分享
获课地址:xingkeit.top/15462/
在 Kubernetes(K8s)成为云原生基础设施标配的今天,运维人员和开发工程师几乎每天都会与各类"Pod 卡住""服务不通""节点失联"等问题打交道。虽然 K8s 提供了强大的自动化能力,但其分布式、多组件、声明式的特点也带来了复杂的故障面。掌握一套高效、结构化的排障思路,比死记命令更重要。本文聚焦 19 个企业环境中最高频的 K8s 故障场景,结合命令行工具的使用逻辑与底层原理,提炼出可快速复用的"秒解"方法论——不贴代码,只讲思路与判断路径。
一、Pod 相关故障
1. Pod 一直处于 Pending 状态
核心思路:资源或调度条件未满足。
排查路径:
查看 Pod 事件(Events),重点检查是否因 CPU/内存不足、节点污点(Taint)无对应容忍(Toleration)、持久卷(PV)未绑定、或节点选择器(NodeSelector)不匹配导致无法调度。
2. Pod 反复 CrashLoopBackOff
核心思路:容器启动后立即退出。
排查路径:
检查前一个容器的日志(--previous 参数),确认是应用启动失败、配置错误、依赖服务不可达,还是健康探针(Liveness Probe)过早触发杀进程。
3. Pod 启动慢或卡在 ContainerCreating
核心思路:镜像拉取或存储挂载问题。
排查路径:
查看事件是否提示 "ImagePullBackOff"(镜像不存在或权限不足)或 "FailedMount"(PV/PVC 配置错误、存储后端不可用)。
4. Pod 被频繁驱逐(Evicted)
核心思路:节点资源压力过大。
排查路径:
检查节点是否出现 DiskPressure 或 MemoryPressure;确认 Pod 是否设置了合理的资源请求(requests)与限制(limits)。
二、服务与网络故障
5. Service 无法访问内部 Pod
核心思路:Endpoints 为空或网络策略阻断。
排查路径:
验证 Service 的 selector 是否与目标 Pod 的标签一致;查看 Endpoints 对象是否包含有效 IP;检查 NetworkPolicy 是否禁止通信。
6. 外部无法通过 Ingress 访问服务
核心思路:Ingress 控制器或路由配置问题。
排查路径:
确认 Ingress Controller 是否正常运行;检查 Ingress 规则中的 host 和 path 是否匹配;验证 TLS 证书是否有效且域名解析正确。
7. Pod 之间网络不通
核心思路:CNI 插件异常或防火墙拦截。
排查路径:
测试同节点与跨节点 Pod 互通性;检查 CNI 插件(如 Calico、Flannel)状态;确认云平台安全组或物理防火墙未阻断 Pod 网段流量。
8. DNS 解析失败(如无法解析 service name)
核心思路:CoreDNS 异常或配置错误。
排查路径:
检查 CoreDNS Pod 是否 Running;查看其日志是否有转发失败;确认 Pod 的 /etc/resolv.conf 是否指向集群 DNS 服务。
三、节点与控制平面故障
9. 节点状态为 NotReady
核心思路:kubelet 或容器运行时异常。
排查路径:
登录节点检查 kubelet 是否运行;查看系统资源(磁盘、内存)是否耗尽;确认 containerd/Docker 是否响应。
10. 新 Pod 无法调度到某节点
核心思路:节点存在污点或资源不足。
排查路径:
查看节点详情中的 Taints 字段;确认 Allocatable 资源是否已被占满;检查是否有 PodDisruptionBudget 限制。
11. API Server 响应缓慢或超时
核心思路:etcd 性能瓶颈或高负载。
排查路径:
监控 etcd 的磁盘延迟、快照频率、watch 请求数;检查 API Server 日志是否有大量 LIST 请求;评估是否需优化控制器或客户端行为。
12. etcd 集群失联或 leader 丢失
核心思路:网络分区或磁盘故障。
排查路径:
使用 etcdctl 检查成员健康状态;确认各节点间 2379/2380 端口互通;避免在高 IO 延迟磁盘上运行 etcd。
四、存储与配置故障
13. PVC 一直处于 Pending
核心思路:StorageClass 不存在或后端存储配额不足。
排查路径:
检查 PVC 指定的 StorageClass 是否存在;确认存储系统(如 NFS、Ceph、云盘)是否有足够容量和权限。
14. Pod 挂载的 ConfigMap/Secret 内容未更新
核心思路:K8s 不自动热更新已挂载的卷。
排查路径:
理解 ConfigMap/Secret 作为 volume 挂载后,内容仅在 Pod 创建时加载;若需动态更新,应通过重启 Pod 或使用 sidecar 同步文件。
五、资源与权限故障
15. Deployment 无法创建新 ReplicaSet
核心思路:RBAC 权限不足或配额限制。
排查路径:
检查部署所用 ServiceAccount 是否有创建 ReplicaSet 的权限;确认命名空间是否设置了 ResourceQuota 且已耗尽。
16. kubectl exec / logs 报错 "Forbidden"
核心思路:用户或 SA 缺少 pod/exec 或 pod/log 权限。
排查路径:
审查当前上下文(Context)绑定的角色(Role/ClusterRole),确认是否包含对 pods/exec 和 pods/log 的 verbs 授权。
六、升级与兼容性故障
17. 升级后某些 API 不可用(如 extensions/v1beta1)
核心思路:K8s 版本弃用旧 API。
排查路径:
查阅官方版本变更日志,将资源定义迁移到新 API(如 apps/v1);使用 kubectl convert(旧版)或手动调整 YAML。
18. Helm Chart 在新集群安装失败
核心思路:Chart 依赖的 CRD 或 API 版本不兼容。
排查路径:
检查 Chart 的 requirements;确认目标集群版本是否满足 Chart 的最低要求;优先使用 Helm 3 并启用 CRD 管理。
七、性能与稳定性故障
19. 集群整体响应变慢,大量 Pod 处于 Unknown 状态
核心思路:节点大规模失联或控制平面过载。
排查路径:
快速检查网络连通性(如节点到 Master 的 6443 端口);评估是否有大规模 Job 或 CronJob 突发创建;检查 kube-controller-manager 是否积压工作队列。
通用排障心法:三层定位 + 事件驱动
看状态:kubectl get 看资源状态(Running, Pending, NotReady...);
看事件:kubectl describe 查看 Events,这是 K8s 自带的"故障日志";
看日志:kubectl logs 获取应用或系统组件输出;
自底向上:从节点 → Pod → 应用,层层剥离;
善用工具:kubectl top、kubectl debug、crictl 等辅助诊断。
结语:排障不是救火,而是系统认知的体现
Kubernetes 的故障看似千奇百怪,实则万变不离其宗——一切问题都源于声明状态与实际状态的不一致。高手排障,靠的不是记忆命令,而是对 K8s 控制循环、组件职责和数据流的深刻理解。当你能在 30 秒内判断出问题是出在调度、网络、存储还是应用自身,你就真正掌握了云原生运维的核心能力。记住:最好的排障,是让故障根本不会发生——通过可观测性、自动化测试和规范治理,把问题消灭在上线之前。
有疑问加站长微信联系(非本文作者))
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
关注微信15 次点击
0 回复
暂无回复
添加一条新回复
(您需要 后才能回复 没有账号 ?)
- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码` - 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传