Pod异常问题排查SOP - 容器服务 Kubernetes 版 ACK

本文介绍关于Pod异常问题排查的诊断流程、排查方法、常见问题及对应的解决方案。

说明

如果您需要了解排查Pod问题常用的控制台界面，例如如何查看Pod状态、基础信息、配置、事件和日志，使用终端进入容器，启用Pod故障诊断等，可跳转至常用排查界面了解。

诊断流程

如果Pod状态异常，可通过查看Pod的事件、Pod的日志、Pod的配置等信息确定异常原因。大体排查流程如下。

阶段一：调度问题

Pod未调度到节点

如果Pod长时间处于“未调度到节点”（Pending）状态，没有被安排到任何节点上运行，可能是出于以下原因。

报错信息	说明	推荐的解决方案
`no nodes available to schedule pods.`	当前集群中无可用节点可供调度。	查看集群节点状态是否为NotReady。如果存在节点处于NotReady状态，则对问题节点进行检查和修复。检查Pod中是否声明了nodeSelector、nodeAffinity或污点容忍。若不存在亲和性策略，可以增加节点池中的节点数量。
`0/x nodes are available: x Insufficient cpu.` `0/x nodes are available: x Insufficient memory.`	集群中没有可用节点能够满足Pod所需的CPU或内存资源。	在节点页面查看容器组、CPU、内存的使用情况，确定集群的资源使用率。说明当某个节点的CPU和内存利用率维持在较低水平时，即便引入一个新Pod不会立即达到资源使用的上限，调度器也会谨慎考虑，以防该Pod的加入导致未来高峰时段节点资源紧张，避免因资源分配不当而引发的节点资源短缺问题。若集群中的CPU或内存已经耗尽，可参考如下方法处理。删除或减少不必要的Pod，请参见管理容器组（Pod）。根据自身业务情况，调整Pod的资源配置，请参见设置容器的CPU和内存资源上下限。您可以启用资源画像，获得容器Request和Limit的推荐配置。根据Pod声明的亲和性策略在集群中添加新的节点，请参见创建节点池。升配节点，请参见升配Worker节点的资源。
`x node(s) didn't match node selector.` `x node(s) didn't match pod affinity/anti-affinity.`	集群现有节点没有匹配Pod声明的节点亲和性（nodeSelector）要求或Pod亲和性（podAffinity和podAnitiAffinity）要求。	检查并调整Pod的节点亲和性策略，包括节点标签、nodeSelector、nodeAffinity、污点和容忍等。检查并调整Pod的Pod亲和性策略，评估节点是否满足Pod的亲和性要求：如果Pod配置了podAffinity，则需要检查目标节点上是否有匹配的Pod存在；如果配置了podAntiAffinity，则需确认目标节点上没有不应共存的Pod。
`0/x nodes are available: x node(s) had volume node affinity conflict.`	Pod所使用的存储卷与待调度的节点之间存在亲和性冲突，云盘无法跨可用区挂载，导致调度失败。	若为静态PVC，希望Pod能够调度到与PV所在相同可用区的节点，需配置Pod的节点亲和性。若为动态PVC，需设置StorageClass的云盘的绑定模式为WaitForFirstConsumer，以便PV等到Pod已调度到节点后再创建，确保云盘被创建在Pod实际运行的节点所在的可用区。
`InvalidInstanceType.NotSupportDiskCategory`	ECS实例不支持挂载的云盘类型。	请参见实例规格族确认当前ECS支持的云盘类型。挂载时，将云盘类型更新为ECS实例当前支持的类型。
`0/x nodes are available: x node(s) had taints that the pod didn't tolerate.`	需要调度的节点打上了污点，不允许Pod调度到该节点上。	如果污点是由您手动添加，您可以删除非预期的污点。如果无法删除污点，可以为Pod配置相应的容忍，请参见污点和容忍、管理节点污点。如果污点为系统自动添加，您可以参见下文解决对应的问题，并等待Pod重新调度。展开查看系统自行添加的污点 `node.kubernetes.io/not-ready`：节点未准备好，处于NotReady状态。 `node.kubernetes.io/unreachable`：节点控制器访问不到节点，相当于节点状况`Ready` 的值为`Unknown`。 `node.kubernetes.io/memory-pressure`：节点存在内存压力。 `node.kubernetes.io/disk-pressure`：节点存在磁盘压力。 `node.kubernetes.io/pid-pressure`：节点存在PID压力。 `node.kubernetes.io/network-unavailable`：节点网络不可用。 `node.kubernetes.io/unschedulable`：节点不可调度。
`0/x nodes are available: x Insufficient ephemeral-storage.`	节点临时存储容量不足。	检查Pod是否配置了临时存储卷的限制，即Pod YAML中`spec.containers.resources.request.ephemeral-storage`的取值。如果取值过高，超出了节点的实际可用容量，Pod会调度失败。执行`kubectl describe node \| grep -A10 Capacity`命令，查看各个节点上可用于临时存储的总容量。如果容量不足，可扩容节点磁盘或增加节点数量。
`0/x nodes are available: pod has unbound immediate PersistentVolumeClaims.`	Pod绑定PVC失败。	检查Pod所指定的PVC或PV是否已经创建，通过`kubectl describe pvc <pvc-name>` 或 `kubectl describe pv <pv-name>`命令查看PVC、PV的Event信息，进一步进行判断。更多信息，请参见Pod的Event提示0/x nodes are available: x pod has unbound immediate PersistentVolumeClaims。

