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

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

Обратитесь к официальной документации 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'ов сервиса до тех пор, пока проба не пройдет успешно.
• 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 probes или очень маленькое значение
            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>.

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

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

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

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

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

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

#Проблемы с сетью

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