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

Question

场景:一个K8S吊舱有多个容器，并为每个容器配置了活性/就绪探测。现在，如果活性探测在一些容器上成功，而在少数容器上失败，那么k8s将做什么。

1. 它是否只重新启动失败的容器？ 或
2. 它会重启整个吊舱吗。

Answer 1

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

只会重新启动失败的容器.

在吊舱生命周期-容器探针中，您列出了所有三个探测：liviness、readiness和startup。

livenessProbe：指示container是否正在运行。如果活性探测失败，kubelet将杀死容器，容器将受到其restart policy的约束。如果容器没有提供活性探测，默认状态是成功。

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

如果命令成功，则返回0，kubelet认为容器是活动的和健康的。如果命令返回一个非零值，kubelet 将终止容器并重新启动。

同样的情况也发生在万一HTTP请求活性探针

如果服务器的/healthz路径的处理程序返回一个成功的代码，那么kubelet就会认为容器是活的和健康的。如果处理程序返回一个失败代码，kubelet将杀死容器并重新启动它。

以及使用TCP活性探针

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

测试

如果您想要创建自己的测试，可以使用下面的HTTP活性探测示例：

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

在豆荚描述中，您将看到重复的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和readiness探针在活性探针，预期持续时间内未调用的准备性探针线程中做了一些测试。它可以为你提供更多的信息。

Answer 2

将重新启动容器。

就k8s文档而言：

kubelet使用就绪探测来了解容器何时准备开始接收流量。当一个Pod的所有容器都准备好时，它就被认为已经准备好了。

为了执行探测，kubelet向运行在容器中并侦听端口8080的服务器发送一个HTTP请求。如果服务器的/healthz路径的处理程序返回一个成功的代码，那么kubelet就会认为容器是活的和健康的。如果处理程序返回一个失败代码，kubelet将杀死容器并重新启动它。

当一个Pod正在运行时，kubelet能够重新启动容器来处理某些故障。在Pod中，Kubernetes跟踪不同的集装箱状态，并决定采取什么措施使Pod再次健康。

您可以看到pod事件，以查看容器是否重新启动。

参考文献：k8s文档和探针