问题
一次，集群的kube-controller,scheduler等容器重启，查看日志，发现时间很集中，在秒级范围内多个pod同时重启。
查看pod状态
kubectl get pod -n kube-system | grep kube-control
kube-controller-manager反复重启了200多次了。
排查
查看kube-control日志，日志显示“failed to renew lease kube-system/kube-controller-manager: failed to tryAcquireOrRenew context deadline exceeded”
kubectl logs -f kube-controller —previous
现renew list失败，租约续签失败，主动关闭容器。
查看api-server容器状态发现api-server日志中有请求的返回时间过长，请求延迟均在10s左右，部分请求时间延迟超过11s，常规请求 回复时间应为毫秒级别。
api-server请求需要和etcd通讯，查询etcd容器状态和日志。发现etcd日志中：
journalctl -u etcd
- wal日志同步过慢，需要8s以上，期望值为1s
- etcdserver：read-only range request......took too long with etcd
- grpc：Server.ProcessUnaryRPC failed to write status: connection error : desc = "transport is closing”.
- Etcd日志显示11点04分出现lost leader报错，同时指出网络连接较慢。
查看prometheus监控，当时磁盘读写时间明显增大
分析
- 重启的pod为kube-controller-manager、kube-scheduler等均为需要选主的服务。
- 以kube-controller-manager为例，配置文--leader-elect=true选项开启选主，--leader-elect-renew-deadline duration选项官方推荐默认配置为10s，超过十秒则选主续约失败，相应endpoint更新失败，默认连接超时，关闭容器进行重启
- etcd、api-server日志均显示当时请求超时。
- 推测当时连接磁盘较慢，IOwait时间长。
总结
kubernetes集群依赖etcd键值库进行请求应答，尤其是有选主需求的服务，选主续约失败会进行自动重启。etcd与数据盘的IO就显得十分重要。
后续考虑采用本地SSD盘方式部署etcd集群。同时将etcd集群与kubernetes的master节点剥离，保证其可用性和IO。
参考：
1. etcdserver: read-only range request took too long with etcd 3.2.24 · Issue #70082 · kubernetes/kubernetes · GitHub
2. kube-controller-manager | Kubernetes
3. [Tuning | etcd](https://etcd.io/docs/v3.3/tuning/#:~:text=By default, etcd uses a 100ms heartbeat interval.,By default, etcd uses a 1000ms election timeout.)
4. https://www.cnblogs.com/360linux/p/12919521.html
标签：选主,scheduler,manager,controller,etcd,pod,kube,日志 From： https://blog.51cto.com/u_11555417/6065697