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

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

Обратитесь к официальной документации 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 проб или очень маленькое значение
            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 могут препятствовать достижению проб контейнера. Проверьте сетевое соединение внутри кластера.