Зонд живучести, Зонд готовности не вызывается в ожидаемый срок

Question

Зонд живучести, Зонд готовности не вызывается в ожидаемый срок

В GKE я попытался использовать зонд готовности / зонд живучести и опубликовать оповещение с помощью мониторинга https://cloud.google.com/monitoring/alerts/using-alerting-ui

в качестве теста я создаю контейнер с тестом готовности / живучести. Как я и ожидал, проверка датчика каждый раз терпела неудачу.

      apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 0
      periodSeconds: 10      
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 20
      periodSeconds: 60
      timeoutSeconds: 30      
      successThreshold: 1
      failureThreshold: 3

И, проверив журнал GCP, оба журнала ошибок сначала появились на основе периода в секундах.

Зонд готовности: каждые 10 секунд

2021-02-21 13:26:30.000 Ошибка проверки готовности JST: ошибка проверки HTTP с кодом состояния: 500

2021-02-21 13:26:40.000 Ошибка проверки готовности JST: сбой проверки HTTP с кодом состояния: 500

Зонд живучести: каждые 1 минуту

2021-02-21 13:25:40.000 Ошибка проверки работоспособности JST: ошибка проверки HTTP с кодом состояния: 500

2021-02-21 13:26:40.000 Ошибка проверки работоспособности JST: ошибка проверки HTTP с кодом состояния: 500

Но после запуска этого модуля несколько минут

Проверка живучести больше не вызывалась
Вызывается проверка готовности, но интервал становится длинным (максимальный интервал составляет около 10 минут)

      $ kubectl get event
LAST SEEN   TYPE      REASON      OBJECT              MESSAGE
30m         Normal    Pulling     pod/liveness-http   Pulling image "k8s.gcr.io/liveness"
25m         Warning   Unhealthy   pod/liveness-http   Readiness probe failed: HTTP probe failed with statuscode: 500
20m         Warning   BackOff     pod/liveness-http   Back-off restarting failed container
20m         Normal    Scheduled   pod/liveness-http   Successfully assigned default/liveness-http to gke-cluster-default-pool-8bc9c75c-rfgc
17m         Normal    Pulling     pod/liveness-http   Pulling image "k8s.gcr.io/liveness"
17m         Normal    Pulled      pod/liveness-http   Successfully pulled image "k8s.gcr.io/liveness"
17m         Normal    Created     pod/liveness-http   Created container liveness
20m         Normal    Started     pod/liveness-http   Started container liveness
4m59s       Warning   Unhealthy   pod/liveness-http   Readiness probe failed: HTTP probe failed with statuscode: 500
17m         Warning   Unhealthy   pod/liveness-http   Liveness probe failed: HTTP probe failed with statuscode: 500
17m         Normal    Killing     pod/liveness-http   Container liveness failed liveness probe, will be restarted

В моем плане я бы создал политику предупреждений, состояние которой похоже на

если ошибка датчика живучести происходит 3 раза за 3 минуты

но если зондирование не вызвало, как я ожидал, эта политика не сработала; даже если модуль не запущен, предупреждение стало исправлено

Почему не запускалась проверка живучести, а интервал проверки готовности изменился?

Примечание: если есть другая хорошая политика предупреждений для проверки работоспособности модуля, меня бы не волновало такое поведение. Я признателен, если кто-нибудь посоветует мне, какая политика предупреждений идеально подходит для проверки модуля.

2

google-kubernetes-engine google-cloud-monitoring readinessprobe livenessprobe

Источник

user9223835 21 фев '21 в 08:38

1 ответ

Другие вопросы по тегам google-kubernetes-engine google-cloud-monitoring readinessprobe livenessprobe

user11148139 09 мар '21 в 17:47 2021-03-09 17:47 · Answer 1 · 2021-03-09 17:47

Фон

В документации Configure Liveness, Readiness и Startup Probes вы можете найти информацию:

