背景
每次参数确定都是一个很头疼的事情,很多时候都是拍脑袋,这个不行就在拍一个参数,虽然每个参数的意思都很明确,过程也知道,哪怎么确定呢?
Kubernetes 1.18以前对于,我是如何确定livenessProbe和readinessProbe的参数,下面就是我们一个服务的健康检查的配置。其中initialDelaySeconds参数很多同学都设置为一样,我认为就是拍脑袋决定。我们如何确定呢?请继续...
livenessProbe:
exec:
command:
- sh
- '-c'
- >-
curl -m 2 -s http://127.0.0.1:8080/actuator/health |cut -b 1-15
|grep UP
initialDelaySeconds: 120
periodSeconds: 30
timeoutSeconds:2
successThreshold: 1
failureThreshold: 3
readinessProbe:
exec:
command:
- sh
- '-c'
- >-
curl -m 2 -s http://127.0.0.1:8080/actuator/health |cut -b
1-15 |grep UP
initialDelaySeconds: 60
timeoutSeconds: 2
periodSeconds: 20
successThreshold: 1
failureThreshold: 2
readinessProbe参数
我理解readinessProbe,是否服务就绪的时间,它是一个下限值。
initialDelaySeconds,它应该是覆盖大部分服务,或者应该是服务最短启动时间延时,我们这里通过统计,需要覆盖80%的服务,减少不不要启动阶段前的探测。
timeoutSeconds,在exec模式低版本不支持,所以如果采用curl命令需要同步在curl命令中增加 -m x参数。
主要是要求服务出现故障时,1分钟内下线节点,所以这里的配置为:
periodSeconds:20
successThreshold:1
failureThreshold:2
这样服务EndPoint可以在40-60s之间完成隔离。
livenessProbe参数
我理解livenessProbe,是服务存活检查,它是一个上限值,基于上限和下限之间,如果服务自动恢复了,readinessProbe参数会重新激活服务的EndPoint,同样存活检查也不会重复。
initialDelaySeconds,它应该覆盖全部服务,否则服务还没有启动,就重启了。那么最大保护时间就是:initialDelaySeconds+periodSeconds*failureThreshold+timeoutSeconds*(failureThreshold-1)。
timeoutSeconds,在exec模式低版本不支持,所以如果采用curl命令需要同步在curl命令中增加 -m x参数。
根据故障要求,服务故障2分钟yi,重启服务,所以这里配置为:
periodSeconds:30
successThreshold:1
failureThreshold:3
这样服务可以在90-120s之间完成隔离。
总结
Kubernetes 给我们提供很多可选项,但是每个参数怎么设置,需要摸索,同样需要结合实际情况总结对应的方法论。