Если ваши поды «умирают» слишком рано или слишком долго не проходят readiness, возможно, вы не до конца понимаете, как работают пробы в Kubernetes. А между тем, это критично для uptime и стабильности продакшена.
📌 Пробы - не «просто пинги»
-
livenessProbe отвечает за "жив ли под". Если не проходит - kubelet убивает контейнер.-
readinessProbe - "готов ли под принимать трафик". Пока не готов - не пускается в сервис.Неправильная настройка может привести к:
- бесконечным перезапускам (flapping),
- недоступности сервиса после деплоя,
- ненужной нагрузке на кластер.
🛠 Типичные ошибки
1. Тот же эндпоинт для обеих проб
Readiness может требовать больше инициализации. Разделяйте эндпоинты:
/healthz/live и /healthz/ready - хорошая практика.2. Слишком агрессивные тайминги
initialDelaySeconds, timeoutSeconds, failureThreshold - не забывайте учитывать холодный старт (особенно при Java, .NET, DB init).3. Тестирование только на dev/stage
На проде нагрузка выше, сеть может вести себя иначе. Профиль подов должен учитывать real-world сценарии.
4. Liveness вместо retries
Liveness не замена retry-логике в приложении. Используйте circuit breakers, retries и grace periods на уровне сервиса.
✅ Как делать правильно
- Используйте простые GET-запросы, без heavy логики.
- Не тестируйте зависимости (БД, внешние API) в liveness - пусть это останется за readiness.
- Применяйте
terminationGracePeriodSeconds и preStop hook, чтобы избежать резкого отключения.🧩 Стартовый шаблон для readiness/liveness
livenessProbe:
httpGet:
path: /healthz/live
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
readinessProbe:
httpGet:
path: /healthz/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
Вывод: Настройка prob - это не ритуал ради YAML-а. Это инструмент стабильности и доступности. Подходите к ним осознанно, валидируйте на нагрузке и помните, что "здоровый" под ≠ "готовый к трафику".
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps