Код-ревью Middle Стратегии деплоя обновлено

Код-ревью: Deployment для безопасной выкатки

Вопрос

Этот Deployment выкатывают rolling update несколько раз в день. Найдите, что приведёт к простою или ошибкам при выкатке.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 100%
  selector:
    matchLabels: {app: api}
  template:
    metadata:
      labels: {app: api}
    spec:
      terminationGracePeriodSeconds: 0
      containers:
        - name: api
          image: registry.example.ru/api:latest
          ports: [{containerPort: 8080}]
          livenessProbe:
            httpGet: {path: /health/db, port: 8080}

Коротко

Безопасная выкатка держится на трёх вещах: стратегия, которая не опускает доступность ниже нужной, readiness, которая пускает трафик только в готовые поды, и graceful shutdown, который даёт доработать начатое.

Что должен найти ревьюер

  1. Ошибкастрока 11
    maxUnavailable: 100% при maxSurge: 0 разрешает погасить все поды сразу: по сути Recreate с простоем. Для API нужно maxUnavailable: 0 и maxSurge: 1 или 25%.
  2. Ошибкастрока 18
    terminationGracePeriodSeconds: 0 убивает контейнер сразу, текущие запросы рвутся. Нужен graceful shutdown по SIGTERM и разумный период.
  3. Ошибкастрока 21
    Тег latest: непонятно, что выкачено, rollout undo может вернуть тот же образ. Тег по SHA или версии.
  4. Ошибкастрока 23
    Нет readinessProbe: трафик пойдёт в под до того, как приложение готово.
  5. Ошибкастрока 24
    Liveness проверяет базу: при сбое БД kubelet перезапустит все поды, и сервис не поднимется даже после восстановления базы. Liveness проверяет только сам процесс.
  6. Производительностьстрока 20
    Нет resources.requests и limits: планировщик не знает, сколько ресурсов нужно, поды могут вытесняться и мешать соседям.

Разбор

Безопасная выкатка держится на трёх вещах: стратегия, которая не опускает доступность ниже нужной, readiness, которая пускает трафик только в готовые поды, и graceful shutdown, который даёт доработать начатое. Ошибка в liveness с проверкой зависимостей отдельная классика: она превращает сбой базы в каскадный рестарт всего сервиса.

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.