Pod — базовая единица в Kubernetes. Не является контейнером: Pod — обёртка вокруг одного или нескольких Docker-контейнеров, которые делят сетевое пространство (один IP) и тома хранилища. Kubernetes управляет Pod-ами, а не контейнерами напрямую.
Как работает
Каждый Pod получает уникальный IP-адрес внутри кластера. Контейнеры внутри одного Pod общаются через localhost и разделяют файловую систему через смонтированные Volume. Жизненный цикл Pod: Pending (ожидание планирования) → Running (запущен) → Succeeded/Failed (завершён).
Pod — эфемерный объект: при падении Pod не перезапускается (это делает контроллер). Pod создаётся заново с новым именем и IP. Поэтому в Kubernetes Pod-ы не создают напрямую — используют Deployment, StatefulSet, DaemonSet. Deployment поддерживает нужное число реплик Pod-ов и выполняет rolling update.
Init контейнеры в Pod выполняются до старта основных контейнеров: например, ожидание доступности базы данных или миграция схемы. Sidecar-контейнеры работают параллельно с основным: log-агент, service mesh proxy (Envoy в Istio).
История
Концепция Pod разработана в Google на основе опыта Borg (внутренняя система оркестрации Google с 2003 года) и Omega. Kubernetes публично анонсирован в июне 2014 года. Группировка контейнеров в Pod отражает паттерн «sidecar», описанный в Borg: вспомогательные процессы работают рядом с основным приложением, деля ресурсы. Pod как концепция унаследована Kubernetes 1.0 (2015) без принципиальных изменений.
Pod lifecycle и управление
Pod проходит через следующие фазы: Pending (ожидает планирования или скачивания образа), Running (хотя бы один контейнер запущен), Succeeded (все контейнеры завершились с кодом 0), Failed (хотя бы один завершился с ненулевым кодом), Unknown (состояние неизвестно, обычно проблема с нодой). Команды управления: kubectl get pods -n namespace, kubectl describe pod
Restart policies: Always (перезапускать всегда — для long-running сервисов), OnFailure (только при ошибке — для batch-задач), Never (не перезапускать). Resources requests и limits: requests.cpu/memory — гарантированные ресурсы, limits — максимум. Превышение limits.memory → OOM kill контейнера. Pod disruption budget (PDB) — защита от одновременного удаления всех pod при обновлениях.
На что обращать внимание
Один Pod — одна копия приложения. Масштабирование — через увеличение числа реплик в Deployment (replicas: 3). Requests и Limits: resources.requests.memory: 256Mi — минимум, который Kubernetes гарантирует Pod-у при планировании; limits.memory: 512Mi — максимум. Превышение limits по памяти → OOMKilled. Превышение CPU limits → throttling (замедление, не убийство).
Для K3s или Kubernetes на одном VPS: минимум 2 ГБ ОЗУ для самого K8s + overhead Pod-ов. При 4 ГБ комфортно запускать 10–20 небольших Pod-ов.
Pod в деталях
Kubernetes не запускает контейнеры напрямую — только через Pods. Каждый Pod получает свой IP в сети кластера. Containers в Pod разделяют localhost: если один контейнер слушает :8080, другой обращается через localhost:8080. Sidecar-паттерн: второй контейнер в Pod — для логирования (fluentd), мониторинга (Envoy proxy) без изменения основного приложения. На K3s: Pods управляются через kubectl get pods -A. Docker-образ можно деплоить как Pod через простой манифест без Deployment.