Kubernetes in Action笔记 - (5) Pod的生命周期与探针

文章目录

Pod生命周期

Pod的phase是Pod生命周期中的简单宏观描述，定义在Pod的PodStatus对象的phase 字段中。

phase有以下几种值：

容器状态

容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

容器重启策略

Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。

restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅针对同一节点上 kubelet 的容器重启动作。当 Pod 中的容器退出时，kubelet 会按指数回退 方式计算重启的延迟（10s、20s、40s、...），其最长延迟为 5 分钟。 一旦某容器执行了 10 分钟并且没有出现问题，kubelet 对该容器的重启回退计时器执行 重置操作。

Pod 状况

Pod 有一个 PodStatus 对象，其中包含一个 PodConditions 数组。Pod 可能通过也可能未通过其中的一些状况测试。

• PodScheduled：Pod 已经被调度到某节点；
• ContainersReady：Pod 中所有容器都已就绪；
• Initialized：所有的 Init 容器 都已成功启动；
• Ready：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。

存活探针

介绍

通过存活探针 (liveness probe) 检查容器是否还在运行。如果探测失败, k8s将定期执行探针并重新启动容器。

可以为pod中的每个容器单独指定存活探针。

有以下三种探测容器的机制：

• HTTP GET 探针
  • 对容器的IP地址(你指定的端口和路径)执行 HTTP GET请求。如果探测器收到响应，并且响应状态码不代表错误(换句话说，如果HTTP响应状态码是2xx或3xx)，则认为探测成功。如果服务器返回错误响应状态码或者根本没有响应,那么探测就被认为是失败的，容器将被重新启动。
• TCP套接字探针
  • 尝试与容器指定端口建立TCP连接。如果连接成功建立,则探测成功。否则，容器重新启动。
• Exec探针
  • 在容器内执行任意命令,并检查命令的退出状态码。如果状态码是0，则探测成功。所有其他状态码都被认为失败。

下面是包含存活探针的例子

 1apiVersion: vl
 2kind: Pod
 3metadata:
 4  name: test-liveness
 5spec:
 6  containers:
 7  - image: pz/testPod
 8    name: testPod
 9    livenessProbe:
10      httpGet:
11        path: /
12        port: 8080
13      initialDelaySeconds: 15

存活探针还有一些附加属性，比如：

• delay: 在容器启动后延迟多久开始探测
• timeout： 此容器必须在多少时间内进行响应, 否则这次探测记作失败
• period： 多久探测一次
• failure： 失败几次后重启容器
• initialDelaySeconds： 初始延迟探测时间。如果没有设置初始延迟，探针将在启动时立即开始探测容器, 这通常会导致探测失败, 因为应用程序还没准备好开始接收请求。如果失败次数超过阈值, 在应用程序能正确响应请求之前, 容器就会重启。务必设置一个初始延迟来说明应用程序的启动时间。

创建有效的探针

对于在生产中运行的pod, 一定要定义一个存活探针。没有探针的话，k8s无法知道应用是否还活着。

存活探针的注意事项：

• 为了更好地进行存活检查，将探针配置为请求特定的URL路径(例如/health), 并让应用从内部对内部运行的所有重要组件执行状态检查, 以确保它们都没有终止或停止响应。
• 一定要检查应用程序的内部, 而没有任何外部因素的影响。 例如, 当服务器无法连接到后端数据库时, 前端Web服务器的存活探针不应该返回失败。 如果间题的底层原因在数据库中, 重启Web服务器容器不会解决问题。 由于存活探测将再次失败, 你将反复重启容器直到数据库恢复。
• 确保 /health 的 HTTP瑞点不需要认证, 否则探剧会一直失败, 导致你的容器无限重启
• 保持探针轻量。它不应消耗太多的计算资源, 并且运行不应该花太长时间
• 无须在探针中实现重试循环。因为它的失败阙值是可配置，而且k8s本身会重试

就绪探针

与存活探针一样，就绪探针也有三种类型:

• HTTP GET 探针
• TCP socket 探针
• Exec 探针

启动容器时,可以为 k8s 配置一个等待时间,经过等待时间后才可以执行第一次准备就绪检查。之后,它会周期性地调用探针,并根据就绪探针的结果采取行动。如果某个 pod 报告它尚未准备就绪,则会从该服务中删除该 pod。 如果 pod再次准备就绪,则重新添加 pod。

就绪探针的重要性:设想一组pod (例如, 运行应用程序服务器的pod)取决于另一个pod (例如, 后端数据库)提供的服务。 如果任何一个前端连接点出现连接间题并且无法再访问数据库, 那么就绪探针可能会告知k8s该pod没有准备好处理任何请求。如果其他pod实例没有遇到类似的连接问题, 则它们可以正常处理请求。就绪探针确保客户端只与正常的pod交互, 并且永远不会知道系统存在问题。

注意事项：

• 务必定义就绪探针
• 不要将停止 pod 的逻辑纳入就绪探针中

两种探针的区别

总的来说 ReadinessProbe 和 LivenessProbe 是使用相同探测的方式，只是探测后对 Pod 的处置方式不同：

• 存活探针： 当检测失败后将杀死容器，并根据 Pod 的重启策略来决定作出对应的措施。即重启，或删除并重建。
• 就绪探针： 当检测失败后，将 Pod 的 IP:Port 从对应 Service 关联的 EndPoint 地址列表中删除。即设置为服务不可访问。

图书资料：

• https://book.douban.com/subject/30418855/

参考：

• http://www.mydlq.club/article/39/
• https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/