Pod已调度到节点

如果Pod已经被调度到某个节点上但仍处于Pending状态，请参见下文解决。

判断Pod是否配置了hostPort：如果Pod配置了hostPort，那么每个节点上只能运行一个使用该hostPort的Pod实例。因此，Deployment或ReplicationController中Replicas值不能超过集群中的节点数。如果该端口被其他应用占用，将导致Pod调度失败。
hostPort会带来一些管理和调度上的复杂性，推荐您使用Service来访问Pod，请参见服务（Service）。
如果Pod没有配置hostPort，请参见下方步骤排查。
1. 通过kubectl describe pod <pod-name>命令查看Pod的Event信息，并解决对应的问题。Event可能会解释Pod启动失败的原因，例如镜像拉取失败、资源不足、安全策略限制、配置错误等。
2. Event中没有有效信息时，进一步查看该节点kubelet的日志，进一步排查Pod启动过程中存在的问题。您可以通过grep -i <pod name> /var/log/messages* | less命令搜索系统日志文件（/var/log/messages*）中包含指定Pod名称的日志条目。

阶段二：镜像拉取问题

报错信息	说明	推荐的解决方案
`Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:`	请求访问镜像仓库时被拒绝，创建Pod时未指定`imagePullSecret`。	检查Pod YAML中`spec.template.imagePullSecrets`指定的Secret是否存在。使用ACR时，可以使用免密插件拉取镜像，请参见使用免密组件拉取容器镜像。
`Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host`	通过HTTPS协议从指定的镜像仓库地址拉取镜像时，镜像地址解析失败。	检查Pod YAML中`spec.containers.image`配置的镜像仓库地址是否正确。如有误，需修改为正确地址。如地址无误，进一步验证从Pod所在节点到镜像仓库的网络连接是否通畅。参见ECS远程连接方式概述登录到Pod所在节点，运行cmd命令`curl -kv https://xxxxxx/xxxxx/` 判断地址是否可以访问。如有报错，进一步判断是否存在网络配置、防火墙规则、DNS解析等网络访问问题。
`Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device`	节点磁盘空间不足。	参见ECS远程连接方式概述登录到Pod所在节点，运行`df -h`查看磁盘空间状态。如磁盘已满，请扩容磁盘，请参见步骤一：扩容云盘容量。
`Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority`	第三方仓库使用了非知名或不安全的CA签署的证书。	建议三方仓库更改使用CA签发的证书。如果您使用的是私有镜像仓库，请参见使用私有镜像仓库创建应用。如果无法更改，可酌情参考下面流程，配置允许节点从使用非安全证书的仓库中拉取和推送镜像。建议仅在测试环境中使用，可能会对节点其他Pod的运行产生影响。展开查看详细步骤为containerd创建证书目录，用于存放与特定镜像仓库相关的证书配置文件。 `$ mkdir -p /etc/containerd/cert.d/xxxxx` 配置containerd信任特定的非安全镜像仓库。 `$ cat << EOF > /etc/containerd/cert.d/xxxxx/hosts.toml server = "https://harbor.test-cri.com" [host."https://harbor.test-cri.com"] capabilities = ["pull", "resolve", "push"] skip_verify = true # ca = "/opt/ssl/ca.crt" # 或者上传ca证书 EOF` 修改Docker Daemon配置以添加非安全仓库。 `vi /etc/docker/daemon.json` 添加以下内容。其中需替换`your-insecure-registry`为目标私有仓库地址。 `{ "insecure-registries": ["your-insecure-registry"] }` 重启相关服务，使更新的配置生效。 `systemctl restart systemd systemctl restart docker`
`Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled`	操作取消，可能是由于镜像文件过大。Kubernetes默认存在拉取镜像超时时间，如果一定时间内镜像下载没有任何进度更新，Kubernetes会认为此操作异常或处于无响应状态，主动取消该任务。	检查Pod YAML中配置的`imagePullPolicy`是否为`IfNotPresent`。参见ECS远程连接方式概述登录到Pod所在节点，运行cmd命令`docker pull`或`ctr images pull`判断镜像是否可以被拉取。
`Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`	无法连接镜像仓库，网络不通。	参见ECS远程连接方式概述登录到Pod所在节点，运行cmd命令`curl https://xxxxxx/xxxxx/`判断地址是否可以访问。如有报错，进一步判断是否存在网络配置、防火墙规则、DNS解析等网络访问问题。判断节点的公网策略是否正常，例如SNAT条目、绑定的弹性公网IP等配置。
`Too Many Requests.`	DockerHub对用户拉取容器镜像的请求设定了上限。	将镜像上传至容器镜像服务ACR，从ACR镜像仓库中拉取镜像。
一直显示`Pulling image`	可能触发了kubelet的镜像拉取限流机制。	通过自定义节点池kubelet配置功能调整registryPullQPS（镜像仓库的QPS上限）和registryBurst（突发性镜像拉取的个数上限）。

