0
点赞
收藏
分享

微信扫一扫

k8s教程(10)-pod生命周期、重启策略及健康检查


文章目录

  • ​​01 引言​​
  • ​​02 pod生命周期​​
  • ​​03 pod重启策略​​
  • ​​04 pod健康检查和服务可用性检查​​
  • ​​4.1 方式一:ExecAction ​​
  • ​​4.2 方式二:TCPSocketAction ​​
  • ​​4.3 方式三:HTTPGetAction ​​
  • ​​4.4 其它 ​​
  • ​​05 文末​​

01 引言

声明:本文为《Kubernetes权威指南:从Docker到Kubernetes实践全接触(第5版)》的读书笔记

本文主要讲解pod的生命周期、重启策略、健康检查及服务可用性检查。

02 pod生命周期

pod在整个生命周期中被系统定义为各种状态,熟悉pod的各种状态对于理解如何设置pod的调度策略、重启策略是很有必要的,pod状态如下:

状态值

描述

Pending

API Server已经创建了pod,但在pod内还有一个或多个容器的镜像没有创建,包括正在下载镜像的过程

Running

pod内所有容器均已创建,且至少有一个容器处于运行状态、正在启动状态或正在重启状态

Succeeded

pod内所有容器均成功执行后退出,且不会在重启

Failed

pod内所有容器均已退出,但至少有一个容器为退出失败状态

Unknown

由于某种原因无法获取该Pod的状态,可能由于网络通信不畅导致的

03 pod重启策略

pod的重启策略(​​RestartPolicy​​)应用于pod内的所有容器,并且仅在pod所处的 node由​​kubelet​ 进行判断和重启操作

当某个容器异常退出或者健康检查 失败时,​​kubelet​​​将根据​​RestartPolicy​​的设置进行相应的操作,pod的重启策略包括​Always​OnFailure​​Never​(默认值为​​Always​​):

重启策略

描述

Always

当容器失效时,由kubelet自动重启该容器

OnFailure

当容器终止运行且退出码不为0时,由kubelet自动重启该容器

Never

不论容器运行状态如何,kubelet都不会重启该容器

kubelet重启失效容器的时间间隔以​​symc-frequency​​​乘以​​2n​​来计算,例如1、 2、4、8倍等,最长延时5min,并且在成功重启后的10min后重置该时间。

pod的重启策略与控制方式息息相关,当前可用于管理​​pod​​​的控制器包括
ReplicationController、Job、DaemonSet,还可以通过kubelet管理(静态
pod)。每种控制器对Pod的重启策略要求如下:

控制器

要求

RC和DaemonSet

必须设置为Always,需要保证该容器持续运行

Job

OnFailure或Never,确保容器执行完成后不再重启

kubelet

在Pod失效时自动重启它,不论将RestartPolicy设置为什么值,也不会对Pod进行健康检查

结合pod的状态和重启策略,常见的状态转换场景如下:

k8s教程(10)-pod生命周期、重启策略及健康检查_容器化技术

04 pod健康检查和服务可用性检查

Kubernetes对Pod的健康状态可以通过三类探针来检查:LivenessProbe、
ReadinessProbe及StartupProbe
,其中最主要的探针为LivenessProbe与
ReadinessProbe,kubelet会定期执行这两类探针来诊断容器的健康状况。

探针

作用

LivenessProbe探针

用于判断容器是否存活(Running状态),如果LivenessProbe探针探测到容器不健康,则kubelet“将“杀掉”该容器,并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针,那么kubelet认 为该容器的LivenessProbe探针返回的值永远是Success

ReadinessProbe探针

用于判断容器服务是否可用(Ready状态),达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod、Service与PodEndpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready 状态变为False,则系统自动将其从Service的后端Endpoint列表中隔离出去,后续再把恢复到Ready状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。需要注意的是ReadinessProbe也是定期触发执行的,存在于Pod的整个生命周期中

StartupProbe探针

某些应用会遇到启动比较慢的情况,例如应用程序启动时需要与远程服务器建立网络连接,或者遇到网络访问较慢等情况时,会造成容器启动缓慢,此时ReadinessProbe就不适用了,因为这属于“有且仅有一次” 的超长延时,可以通过StartupProbe探针解决该问题

以上探针均可配置以下三种实现方式。

4.1 方式一:ExecAction

ExecAction在容器内部运行一个命令,如果该命令的返回码为0,则 表明容器健康。

举例:通过运行cat/tmp/health命令来判断一个容器运行是否正常。在该pod运行后,将在创建​/tmp/health​文件10s后删除该文件,而​LivenessProbe​健康检查的初始探测时间(​initialDelaySeconds​)为15s,探测结果是​Fail​,将导致​kubelet​ “杀掉” 该容器并重启它

k8s教程(10)-pod生命周期、重启策略及健康检查_重启_02

4.2 方式二:TCPSocketAction

TCPSocketAction通过容器的IP地址和端口号执行TCP检查,如果能够建立TCP连接,则表明容器健康。

举例:通过与容器内的​​localhost:80​​建立TCP连接进行健康检查:

k8s教程(10)-pod生命周期、重启策略及健康检查_云原生_03

4.3 方式三:HTTPGetAction

HTTPGetAction通过容器的IP地址、端口号及路径调用HTTP Get方 法,如果响应的状态码大于等于200且小于400,则认为容器健康。

举例:kubelet定时发送​​HTTP​​​请求到​​localhost:80/_status​​​,​​/healthz​​来进行容器应用的健康检查:

k8s教程(10)-pod生命周期、重启策略及健康检查_生命周期_04

4.4 其它

对于每种探测方式,都需要设置initialDelaySecondstimeoutSeconds两个参数,它们的含义分别如下。

参数

含义

initialDelaySeconds

启动容器后进行首次健康检查的等待时间,单位为s

timeoutSeconds

健康检查发送请求后等待响应的超时时间,单位为s ,当超时发生时,kubelet会认为容器已经无法提供服务,将会重启该容器

如下代码片段是StartupProbe探针的一个参考配置,可以看到,这个​​Pod​​可以有长达30×10=300s的超长启动时间:

k8s教程(10)-pod生命周期、重启策略及健康检查_云原生_05

​Kubernetes​​​的​​Pod​​可用性探针机制可能无法满足某些复杂应用对容器内服务可 用状态的判断,所以Kubernetes从1.11版本开始,引入了Pod Ready++特性对Readiness探测机制进行扩展,在1.14版本时达到GA稳定版本,称其为Pod
Readiness Gates。

Pod Readiness Gates给予了Pod之外的组件控制某个Pod就绪的能力,通过Pod Readiness Gates机制,用户可以设置自定义的Pod可用性探测方式来告诉Kubernetes某个Pod是否可用,具体使用方式是用户提供一个外部的控 制器(Controller)来设置相应Pod的可用性状态。

举例:Pod的Readiness Gates在Pod定义中的ReadinessGate字段进行一个类型为www.example.com/feature-l的新Readiness Gate:

k8s教程(10)-pod生命周期、重启策略及健康检查_重启_06


新增的自定义Condition的状态(​status​)将由用户自定义的外部控制器设置(默认值为​False​​Kubernetes​将在判断全部​readinessGates​条件都为​True​时, 才设置​Pod​为服务可用状态(​Ready​​True​)

05 文末

本文主要讲解pod生命周期、重启策略及健康检查,希望能帮助到大家,谢谢大家的阅读,本文完!


举报

相关推荐

0 条评论