Какие типы probe (проб) вы знаете в Kubernetes и для чего они используются?

Question

Какие типы probe (проб) вы знаете в Kubernetes и для чего они используются?

Тип вопроса: Kubernetes Вероятность: 24% Категория: Devops Инженер

Ответ

В Kubernetes пробы — это механизм проверки состояния контейнера. Я настраиваю их для всех production-ворклодов, чтобы обеспечить отказоустойчивость и нулевое время простоя.

Три основных типа probe:

Liveness Probe (Проба жизнеспособности)
- Назначение: Определяет, жив ли контейнер. Если проба fails, kubelet убивает контейнер и перезапускает его согласно политике restartPolicy.
- Использование: Для восстановления "зависших" приложений, которые не отвечают, но процесс еще работает.
```
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 30  # Даем приложению время на старт
periodSeconds: 10        # Проверяем каждые 10 секунд
failureThreshold: 3      # После 3 неудач контейнер будет перезапущен
```
Readiness Probe (Проба готовности)
- Назначение: Определяет, готов ли контейнер принимать трафик. При fail'е контейнер удаляется из эндпоинтов Service.
- Использование: Для ситуаций, когда приложение временно не может обслуживать запросы (загрузка кэша, подключение к БД).
```
readinessProbe:
exec:
command:
  - /app/check-ready.sh  # Кастомный скрипт проверки зависимостей
initialDelaySeconds: 5
periodSeconds: 5
```
Startup Probe (Проба старта)
- Назначение: Для медленно стартующих приложений. Пока startup probe не станет successful, liveness и readiness пробы не активируются.
- Использование: Защищает приложения с долгим временем инициализации от преждевременных перезапусков.
```
startupProbe:
httpGet:
path: /health/startup
port: 8080
failureThreshold: 30  # Пробуем много раз
periodSeconds: 10     # с большим интервалом
```

Ключевой момент: Правильная настройка initialDelaySeconds, timeoutSeconds и failureThreshold критически важна, чтобы пробы не мешали нормальной работе приложения.

Ответ 18+ 🔞

А, пробы в кубере! Ну это, блядь, как с машиной старой — если не ткнуть в неё палкой, не поймёшь, живая она ещё или уже накрылась медным тазом. Так и контейнеры: вроде процесс висит, а по факту — сосалка, а не сервис.

В общем, есть три главных способа тыкать палкой в своё приложение, чтобы понять, что с ним.

1. Liveness Probe (Проба "Ты ещё живой, блядь?") Вот смотри. Контейнер запустился, и вроде бы всё ок. А потом он взял и повис, потому что где-то там внутри deadlock или память кончилась. Процесс-то есть, а толку — ноль. Вот для этого и нужна liveness-проба. Если она трижды поймёт, что приложение не дышит, кублет его прибьёт и перезапустит. По сути, автоматический пинок под жопу. Без неё — сиди и гадай, почему сервис не отвечает, а он просто в отрубе.

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 30  # Даём время, чтобы приложение откашлялось и встало
  periodSeconds: 10        # Тыкаем палкой каждые 10 секунд
  failureThreshold: 3      # Три раза не ответил — всё, пидарас шерстяной, на перезапуск

2. Readiness Probe (Проба "А ты уже готов работать, или мне подождать?") А это уже хитрая жопа. Представь: контейнер запустился, но он ещё не готов. Кэш грузит, к базе подключается, конфиги читает. В этот момент слать ему трафик — это как волку в пасть совать. Он его просто сожрёт и подавится. Readiness-проба как раз и говорит куберу: "Не-не-не, чувак, пока не готов, не пускай ко мне клиентов". И кубер убирает поду из-под балансировщика, пока та не скажет "ок". Крайне важная штука для плавных деплоев, чтобы не было проседаний.

readinessProbe:
  exec:
    command:
      - /app/check-ready.sh  # Твой кастомный скрипт, который проверит, всё ли на месте
  initialDelaySeconds: 5
  periodSeconds: 5

3. Startup Probe (Проба "Давай, блядь, не тормози, мы тебя ждём!") Ну а это для тех, у кого приложение стартует овердохуища долго. Java-монстрики всякие, которые минуту думают, прежде чем сказать "привет". Если на такое чудовище навесить обычную liveness-пробу, она через 30 секунд решит, что всё, коньки отбросил, и начнёт его убивать. А оно ещё даже не родилось! Startup-проба решает эту проблему. Пока приложение не скажет "я запустился", все остальные пробы молчат и не достают. Даёшь ему время на раскачку.

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30  # Много попыток даём, терпения ебать
  periodSeconds: 10     # И не часто дёргаем

Главное, что надо уяснить, ёпта: Тайминги — это всё. Если поставить initialDelaySeconds: 2, а приложение грузится 20 секунд, то ты сам себе злой буратино. Проба начнёт дёргать недоработавшее приложение, получит fail, и понеслась: перезапуски, волнение ебать, а виноват ты сам, распиздяй. Выставляй значения с запасом, смотри логи и не делай пробы слишком агрессивными, а то замучаешься гадать, чего это поды мечутся как угорелые.