**協助改進此頁面** 

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 偵測節點運作狀態問題並啟用自動節點修復
<a name="node-health"></a>

節點運作狀態是指 Kubernetes 節點有效執行工作負載的操作狀態和功能。運作狀態良好的節點會維持預期的網路連線能力、有足夠的運算和儲存資源，而且可以成功執行工作負載而不會中斷。

為了協助在 EKS 叢集中維護正常運作的節點，EKS 提供*節點監控代理*程式和*自動節點修復*。這些功能會透過 EKS Auto Mode 運算自動啟用。您也可以搭配 EKS 受管節點群組和 Karpenter 使用自動節點修復，也可以搭配 AWS Fargate 以外的任何 EKS 運算類型使用 EKS 節點監控代理程式。EKS 節點監控代理程式和自動節點修復在一起使用時最有效，但也可以在 EKS 叢集中個別使用。

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

## 節點監控代理程式
<a name="node-monitoring-agent"></a>

EKS 節點監控代理程式會讀取節點日誌，以偵測運作狀態問題。它會剖析日誌，以偵測故障並顯示節點運作狀態的相關資訊。對於偵測到的每個問題類別，代理程式會將專用 `NodeCondition` 套用至工作者節點。如需 EKS 節點監控代理程式偵測到的節點運作狀態問題詳細資訊，請參閱 [使用 EKS 節點監控代理程式偵測節點運作狀態問題](node-health-nma.md)。

EKS Auto Mode 運算包含節點監控代理程式。對於其他 EKS 運算類型，您可以將節點監控代理程式新增為 EKS 附加元件，也可以使用 Helm 等 Kubernetes 工具進行管理。如需詳細資訊，請參閱[設定節點監控代理程式](node-health-nma.md#node-monitoring-agent-configure)。

使用 EKS 節點監控代理程式時，下列類別的節點運作狀態問題會呈現為節點條件。請注意，`Ready`、 `DiskPressure`和 `MemoryPressure`是標準 Kubernetes 節點條件，即使沒有 EKS 節點監控代理程式也會呈現。


| 節點條件 | Description | 
| --- | --- | 
|  AcceleratedHardwareReady  |  AcceleratedHardwareReady 指出節點上的加速硬體 (GPU、Neuron) 是否正常運作。  | 
|  ContainerRuntimeReady  |  ContainerRuntimeReady 指出容器執行時間 （容器等） 是否正常運作且能夠執行容器。  | 
|  DiskPressure  |  DiskPressure 是標準 Kubernetes 條件，表示節點遇到磁碟壓力 （磁碟空間不足或 I/O 高）。  | 
|  KernelReady  |  KernelReady 指出核心是否正常運作，而不會發生嚴重錯誤、恐慌或資源耗盡。  | 
|  MemoryPressure  |  MemoryPressure 是標準 Kubernetes 條件，表示節點正經歷記憶體壓力 （可用的記憶體不足）。  | 
|  NetworkingReady  |  NetworkingReady 指出節點的網路堆疊是否正常運作 （介面、路由、連線能力）。  | 
|  StorageReady  |  StorageReady 指出節點的儲存子系統是否正常運作 （磁碟、檔案系統、I/O)。  | 
|  備妥  |  Ready 是標準 Kubernetes 條件，表示節點運作狀態良好且已準備好接受 Pod。  | 

## 自動節點修復
<a name="node-auto-repair"></a>

EKS 自動節點修復會持續監控節點運作狀態、對偵測到的問題做出反應，並盡可能取代或重新啟動節點。這可在最少手動介入的情況下改善叢集可靠性，並有助於減少應用程式停機時間。

EKS 自動節點修復本身會回應 kubelet `Ready`的條件、任何手動刪除的節點物件，以及無法加入叢集的 EKS 受管節點群組執行個體。在安裝節點監控代理程式的情況下啟用 EKS 自動節點修復時，EKS 自動節點修復會回應其他節點條件：`AcceleratedHardwareReady`、`ContainerRuntimeReady`、`KernelReady`、 `NetworkingReady`和 `StorageReady`。

