如何解决当 pod 包含多个容器时,K8s 活性探测行为?
场景:一个 K8S pod 有多个容器,并且为每个容器配置了 liveness/readiness 探针。现在,如果活性探测在一些容器上成功而在少数容器上失败,k8s 会做什么。
- 它会不会只重启失败的容器
或 - 它会重新启动整个 pod。
解决方法
如果活性探测在一些容器上成功而在少数容器上失败,k8s 会做什么?
它只会重启失败的容器。
在 Pod Lifecycle - Container Probes 中,您列出了所有 3 个探针:liviness
、readiness
和 startup
。
livenessProbe
:指示 container
是否正在运行。 如果活性探测失败,kubelet 会杀死容器,并且容器会受到其 restart policy
的影响。如果容器不提供活性探测,则默认状态为成功。
在 Configure Liveness,Readiness and Startup Probes - Define a liveness command 中,您有示例,并且提到:
如果命令成功,则返回 0,kubelet 认为容器是存活且健康的。如果命令返回一个非零值,kubelet 杀死容器并重新启动它。
情况相同的情况是 HTTP request liveness probe:
如果服务器的 /healthz 路径的处理程序返回成功代码,则 kubelet 认为容器处于活动状态且健康。如果处理程序返回失败代码,kubelet 会杀死容器并重新启动它。
kubelet 将在容器启动 15 秒后运行第一个 liveness probe。就像就绪探针一样,这将尝试连接到端口 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 Probe,Readiness Probe not called in expected duration 中对 liveness
和 readiness
探针进行了一些测试。它可以为您提供其他信息。
将重新启动容器。
就 k8s 文档而言:
kubelet 使用就绪探针来了解容器何时准备好开始接受流量。当 Pod 的所有容器都准备就绪时,就认为 Pod 准备就绪。
为了执行探测,kubelet 向在容器中运行并侦听端口 8080 的服务器发送 HTTP GET 请求。如果服务器的 /healthz 路径的处理程序返回成功代码,则 kubelet 认为容器活得健康。如果处理程序返回失败代码,kubelet 会杀死容器并重新启动它。
当 Pod 正在运行时,kubelet 能够重新启动容器以处理某种故障。在 Pod 内,Kubernetes 会跟踪不同的容器状态,并确定采取什么措施使 Pod 再次健康。
您可以查看 pod 事件以查看容器是否重新启动。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。