共计 1529 个字符,预计需要花费 4 分钟才能阅读完成。
背景
某客户 kubernetes 集群新加了一个节点,新节点部署利用后,利用会间歇性unavaliable
,用户拜访报 503,没有事件音讯,主机状态也失常。
排查
初步狐疑是新节点问题,在系统日志 /var/log/message
和dmesg
中都未发现相干错误信息,在 kubelet 中发现以下日志
kubernetes 集群时通过 rke 进行装置,能够在节点上间接执行命令
docker logs -f --tail=30 kubelet
查看 kubelet 日志
E0602 03:18:27.766726 1301 controller.go:136] failed to ensure node lease exists, will retry in 7s, error: an error on the server ("") has prevented the request from succeeding (get leases.coordination.k8s.io k8s-node-dev-6)
E0602 03:18:34.847254 1301 reflector.go:178] k8s.io/client-go/informers/factory.go:135: Failed to list *v1.CSIDriver: an error on the server ("") has prevented the request from succeeding (get csidrivers.storage.k8s.io)
I0602 03:18:39.176996 1301 streamwatcher.go:114] Unexpected EOF during watch stream event decoding: unexpected EOF
E0602 03:18:43.771023 1301 controller.go:136] failed to ensure node lease exists, will retry in 7s, error: an error on the server ("") has prevented the request from succeeding (get leases.coordination.k8s.io k8s-node-dev-6)
其中比拟关注 failed to ensure node lease exists
这个错误信息,从字面上了解应该就是无奈注册主机信息,然而 kubectl get nodes
失去的状态都是 Ready
。联想到利用间歇性的不可用,狐疑可能是短时间节点不可用而后疾速复原,因而可能在执行命令的时候是失常的,为了验证猜测,在后盾始终执行kubectl get nodes
命令,终于捕捉到 NotReady
状态
并且也捕捉到不可用时的详细信息
依据 kubelet stopped posting node status
作为关键字搜寻,在 stackoverflow 上找到相似的问题,高赞答复倡议设置 kube-apiserver 参数 --http2-max-streams-per-connection
,因为最近集群部署了 prometheus,并且减少了多个节点,对 apiserver 的申请量忽然变大可能导致 apiserver 的连接数不够,该参数能够减少连接数,因为集群是通过 rke 进行装置,因而须要更改 rke 配置文件后从新执行rke up
命令,更改如下
kube-api:
service_node_port_range: "1-65535"
extra_args:
http2-max-streams-per-connection: 1000
从新执行 rke up
后进行集群更新,更新结束有重启 kubelet,问题解决
如果是 rke 装置能够在节点上执行命令
docker restart kubelet
重启 kubelet