K8sPod故障排查，K8s故障自愈原理——

本文目录一览：

• 1、K8S问题排查-UDP频繁发包导致Pod重启后无法接收数据
• 2、当K8s出现问题时,我们可以从哪些方面排查出
• 3、K8S故障检查-Pod处于ContainerCreating状态

K8S问题排查-UDP频繁发包导致Pod重启后无法接收数据

1、首先K8sPod故障排查，构建K8S集群，部署UDP服务并用nc命令模拟客户端频繁发送UDP请求。网络分析显示请求正常到达目标Pod和节点，但Pod重启后接收中断。通过删除Pod构造重启，发现在Pod重启后，流量未按预期到达Pod，而是节点IP。使用iptables跟踪请求路径，发现流量未经过预期路径，而是进入INPUT链，指向DNAT问题。

2、原因K8sPod故障排查： conntrack表项问题：在K8S环境中，通过NodePort暴露K8sPod故障排查的UDP服务在接收到频繁请求时，由于UDP conntrack表项默认老化时间为30秒，频繁请求可能导致老化失效。当Pod重启后，conntrack表中记录的可能是节点IP而非Pod IP，导致后续请求被错误地转发到节点IP而非新的Pod IP。

3、但大约20分钟后，其中一个node的内存持续飙升，导致该节点重启。

4、节点故障 节点网络故障：节点的网络设备出现问题，如网卡损坏、网线松动等，会导致该节点上的Pod无法与外界或其他节点上的Pod通信。例如，节点的物理网卡故障，会使节点无法接收和发送网络数据包，从而影响其上Pod的网络连接。

5、排查逻辑：以“资源限制”为假设，通过监控数据（线程数飙升至46k）和系统参数（pid_max仅49k）的对比，逐步缩小范围，最终锁定全局PID耗尽这一核心问题。解决方案：分短期应急（调整pid_max、重启泄漏Pod）和长期防御（监控强化、K8s资源限制、内核调优），体现“止血-根治-预防”的完整闭环。

当K8s出现问题时,我们可以从哪些方面排查出

1、建议优先检查集群状态和事件日志K8sPod故障排查，再聚焦具体POD或Service的配置与运行状态。

2、当Kubernetes（K8s）集群出现问题时K8sPod故障排查，系统的稳定性和应用程序的可用性可能会受到影响。

3、资源分配与调度问题 资源不足导致应用故障K8sPod故障排查：当k8s集群中资源分配不合理K8sPod故障排查，比如CPU、内存等资源不足时K8sPod故障排查，运行的应用可能会出现性能下降甚至崩溃。例如，某个高负载的应用由于分配的内存不足，频繁出现OOM（Out Of Memory）错误，导致服务不可用。

4、K8s跨节点的网络问题可能由多种因素引起，需要从基础网络连通性、网络插件配置、路由表、ARP表项以及特定网络插件的排查等多个方面进行综合考虑和解决。确认基础网络连通性：确保节点间通过主机IP可以互相通信：使用ping命令检查节点间的连通性，同时检查TCP端口（如8472端口）的连通性，确保没有网络阻塞。

K8S故障检查-Pod处于ContainerCreating状态

1、常见导致pod长时间处于“ContainerCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。

2、在 Cloud 和 Edge 被启动之后，通过如下的命令去检查边缘节点的状态。请确保您创建的边缘节点状态是 ready 。像使用普通k8s一样部署你的应用到edge节点 示例：提示： 目前对于边缘端，必须在 Pod 配置中使用 hostPort，不然 Pod 会一直处于 ContainerCreating 状态。