Kubernetes集群中controller manager与scheduler频繁重启的根因诊断与优化实践
1. 问题现象与初步排查
最近在维护一个Kubernetes生产集群时，发现控制平面的两个关键组件——controller manager和scheduler频繁重启。这个问题看似简单，但背后可能隐藏着严重的性能隐患。先来看看我们最初观察到的现象：
在kubelet日志中，频繁出现类似这样的错误：
failed to update node lease, error: Put https://kapi-xxx-xx:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/node02?timeout=10s: read tcp 192.168.111.104:35660->192.168.111.100:6443: read: connection reset by peer执行kubectl get cs检查组件状态时，发现etcd、controller-manager和scheduler的状态间歇性变为"unknown"。这种问题在业务高峰期尤为明显，严重时甚至会影响Pod的调度和部署。
排查第一步，我们检查了各组件的日志时间线：
- 先看controller-manager和scheduler的日志，发现大量"leader election lost"的记录
- 查看apiserver日志，发现存在大量"etcdserver: request timed out"错误
- 最终在etcd日志中找到了关键线索：
leader failed to send out heartbeat on time; took too long, leader is overloaded likely from slow disk这个线索直接指向了etcd的性能问题。etcd作为Kubernetes的大脑，存储着整个集群的状态数据。当它出现性能瓶颈时，首当其冲受影响的就是依赖它工作的controller manager和scheduler。
2. etcd性能问题的三大元凶
2.1 磁盘I/O瓶颈
etcd对磁盘性能极其敏感，因为它需要将所有变更持久化到预写日志(WAL)中。我们通过监控发现，wal_fsync_duration_seconds指标经常超过100ms，远高于推荐的10ms阈值。
这种情况通常由以下原因导致：
- 使用机械硬盘而非SSD
- 磁盘与其他高I/O服务共享
- 文件系统未正确配置（如ext4未启用barrier）
- RAID卡未配置写缓存
解决方案：
# 检查磁盘调度策略（应为deadline或noop） cat /sys/block/sda/queue/scheduler # 检查文件系统挂载参数（推荐添加data=writeback,barrier=0） mount | grep etcd2.2 CPU资源竞争
当etcd进程需要与其他高CPU消耗的服务竞争资源时，也会导致心跳超时。我们遇到过这样的情况：
- 节点上同时运行了elasticsearch等重型服务
- 未设置CPU亲和性，导致etcd频繁跨核调度
- 突发流量导致软中断处理占用大量CPU
优化方法：
# 使用cgroups限制etcd的CPU使用 systemctl set-property etcd.service CPUShares=1024 # 设置CPU亲和性 taskset -pc 2,3 $(pgrep etcd)2.3 网络延迟问题
跨机房部署的etcd集群特别容易遇到网络问题。我们曾测量到以下异常：
- 节点间RTT超过50ms
- 网卡出现丢包和重传
- 交换机缓冲区溢出导致报文丢弃
诊断命令：
# 测量节点间延迟 ping -c 10 etcd-node2 # 检查重传率 netstat -s | grep retransmit # 检查带宽利用率 iftop -i eth03. 关键参数调优实战
3.1 etcd核心参数调整
根据前面的分析，我们对etcd配置做了以下关键调整：
# 心跳间隔从100ms调整为500ms heartbeat-interval: 500 # 选举超时从1000ms调整为2500ms election-timeout: 2500 # WAL单独存放于高性能NVMe磁盘 wal-dir: /mnt/nvme/etcd/wal # 提高快照触发阈值 snapshot-count: 20000调整原则：
- 心跳间隔应大于P99网络RTT的3倍
- 选举超时至少是心跳间隔的5倍
- 对于写密集场景，适当增加snapshot-count
3.2 Kubernetes组件调优
controller-manager和scheduler也需要相应调整：
# 增加leader选举租约时间 --leader-elect-lease-duration=30s --leader-elect-renew-deadline=15s --leader-elect-retry-period=5s # 调大QPS限制 --kube-api-qps=100 --kube-api-burst=1503.3 监控指标看板
建立以下关键监控指标：
etcd:
- wal_fsync_duration_seconds
- disk_backend_commit_duration_seconds
- etcd_network_peer_round_trip_time_seconds
Kubernetes:
- rest_client_request_duration_seconds
- workqueue_depth
- leader_election_master_status
4. 长效预防机制
4.1 硬件选型建议
对于生产环境etcd集群，推荐以下配置：
- CPU: 4核以上专用核心
- 内存: 16GB+
- 存储: NVMe SSD，建议500GB以上
- 网络: 万兆网卡，单独VLAN
4.2 定期维护操作
我们建立了这些日常维护习惯：
- 每月执行一次defrag操作：
etcdctl defrag --endpoints=https://etcd1:2379- 监控etcd db大小：
etcdctl endpoint status -w table- 定期检查告警规则是否生效
4.3 灾备方案设计
建议实施以下灾备措施：
- 每日定时备份etcd数据
- 准备冷备节点，随时可替换
- 制定etcd集群扩容方案
- 演练单节点故障恢复流程
经过上述优化后，我们的集群已经稳定运行6个月未出现组件重启问题。最关键的经验是：etcd性能问题往往具有传导性，必须建立从底层硬件到上层组件的全栈监控体系。