Kubelet 停止发布节点状态答案

【问题标题】：Kubelet stopped posting node statusKubelet 停止发布节点状态
【发布时间】：2020-04-04 15:18:57
【问题描述】：

我的两个集群节点有时会在kubectl describe node 中获得Kubelet stopped posting node status。在该节点的日志中，我看到了这一点：

Dec 11 12:01:03 alma-kube1 kubelet[946]: E1211 06:01:03.166998     946 controller.go:115] failed to ensure node lease exists, will retry in 6.4s, error: Get https://192.168.151.52:6443/apis/coordination.k8s.io/v1beta1/namespaces/kube-node-lease/leases/alma-kube1?timeout=10s: read tcp 192.168.170.7:46824->192.168.151.52:6443: use of closed network connection
Dec 11 12:01:03 alma-kube1 kubelet[946]: W1211 06:01:03.167045     946 reflector.go:289] object-"kube-public"/"myregistrykey": watch of *v1.Secret ended with: very short watch: object-"kube-public"/"myregistrykey": Unexpected watch close - watch lasted less than a second and no items received
Dec 11 12:01:03 alma-kube1 kubelet[946]: W1211 06:01:03.167356     946 reflector.go:289] object-"kube-system"/"kube-router-token-bfzkn": watch of *v1.Secret ended with: very short watch: object-"kube-system"/"kube-router-token-bfzkn": Unexpected watch close - watch lasted less than a second and no items received
Dec 11 12:01:03 alma-kube1 kubelet[946]: W1211 06:01:03.167418     946 reflector.go:289] object-"kube-public"/"default-token-kcnfl": watch of *v1.Secret ended with: very short watch: object-"kube-public"/"default-token-kcnfl": Unexpected watch close - watch lasted less than a second and no items received
Dec 11 12:01:13 alma-kube1 kubelet[946]: E1211 06:01:13.329262     946 kubelet_node_status.go:385] Error updating node status, will retry: failed to patch status "{\"status\":{\"$setElementOrder/conditions\":[{\"type\":\"MemoryPressure\"},{\"type\":\"DiskPressure\"},{\"type\":\"PIDPressure\"},{\"type\":\"Ready\"}],\"conditions\":[{\"lastHeartbeatTime\":\"2019-12-11T06:01:03Z\",\"type\":\"MemoryPressure\"},{\"lastHeartbeatTime\":\"2019-12-11T06:01:03Z\",\"type\":\"DiskPressure\"},{\"lastHeartbeatTime\":\"2019-12-11T06:01:03Z\",\"type\":\"PIDPressure\"},{\"lastHeartbeatTime\":\"2019-12-11T06:01:03Z\",\"type\":\"Ready\"}]}}" for node "alma-kube1": Patch https://192.168.151.52:6443/api/v1/nodes/alma-kube1/status?timeout=10s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

【问题讨论】：

表示节点无法连接api服务器。
这可能是你的 master 内存问题
如何查看？

标签： kubernetes kubelet

【解决方案1】：

问题是kubelet 有时无法修补其节点状态，超过 250 个资源停留在节点上，kubelet 无法同时使用 kube-apiserver 观看超过 250 个流。将 kube-apiserver --http2-max-streams-per-connection 调整为 1000 以减轻痛苦。

看一看：kubernetes-patch。

编辑：

Kubernetes 使用客户端证书、承载令牌、身份验证代理或 HTTP 基本身份验证来通过身份验证插件对 API 请求进行身份验证。当向 API 服务器发出 HTTP 请求时，插件会尝试将以下属性与请求相关联：

您可以一次启用多种身份验证方法。您通常应该至少使用两种方法：

服务帐户的服务帐户令牌
至少有一种其他的用户身份验证方法。

启用多个身份验证器模块时，第一个成功验证请求的模块会短路评估。 API 服务器不保证验证器运行的顺序。

您可以在此处找到有关令牌的信息：tokens。

您还可以使用服务帐户，它是一个自动启用的身份验证器，它使用签名的bearer tokens 来验证请求。

Service accounts 通常由 API 服务器自动创建，并通过 ServiceAccount 准入控制器与集群中运行的 pod 关联。 Bearer 令牌安装在已知位置的 pod 中，并允许集群内进程与 API 服务器通信。

服务帐户不记名令牌完全可以在集群外使用，并可用于为希望与 Kubernetes API 对话的长期工作创建身份。要手动创建服务帐户，只需使用 kubectl create serviceaccount (NAME) 命令。这会在当前命名空间中创建一个服务帐户和一个关联的机密。

Secret 通常包含跨越一系列重要性的值，其中许多可能导致 Kubernetes 内部（例如服务帐户令牌）和外部系统的升级。即使单个应用程序可以推断出它期望与之交互的秘密的力量，同一命名空间中的其他应用程序也可能使这些假设无效。

要首先检查令牌，您必须列出秘密，然后描述它们 ($ kubectl describe secret secret-name)。

要列出秘密，请执行以下命令：

$ kubectl get secret

您可以在此处找到更多信息：secret。

【讨论】：

好的，我会测试这个解决方案并回信
在所有监督节点上进行更改并没有帮助
我能检查一下您的证书/令牌吗？也许阅读一遍并仔细检查您的设置？ kubernetes.io/docs/reference/access-authn-authz/node
我如何检查我的秘密和令牌？很可能是网络问题，可能是我的 cisco 2911 路由器...
我已经更新了我的答案 - 包含秘密和令牌信息。它解决了你的问题吗？请考虑支持并接受答案。

【解决方案2】：

TL;DR

ssh <failing node>
sudo systemctl restart kubelet

“你试过打开和关闭它吗？”这句神奇的话我不知道是什么导致我的kubelet 失败，但我只是将ssh 放入VM 并重新启动kubelet 服务，一切又开始工作了。

【讨论】：