✅ Чеклист по нулевому времени простоя в Kubernetes

🔴 Обновления (RollingUpdate)

Компонент	Настройка	Цель	Риски при отсутствии
Deployment strategy	spec.strategy.rollingUpdate.maxUnavailable: 0	Исключить падение количества pod ниже replicas при обновлении	Потеря доступности при rollout
ReadinessProbe / StartupProbe	Настроены	Не направлять трафик на неготовые pod	Ошибки 5xx, падение RPS
LivenessProbe	Только при необходимости	Перезапуск «зависших» контейнеров	Флаппинг pod при неверной настройке
PreStop hook + terminationGracePeriodSeconds	Добавлен sleep перед SIGTERM	Дать время убрать pod из endpoints	Потеря запросов при остановке pod

Полезные факты:

• ReadinessProbe должна проверять именно готовность приложения, а не факт запущенного процесса.
• StartupProbe предотвращает ранние перезапуски, особенно для приложений с долгим стартом.
• Всегда проверяйте время завершения pod на проде, чтобы правильно подобрать terminationGracePeriodSeconds.
• LivenessProbe используйте осторожно: она не должна дублировать readiness.

🟠 Ресурсы и планирование

Компонент	Настройка	Цель	Риски при отсутствии
CPU/Memory Requests	Заданы	Используются для планирования под на ноду и для HPA (среднее потребление)	Pod может быть запущен на перегруженной ноде, HPA не сможет адекватно масштабироваться
CPU/Memory Limits	Заданы	Используются только для ограничения использования ресурсов	Возможен OOMKill и деградация работы других pod

Полезные факты:

• Requests должны подбираться на основе нагрузочного тестирования, а не «на глаз».
• HPA считает утилизацию как usage/requests. Если requests занижены — скейл может быть агрессивным.
• Слишком маленький разрыв между requests и limits приводит к throttling.
• Если ресурсы не заданы — kube-scheduler может запустить под на перегруженную ноду.

🟡 Автоскейлинг

Компонент	Настройка	Цель	Риски при отсутствии
HorizontalPodAutoscaler (HPA)	maxReplicas = 2× пиковая нагрузка (по нагрузочному тесту)	Масштабирование под нагрузку	Недостаток pod в пике, ошибки 5xx
HPA scaleDown stabilization	stabilizationWindowSeconds ≥ 600	Исключить резкие флуктуации реплик	«Пила» при кратковременных просадках RPS

Полезные факты:

• Настраивайте метрики HPA не только по CPU, но и по RPS/latency через custom metrics.
• Всегда проверяйте, что внешние системы (БД, очереди) выдерживают рост pod.
• Важно протестировать «горячее» масштабирование под нагрузкой.
• Для долгоживущих соединений (например WebSocket) учитывайте, что новый pod не сразу получит трафик.

🟢 Доступность при обслуживании (Maintenance)

Компонент	Настройка	Цель	Риски при отсутствии
PodDisruptionBudget (PDB)	minAvailable или maxUnavailable	Минимальное число pod при drain/upgrade	Одновременное завершение всех pod
TopologySpreadConstraints	Распределение pod по zone или hostname	Устойчивость к отказу ноды/зоны	Снижение доступности при падении ноды

Полезные факты:

• PDB защищает от kubectl drain, Cluster Autoscaler и обновлений ASG.
• PDB + maxUnavailable в Deployment должны быть согласованы, иначе могут заблокировать обновление.
• TopologySpreadConstraints помогают не только при падении ноды, но и при сетевых проблемах в AZ.
• При малом числе pod стоит использовать DoNotSchedule, а не ScheduleAnyway, чтобы сохранить равномерность.

🔵 Fault Tolerance (устойчивость к ошибкам)

Компонент	Настройка	Цель	Риски при отсутствии
Service Mesh Circuit Breaker	Outlier detection (Istio / Linkerd)	Изоляция «плохих» pod, защита от каскадных отказов	Срыв всей системы из-за единичных pod с ошибками
Circuit Breaker параметры	consecutiveErrors, maxEjectionPercent	Управляемый вывод pod из пула	Массовые ошибки, перегрузка клиентов
Timeouts (Linkerd)	request: 2s	Ограничение времени ответа	Подвисшие запросы блокируют клиентов
Retries (Linkerd)	attempts: 2	Повтор неудачных запросов	Потеря запросов при временных сбоях

Полезные факты:

• В Istio используйте baseEjectionTime и interval для управления деградацией.
• Не ставьте слишком маленькие timeouts — это создаст ложные ошибки.
• Лимит на количество retries обязателен, иначе нагрузка при сбое удвоится.
• Circuit breaker стоит настраивать так, чтобы «выбивались» только реальные проблемные pod, а не временные пики.