阶段三：启动问题

Pod处于init状态

错误信息	说明	推荐的解决方案
停留在`Init:N/M`状态	该Pod包含M个Init容器，其中N个已经启动完成，但仍有M-N个Init容器未启动成功。	通过`kubectl describe pod -n <ns> <pod name>`命令查看Pod的事件，确认当前Pod中未启动的Init容器是否存在异常。通过`kubectl logs -n <ns> <pod name> -c <container name>`命令查看Pod中未启动的Init容器的日志，通过日志内容排查问题。查看Pod的配置，例如检查健康检查配置，进一步确认未启动的Init容器配置是否正常。关于Init容器的更多信息，请参见调试Init容器。
停留在`Init:Error`状态	Pod中的Init容器启动失败。
停留在`Init:CrashLoopBackOff`状态	Pod中的Init容器启动失败并处于反复重启状态。

Pod创建中（Creating）

错误信息	说明	推荐的解决方案
`failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx`	Flannel网络插件设计原因，是预期内现象。	升级Flannel组件版本至v0.15.1.11-7e95fe23-aliyun及以上版本，请参见Flannel。
	集群低于1.20版本时，如果发生Pod反复重启、CronJob中的Pod在短时间内完成任务并退出等事件，可能会导致IP地址泄漏。	升级集群版本至1.20及以上，推荐使用最新版本的集群，请参见手动升级集群。
	containerd、runC存在的缺陷。	参见为什么Pod无法正常启动，且报错no IP addresses available in range？进行临时紧急处理。
`error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found`	Pod所在的节点中，Terway网络插件维护的用于追踪和管理网络接口ENI的内部数据库状态与实际的网络设备配置之间存在数据不一致，造成ENI分配失败。	网卡在系统中加载是异步的。在CNI配置过程中，网卡可能仍在加载中，可能导致CNI自动重试。这种情况不会影响ENI最终的分配，请通过Pod最终状态判断操作是否成功。如果Pod长时间没有创建成功，仍然提示上述错误，通常是由于ENI挂载时高阶内存不足导致驱动加载失败。请通过重启ECS实例来解决，请参见重启实例。
`cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded` `cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition`	可能是Terway向vSwitch申请IP时失败。	查看Pod所在节点中Terway组件Pod的Terway容器日志，查看ENI分配过程。执行`kubectl logs -n kube-system <terwayPodName > -c terway \| grep <podName>`命令，查看Terway Pod中Terway网卡的ENI情况，获取到申请IP操作的Request ID以及OpenAPI的报错信息。根据Request ID和报错信息进一步排查失败的原因。

