針對狀況良好節點變更為 [未就緒] 狀態進行疑難解答

發行項
10/15/2024

本文討論在節點處於狀況良好狀態一段時間后，Azure Kubernetes Service （AKS）叢集節點的狀態會變更 為「未就緒 」的案例。本文概述特定原因，並提供可能的解決方案。

必要條件

Kubernetes kubectl 工具。若要使用 Azure CLI 安裝 kubectl，請執行 az aks install-cli 命令。
Kubernetes kubelet 工具。
Kubernetes 容器化工具。
下列 Linux 工具：
- awk
- 頭
- journalctl
- ps
- sort
- watch

徵兆

叢集節點的狀態，其狀態良好（所有正在執行的服務）意外變更為 [未就緒]。若要檢視節點的狀態，請執行下列 kubectl describe 命令：

kubectl describe nodes

原因

kubelet 已停止張貼其 [就緒] 狀態。

檢查命令的 kubectl describe nodes 輸出，以尋找 [ 條件 ] 字段和 [容量] 和 [ Allocatable 區塊]。這些欄位的內容是否如預期般顯示？（例如，在中條件字段，屬性是否 message 包含「kubelet 正在張貼就緒狀態」字串？）在此情況下，如果您有節點的直接安全殼層（SSH）存取權，請檢查最近的事件以了解錯誤。 查看 /var/log/messages 檔案。或者，執行下列殼層命令來產生 kubelet 和容器精靈記錄檔：

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

執行這些命令之後，請檢查訊息和精靈記錄檔，以取得錯誤的詳細資訊。

解決方案

步驟 1：檢查網路層級的變更

如果所有叢集節點都回歸到 「未就緒 」狀態，請檢查網路層級是否發生任何變更。網路層級變更的範例包括：

網域名稱系統 (DNS) 變更
防火牆規則變更，例如埠、完整功能變數名稱（FQDN）等等。
新增的網路安全性群組 (NSG)
已套用或變更 AKS 流量的路由表設定

如果網路層級有變更，請進行任何必要的修正。如果您有節點的直接安全殼層（SSH）存取權，您可以使用 curl 或 telnet 命令來檢查 AKS 輸出需求的連線能力。修正問題之後，請停止並重新啟動節點。如果節點在這些修正程序之後保持良好狀態，您可以放心地略過其餘步驟。

步驟 2：停止並重新啟動節點

如果只有少數節點回歸到 「未就緒 」狀態，只要停止並重新啟動節點即可。僅此動作就可能會將節點返回良好狀態。然後，檢查 Azure Kubernetes Service 診斷概觀，以判斷是否有任何問題，例如下列問題：

節點錯誤
來源網路位址轉譯 (SNAT) 失敗
節點每秒輸入/輸出作業 (IOPS) 效能問題
其他問題

如果診斷未發現任何基礎問題，且節點已返回 [就緒] 狀態，您可以安全地略過其餘步驟。

步驟 3：修正公用 AKS API 叢集的 SNAT 問題

AKS 診斷是否發現任何 SNAT 問題？如果是，請視需要採取下列一些動作：

檢查您的連線是否長時間保持閑置，並依賴默認閑置逾時來釋放其埠。如果連線顯示此行為，您可能必須減少預設逾時 30 分鐘。
判斷您的應用程式如何建立輸出連線能力。例如，它是否使用程式代碼檢閱或封包擷取？
判斷此活動是否代表預期的行為，或相反地顯示應用程式的行為錯誤。使用 Azure 監視器中的計量和記錄來證實您的發現。例如，您可以使用 [失敗 ] 類別做為 SNAT 連線計量。
評估是否遵循適當的模式。
評估是否應透過使用額外的輸出 IP 位址和更多配置的輸出連接埠，來緩解 SNAT 連接埠耗盡的情況。如需詳細資訊，請參閱調整受控輸出公用IP 的數目和設定配置的輸出埠。

如需如何針對 SNAT 埠 exhaution 進行疑難解答的詳細資訊，請參閱針對 AKS 節點上的 SNAT 埠耗盡進行疑難解答。

步驟 4：修正 IOPS 效能問題

如果 AKS 診斷發現降低 IOPS 效能的問題，請視需要採取下列一些動作：

若要增加虛擬機（VM）擴展集上的 IOPS，請選擇較大的磁碟大小，藉由部署新的節點集區來提供更好的 IOPS 效能。不支援直接調整 VMSS 的大小。如需調整節點集區大小的詳細資訊，請參閱調整 Azure Kubernetes Service （AKS）中的節點集區大小。
增加節點 SKU 大小，以取得更多記憶體與 CPU 處理功能。
請考慮使用暫時操作系統。
限制 Pod 的 CPU 與記憶體使用量。這些限制有助於防止節點 CPU 耗用量與記憶體不足的情況。
使用排程拓撲方法來新增更多節點，並將負載分散在節點之間。如需詳細資訊，請參閱 Pod拓撲散布條件約束。

步驟 5：修正線程問題

Kubernetes 元件，例如 kubelets 和容器運行時間嚴重依賴線程，而且會定期繁衍新的線程。如果新執行緒的配置不成功，則此失敗可能會影響服務整備程度，如下所示：

節點狀態會變更為 [未就緒]，但由補救程式重新啟動，而且能夠復原。
在 /var/log/messages 和 /var/log/syslog 記錄檔中，重複出現下列錯誤專案：

pthread_create 失敗：各種處理序暫時無法使用資源

所引用的處理序包含 containerd，也可能包含 kubelet。
節點狀態會在失敗專案寫入記錄檔之後不久變更為 [未就緒]。pthread_create

處理序識別碼 (PID) 代表執行緒。 Pod 可以使用的預設 PID 數目可能取決於作業系統。但是，預設數目至少為 32,768。在大部分情況下，此數量已超過足夠的 PID 數目。是否有任何已知的應用程式要求更高的 PID 資源？如果沒有，則即使增加八倍到 262,144 個 PID，也可能不足以適應高資源應用程式。

改為識別有問題的應用程式，然後採取適當的動作。考慮其他選項，例如增加 VM 大小或升級 AKS。這些動作可以暫時減輕問題，但不保證問題不會再次出現。

若要監視每個控制群組 (cgroup) 的執行緒計數，並列印前八個 cgroup，請執行下列 Shell 命令：

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

如需詳細資訊，請參閱進程標識碼限制和保留。

Kubernetes 提供了兩種在節點層級管理 PID 耗盡的方法：

使用 --pod-max-pids 參數，設定 kubelet 內 Pod 上允許的 PID 數目上限。此組態會在 pids.max 每個 Pod 的 cgroup 內設定設定。您也可以分別使用 --system-reserved 和 --kube-reserved 參數來設定系統和 kubelet 限制。
設定 PID 型收回。

注意

依預設，這兩種方法都不會設定。此外，您目前無法使用 AKS 節點集區的節點組態來設定任一方法。

步驟 6：使用較高的服務層級

您可以使用較高的服務層級，確定 AKS API 伺服器具有高可用性。如需詳細資訊，請參閱 Azure Kubernetes Service （AKS）執行時間 SLA。

其他相關資訊

若要檢視 AKS API 伺服器和 Kubelets 的健康情況和效能，請參閱受控 AKS 元件。
如需一般疑難解答步驟，請參閱節點未就緒失敗的基本疑難解答。

共用方式為