当 pod 包含多个容器时，K8s 的活性探测行为？

Question

场景：一个 K8S Pod 具有多个容器，并且为每个容器配置活性/就绪探针。现在，如果活性探测在某些容器上成功，但在少数容器上失败，k8s 会做什么。

1. 它会仅重新启动失败的容器
   还是
2. 它会重新启动整个 Pod 吗？

Answer 1

如果活性探针在某些容器上成功而在少数容器上失败，k8s 会做什么？

它将仅重新启动失败的容器。

在Pod Lifecycle - Container Probes中，您列出了所有 3 个探针：liviness、readiness和startup。

livenessProbe：表示是否container正在运行。如果活性探测失败，kubelet 将杀死该容器，并且该容器将受到其restart policy. 如果容器不提供活性探测，则默认状态为成功。

在配置活跃度、就绪性和启动探针 - 定义活跃度命令中，您有示例并提到：

如果命令成功，则返回 0，并且 kubelet 认为容器处于活动状态并且运行状况良好。如果该命令返回非零值，kubelet 将终止容器并重新启动它。

HTTP 请求活性探针的情况也是如此：

如果服务器的 /healthz 路径的处理程序返回成功代码，则 kubelet 认为容器处于活动状态并且运行状况良好。如果处理程序返回失败代码，kubelet 将终止容器并重新启动它。

并使用TCP 活跃度探测：

kubelet 将在容器启动后 15 秒运行第一个活性探测。就像就绪探针一样，这将尝试连接到端口 8080 上的 goproxy 容器。如果活动探针失败，容器将重新启动。

测试

如果您想创建自己的测试，可以使用以下 HTTP Liveness 探针示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http-probe
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: 5      
      timeoutSeconds: 5
      successThreshold: 1
      failureThreshold: 3
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 5
      periodSeconds: 10     
      successThreshold: 1
      failureThreshold: 3 
  - name: nginx
    image: nginx

一段时间后，您将能够看到 已container重新启动，restart count有所增加，但pod仍然存在，Age仍在计数。

$ kubectl get po -w
NAME                  READY   STATUS    RESTARTS   AGE
liveness-http-probe   2/2     Running   0          20s
liveness-http-probe   1/2     Running   0          23s
liveness-http-probe   1/2     Running   1          42s
liveness-http-probe   2/2     Running   1          43s
liveness-http-probe   1/2     Running   1          63s
...
liveness-http-probe   1/2     Running   5          3m23s
liveness-http-probe   2/2     Running   5          3m23s
liveness-http-probe   1/2     Running   5          3m43s
liveness-http-probe   1/2     CrashLoopBackOff   5          4m1s
liveness-http-probe   1/2     Running            6          5m25s
liveness-http-probe   2/2     Running            6          5m28s
liveness-http-probe   1/2     Running            6          5m48s
liveness-http-probe   1/2     CrashLoopBackOff   6          6m2s
liveness-http-probe   1/2     Running            7          8m46s
liveness-http-probe   2/2     Running            7          8m48s
...
liveness-http-probe   2/2     Running   11         21m
liveness-http-probe   1/2     Running   11         21m
liveness-http-probe   1/2     CrashLoopBackOff   11         22m
liveness-http-probe   1/2     Running            12         27m
...
liveness-http-probe   1/2     Running            13         28m
liveness-http-probe   1/2     CrashLoopBackOff   13         28m

在 Pod 描述中，您将看到重复Warnings的(x8 over 28m),(x84 over 24m)或(x2 over 28m)。

  Normal   Pulling    28m (x2 over 28m)     kubelet            Pulling image "k8s.gcr.io/liveness"
  Normal   Killing    28m                   kubelet            Container liveness failed liveness probe, will be restarted
  Normal   Started    28m (x2 over 28m)     kubelet            Started container liveness
  Normal   Created    28m (x2 over 28m)     kubelet            Created container liveness
  Normal   Pulled     28m                   kubelet            Successfully pulled image "k8s.gcr.io/liveness" in 561.418121ms
  Warning  Unhealthy  27m (x8 over 28m)     kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500
  Warning  Unhealthy  27m (x4 over 28m)     kubelet            Liveness probe failed: HTTP probe failed with statuscode: 500
  Normal   Pulled     13m (x2 over 14m)     kubelet            (combined from similar events): Successfully pulled image "k8s.gcr.io/liveness" in 508.892628ms
  Warning  BackOff    3m45s (x84 over 24m)  kubelet            Back-off restarting failed container

最近，我在线程中进行了一些测试liveness和探测 - Liveness Probe, Readiness Probe not call in Expected period。它可以为您提供更多信息。readiness

Answer 2

将重新启动容器。

就 k8s 文档而言：
kubelet 使用就绪探针来了解容器何时准备好开始接受流量。当 Pod 的所有容器都准备就绪时，该 Pod 就被认为准备就绪。

为了执行探测，kubelet 会向在容器中运行并侦听端口 8080 的服务器发送 HTTP GET 请求。如果服务器的 /healthz 路径的处理程序返回成功代码，kubelet 会认为容器处于活动状态，并且健康。如果处理程序返回失败代码，kubelet 将终止容器并重新启动它。

当 Pod 运行时，kubelet 能够重新启动容器来处理某种故障。在 Pod 中，Kubernetes 跟踪不同的容器状态并确定采取哪些操作来使 Pod 再次正常运行。

您可以查看 pod 事件来了解容器是否重新启动。

参考：k8s 文档和探针