Pod启动失败（CrashLoopBackOff）

错误信息	说明	推荐的解决方案
日志中存在`exit(0)`。		登录异常工作负载所在的节点。执行`docker ps -a \| grep $podName`命令，如果容器中无持续进程，会出现`exit (0)`。
Event信息中存在`Liveness probe failed: Get http…`。	健康检查失败。	核查Pod中所配置的容器健康检查（Liveness Probe）策略是否符合预期，能有效地反映出容器内应用程序的实际运行状况。
Pod日志中存在`no left space`。	磁盘空间不足。	参见步骤一：扩容云盘容量扩容磁盘。清理不必要的镜像，释放磁盘空间，并按需配置imageGCHighThresholdPercent，控制节点上触发镜像垃圾回收（Image GC）的阈值。
启动失败，无Event信息。	Pod中声明的Limit资源少于实际所需资源时，会导致启动容器失败。	检查Pod的资源配置是否正确。您可以启用资源画像，获得容器Request和Limit的推荐配置。
Pod日志中出现`Address already in use`。	同一Pod中的Container端口存在冲突。	检查Pod是否配置了`hostNetwork: true`，这意味着Pod内的容器会直接与宿主机共享网络接口和端口空间。如果无需使用，请改为`hostNetwork: false`。如果Pod需要使用`hostNetwork: true`，请配置Pod的反亲和性，确保同一副本集中的Pod被调度到不通节点。检查并确保不存在也不会有两个或多个具有相同端口需求的Pod运行在同一台节点上。
Pod日志中出现`container init caused \"setenv: invalid argument\"": unknown`。	工作负载中挂载了Secret，但Secret对应的值没有进行Base64加密。	通过控制台创建Secret，Secret对应的值会自动进行Base64加密。具体操作，请参见管理保密字典。通过YAML创建Secret，并执行`echo -n "xxxxx" \| base64`命令手动对密钥值进行Base64加密。
自身业务问题。		查看Pod日志，通过日志内容排查问题。

阶段四：Pod运行问题

OOM

当集群中的容器使用超过其限制的内存，容器可能会被终止，触发OOM（Out Of Memory）事件，导致容器异常退出。关于OOM事件，请参见为容器和Pod分配内存资源。

若被终止的进程为容器的阻塞进程，可能会导致容器异常重启。
若出现OOM异常问题，在控制台的Pod详情页面单击事件页签将展示OOM事件pod was OOM killed。
若集群配置了集群容器副本异常报警，OOM事件出现时会收到相关报警信息，请参见容器服务报警管理。

OOM级别	说明	推荐的解决方案
OS级别	查看Pod所在节点的内核日志`/var/log/messages`，日志中存在Killed Process，但不存在cgroup日志，表明OOM为OS级别。	可能是系统全局内存不足、内存节点的内存不足或内存碎片化时伙伴系统内存不足。关于不同现象可能出现的原因，请参见可能原因；关于问题对应的解决方案，请参见解决方案。
cgroup级别	查看Pod所在节点的内核日志`/var/log/messages`，日志中存在类似`Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx`的报错信息，表明OOM为cgroup级别。	若进程运行状态正常，则根据实际运行需要，适当增大Pod的内存Limit，建议Pod的内存实际使用量不超过内存Limit取值的80%。具体操作，请参见设置容器的CPU和内存资源上下限。您可以启用资源画像，获得容器Request和Limit的推荐配置。

Terminating

