Что такое pod в Kubernetes?

Что такое Pod

Pod — базовая (минимальная) единица развертывания в Kubernetes. Это логическая оболочка вокруг одного или нескольких контейнеров, которые запускаются вместе на одном узле, разделяют сетевой и (по желанию) файловый контекст и рассматриваются планировщиком как единое целое. В типичном сценарии Pod содержит один основной контейнер приложения; несколько контейнеров в одном Pod используются для шаблонных паттернов (sidecar, ambassador, adapter).

Внутреннее устройство и поведение

  • Сеть: каждый Pod получает собственный IP-адрес. Контейнеры внутри Pod-а делят сетевой неймспейс — значит, они видят друг друга по localhost и могут обмениваться данными по локальным портам. containerPort — информационное поле; реальное поведение задаётся политиками сервиса/Ingress.

  • Файловая система: контейнеры могут монтировать общие тома (emptyDir, PVC и т.д.), что позволяет хранить и разделять состояние между контейнерами Pod-а.

  • Процессы: контейнеры изолированы, но могут делить PID/IPC при необходимости (hostPID/hostIPC — специальные опции).

  • Init-контейнеры: выполняются до основных контейнеров, полезны для подготовки окружения (миграции, загрузки конфигов).

  • Жизненные хуки: preStop и postStart позволяют запускать скрипты при старте/остановке контейнера.

  • Эфемерность: Pod — временный объект. Контроллеры (Deployment, ReplicaSet, StatefulSet и т.д.) создают и восстанавливают Pod-ы; напрямую управлять Pod-ами вручную в production не рекомендуется.

Жизненный цикл и статус

  • Фазы: Pending → Running → Succeeded / Failed / Unknown.

  • Контейнеры имеют состояния: Waiting, Running, Terminated. События kubectl describe pod помогают увидеть причины проблем (ImagePullBackOff, CrashLoopBackOff и т.д.).

  • Политика рестарта (restartPolicy) управляет перезапусками контейнеров внутри Pod-а (Always, OnFailure, Never). Для контролируемых нагрузок обычно Always и управление на уровне контроллеров.

  • QoS-классы: Guaranteed, Burstable, BestEffort — определяется наличием requests и limits CPU/RAM; влияет на эвикшен при давлении на узел.

Ключевые поля манифеста (короткий пример)

apiVersion: v1
kind: Pod
metadata:
name: web-pod
labels:
app: web
spec:
containers:
\- name: web
image: nginx:1.23
ports:
\- containerPort: 80
resources:
requests: { cpu: "100m", memory: "128Mi" }
limits: { cpu: "500m", memory: "512Mi" }
readinessProbe:
httpGet: { path: "/", port: 80 }
initialDelaySeconds: 5
livenessProbe:
httpGet: { path: "/health", port: 80 }
initialDelaySeconds: 15
restartPolicy: Always

Пояснения: readinessProbe сообщает контроллеру, когда Pod готов принимать трафик; livenessProbe — когда контейнер нужно перезапустить; resources влияют на планирование и QoS; labels используются сервисами/селекторами.

Полезные возможности и паттерны

  • Sidecar — лог-агрегатор, proxy, кеш рядом с основным контейнером.

  • Ambassador/Adapter — адаптация/проксирование сторонних API.

  • Init containers для миграций/проверок перед стартом приложения.

  • Ephemeral containers — динамические контейнеры для отладки запущенного Pod-а (debug).

Scheduling, безопасность и управление

  • Scheduling: nodeSelector, nodeAffinity, podAffinity/antiAffinity, tolerations управляют размещением Pod-ов по узлам/AZ.

  • Security: serviceAccount, securityContext (user, capabilities), PodSecurityAdmission, NetworkPolicy — минимизируют привилегии и контролируют сетевой доступ.

  • Immutable fields: некоторые поля Pod-а нельзя менять после создания — контроллеры пересоздают Pod при изменениях шаблона.

Лучшие практики

  • Деплойте Pod-ы через контроллеры (Deployment/StatefulSet), не вручную.

  • Задавайте requests и limits для корректного планирования и предсказуемой работы.

  • Используйте readiness probe, чтобы избежать отправки трафика на ещё неготовые Pod-ы.

  • Держите контейнеры в Pod-е одноцелевыми; sidecar-паттерн для вспомогательных задач.

  • Не храните критичные данные в emptyDir — используйте PVC и управляемые хранилища.

  • Ограничивайте права через securityContext и RBAC, используйте non-root.

Когда Pod не подходит

Для долговременного хранения состояния и прямого управления экземпляром лучше использовать StatefulSet с PersistentVolumes или управляемые облачные сервисы (DBaaS). Pod — отличен для самовосстановляемых, масштабируемых приложений, но не для ручного управления долгоживущими инстансами.