В чем разница между livenessProbe и readinessProbe?

livenessProbe vs readinessProbe в Kubernetes

Это две разные проверки здоровья в Kubernetes которые решают разные проблемы. Правильное их использование критично для надёжности приложений.

Быстрое сравнение

livenessProbe:
- Проверяет: жив ли контейнер?
- Действие при failure: RESTART контейнер
- Использование: обнаружить deadlock'и и зависания

readinessProbe:
- Проверяет: готов ли приложение принимать трафик?
- Действие при failure: REMOVE из Service (не restart)
- Использование: graceful startup/shutdown

livenessProbe - "жив ли процесс?"

Назначение: Обнаружить если контейнер зависла или находится в deadlock состоянии.

Действие при failure:

• Kubernetes ПЕРЕЗАГРУЖАЕТ контейнер
• Убивает (SIGKILL) и создаёт новый

Примеры:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    
    # HTTP check
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30  # Wait 30s before first check
      periodSeconds: 10         # Check every 10s
      timeoutSeconds: 5         # Timeout for check
      failureThreshold: 3       # Restart after 3 failures
    
    # TCP check (для приложений без HTTP)
    # livenessProbe:
    #   tcpSocket:
    #     port: 5432
    #   initialDelaySeconds: 30
    #   periodSeconds: 10
    
    # Exec check (запустить команду)
    # livenessProbe:
    #   exec:
    #     command:
    #     - /bin/sh
    #     - -c
    #     - ps aux | grep java
    #   initialDelaySeconds: 30
    #   periodSeconds: 10

Логика:

Проверка каждые 10 секунд
  ✓ Success → OK, продолжаем
  ✗ Failure → счётчик += 1
  
После 3 failures подряд:
  → Контейнер RESTART'ится
  → Новый контейнер создаётся

readinessProbe - "готово ли к трафику?"

Назначение: Определить когда приложение готово принимать requests.

Действие при failure:

• Kubernetes УДАЛЯЕТ pod из Service endpoints
• Трафик перестаёт идти на этот pod
• Pod НЕ перезагружается (процесс живой, просто не готов)

Примеры:

apiVersion: v1
kind: Pod
metadata:
  name: readiness-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    
    # HTTP check
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 10   # Быстрее чем liveness
      periodSeconds: 5          # Часто проверяем
      timeoutSeconds: 2
      failureThreshold: 1       # Одна failure = remove из Service
    
    # Exec check (проверка БД)
    # readinessProbe:
    #   exec:
    #     command:
    #     - /bin/sh
    #     - -c
    #     - curl -f http://localhost:5432/health || exit 1
    #   initialDelaySeconds: 5
    #   periodSeconds: 5

Логика:

Проверка каждые 5 секунд
  ✓ Ready → добавляем в Service endpoints (трафик идёт)
  ✗ NotReady → удаляем из endpoints (трафик НЕ идёт)
  
Процесс продолжает работать, но изолирован от трафика

Практическое объяснение

Сценарий 1: Startup

Под создан (startup phase)
  ↓
Приложение инициализируется
  - Загружает конфигурацию
  - Подключается к БД
  - Прогревает кеш
  ↓
readinessProbe = FAIL → Pod удалён из Service
  (Ещё не готов к трафику)
  ↓
После загрузки
readinessProbe = OK → Pod добавлен в Service
  (Может принимать трафик)

Сценарий 2: Runtime проблема

Приложение работает нормально
  ↓
Вдруг БД стала недоступна
  ↓
readinessProbe = FAIL
  Pod удалён из Service
  Другие pods обрабатывают трафик
  ↓
При этом livenessProbe = OK
  (Процесс жив, просто не готов)
  ↓
Когда БД восстановится
readinessProbe = OK
  Pod добавлен обратно в Service

Сценарий 3: Deadlock

Приложение входит в deadlock
  ↓
livenessProbe = FAIL
  (Не может ответить)
  ↓
Кубернетес ПЕРЕЗАГРУЖАЕТ контейнер
  ↓
Процесс убит, новый создан
  → Самовосстанавливаемость

Полный пример

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: app
        image: myapp:1.0
        ports:
        - containerPort: 8080
        
        # Startup probe (K8s 1.18+)
        # Позволяет достаточно времени на startup
        startupProbe:
          httpGet:
            path: /health
            port: 8080
          failureThreshold: 30
          periodSeconds: 10  # 30 * 10 = 300s max для startup
        
        # Readiness: когда готов к трафику
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 1
        
        # Liveness: жив ли процесс
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3

Best Practices

1. Разные endpoints для readiness и liveness

# Python Flask приложение
from flask import Flask
from database import db

app = Flask(__name__)

@app.route('/health')
def health():
    # Liveness: просто проверяем что процесс работает
    return {'status': 'alive'}, 200

@app.route('/ready')
def ready():
    # Readiness: проверяем зависимости (БД, кеш, и т.д.)
    try:
        db.check_connection()
        cache.ping()
        return {'status': 'ready'}, 200
    except Exception as e:
        return {'status': 'not ready', 'reason': str(e)}, 503

2. Правильные timings

startupProbe:           # Если дольше стартует
  failureThreshold: 30  # 30 * periodSeconds
  periodSeconds: 10

readinessProbe:         # Чувствителен к изменениям
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 1   # Быстро удаляем

livenessProbe:          # Консервативнее
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3   # Даём несколько попыток

3. Избегать слишком жёстких проверок

# Плохо - слишком частая проверка
readinessProbe:
  periodSeconds: 1  # Слишком нагружает
  
# Хорошо
readinessProbe:
  periodSeconds: 5-10

Диагностика

# Посмотреть статус probes
kubectl describe pod <pod-name>

# Пример вывода
Liveness probe failed: HTTP probe failed with statuscode: 500
Readiness probe failed: HTTP probe failed with statuscode: 503
Last Probe Time:   Mon, 26 Nov 2024 10:15:30 +0000
Last Transition Time: Mon, 26 Nov 2024 10:15:00 +0000
Status: True
Type: Ready

# Логи контейнера
kubectl logs <pod-name>
kubectl logs <pod-name> -f  # Follow

# События
kubectl events --field-selector involvedObject.name=<pod-name>

Выводы

livenessProbe:

• Жизнь процесса
• RESTART при failure
• Для обнаружения deadlock'ов
• Консервативнее (failureThreshold=3)

readinessProbe:

• Готовность к трафику
• REMOVE из Service при failure
• Для graceful startup/shutdown
• Более чувствительный (failureThreshold=1)

Правило: используй обе в production!

• readinessProbe для smooth traffic management
• livenessProbe для self-healing
• startupProbe для медленного startup