Deployment и Service

Как читать манифест и что произойдёт при его применении.

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: registry.example.com/web:1.4.2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi

Разбор по частям:

• replicas: 3 — желаемое количество подов.
• selector — по каким меткам Deployment находит «свои» поды. Должен совпадать с template.metadata.labels, иначе объект не создастся.
• template — шаблон Pod. Любое изменение здесь запускает выкат новой версии.

requests и limits — разные вещи

Их путают чаще всего:

• requests — сколько гарантированно нужно. Планировщик по этому числу выбирает ноду. Если ни на одной ноде нет столько свободного, под останется в Pending.
• limits — потолок. Превышение по памяти означает OOMKilled; превышение по CPU не убивает, а притормаживает процесс.

Практическое правило: лимит по памяти ставить обязательно, лимит по CPU — осторожно. Троттлинг CPU даёт медленные ответы, которые сложно диагностировать, тогда как отсутствие лимита памяти позволяет одному поду выжить соседей с ноды.

Service

Поды смертны и получают новый IP при каждом пересоздании. Service даёт стабильный адрес:

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

Service находит поды по тем же меткам и балансирует трафик между теми, что готовы. Внутри кластера он доступен по имени: http://web из того же namespace.

port — на чём слушает Service, targetPort — куда он шлёт в под. Их путаница — частая причина «сервис есть, а ответа нет».

Проверить, что связка работает

kubectl get endpoints web

Если список пуст — Service никого не нашёл. Почти всегда это несовпадение меток между Service.spec.selector и метками подов, либо поды не готовы (не проходит readiness).

Что происходит при выкате

Меняете тег образа и применяете. Deployment создаёт новый ReplicaSet и постепенно переключает: поднимает новые поды, дожидается их готовности, гасит старые.

kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web      # откат

Без корректного readiness-пробы это ломается: Kubernetes считает под готовым сразу после старта и переводит на него трафик до того, как приложение сможет отвечать.