EKS 自動節點修復不會回應標準 Kubernetes `DiskPressure``MemoryPressure`、 或 `PIDPressure`節點條件。這些條件通常表示應用程式行為、工作負載組態或資源限制的問題，而不是節點層級失敗，因此難以判斷適當的預設修復動作。在這些情況下，工作負載會受到 Kubernetes [節點壓力移出行為](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction)的約束。

如需 EKS 自動節點修復的詳細資訊，請參閱 [自動修復 EKS 叢集中的節點](node-repair.md)。

**Topics**

# 使用 EKS 節點監控代理程式偵測節點運作狀態問題
<a name="node-health-nma"></a>

本主題詳細說明 EKS 節點監控代理程式偵測到的節點運作狀態問題、這些問題如何呈現為節點條件或事件，以及如何設定節點監控代理程式。

EKS 節點監控代理程式可以搭配或不搭配 EKS 自動節點修復使用。如需 EKS 自動節點修復的詳細資訊，請參閱 [自動修復 EKS 叢集中的節點](node-repair.md)。

EKS 節點監控代理程式的原始碼會發佈在 [aws/eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent) 儲存庫的 GitHub 上。

## 節點運作狀態問題
<a name="node-health-issues"></a>

下表中列出了節點監控代理程式能夠偵測的節點運作狀態問題。有兩種類型的問題：
+ 條件 – 必須執行修復動作的終端問題，例如，執行個體取代或重新啟動。啟用自動修復後，Amazon EKS 將執行修復動作，取代節點或重新啟動。如需詳細資訊，請參閱[節點條件](learn-status-conditions.md#status-node-conditions)。
+ 事件 – 暫時性問題或次佳節點組態。無須執行自動修復動作。如需詳細資訊，請參閱[事件節點](learn-status-conditions.md#status-node-events)。

## AcceleratedHardware 節點運作狀態問題
<a name="node-health-AcceleratedHardware"></a>

針對下表中所列嚴重性為「條件」的問題，監控條件為 `AcceleratedHardwareReady`。下表中的事件和條件適用於 NVIDIA 和 Neuron 相關的節點運作狀態問題。


| 名稱 | 嚴重性 | 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 錯誤。  |  無  | 

## NVIDIA XID 錯誤代碼
<a name="nvidia-xid-codes"></a>

節點監控代理程式會從 GPU 核心日誌偵測 NVIDIA XID 錯誤。XID 錯誤分為兩個類別：
+  **眾所周知的 XID 代碼** – 設定節點條件 (`AcceleratedHardwareReady=False`) 並在啟用時觸發自動修復的嚴重錯誤。原因碼格式為 `NvidiaXID[Code]Error`。EKS 節點監控代理程式偵測到的已知 XID 代碼可能不代表需要修復動作的 NVIDIA XID 代碼完整清單。
+  **未知 XID 代碼** – 僅記錄為 Kubernetes 事件。這些不會觸發自動修復。原因碼格式為 `NvidiaXID[Code]Warning`。若要調查未知的 XID 錯誤，請使用 檢閱您的核心日誌`dmesg | grep -i nvrm`。

若要了解 XID 錯誤的詳細資訊，請參閱 *NVIDIA GPU 部署與管理文件中*的 [Xid 錯誤](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1)。若要了解個別 XID 訊息的詳細資訊，請參閱 *NVIDIA GPU 部署與管理文件中*的[了解 Xid 訊息](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages)。

下表列出已知的 XID 代碼、其意義，以及啟用的預設節點修復動作。


| XID 代碼 | Description | 修復動作 | 
| --- | --- | --- | 
|  13  |  圖形引擎例外狀況 – 發生 GPU 圖形引擎錯誤，通常是由軟體問題或驅動程式錯誤造成。  |  重新啟動  | 
|  31  |  GPU 記憶體頁面故障 – 應用程式嘗試存取無法映射或可存取的 GPU 記憶體。  |  重新啟動  | 
|  48  |  雙位元 ECC 錯誤 – GPU 記憶體中發生無法修正的雙位元錯誤，表示潛在的硬體降級。  |  重新啟動  | 
|  63  |  GPU 記憶體重新映射事件 – GPU 驅動程式因為偵測到錯誤而重新映射一部分 GPU 記憶體。這通常可以復原。  |  重新啟動  | 
|  64  |  GPU 記憶體重新映射失敗 – GPU 無法重新映射故障的記憶體，表示硬體問題。  |  重新啟動  | 
|  74  |  NVLink 錯誤 – GPUs 之間的高速 NVLink 互連發生錯誤。  |  取代  | 
|  79  |  GPU 已脫離匯流排 – 無法再透過 PCIe 存取 GPU，通常表示硬體故障或電源問題。  |  取代  | 
|  94  |  包含的記憶體錯誤 – 發生記憶體錯誤，但已包含且不會影響其他應用程式。  |  重新啟動  | 
|  95  |  未包含的記憶體錯誤 – 發生記憶體錯誤，可能已影響其他應用程式或系統記憶體。  |  重新啟動  | 
|  119  |  GSP RPC 逾時 – 與 GPU 系統處理器的通訊逾時，可能是因為韌體問題。  |  取代  | 
|  120  |  GSP 錯誤 – GPU 系統處理器發生錯誤。  |  取代  | 
|  121  |  C2C 錯誤 – chip-to-chip互連 （用於多晶片 GPUs) 發生錯誤。  |  取代  | 
|  140  |  ECC 未復原錯誤 – ECC 錯誤逸出遏制，可能已損毀資料。  |  取代  | 

若要檢視與 GPU 運作狀態相關的目前節點條件，請執行下列命令。

```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```

若要檢視叢集上的 XID 相關事件，請執行下列其中一個命令。

```
kubectl get events | grep -i "NvidiaXID"
```

## ContainerRuntime 節點運作狀態問題
<a name="node-health-ContainerRuntime"></a>

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


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

## 核心節點運作狀態問題
<a name="node-health-Kernel"></a>

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


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

## 聯網節點運作狀態問題
<a name="node-health-Networking"></a>

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


| 名稱 | 嚴重性 | Description | 修復動作 | 
| --- | --- | --- | --- | 
|  BandwidthInExceeded  |  事件  |  因傳入的彙總頻寬超過執行個體的上限而排入佇列或丟棄的封包數目。  |  無  | 
|  BandwidthOutExceeded  |  事件  |  因傳出的彙總頻寬超過執行個體的上限而排入佇列或丟棄的封包數目。  |  無  | 
|  ConntrackExceeded  |  事件  |  連線追蹤超出執行個體上限，並且不能建立新的連線，這可能會導致封包遺失。  |  無  | 
|  EFAErrorMetric  |  事件  |  EFA 驅動程式指標顯示有一個具有效能降級的界面。  |  無  | 
|  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`，可能封鎖預期的流量。  |  無  | 

## 儲存節點運作狀態問題
<a name="node-health-Storage"></a>

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


| 名稱 | 嚴重性 | 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 平均叢集大小很小，表示可用空間分段過多。這可以防止在可用節點或可用空間的情況下建立檔案。  |  無  | 

## 設定節點監控代理程式
<a name="node-monitoring-agent-configure"></a>

EKS 節點監控代理程式會部署為 DaemonSet。當您將其部署為 EKS 附加元件時，您可以使用下列組態值來自訂安裝。如需預設組態，請參閱 EKS 節點監控代理程式 [Helm Chart](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml)。


| 組態選項 | Description | 
| --- | --- | 
|   `monitoringAgent.resources.requests.cpu`   |  監控代理程式的 CPU 資源請求。  | 
|   `monitoringAgent.resources.requests.memory`   |  監控代理程式的記憶體資源請求。  | 
|   `monitoringAgent.resources.limits.cpu`   |  監控代理程式的 CPU 資源限制。  | 
|   `monitoringAgent.resources.limits.memory`   |  監控代理程式的記憶體資源限制。  | 
|   `monitoringAgent.tolerations`   |  在污點節點上排程監控代理程式的容錯。  | 
|   `monitoringAgent.additionalArgs`   |  要傳遞給監控代理程式的其他命令列引數。  | 

**注意**  
您可以使用 EKS 附加元件或 Helm 安裝`verbosity``monitoringAgent.additionalArgs`來設定 `hostname-override`和 。您目前無法使用 EKS 附加元件`8002`或 Helm 安裝，透過其他 args 自訂節點監控代理程式的 `probe-address`() 或 `metrics-address`(`8003`)。

節點監控代理程式包含用於監控 NVIDIA GPUs 的 NVIDIA DCGM （資料中心 GPU Manager) 伺服器元件 (`nv-hostengine`)。此元件只會在屬於 NVIDIA GPU 執行個體類型的節點上執行，如代理程式 [Helm Chart](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) `nodeAffinity`中的 所示。您無法搭配 EKS 節點監控代理程式使用現有的 NVIDIA DCGM 安裝，如果您需要此功能，請針對 EKS 藍圖 [GitHub 問題 \$12763](https://github.com/aws/containers-roadmap/issues/2763) 提供意見回饋。

當您將 EKS 節點監控代理程式部署為 EKS 附加元件時，您可以使用下列組態值自訂 NVIDIA DCGM 安裝。


| 組態選項 | Description | 
| --- | --- | 
|   `dcgmAgent.resources.requests.cpu`   |  DCGM 代理程式的 CPU 資源請求。  | 
|   `dcgmAgent.resources.requests.memory`   |  DCGM 代理程式的記憶體資源請求。  | 
|   `dcgmAgent.resources.limits.cpu`   |  DCGM 代理程式的 CPU 資源限制。  | 
|   `dcgmAgent.resources.limits.memory`   |  DCGM 代理程式的記憶體資源限制。  | 
|   `dcgmAgent.tolerations`   |  在污點節點上排程 DCGM 代理程式的容錯。  | 

您可以使用下列 AWS CLI 命令來取得 EKS 節點監控代理程式 EKS 附加元件的版本和結構描述的實用資訊。

取得 Kubernetes 版本的最新代理程式附加元件版本。將 取代`1.35`為您的 Kubernetes 版本。

```
aws eks describe-addon-versions \
  --addon-name eks-node-monitoring-agent \
  --kubernetes-version 1.35 \
  --query='addons[].addonVersions[].addonVersion'
```

取得 EKS 附加元件中支援的代理程式附加元件結構描述。`v1.5.1-eksbuild.1` 將 取代為您的代理程式版本。

```
aws eks describe-addon-configuration \
  --addon-name eks-node-monitoring-agent \
  --addon-version v1.5.1-eksbuild.1
```

# 自動修復 EKS 叢集中的節點
<a name="node-repair"></a>

本主題詳細說明 EKS 自動節點修復行為，以及如何將其設定為滿足您的需求。EKS 自動節點修復預設為在 EKS Auto 模式中啟用，可與 EKS 受管節點群組和 Karpenter 搭配使用。

預設 EKS 自動節點修復動作摘要如下表所示，適用於 EKS Auto Mode、EKS 受管節點群組和 Karpenter 的行為。使用 EKS Auto Mode 或 Karpenter 時，所有`AcceleratedHardwareReady`修復動作都是 `Replace`，只有 EKS 受管節點群組支援`Reboot`做為修復動作。

如需 EKS 節點監控代理程式偵測到的節點運作狀態問題及其對應節點修復動作的詳細清單，請參閱 [使用 EKS 節點監控代理程式偵測節點運作狀態問題](node-health-nma.md)。


| 節點條件 | Description | 在 之後修復 | 修復動作 （多個） | 
| --- | --- | --- | --- | 
|  AcceleratedHardwareReady  |  AcceleratedHardwareReady 指出節點上的加速硬體 (GPU、Neuron) 是否正常運作。  |  10m  |  取代或重新啟動  | 
|  ContainerRuntimeReady  |  ContainerRuntimeReady 指出容器執行時間 （容器等） 是否正常運作且能夠執行容器。  |  30m  |  取代  | 
|  DiskPressure  |  DiskPressure 是標準 Kubernetes 條件，表示節點遇到磁碟壓力 （磁碟空間不足或 I/O 高）。  |  N/A  |  無  | 
|  KernelReady  |  KernelReady 指出核心是否正常運作，而不會發生嚴重錯誤、恐慌或資源耗盡。  |  30m  |  取代  | 
|  MemoryPressure  |  MemoryPressure 是標準 Kubernetes 條件，表示節點正經歷記憶體壓力 （可用的記憶體不足）。  |  N/A  |  無  | 
|  NetworkingReady  |  NetworkingReady 指出節點的網路堆疊是否正常運作 （介面、路由、連線能力）。  |  30m  |  取代  | 
|  StorageReady  |  StorageReady 指出節點的儲存子系統是否正常運作 （磁碟、檔案系統、I/O)。  |  30m  |  取代  | 
|  備妥  |  Ready 是標準 Kubernetes 條件，表示節點運作狀態良好且已準備好接受 Pod。  |  30m  |  取代  | 

在下列情況下，EKS 自動節點修復動作預設為停用。在每個案例中，進行中的節點修復動作都會繼續。如需如何覆寫這些預設設定[設定自動節點修復](#configure-node-repair)，請參閱 。

 **EKS 受管節點群組** 
+ 節點群組有超過五個節點，且節點群組中超過 20% 的節點運作狀態不佳。
+ 透過應用程式復原控制器 (ARC) 觸發叢集的區域轉移。

 **EKS 自動模式和 Karpenter** 
+ NodePool 中超過 20% 的節點運作狀態不佳。
+ 對於獨立 NodeClaims，叢集中的 20% 節點運作狀態不佳。

## 設定自動節點修復
<a name="configure-node-repair"></a>

使用 EKS Auto Mode 時，無法設定自動節點修復，且一律以與 Karpenter 相同的預設設定啟用。

### Karpenter
<a name="configure-node-repair-karpenter"></a>

若要搭配 Karpenter 使用自動節點修復，請啟用功能閘道 `NodeRepair=true`。您可以透過 CLI `--feature-gates` 選項或 Karpenter 部署中的`FEATURE_GATES`環境變數來啟用功能閘道。如需詳細資訊，請參閱 [Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair) 文件。

### 受管節點群組
<a name="configure-node-repair-mng"></a>

您可以在建立新的 EKS 受管節點群組或更新現有的 EKS 受管節點群組時啟用自動節點修復。
+  **Amazon EKS 主控台** – 選取受管**節點群組的啟用節點自動修復**核取方塊。如需詳細資訊，請參閱[建立叢集的受管節點群組](create-managed-node-group.md)。
+  ** AWS CLI** – `--node-repair-config enabled=true`新增至 [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html)或 [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html)命令。
+  **eksctl** – 設定 `managedNodeGroups.nodeRepairConfig.enabled: true`，請參閱 [eksctl GitHub](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml) 中的範例。

使用 EKS 受管節點群組時，您可以使用下列設定控制節點自動修復行為。

若要控制節點自動修復何時停止採取動作，請根據節點群組中運作狀態不佳的節點數目來設定閾值。設定絕對計數或百分比，但不能同時設定兩者。


| 設定 | Description | 
| --- | --- | 
|   `maxUnhealthyNodeThresholdCount`   |  節點自動修復停止運作狀態不佳的節點絕對數量。使用此項目來限制修復的範圍。  | 
|   `maxUnhealthyNodeThresholdPercentage`   |  節點自動修復停止運作狀態不佳的節點百分比 (0-100)。  | 

若要控制同時修復的節點數量，您可以設定修復平行處理。如同運作狀態不佳的節點閾值，請設定絕對計數或百分比，但不能同時設定兩者。


| 設定 | Description | 
| --- | --- | 
|   `maxParallelNodesRepairedCount`   |  要同時修復的節點數目上限。  | 
|   `maxParallelNodesRepairedPercentage`   |  要同時修復的不良節點百分比上限 (0-100)。  | 

使用 `nodeRepairConfigOverrides`，您可以針對特定條件自訂修復行為。當您需要不同的修復動作或不同問題類型的等待時間時，請使用此選項。

每個覆寫都需要下列所有欄位：


| 欄位 | Description | 
| --- | --- | 
|   `nodeMonitoringCondition`   |  節點監控代理程式報告的節點條件類型。例如：`AcceleratedHardwareReady`、`NetworkingReady`、`StorageReady`、`KernelReady`。  | 
|   `nodeUnhealthyReason`   |  狀況不良的特定原因代碼。例如：`NvidiaXID31Error`、`IPAMDNotRunning`。  | 
|   `minRepairWaitTimeMins`   |  在節點符合修復資格之前，條件必須保留的最短時間，以分鐘為單位。使用此選項可避免針對暫時問題修復節點。  | 
|   `repairAction`   |  符合條件時要採取的動作。有效值： `Replace`（終止並取代節點）、 `Reboot`（重新啟動節點） 或 `NoAction`（無修復動作）。  | 

下列 AWS CLI 範例會建立具有自訂修復設定的節點群組。

```
aws eks create-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --node-role arn:aws:iam::111122223333:role/NodeRole \
  --subnets subnet-0123456789abcdef0 \
  --node-repair-config '{
    "enabled": true,
    "maxUnhealthyNodeThresholdPercentage": 10,
    "maxParallelNodesRepairedCount": 3,
    "nodeRepairConfigOverrides": [
      {
        "nodeMonitoringCondition": "AcceleratedHardwareReady",
        "nodeUnhealthyReason": "NvidiaXID64Error",
        "minRepairWaitTimeMins": 5,
        "repairAction": "Replace"
      },
      {
        "nodeMonitoringCondition": "AcceleratedHardwareReady",
        "nodeUnhealthyReason": "NvidiaXID31Error",
        "minRepairWaitTimeMins": 15,
        "repairAction": "NoAction"
      }
    ]
  }'
