前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >容器健康检查使用小结

容器健康检查使用小结

原创
作者头像
白鹏飞
修改2022-04-11 16:22:50
6690
修改2022-04-11 16:22:50
举报

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

一 基本原理

(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

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一 基本原理
    • (1)常见的2种probe:Readiness + Liveness
      • (2)核心使用场景
      • 二 配置方式
        • 2.1 三种探测方式
          • 2.2 探测成功
          • 三 最佳实践
            • (1)监听地址配置
              • (2)延迟探测配置
                • (3)监听本地业务
                  • (4)liveness+readyness 双保险
                    • (5)启动日志输出
                    • 四 FAQ
                    • 五 参考资料
                    相关产品与服务
                    容器服务
                    腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
                    领券
                    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档