Pod в Kubernetes — это такая минимальная «капсула», в которой живут один или несколько контейнеров. Они запускаются вместе, делят один IP-адрес, сетевой стек и подключённые тома. Для них друг друга видно как localhost, а общие директории через volume выглядят как обычная файловая система, доступная сразу всем контейнерам внутри пода.
Управляется под как единое целое. Если один контейнер в нём падает, Kubernetes рассматривает ситуацию на уровне всего пода и может перезапустить его полностью. Поэтому внутрь одного пода обычно кладут тесно связанные процессы: например, само приложение и sidecar-контейнер, который занимается логированием, проксированием трафика, метриками и прочей обвязкой.
Каждый под получает свой IP внутри кластера, и другие поды могут ходить к нему по внутренней сети. Через kubectl describe pod смотрят подробности конфигурации и статуса, kubectl logs показывает логи конкретного контейнера, а kubectl exec позволяет «зайти внутрь» и выполнить команду в контейнере.
Если упрощать, контейнер — это просто процесс в изолированной среде, а pod — это более высокий уровень: он описывает, как этот процесс живёт в кластере. Где хранить данные, какие порты открыть, как взаимодействовать с другими сервисами, какие ресурсы ему выделять — всё это задаётся именно на уровне пода.
Поды — базовый строительный блок Kubernetes. За счёт них платформа умеет быстро поднимать и убивать копии приложения, масштабировать их под нагрузку, переживать сбои отдельных узлов. K8s просто создаёт или удаляет поды по необходимости, и с точки зрения разработчика это выглядит как автоматическое управление жизненным циклом сервиса.
Если совсем в лоб сравнивать:
– Container — это единица запуска (отдельный процесс, например в Docker),
– Pod — единица развертывания и управления в Kubernetes, в которой может быть сразу несколько контейнеров.
Понимание, как устроены поды и зачем они нужны, — это такой входной билет в Kubernetes. Без этого сложно грамотно строить микросервисы, CI/CD-пайплайны и вообще какие-то вменяемо масштабируемые облачные системы.
Пример YAML-файла для Pod #
Ниже — простой пример манифеста пода с одним контейнером nginx:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
labels:
app: demo
spec:
containers:
- name: nginx-container
image: nginx:1.25
ports:
- containerPort: 80
resources:
limits:
memory: "128Mi"
cpu: "500m"
Что делает этот под на практике:
- Запускает контейнер с образом
nginx:1.25. - Открывает внутри контейнера порт 80, чтобы nginx мог принимать HTTP-трафик.
- Ограничивает ресурсы: максимум 128 МБ памяти и половина CPU (0.5 vCPU).
- Даёт поду имя
example-podи простую меткуapp: demo, чтобы потом можно было удобно его искать и привязывать сервисы.
Пример Pod с двумя контейнерами #
А вот пример пода, где контейнеров уже два: основной и sidecar для логов.
apiVersion: v1
kind: Pod
metadata:
name: multi-container-pod
labels:
app: demo-multi
spec:
containers:
- name: app-container
image: nginx:1.25
ports:
- containerPort: 80
volumeMounts:
- name: shared-logs
mountPath: /var/log/nginx
- name: log-sidecar
image: busybox
command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]
volumeMounts:
- name: shared-logs
mountPath: /var/log/nginx
volumes:
- name: shared-logs
emptyDir: {}
Что здесь происходит: #
- Первый контейнер,
app-container, поднимает nginx — это основное приложение. - Второй контейнер,
log-sidecar, запускаетbusyboxи просто вечно читает файлaccess.logчерезtail -f. - Они оба монтируют один и тот же том
shared-logs, созданный какemptyDir. Это временное общее хранилище, доступное обоим контейнерам пока живёт под. - С точки зрения Kubernetes это один объект: под. Он стартует, останавливается и пересоздаётся целиком, а контейнеры внутри ведут себя как единый логический блок.
