啟用節點自動修復並調查節點運作狀態問題

節點運作狀態是指節點有效執行工作負載的運作狀態與能力。若節點運作狀態良好，則能夠維持預期的連線能力、具備充足的資源，以及能夠在不中斷的情況下成功執行 Pod。如需獲取節點相關詳細資訊，請參閱檢視節點的運作狀態與使用 kubectl 及 S3 擷取受管節點的節點日誌。

Amazon EKS 提供了節點監控代理程式與節點自動修復功能，以協助確保節點運作良好。

重要

節點監控代理程式與節點自動修復功能僅適用於 Linux。這些功能不適用於 Windows。

節點監控代理程式

節點監控代理程式會自動讀取節點日誌，以偵測特定運作狀態問題。該功能可剖析節點日誌來偵測故障，以及顯示工作節點的各種狀態資訊。針對偵測到的每種問題類別，例如儲存問題與聯網問題，在工作節點上套用專門的 NodeCondition。在可觀測性儀表板中，提供了偵測的運作狀態問題說明。如需詳細資訊，請參閱節點運作狀態問題。

在所有 Amazon EKS 自動模式叢集中，均包括節點監控代理程式功能。針對其他叢集類型，您可作為 Amazon EKS 附加元件來新增監控代理程式功能。如需詳細資訊，請參閱建立 Amazon EKS 附加元件。

節點自動修復

節點自動修復是一項新增功能，能夠持續監控節點的運作狀態、自動回應偵測的問題，以及儘可能地取代節點。此功能有助於提高叢集的整體可用性，並且盡可能減少手動介入。若運作狀態檢查失敗，可自動隔離節點，以免在節點上排程新的 Pod。

節點自動修復本身可以對 kubelet 的 Ready 狀況，以及對手動刪除的任何節點物件做出反應。當與節點監控代理程式配對時，節點自動修復可以對更多無法偵測到的情況做出反應。這些額外的情況包括 KernelReady、NetworkingReady 和 StorageReady。

此自動化節點復原會自動解決間歇性的節點問題，例如無法加入叢集、無回應的 kubelet，以及加速器 (裝置) 錯誤增加。可靠性改善後，有助於減少應用程式停機時間並改善叢集運作。節點自動修復不能處理報告的某些問題，例如 DiskPressure、MemoryPressure 及 PIDPressure。Amazon EKS 在針對 AcceleratedHardwareReady NodeConditions 執行動作之前會等候 10 分鐘，針對其他條件則會等候 30 分鐘。

在兩種情境下，受管節點群組亦會出於安全考量自動停用節點修復。針對兩種情境，之前進行中的任何修復操作皆會繼續。

若已透過 Application Recovery Controller (ARC) 觸發叢集區域轉移，則會終止所有後續修復操作。
若節點群組擁有五個以上的節點，並且節點群組中超過 20% 的節點運作狀態不佳，則會終止修復操作。

在建立或編輯受管節點群組後，您可啟用節點自動修復。

使用 Amazon EKS 主控台時，可為受管節點群組啟用節點自動修復核取方塊。如需詳細資訊，請參閱建立叢集的受管節點群組。
使用 AWS CLI 時，請將 --node-repair-config enabled=true新增至 eks create nodegroup或 eks update-nodegroup-config命令。
若要了解 eksctl ClusterConfig 使用啟用了自動修復功能的受管節點群組的範例，請參閱 GitHub 上的 44-node-repair.yaml。

Amazon EKS 透過以下功能，能夠更精細地控制節點自動修復行為：

maxUnhealthyNodeThresholdCount 和 maxUnhealthyNodeThresholdPercentage
- 藉助這些欄位，您可指定運作狀態不佳的節點數量或百分比閾值，若超過此閾值，則會停止節點自動修復動作。這樣一來可更好地控制節點自動修復的「影響範圍」。
- 您可設定絕對數量或百分比，但無法同時設定兩者。
maxParallelNodesRepairedCount 和 maxParallelNodesRepairedPercentage
- 藉助這些欄位，您可指定能夠同時或平行修復的最大節點數量，以數量或百分比來表示所有運作狀態不佳的節點。這樣一來，您就能更精細地控制節點取代速度。
- 與運作狀態不佳的節點閾值一樣，您可設定絕對數量或百分比，但無法同時設定兩者。
nodeRepairConfigOverrides
- 這是一個複雜的結構，您可以針對特定修復動作來設定精細的覆寫。透過這些覆寫，可控制認為節點符合修復資格之前的修復動作與修復延遲時間。
- 此結構中的特定欄位包括：
  - nodeMonitoringCondition：節點監控代理程式報告的運作不佳狀態。
  - nodeUnhealthyReason：節點監控代理程式確定節點運作狀態不佳的原因。
  - minRepairWaitTimeMins：節點符合修復資格之前，修復條件與運作狀態不佳原因必須保持的最短時間 (分鐘)。
  - repairAction：滿足上述條件後，修復系統應執行的動作。