```

此組態會執行下列動作：
+ 啟用節點自動修復
+ 當超過 10% 的節點運作狀態不佳時，停止修復動作
+ 一次最多可修復 3 個節點
+ 覆寫 XID 64 錯誤 (GPU 記憶體重新映射失敗），以在 5 分鐘後取代節點。預設值為 10 分鐘後重新啟動。
+ 覆寫 XID 31 錯誤 (GPU 記憶體頁面錯誤） 不採取任何動作。預設值為 10 分鐘後重新啟動。

# 檢視節點的運作狀態
<a name="learn-status-conditions"></a>

本主題說明可用於監控 Amazon EKS 叢集中節點運作狀態的工具和方法。相關資訊涵蓋節點條件、事件和偵測案例，可協助您識別和診斷節點層級問題。使用此處所述的命令和模式來檢查節點運作狀態資源、解譯狀態條件，並分析節點事件以進行操作故障診斷。

您可以針對所有節點使用 Kubernetes 命令，以取得一些節點運作狀態資訊。此外，如果您透過 Amazon EKS 自動模式或 Amazon EKS 受管附加元件使用節點監控代理程式，您將會取得更多種類的節點訊號，進而協助故障診斷。在可觀測性儀表板中，還會提供節點監控代理程式偵測的運作狀態問題說明。如需詳細資訊，請參閱[使用 EKS 節點監控代理程式偵測節點運作狀態問題](node-health-nma.md)。

## 節點條件
<a name="status-node-conditions"></a>

節點條件代表需要修復動作的終端問題，例如執行個體替換或重新啟動。

 **若要取得所有節點的條件：**

```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```

 **若要取得特定節點的詳細條件** 

```
kubectl describe node node-name
```

 **運作狀態良好的節點的範例條件輸出：**

```
  - lastHeartbeatTime: "2024-11-21T19:07:40Z"
    lastTransitionTime: "2024-11-08T03:57:40Z"
    message: Monitoring for the Networking system is active
    reason: NetworkingIsReady
    status: "True"
    type: NetworkingReady