Кублет использует, чтобы знать, когда перезапустить контейнер. Например, проверки работоспособности могут обнаружить взаимоблокировку, когда приложение работает, но не может двигаться вперед. Перезапуск контейнера в таком состоянии может помочь сделать приложение более доступным, несмотря на ошибки.

Кублет использует readiness probesчтобы узнать, когда контейнер готов начать принимать трафик. Pod считается готовым, когда готовы все его контейнеры. Одно из применений этого сигнала — контролировать, какие поды используются в качестве серверных частей для сервисов. Когда под не готов, он удаляется из балансировщиков нагрузки службы.

Поскольку master управляется Google, вы не найдете kubeletжурналы с использованием CLI(вы можете попробовать использовать Stackdriver). Я протестировал его на кластере и установил verbosityуровень до 8.

При использовании вы получаете события только за последний час (это можно изменить в настройках Kubernetes — Kubeadmно я не думаю, что его можно изменить, так как мастер управляется Google.)

      $ kubectl get events
LAST SEEN   TYPE      REASON                    OBJECT              MESSAGE
37m         Normal    Starting                  node/kubeadm        Starting kubelet.
...
33m         Normal    Scheduled                 pod/liveness-http   Successfully assigned default/liveness-http to kubeadm
33m         Normal    Pulling                   pod/liveness-http   Pulling image "k8s.gcr.io/liveness"
33m         Normal    Pulled                    pod/liveness-http   Successfully pulled image "k8s.gcr.io/liveness" in 893.953679ms
33m         Normal    Created                   pod/liveness-http   Created container liveness
33m         Normal    Started                   pod/liveness-http   Started container liveness
3m12s       Warning   Unhealthy                 pod/liveness-http   Readiness probe failed: HTTP probe failed with statuscode: 500
30m         Warning   Unhealthy                 pod/liveness-http   Liveness probe failed: HTTP probe failed with statuscode: 500
8m17s       Warning   BackOff                   pod/liveness-http   Back-off restarting failed container

Снова та же команда после ~1 hour.

      $ kubectl get events
LAST SEEN   TYPE      REASON      OBJECT              MESSAGE
33s         Normal    Pulling     pod/liveness-http   Pulling image "k8s.gcr.io/liveness"
5m40s       Warning   Unhealthy   pod/liveness-http   Readiness probe failed: HTTP probe failed with statuscode: 500
15m         Warning   BackOff     pod/liveness-http   Back-off restarting failed container

Тесты

Проверка выполняется каждые 10 секунд в течение более одного часа.

      Mar 09 14:48:34 kubeadm kubelet[3855]: I0309 14:48:34.222085    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 14:48:44 kubeadm kubelet[3855]: I0309 14:48:44.221782    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 14:48:54 kubeadm kubelet[3855]: I0309 14:48:54.221828    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
...
Mar 09 15:01:34 kubeadm kubelet[3855]: I0309 15:01:34.222491    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4
562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 15:01:44 kubeadm kubelet[3855]: I0309 15:01:44.221877    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 15:01:54 kubeadm kubelet[3855]: I0309 15:01:54.221976    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
...
Mar 09 15:10:14 kubeadm kubelet[3855]: I0309 15:10:14.222163    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 15:10:24 kubeadm kubelet[3855]: I0309 15:10:24.221744    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 15:10:34 kubeadm kubelet[3855]: I0309 15:10:34.223877    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
...
Mar 09 16:04:14 kubeadm kubelet[3855]: I0309 16:04:14.222853    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 16:04:24 kubeadm kubelet[3855]: I0309 16:04:24.222531    3855 prober.go:117] Readiness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500

Кроме того, есть Liveness probeзаписи.

      Mar 09 16:12:58 kubeadm kubelet[3855]: I0309 16:12:58.462878    3855 prober.go:117] Liveness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 16:13:58 kubeadm kubelet[3855]: I0309 16:13:58.462906    3855 prober.go:117] Liveness probe for "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a):liveness" failed (failure): HTTP probe failed with statuscode: 500