- 若您使用此欄位，必須在結構中指定所有欄位。您還可提供這些覆寫的清單。
- nodeMonitoringCondition 與 nodeUnhealthyReason 是您設定的手動文字輸入，表明您想要偏離系統的預設行為。
- minRepairWaitTimeMins 與 repairAction 欄位允許您指定與系統預設行為的偏離。

節點運作狀態問題

下表中列出了節點監控代理程式能夠偵測的節點運作狀態問題。有兩種類型的問題：

條件 – 必須執行修復動作的終端問題，例如，執行個體取代或重新啟動。啟用自動修復後，Amazon EKS 將執行修復動作，取代節點或重新啟動。如需詳細資訊，請參閱節點條件。
事件 – 暫時性問題或次佳節點組態。無須執行自動修復動作。如需詳細資訊，請參閱事件節點。

AcceleratedHardware 節點運作狀態問題

針對下表中所列嚴重性為「條件」的問題，監控條件為 AcceleratedHardwareReady。

若啟用自動修復，在偵測到問題後 10 分鐘內，即會開始執行所列修復動作。若要了解 XID 錯誤的詳細資訊，請參閱 NVIDIA GPU 部署與管理文件中的 Xid 錯誤。若要了解個別 XID 訊息的詳細資訊，請參閱 NVIDIA GPU 部署與管理文件中的了解 Xid 訊息。

Name	嚴重性	Description
DCGMDiagnosticFailure	條件	DCGM 作用中診斷測試套件的測試案例失敗。
DCGMError	條件	DCGM 主機程序的連線遺失或無法建立。
DCGMFieldError【代碼】	事件	DCGM 透過欄位識別符偵測到 GPU 降級。
DCGMHealthCode【Code】	事件	DCGM 運作狀態檢查以非嚴重方式失敗。
DCGMHealthCode【Code】	條件	DCGM 運作狀態檢查嚴重失敗。
NeuronDMAError	條件	DMA 引擎遇到無法復原的錯誤。
NeuronHBMUncorrectableError	條件	HBM 遇到無法修正的錯誤，且產生了錯誤結果。
NeuronNCUncorrectableError	條件	偵測到 Neuron Core 無法修正的記憶體錯誤。
NeuronSRAMUncorrectableError	條件	晶片上 SRAM 遇到同位錯誤，且產生了錯誤結果。
NvidiaDeviceCountMismatch	事件	透過 NVML 可見的 GPUs 數量與檔案系統上的 NVIDIA 裝置計數不一致。
NvidiaDoubleBitError	條件	GPU 驅動程式產生了雙位元錯誤。
NvidiaNCCLError	事件	NVIDIA Collective Communications 程式庫 () 中發生分段錯誤`libnccl`。
NvidiaNVLinkError	條件	GPU 驅動程式報告了 NVLink 錯誤。
NvidiaPCIeError	事件	觸發 PCIe 重播以從傳輸錯誤中復原。
NvidiaPageRetirement	事件	GPU 驅動程式已標記記憶體頁面進行淘汰。若在同一位址遇到單一雙位元錯誤或兩個單一位元錯誤，可能會發生此情況。
NvidiaPowerError	事件	GPUs 的用電量超過允許的閾值。
NvidiaThermalError	事件	GPUs 的熱狀態超過允許的閾值。
NvidiaXID【Code】Error	條件	發生嚴重 GPU 錯誤。
NvidiaXID[Code]Warning	事件	發生非關鍵 GPU 錯誤。

ContainerRuntime 節點運作狀態問題

針對下表中所列嚴重性為「條件」的問題，監控條件為 ContainerRuntimeReady。

Name	嚴重性	Description
ContainerRuntimeFailed	事件	容器執行時期未能建立容器，若重複發生，很可能與任何報告的問題相關。
DeprecatedContainerdConfiguration	事件	使用已棄用的映像資訊清單第 2 版的容器映像，結構描述 1 最近透過提取至節點`containerd`。
KubeletFailed	事件	kubelet 進入失敗狀態。
LivenessProbeFailures	事件	偵測到活體探查失敗，若重複發生，可能表明應用程式碼問題或逾時值不足。
PodStuckTerminating	條件	Pod 終止或終止時凍結時間過長，可能是由於阻止 Pod 狀態進度的 CRI 錯誤所致。
ReadinessProbeFailures	事件	偵測到整備探查失敗，若重複發生，可能表明應用程式碼問題或逾時值不足。
【Name】RepeatedRestart	事件	系統化單位經常重新啟動。
ServiceFailedToStart	事件	未能啟動系統化單元。

核心節點運作狀態問題

針對下表中所列嚴重性為「條件」的問題，監控條件為 KernelReady。