可能原因	说明	推荐的解决方案
节点存在异常，处于NotReady状态。		处于NotReady状态的节点恢复正常后会被自动删除。
Pod配置了Finalizers。	如果Pod配置了Finalizers，Kubernetes会在删除Pod之前执行Finalizers指定的清理操作。如果相关的清理操作没有正常响应，Pod将保持在Terminating状态。	通过`kubectl get pod -n <ns> <pod name> -o yaml`查看Pod的Finalizers配置，进一步排查异常原因。
Pod的preStop配置异常。	如果Pod配置了preStop，Kubernetes会在容器被终止之前执行preStop指定的操作。Pod正处于终止流程的preStop阶段时，Pod将处于Terminating状态。	通过`kubectl get pod -n <ns> <pod name> -o yaml`查看Pod的preStop配置，进一步排查异常原因。
Pod配置了优雅退出时间。	如果Pod配置了优雅退出时间（`terminationGracePeriodSeconds`），Pod收到终止命令后（例如`kubectl delete pod <pod_name>`命令）会进入Terminating状态。等待`terminationGracePeriodSeconds`设定的时间后，或容器提前退出后，Kubernetes才认为Pod已经成功关闭。	等待容器优雅退出后，Kubernetes将自动删除Pod。
容器无响应。	发起停止或删除Pod的请求后，Kubernetes会向Pod内的容器发送`SIGTERM`信号。如果容器在终止过程中没有正确响应`SIGTERM`信号，Pod可能会停留在Terminating状态。	使用`kubectl delete pod <pod-name> --grace-period=0 --force`强制删除，释放Pod资源。检查Pod所在节点的containerd或Docker日志，进一步进行排查。

Evicted

可能原因	说明	推荐的解决方案
节点存在资源压力，包括内存不足、磁盘空间不足等，引发kubelet主动驱逐节点上的一个或者多个Pod，以回收节点资源。	可能存在内存压力、磁盘压力、Pid压力等。可以通过`kubectl describe node <node name> \| grep Taints`命令查询。内存压力：带有污点`node.kubernetes.io/memory-pressure`。磁盘压力：带有污点`node.kubernetes.io/disk-pressure`。 Pid压力：带有污点`node.kubernetes.io/pid-pressure`。	内存压力：根据自身业务情况，调整Pod的资源配置，管理容器组（Pod）。升配节点，请参见升配Worker节点的资源。磁盘压力：定时清理节点上的业务Pod日志，防止磁盘空间被耗尽。为节点进行磁盘扩容，请参见步骤一：扩容云盘容量。 Pid压力：根据自身业务情况，调整Pod的资源配置，请参见进程ID约束与预留。
发生了非预期的驱逐行为。	待运行Pod的节点被手动打上了NoExecute的污点，导致出现非预期的驱逐行为。	通过`kubectl describe node <node name> \| grep Taints`命令检查节点是否被打上了NoExecute污点。如是，请删除。
未按照预期流程执行驱逐。	`--pod-eviction-timeout`：当节点宕机时间超过设置时间后，开始驱逐宕机节点上的Pod，默认为5min。 `--node-eviction-rate`：每秒从节点上驱逐的Pod数量。默认为0.1，即每10s至多从一个节点上驱逐Pod。 `--secondary-node-eviction-rate`：第二档的节点驱逐速率。当集群中宕机节点过多时，节点驱逐速率会降低至第二档，默认值为0.01。 `--unhealthy-zone-threshold`：可用区的不健康阈值，默认为0.55，即当宕机的节点数量超过总节点数的55%时，该可用区被判定为不健康。 `--large-cluster-size-threshold`：集群的大规模阈值，默认为50，即当集群节点数量超过50时判定集群为大规模集群。	在小规格的集群（集群节点数小于等于50个节点）中，如果故障的节点大于总节点数的55%，实例的驱逐会被停止，更多信息请参见节点驱逐速率限制。
未按照预期流程执行驱逐。		在大规模集群中（集群节点数大于50），如果集群中不健康的节点数量占总节点数的比例超过了预设的阈值`--unhealthy-zone-threshold`（默认为0.55），驱逐速率由`--secondary-node-eviction-rate`控制（代表每分钟驱逐节点上Pod的最大比例），默认值为0.01。更多信息，请参见节点驱逐速率限制。
容器被驱逐后仍然频繁调度到原节点。	节点驱逐容器时会根据节点的资源使用率进行判断，而容器的调度规则是根据节点上的“资源分配量”进行判断，被驱逐的Pod有可能被再次调度到这个节点，从而出现频繁调度到原节点的现象。	根据集群节点的可分配资源检查Pod的资源Request请求配置是否合理。如需调整，请参见设置容器的CPU和内存资源上下限。您可以启用资源画像，获得容器Request和Limit的推荐配置。

