“Kubelet 停止發布節點狀態”並且節點無法訪問

Question

我在一個相當新的集群中遇到了一些問題，其中幾個節點（似乎總是成對發生，但可能只是巧合）將變為 NotReady，並且kubectl describe會說 Kubelet 停止發布內存、磁盤、PID 的節點狀態並准備好了。

所有正在運行的 pod 都卡在 Termination 中（可以使用 k9s 連接到集群並查看這一點），我找到的唯一解決方案是封鎖和排空節點。 幾個小時后，它們似乎被刪除並創建了新的。 或者，我可以使用 kubectl 刪除它們。

它們完全無法通過 ssh（超時）訪問，但 AWS 報告 EC2 實例沒有問題。

這種情況在過去一周內已經發生了 3 次。 一切都恢復良好，但顯然存在一些問題，我想深入了解它。

如果我根本無法進入箱子，我將如何去查明發生了什么？ （實際上我突然想到可能會拍攝卷的快照並安裝它，所以如果再次發生，我會嘗試這樣做，但歡迎任何其他建議）

運行 kubernetes v1.18.8

Answer 1

這里有兩種最常見的可能性，最有可能是由大負載引起的：

• kubelet 主機上的Out of Memory不足錯誤。 可以通過向BootstrapArguments添加適當的--kubelet-extra-args來解決。 例如：-- --kubelet-extra-args "--kube-reserved memory=0.3Gi,ephemeral-storage=1Gi --system-reserved memory=0.2Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"

• 這里解釋了一個問題：

kubelet 有時無法修補其節點狀態，'因為節點上有 250 多個資源，kubelet 無法同時使用 kube-apiserver 觀看超過 250 個流。 所以，我只是將 kube-apiserver --http2-max-streams-per-connection 調整為 1000 以減輕痛苦。

您可以調整上面提供的值，也可以嘗試找出高負載/iops 的原因並嘗試將其調低。

Answer 2

答案原來是 iops 的問題，因為 du 命令來自 - 我認為 - cadvisor。 我已經轉移到 io1 盒子並且從那時起就很穩定，所以將其標記為關閉，並將 ec2 實例類型的移動標記為分辨率

謝謝您的幫助！

Answer 3

我遇到了同樣的問題，在 20-30 分鍾后，我的節點處於NotRready狀態，並且所有鏈接到這些節點的NotRready都陷入了Terminating狀態。
我嘗試通過 SSH 連接到我的節點，有時我會遇到超時，有時我可以（幾乎）連接，然后我執行top命令來檢查正在運行的進程。
消耗最大的進程是kswapd0 。
我的實例內存和CPU都滿了（！），因為它試圖交換很多（由於內存不足），導致kswapd0進程消耗了超過50％的CPU！

根本原因：
一些 Pod 消耗了 400% 的內存請求（在 Kubernetes 部署中定義），因為它們最初供應不足。 因此，當我的節點啟動時，Kubernetes 將它們放置在每個 pod 僅具有 32Mb 內存請求（我定義的值）的節點上，但這還不夠。

解決方案：
解決方案是增加容器請求：

requests:
  memory: "32Mi"
    cpu: "20m"
    limits:
       memory: "256Mi"
       cpu: "100m"

使用這些值（就我而言）：

requests:
  memory: "256Mi"
    cpu: "20m"
    limits:
       memory: "512Mi"
       cpu: "200m"

重要：
之后，我處理了節點的滾動更新（ cordon > drain > delete ），以確保 Kubernetes 直接為我剛啟動的 pod 保留足夠的內存。

結論：
定期檢查您的 Pod 的內存消耗，並隨着時間的推移調整您的資源請求。
目標是永遠不要讓您的節點對內存飽和感到驚訝，因為交換對您的節點來說可能是致命的。