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?timeout10s: 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未启用barrierRAID卡未配置写缓存解决方案# 检查磁盘调度策略应为deadline或noop cat /sys/block/sda/queue/scheduler # 检查文件系统挂载参数推荐添加datawriteback,barrier0 mount | grep etcd2.2 CPU资源竞争当etcd进程需要与其他高CPU消耗的服务竞争资源时也会导致心跳超时。我们遇到过这样的情况节点上同时运行了elasticsearch等重型服务未设置CPU亲和性导致etcd频繁跨核调度突发流量导致软中断处理占用大量CPU优化方法# 使用cgroups限制etcd的CPU使用 systemctl set-property etcd.service CPUShares1024 # 设置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-count3.2 Kubernetes组件调优controller-manager和scheduler也需要相应调整# 增加leader选举租约时间 --leader-elect-lease-duration30s --leader-elect-renew-deadline15s --leader-elect-retry-period5s # 调大QPS限制 --kube-api-qps100 --kube-api-burst1503.3 监控指标看板建立以下关键监控指标etcd:wal_fsync_duration_secondsdisk_backend_commit_duration_secondsetcd_network_peer_round_trip_time_secondsKubernetes:rest_client_request_duration_secondsworkqueue_depthleader_election_master_status4. 长效预防机制4.1 硬件选型建议对于生产环境etcd集群推荐以下配置CPU: 4核以上专用核心内存: 16GB存储: NVMe SSD建议500GB以上网络: 万兆网卡单独VLAN4.2 定期维护操作我们建立了这些日常维护习惯每月执行一次defrag操作etcdctl defrag --endpointshttps://etcd1:2379监控etcd db大小etcdctl endpoint status -w table定期检查告警规则是否生效4.3 灾备方案设计建议实施以下灾备措施每日定时备份etcd数据准备冷备节点随时可替换制定etcd集群扩容方案演练单节点故障恢复流程经过上述优化后我们的集群已经稳定运行6个月未出现组件重启问题。最关键的经验是etcd性能问题往往具有传导性必须建立从底层硬件到上层组件的全栈监控体系。