Что такое под и зачем он нужен:
Kubernetes не управляет контейнерами напрямую, он управляет подами. Под это группа из одного или нескольких контейнеров, которые делят между собой сеть (один IP-адрес, общий localhost) и могут делить тома с данными. В девяноста процентах случаев в поде ровно один контейнер, и это нормально. Несколько контейнеров кладут в один под, когда они не имеют смысла друг без друга: например, приложение плюс агент, который собирает его логи. Такой паттерн называют sidecar. Начиная с Kubernetes 1.33 сайдкары это нативная фича (GA): сайдкар-контейнер объявляют в initContainers с restartPolicy: Always. Тогда он гарантированно стартует раньше основного контейнера, живёт рядом с ним весь срок жизни пода, а в Job не мешает поду завершиться, когда основной контейнер закончил работу. В 2026 новые сайдкары делайте именно так, а не вторым элементом в containers, как в старых статьях.
Факт, который экономит часы при отладке: контейнеры внутри одного пода видят друг друга по localhost и всегда работают на одной ноде. Разные поды, наоборот, общаются по сети через свои IP.
Первый под:
Самый быстрый способ, команда kubectl run:
Код: Выделить всё
kubectl run nginx --image=nginx:1.27Код: Выделить всё
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80Применяем и смотрим:
Код: Выделить всё
kubectl apply -f nginx-pod.yaml
kubectl get pods
kubectl describe pod nginxЗаглянуть внутрь работающего пода:
Код: Выделить всё
kubectl logs nginx
kubectl exec -it nginx -- sh
kubectl port-forward pod/nginx 8080:80Типичные грабли:
Первое. Под удалили или нода упала, и он исчез навсегда. Так и задумано: голый под никто не пересоздаёт. Самовосстановление даёт Deployment, про него следующая глава. Голые поды в проде это почти всегда ошибка.
Второе. Статус ImagePullBackOff. Чаще всего опечатка в имени образа или тега, либо приватный registry без секрета доступа. Точная причина будет в Events у describe. Из СНГ docker.io временами отдаёт образы медленно и с лимитами, многие держат зеркало или прокси-registry, это нормальная практика.
Третье. CrashLoopBackOff. Контейнер стартует и сразу падает, kubelet перезапускает его с растущей паузой. За перезапуски отвечает поле restartPolicy в спеке пода: Always (по умолчанию), OnFailure или Never. Важно не путать два уровня: restartPolicy это про рестарт контейнеров внутри живого пода на той же ноде, а пересоздание самого пода после удаления или смерти ноды, как в первых граблях, никакая restartPolicy не обеспечит, это работа контроллера вроде Deployment. Отлаживать так: первым делом kubectl logs, а если контейнер уже успел перезапуститься, kubectl logs nginx --previous покажет вывод прошлого запуска.
Четвёртое. Правка спеки живого пода через kubectl edit. Почти все поля спеки неизменяемы, кластер откажет с ошибкой про forbidden fields. Но есть короткий список исключений: spec.containers[*].image и initContainers[*].image, activeDeadlineSeconds, плюс можно добавлять tolerations. То есть поменять образ у живого пода как раз можно: API-сервер примет правку, kubelet остановит контейнер и запустит его с новым образом. Для экспериментов удобно, но в проде так не делайте, реальное состояние тут же разъезжается с манифестом в git. Для всех остальных полей путь один: удалить под и применить манифест заново, либо дождаться Deployment, который умеет катить обновления сам.
Итог:
Под это атом Kubernetes: обёртка над контейнерами с общим IP и общим localhost внутри, описывается YAML-манифестом. Вы умеете создать его через apply, проверить статус и события, прочитать логи, зайти внутрь и пробросить порт. Главное ограничение пода в том, что он смертен и сам не возрождается. Как заставить кластер держать нужное число копий и переживать падения, разберём в следующей главе про Deployment и ReplicaSet.