```

 **存在聯網問題的運作狀態不佳的節點的範例條件：**

```
  - lastHeartbeatTime: "2024-11-21T19:12:29Z"
    lastTransitionTime: "2024-11-08T17:04:17Z"
    message: IPAM-D has failed to connect to API Server which could be an issue with
      IPTable rules or any other network configuration.
    reason: IPAMDNotReady
    status: "False"
    type: NetworkingReady
```

## 事件節點
<a name="status-node-events"></a>

節點事件表示暫時性問題或非最佳化的組態。

 **若要取得節點監控代理程式報告的所有事件** 

節點監控代理程式可用時，您可以執行下列命令。

```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```

輸出範例：

```
LAST SEEN   TYPE      REASON       OBJECT                                              MESSAGE
4s          Warning   SoftLockup   node/ip-192-168-71-251.us-west-2.compute.internal   CPU stuck for 23s
```

 **若要取得所有節點的事件** 

```
kubectl get events --field-selector involvedObject.kind=Node
```

 **若要取得特定節點的事件** 

```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```

 **若要即時監看事件** 

```
kubectl get events -w --field-selector involvedObject.kind=Node
```

 **範例事件輸出：**

```
LAST SEEN   TYPE     REASON           OBJECT         MESSAGE
2m          Warning  MemoryPressure   Node/node-1    Node experiencing memory pressure
5m          Normal   NodeReady        Node/node-1    Node became ready
```

## 常見的故障診斷命令
<a name="status-node-troubleshooting"></a>

```
# Get comprehensive node status
kubectl get node node-name -o yaml

