Kubernetes中的livenessProbe和readinessProbe中的参数如何确定?

背景

每次参数确定都是一个很头疼的事情,很多时候都是拍脑袋,这个不行就在拍一个参数,虽然每个参数的意思都很明确,过程也知道,哪怎么确定呢?

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 给我们提供很多可选项,但是每个参数怎么设置,需要摸索,同样需要结合实际情况总结对应的方法论。

 

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值