前言

我们知道 Pod 是 Kubernetes 集群中的最⼩单元，⽽ Pod 是有容器组组成的，所以在讨论 Pod 的⽣命周期的时候我们可以先来讨论下容器的⽣命周期。

Pod Hook

Pod Hook 是由 kubelet 发起的，当容器中的进程启动前或者容器中的进程终⽌之前运⾏，这是包含在容器的⽣命周期之中。我们可以同时为 Pod 中的所有容器都配置 hook。

Kubernetes 为我们提供了两种钩⼦函数：

• PostStart：这个钩⼦在容器创建后⽴即执⾏。但是，并不能保证钩⼦将在容器 ENTRYPOINT 之前运 ⾏，因为没有参数传递给处理程序。主要⽤于资源部署、环境准备等。不过需要注意的是如果钩 ⼦花费太⻓时间以⾄于不能运⾏或者挂起， 容器将不能达到 running 状态。
• PreStop：这个钩⼦在容器终⽌之前⽴即被调⽤。它是阻塞的，意味着它是同步的， 所以它必须 在删除容器的调⽤发出之前完成。主要⽤于优雅关闭应⽤程序、通知其他系统等。如果钩⼦在执 ⾏期间挂起， Pod阶段将停留在 running 状态并且永不会达到 failed 状态。

如果 PostStart 或者 PreStop 钩⼦失败， 它会杀死容器。所以我们应该让钩⼦函数尽可能的轻量。当 然有些情况下，⻓时间运⾏命令是合理的， ⽐如在停⽌容器之前预先保存状态。

另外我们有两种⽅式来实现上⾯的钩⼦函数：

• Exec - ⽤于执⾏⼀段特定的命令，不过要注意的是该命令消耗的资源会被计⼊容器。
• HTTP - 对容器上的特定的端点执⾏ HTTP 请求。

环境准备

以下示例中，定义了⼀个Nginx Pod，其中设置了 PostStart 钩⼦函数，即在容器创建成功后，写⼊⼀句话到 /usr/share/message ⽂件中。

apiVersion: v1 
kind: Pod 
metadata: 
name: hook-demo1 
spec: 
containers: 
- name: hook-demo1 
image: nginx 
lifecycle: 
postStart: 
exec: 
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/m 
essage"] 

优雅删除资源对象

当⽤户请求删除含有 pod 的资源对象时（如Deployment等），K8S 为了让应⽤程序优雅关闭（即让应⽤程序完成正在处理的请求后，再关闭软件），K8S提供两种信息通知：

• 默认：K8S 通知 node 执⾏ docker stop 命令，docker 会先向容器中 PID 为1的进程发送系统信号 SIGTERM ，然后等待容器中的应⽤程序终⽌执⾏，如果等待时间达到设定的超时时间，或者默认超时时间（30s），会继续发送 SIGKILL 的系统信号强⾏ kill 掉进程。
• 使⽤ pod ⽣命周期（利⽤ PreStop 回调函数），它执⾏在发送终⽌信号之前。

默认所有的优雅退出时间都在30秒内。kubectl delete 命令⽀持 --grace-period=<seconds> 选项，这 个选项允许⽤户⽤他们⾃⼰指定的值覆盖默认值。值’0’代表 强制删除 pod. 在 kubectl 1.5 及以上的版 本⾥，执⾏强制删除时必须同时指定 --force --grace-period=0 。

强制删除⼀个 pod 是从集群状态还有 etcd ⾥⽴刻删除这个 pod。 当 Pod 被强制删除时， api 服务器 不会等待来⾃ Pod 所在节点上的 kubelet 的确认信息：pod 已经被终⽌。在 API ⾥ pod 会被⽴刻删 除，在节点上， pods 被设置成⽴刻终⽌后，在强⾏杀掉前还会有⼀个很⼩的宽限期。

以下示例中，定义了⼀个Nginx Pod，其中设置了 PreStop 钩⼦函数，即在容器退出之前，优雅的关闭 Nginx:

