Pod, Deployment и Service в Kubernetes: объяснение на примерах

Короткий ответ

Чтобы запустить приложение в Kubernetes, обычно нужны три объекта:

• Pod — минимальная единица запуска: один или несколько контейнеров с общей сетью.
• Deployment — описывает, сколько подов нужно и из какого образа, и поддерживает это состояние.
• Service — стабильный адрес и балансировщик для группы подов.

Связь между ними держится на метках (labels): Deployment создаёт поды с меткой app: web, а Service направляет трафик на все поды с этой меткой.

Pod: где живёт контейнер

Pod — обёртка вокруг контейнера. Контейнеры одного пода разделяют IP-адрес и могут общаться через localhost. Чаще всего в поде один контейнер.

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80

Ключевое свойство: поды временные. Если под упал или нода отказала, этот под не восстановится сам, а у нового будет другой IP. Поэтому поды почти никогда не создают вручную — этим занимается Deployment.

Deployment: сколько копий и какой версии

Deployment говорит: «держи три пода по такому шаблону». Если под исчезнет, Deployment создаст замену. Если изменить образ, он постепенно заменит старые поды новыми.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi

Что здесь важно:

• replicas — желаемое число подов.
• selector.matchLabels должен совпадать с template.metadata.labels, иначе Deployment не примет конфигурацию.
• template — шаблон пода, по сути тот же Pod из примера выше.
• resources помогает планировщику размещать поды и защищает ноду от перегрузки.

Под капотом Deployment создаёт ReplicaSet, который непосредственно следит за числом подов. Напрямую с ReplicaSet работать обычно не нужно.

Service: постоянный адрес

IP подов меняются, поэтому обращаться к ним напрямую нельзя. Service получает постоянное имя и IP внутри кластера и распределяет запросы между подходящими подами.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Теперь другие поды в том же namespace обращаются к приложению по адресу http://web.

Основные типы Service:

Для HTTP-сайтов с доменами обычно добавляют Ingress — он маршрутизирует запросы по домену и пути к нужным Service.

Как всё работает вместе

1. Вы применяете файлы: kubectl apply -f deployment.yaml -f service.yaml.
2. Deployment создаёт ReplicaSet, тот — три пода с меткой app: web.
3. Scheduler распределяет поды по нодам.
4. Service находит поды по селектору app: web и начинает слать им трафик.
5. Под упал — Deployment создаёт новый, Service автоматически включает его в балансировку.

Полезные команды для проверки:

kubectl get pods -l app=web
kubectl describe deployment web
kubectl get endpoints web
kubectl rollout status deployment/web

Частые ошибки

• Метки не совпадают. Селектор Service не находит поды — kubectl get endpoints покажет пустой список.
• Перепутаны port и targetPort. port — порт Service, targetPort — порт контейнера.
• Поды без Deployment. Ручной под не переживёт сбой ноды.
• Нет readiness probe. Service может отправить трафик в под, который ещё не готов принимать запросы.
• Тег latest. Сложно понять, какая версия запущена, и откатиться.

Подробнее — в документации Kubernetes.