Зондирование Kubernetes Pod
abcdocker перспектива DevOps
Введение в капсулу
Каждый Pod имеет специальный контейнер Pause, который называется корневым контейнером. Изображение, соответствующее контейнеру Pause, является частью платформы Kubernetes.В дополнение к контейнеру Pause каждый Pod также содержит один или несколько тесно связанных бизнес-контейнеров пользователей.
Почему Kubernetes разработал новую концепцию Pod с такой особой структурой?
- Контейнер Pause служит корневым контейнером Pod, и его состояние представляет состояние всей группы контейнеров.
- Несколько бизнес-контейнеров в Pod совместно используют IP-адрес контейнера Pause, а Volume
Kubernetes, к которому подключен контейнер Pause, назначает уникальный IP-адрес каждому Pod, который называется Pod IP. Несколько контейнеров в Pod совместно используют IP-адрес Pod. Kubernetes требует, чтобы базовая сеть поддерживала прямую связь TCP / IP между любыми двумя модулями в кластере с использованием сетевой технологии виртуального уровня 2 для достижения прямой связи между контейнером в одном модуле и контейнером модулей на другом хосте.Статическая и обычная капсулы
Обычная капсула
Как только обычный Pode создан, он будет сохранен в etcd, а затем будет назначен Kubernetes Master на конкретный узел и привязан (привязка), а затем Pod будет создан процессом kubelet на соответствующем узле. A набор связанных контейнеров докеров запущен и работает. Когда контейнер в Pod останавливается, Kubernetes автоматически обнаруживает проблему и перезапускает Pod (перезапускает все контейнеры в Pod). Если узел, на котором расположен Pod, выходит из строя, все Pod на этом узле будут перенесены на другой узлы.
Статический модуль (STatic Pod)
Статический Pod не хранится в хранилище etcd Kubernetes, а хранится в файле на определенном узле, запускается и выполняется только на этом узле.
Статический модуль - это модуль, управляемый kubelet, который существует только на определенном узле. Они не могут управляться через сервер API, не могут быть связаны с ReplicationController (RC), Deployment или DaemonSet, а kubelet не может выполнять на них проверку работоспособности. Static Pod всегда создается kubelet и всегда запускается на узле, где расположен kubelet.Конечная точка
IP-адрес модуля и порт контейнера здесь образуют совершенно новую концепцию - конечную точку, которая представляет собой внешний коммуникационный адрес процесса службы в этом модуле. Pod также имеет несколько конечных точек.Например, когда мы определяем Tomcat как Pod, мы можем предоставить две конечные точки, порт и порт службы.
Мероприятие
Событие - это запись события, в которой записывается время самого раннего возникновения события, время последнего повторения, количество повторений, инициатор, тип и причина события, а также много другой информации. Событие обычно связано с конкретным ресурсом, который является важным справочным материалом для устранения неполадок.Информация об описании узла включает событие, а модуль Pod также содержит записи о событиях.
Когда мы обнаруживаем, что Pod не может быть создан в течение длительного времени, мы можем использовать kubectl describe pod [Pod name], чтобы проверить и найти проблему.
Пример:
# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-5c6b9976cc-2qbkr 0/1 ContainerCreating 0 14s
nginx-deployment-5c6b9976cc-bqtvp 0/1 ContainerCreating 0 14s
nginx-deployment-5c6b9976cc-ttdrz 0/1 ContainerCreating 0 14s
# kubectl describe pod nginx-deployment-5c6b9976cc-2qbkr
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 35s default-scheduler Successfully assigned default/nginx-deployment-5c6b9976cc-2qbkr to master
Warning FailedCreatePodSandBox 6s (x2 over 28s) kubelet, master Failed create pod sandbox: rpc error: code = Unknown desc = failed pulling image "gcr.io/google_containers/pause-amd64:3.0": Error response from daemon: Get https://gcr.io/v1/_ping: dial tcp 74.125.203.82:443: getsockopt: connection timed out