apiVersion: v1 
kind: Pod 
metadata: 
name: hook-demo2 
spec: 
containers: 
- name: hook-demo2 
image: nginx 
lifecycle: 
preStop: 
exec: 
command: ["/usr/sbin/nginx","-s","quit"] 
--- 
apiVersion: v1 
kind: Pod 
metadata: 
name: hook-demo2 
labels: 
app: hook 
spec: 
containers: 
- name: hook-demo2 
image: nginx 
ports: 
- name: webport 
containerPort: 80 
volumeMounts: 
- name: message 
mountPath: /usr/share/ 
lifecycle: 
preStop: 
exec: 
command: ['/bin/sh', '-c', 'echo Hello from the preStop Handler > /usr/share/mes 
sage'] 
volumes: 
- name: message 
hostPath: 
path: /tmp 

另外 Hook 调⽤的⽇志没有暴露个给 Pod 的 event，所以只能通过 describe 命令来获取，如果有错误 将可以看到 FailedPostStartHook 或 FailedPreStopHook 这样的 event。

健康检查

除了上⾯这两个钩⼦函数以外，还有⼀项配置会影响到容器的⽣命周期的，那就是健康检查的探针。

在 Kubernetes 集群当中，我们可以通过配置 liveness probe （存活探针）和 readiness probe （可读性探针）来影响容器的⽣存周期。

• kubelet 通过使⽤ liveness probe 来确定你的应⽤程序是否正在运⾏，通俗点将就是是否还活着。⼀般来 说，如果你的程序⼀旦崩溃了， Kubernetes 就会⽴刻知道这个程序已经终⽌了，然后就会重启这个程序。⽽我 们的 liveness probe 的⽬的就是来捕获到当前应⽤程序还没有终⽌，还没有崩溃，如果出现了这些情况，那么 就重启处于该状态下的容器，使应⽤程序在存在 bug 的情况下依然能够继续运⾏下去。
• kubelet 使⽤ readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是 否准备好了，现在可以开始⼯作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处 于就绪状态，因为⼀个 Pod 下⾯可能会有多个容器。当然 Pod 如果处于⾮就绪状态，那么我们就会将他从我们 的⼯作队列(实际上就是我们后⾯需要重点学习的 Service)中移除出来，这样我们的流量就不会被路由到这个 Pod ⾥⾯来了。

和前⾯的钩⼦函数⼀样的，我们这两个探针的⽀持两种配置⽅式：

• exec：执⾏⼀段命令
• http：检测某个 http 请求
• tcpSocket：使⽤此配置， kubelet 将尝试在指定端⼝上打开容器的套接字。如果可以建⽴连接，容器被认为 是健康的，如果不能就认为是失败的。实际上就是检查端⼝

我们先来给⼤家演示下存活探针的使⽤⽅法，⾸先我们⽤ exec 执⾏命令的⽅式来检测容器的存活，如下:

apiVersion: v1 
kind: Pod 
metadata: 
name: liveness-exec 
labels: 
test: liveness 
spec: 
containers: 
- name: liveness 
image: busybox 
args: 
- /bin/sh 
- -c 
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 
livenessProbe: 
exec: 
command: 
- cat 
- /tmp/healthy 
initialDelaySeconds: 5 
periodSeconds: 5 

我们这⾥需要⽤到⼀个新的属性： livenessProbe ，下⾯通过 exec 执⾏⼀段命令，其 中 periodSeconds 属性表示让 kubelet 每隔5秒执⾏⼀次存活探针，也就是每5秒执⾏⼀次上⾯的 cat /tmp/healthy 命令，如果命令执⾏成功了，将返回0，那么 kubelet 就会认为当前这个容器是存活的并且很监控，如果返回的是⾮0值，那么 kubelet 就会把该容器杀掉然后重启它。另外⼀个属性 initialDelaySeconds 表示在第⼀次执⾏探针的时候要等待5秒，这样能够确保我们的容器能够有⾜够的时间启动起来。

另外我们在容器启动的时候，执⾏了如下命令：

☁ ~ /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

意思是说在容器最开始的30秒内有⼀个 /tmp/healthy ⽂件，在这30秒内执⾏ cat /tmp/healthy 命令 都会返回⼀个成功的返回码。30秒后，我们删除这个⽂件，现在执⾏ cat /tmp/healthy 是不是就会失败了，这个时候就会重启容器了。

我们来创建下该 Pod ，在30秒内，查看 Pod 的 Event ：

☁ ~ kubectl describe pod liveness-exec

我们可以观察到容器是正常启动的，在隔⼀会⼉，⽐如40s后，再查看下 Pod 的 Event ，在最下⾯有⼀条信息显示 liveness probe 失败了，容器被删掉并重新创建。

然后通过 kubectl get pod liveness-exec 可以看到 RESTARTS 值加1了。

同样的，我们还可以使⽤ HTTP GET 请求来配置我们的存活探针，我们这⾥使⽤⼀个 liveness 镜像来验证演示下

apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: liveness 
name: liveness-http 
spec: 
containers: 
- name: liveness 
image: cnych/liveness 
args: 
- /server 
livenessProbe: 
httpGet: 
path: /healthz 
port: 8080 
httpHeaders: 
- name: X-Custom-Header 
value: Awesome 
initialDelaySeconds: 3 
periodSeconds: 3 

同样的，根据periodSeconds属性我们可以知道 kubelet 需要每隔3秒执⾏⼀次 liveness probe ，该探针将向容器中的 server 的8080端⼝发送⼀个 HTTP GET 请求。如果 server 的 /healthz 路径的 handler 返回⼀个成功的返回码， kubelet 就会认定该容器是活着的并且很健康,如果返回失败的返回码， kubelet 将杀掉该容器并重启它。。 initialDelaySeconds 指定 kubelet 在该执⾏第⼀次探测之前需要等待3秒钟。

通常来说，任何⼤于200⼩于400的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。

我们可以来查看下上⾯的 healthz 的实现：

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { 
duration := time.Now().Sub(started) 
if duration.Seconds() > 10 { 
w.WriteHeader(500) 
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds()))) 
} else { 
w.WriteHeader(200) 
w.Write([]byte("ok")) 
} 
}) 

