Kubernetes集群中controller manager与scheduler频繁重启的根因排查与优化实践

1. 问题现象与初步诊断最近在维护一个Kubernetes生产集群时发现控制平面的两个关键组件——controller manager和scheduler频繁重启。这个问题看似简单但背后可能隐藏着严重的性能隐患。先来看下我们当时观察到的具体现象通过kubectl get pods -n kube-system命令发现kube-controller-manager和kube-scheduler的RESTARTS计数不断增长查看组件日志时发现大量leader election lost、failed to renew lease等错误信息执行kubectl get cs命令显示controller-manager和scheduler状态间歇性变为Unknown这种情况在大型集群中尤为常见。我记得第一次遇到这个问题时第一反应是去检查这两个组件的资源配额。但通过kubectl top pod查看资源使用情况后发现CPU和内存消耗都在合理范围内。这说明问题可能不在组件本身而是其依赖的服务出现了异常。2. 深入排查etcd性能问题2.1 etcd与控制器组件的关联机制Controller manager和scheduler都需要通过API Server与etcd交互。具体来说Controller manager需要持续监控集群状态变化如Deployment副本数变化这些信息都存储在etcd中Scheduler需要获取Node资源信息这些数据同样来自etcd两者都使用watch机制监听资源变更而watch依赖于etcd的事件流当etcd响应变慢时这些组件的健康检查就会超时导致kubelet认为组件异常而触发重启。这就像餐厅里服务员controller manager/scheduler需要不断向厨房etcd确认订单状态如果厨房响应太慢经理kubelet就会认为服务员出了问题。2.2 关键指标分析与诊断我们主要通过以下几个etcd指标来诊断性能问题wal_fsync_duration_secondsWAL日志同步到磁盘的耗时健康值P99 10ms问题值持续 25msbackend_commit_duration_seconds事务提交耗时健康值P99 100ms问题值持续 250msetcd_disk_wal_fsync_duration_seconds_bucket磁盘同步耗时分布通过Prometheus查询这些指标我们发现wal_fsync的P99值达到了58ms明显高于正常水平。这提示可能存在磁盘I/O瓶颈。3. 常见根因与解决方案3.1 磁盘I/O性能不足这是我们在生产环境遇到最多的情况。etcd对磁盘延迟极其敏感特别是对于虚拟机使用的共享存储机械硬盘HDD没有隔离I/O的云盘优化方案# 1. 使用高性能SSD并独占磁盘 fio --nameetcd-test --ioenginelibaio --rwwrite --bs4k \ --numjobs1 --size8G --runtime60 --time_based --direct1 # 2. 调整etcd数据目录mount参数/etc/fstab /dev/nvme0n1 /var/lib/etcd ext4 defaults,discard,noatime,nodiratime 0 0 # 3. 分离WAL目录与数据目录 # etcd.yaml ... - --wal-dir/mnt/etcd-wal - --data-dir/mnt/etcd-data ...3.2 网络延迟问题跨可用区部署etcd节点时网络延迟会导致心跳包传输延迟提案提交超时快照同步缓慢优化方案# 调整etcd网络相关参数 # etcd.env ETCD_HEARTBEAT_INTERVAL500 ETCD_ELECTION_TIMEOUT2500 ETCD_SNAPSHOT_COUNT10000 # 使用专用网络接口 ethtool -K eth0 tx off rx off tso off gso off3.3 资源竞争问题当etcd与其他高负载服务如数据库混部时会出现CPU调度延迟内存交换磁盘I/O竞争优化方案# 使用cgroups限制资源 mkdir /sys/fs/cgroup/cpu/etcd echo 100000 /sys/fs/cgroup/cpu/etcd/cpu.cfs_period_us echo 80000 /sys/fs/cgroup/cpu/etcd/cpu.cfs_quota_us echo 1234 /sys/fs/cgroup/cpu/etcd/tasks # 调整进程优先级 renice -n -10 -p $(pgrep etcd)4. 参数调优实践4.1 etcd核心参数优化根据我们的经验生产环境推荐以下参数配置参数默认值推荐值说明heartbeat-interval100ms500ms适当降低心跳频率election-timeout1000ms2500ms超时时间需为心跳间隔的5倍snapshot-count1000050000减少快照频率max-request-bytes1.5MB10MB提高大请求处理能力quota-backend-bytes2GB8GB根据数据量调整配置示例# /etc/etcd/etcd.conf heartbeat-interval: 500 election-timeout: 2500 snapshot-count: 50000 max-request-bytes: 10485760 quota-backend-bytes: 85899345924.2 Kubernetes组件调优Controller manager和scheduler也需要相应调整# kube-controller-manager.yaml - --leader-electtrue - --leader-elect-lease-duration30s - --leader-elect-renew-deadline15s - --leader-elect-retry-period5s - --node-monitor-period5s - --node-monitor-grace-period40s # kube-scheduler.yaml - --leader-electtrue - --leader-elect-lease-duration30s - --leader-elect-renew-deadline15s - --leader-elect-retry-period5s5. 监控与告警配置完善的监控体系能帮助我们提前发现问题。以下是我们使用的关键告警规则# prometheus-rules.yaml - alert: HighEtcdWalLatency expr: histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (le)) 0.025 for: 5m labels: severity: critical annotations: summary: etcd high WAL sync latency (instance {{ $labels.instance }}) description: etcd is taking {{ $value }}s to sync WAL files - alert: EtcdLeaderChanges expr: rate(etcd_server_leader_changes_seen_total[1h]) 3 for: 10m labels: severity: warning annotations: summary: etcd frequent leader changes (instance {{ $labels.instance }}) description: etcd cluster is unstable with {{ $value }} leader changes per hour6. 硬件选型建议根据我们管理多个大型集群的经验etcd服务器的硬件配置应满足小型集群50节点CPU4核内存16GB存储NVMe SSD 200GB中型集群50-200节点CPU8核内存32GB存储NVMe SSD 500GB大型集群200节点专用etcd集群3-5节点每节点CPU16核内存64GB存储NVMe SSD 1TB特别提醒避免使用云平台的共享存储实测发现其I/O延迟波动很大。我们曾在一个客户环境中将etcd迁移到本地NVMe SSD后wal_fsync延迟从平均35ms降到了3ms。7. 问题复现与测试方法为了验证优化效果我们设计了一套压力测试方案# 1. 安装etcd基准测试工具 go get go.etcd.io/etcd/tools/benchmark # 2. 运行写入测试 benchmark --endpointshttp://etcd1:2379,http://etcd2:2379,http://etcd3:2379 \ --target-latency10ms --conns100 --clients1000 \ put --key-size32 --val-size256 --total1000000 # 3. 监控关键指标 watch -n 1 curl -s http://localhost:2379/metrics | grep -E wal_fsync|backend_commit|leader_changes # 4. 模拟网络延迟在测试环境 tc qdisc add dev eth0 root netem delay 50ms 20ms distribution normal这套测试方案帮助我们复现了生产环境的类似问题验证了参数调整的有效性。在优化后的集群上即使模拟50ms网络延迟etcd仍能保持稳定运行。