当前位置：首页 > news >正文

Pod的生命周期

news 来源：原创 2025/8/29 0:19:24

概念

Pod对象自从其创建开始至其终止退出的时间范围称为其生命周期。在这段时间中，Pod会处于多种不同的状态，并执行一些操作；其中，创建主容器（main container）为必需的操作，其他可选的操作还包括运行初始化容器（init container）、容器启动后钩子（post start hook）、容器的存活性探测（liveness probe）、就绪性探测（readiness probe）以及容器终止前钩子（pre stop hook）等，这些操作是否执行则取决于Pod的定义。

在整个生命周期中，Pod会出现5种状态（相位），分别如下：

取值	描述
`Pending`（悬决）	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
`Running`（运行中）	Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
`Succeeded`（成功）	Pod 中的所有容器都已成功结束，并且不会再重启。
`Failed`（失败）	Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止，且未被设置为自动重启。
`Unknown`（未知）	因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

创建和终止

pod的创建过程
1. 用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer2. apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端3. apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的 变动4. scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer5. node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer6. apiServer将接收到的pod状态信息存入etcd中

pod的终止过程
1. 用户向apiServer发送删除pod对象的命令
2. apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为
dead
3. 将pod标记为terminating状态
4. kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
6. 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动
执行
7. pod对象中的容器进程收到停止信号
8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
9. kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可
见

钩子函数

kubernetes在主容器的启动之后和停止之前提供了两个钩子函数：
post start：容器创建之后执行，如果失败了会重启容器
pre stop ：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的
操作

钩子处理器支持使用下面三种方式定义动作：
Exec命令：在容器内执行一次命令
……lifecycle:postStart: exec:command:- cat- /tmp/healthy
……TCPSocket：在当前容器尝试访问指定的socket
……      lifecycle:postStart:tcpSocket:port: 8080
……HTTPGet：在当前容器中向某url发起http请求……lifecycle:postStart:httpGet:path: / #URI地址port: 80 #端口号host: 192.168.109.100 #主机地址scheme: HTTP #支持的协议，http或者https
……

我们以exec方式为例，演示下钩子函数的使用，创建pod-exec.yaml文件，写入：

apiVersion: v1
kind: Pod
metadata:name: pod-execnamespace: dev
spec:containers:- name: execimage: nginx:1.17.1ports:- name: nginx-portcontainerPort: 80lifecycle:postStart: exec: # 在容器启动的时候执行一个命令，修改掉nginx的默认首页内容command: ["/bin/sh", "-c", "echo postStart... > 
/usr/share/nginx/html/index.html"]preStop:exec: # 在容器停止之前停止nginx服务command: ["/usr/sbin/nginx","-s","quit"]

# 创建pod
[root@master ~]# kubectl create -f pod-exec.yaml
pod/pod-exec created
# 查看pod
[root@master ~]# kubectl get pods pod-exec -n dev -o wide
NAME           READY   STATUS     RESTARTS   AGE    IP            NODE    
pod-exec  1/1     Running    0          30s    10.264.3.68   node1   
# 访问pod
[root@master ~]# curl 10.264.3.68
postStart...

容器探针

在pod生命周期中可以做的一些事情。主容器启动前可以完成初始化容器，初始化容器可以有多个，他们是串行执行的，执行完成后就推出了，在主程序刚刚启动的时候可以指定一个post start 主程序启动开始后执行一些操作，在主程序结束前可以指定一个 pre stop 表示主程序结束前执行的一些操作。在程序启动后可以做两类检测 liveness probe（存活性探测）和 readness probe（就绪性探测）

探针是由 kubelet 对容器执⾏的定期诊断。要执⾏诊断， kubelet 调⽤由容器实现的 Handler。有三种类型的处理程序：

ExecAction：在容器内执⾏指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端⼝上的容器的 IP 地址进⾏ TCP 检查。如果端⼝打开，则诊断被认为是成功的
HTTPGetAction：对指定的端⼝和路径上的容器的 IP 地址执⾏ HTTP Get 请求。如果响应的状态码⼤于等于200且⼩于 400，则诊断被认为是成功的。

Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：

livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
startupProbe：指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依靠重启策略进行重启。如果容器没有提供启动探测，则默认状态为 Success。

何时该使用存活态探针?

如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针； kubelet 将根据 Pod 的 restartPolicy 自动执行修复操作。

如果你希望容器在探测失败时被杀死并重新启动，那么请指定一个存活态探针，并指定 restartPolicy 为 "Always" 或 "OnFailure"。

何时该使用就绪态探针？

如果要仅在探测成功时才开始向 Pod 发送请求流量，请指定就绪态探针。在这种情况下，就绪态探针可能与存活态探针相同，但是规约中的就绪态探针的存在意味着 Pod 将在启动阶段不接收任何数据，并且只有在探针探测成功后才开始接收数据。

如果你希望容器能够自行进入维护状态，也可以指定一个就绪态探针，检查某个特定于就绪态的因此不同于存活态探测的端点。

如果你的应用程序对后端服务有严格的依赖性，你可以同时实现存活态和就绪态探针。当应用程序本身是健康的，存活态探针检测通过后，就绪态探针会额外检查每个所需的后端服务是否可用。这可以帮助你避免将流量导向只能返回错误信息的 Pod。

如果你的容器需要在启动期间加载大型数据、配置文件或执行迁移，你可以使用启动探针。然而，如果你想区分已经失败的应用和仍在处理其启动数据的应用，你可能更倾向于使用就绪探针。

何时该使用启动探针？

对于所包含的容器需要较长时间才能启动就绪的 Pod 而言，启动探针是有用的。你不再需要配置一个较长的存活态探测时间间隔，只需要设置另一个独立的配置选定，对启动期间的容器执行探测，从而允许使用远远超出存活态时间间隔所允许的时长。

如果你的容器启动时间通常超出 \( initialDelaySeconds + failureThreshold \times periodSeconds \) 总值，你应该设置一个启动探测，对存活态探针所使用的同一端点执行检查。 periodSeconds 的默认值是 10 秒。你应该将其 failureThreshold 设置得足够高，以便容器有充足的时间完成启动，并且避免更改存活态探针所使用的默认值。这一设置有助于减少死锁状况的发生。

重启策略

一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由
pod的重启策略决定的，pod的重启策略有 3 种，分别如下：
Always ：容器失效时，自动重启该容器，这也是默认值。
OnFailure ：容器终止运行且退出码不为0时重启
Never ：不论状态为何，都不重启该容器
重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再
次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。

创建pod-restartpolicy.yaml：

apiVersion: v1
kind: Pod
metadata:name: pod-restartpolicynamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1ports:- name: nginx-portcontainerPort: 80livenessProbe:httpGet:scheme: HTTPport: 80path: /haharestartPolicy: Never # 设置重启策略为Never

# 创建Pod
[root@master ~]# kubectl create -f pod-restartpolicy.yaml
pod/pod-restartpolicy created
# 查看Pod详情，发现nginx容器失败
[root@master ~]# kubectl describe pod pod-restartpolicy -n dev
......Warning  Unhealthy  15s (x3 over 35s)  kubelet, node1     Liveness probe 
failed: HTTP probe failed with statuscode: 404Normal   Killing    15s                kubelet, node1     Container nginx 
failed liveness probe# 多等一会，再观察pod的重启次数，发现一直是0，并未重启   
[root@master ~]# kubectl get pod pod-restartpolicy -n dev
NAME                   READY   STATUS    RESTARTS   AGE
pod-restartpolicy      0/1     Running   0          5min42s

概念