kubernetes健康检查liveness readiness startupProbe探针

由于历史项目跑在kubernetes中 出现了一些如下问题

• 程序发布的时候 新版本的pod还没有启动成功 老版本的pod就已经停止了 ，这就导致部分请求访问到了新pod，由于新pod内程序还没有启动成功，所有这部分请求就以失败告终。还有可能新pod 启动失败了 就会出现pod一直在重启 然而服务又不可用。
  
• 运行中的pod 因为网络或者某种原因导致服务暂时不可用，对于kubernetes来说pod是状态是正常的，这时候的业务流量也可能会分发在次pod中，也是会报错误失败。
  
• 如何让kubernetes定义pod是否健康 是否启动成功？
  

健康检查

当前的kubernetes版本为 v1.19 提供了三种健康检查。

• 存活探针 livenessProbe：通过检测容器响应是否正常来决定是否重启
  如果此探针检查失败 会重启容器
  
• 就绪探针 readinessProbe:  用来确定容器是否已经就绪可以接受请求
  如果配置了就绪探针 只有通过探针检查后 才会认为pod具备访问的能力，kubernetes才会把ip port 加入到service中的endpoint中去，反之失败也会从endpoint中移除，这样流量就不会被分配到没有准备好的容器中去。
  
• 启动探针 startupProbe: 检测容器内应用是否已经启动 v1.18+才支持
  启动探针在没有探测成功之前 livenessProbe、readinessProbe 探针会处于禁用状态。基于此特性 就可以避免livenessProbe由于一直失败 一直重启容器的死锁问题。
  

这3种探针都分别提供3种探测方式

• exec 执行命令行检查  如果返回值为0，则认为容器健康。
  
• httpGet  HTTP请求检查  如果状态码为200~400之间，则认为容器健康
  
• tcpSocket TCP端口检查  如果端口是通的就认为容器健康。
  

由于项目使用SpringBoot 2.2.6项目 就自然使用到了spring-boot-starter-actuator包，注意 这里不同的Boot版本有点区别 如1.x，2.2.x和2.3 配置暴露指标的访问有些不一样。
springboot2.3+版本 还有提供 可读就绪指标/actuator/health/readiness   和 存活指标/actuator/health/liveness接口 可以直接分别用于kubernetes的就绪探针和存活探针。由于这里使用的2.2.6就都使用/actuator/health指标。

1. <dependency>
2.     <groupId>org.springframework.boot</groupId>
3.     <artifactId>spring-boot-starter-actuator</artifactId>
4. </dependency>

复制代码

配置暴露health指标

1. management.endpoints.web.base-path=/actuator
2. management.endpoints.web.exposure.include=health

复制代码

配置启动探针检查  理论是只有应用启动成功之后 才能对外提供服务 所以配置了httpGet探针来探测容器内 ip:port/actuator/health地址 如能成功返回200则认为是启动成功。

1. startupProbe:  # 启动探针
2.   httpGet:
3.     path: /actuator/health
4.     port: 8080
5.   initialDelaySeconds: 10
6.   periodSeconds: 10
7.   timeoutSeconds: 5
8.   successThreshold: 1
9.   failureThreshold: 30

复制代码

这里额外配置了一些指标参数。三种探针 startupProbe 、livenessProbe、readinessProbe 都是一样的配置 这也是kubernetes在健康检查的配置上做得比较优秀的地方。

• periodSeconds  检查周期(s) 多少秒去检查一次
  
• initialDelaySeconds 延迟时间 (s) pod启动后 延迟多少时间 (s)后再去检查
  
• timeoutSeconds 超时时间 (s)  访问探测方式的超时时间  如上面访问 ip:port/actuator/health如果5秒还没有返回则认为是超时失败。
  
• successThreshold 成功阈值 (次数)  默认情况下 只要有1次访问成功 就算成功
  
• failureThreshold  最大失败次数 如上面配置的30次  30次都尝试都失败就表示Pod启动失败。这里可以配合periodSeconds参数来控制某些程序启动耗费时间太长的问题 如上面配置30*10=300s都没有成功的话 就失败。
  

配置存活探针 其目的是为了探测保证程序假死的情况

1. livenessProbe:                 # 存活探针
2.   httpGet:
3.     path: /actuator/health
4.     port: 8080
5.   initialDelaySeconds: 10
6.   periodSeconds: 10
7.   timeoutSeconds: 5
8.   successThreshold: 1
9.   failureThreshold: 10

复制代码

配置就绪探针 其目的是为了探测保证程序随时都可用  如果就绪探针出现不可用的时候 会剔除service中的endpoint的ip port。保证流量只分发到可用的容器中去。

1. readinessProbe:                # 就绪探针
2.   httpGet:
3.       path: /actuator/health
4.       port: 8080
5.   initialDelaySeconds: 10
6.   periodSeconds: 10
7.   timeoutSeconds: 5
8.   successThreshold: 1
9.   failureThreshold: 10

复制代码

这3中探针并不是必须都要配置， 需要视情况配置，如果不配置的情况下 默认按照Pod状态读取。如果Pod状态是成功  那么就认为是存活的、就绪的。
遇到的问题

• 刚开始只配置了存活探针和就绪探针。导致启动的时候  存活探针一直失败达到了重启的条件。就出现一直重启pod的情况。后面加了启动探针 保证启动时间周期内不触发就绪探针。尽可能的配置failureThreshold * periodSeconds 来包容最坏情况下的启动耗时。
  
• 部分服务出现deadline的情况
  context deadline exceeded (Client.Timeout exceeded while awaiting headers) Back-off restarting failed container
  可以把timeoutSeconds 配置调节大几秒钟。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！