Health-пробы и жизненный цикл: liveness, readiness, startup и последовательность остановки без потерянных запросов

Три пробы — три разных вопроса

К концу урока вы будете точно знать, какой из трёх проб принадлежит какой вопрос — и почему путаница между ними превращает 28-секундный блип в 40-минутный инцидент при каждом повторении.

Liveness спрашивает: сломан ли процесс без шанса на самопочинку — дедлок, клин, порча состояния? Провал означает рестарт контейнера кубелетом, поэтому хендлер обязан проверять только то, что рестарт чинит: цикл обработки отвечает — и всё. Зависимости он не проверяет никогда: рестарт не чинит базу — он лишь конвертирует любой сбой зависимости в шторм рестартов на весь флот, ровно как в крючке. Readiness спрашивает: слать ли этому поду трафик прямо сейчас? Провал убирает под из эндпоинтов сервиса — обратимо, дёшево и ровно то, что нужно при сбое зависимости, перегрузке или дрейне. Вот где живут проверки зависимостей. Startup спрашивает: закончилась ли загрузка? Пока она не пройдена, liveness и readiness приостановлены — бюджет на миграции и прогрев кэшей равен failureThreshold, умноженному на periodSeconds, а без неё liveness убивает медленный старт на своём пороге и зацикливается навсегда.

livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3        # 30 с настоящего клина до рестарта
readinessProbe:
  httpGet: { path: /readyz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 2        # вывод из ротации за ~10 с
startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 36       # до 180 с на загрузку, прежде чем взведётся liveness

Настоящий readiness на Go

Readiness-хендлер, безусловно возвращающий 200, — это театр: он сообщает Kubernetes, что под готов обслуживать, когда сам под не знает ничего. Настоящий readiness проверяет то, без чего сервис не обслужит ни один запрос, с таймаутом, и несёт флаг дрейна:

var ready atomic.Bool // станет true после завершения загрузки

mux.HandleFunc("GET /healthz", func(w http.ResponseWriter, r *http.Request) {
	w.WriteHeader(http.StatusOK) // liveness: процесс жив — и ничего больше
})

mux.HandleFunc("GET /readyz", func(w http.ResponseWriter, r *http.Request) {
	if !ready.Load() {
		http.Error(w, "draining", http.StatusServiceUnavailable)
		return
	}
	ctx, cancel := context.WithTimeout(r.Context(), 1*time.Second)
	defer cancel()
	if err := db.PingContext(ctx); err != nil { // зависимость, нужная каждому запросу
		http.Error(w, "db unreachable", http.StatusServiceUnavailable)
		return
	}
	w.WriteHeader(http.StatusOK)
})

Дисциплина режет в обе стороны: сюда входят только жёсткие зависимости — те, без которых падает каждый запрос. Вписать в readiness необязательный кэш или некритичный даунстрим — значит позволить одному мигающему сайдкару вывести весь флот из ротации; необязательные зависимости деградируют ответы, а не «разготавливают» поды. И держите таксономию эндпоинтов в порядке: /healthz тривиален и существует для кубелета, /readyz проверяет зависимости и ворота трафика, /debug/pprof — для инженеров и никогда не публичен: импорт net/http/pprof побочным эффектом регистрирует хендлеры на DefaultServeMux — так профайлеры и оказываются торчащими в интернет; отдавайте его на отдельном localhost- или внутрикластерном листенере.

Последовательность остановки и бюджет грейса

Завершение — это распределённое рукопожатие, и пробы — его половина. На SIGTERM удаление из эндпоинтов распространяется асинхронно — балансировщики шлют новые запросы ещё несколько секунд. Сервер, мгновенно перестающий принимать соединения, отдаёт connection refused живому трафику на каждом деплое. Правильный порядок: сначала провалить readiness, переждать распространение, затем дрейнить — прямая спираль в урок graceful shutdown из go/03, теперь с кластерной хореографией:

<-ctx.Done()                 // SIGTERM от кубелета
ready.Store(false)           // 1. /readyz теперь 503 — началось удаление из эндпоинтов
time.Sleep(5 * time.Second)  // 2. поглощаем лаг распространения
shutdownCtx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
defer cancel()
_ = srv.Shutdown(shutdownCtx) // 3. дрейним запросы в полёте

Арифметика не обсуждается: terminationGracePeriodSeconds (по умолчанию 30) должен покрыть сон на распространение плюс дедлайн дрейна плюс запас — по его истечении SIGKILL приходит безусловно и забирает недоделанный дрейн с собой. Пять плюс двадцать оставляют пять секунд запаса внутри дефолта — а если ваш самый медленный легитимный запрос идёт 25 секунд, дефолтный бюджет уже сломан: поднимайте грейс до 40, а не сбривайте сон. Тайминг проб входит в ту же арифметику с другой стороны: readiness переключается за failureThreshold, умноженный на periodSeconds, то есть при 2 x 5 с балансировщик в худшем случае начнёт убирать вас секунд через десять после флипа — сон покрывает лаг от контроллера до дата-плейна, каденс пробы покрывает обнаружение.