Обратитесь к официальной документации сайта Kubernetes: Pod
Pod — это наименьшая единица вычислений, которую вы можете создать и управлять в Kubernetes. Pod (как стая китов или стручок гороха) — это группа из одного или нескольких контейнеров (например, Docker-контейнеров) с общими ресурсами хранения и сети, а также спецификацией того, как запускать эти контейнеры. Pods являются фундаментальными строительными блоками, на которых основаны все контроллеры более высокого уровня (например, Deployments, StatefulSets, DaemonSets).
Хотя Pods часто управляются контроллерами более высокого уровня, прямые операции kubectl с Pod'ами полезны для устранения неполадок, инспекции и выполнения разовых задач.
Чтобы вывести список всех Pod в текущем namespace:
Чтобы вывести список всех Pod во всех namespace:
Чтобы получить подробную информацию о конкретном Pod:
Чтобы просмотреть логи контейнера внутри Pod (полезно для отладки):
Если в Pod несколько контейнеров, необходимо указать имя контейнера:
Чтобы следить за логами в режиме реального времени (поток новых логов по мере их появления):
Чтобы выполнить команду внутри конкретного контейнера в Pod (полезно для отладки, например, доступа к shell):
Для проброса локального порта на порт Pod, что позволяет напрямую получить доступ к сервису, работающему внутри Pod, с вашей локальной машины (полезно для тестирования или прямого доступа без внешнего экспонирования сервиса):
После выполнения этой команды вы сможете получить доступ к веб-серверу Nginx, работающему в my-nginx-pod, перейдя в браузере по адресу localhost:8080 .
Чтобы удалить конкретный Pod:
Чтобы удалить несколько Pod по именам:
Чтобы удалить Pod по селектору меток (например, удалить все Pod с меткой app=nginx):
Интерфейс платформы предоставляет различную информацию о Pod для быстрого ознакомления.
В Container Platform перейдите в Workloads > Pods в левой боковой панели.
Найдите Pod, который хотите просмотреть.
Нажмите на имя деплоя, чтобы увидеть Details, YAML, Configuration, Logs, Events, Monitoring и другие вкладки.
Ниже приведены пояснения к некоторым параметрам:
Параметр | Описание |
---|---|
Resource Requests & Limits | Resource Requests и Limits определяют границы потребления CPU и памяти для контейнеров внутри Pod, которые затем суммируются для формирования общего профиля ресурсов Pod. Эти значения важны для планировщика Kubernetes, чтобы эффективно размещать Pod на узлах, а также для kubelet, чтобы обеспечивать управление ресурсами.
m для milliCPU, Mi для мебибайт) см. Resource Units. Логика расчёта ресурсов на уровне Pod Эффективные значения Requests и Limits CPU и памяти для Pod вычисляются как сумма и максимум значений отдельных контейнеров. Метод расчёта для Requests и Limits на уровне Pod аналогичен; в этом документе приведена логика на примере Limit. Если Pod содержит только стандартные контейнеры (рабочие контейнеры): Эффективное значение Limit CPU/памяти Pod — это сумма Limit CPU/памяти всех контейнеров внутри Pod. Пример: если Pod содержит два контейнера с Limit CPU/памяти 100m/100Mi и 50m/200Mi соответственно, то агрегированный Limit CPU/памяти Pod будет 150m/300Mi. Если Pod содержит как initContainers, так и стандартные контейнеры: Шаги расчёта Limit CPU/памяти Pod следующие:
|
Source | Контроллер рабочей нагрузки Kubernetes, управляющий жизненным циклом этого Pod. Это могут быть Deployments, StatefulSets, DaemonSets, Jobs. |
Restart | Количество перезапусков контейнера внутри Pod с момента запуска Pod. Высокое количество перезапусков часто указывает на проблему с приложением или его окружением. |
Node | Имя Kubernetes Node, на котором в данный момент запланирован и работает Pod. |
Service Account | Service Account — это объект Kubernetes, предоставляющий идентичность процессам и сервисам, работающим внутри Pod, позволяя им аутентифицироваться и получать доступ к Kubernetes APIServer. Это поле обычно видно только пользователям с ролью администратора платформы или аудитора платформы, что позволяет просматривать YAML-определение Service Account. |
Удаление Pod может повлиять на работу вычислительных компонентов; пожалуйста, действуйте осторожно.
Быстро восстановить Pod в желаемое состояние: если Pod находится в состоянии, влияющем на бизнес-процессы, например Pending
или CrashLoopBackOff
, ручное удаление Pod после устранения ошибки поможет ему быстро вернуться в желаемое состояние, например Running
. При этом удалённые Pod будут пересозданы на текущем узле или переназначены.
Очистка ресурсов для управления операциями: некоторые Pod достигают определённого этапа, когда они больше не изменяются, и такие группы часто накапливаются в большом количестве, усложняя управление другими Pod. К Pod, подлежащим очистке, могут относиться те, что находятся в статусе Evicted
из-за нехватки ресурсов узла, или в статусе Completed
, вызванном повторяющимися запланированными задачами. В этом случае удалённые Pod больше не будут существовать.
Примечание: для запланированных задач, если необходимо проверять логи каждого выполнения задачи, не рекомендуется удалять соответствующие Pod со статусом Completed
.
Перейдите в Container Platform.
В левой навигационной панели нажмите Workloads > Pods.
(Удаление по одному) Нажмите ⋮ справа от Pod, который нужно удалить > Delete, подтвердите действие.
(Массовое удаление) Выберите Pod для удаления, нажмите Delete над списком и подтвердите.