我说老李你说黑1. 项目概述
在Kubernetes生产环境中，kube-system命名空间下的Pod承载着集群核心组件（如kube-proxy、CoreDNS、metrics-server等），这些Pod的异常往往会导致集群级故障。不同于普通业务Pod，系统Pod的排查需要更精准的命令组合和问题定位策略。本文将分享一套经过生产验证的排查命令集，特别针对kube-system命名空间下的典型故障场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心排查流程
2.1 快速状态诊断
bash复制# 查看kube-system下所有Pod状态（按重启次数排序）
kubectl -n kube-system get pods --sort-by='.status.containerStatuses[0].restartCount'
# 带节点信息的扩展视图
kubectl -n kube-system get pods -o wide --sort-by='.spec.nodeName'
注意：优先关注RESTARTS>10或STATUS非Running的Pod。节点分布异常（如某个节点堆积大量异常Pod）可能暗示节点硬件问题。
2.2 深度日志分析
bash复制# 实时日志追踪（适合CrashLoopBackOff场景）
kubectl -n kube-system logs <pod_name> --previous --tail=50 --follow
# 多容器Pod的日志分离查看
kubectl -n kube-system logs <pod_name> -c <container_name>
日志分析要点：
- 搜索"error"、"failed"、"panic"等关键词
- 检查证书过期相关提示（常见于kube-apiserver等组件）
- 关注资源不足报错（OOMKilled、CPU throttling）
2.3 资源瓶颈检查
bash复制# 查看Pod资源请求/限制与实际使用对比
kubectl -n kube-system top pods --containers
# 配合节点资源状态查看
kubectl top nodes
典型问题模式：
- 内存使用持续接近limit值（可能引发OOM）
- CPU使用率长期>80%（导致调度延迟）
3. 高级诊断技巧
3.1 网络连通性测试
bash复制# 进入Pod网络命名空间测试（需宿主机权限）
nsenter -t $(docker inspect -f '{{.State.Pid}}' <container_id>) -n ping <target_ip>
# 检查kube-dns解析
kubectl -n kube-system run -it --rm dns-test --image=busybox --restart=Never -- nslookup kubernetes.default
网络问题特征：
- CoreDNS Pod频繁重启
- 跨节点Pod间通信失败
- 服务ClusterIP无法访问
3.2 存储卷异常处理
bash复制# 查看PVC/PV绑定状态
kubectl -n kube-system get pvc
kubectl get pv
# 检查存储卷挂载详情
kubectl -n kube-system describe pod <pod_name> | grep -A10 "Mounts"
存储相关故障：
- PersistentVolumeClaim处于Pending状态
- 挂载超时（常见于NFS/CEPH存储）
- 权限拒绝错误（fsGroup配置问题）
4. 典型场景解决方案
4.1 CoreDNS循环重启
- 检查配置映射：
bash复制kubectl -n kube-system get cm coredns -o yaml | grep forward
- 验证上游DNS可达性：
bash复制kubectl -n kube-system exec -it <coredns_pod> -- nslookup example.com <upstream_dns>
- 常见修复方案：
- 调整forward插件超时时间（默认5s可能不足）
- 更换为TCP协议查询（添加
prefer_udp false配置）
4.2 kube-proxy端口冲突
症状表现：
- 节点上出现大量"Address already in use"日志
- 服务ClusterIP无法访问
诊断命令：
bash复制# 检查端口占用情况
ss -tulnp | grep <port_number>
# 查看kube-proxy当前配置
kubectl -n kube-system get cm kube-proxy -o yaml
解决方案：
- 修改
--metrics-bind-address参数避免冲突 - 清理旧的iptables规则（谨慎操作）：
bash复制iptables-save | grep -v KUBE | iptables-restore
5. 排查工具链推荐
5.1 原生Kubectl插件
kubectl-debug: 直接调试运行中的Pod（需提前安装）
bash复制kubectl debug -n kube-system <pod_name> -it --image=nicolaka/netshoot
5.2 第三方诊断工具
kube-score: 配置静态检查
bash复制kube-score score -n kube-system <(kubectl get pods -n kube-system -o yaml)
popeye: 集群健康扫描
bash复制popeye -n kube-system --save --out html
6. 预防性维护建议
-
监控指标配置：
- 设置Pod重启次数告警（>5次即预警）
- 监控容器内存使用率（超过limit的90%触发）
-
定期维护操作：
bash复制# 检查证书过期时间
openssl x509 -noout -dates -in /etc/kubernetes/pki/apiserver.crt
# 清理Evicted状态的Pod
kubectl -n kube-system delete pods --field-selector=status.phase=Failed
- 关键配置检查清单：
- kubelet的
--image-gc-high-threshold（建议85%） - 控制器管理器的
--terminated-pod-gc-threshold（建议50） - API服务器的
--default-not-ready-toleration-seconds（建议30）
- kubelet的
在实际运维中，我发现系统组件的异常往往具有连锁反应。例如某个节点kubelet异常会导致该节点上的所有系统Pod被标记为NotReady，进而影响CoreDNS的Endpoint切片更新。此时需要从节点级开始排查，而不是单独处理Pod问题。