Pod 生命周期由 Kubelet 在数据平面进行管理。
根据定义:如果 liveness probe 失败,kubelet 会杀死容器
Pod 只是一个带有专用网络命名空间和 IPC 命名空间的容器,带有一个沙盒容器。
比如说,如果 Pod 是单个应用容器 Pod,那么在 liveness 失败时:
- kubelet 会杀死 Pod 吗?
或者
- kubelet 是否会(仅)杀死 Pod 中的容器?
Pod 生命周期由 Kubelet 在数据平面进行管理。
根据定义:如果 liveness probe 失败,kubelet 会杀死容器
Pod 只是一个带有专用网络命名空间和 IPC 命名空间的容器,带有一个沙盒容器。
比如说,如果 Pod 是单个应用容器 Pod,那么在 liveness 失败时:
或者
Pod 确实是 Kubernetes 中最小的元素,但这并不意味着它实际上是“空的”而没有容器。
为了生成一个 pod 以及因此需要附加更多容器的容器元素,使用该pause
图像创建了一个非常小的容器。这用于分配一个 IP,然后用于 pod。之后启动为 pod 声明的 init-containers 或运行时容器。
如果生命周期探测失败,则重新启动容器。豆荚幸免于难。这甚至很重要:您可能希望在之后获取崩溃/重新启动的容器的日志。如果 pod 被销毁并重新创建,这是不可能的。
kubelet 使用 liveness probes 来了解何时重新启动容器(而不是整个 Pod)。如果 liveness probe 失败,kubelet 会杀死容器,然后容器可能会重启,但这取决于它的重启策略。
我创建了一个简单的示例来演示它是如何工作的。
首先,我创建了一个app-1
带有两个容器(web
和db
)的 Pod。web
容器配置了 liveness probe,由于未配置路径,它总是失败/healthz
。
$ cat app-1.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: app-1
name: app-1
spec:
containers:
- image: nginx
name: web
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
- image: postgres
name: db
env:
- name: POSTGRES_PASSWORD
value: example
应用上述清单并等待一段时间后,我们可以描述app-1
Pod 以检查只有web
容器已重新启动并且db
容器正在不间断地运行:
注意:我只提供了kubectl describe pod app-1
命令中的重要信息,而不是整个输出。
$ kubectl apply -f app-1.yml
pod/app-1 created
$ kubectl describe pod app-1
Name: app-1
...
Containers:
web:
...
Restart Count: 4 <--- Note that the "web" container was restarted 4 times
Liveness: http-get http://:8080/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
...
db:
...
Restart Count: 0 <--- Note that the "db" container works fine
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
...
Normal Killing 78s (x2 over 108s) kubelet Container web failed liveness probe, will be restarted
...
我们可以连接到db
容器以查看它是否正在运行:
注意:db
即使重新启动容器,我们也可以使用 web
容器。
$ kubectl exec -it app-1 -c db -- bash
root@app-1:/#
相比之下,在连接到web
容器后,我们可以观察到 liveness 探针重新启动了这个容器:
$ kubectl exec -it app-1 -c web -- bash
root@app-1:/# command terminated with exit code 137