Liveness Probe，Readiness Probe 未在预期持续时间内调用答案

【问题标题】：Liveness Probe, Readiness Probe not called in expected durationLiveness Probe，Readiness Probe 未在预期持续时间内调用
【发布时间】：2021-05-23 17:42:26
【问题描述】：

在 GKE 上，我尝试使用 readiness probe/ liveness probe ，并使用监控 https://cloud.google.com/monitoring/alerts/using-alerting-ui 发布警报

作为测试，我创建了一个具有就绪探针/活性探针的 pod。正如我所料，探针检查每次都失败。

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 日志，两个错误日志都首先基于 periodSeconds 显示。

就绪探测：每 10 秒

2021-02-21 13:26:30.000 日本标准时间就绪探测失败：HTTP 探测失败，状态码：500

2021-02-21 13:26:40.000 日本标准时间就绪探测失败：HTTP 探测失败，状态码：500

活性探测：每 1 分钟一次

2021-02-21 13:25:40.000 日本标准时间活动探测失败：HTTP 探测失败，状态码：500

2021-02-21 13:26:40.000 日本标准时间活动探测失败：HTTP 探测失败，状态码：500

但是，在运行这个 pod 几分钟后

不再调用 Liveness 探测检查
已调用就绪探测检查，但间隔变长（最大间隔大约为 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 次

但是如果探测检查没有像我预期的那样调用，那么这些策略就不起作用；即使 pod 没有运行，警报也已修复

为什么 Liveness 探测没有运行，而 Readiness 探测的间隔改变了？

注意：如果有其他好的警报策略来检查 pod 的活跃度，我不会在意这种行为。如果有人能建议我哪种警报策略最适合检查 pod，我将不胜感激。

【问题讨论】：

您使用的是什么 GKE 版本？您能否告知您制定的具体政策是什么？
@PjoterS 集群版本为 1.18.12-gke.1210 。指标是 jsonPayload.reason="Unhealthy" AND resource.type="k8s_pod" AND severity="WARNING" 。 警报政策是trigger:1 alignment_period:600s，带有指标

标签： google-kubernetes-engine google-cloud-monitoring readinessprobe livenessprobe

【解决方案1】：

背景

在Configure Liveness, Readiness and Startup Probes 文档中您可以找到信息：

kubelet 使用liveness probes 知道何时重启容器。例如，活跃度探针可以捕获死锁，即应用程序正在运行，但无法取得进展。在这种状态下重新启动容器有助于使应用程序更加可用，尽管存在错误。

kubelet 使用readiness probes 知道容器何时准备好开始接受流量。当 Pod 的所有容器都准备好时，就认为 Pod 准备好了。此信号的一种用途是控制哪些 Pod 用作服务的后端。当 Pod 未准备好时，它会从服务负载均衡器中移除。

由于GKE master 由google 管理，使用CLI 将找不到kubelet 日志（您可以尝试使用Stackdriver）。我已经在Kubeadm 集群上对其进行了测试，并将verbosity 级别设置为8。

当您使用 $ kubectl get events 时，您只能从最后一小时获得事件（它可以在 Kubernetes 设置中更改 - Kubeadm 但我认为它不能在 GKE 中更改，因为 master 由谷歌。）

$ 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

测试

Readiness Probe 检查每 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 check 不再调用

Liveness check 在 Kubernetes 创建 pod 时创建，并在每次重启 Pod 时重新创建。在您的配置中，您设置了initialDelaySeconds: 20，因此在创建pod 后，Kubernetes 将等待20 秒，然后它将调用liveness 探测3 次（正如您设置的failureThreshold: 3）。 3次失败后，Kubernetes会根据RestartPolicy重启这个pod。同样在日志中，您将能够在日志中找到：

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: 表示容器是否正在运行。如果 liveness probe 失败，kubelet 会杀死容器，并且容器会受到其重启策略的约束。

GKE 中的默认 Restart Policy 是 Always。因此，您的 pod 将一遍又一遍地重新启动。

已调用就绪探测检查，但间隔变长（最大间隔大约为 10 分钟）

我认为您已经根据$ kubectl get events 和$ kubectl describe po 得出了这个结论。在这两种情况下，默认事件都会在 1 小时后删除。在我的Tests 部分中，您可以看到Readiness probe 条目从14:48:34 到16:04:24，因此Kubernetes 每10 秒调用一次Readiness Probe。

为什么 Liveness 探测没有运行，而 Readiness 探测的间隔发生了变化？

正如我在 Tests 部分中向您展示的那样，Readiness probe 没有改变。在这种情况下误导使用$ kubectl events。关于Liveiness Probe，它仍在调用，但在 pod 之后只有 3 次为created/restarted。我还包括了$ kubectl get po -w 的输出。当 pod 重新创建时，您可能会在 kubelet 日志中找到那些 liveness probes。

在我的计划中，我将创建警报策略，其条件如下：

如果活性探测错误在 3 分钟内发生 3 次

如果 liveness probe 失败 3 次，使用您当前的设置，它将重新启动此 pod。在这种情况下，您可以使用每个restart 创建一个alert。

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

您可以在 Stackoverflow 案例中找到有关 Monitoring alert 的一些有用信息，例如：

【讨论】：