排查定位
kube-system 承载着 CoreDNS、kube-proxy、metrics-server、网络插件以及 kubeadm 集群里的静态控制面 Pod。适用平台是 Kubernetes。它出问题往往影响面很大（解析、指标、网络转发同时失效），但也最容易被盲目重启掩盖现场。正确的收敛顺序是：先看 Pod 状态与重启次数，再看事件，再看日志，最后才考虑节点侧——按这个顺序走，既能定位根因，也不会把证据冲掉。
基本信息
| 适用平台 | Kubernetes，控制面与系统组件所在命名空间 |
|---|---|
| 常见成员 | coredns、kube-proxy、metrics-server、网络插件、云控制器 |
| kubeadm 特殊点 | apiserver、scheduler、controller-manager、etcd 以静态 Pod 形式由 kubelet 拉起 |
| 权限要求 | 读 kube-system 下 Pod、事件、日志的权限 |
典型使用场景
- 集群整体异常：先确认系统组件是否都在运行，快速判断影响面
- 解析或指标同时失效：CoreDNS 与 metrics-server 也在 kube-system，需一起核对
- 升级后异常：比对组件镜像版本与节点容器运行时状态
- 节点扩容后插件没起来：检查 DaemonSet 是否覆盖新节点
- 故障复盘：按时间线把事件与日志对齐，避免只留结论丢失过程
总览与下钻
总览与下钻
kubectl get pods -n kube-system -o wide # 状态、重启次数与落点
kubectl get events -n kube-system --sort-by=.lastTimestamp | tail -20
kubectl describe pod -n kube-system coredns-6d4b75cb6d-abcde # 事件与容器状态
kubectl logs -n kube-system deploy/coredns --tail=50 # 组件日志
kubectl get ds -n kube-system -o wide # 插件是否全覆盖
kubectl get --raw /healthz # apiserver 自身健康观察点与含义
| 观察点 | 正常表现 | 异常含义 |
|---|---|---|
| RESTARTS | 长期为 0 或极少 | 持续增长说明崩溃循环 |
| DESIRED 与 READY（DaemonSet） | 两者相等 | 不相等说明有节点没跑起来 |
| 事件里的 Warning | 偶发少量 | 集中出现往往指向同一根因 |
| 静态 Pod 日志 | 可用 kubectl logs 读取 | 读不到时改在节点上用 crictl 看 |
kubeadm 集群里 apiserver、scheduler、controller-manager、etcd 由 kubelet 以静态 Pod 拉起，日志可用 kubectl logs 或节点上的 crictl 查看。
系统组件的副本通常只有一到两个，重启期间对应能力会整体失效，动作前先确认是否有其他副本承担流量。
取证顺序
- 第一步看状态：Pod 是否 Running、重启次数是否在增长，先划定范围
- 第二步看事件：按时间排序取尾部，事件里的 reason 往往直接指向根因
- 第三步看日志：确认是启动失败、探活失败还是运行期报错
- 第四步看节点：只有在前面都无法解释时，才转到节点侧查 kubelet 与运行时