Паттерн деплоя в Kubernetes

Действуй как Senior SRE. Спроектируй Kubernetes-манифесты для сервиса: {{service_kind}}, профиль трафика: {{traffic_profile}}.

Шаги

1. Выбери тип workload.

   • Deployment — stateless: API, воркеры с горизонтальным масштабированием.
   • StatefulSet — если нужны стабильные имена pod'ов, постоянные тома per-replica или порядок старта (БД, брокеры).
   • DaemonSet — по одному pod'у на ноду (логгер, агент мониторинга, CNI).
   • Job/CronJob — разовая или периодическая задача с гарантией завершения. Обоснуй выбор: если выбираешь Deployment, объясни почему не StatefulSet.

2. Стратегия выката.

   • RollingUpdate с maxSurge и maxUnavailable под профиль: для API с резервом ресурсов — maxSurge: 25%, maxUnavailable: 0.
   • Blue/Green через два Service'а или Argo Rollouts — когда нужен мгновенный rollback и нет места для смешения версий (миграции схемы, протокольные изменения).
   • Canary — Argo Rollouts/Flagger с метриками: 5% → 25% → 100% по SLO.

3. Probes. Это самый частый источник outage'ов.

   • startupProbe — для медленно стартующих приложений; пока он не пройдёт, остальные не проверяются.
   • readinessProbe — снимает pod из Service при деградации. Проверяй зависимости (БД connectivity), но осторожно: каскадный fail БД выкинет все pod'ы.
   • livenessProbe — только для безвозвратных зависаний. Слишком агрессивный liveness = perma-restart loop.

4. Resource limits.

   • requests ставь по p50 фактического потребления (после нагрузочных тестов).
   • limits для CPU зачастую не нужны (throttling вреднее перерасхода); для memory обязательны, иначе OOM убьёт соседей.
   • QoS-класс Guaranteed (requests == limits) — для критичных сервисов.

5. Anti-affinity и распределение.

   • podAntiAffinity по topology.kubernetes.io/zone — реплики в разных AZ.
   • topologySpreadConstraints — для равномерного распределения по нодам без жёсткого запрета.
   • PDB (PodDisruptionBudget) с minAvailable — защита при drain.

6. HPA. Метрика — то, что коррелирует с user-perceived latency. CPU подходит для CPU-bound, для HTTP-сервисов лучше custom metric (RPS на pod, p95-latency). minReplicas ≥ 2, maxReplicas — с запасом x3 от ожидаемого пика, scale-down stabilization window 5+ минут.

Anti-patterns

• ❌ livenessProbe проверяет /health, который дёргает БД — БД мигнула, все pod'ы рестартанули, лавина.
• ❌ Нет PodDisruptionBudget → node drain убивает все реплики одновременно.
• ❌ maxUnavailable: 25% без PDB — кластерный апгрейд снесёт половину сервиса.
• ❌ HPA по CPU для I/O-bound сервиса — масштабирование не сработает в нужный момент.
• ❌ Одинаковые requests = limits = 4Gi для всех pod'ов "на всякий случай" — кластер не плотный, деньги горят.

Формат вывода

# Workload
<манифест Deployment/StatefulSet с обоснованием каждого блока в комментариях>

# HPA
<манифест с обоснованием метрики>

# PDB + NetworkPolicy (если применимо)

Принцип: каждое значение в манифесте должно быть осознанно выбрано. Если копипастишь чужой YAML — объясни хотя бы себе, почему именно эти числа.