Question

我的两个群集节点有时在Kubelet stopped posting node status中获得kubectl describe node。在该节点的日志中，我看到以下内容：

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)

Answer 1

TL;博士

ssh <failing node>
sudo systemctl restart kubelet

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

Answer 2

问题是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 Admission Controller与群集中运行的Pod关联。承载令牌安装在知名位置的Pod中，并允许集群内进程与API服务器通信。

服务帐户承载令牌非常有效，可以在集群外部使用，并且可以用于为希望与Kubernetes API通讯的长期工作创建身份。要手动创建服务帐户，只需使用kubectl create serviceaccount（NAME）命令。这样会在当前名称空间中创建一个服务帐户以及一个关联的机密。

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

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

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

$ kubectl get secret

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

您可以在这里找到更多信息：secret。

Kubelet停止发布节点状态

2 个答案: