Zero-downtime выкладки в Kubernetes

Релиз в прод должен быть скучным. Ниже — минимум контроля, без которого «безопасный» rollout обычно небезопасен.

Почему падают выкладки#

Чаще всего виноваты не «баги Kubernetes», а отсутствие readiness, агрессивный disruption и резкий cutover трафика.

Какие сигналы важны#

• Readiness должен падать, пока процесс реально не готов принимать трафик.
• Liveness перезапускает зависшее — но не во время прогрева.
• Startup probes дают время тяжёлым рантаймам и миграциям.

Оценка ёмкости на всплеске#

Если базовый RPS — $R$, а пиковый множитель — $k$, нужен запас примерно:

где $m$ — safety margin (обычно начинаем с $0.25$).

Пример Deployment#

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      containers:
        - name: api
          readinessProbe:
            httpGet:
              path: /readyz
              port: 8080
            periodSeconds: 5

Контракт probe важнее фреймворка:

export async function readyz(ctx: Context) {
  await ctx.db.ping(); 
  return ctx.json({ ok: true });
}

Чеклист перед promote#

1. PDB оставляет хотя бы одну здоровую реплику.
2. Миграции обратно совместимы на один релиз.
3. Дашборды покрывают ошибки, latency и saturation.
4. Rollback отрепетирован, а не «на бумаге».

Итог#

Zero downtime — это дисциплина, а не одна аннотация. Начните с probes и PDB, остальное автоматизируйте.