【k8s】etcd集群took too long to execute慢日志告警问题分析

最新推荐文章于 2025-07-25 15:43:58 发布

原创

最新推荐文章于 2025-07-25 15:43:58 发布 · 7k 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#运维 #java #大数据 #docker #数据库

本文分析了k8s集群中etcd出现大量'took too long'慢日志的问题，问题源于kube-controller-manager的cronjob-controller频繁全量查询所有namespace的job。解决方案包括配置job的ttlSecondsAfterFinished属性和避免使用cronjob_controller的全量查询。实施后，etcd慢查询告警显著下降。

背景

目前机器学习平台后端采用k8s架构进行GPU和CPU资源的调度和容器编排。总所周知，k8s的后端核心存储使用etcd进行metadata持久化存储。机器学习平台采取External etcd topology结构进行etcd的HA部署。

etcd集群的稳定性直接关系到k8s集群和机器学习平台的稳定性。odin平台直接接入etcd集群的慢日志(etcd请求操作>100ms)告警，实时监控etcd的稳定性。

问题记录

2020-01-06 运维同学反馈2019年12月中旬etcd慢日志监控出现大量的告警记录，而且告警呈上升趋势。

2020-01-20 运维同学继续反馈etcd慢日志告警数量继续上涨，未呈现稳态趋势。

问题分析

2020-01-06 运维同学反馈告警问题时，当时怀疑etcd 集群磁盘latency性能问题，通过etcd metrics接口dump backend_commit_duration_seconds 和 wal_fsync_duration_seconds，latency区间在128ms。etcd官方文档what-does-the-etcd-warning-apply-entries-took-too-long-mean 建议排查磁盘性能问题，保证 "p99 duration should be less than 25ms"。和运维同学讨论，先将etcd设置的慢日志阈值调整到100，继续跟踪告警问题。

root@xxx-ser00:~$ curl -L -s http://localhost:2379/metrics | grep backend_commit_duration_seconds
# HELP etcd_disk_backend_commit_duration_seconds The latency distributions of commit called by backend.
# TYPE etcd_disk_backend_commit_duration_seconds histogram
etcd_disk_backend_commit_duration_seconds_bucket{le="0.001"} 28164
etcd_disk_backend_commit_duration_seconds_bucket{le="0.002"} 357239
etcd_disk_backend_commit_duration_seconds_bucket{le="0.004"} 1.9119004e+07
etcd_disk_back