Kubernetes-探针readinessProbe、livenessProbe和startupProbe
更多相关资料见 : K8S Basic-Pod资源管理进阶(Pod声明周期、相位、资源限制)
目录
一、Pod三种探针方式
- readinessProbe
- livenessProbe
- startupProbe(v1.16版本增加)
-
livenessProbe和readnessProbe、startupProbe:一般支持的命令都是三种
exec
执行命令来做健康状态检测且此命令一定时容器内部支持的命令httpGet
如果资源为web服务,也可以直接服务请求一个资源,如果请求成功为成功,无响应则为不健康tcpSocket
探测服务监听的某个端口,发起请求,根据响应判断健康与否failureThreshold
(错误阈值)探测的多少次没有响应才视为服务出现问题,默认为三次successThreshold
(成功阈值) 探测连续成功多少次才视为成功,默认值为1,成功探测一次则视为成功,不可修改periodSeconds
(检查周期)每次探测的时间间隔,默认为10s,最低值为1sinitialDelaySeconds
资源初始化多久以后在进行探测检查,如果不定义默认为启动资源则开始执行探测timeoutSeconds
(探测的超时时间间隔)每次检查资源未响应等待时间,比如请求发出一直等待响应的时间,默认1s
-
每次探测都将获得以下三种结果之一:
- 成功:容器通过了诊断。
- 失败:容器未通过诊断。
- 未知:诊断失败,因此不会采取任何行动。
1.1、readinessProbe存活探针
- readinessProbe : 指示容器是否准备好服务请求(是否启动完成并就绪)。绪探针初始延迟之前的就绪状态默认为Failure,待容器启动成功弹指指标探测结果为成功后,状态变更为 Success。如果未配置就绪探针,则默认状态为Success。
- 只有状态为 Success ,才会被纳入 pod 所属 service 中,也就是 service 接收到请求后才有可能会被分发处理请求。
如果ReadinessProbe探针检测到失败,则Pod的状态被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。
1.1.1、存活探针 - HTTP协议
containers:
- name: xxx
image: xxx
# 存活检查
livenessProbe:
httpGet:
scheme: HTTP # 协议
path: /actuator/health # 路径
port: 8080 # 端口
initialDelaySeconds: 30 # 延迟探测时间(秒) 【 在k8s第一次探测前等待秒 】
periodSeconds: 10 # 执行探测频率(秒) 【 每隔秒执行一次 】
timeoutSeconds: 1 # 超时时间
successThreshold: 1 # 健康阀值
failureThreshold: 3 # 不健康阀值
1.1.2、存活探针 - TCP协议
containers:
- name: xxx
image: xxx
# 存活检查
livenessProbe:
tcpSocket: # TCP
port: 8090 # 端口
initialDelaySeconds: 50 # 延迟探测时间(秒) 【 在k8s第一次探测前等待秒 】
periodSeconds: 10 # 执行探测频率(秒) 【 每隔秒执行一次 】
timeoutSeconds: 1 # 超时时间
successThreshold: 1 # 健康阀值
failureThreshold: 3 # 不健康阀值
# 上面配置的意思是容器启动50s后,每10s检查一次,允许失败的次数是3次。如果失败次数超过3则会触发restartPolicy。
1.2、readnessProbe就绪探针
- readnessProbe : 用于判断容器是否存活(running状态),如果LivenessProbe探针探测到容器不健康(你可以配置连续多少次失败才记为不健康),则 kubelet 会杀掉该容器,并根据容器的重启策略做相应的处理。如果未配置存活探针,则默认状态为Success。即探针返回的值永远是 Success。
1.2.1、就绪探针 - HTTP协议
- HTTP协议和TCP协议配置方法和存活探测相同
containers:
- name: xxx
image: xxx
# 就绪检查
readinessProbe:
httpGet:
scheme: HTTP # 协议
path: /actuator/health # 路径
port: 8080 # 端口
initialDelaySeconds: 30 # 延迟探测时间(秒)【 在k8s第一次探测前等待秒 】
periodSeconds: 2 # 执行探测频率(秒) 【 每隔秒执行一次 】
timeoutSeconds: 1 # 超时时间
successThreshold: 1 # 健康阀值
failureThreshold: 3 # 不健康阀值
1.3、startupProbe启动探针
- startupProbe是在k8s v1.16加入了alpha版,官方对其作用的解释是:
Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state is Success
大概是意思是:判断容器内的应用程序是否已启动。如果提供了启动探测,则禁用所有其他探测,直到它成功为止。如果启动探测失败,kubelet将杀死容器,容器将服从其重启策略。如果容器没有提供启动探测,则默认状态为成功。
注意:不要将startupProbe和readinessProbe混淆。
1.3.1、启动探针
- startupProbe 脚本内容和 readinessProbe 相比,除了名字不同之外,其他配置和含义相同;
- 通常将 startupProbe 和 livenessProbe 组合使用,livenessProbe 的时间是从 startupProbe 状态成功后开始计算;
livenessProbe:
httpGet:
path:/test
prot:80
failureThreshold:1
initialDelay:10
periodSeconds:10
startupProbe:
httpGet:
path:/test
prot:80
failureThreshold:10
initialDelay:10
periodSeconds:10
# 上面的配置是只有startupProbe探测成功后再交给livenessProbe。咱们startupProbe配置的是10*10s,也就是说只要应用在100s内启动都是OK的,并且应用挂掉了10s就会发现问题
向往的地方很远,喜欢的东西很贵,这就是我努力的目标。