使用 Kubernetes 监控定位 Pod 状态异常根因 | 学习笔记

简介: 快速学习 使用 Kubernetes 监控定位 Pod 状态异常根因

开发者学堂课程【使用 Kubernetes 监控定位 Pod 状态异常根因使用 Kubernetes 监控定位 Pod 状态异常根因】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/951/detail/14763


使用 Kubernetes 监控定位 Pod 状态异常根因


内容介绍

一、     背景介绍

二、     典型场景

三、     最佳实践

 

 

一、背景介绍

说明 Kubernetes Pod 作为 Kubernetes 核心资源对象,不仅 service controller worker 都是围绕着他展开工作,同时它还承担着传统 ID 环境主机的职责.

image.png

Pod 像是机器,容器则是进程所以调度、网络、存储、安全等机器级别的异常以及进程运行的异常都会在Pod上体现出来。那么围绕着 Pod 来说,有以下几个关键的点是非常容易出现问题的:

关键检查点                       关键观测数据    

调度

镜像拉取                         Pod Status 字段

磁盘挂载                         相关事件

Liveless/Readiness probe            日志

postStart/preStop handler           性能指标

配置                             请求链路

运行时


二、典型场景

因为 Pod 具有复杂的生命周期和依赖,绝大多数 Kubernetes 问题都会在 Pod 上表现出来。

1、问题场景一:就绪失败

问题表象

Pod 一直无法到达 Ready 状态,无法接受请求,进行业务处理

image.png

可能根因

