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，则认为容器健康。
[*]httpGetHTTP请求检查如果状态码为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指标。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>配置暴露health指标
management.endpoints.web.base-path=/actuator
management.endpoints.web.exposure.include=health配置启动探针检查理论是只有应用启动成功之后 才能对外提供服务 所以配置了httpGet探针来探测容器内 ip:port/actuator/health地址 如能成功返回200则认为是启动成功。
startupProbe:# 启动探针
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
successThreshold: 1
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都没有成功的话 就失败。
配置存活探针 其目的是为了探测保证程序假死的情况
livenessProbe: # 存活探针
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 10配置就绪探针 其目的是为了探测保证程序随时都可用如果就绪探针出现不可用的时候 会剔除service中的endpoint的ip port。保证流量只分发到可用的容器中去。
readinessProbe: # 就绪探针
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 10这3中探针并不是必须都要配置， 需要视情况配置，如果不配置的情况下 默认按照Pod状态读取。如果Pod状态是成功那么就认为是存活的、就绪的。
遇到的问题
[*]刚开始只配置了存活探针和就绪探针。导致启动的时候存活探针一直失败达到了重启的条件。就出现一直重启pod的情况。后面加了启动探针 保证启动时间周期内不触发就绪探针。尽可能的配置failureThreshold * periodSeconds 来包容最坏情况下的启动耗时。
[*]部分服务出现deadline的情况
context deadline exceeded (Client.Timeout exceeded while awaiting headers) Back-off restarting failed container
可以把timeoutSeconds 配置调节大几秒钟。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]