Как readiness probe, liveness probe и PodDisruptionBudget влияют на достижение SLO сервиса, и как обсуждать эти настройки в терминах error budget?

Короткий ответ

Единого "правильного" порога probe и PDB не существует — их нужно настраивать исходя из конкретного SLO сервиса (например, допустимой доли ошибок за период) и бюджета ошибок: слишком агрессивные probe увеличивают число ложных исключений из трафика и расходуют error budget на ровном месте, а слишком мягкие probe/PDB позволяют реальным сбоям дольше оставаться незамеченными или допускают избыточные одновременные добровольные нарушения доступности.

Как это работает подробнее

каждое срабатывание readiness-провала временно убирает под из трафика, что при недостаточном числе оставшихся готовых реплик может повысить нагрузку на них и увеличить латентность или долю ошибок — то есть сами механизмы защиты (probe) при неверной настройке могут стать источником нарушения SLO, а не только средством его защиты. PodDisruptionBudget ограничивает, сколько реплик может быть недоступно одновременно из-за плановых операций (апгрейд узлов, автоскейлинг вниз), что напрямую связано с тем, сколько "бюджета" доступности команда готова потратить на плановое обслуживание в течение отчётного периода SLO.

• Компромисс. нет единого ответа, насколько строгим должен быть PDB или насколько агрессивны должны быть probe — это всегда результат переговоров между надёжностью (меньше риск простоя от плановых операций) и операционной гибкостью (возможность быстро проводить апгрейды и масштабирование); команда должна явно формализовать эти пороги в терминах SLO/error budget и пересматривать их по мере изменения критичности сервиса или истории инцидентов, а не оставлять как статичную "настройку по умолчанию".

Пример кода

manifest.yamlКопировать

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: checkout-pdb }
spec:
  maxUnavailable: 1
  selector: { matchLabels: { app: checkout } }

Что использовать на практике

• Практика. обсуждение этих настроек должно начинаться с вопроса "какой SLO у этого сервиса и сколько error budget уже израсходовано в этом периоде", а не с универсальных рекомендаций по таймаутам; например, сервис с SLO 99.9% и почти исчерпанным error budget за месяц должен консервативнее подходить к плановым операциям (более строгий PDB, перенос необязательных апгрейдов узлов на начало следующего периода), тогда как сервис с большим запасом бюджета может позволить себе более агрессивное плановое обслуживание. Также стоит учитывать, что SLO обычно измеряется с точки зрения клиента (доля успешных запросов, задержка), а probe и PDB — это внутренние механизмы Kubernetes, корреляция которых с клиентским опытом требует отдельной проверки (например, через синтетические проверки снаружи кластера).

Подводные камни

• Риски. частая ошибка — настраивать таймауты probe и maxUnavailable у PDB по универсальным "best practice" значениям без привязки к конкретному SLO сервиса; также кандидаты часто не замечают, что сами слишком агрессивные probe могут расходовать error budget, рассматривая их только как защитный механизм, а не как потенциальный источник нарушений.