Name	嚴重性	Description
AppBlocked	事件	排程導致任務已遭到長時間封鎖，通常是由於輸入或輸出遭到封鎖所致。
AppCrash	事件	節點上的應用程式已當機。
ApproachingKernelPidMax	事件	程序數目接近目前`kernel.pid_max`設定可用的 PIDs 數目上限，之後就無法再啟動任何程序。
ApproachingMaxOpenFiles	事件	依據目前的核心設定，開啟的檔案數目正在接近可開啟的最大檔案數目，之後將無法開啟新檔案。
ConntrackExceededKernel	事件	連線追蹤超出核心上限，並且不能建立新的連線，這可能會導致封包遺失。
ExcessiveZombieProcesses	事件	若程序不能完全回收，則會大量累積，這表明存在應用程式問題，並且可能會導致達到系統程序限制。
ForkFailedOutOfPIDs	條件	系統缺少程序 ID 或記憶體導致分支或執行呼叫失敗，這可能是由於殭屍程序或實體記憶體耗盡所致。
KernelBug	事件	Linux 核心本身偵測並報告了核心錯誤，但此錯誤有時可能是由於節點具有高 CPU 或記憶體而導致事件處理延遲所致。
LargeEnvironment	事件	此程序的環境變數數量大於預期，可能是由許多將 `enableServiceLinks`設為 true 的服務所造成，這可能會導致效能問題。
RapidCron	事件	此節點上每五分鐘的 Cron 任務執行速度更快，若任務取用大量資源，則可能會影響效能。
SoftLockup	事件	CPU 在一定時間內停滯。

聯網節點運作狀態問題

針對下表中所列嚴重性為「條件」的問題，監控條件為 NetworkingReady。

Name	嚴重性	Description
BandwidthInExceeded	事件	因傳入的彙總頻寬超過執行個體的上限而排入佇列或丟棄的封包數目。
BandwidthOutExceeded	事件	因傳出的彙總頻寬超過執行個體的上限而排入佇列或丟棄的封包數目。
ConntrackExceeded	事件	連線追蹤超出執行個體上限，並且不能建立新的連線，這可能會導致封包遺失。
IPAMDInconsistentState	事件	磁碟上 IPAMD 檢查點的狀態不會反映容器執行時間中的 IPs。
IPAMDNoIPs	事件	IPAMD 沒有 IP 地址。
IPAMDNotReady	條件	IPAMD 未能連線至 API 伺服器。
IPAMDNotRunning	條件	找不到正在執行的 Amazon VPC CNI 程序。
IPAMDRepeatedlyRestart	事件	IPAMD 服務發生多次重新啟動。
InterfaceNotRunning	條件	此介面看起來未在執行中，或者存在網路問題。
InterfaceNotUp	條件	此介面看起來未啟用，或者存在網路問題。
KubeProxyNotReady	事件	Kube-proxy 未能監看或列示資源。
LinkLocalExceeded	事件	由於本機代理伺服器服務的流量 PPS 超過網路介面上限而丟棄的封包數目。
MACAddressPolicyMisconfigured	事件	systemd-networkd 連結組態的值不正確`MACAddressPolicy`。
MissingDefaultRoutes	事件	缺少預設路由規則。
MissingIPRoutes	事件	Pod IPs 缺少路由。
MissingIPRules	事件	Pod IPs 缺少規則。
MissingLoopbackInterface	條件	此執行個體缺少迴路介面，從而導致服務未能執行，具體取決於本機連線。
NetworkSysctl	事件	此節點的網路`sysctl`設定可能不正確。
PPSExceeded	事件	因雙向 PPS 超過執行個體的上限而排入佇列或丟棄的封包數目。
PortConflict	事件	如果 Pod 使用 hostPort，它可以寫入覆寫主機已繫結連接埠的`iptables`規則，從而可能阻止 API 伺服器存取 `kubelet`。
UnexpectedRejectRule	事件	在中找到非預期的 `REJECT`或 `DROP`規則`iptables`，可能封鎖預期的流量。

儲存節點運作狀態問題

針對下表中所列嚴重性為「條件」的問題，監控條件為 StorageReady。

Name	嚴重性	Description
EBSInstanceIOPSExceeded	事件	已超過執行個體的 IOPS 上限。
EBSInstanceThroughputExceeded	事件	已超過執行個體的最大輸送量。
EBSVolumeIOPSExceeded	事件	已超過特定 EBS 磁碟區的 IOPS 上限。
EBSVolumeThroughputExceeded	事件	已超過特定 Amazon EBS 磁碟區的最大輸送量。
EtcHostsMountFailed	事件	由於使用者資料在`kubelet-container`操作`/var/lib/kubelet/pods`期間重新掛載，因此產生的 kubelet 掛載`/etc/hosts`失敗。
IODelays	事件	程序中偵測到輸入或輸出延遲，若過多，可能表明輸入輸出佈建不足。
KubeletDiskUsageSlow	事件	`kubelet` 會在嘗試存取檔案系統時報告磁碟使用量緩慢。這可能表示磁碟輸入輸出不足或檔案系統問題。
XFSSmallAverageClusterSize	事件	XFS 平均叢集大小很小，表示可用空間分段過多。這可以防止建立檔案，即使有可用的節點或可用空間。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

自訂建置

檢視節點運作狀態