Completed

Completed状态下，Pod中容器的启动命令已执行完毕，容器中的所有进程均已成功退出。Completed状态通常适用于Job、Init容器等。

其他常见问题

Pod状态为Running但没正常工作

如果您的业务YAML存在问题，Pod可能会处于Running状态但没有正常工作。您可以参见以下流程解决。

查看Pod的配置，确定Pod中容器的配置是否符合预期。
使用以下方法，排查环境变量中的某一个Key是否存在拼写错误。
创建Pod时，如果环境变量中的某个Key拼写错误（例如将command拼写为commnd），集群会忽略该错误并使用该YAML成功创建资源。但在容器运行过程中，系统无法执行YAML文件中指定的命令。
下文以command拼写成commnd为例，介绍拼写问题的排查方法。
1. 在执行kubectl apply -f命令前为其添加--validate，然后执行kubectl apply --validate -f XXX.yaml 命令。
  如拼写存在错误，会提示报错XXX] unknown field: commnd XXX] this may be a false alarm, see https://gXXXb.XXX/6842pods/test。
2. 执行以下命令，将输出结果的pod.yaml与您创建Pod使用的YAML进行对比。
  说明
  [$Pod]为异常Pod的名称，您可以通过kubectl get pods命令查看。
```
  kubectl get pods [$Pod] -o yaml > pod.yaml
```
  - pod.yaml文件比您创建Pod所使用的文件行数更多，表明已创建的Pod符合预期。
  - 如果您创建Pod的YAML代码行不存在于pod.yaml文件中，表明YAML中存在拼写问题。
查看Pod的日志，通过日志内容排查问题。
通过终端进入容器，查看容器内的本地文件是否符合预期。

Pod访问数据库概率性网络断联

针对ACK集群中Pod访问数据库有概率性网络断联的问题，可以按照以下步骤进行排查。

1、检查Pod

查看目标集群中该Pod的事件记录，检查是否存在连接不稳定的异常事件，例如网络异常、重启事件、资源不足等。
查看Pod的日志输出，确定是否有与数据库连接相关的错误信息，例如超时、认证失败或者重连机制触发等。
查看Pod的CPU和内存使用情况，避免资源耗尽导致应用程序或数据库驱动程序异常退出。
查看Pod的资源Request和Limit配置，确保Pod分配了足够的CPU和内存资源。

2、检查节点

查看节点的资源使用情况，确认是否有内存、磁盘等资源不足等情况。具体操作，请参见监控节点。
测试节点到与目标数据库之间是否出现概率性网络断联。

3、检查数据库

检查数据库的状态和性能指标，是否出现重启或性能瓶颈。
查看异常连接数和连接超时设置，并根据业务需求进行调整。
检查日志数据库是否有相关断开连接的日志。

4、检查集群组件状态

集群组件异常会影响Pod与集群内其他组件的通信。使用如下命令，检查ACK集群组件状态。

kubectl get pod -n kube-system  # 查看组件Pod状态。

同时检查网络组件：

CoreDNS组件：检查组件状态和日志，确保Pod能正常解析数据库服务的地址。
Flannel插件：查看kube-flannel组件的状态和日志。
Terway插件：查看terway-eniip组件的状态和日志。

5、分析网络流量

您可以使用 tcpdump 来抓包并分析网络流量，以帮助定位问题的原因。

使用以下命令确定数据库连接断开问题发生在哪个Pod和哪个节点上。
```
kubectl  get pod -n [namespace] -o wide 
```

登录到目标节点，请参见ECS远程连接方式概述。

使用以下命令，分别获取不同版本的容器进程PID。

containerd（1.22以上集群）

执行以下命令查看容器CONTAINER。

crictl ps |grep <Pod名称关键字>

预期输出：

CONTAINER           IMAGE               CREATED             STATE                      
a1a214d2*****       35d28df4*****       2 days ago          Running

使用CONTAINER ID参数，执行以下命令查看容器PID

crictl inspect  a1a214d2***** |grep -i PID