# Watch node status changes
kubectl get nodes -w

# Get node metrics
kubectl top node
```

# 使用 kubectl 及 S3 擷取受管節點的節點日誌
<a name="auto-get-logs"></a>

了解如何為已安裝節點監控代理程式的 Amazon EKS 受管節點擷取節點記錄。

## 先決條件
<a name="_prerequisites"></a>

請確認您已具備以項目：
+ 現有已安裝節點監控代理程式的 Amazon EKS 叢集。如需詳細資訊，請參閱[偵測節點運作狀態問題並啟用自動節點修復](node-health.md)。
+ 已安裝並設定為可與您叢集通訊的 `kubectl` 命令列工具。
+ 安裝並登入 AWS 的 CLI 具有足夠的許可來建立 S3 儲存貯體和物件。
+ 已安裝最新版本 Python 3
+ 已安裝適用於 Python 3、Boto 3 的 AWS SDK。

## 步驟 1：建立 S3 儲存貯體目的地 (選用)
<a name="_step_1_create_s3_bucket_destination_optional"></a>

若您還沒有 S3 儲存貯體來儲存日誌，請先建立一個。使用下列 AWS CLI 命令。儲存貯體預設為 `private` 存取控制清單。以您選擇的唯一儲存貯體名稱取代 *bucket-name*。

```
aws s3api create-bucket --bucket <bucket-name>
```

## 步驟 2：建立用於 HTTP Put 的預先簽章 S3 URL
<a name="_step_2_create_pre_signed_s3_url_for_http_put"></a>

Amazon EKS 透過對您指定的 URL 執行 HTTP PUT 操作來回傳節點記錄。在本教學中，我們將產生一個預先簽章的 S3 HTTP PUT URL。

日誌會以 gzip 壓縮的 tar 檔 (副檔名為 `.tar.gz`) 形式傳回。

**注意**  
您必須使用 AWS API 或 SDK 來建立預先簽章的 S3 上傳 URL，以供 EKS 上傳日誌檔案。您無法使用 CLI 建立預先簽章的 S3 AWS 上傳 URL。

1. 決定您要在儲存貯體中的哪個位置儲存日誌。例如，您可以使用 *2024-11-12/logs1.tar.gz* 做為金鑰。

1. 將下列 Python 程式碼儲存至檔案 https：//*presign-upload.py*。取代 *<bucket-name>* 和 *<key>*。金鑰應以 `.tar.gz` 結尾。

   ```
   import boto3; print(boto3.client('s3').generate_presigned_url(
      ClientMethod='put_object',
      Params={'Bucket': '<bucket-name>', 'Key': '<key>'},
      ExpiresIn=1000
   ))
   ```

1. 使用以下命令執行指令碼

   ```
   python presign-upload.py
   ```

1. 記錄 URL 輸出。在下一個步驟中使用此值做為 *http-put-destination*。

如需詳細資訊，請參閱[在適用於 Python 文件的Boto3 開發套件中產生預先簽章的 URL 以上傳檔案](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file)。 AWS Boto3 

## 步驟 3：建立 NodeDiagnostic 資源
<a name="_step_3_create_nodediagnostic_resource"></a>

識別您要從中收集日誌的節點名稱。

建立 `NodeDiagnostic` 資訊清單，使用該節點名稱作為資源名稱，並提供 HTTP PUT URL 目的地。

```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
    name: <node-name>
