问题导向&排查
网络诊断
- 连通性测试：使用
ping、nc、telnet等工具测试 Pod 间的网络连通性，或通过curl检查服务端口是否可达。 - NetworkPolicy 检查：确认 NetworkPolicy 规则是否过于严格导致通信阻断，使用
kubectl get netpol查看并分析现有策略。 - CNI 插件排查：检查 CNI 插件（如 Calico、Flannel 等）的日志，排查网络配置或插件自身问题。
存储问题排查
- PVC/PV 状态检查：使用
kubectl get pvc,pv查看PersistentVolumeClaim和PersistentVolume的绑定状态与容量，确认是否存在未绑定、容量不足等问题。 - 存储日志与事件：检查存储插件（如 Local Volume、CSI Driver 等）日志，以及 PVC/PV 的事件信息，查找存储访问异常。
- 数据完整性验证：必要时，直接在宿主机上挂载存储卷，检查数据完整性和一致性。
资源调度与亲和性问题
- 节点资源分析：使用
kubectl top nodes查看节点资源使用情况，判断是否存在资源瓶颈。 - 调度策略检查：确认 Deployments、StatefulSets 等资源的
.spec.template.spec.nodeSelector、.spec.affinity、.spec.tolerations等调度相关字段配置，看是否限制了 Pod 的调度范围。 - kube-scheduler 日志：分析 kube-scheduler 日志，了解调度决策过程，找出影响调度的因素。
认证授权与访问控制
- RBAC 规则审查：使用
kubectl get rolebindings,clusterrolebindings检查角色绑定关系，确保用户或服务账户具有正确的 API 访问权限。 - API Server 访问日志：分析
kube-apiserver-audit.log，跟踪特定用户或账户的 API 请求与响应，排查授权问题。 - 网络代理与认证配置：检查 kubeconfig 文件、API Server 配置及网络代理（如 kube-proxy、ingress-nginx 等）的认证设置，确保访问路径无误。
不管是否初学者，大家一般都可以从现象识别到问题定位，再到深入排查与解决方案制定，形成一套完整的问题解决闭环。随着实践经验的积累，排查效率与解决问题的能力将不断提升。
K8s 常见故障案例
下面再给大家来些经典的故障案例及其排查方法：
故障案例 1：服务间网络通信异常，表现为超时或连接失败
问题点： Kubernetes 集群内不同服务之间的网络通信出现异常，表现为请求超时、连接失败或响应缓慢。
影响范围：
直接影响：服务间依赖关系中断，导致依赖服务的功能不可用或性能下降。间接影响：可能波及整个微服务架构，引发连锁反应，造成系统整体不稳定。
排查方法：
- 验证服务状态： 使用 kubectl get svc 和 kubectl get po 确认涉及的服务和 Pod 是否正常运行。
- 测试网络连通性： 在出现问题的 Pod 内使用 ping、nc 或 curl 等工具测试与目标服务的网络连通性，包括 ClusterIP、NodePort 或 Headless Service 的 DNS 解析。
- 检查 NetworkPolicy 规则： 使用 kubectl get netpol 查看是否有 NetworkPolicy 规则限制了服务间的通信。
- 检查网络插件日志： 检查网络插件（如 Calico、Flannel 等）的日志，寻找可能的网络异常或配置问题。
- 排查 DNS 解析问题： 如果通过服务名访问出现问题，检查内部 DNS 服务（如 CoreDNS）日志，确认服务 DNS 记录是否正确。
故障案例 2：Pod 无法启动，状态持续为 ImagePullBackOff
问题点： Pod 在创建过程中无法成功拉取指定的容器镜像，状态持续显示为 ImagePullBackOff。
影响范围：
- 直接影响：该 Pod 无法启动，对应的服务或应用无法正常运行。
排查方法：
- 查看 Pod 事件： 使用
kubectl describe pod <pod-name>查看 Pod 的详细状态和事件列表，定位到与镜像拉取相关的事件，通常会包含具体的错误信息。 - 验证镜像名称与仓库： 确认提交的 Pod 定义（如 Deployment、StatefulSet 等）中使用的镜像名称、标签和仓库地址是否正确无误，且与实际存在的镜像匹配。
- 检查私有仓库访问： 如果镜像位于私有仓库，确认 Deployment 的 imagePullSecrets 是否已正确配置了仓库访问凭据，以及网络是否允许 Pod 访问仓库。
- 测试镜像拉取： 在集群内其他节点或同一节点上的另一个容器中尝试手动拉取镜像，以排除网络或仓库临时问题。
- 检查镜像仓库状态： 如果镜像仓库位于外部，检查仓库服务的运行状态和日志，确保服务正常且镜像可供下载。
故障案例 3：节点资源压力告警，触发 MemoryPressure 或 DiskPressure
问题点： Kubernetes 节点报告内存或磁盘资源压力，标记节点状态为 NotReady 或应用 MemoryPressure、DiskPressure 污点，导致调度器不再将新 Pod 调度到该节点。
影响范围：
- 直接影响：节点上的现有 Pod 可能因资源不足而性能下降或被系统强制终止。
- 间接影响：集群的整体资源利用率降低，新部署或扩缩容的操作受阻，可能导致服务容量不足或响应延迟。
排查方法：
- 查看节点状态： 使用
kubectl get node查看所有节点状态，重点关注Conditions列中的MemoryPressure和DiskPressure状态。 - 检查资源使用情况： 使用
kubectl top nodes查看节点的实时资源使用率，对比节点的总资源容量，判断是否存在过度消耗。 - 分析资源消耗大户： 使用
kubectl top pods --all-namespaces --sort-by=memory或 ``–sort-by=cpu` 查找占用资源最多的 Pod，分析其资源使用合理性。 - 检查磁盘使用情况： 对于
DiskPressure，使用df -h或du -sh /*（在节点上执行）查看磁盘空间使用情况，定位占用空间大的目录。 - 清理资源或调整策略： 根据分析结果，可能需要清理无用数据、优化 Pod 资源请求/限制、调整日志留存策略、迁移部分工作负载到其他节点等。
故障案例 4：Ingress 资源更新后，外部访问未按预期生效
问题点： 修改或新增 Ingress 资源后，外部客户端通过 Ingress 的域名访问服务时，路由规则、TLS 配置等未按预期更新。
影响范围：
- 直接影响：外部客户端无法访问到最新部署的服务，或访问行为不符合更新后的 Ingress 规则。
- 间接影响：可能影响用户体验、业务流程或数据一致性，特别是在进行版本升级、功能切换等重要变更时。
排查方法：
- 确认 Ingress 更新状态： 使用
kubectl get ingress <ingress-name> -o yaml查看 Ingress 资源的最新配置，确认更新已生效。 - 检查 Ingress Controller 日志： 查看负责处理 Ingress 的控制器（如 Nginx Ingress Controller、Traefik 等）的日志，查找与 Ingress 更新相关的事件和错误。
- 测试内部服务访问： 使用
kubectl exec进入集群内其他 Pod，通过 ClusterIP 或 NodePort 直接访问服务，验证服务本身是否正常。 - 清理缓存或等待传播： 如果涉及 DNS 缓存问题，可能需要等待 DNS 记录在全球范围内更新，或者在客户端手动清理 DNS 缓存后再试。
- 检查负载均衡器配置： 对于云服务商托管的 LoadBalancer 类型 Ingress，检查云平台控制台中负载均衡器的配置是否已同步更新。
故障案例 5：Kubernetes API 服务器响应变慢或不可用
问题点： Kubernetes API 服务器响应时间明显增加，或出现无法连接、请求超时、返回错误等情况。
影响范围：
- 直接影响：所有依赖 Kubernetes API 的操作（如 kubectl 命令、CI/CD 流程、集群自动化管理等）都将受到影响。
- 间接影响：可能导致集群管理困难、应用部署延迟、监控数据丢失、故障响应不及时等问题，严重时可能影响整个系统的稳定运行。
排查方法：
- 检查 API 服务器日志： 查看 API 服务器（kube-apiserver）的日志，查找异常消息、错误或警告，定位可能的问题根源。
- 监控 API 服务器性能指标： 监视 API 服务器的 CPU、内存使用率、请求数、错误率等性能指标，判断是否存在资源瓶颈或异常波动。
- 检查 etcd 状态： API 服务器依赖于 etcd 存储集群状态，使用
etcdctl工具检查 etcd 集群的健康状况和响应时间。 - 排查网络问题： 检查 API 服务器所在节点的网络连接，确认与其他节点及客户端的网络通信是否正常。
- 审查近期变更： 回顾最近对集群进行的配置更改、版本升级、RBAC 规则调整等操作，判断是否引入了导致 API 性能下降的因素。
故障案例 6：Pod 间网络通信时断时续
问题点： Kubernetes 集群内不同 Pod 之间的网络通信出现间歇性中断或延迟严重，时好时坏，无明显规律。
影响范围：
- 直接影响：依赖网络通信的服务或应用可能出现短暂不可用、数据传输失败、请求超时等问题。
- 间接影响：可能导致业务流程中断、数据不一致、用户体验下降，严重时影响整个系统的稳定性和可用性。
排查方案：
- 监控网络流量与延迟： 使用网络监控工具（如 Prometheus + Grafana、Netdata 等）监控 Pod 间的网络流量、丢包率和延迟，观察是否存在周期性波动或异常峰值。
- 深入抓包分析： 在受影响的 Pod 内使用
tcpdump或wireshark抓取网络包进行分析，查找是否存在重传、乱序、RST 包等异常现象。 - 检查网络插件及底层网络设备： 查看网络插件（如 Calico、Flannel 等）的日志，以及宿主机网络设备（如网卡、交换机、路由器等）的状态和日志，排查可能的网络设备故障或配置问题。
- 分析网络拓扑与策略： 使用
kubectl get netpol查看 NetworkPolicy 规则，确认是否存在过于严格的策略导致网络中断。检查网络拓扑结构，看是否存在可能导致路由不稳定的设计问题（如多路径、浮动 IP 等）。 - 排查外部干扰因素： 考虑是否存在外部网络环境变化（如云服务商网络调整、DDoS 攻击、网络维护等）影响集群内通信。如果可能，尝试更换网络环境或时间段观察问题是否重现。
故障案例 7：Kubernetes 控制平面组件间通信异常
问题点： Kubernetes 控制平面组件（如 API 服务器、etcd、控制器管理器、调度器等）之间通信异常，导致集群管理功能受限或失效。
影响范围：
- 直接影响：集群管理功能受限，如无法创建/更新资源、Pod 无法调度、状态更新延迟等。
- 间接影响：可能导致整个集群的稳定性下降，应用无法正常部署、扩展或恢复，数据一致性问题，严重的甚至可能导致集群完全不可用。
排查方案：
- 检查控制平面组件状态： 使用
kubectl get componentstatuses查看控制平面各组件的状态，关注是否有Unhealthy或Unknown的组件。 - 查看控制平面日志： 分别检查 API 服务器、etcd、控制器管理器、调度器等组件的日志，查找与通信异常相关的错误或警告。
- 检查 etcd 集群健康状况： 使用
etcdctl工具检查 etcd 集群的健康状况、成员列表、领导者选举状态等，确认各成员间通信是否正常。 - 检查控制平面网络连接： 使用
netstat、ss或telnet等工具检查控制平面组件之间的网络连接，确认端口是否可达、TCP 连接是否正常。 - 审查控制平面配置： 检查控制平面组件的配置文件（如
/etc/kubernetes/manifests下的静态 Pod 清单），确认 API 服务器的--etcd-servers、控制器管理器和调度器的--master参数等是否正确。
故障案例 8：StatefulSet 中 Pod 无法完成初始化或滚动更新
问题点： StatefulSet 中的 Pod 在创建或滚动更新过程中无法完成初始化，始终处于 Pending 或 ContainerCreating 状态，或反复重启。
影响范围：
- 直接影响：对应 StatefulSet 的服务无法按预期提供完整功能，数据一致性或可用性可能受到影响。
排查方案：
- 查看 Pod 事件与状态： 使用
kubectl describe pod <pod-name>查看 Pod 详细状态和事件列表，定位问题发生的具体阶段和原因。 - 检查存储卷关联与状态： 使用
kubectl get pvc查看 PersistentVolumeClaim（PVC）的状态，确认 PVC 是否已绑定到合适的 PersistentVolume（PV），PV 是否正常。检查 PV 的详细信息，确认其状态、容量、访问模式等是否满足 StatefulSet 的要求。 - 检查存储服务日志与状态： 如果使用的是云服务商提供的存储服务（如 OSS、S3、Disk、NAS 等），检查其控制台或日志，确认存储服务本身无异常。
- 检查应用初始化脚本： 如果 StatefulSet 中的 Pod 在启动时执行了自定义的初始化脚本（如
initContainers），检查这些脚本的逻辑和输出，确认无误。 - 验证存储卷数据完整性： 如果怀疑存储卷数据损坏或不一致导致问题，尝试在其他节点上挂载该 PV，检查数据是否正确。必要时，从备份恢复数据。
故障案例 9：Helm 升级应用后部分功能异常
问题点： 使用 Helm 升级 Kubernetes 应用后，部分功能出现异常，如服务不可用、接口返回错误、数据不一致等。
影响范围：
- 直接影响：升级后的应用无法正常提供全部功能，可能影响用户访问、数据处理、业务流程等。
- 间接影响：可能导致信任度下降、运维复杂度增加、回滚成本增大。
排查方案：
- 对比旧版与新版资源定义： 使用
helm get values <release-name>和helm get manifest <release-name>获取升级前后的资源定义和配置值，对比差异，看是否有误删、误改的关键配置。 - 检查滚动更新策略： 使用
helm get all <release-name>查看 Helm Release 的详细信息，确认滚动更新策略（如maxUnavailable、maxSurge）是否合理，是否可能导致服务中断。 - 检查应用日志与状态： 使用
kubectl logs和kubectl describe查看升级后 Pod 的日志和状态，定位具体出错的服务或组件。 - 验证数据迁移或迁移脚本： 如果升级涉及数据迁移，检查迁移脚本或工具的执行结果，确认数据是否正确迁移。对于有状态应用，确认新旧版本能否正确共享存储。
- 回滚并逐步升级验证： 如果问题难以定位，可先回滚到旧版本，然后逐步升级部分组件或功能，观察问题是否重现，缩小排查范围。
故障案例 10：Kubernetes 集群频繁出现节点 NotReady
问题点： Kubernetes 集群中的节点频繁出现 NotReady 状态，即使自动恢复后不久又再次变为 NotReady。
影响范围：
- 直接影响：节点上运行的 Pod 可能被驱逐，导致服务中断、数据丢失或处理延迟。
- 间接影响：频繁的节点状态变化可能导致调度压力增大、资源利用率降低，影响集群整体稳定性和性能。
排查方案：
- 监控节点资源使用： 使用
kubectl top nodes和第三方监控工具（如 Prometheus + Grafana）持续监控节点的 CPU、内存、磁盘、网络等资源使用情况，查找是否有资源耗尽的迹象。 - 检查节点日志与系统状态： 登录到问题节点，检查系统日志（如
/var/log/messages、/var/log/syslog等）、Docker（或 Containerd）日志、kubelet 日志，查找与节点状态变化相关的错误或警告。 - 排查硬件故障或网络问题： 检查节点的硬件状态（如 CPU、内存、磁盘健康状况），以及网络设备（如网卡、交换机）的状态和日志，看是否存在硬件故障或网络问题。
- 检查节点配置与污点： 使用
kubectl describe node <node-name>查看节点详细信息，确认节点配置（如标签、Taints）是否合理，是否被正确调度。 - 排查系统级软件问题： 检查节点的操作系统、内核、kubelet、Docker（或 Containerd）、CNI 插件等软件版本和配置，确认无已知问题或冲突。必要时，升级到稳定版本或重新安装。