k8s controller manager 无限重启最常见的原因是底层存储 etcd 性能不足导致租约续签失败，其次是配置冲突或权限问题，建议优先排查 etcd 磁盘 IO 和组件日志中的 lease 报错。
先说结论：多数情况是 etcd 响应慢导致控制平面组件选主续约超时，少数情况是配置冲突或权限缺失。
- 先确认：查看组件日志是否有 failed to renew lease 或 connection reset 错误
- 先处理：检查 etcd 磁盘性能及历史数据大小，必要时清理或扩容
- 再验证：观察 Pod 重启计数是否停止增长，集群组件状态恢复 Ready
命令速用版
快速查看组件状态和最近日志：
kubectl get pods -n kube-system | grep controller-manager
kubectl logs -n kube-system kube-controller-manager-xxx `--previous`
journalctl -u etcd -n 50
为什么会这样
controller manager 在高可用模式下需要通过 etcd 进行选主（leader election），默认续约超时时间较短（公开资料中常见默认值为 10s 左右）。如果 etcd 所在磁盘 IO 延迟过高，或者 etcd 历史数据过多导致响应变慢，组件无法在规定时间内完成租约续签，就会主动退出并重启。此外，集群初始化时的网段配置冲突（如 cluster-cidr 耗尽）或 RBAC 权限误删也会导致组件无法正常工作而反复重启。
分步处理
1. 检查组件日志
重点查找 failed to renew lease、context deadline exceeded 或 connection reset by peer 等关键字。如果看到此类报错，说明组件与 API Server 或 etcd 的通信受阻。
2. 排查 etcd 健康状况
查看 etcd 日志是否有 slow disk、leader failed to send out heartbeat on time 等警告。如果存在，需检查磁盘 IO 性能。公开资料中提到，wal 日志同步过慢（如超过 8s）是典型诱因。
3. 清理 etcd 数据（谨慎操作）
如果确认是 etcd 历史数据过大，可执行 defrag 操作清理碎片，但需注意该操作有风险，建议在维护窗口进行。
4. 检查配置文件
如果是新搭建集群，检查 kube-controller-manager.yaml 中的 cluster-cidr 是否与 service-cluster-ip-range 冲突，或者 CIDR 是否已分配耗尽。
怎么验证是否生效
执行 kubectl get pods -n kube-system 观察重启次数（RESTARTS 列）是否不再增加。同时使用 kubectl get cs 或检查组件日志，确认不再出现 unknown 状态或选主失败报错。
常见坑
- 不要随意将 leader-elect 改为 false，这会导致高可用集群出现脑裂风险。
- etcd 数据盘建议使用本地 SSD，避免与其他高 IO 业务混用。
- 修改 manifests 配置后，通常组件会自动重启生效，无需手动删除 Pod。
参考来源
- K8s 集群频繁重启？可能是 etcd 磁盘性能拖了后腿 (附调优参数详解)
- 人为惨案之 kube-controller-manager 不断重启根因溯源
- 记一次 controller manager and scheduler 重复重启问题分析
- k8s 学习 - 记录一次集群 kube-controller,scheduler 等多个 pod 重启的问题解决
- apiserver 重启、响应慢、etcd 选主频繁、k8s 系统组件重启次数多解决方法
原文链接：https://www.zjcp.cc/ask/10443.html