Зонды Kubernetes должны быть специфичными: startup проверяет завершение инициализации, readiness оценивает, может ли экземпляр обрабатывать трафик, а liveness определяет, завис ли процесс. Зонды startup предоставляют дополнительное время для задач инициализации, таких как компиляция правил ценообразования, прежде чем другие зонды станут активными. Зонды readiness проверяют, может ли экземпляр обслуживать активное правило и необходимые состояния зависимостей, удаляя pod из конечных точек обслуживания в случае сбоя. Зонды liveness проверяют необратимые проблемы процесса, инициируя перезапуск контейнера при обнаружении проблемы. Такое разделение предотвращает ненужные перезапуски контейнеров из-за сбоев несвязанных зависимостей, что может усугубить проблемы. Для API управления недвижимостью readiness гарантирует, что экземпляр готов обслуживать конкретное правило ценообразования, защищая арендаторов от несогласованных расчетов. Зонды startup необходимы, когда инициализация занимает больше времени, чем бюджет liveness, предотвращая преждевременные проверки liveness или readiness. Зонды readiness выбираются для условий, которые останавливают новый трафик, но могут восстановиться без перезапуска, например, отсутствие снимка правил. Зонды liveness зарезервированы для проблем, которые может исправить перезапуск, таких как неотзывчивый цикл событий, и должны быть узконаправленными, чтобы избежать ненужных перезапусков. Конечные точки работоспособности должны использовать разные пути для каждого типа зонда, избегать сетевых вызовов в проверках liveness и возвращать минимальные коды состояния.