針對狀況良好節點的未就緒狀態進行疑難解答
本文討論在節點處於狀況良好狀態一段時間之後,Azure Kubernetes Service (AKS) 叢集節點的狀態變更為[未就緒] 的案例。 本文概述特定原因,並提供可能的解決方案。
必要條件
- Kubernetes kubectl 工具。 若要使用 Azure CLI 安裝 kubectl,請執行 az aks install-cli 命令。
- Kubernetes kubelet 工具。
- 下列 Linux 工具:
徵狀
叢集節點狀態良好, (執行的所有服務) 意外變更為 [未就緒]。 若要檢視節點的狀態,請執行下列 kubectl describe 命令:
kubectl describe nodes
原因
kubelet 已停止張貼其就緒狀態。
檢查命令的 kubectl describe nodes
輸出,以尋找 [ 條件] 字 段和 [ 容量] 和 [Allocatable] 區 塊。 這些欄位的內容是否如預期般顯示? (例如,在 [ 條件] 字 段中,屬性是否 message
包含「kubelet 正在張貼就緒狀態」字串?) 在此情況下,如果您有直接安全殼層 (SSH) 節點的存取權,請檢查最近的事件以了解錯誤。 查看 /var/log/messages 檔案。 或者,執行下列殼層命令來產生 kubelet 和容器精靈記錄檔:
journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log
執行這些命令之後,請檢查精靈記錄檔,以取得錯誤的詳細數據。
步驟 1:檢查是否有任何網路層級變更
如果所有叢集節點都回歸為 「未就緒 」狀態,請檢查網路層級是否已發生任何變更。 網路層級變更的範例包括下列專案:
- 功能變數名稱系統 (DNS) 變更
- 防火牆埠變更
- 已新增網路安全組 (NSG)
如果網路層級有變更,請進行任何必要的更正。 在您修正問題之後,停止並重新啟動執行中的節點。 如果節點在這些修正之後維持在狀況良好的狀態,您可以放心地略過其餘步驟。
步驟 2:停止並重新啟動節點
如果只有少數節點回歸為 「未就緒」 狀態,只要停止並重新啟動節點即可。 此動作本身可能會讓節點恢復良好狀態。 然後,檢查 Azure Kubernetes Service 診斷概觀,以判斷是否有任何問題,例如下列問題:
- 節點錯誤
- SNAT) 失敗的來源網路位址轉換 (
- 每秒節點輸入/輸出作業 (IOPS) 效能問題
- 其他問題
如果診斷未發現任何基礎問題,您可以放心地略過其餘步驟。
步驟 3:修正公用 AKS API 叢集的 SNAT 問題
AKS 診斷是否發現任何 SNAT 問題? 如果是,請視需要採取下列一些動作:
檢查您的連線是否長時間處於閑置狀態,並依賴預設的閑置逾時來釋放其埠。 如果連線呈現此行為,您可能必須減少預設逾時 30 分鐘。
判斷您的應用程式如何建立輸出連線。 例如,它會使用程式代碼檢閱或封包擷取?
判斷此活動是否代表預期的行為,或改為顯示應用程式行為錯誤。 使用 Azure 監視器中的計量和記錄來證明您的發現。 例如,您可以使用 [失敗] 類別作為 SNAT Connections 度量。
評估是否遵循適當的模式。
評估您是否應該使用額外的輸出IP位址和更多配置的輸出埠來減輕SNAT埠耗盡。 如需詳細資訊,請參閱 調整受控輸出公用IP的數目 和 設定配置的輸出埠。
步驟 4:修正 IOPS 效能問題
如果 AKS 診斷發現會降低 IOPS 效能的問題,請視需要採取下列一些動作:
若要在 VM) 擴展集 (虛擬機上增加 IOPS,請部署新的節點集區來變更磁碟大小。
增加節點 SKU 大小,以增加記憶體和 CPU 處理功能。
請考慮使用 暫時OS。
限制 Pod 的 CPU 和記憶體使用量。 這些限制有助於防止節點 CPU 耗用量和記憶體不足的情況。
使用排程拓撲方法來新增更多節點,並將負載分散到節點之間。 如需詳細資訊,請參閱 Pod拓撲散布條件約束。
步驟 5:修正線程問題
kubelets 和 容器化運行時間 等 Kubernetes 元件高度依賴線程處理,而且會定期繁衍新的線程。 如果新線程的配置不成功,此失敗可能會影響服務整備程度,如下所示:
節點狀態會變更為 [未就緒],但會由補救程式重新啟動,而且能夠復原。
在 /var/log/messages 和 /var/log/syslog 記錄檔中,重複出現下列錯誤專案:
pthread_create失敗:各種進程暫時無法使用資源
所述的進程包括容器化和可能的 kubelet。
在失敗專案寫入記錄檔之後
pthread_create
,節點狀態會變更為 [未就緒]。
處理標識碼 (PID) 代表線程。 Pod 可以使用的預設 PID 數目可能取決於作業系統。 不過,預設數位至少為 32,768。 在大部分情況下,此數量超過足夠的 PID。 對於較高的 PID 資源,是否有任何已知的應用程式需求? 如果沒有,則即使將 8 倍增加至 262,144 個 PID 也可能不足以容納高資源應用程式。
請改為識別違規的應用程式,然後採取適當的動作。 請考慮其他選項,例如增加 VM 大小或升級 AKS。 這些動作可以暫時減輕問題,但無法保證問題不會再次出現。
若要監視每個控件群組的線程計數 (cgroup) 並列印前八個 cgroup,請執行下列殼層命令:
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 元件。
如需一般疑難解答步驟,請參閱 節點未就緒失敗的基本疑難解答。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應