预期输出：

    "pid": 2309838,    # 目标容器的PID进程号。
            "pid": 1
            "type": "pid"

Docker（1.22及以下集群）

执行以下命令查看容器CONTAINER ID。

docker ps |grep <pod名称关键字>

预期输出：

CONTAINER ID        IMAGE                  COMMAND     
a1a214d2*****       35d28df4*****          "/nginx

使用CONTAINER ID参数，执行以下命令查看容器PID。

docker inspect  a1a214d2***** |grep -i PID

预期输出：

            "Pid": 2309838,  # 目标容器的PID进程号。
            "PidMode": "",
            "PidsLimit": null,

执行抓包命令。
使用获取到的容器PID，执行以下命令，捕获Pod与目标数据库之间的网络通信数据包。
```
nsenter -t <容器PID> tcpdump -i any -n -s 0 tcp and host <数据库IP地址> 
```
使用获取到的容器PID，执行以下命令，捕获Pod与宿主机之间的网络通信数据包。
```
nsenter -t <容器PID> tcpdump -i any -n -s 0 tcp and host <节点IP地址>
```
执行以下命令，捕获宿主机与数据库之间的网络通信数据包。
```
tcpdump -i any -n -s 0 tcp and host <数据库IP地址> 
```

6、优化业务应用程序

在业务应用程序中实现数据库连接的自动重连机制，确保数据库发生切换或迁移时，应用程序能够自动恢复连接，无需人工干预。
使用持久化的长连接而非短连接来与数据库通信。长连接能显著降低性能损耗和资源消耗，提高系统整体效率。

常用排查界面

您可以登录容器服务管理控制台，进入集群的详情页面，排查Pod可能存在的问题。

操作	控制台界面
检查Pod的状态	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择工作负载 > 容器组。在容器组页面左上角选择Pod所在的命名空间，查看Pod状态。若状态为Running，表明Pod运行正常。若状态不为Running，表明Pod状态异常，请参见本文处理。
检查Pod的基础信息	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择工作负载 > 容器组。在容器组页面左上角选择Pod所在的命名空间，然后单击目标Pod名称或者目标Pod右侧操作列下的详情，查看Pod的名称、镜像、Pod IP、所在节点等详细信息。
检查Pod的配置	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择工作负载 > 容器组。在容器组页面左上角选择Pod所在的命名空间，然后单击目标Pod名称或者目标Pod右侧操作列下的详情。在Pod详情页面右上角单击编辑，查看Pod的YAML文件和详细配置。
检查Pod的事件	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择工作负载 > 容器组。在容器组页面左上角选择Pod所在的命名空间，然后单击目标Pod名称或者目标Pod右侧操作列下的详情。在Pod详情页面下方单击事件页签，查看Pod的事件。说明 Kubernetes默认保留最近1小时的事件，若需保存更长时间的事件，请参见创建并使用K8s事件中心。
查看Pod的日志	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择工作负载 > 容器组。在容器组页面左上角选择Pod所在的命名空间，然后单击目标Pod名称或者目标Pod右侧操作列下的详情。在Pod详情页面下方单击日志页签，查看Pod的日志。说明 ACK集群集成了日志服务SLS。您可在集群中启用SLS，快速采集集群的容器日志，请参见通过DaemonSet采集Kubernetes容器文本日志。
检查Pod的监控	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择运维管理 > Prometheus 监控。在Prometheus监控页面，单击集群监控概览页签，选择查看Pod的CPU、内存、网络I/O等监控大盘。说明 ACK集群集成了阿里云Prometheus。您可以在集群中快速启用阿里云Prometheus，以实时监控集群和容器的健康状况，并查看可视化的Grafana监控数据大盘，请参见使用阿里云Prometheus监控。
使用终端进入容器，进入容器内部查看本地文件等信息	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择工作负载 > 容器组。在容器组页面，单击目标容器组右侧操作列下的终端。
启用Pod故障诊断	在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择工作负载 > 容器组。在容器组页面，单击目标容器组右侧操作列下的诊断，对该容器组进行故障诊断，根据诊断结果解决问题。说明容器智能运维平台提供了一键故障诊断能力，辅助您定位集群中出现的问题，请参见使用集群诊断。