所以无论 回调函数的执行结果如何，容器最终都会在 Pod 的终止宽限期内被终止。
没有参数会被传递给处理程序。
PreStop 回调并不会与停止容器的信号处理程序异步执行；回调必须在 可以发
送信号之前完成执行。 如果 PreStop 回调在执行期间停滞不前，Pod 的阶段会变成
Terminating 并且一直处于该状态，直到其 terminationGracePeriodSeconds 耗尽
为止， 这时 Pod 会被杀死。 这一宽限期是针对 PreStop 回调的执行时间及容器正常
停止时间的总和而言的。 例如，如果 terminationGracePeriodSeconds 是 60，回
调函数花了 55 秒钟 完成执行，而容器在收到信号之后花了 10 秒钟来正常结束，那
么容器会在其 能够正常结束之前即被杀死，因为 terminationGracePeriodSeconds
的值 小于后面两件事情所花费的总时间（55+10）。
prestop是对于通过svc暴露服务的应用的在业务零中断的滚动更新重要考量之
一。当Pod 被删除后，会被设置为 Terminating 状态，并从所有 Service 的 End-
points 列表中删除。此时，Pod 停止获得新的流量，但依然可以处理老的流量请
求，但是存在一种可能就是 Pod 收到 SIGTERM 信号并且停止工作后，但是还未从
Endpoints 或者ipvs的转发规则中移除，这时候就存在新的流量打到了停止的pod或
者已经不存在的pod情况，从而造成了访问的5xx。所以建议为 pod 配置 preStop
Hook，使 Pod 收到 SIGTERM 时 sleep 一段时间而不是立刻停止工作，而是相关的
转发规则和endpoint移除后，pod才被终止工作，从而保证pod在终止前可以平滑的
处理相关请求。
需要注意的是k8s对于pod有个参数terminationGracePeriodSeconds，默认是
30s，表明pod如果prestop运行达到30s就会被立刻终止，此时如果应用的请求还未
被处理完毕，依然会产生请求中断的情况，所以合理考虑和设置prestop是需要考虑
的因素之一。一般情况下，我们建议terminationGracePeriodSeconds 时间建议设
置为 preStop 的时间再加 30 秒以上，或者提前在镜像中写好了终止脚本，当pod收
到term信号后，执行终止脚本，让应用程序优雅的主动关闭相关的连接请求。
3.2.3 健康检查
readiness
kubelet 使用就绪探测器可以知道容器何时准备好接受请求流量，当一个 Pod 内
的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个
Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔
除。有时候，应用会暂时性地无法为请求提供服务。 例如，应用在启动时可能需要
加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 在这种情况下，应
用是无法承载相关业务流量的。Kubernetes 提供了就绪探测器来发现并缓解这些情
况。即设置合理的就绪探针policy，让业务应用在完全启动之后，才加入到service的
后端中承载业务流量。 就绪探测器在容器的整个生命周期中保持运行状态 ，合理的
就绪设置，对于应用的平滑部署和滚动更新至关重要：
a. 目前探针类型主要是EXEC， TCP和HTTP（1.24版本中会加入grpc）：如果
业务是HTTP协议暴露的端口，建议探针类型选择HTTP，很多部署情况下会使用
TCP探针，这种情况下存在四层监听就绪，但是七层业务还未启动的情况，可能会让
业务状态未ok的pod被加到svc的后段，承载业务，进而引发业务超时或者5xx。
b.合理设置successThreshold、failureThreshold和timeoutSeconds对于pod能
否平稳的提供业务应用非常重要。timeoutSeconds设置太小，比如 1ms等，这样的
含义是探针1ms内没有得到回复，就认为探针失败，failure次数增加一次，这样很容
易增加pod达到被判定失败的阈值，从而被从svc中移除后端，对于success来说，反
之亦然。
liveness
kubelet 使用存活探测器来确定什么时候要重启容器。 例如，存活探测器可以探
测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种
状态下的容器有助于提高应用的可用性，即使其中存在缺陷。根据这个探针的行为，
当探测失败达到阈值时候时候，会杀死重启容器。
31 企业级云原生白皮书项目实战 企业级云原生白皮书项目实战 32
企业级云原生白皮书项目实战
