k8s学习-记录一次集群kube-controller,scheduler等多个pod重启的问题解决

问题

一次，集群的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​​