由于历史项目跑在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
指标。
org.springframework.boot spring-boot-starter-actuator
配置暴露health指标
management.endpoints.web.base-path=/actuatormanagement.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 配置调节大几秒钟。
转载请注明出处。
作者:peachyy
出处:http://www.cnblogs.com/peachyy/
出处:https://peachyy.gitee.io/
出处:https://peachyy.github.io/