spec:
    logCapture:
        destination: http-put-destination
```

將清單檔案套用至叢集。

```
kubectl apply -f nodediagnostic.yaml
```

您可以透過描述 `NodeDiagnostic` 資源以檢查集合的狀態：
+ 狀態為 `Success` 或 `SuccessWithErrors` 表示任務已完成，且日誌已上傳到提供的目的地 (`SuccessWithErrors` 表示可能缺少部分日誌)
+ 如果狀態為「失敗」，請確認上傳 URL 格式正確且未過期。

```
kubectl describe nodediagnostics.eks.amazonaws.com/<node-name>
```

## 步驟 4：從 S3 下載日誌
<a name="_step_4_download_logs_from_s3"></a>

請等待大約一分鐘再嘗試下載日誌。然後使用 S3 CLI 下載日誌。

```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3://<bucket-name>/key ./<path-to-node-logs>.tar.gz
```

## 步驟 5：清理 NodeDiagnostic 資源
<a name="_step_5_clean_up_nodediagnostic_resource"></a>
+  `NodeDiagnostic` 資源不會自動刪除。取得日誌成品後，您應自行清除這些項目

```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/<node-name>
```

## NodeDiagnostic `node` 目的地
<a name="_nodediagnostic_node_destination"></a>

從節點監控代理`v1.6.0`程式的版本開始，您可以選擇將日誌收集目的地設定為 `node`。使用此目的地將導致節點上日誌的收集和暫時保留，以供稍後收集。除了此功能之外，在節點監控代理程式的 GitHub 儲存庫中，您還可以安裝 `kubectl` 外掛程式，以便輕鬆互動和收集日誌。如需詳細資訊，請參閱 [`kubectl ekslogs` 外掛程式的文件](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md)。

## 使用範例
<a name="_example_usage"></a>

```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs <node-name>

# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs <node-name-1> <node-name-2> <node-name-3>

# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l <key>=<value>
```