針對狀況良好節點的未就緒狀態進行疑難解答

  • 發行項

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

必要條件

徵狀

叢集節點狀態良好， (執行的所有服務) 意外變更為 [未就緒]。 若要檢視節點的狀態，請執行下列 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 耗盡：

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

  2. 設定以 PID 為基礎的收回。

注意事項

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

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

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

其他相關資訊