Pod: минимальная единица в Kubernetes

В Docker ты запускаешь контейнер. В Kubernetes минимальная единица — Pod. Это не просто обёртка над контейнером, а принципиально иная абстракция.

Что такое Pod

Pod — это группа из одного или нескольких контейнеров, которые:

• Запускаются вместе на одном узле
• Разделяют одну сеть (один IP-адрес, localhost между собой)
• Разделяют одни volumes (общая файловая система)
• Имеют общий жизненный цикл — стартуют и умирают вместе

Чаще всего в Pod живёт один контейнер. Несколько контейнеров используют, когда нужен sidecar-паттерн: основное приложение + логгер/прокси/агент.

Аналогия: Pod — это квартира. В ней могут жить несколько жильцов (контейнеров), у них общий почтовый ящик (IP) и общая кладовка (volume). Жильцы свободно общаются через localhost.

Создание Pod императивно

# Запустить Pod с nginx
kubectl run nginx --image=nginx:1.25

# Запустить Pod и сразу попасть внутрь
kubectl run -it busybox --image=busybox --restart=Never -- sh

# Удалить Pod
kubectl delete pod nginx

Создание Pod декларативно (YAML)

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
    env: production
spec:
  containers:
    - name: app
      image: nginx:1.25
      ports:
        - containerPort: 80
      resources:
        requests:
          memory: "64Mi"
          cpu: "100m"
        limits:
          memory: "128Mi"
          cpu: "200m"

# Применить манифест
kubectl apply -f pod.yaml

# Удалить через манифест
kubectl delete -f pod.yaml

Pod с несколькими контейнерами (sidecar)

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: app
      image: my-app:1.0
      ports:
        - containerPort: 8000
    - name: log-shipper
      image: fluentd:v1.16
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
  volumes:
    - name: logs
      emptyDir: {}

Оба контейнера видят один и тот же volume /var/log/app. Приложение пишет логи, fluentd их собирает.

Жизненный цикл Pod

Pending → Running → Succeeded
                  ↘ Failed
                  ↘ Unknown

• Pending — Pod принят кластером, но ещё не запущен. Scheduler ищет подходящий узел, образ скачивается.
• Running — Pod размещён на узле, хотя бы один контейнер запущен.
• Succeeded — все контейнеры завершились успешно (код 0). Типично для Job.
• Failed — хотя бы один контейнер завершился с ошибкой.
• Unknown — состояние не удаётся определить (проблемы с узлом).

Статусы контейнеров внутри Pod: Waiting, Running, Terminated.

kubectl команды для работы с подами

# Список всех подов в namespace default
kubectl get pods

# Список с дополнительной информацией (IP, Node)
kubectl get pods -o wide

# Подробная информация о поде (события, состояние)
kubectl describe pod my-app

# Логи контейнера
kubectl logs my-app

# Логи конкретного контейнера в multi-container Pod
kubectl logs my-app -c log-shipper

# Следить за логами в реальном времени
kubectl logs -f my-app

# Выполнить команду внутри контейнера
kubectl exec -it my-app -- bash

# Пробросить порт с пода на localhost
kubectl port-forward pod/my-app 8080:80

# Пример вывода kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
my-app     1/1     Running   0          5m
busybox    0/1     Completed 0          2m

Почему Pod не используют напрямую в production

Pod — это смертная единица. Если узел упал или Pod завершился с ошибкой, никто его не перезапустит — Pod просто исчезнет навсегда.

В production нужно гарантировать, что нужное количество подов всегда работает. Для этого используют Deployment → он создаёт ReplicaSet → который управляет подами.

Единственный случай, когда Pod создают напрямую — это отладка и разовые задачи (kubectl run для диагностики).

Правило: в production всегда создавай Deployment, никогда не создавай Pod напрямую.