Kubernetes：加入工作节点后master节点kube-system Pod持续重启

这种核心组件反复在Pending/Running间切换甚至消失的问题，我之前帮团队排查过好几个类似案例，大概率是执行的那个命令触发了配置冲突、资源瓶颈或者网络异常，咱们一步步来定位：

• 先锁定触发问题的关键命令
  问题是在执行某命令后才出现的，先把这个命令的具体内容和参数理清楚——比如是不是手动修改了kube-apiserver的启动参数？还是给worker节点join时用了错误的token/CA哈希？或者是调整了kube-system组件的资源限制？这个触发点是最核心的突破口。

• 检查Master节点的资源负载
  etcd、kube-apiserver这类核心组件对CPU、内存和磁盘IO非常敏感，执行以下命令看资源占用情况：

  kubectl top nodes
  free -h
  iostat -x 1 3
  

  如果内存占满、CPU持续100%或者磁盘IO过高，kubelet会被迫重启Pod，甚至直接驱逐低优先级的组件Pod。

• 查看核心组件的日志细节
  重点排查etcd和kube-apiserver的日志，这两个是整个集群的核心枢纽：

  # 查看etcd日志
  kubectl logs -n kube-system etcd-$(hostname)
  # 查看kube-apiserver日志
  kubectl logs -n kube-system kube-apiserver-$(hostname)
  

  比如etcd出现磁盘空间不足、集群连接异常，或者apiserver出现认证失败、端口被占用，都会直接导致所有依赖它们的Pod反复重启。

• 验证网络插件的状态
  很多时候worker节点加入后，网络插件（Flannel/Calico/Cilium）的配置冲突会导致Pod通信异常：

  # 以Flannel为例，查看网络Pod状态
  kubectl get pods -n kube-system -l k8s-app=flannel
  # 查看Calico节点Pod状态
  kubectl get pods -n kube-system -l k8s-app=calico-node
  

  如果网络Pod本身处于CrashLoopBackOff状态，或者worker节点的Pod CIDR和master配置的集群CIDR冲突，会导致kube-system Pod无法正常通信，进而被反复重启。

• 检查kubelet服务的运行状态
  在master节点上查看kubelet的系统服务状态，确认它是否稳定：

  systemctl status kubelet
  journalctl -u kubelet -f
  

  kubelet是节点上管理Pod的核心进程，如果它本身因为配置错误（比如cgroup驱动不匹配）或者资源不足频繁重启，节点上的所有Pod都会跟着反复重建。

• 查看集群事件日志
  用事件日志快速定位最近的异常操作：

  kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp'
  

  这里会显示Pod被调度、驱逐、镜像拉取失败、资源不足等关键信息，能帮你快速缩小问题范围。

如果暂时找不到头绪，可以先尝试回滚到执行那个命令之前的状态（比如恢复kubelet配置、重启kube-apiserver和etcd服务），再逐步重新操作，对比每一步的变化来定位问题。

内容的提问来源于stack exchange，提问作者Saad Farooq