#Проверки состояния

#Понимание проверок состояния

Обратитесь к официальной документации Kubernetes:

• Liveness, Readiness, and Startup Probes
• Configure Liveness, Readiness and Startup Probes

В Kubernetes проверки состояния, также известные как пробы, являются критическим механизмом для обеспечения высокой доступности и устойчивости ваших приложений. Kubernetes использует эти пробы для определения состояния здоровья и готовности ваших Pod'ов, что позволяет системе предпринимать соответствующие действия, такие как перезапуск контейнеров или маршрутизация трафика. Без правильных проверок состояния Kubernetes не сможет надежно управлять жизненным циклом вашего приложения, что может привести к ухудшению качества сервиса или сбоям.

Kubernetes предлагает три типа проб:

• livenessProbe: Определяет, запущен ли контейнер. Если liveness probe не проходит, Kubernetes завершит Pod и перезапустит его согласно политике перезапуска.
• readinessProbe: Определяет, готов ли контейнер обслуживать трафик. Если readiness probe не проходит, Endpoint Controller удалит Pod из списка Endpoint'ов Service до тех пор, пока проба не станет успешной.
• startupProbe: Специально проверяет, успешно ли запустилось приложение. Liveness и readiness пробы не будут выполняться, пока startup probe не пройдет успешно. Это очень полезно для приложений с длительным временем запуска.

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

#Типы проб

Kubernetes поддерживает три механизма реализации проб:

#HTTP GET действие

Выполняет HTTP-запрос GET к IP-адресу Pod'а на указанном порту и пути. Проба считается успешной, если код ответа находится в диапазоне от 200 до 399.

• Случаи использования: Веб-серверы, REST API или любое приложение, предоставляющее HTTP-эндпоинт.

• Пример:

  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 15
    periodSeconds: 20

#exec действие

Выполняет указанную команду внутри контейнера. Проба считается успешной, если команда завершается с кодом 0.

• Случаи использования: Приложения без HTTP-эндпоинтов, проверка внутреннего состояния приложения или выполнение сложных проверок, требующих специальных инструментов.

• Пример:

  readinessProbe:
    exec:
      command:
        - cat
        - /tmp/healthy
    initialDelaySeconds: 5
    periodSeconds: 5

#TCP Socket действие

Пытается открыть TCP-сокет на IP-адресе контейнера и указанном порту. Проба считается успешной, если TCP-соединение установлено.

• Случаи использования: Базы данных, очереди сообщений или любое приложение, которое общается по TCP-порту, но может не иметь HTTP-эндпоинта.

• Пример:

  startupProbe:
    tcpSocket:
      port: 3306
    initialDelaySeconds: 5
    periodSeconds: 10
    failureThreshold: 30

#Лучшие практики

• Liveness vs. Readiness:
  • Liveness: Если ваше приложение не отвечает, лучше перезапустить его. При сбое Kubernetes выполнит перезапуск.
  • Readiness: Если ваше приложение временно не может обслуживать трафик (например, подключается к базе данных), но может восстановиться без перезапуска, используйте Readiness Probe. Это предотвратит маршрутизацию трафика на нездоровый экземпляр.
• Startup Probes для медленных приложений: Используйте Startup Probes для приложений с длительным временем инициализации. Это предотвращает преждевременные перезапуски из-за сбоев Liveness Probe или проблемы с маршрутизацией трафика из-за сбоев Readiness Probe во время запуска.
• Легковесные пробы: Убедитесь, что ваши эндпоинты проб легковесны и выполняются быстро. Они не должны включать тяжелые вычисления или внешние зависимости (например, вызовы к базе данных), которые могут сделать пробу ненадежной.
• Содержательные проверки: Проверки должны действительно отражать состояние здоровья и готовности вашего приложения, а не просто факт работы процесса. Например, для веб-сервера проверяйте, может ли он обслуживать базовую страницу, а не просто открыт ли порт.
• Настройка initialDelaySeconds: Устанавливайте initialDelaySeconds так, чтобы дать приложению достаточно времени на запуск перед первой проверкой.
• Настройка periodSeconds и failureThreshold: Балансируйте необходимость быстрого обнаружения сбоев и избегайте ложных срабатываний. Слишком частые пробы или слишком низкий failureThreshold могут привести к ненужным перезапускам или состоянию «не готов».
• Логи для отладки: Обеспечьте, чтобы ваше приложение логировало понятные сообщения, связанные с вызовами эндпоинтов проверок и внутренним состоянием, для облегчения отладки сбоев проб.
• Комбинирование проб: Часто все три пробы (Liveness, Readiness, Startup) используются вместе для эффективного управления жизненным циклом приложения.

#Пример YAML файла

spec:
  template:
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2 # Container image
          ports:
            - containerPort: 80 # Container exposed port
          startupProbe:
            httpGet:
              path: /startup-check
              port: 8080
            initialDelaySeconds: 0 # Обычно 0 для startup probe или очень маленькое значение
            periodSeconds: 5
            failureThreshold: 60 # Позволяет 60 * 5 = 300 секунд (5 минут) на запуск
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5 # Задержка 5 секунд после старта Pod перед проверкой
            periodSeconds: 10 # Проверка каждые 10 секунд
            timeoutSeconds: 5 # Таймаут через 5 секунд
            failureThreshold: 3 # Считается нездоровым после 3 последовательных неудач
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3

#Параметры конфигурации проверок состояния через веб-консоль

#Общие параметры

#Параметры, специфичные для протокола

#Устранение неполадок с провалами проб

Если статус Pod указывает на проблемы, связанные с пробами, вот как их можно устранить:

#Проверьте события Pod

kubectl describe pod <pod-name>

Ищите события, связанные с LivenessProbe failed, ReadinessProbe failed или StartupProbe failed. Эти события часто содержат конкретные сообщения об ошибках (например, отказ соединения, HTTP 500, код выхода команды).

#Просмотрите логи контейнера

kubectl logs <pod-name> -c <container-name>

Изучите логи приложения, чтобы увидеть ошибки или предупреждения в момент сбоя пробы. Возможно, приложение логирует причины, по которым эндпоинт проверки не отвечает корректно.

#Проверьте эндпоинт пробы вручную

• HTTP: Если возможно, выполните kubectl exec -it <pod-name> -- curl <probe-path>:<probe-port> или wget внутри контейнера, чтобы увидеть реальный ответ.
• Exec: Запустите команду пробы вручную: kubectl exec -it <pod-name> -- <command-from-probe> и проверьте код выхода и вывод.
• TCP: Используйте nc (netcat) или telnet из другого Pod в той же сети или с хоста (если разрешено), чтобы проверить TCP-соединение: kubectl exec -it <another-pod> -- nc -vz <pod-ip> <probe-port>.

#Проверьте конфигурацию проб

• Тщательно проверьте параметры проб (путь, порт, команда, задержки, пороги) в вашем Deployment/Pod YAML. Частая ошибка — неверный порт или путь.

#Проверьте код приложения

• Убедитесь, что эндпоинт проверки состояния реализован корректно и действительно отражает готовность/работоспособность приложения. Иногда эндпоинт может возвращать успех, даже если приложение сломано.

#Ограничения ресурсов

• Недостаток CPU или памяти может привести к тому, что приложение перестанет отвечать, вызывая сбои проб. Проверьте использование ресурсов Pod (kubectl top pod <pod-name>) и рассмотрите возможность настройки лимитов/запросов ресурсов.

#Сетевые проблемы

• В редких случаях политики сети или проблемы с CNI могут препятствовать достижению проб до контейнера. Проверьте сетевое соединение внутри кластера.