容器健康检查使用小结

2022-04-11 16:22:50 浏览数 (4)

本文内容，偏经验总结，非入门指引。建议使用容器技术，有一定理解后再予以阅读，效果更佳。

一 基本原理

（1）常见的2种probe：Readiness Liveness

  • 前者负责探测pod是否Ready。Ready 则加入到 service参加负载均衡，反之不会加入service。具体实践时，查看service 对应的endpoint 即可明确感知.
代码语言：javascript复制
# kubectl get ep *** -n <NameSpace>

假如一个service，对应了2个pod，其中一个ready，另外一个pending。此时，ep 便只有一个端点。

  • 后者负责监测pod是否健康存活。Liveness工作时，基于特定的参数，如延迟探测时间、探测地址、成功失败阈值、超时时间来判断pod 健康状态。健康则忽略，不健康就会重启Pod。
代码语言：javascript复制
#检查重启restart 次数 1
# kubectl get pod ** -n <NameSpace> 

#检查状态码
# kubectl descrie pod ** -n <NameSpace>  
 ……
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    ****
      Started:      Mon, 11 Apr 2022 15:28:35  0800
      Finished:     Mon, 11 Apr 2022 15:28:57  0800
 ……

（2）核心使用场景

Readiness：确保业务启动OK，再加入Service负载均衡。如果不用service，不配也可。

Liveness：确保业务Pod状态正常，能否对外提供服务。避免程序hung 死，或者内部错误导致的程序crash，影响上游请求处理。Pod 状态异常，超过阈值就会被重启。

二 配置方式

2.1 三种探测方式

  • http/https 探测
  • tcp 端口探测
  • exec 命令/脚本探测

具体的参数作用，如initialDelaySeconds、periodSeconds、failureThreshold、timeoutSeconds、successThreshold，可以前往官方文档链接，自行体会，不再赘述。

2.2 探测成功

（1）http/https， 返回码 【200～400），左闭右开，不包括400；

（2）tcp 端口，端口探测畅通;

（3）exec 执行命令，返回码为0；

探测失败，正好是相反，不再赘述。

三 最佳实践

（1）监听地址配置

如非必要，建议业务监听地址为0.0.0.0；很多业务开发模式，会配置为127.0.0.1， 这种一般会探测失败。

（2）延迟探测配置

部分业务启动过程繁琐，加载内容或者配置等待较久，使用默认的probe 配置，往往还没启动Running，Pod就被重启。这种情况，2点建议：

  • 优化业务启动逻辑
  • 配置延迟启动参数 initialDelaySeconds，具体看业务自身状态。

（3）监听本地业务

健康检查，建议是探测当前Pod自身，而非上下游的依赖系统。

比如一个 server http 接口，工作时需要访问下游组件，这种属于业务逻辑关联的，不是很建议使用。

（4）liveness readyness 双保险

场景比较容易理解，略过。

（5）启动日志输出

如果配置了存活探测，建议输出相关的启动日志，标准输出，或者日志文件均可。

后续出现pod 异常，便于分析。

四 FAQ

（1）为什么我的pod 重启？

代码语言：javascript复制
分析要点：
（1）describe pod分析状态码
（2）get ev 看当前事件
（3）get node 看node 状态
（4）logs -p 查看历史pod 日志

（2）为什么探测失败，pod没有重启？

代码语言：javascript复制
分析要点：重点分析probe 配置参数，达到失败阈值才会重启

（3）为什么只有这个pod 重启？

代码语言：javascript复制
分析要点：建议结合FAQ 1 及业务日志综合排查。

（4）Pod没有健康检查，为啥也会重启？

代码语言：javascript复制
分析要点：Node 是否重启，pod 是否crash，ev 、日志都是分析点。

（5）node 重启导致的pod restart

代码语言：javascript复制
略

（6）调试撒手锏

代码语言：javascript复制
分析要点：
（1）手动更新pod 启动命令，如sleep infinity , 保持pod前台运行
（2）exec 进入pod，手动运行业务；
（3）观察业务 端口，http 响应，以及exec 结果
（4）到这一步，基本大部分异常可以处理掉。
（5）以上手段都不行：这种确实有点难搞了，这种一般是要待复现，保留现场，及时上机分析。

五 参考资料

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

https://cloud.tencent.com/developer/article/1690857

容器 kubernetes容器 kubernetes 健康检查 重启 pod

0 人点赞