⼤概意思就是最开始前10s返回状态码200，10s过后就返回500的 status_code 了。所以当容器启动3 秒后， kubelet 开始执⾏健康检查。第⼀次健康监测会成功，因为是在10s之内，但是10秒后，健康 检查将失败，因为现在返回的是⼀个错误的状态码了，所以 kubelet 将会杀掉和重启容器。

同样的，我们来创建下该 Pod 测试下效果，10秒后，查看 Pod 的 event，确认 liveness probe 失败并重启了容器。

☁ ~ kubectl describe pod liveness-http

然后我们来通过端⼝的⽅式来配置存活探针，使⽤此配置， kubelet 将尝试在指定端⼝上打开容器的套接字。 如果可以建⽴连接，容器被认为是健康的，如果不能就认为是失败的。

apiVersion: v1 
kind: Pod 
metadata: 
name: goproxy 
labels: 
app: goproxy 
spec: 
containers: 
- name: goproxy 
image: cnych/goproxy 
ports: 
- containerPort: 8080 
readinessProbe: 
tcpSocket: 
port: 8080 
initialDelaySeconds: 5 
periodSeconds: 10 
livenessProbe: 
tcpSocket: 
port: 8080 
initialDelaySeconds: 15 
periodSeconds: 20 

我们可以看到，TCP 检查的配置与 HTTP 检查⾮常相似，只是将 httpGet 替换成了 tcpSocket 。

另外除了上⾯的 initialDelaySeconds 和 periodSeconds 属性外，探针还可以配置如下⼏个参数：

• timeoutSeconds：探测超时时间，默认1秒，最⼩1秒。
• successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1，但是如果是livene ss则必须是 1。最⼩值是 1。
• failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3，最⼩值是 1。