Mar 09 16:14:58 kubeadm kubelet[3855]: I0309 16:14:58.465470    3855 kuberuntime_manager.go:656] Container "liveness" ({"docker" "95567f85708ffac8b34b6c6f2bdb4
9d8eb57e7704b7b416083c7f296dd40cd0b"}) of pod liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a): Container liveness failed liveness probe, will be restarted
Mar 09 16:14:58 kubeadm kubelet[3855]: I0309 16:14:58.465587    3855 kuberuntime_manager.go:712] Killing unwanted container "liveness"(id={"docker" "95567f85708ffac8b34b6c6f2bdb49d8eb57e7704b7b416083c7f296dd40cd0b"}) for pod "liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a)"

Общее время испытаний:

      $ kubectl get po -w
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   0/1     Running   21         99m
liveness-http   0/1     CrashLoopBackOff   21         101m
liveness-http   0/1     Running            22         106m
liveness-http   1/1     Running            22         106m
liveness-http   0/1     Running            22         106m
liveness-http   0/1     Running            23         109m
liveness-http   1/1     Running            23         109m
liveness-http   0/1     Running            23         109m
liveness-http   0/1     CrashLoopBackOff   23         112m
liveness-http   0/1     Running            24         117m
liveness-http   1/1     Running            24         117m
liveness-http   0/1     Running            24         117m

Вывод

Проверка Liveness probe больше не вызывалась

Liveness checkсоздается, когда Kubernetes создает pod, и воссоздается каждый раз, когда Podперезапускается. В вашей конфигурации вы установили initialDelaySeconds: 20поэтому после создания Kubernetes будет ждать 20 секунд, а затем вызовет livenessзонд 3 раза (как вы установили failureThreshold: 3). После сбоя 3 Kubernetes перезапустит этот модуль в соответствии с RestartPolicy. Также в логах вы сможете найти в логах:

      Mar 09 16:14:58 kubeadm kubelet[3855]: I0309 16:14:58.465470    3855 kuberuntime_manager.go:656] Container "liveness" ({"docker" "95567f85708ffac8b34b6c6f2bdb4
9d8eb57e7704b7b416083c7f296dd40cd0b"}) of pod liveness-http_default(8c87a08e-34aa-4bb1-be9b-fdca39a4562a): Container liveness failed liveness probe, will be restarted

Почему он будет перезапущен? Ответ можно найти в Container probes .

livenessProbe:Указывает, запущен ли контейнер. Если проверка живучести дает сбой, kubelet убивает контейнер, и на контейнер распространяется его политика перезапуска.

Политика перезапуска по умолчанию в GKEявляется Always. Таким образом, ваш модуль будет перезапускаться снова и снова.

Проверка зонда готовности вызвана, но интервал стал длинным (максимальный интервал составляет около 10 минут)

Я думаю, что вы пришли к такому выводу, поскольку основывались на $ kubectl get eventsа также $ kubectl describe po. В обоих случаях события по умолчанию удаляются через 1 час. В моей части вы можете видеть, что записи из 14:48:34пока 16:04:24, поэтому каждые 10 секунд Kubernetes вызывает Readiness Probe.

Почему не запустилась проверка Liveness, а интервал проверки готовности изменился?

Как я показываю вам в Testsчасть, Readiness probeне изменился. Вводящим в заблуждение в данном случае было использование $ kubectl events. Касательно Liveiness Probeон все еще звонит, но только 3 раза после того, как pod будет created/ restarted. Также я включил вывод $ kubectl get po -w. Когда podвоссоздан, вы можете найти в журналах kubelet те liveness probes.

В моем плане я бы создал политику предупреждений, условие которой выглядит следующим образом:

если ошибка проверки живучести происходит 3 раза за 3 минуты

Если liveness probeтерпит неудачу 3 раза, с вашими текущими настройками он перезапустит этот модуль. В этой ситуации вы можете использовать каждый restartсоздать alert.

      Metric: kubernetes.io/container/restart_count
Resource type: k8s_container

Некоторая полезная информация, которую вы можете найти в кейсах Stackoverflow, касающихся Monitoring alertкак: