kubernetes - Kubelet 停止发布节点状态

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

问题是 kubelet有时无法修补其节点状态，超过 250 个资源留在节点上，kubelet 无法同时使用 kube-apiserver 观看超过 250 个流。调整 kube-apiserver --http2-max-streams-per-connection到1000来缓解疼痛。

看一看:kubernetes-patch .

编辑:

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

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

服务帐户的服务帐户 token

至少一种用于用户认证的其他方法。

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

您可以在此处找到有关 token 的信息: tokens .

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

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

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

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

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

要列出 secret ，请执行以下命令:

$ kubectl get secret

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

您可以在这里找到更多信息: secret .