Kubelet 停止發布節點狀態

Question

我的兩個集群kubectl describe node有時會Kubelet stopped posting node status在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)

Answer 1

問題是kubelet有時無法打補丁自己的節點狀態，250多個資源留在節點上，kubelet不能同時用kube-apiserver看250多個流。 將 kube-apiserver --http2-max-streams-per-connection為 1000 以緩解痛苦。

看看： kubernetes-patch 。

編輯：

Kubernetes 使用客戶端證書、不記名令牌、身份驗證代理或 HTTP 基本身份驗證通過身份驗證插件對 API 請求進行身份驗證。 當向 API 服務器發出 HTTP 請求時，插件會嘗試將以下屬性與請求相關聯：

您可以一次啟用多種身份驗證方法。 您通常應該至少使用兩種方法：

• 服務帳戶的服務帳戶令牌
• 至少一種其他用戶身份驗證方法。

當啟用多個驗證器模塊時，第一個成功驗證請求的模塊會進行短路評估。 API 服務器不保證運行中的順序驗證器。

您可以在此處找到有關令牌的信息： 令牌。

您還可以使用服務帳戶，它是一個自動啟用的身份驗證器，它使用簽名的不記名令牌來驗證請求。

服務帳戶通常由 API 服務器自動創建，並通過 ServiceAccount 准入控制器與集群中運行的 Pod 相關聯。 Bearer 令牌安裝在眾所周知的位置的 pod 中，並允許集群內進程與 API 服務器通信。

服務帳戶不記名令牌在集群外使用完全有效，可用於為希望與 Kubernetes API 通信的長期作業創建身份。 要手動創建服務帳戶，只需使用 kubectl create serviceaccount (NAME) 命令。 這將在當前命名空間中創建一個服務帳戶和一個關聯的機密。

秘密通常包含跨越一系列重要性的值，其中許多可能導致 Kubernetes 內部（例如服務帳戶令牌）和外部系統的升級。 即使單個應用程序可以推斷出它希望與之交互的秘密的力量，同一命名空間內的其他應用程序也可能使這些假設無效。

要首先檢查令牌，您必須列出秘密，然后描述它們（ $ kubectl describe secret secret-name ）。

要列出機密，請執行以下命令：

$ kubectl get secret

秘密通常包含跨越一系列重要性的值，其中許多可能導致 Kubernetes 內部（例如服務帳戶令牌）和外部系統的升級。 即使單個應用程序可以推斷出它希望與之交互的秘密的力量，同一命名空間內的其他應用程序也可能使這些假設無效。

您可以在此處找到更多信息：秘密。

Answer 2

TL; 博士

ssh <failing node>
sudo systemctl restart kubelet

“你試過打開和關閉它嗎？”的神奇話語。 我不知道是什么導致了我的kubelet失敗，但我只是通過ssh進入虛擬機並重新啟動了kubelet服務，一切又開始工作了。