开发者学堂课程【使用 Kubernetes 监控定位 Pod 状态异常根因：使用 Kubernetes 监控定位 Pod 状态异常根因】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/951/detail/14763
使用 Kubernetes 监控定位 Pod 状态异常根因
内容介绍
一、 背景介绍
二、 典型场景
三、 最佳实践
一、背景介绍
说明 Kubernetes Pod 作为 Kubernetes 核心资源对象，不仅 service controller worker 都是围绕着他展开工作，同时它还承担着传统 ID 环境主机的职责.
Pod 像是机器,容器则是进程所以调度、网络、存储、安全等机器级别的异常以及进程运行的异常都会在Pod上体现出来。那么围绕着 Pod 来说，有以下几个关键的点是非常容易出现问题的:
关键检查点 关键观测数据
调度
镜像拉取 Pod Status 字段
磁盘挂载 相关事件
Liveless/Readiness probe 日志
postStart/preStop handler 性能指标
配置 请求链路
运行时
二、典型场景
因为 Pod 具有复杂的生命周期和依赖，绝大多数 Kubernetes 问题都会在 Pod 上表现出来。
1、问题场景一：就绪失败
问题表象
Pod 一直无法到达 Ready 状态，无法接受请求，进行业务处理
可能根因
资源不足，无法调度( Pending ),集群的漏斗没有预留资源满足 Pod 的 request
镜像拉取失败(ImagePullBackoff )
磁盘挂载失败( Pending ),比如容器挂载的 puvc 并没有 Pend 特定的 pv
Liveless probe 探针失败,导致频繁重启
Readiness probe 探针失败，无法达到r eady,接受业务请求
postStart 执行失败，一直无法进入状态
运行时程序崩溃( CrashLoopBackOff )，频繁重启
配置错误,比如挂载的 Volume 不存在( RunContainerError)，导致容器运行错误
2、问题场景二：频繁重启（过去24小时重启次数＞=2）
问题表象：Pod 频繁重启，过去24小时 restart 次数＞=2
可能根因
程序异常退出，比如非法访问以及进入了异常状态，一直退出
容器内存使用量超过内存 Limit 量
3、问题场景三：请求处理错误率高
问题表象
Pod 处理请求的错误率高，比如过去1秒100次请求,20次都是处理错误
可能根因
请求量突增，程序自身可能触发流控或者其他异常处理导致请求处理失败率突增
自身代码处理错误，请求量没有变换可能是上线新的功能有漏洞
不可压缩资源不足(磁盘，内存)，比如请求处理包含磁盘的写操作，资源不足出现失败
外部依赖服务报错，请求处理需要调用下游服务，能够报错，请求下游处理失败
4、问题场景四:请求处理P95响应时间高
问题表象
Pod 处理请求的 P95响应时间高，比如过去30分钟，有5%的请求耗时都超过了3s，会影响该接口用户的体验
可能根因
请求量突增，程序自身处理不过来，导致超时
自身代码池化资源不足，比如因为 bug 导致的现增池或者队列满请求处理不过来导致超时
Pod 运行资源不足，请求处理包含 cpu 、memory 、io 资源的申请，但是资源不足导致处理慢
外部依赖服务响应时间高，外部依赖服务响应时间高，请求处理需要调用下游服务，响应时间高会导致请求处理慢。
5、问题场景五:内存使用率高
问题表象
Pod 内存使用率高，比如超过80%，这时不仅有 omq 的风险也有被驱逐的风险
可能根因
自身代码内存泄露
Pod 内存 Request 值偏低，如果该值偏低的情况下配置 HPA 会频繁触发扩容，同时该 Pod 有被节点驱逐的风险
6、问题场景六:内存 OOM
问题表象
Pod 周期性出现内存 OOM 现象，导致重启
可能根因
自身代码内存泄露;
Pod 内存 Limit 值偏低，容器内存使用量超过 Limti 值会被 OOM 替换掉
7、问题场景七: CPU 使用率高
问题表象
Pod CPU 使用率高，比如超过80%
可能根因
自身代码效率不足，业务处理时间普查度太高，需要找到热点方法进行优化
Pod CPU Request 值偏低，如果该情况下配置水平扩孔容会触发扩容，并有被节点驱逐的风险
8、问题场景八: CPU Throttled
问题表象
Pod 周期性出现 CPU Throttled 现象，导致请求处理偶现超时
可能根因
自身代码效率不足，自身代码效率不足，业务处理时时间复杂度太高，需要找到热点方法进行优化。
Pod CPU Limit 值设置太低, cpu 使用量超过该值，对应容器的 cpu 会被 throttle
容器运行时自身 bug , 容器运行时自身问题更具体来说，个别内核版本，即使 cpu 没有超过 limit limit 值的时候，也会对容器进行 cpu throttle 需要关注这种问题。
9、问题场景九: Pod IO 高
问题表象
Pod 处理文件读写慢，但是磁盘使用率并不高。
可能根因
自身代码文件读写过于频繁,可以考虑批量化读写
节点本身的 IO 高影响 Pod ,节点的 IO 是共享资源，部分高 IO 的 Pod 可能会影响其他 Pod
四、最佳实践
描述如何使用 Kubernetes 监控处理异常场景，快速定位发现对应异常场景的根因
最佳实践一：Pod 的 Kubernetes 状态异常定位
Kubernetes 监控的 pod 详情页面包含了 pod 相关的 cubulence 信息，比如事件、conditions、日志界面以及终端能力，能够快速帮助定位异常场景一和异常场景二的根因。
最佳实践二：Pod 的错慢请求分析
Kubernetes 监控的 pod 详情页包含了该 pod 作为服务端的性能监控，可以快速发现错慢趋势。对于错慢请求，存储了明细，包含了请求和响应信息、整体耗时以及请求接收请求处理和响应的分段耗时能够帮助快速定位错在哪，慢在哪，能够快速帮助定位异常场景三和异常场景式四的根因。
最佳实践三：Pod 的资源消耗分析
Kubernetes 监控详情页包含了该 pod 的资源消耗以及特定容器的资源申请。失败监控可以看到哪些容器资源消耗得多，将会加关注，帮助回答哪个方法占用 cpu 比较多，哪个对象占用内存比较多。与此同时，详情页还包含了关联load 的资源消耗情况，能够快速帮助定位异常场景五到九的根因
最佳实践四：Pod 到外部服务的请求性能分析
Kubernetes 监控的拓扑页面会展示集群节点到外部服务以及集群节点之间的请求关系，点击请求关系可以快速查看特定节点到特定外部服务的请求性能，可以快速定位下游问题，帮助解决异常场景三四的根因
最佳实践五：Pod 到外部服务的网络性能分析
Kubernetes 监控在监控的拓扑页面，会展示集群节点到外部服务以及集群节点之间的网络关系。点击网络关系可以快速查看特定节点到特定外部服务的网络，包含包重传数以及包传输的 RTT，可以快速帮助
定位网络和下游问题，解决异常场景三四的根因。
介绍 Kubernetes 监控支持以上最佳实践的产品能力
进入 Kubernetes 监控 Pod 的详情页面，在这里包含了 Kubernetes 资源信息，包含查看 YAML、查看日志和进入终端。
在下面可以看到它的 container 列表以及最核心的 conditions，并且点击 container 可以进到特定的 container,查看的相关的信息.与此同时可以看到 Pod 还具备性能监控。
对于错慢的请求，我们保留明细，点击错误数的明细列表可以看到相应的请求和返回码以及整体耗时和分段耗时资源。
关于资源消耗层面可以看到该 Pod 的资源使用量，Cpu 和内存，以及请求量和线质量。对于 container 来说，可以查看 cpu 的 throttle 和内存申请失败的情况。
再进行 top 页面，我们可以查看特定的节点之间的关系。可以搜索一个节点，查看它的上下游，我们可以关注它和特定的卡不卡服务的关系,可以看到耗时和请求数。