资源不足,无法调度( 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

image.png

可能根因

程序异常退出,比如非法访问以及进入了异常状态,一直退出

容器内存使用量超过内存 Limit

3、问题场景三:请求处理错误率高

问题表象

Pod 处理请求的错误率高,比如过去1100次请求,20次都是处理错误

image.png

可能根因

请求量突增,程序自身可能触发流控或者其他异常处理导致请求处理失败率突增

自身代码处理错误,请求量没有变换可能是上线新的功能有漏洞

不可压缩资源不足(磁盘,内存),比如请求处理包含磁盘的写操作,资源不足出现失败

外部依赖服务报错,请求处理需要调用下游服务,能够报错,请求下游处理失败

4、问题场景四:请求处理P95响应时间高

问题表象

Pod 处理请求的 P95响应时间高,比如过去30分钟,有5%的请求耗时都超过了3s,会影响该接口用户的体验

image.png

可能根因

请求量突增,程序自身处理不过来,导致超时

自身代码池化资源不足,比如因为 bug 导致的现增池或者队列满请求处理不过来导致超时

Pod 运行资源不足,请求处理包含 cpu memory io 资源的申请,但是资源不足导致处理慢

外部依赖服务响应时间高,外部依赖服务响应时间高,请求处理需要调用下游服务,响应时间高会导致请求处理慢。

5、问题场景五:内存使用率高

问题表象

Pod 内存使用率高,比如超过80%,这时不仅有 omq 的风险也有被驱逐的风险

image.png

可能根因

自身代码内存泄露

Pod 内存 Request 值偏低,如果该值偏低的情况下配置 HPA 会频繁触发扩容,同时该 Pod 有被节点驱逐的风险

6、问题场景六:内存 OOM

问题表象

Pod 周期性出现内存 OOM 现象,导致重启

image.png

可能根因

自身代码内存泄露;

Pod 内存 Limit 值偏低,容器内存使用量超过 Limti 值会被 OOM 替换掉

7、问题场景七: CPU 使用率高

问题表象

Pod CPU 使用率高,比如超过80%

image.png

可能根因

自身代码效率不足,业务处理时间普查度太高,需要找到热点方法进行优化

Pod CPU Request 值偏低,如果该情况下配置水平扩孔容会触发扩容,并有被节点驱逐的风险

8、问题场景八: CPU Throttled

问题表象

Pod 周期性出现 CPU Throttled 现象,导致请求处理偶现超时

image.png

可能根因

自身代码效率不足,自身代码效率不足,业务处理时时间复杂度太高,需要找到热点方法进行优化。

Pod CPU Limit 值设置太低, cpu 使用量超过该值,对应容器的 cpu 会被 throttle

容器运行时自身 bug , 容器运行时自身问题更具体来说,个别内核版本,即使 cpu 没有超过 limit limit 值的时候,也会对容器进行 cpu throttle 需要关注这种问题。

9、问题场景九: Pod IO

问题表象

Pod 处理文件读写慢,但是磁盘使用率并不高。

image.png

可能根因

自身代码文件读写过于频繁,可以考虑批量化读写

节点本身的 IO 高影响 Pod ,节点的 IO 是共享资源,部分高 IO Pod 可能会影响其他 Pod

 

四、最佳实践

描述如何使用 Kubernetes 监控处理异常场景,快速定位发现对应异常场景的根因

最佳实践一:Pod 的 Kubernetes 状态异常定位

image.png

Kubernetes 监控的 pod 详情页面包含了 pod 相关的 cubulence 信息,比如事件、conditions、日志界面以及终端能力,能够快速帮助定位异常场景一和异常场景二的根因。

最佳实践二:Pod 的错慢请求分析

image.png

Kubernetes 监控的 pod 详情页包含了该 pod 作为服务端的性能监控,可以快速发现错慢趋势。对于错慢请求,存储了明细,包含了请求和响应信息、整体耗时以及请求接收请求处理和响应的分段耗时能够帮助快速定位错在哪,慢在哪,能够快速帮助定位异常场景三和异常场景式四的根因。

最佳实践三:Pod 的资源消耗分析    

image.png

Kubernetes 监控详情页包含了该 pod 的资源消耗以及特定容器的资源申请。失败监控可以看到哪些容器资源消耗得多,将会加关注,帮助回答哪个方法占用 cpu 比较多,哪个对象占用内存比较多。与此同时,详情页还包含了关联load 的资源消耗情况,能够快速帮助定位异常场景五到九的根因

最佳实践四:Pod 到外部服务的请求性能分析

image.png

Kubernetes 监控的拓扑页面会展示集群节点到外部服务以及集群节点之间的请求关系,点击请求关系可以快速查看特定节点到特定外部服务的请求性能,可以快速定位下游问题,帮助解决异常场景三四的根因

最佳实践五:Pod 到外部服务的网络性能分析

image.png

Kubernetes 监控在监控的拓扑页面,会展示集群节点到外部服务以及集群节点之间的网络关系。点击网络关系可以快速查看特定节点到特定外部服务的网络,包含包重传数以及包传输的 RTT,可以快速帮助

定位网络和下游问题,解决异常场景三四的根因。

介绍 Kubernetes 监控支持以上最佳实践的产品能力

image.png

进入 Kubernetes 监控 Pod 的详情页面,在这里包含了 Kubernetes 资源信息,包含查看 YAML、查看日志和进入终端。

在下面可以看到它的 container 列表以及最核心的 conditions,并且点击 container 可以进到特定的 container,查看的相关的信息.与此同时可以看到 Pod 还具备性能监控。

image.png

对于错慢的请求,我们保留明细,点击错误数的明细列表可以看到相应的请求和返回码以及整体耗时和分段耗时资源。

关于资源消耗层面可以看到该 Pod 的资源使用量,Cpu 和内存,以及请求量和线质量。对于 container 来说,可以查看 cpu throttle 和内存申请失败的情况。

image.png

再进行 top 页面,我们可以查看特定的节点之间的关系。可以搜索一个节点,查看它的上下游,我们可以关注它和特定的卡不卡服务的关系,可以看到耗时和请求数。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
6月前
|
Kubernetes Docker 容器
Kubernetes与Docker参数对照:理解Pod中的command、args与Dockerfile中的CMD、ENTRYPOINT。
需要明确的是,理解这些都需要对Docker和Kubernetes有一定深度的理解,才能把握二者的区别和联系。虽然它们都是容器技术的二个重要组成部分,但各有其特性和适用场景,理解它们的本质和工作方式,才能更好的使用这些工具,将各自的优点整合到生产环境中,实现软件的快速开发和部署。
205 25
|
6月前
|
Prometheus Kubernetes 监控
Kubernetes监控:Prometheus与AlertManager结合,配置邮件告警。
完成这些步骤之后,您就拥有了一个可以用邮件通知你的Kubernetes监控解决方案了。当然,所有的这些配置都需要相互照应,还要对你的Kubernetes集群状况有深入的了解。希望这份指南能帮助你创建出适合自己场景的监控系统,让你在首次发现问题时就能做出响应。
299 22
|
10月前
|
Prometheus Kubernetes 监控
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
|
6月前
|
Kubernetes Shell Windows
【Azure K8S | AKS】在AKS的节点中抓取目标POD的网络包方法分享
在AKS中遇到复杂网络问题时,可通过以下步骤进入特定POD抓取网络包进行分析:1. 使用`kubectl get pods`确认Pod所在Node;2. 通过`kubectl node-shell`登录Node;3. 使用`crictl ps`找到Pod的Container ID;4. 获取PID并使用`nsenter`进入Pod的网络空间;5. 在`/var/tmp`目录下使用`tcpdump`抓包。完成后按Ctrl+C停止抓包。
213 12
|
10月前
|
存储 Kubernetes Docker
【赵渝强老师】Kubernetes中Pod的基础容器
Pod 是 Kubernetes 中的基本单位,代表集群上运行的一个进程。它由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。基础容器负责维护 Pod 的网络空间,对用户透明。文中附有图片和视频讲解,详细介绍了 Pod 的组成结构及其在网络配置中的作用。
173 1
【赵渝强老师】Kubernetes中Pod的基础容器
|
10月前
|
运维 Kubernetes Shell
【赵渝强老师】K8s中Pod的临时容器
Pod 是 Kubernetes 中的基本调度单位,由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。临时容器用于故障排查和性能诊断,不适用于构建应用程序。当 Pod 中的容器异常退出或容器镜像不包含调试工具时,临时容器非常有用。文中通过示例展示了如何使用 `kubectl debug` 命令创建临时容器进行调试。
177 1
|
10月前
|
Kubernetes 调度 容器
【赵渝强老师】K8s中Pod中的业务容器
Pod 是 Kubernetes 中的基本调度单元,由一个或多个容器组成。除了业务容器,Pod 还包括基础容器、初始化容器和临时容器。本文通过示例介绍如何创建包含业务容器的 Pod,并提供了一个视频讲解。示例中创建了一个名为 "busybox-container" 的业务容器,并使用 `kubectl create -f firstpod.yaml` 命令部署 Pod。
136 1
|
4月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
155 9
|
4月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
本文介绍如何利用阿里云的分布式云容器平台ACK One的多集群应用分发功能,结合云效CD能力,快速将单集群CD系统升级为多集群CD系统。通过增加分发策略(PropagationPolicy)和差异化策略(OverridePolicy),并修改单集群kubeconfig为舰队kubeconfig,可实现无损改造。该方案具备多地域多集群智能资源调度、重调度及故障迁移等能力,帮助用户提升业务效率与可靠性。
|
6月前
|
存储 Kubernetes 监控
K8s集群实战:使用kubeadm和kuboard部署Kubernetes集群
总之,使用kubeadm和kuboard部署K8s集群就像回归童年一样,简单又有趣。不要忘记,技术是为人服务的,用K8s集群操控云端资源,我们不过是想在复杂的世界找寻简单。尽管部署过程可能遇到困难,但朝着简化复杂的目标,我们就能找到意义和乐趣。希望你也能利用这些工具,找到你的乐趣,满足你的需求。
610 33

推荐镜像

更多