**協助改進此頁面** 

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

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

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

# EKS 自動模式疑難排解
<a name="auto-troubleshoot"></a>

使用 EKS Auto 模式時， 會 AWS 對您 AWS 帳戶中的 EC2 執行個體承擔更多責任。EKS 負責節點上的容器執行時期、節點上的作業系統，以及某些控制器。這包括區塊儲存控制器、負載平衡控制器及運算控制器。

您必須使用 AWS 和 Kubernetes APIs 對節點進行故障診斷。您可以：
+ 使用 Kubernetes `NodeDiagnostic` 資源，透過 [節點監控代理程式](#auto-node-monitoring-agent) 來擷取節點日誌。如需更多步驟，請參閱 [使用 kubectl 及 S3 擷取受管節點的節點日誌](auto-get-logs.md)。
+ 使用 Kubernetes `NodeDiagnostic` 資源擷取節點上的網路流量。如需更多步驟，請參閱 [使用 kubectl 和 S3 擷取受管節點上的網路流量](auto-get-tcpdump.md)。
+ 使用 AWS EC2 CLI 命令從節點`get-console-output`擷取主控台輸出。如需更多步驟，請參閱 [使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出](#auto-node-console)。
+ 使用 Kubernetes *偵錯容器*來擷取節點日誌。如需更多步驟，請參閱 [使用*偵錯容器*和 `kubectl` CLI 取得節點日誌](#auto-node-debug-logs)。

**注意**  
EKS 自動模式使用 EC2 受管執行個體。您無法直接存取 EC2 受管執行個體，包括透過 SSH。

您可能會遇到以下特定於 EKS 自動模式元件的問題及解決方案：
+ Pod 卡在 `Pending` 狀態，無法排程到自動模式節點上。解決方案請參閱 [對 Pod 無法排程到自動模式節點進行疑難排解](#auto-troubleshoot-schedule)。
+ EC2 受管執行個體無法以 Kubernetes 節點身分加入叢集。解決方案請參閱 [對未加入叢集的節點進行疑難排解](#auto-troubleshoot-join)。
+ 使用 EKS 自動模式中包含的控制器的 `NodePools`、`PersistentVolumes` 和 `Services` 出現錯誤和問題。解決方案請參閱 [對自動模式中包含的控制器進行疑難排解](#auto-troubleshoot-controllers)。
+ 增強的 Pod 安全性阻止了跨 Pod 共用磁碟區。解決方案請參閱 [跨 Pod 共用磁碟區](#auto-troubleshoot-share-pod-volumes)。

您可使用以下方法對 EKS 自動模式元件進行疑難排解：
+  [使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出](#auto-node-console) 
+  [使用*偵錯容器*和 `kubectl` CLI 取得節點日誌](#auto-node-debug-logs) 
+  [在 AWS 主控台中檢視與 EKS Auto Mode 相關聯的資源](#auto-node-ec2-web) 
+  [檢視您 AWS 帳戶中的 IAM 錯誤](#auto-node-iam) 
+  [使用 `VPC Reachability Analyzer` 檢測節點連線問題](#auto-node-reachability) 

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

EKS 自動模式包含 Amazon EKS 節點監控代理程式。您可使用此代理程式來檢視有關節點的疑難排解和偵錯資訊。節點監控代理程式會發布 Kubernetes `events` 與節點 `conditions` 狀況。如需詳細資訊，請參閱[偵測節點運作狀態問題並啟用自動節點修復](node-health.md)。

## 使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出
<a name="auto-node-console"></a>

此程序有助於對開機時或核心層級的問題進行疑難排解。

首先，您需要確定與您工作負載關聯的執行個體的 EC2 執行個體 ID。其次，使用 AWS CLI 擷取主控台輸出。

1. 確認您已安裝 `kubectl` 並連接到您的叢集

1. (選用) 使用 Kubernetes 部署的名稱來列出關聯的 Pod。

   ```
   kubectl get pods -l app=<deployment-name>
   ```

1. 使用 Kubernetes Pod 的名稱來確定關聯節點的 EC2 執行個體 ID。

   ```
   kubectl get pod <pod-name> -o wide
   ```

1. 使用 EC2 執行個體 ID 來擷取主控台輸出。

   ```
   aws ec2 get-console-output --instance-id <instance id> --latest --output text
   ```

## 使用*偵錯容器*和 `kubectl` CLI 取得節點日誌
<a name="auto-node-debug-logs"></a>

要從 EKS 自動模式節點擷取日誌，建議的方法是使用 `NodeDiagnostic` 資源。相關步驟請參閱 [使用 kubectl 及 S3 擷取受管節點的節點日誌](auto-get-logs.md)。

但是，您可以使用 `kubectl debug node` 命令從執行個體即時串流日誌。此命令會在您要偵錯的節點上啟動新的 Pod，然後您可以互動式地使用。

1. 啟動偵錯容器。以下命令使用 `i-01234567890123456` 作為節點的執行個體 ID，`-it` 分配一個 `tty` 並附加 `stdin` 以供互動式使用，並使用 kubeconfig 檔案中的 `sysadmin` 設定檔。

   ```
   kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
   ```

   範例輸出如下。

   ```
   Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
   If you don't see a command prompt, try pressing enter.
   bash-5.2#
   ```

1. 從 shell 中，您現在可以安裝 `util-linux-core`，它提供了 `nsenter` 命令。使用 `nsenter` 進入主機上 PID 1 (`init`) 的掛載命名空間，並執行 `journalctl` 命令來從 `kubelet` 串流記錄：

   ```
   yum install -y util-linux-core
   nsenter -t 1 -m journalctl -f -u kubelet
   ```

為了安全起見，Amazon Linux 容器映像預設不安裝許多二進位檔。您可以使用 `yum whatprovides` 命令來識別必須安裝哪個套件才能提供給定的二進位檔。

```
yum whatprovides ps
```

```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : @System
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : amazonlinux
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps
```

## 在 AWS 主控台中檢視與 EKS Auto Mode 相關聯的資源
<a name="auto-node-ec2-web"></a>

您可以使用 AWS 主控台來檢視與 EKS Auto Mode 叢集相關聯的資源狀態。
+  [EBS 磁碟區](https://console.aws.amazon.com/ec2/home#Volumes) 
  + 透過搜尋標籤鍵 `eks:eks-cluster-name` 來檢視 EKS 自動模式磁碟區 
+  [負載平衡器](https://console.aws.amazon.com/ec2/home#LoadBalancers) 
  + 搜尋標籤索引鍵 `eks:eks-cluster-name` 來檢視 EKS 自動模式負載平衡器 
+  [EC2 執行個體](https://console.aws.amazon.com/ec2/home#Instances) 
  + 透過搜尋標籤鍵 `eks:eks-cluster-name` 來檢視 EKS 自動模式執行個體 

## 檢視您 AWS 帳戶中的 IAM 錯誤
<a name="auto-node-iam"></a>

1. 導覽至 CloudTrail 主控台

1. 從左側導覽窗格選取「事件歷程記錄」

1. 套用錯誤碼篩選條件：
   + AccessDenied
   + UnauthorizedOperation
   + InvalidClientTokenId

尋找與您的 EKS 叢集相關的錯誤。透過錯誤訊息來更新您的 EKS 存取項目、叢集 IAM 角色或節點 IAM 角色。您可能需要為這些角色附加具有 EKS 自動模式許可的新政策。

## 對 Pod 無法排程到自動模式節點進行疑難排解
<a name="auto-troubleshoot-schedule"></a>

如果 Pod 停留在 `Pending` 狀態且無法被排程到自動模式節點，請確認您的 Pod 或部署資訊清單是否具有 `nodeSelector`。如果存在 `nodeSelector`，請確保它使用 `eks.amazonaws.com/compute-type: auto` 以便在由 EKS 自動模式建立的節點上進行排程。有關 EKS 自動模式使用的節點標籤的更多資訊，請參閱 [控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)。

## 對未加入叢集的節點進行疑難排解
<a name="auto-troubleshoot-join"></a>

EKS 自動模式會自動設定新的 EC2 執行個體，提供正確的資訊以加入叢集，包括叢集端點和叢集憑證認證機構 (CA)。然而，這些執行個體仍可能無法作為節點加入 EKS 叢集。執行以下命令來識別未加入叢集的執行個體：

1. 執行 `kubectl get nodeclaim` 來檢查 `NodeClaims` 是否為 `Ready = False`。

   ```
   kubectl get nodeclaim
   ```

1. 執行 `kubectl describe nodeclaim <node_claim>` 並在**狀態**下尋找阻止節點加入叢集的任何問題。

   ```
   kubectl describe nodeclaim <node_claim>
   ```

 **常見錯誤訊息：**

 `Error getting launch template configs`   
如果您使用預設叢集 IAM 角色許可在 `NodeClass` 中設定自訂標籤，可能會收到此錯誤。請參閱 [了解 EKS 自動模式中的身分和存取](auto-learn-iam.md)。

 `Error creating fleet`   
從 EC2 API 呼叫 `RunInstances` 時可能存在某些授權問題。Check AWS CloudTrail 是否有錯誤，請參閱 [Amazon EKS 自動模式叢集 IAM 角色](auto-cluster-iam-role.md) 以取得所需的 IAM 許可。

### 使用 `VPC Reachability Analyzer` 檢測節點連線問題
<a name="auto-node-reachability"></a>

**注意**  
您需要為 VPC Reachability Analyzer 執行的每次分析付費。如需定價的詳細資訊，請參閱 [Amazon VPC 定價](https://aws.amazon.com/vpc/pricing/)。

執行個體無法加入叢集的一個原因是網路連線問題阻止其連線到 API 伺服器。要診斷此問題，您可以使用 [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)，對無法加入叢集的節點與 API 伺服器之間的連線狀態執行分析。您需要兩條資訊：
+  無法加入叢集的節點的**執行個體 ID**
+ **Kubernetes API 伺服器端點**的 IP 位址 

要取得**執行個體 ID**，您需要在叢集上建立工作負載，以促使 EKS 自動模式啟動一個 EC2 執行個體。這也會在您的叢集中建立具有執行個體 ID 的 `NodeClaim` 物件。執行 `kubectl get nodeclaim -o yaml` 以列印叢集中的全部 `NodeClaims`。每個 `NodeClaim` 都包含執行個體 ID 作為欄位，並在 providerID 中再次出現：

```
kubectl get nodeclaim -o yaml
```

範例輸出如下。

```
    nodeName: i-01234567890123456
    providerID: aws:///us-west-2a/i-01234567890123456
```

您可以透過執行 `kubectl get endpoint kubernetes -o yaml` 來確定您的 **Kubernetes API 伺服器端點**。位址位於位址欄位中：

```
kubectl get endpoints kubernetes -o yaml
```

範例輸出如下。

```
apiVersion: v1
kind: Endpoints
metadata:
  name: kubernetes
  namespace: default
subsets:
- addresses:
  - ip: 10.0.143.233
  - ip: 10.0.152.17
  ports:
  - name: https
    port: 443
    protocol: TCP
```

透過這兩項資訊，您可以執行分析。首先導覽至 AWS 管理主控台中的 VPC Reachability Analyzer。

1. 按一下「建立並分析路徑」

1. 為分析提供一個名稱 (例如「Node Join Failure」)

1. 針對「來源類型」，選取「執行個體」

1. 輸入失敗節點的執行個體 ID 作為「來源」

1. 對於「路徑目的地」，選取「IP 位址」

1. 輸入 API 伺服器的其中一個 IP 位址作為「目的地位址」

1. 展開「其他封包標頭組態區段」

1. 輸入 443 的「目的地連接埠」

1. 如果尚未選取，選取「通訊協定」作為 TCP

1. 按一下「建立並分析路徑」

1. 分析可能需要幾分鐘的時間才會完成。如果分析結果顯示連線失敗，則將指出網路路徑中失敗的位置，以便您解決問題。

## 跨 Pod 共用磁碟區
<a name="auto-troubleshoot-share-pod-volumes"></a>

EKS 自動模式節點設定為在強制模式下使用 SELinux，這為在同一節點上執行的 Pod 之間提供了更多隔離。啟用 SELinux 時，大多數非特殊權限 Pod 會自動套用其自己的多類別安全 (MCS) 標籤。此 MCS 標籤對每個 Pod 都是唯一的，旨在確保一個 Pod 中的程序無法操縱任何其他 Pod 或主機上的程序。即使帶有標籤的 Pod 以根目錄執行並具有對主機檔案系統的存取權，也將無法操縱檔案、在主機上進行敏感的系統呼叫、存取容器執行時期或取得 kubelet 的私密金鑰材料。

因此，當您嘗試在 Pod 之間共用資料時可能會遇到問題。例如，具有 `ReadWriteOnce` 存取模式的 `PersistentVolumeClaim` 仍然不允許多個 Pod 同時存取該磁碟區。

要啟用 Pod 之間的這種共用，您可以使用 Pod 的 `seLinuxOptions` 在這些 Pod 上設定相同的 MCS 標籤。在此範例中，我們為 Pod 分配了三個類別 `c123,c456,c789`。這不會與節點上自動分配給 Pod 的任何類別產生衝突，因為它們只會分配兩個類別。

```
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456,c789"
```

## 在控制平面日誌中檢視 Karpenter 事件
<a name="auto-view-karpenter-logs"></a>

對於啟用了控制平面日誌的 EKS 叢集，您可透過查詢記錄來深入了解 Karpenter 的操作和決策程序。這對於對與節點佈建、擴展和終止相關的 EKS 自動模式問題進行疑難排解特別有用。要檢視 Karpenter 相關事件，請使用以下 CloudWatch Logs Insights 查詢：

```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```

此查詢在 kube-apiserver 稽核日誌中篩選特定的 [Karpenter 相關事件](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go)。這些事件包括各種中斷狀態、排程失敗、容量問題及節點相關問題。透過分析這些日誌，您可以更好地了解：
+ Karpenter 採取某些動作的原因。
+ 阻止正常節點佈建、擴展或終止的任何問題。
+ 與執行個體類型相關的潛在容量或相容性問題。
+ 節點生命週期事件，如中斷、移出或終止。

要使用此查詢：

1. 導覽至 CloudWatch 主控台

1. 從左側導覽窗格中選取「Logs Insights」

1. 選擇您的 EKS 叢集控制平面日誌的日誌群組

1. 將此查詢貼到查詢編輯器中

1. 視需要調整時間範圍

1. 執行查詢

結果將向您顯示 Karpenter 相關事件的時間軸，協助您對問題進行疑難排解，並了解 EKS 自動模式在您叢集中的行為。要檢視特定節點上的 Karpenter 操作，您可以將以下指定執行個體 ID 的行篩選器新增到上述查詢中：

```
|filter @message like /[.replaceable]`i-12345678910123456`/
```

**注意**  
要使用此查詢，必須在您的 EKS 叢集上啟用控制平面日誌。如果您還未這麼做，請參閱 [將控制平面日誌傳送至 CloudWatch Logs](control-plane-logs.md)。

## 對自動模式中包含的控制器進行疑難排解
<a name="auto-troubleshoot-controllers"></a>

如果控制器出現問題，您應該研究：
+ 與該控制器關聯的資源是否格式正確且有效。
+ 如果已為您的叢集正確設定 AWS IAM 和 Kubernetes RBAC 資源。如需詳細資訊，請參閱[了解 EKS 自動模式中的身分和存取](auto-learn-iam.md)。

## 相關資源
<a name="_related_resources"></a>

使用這些 AWS re：Post 中的文章進行進階故障診斷步驟：
+  [如何在 EKS 自動模式中對常見的擴展問題進行疑難排解？](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ) 
+  [如何對 Amazon EKS 自動模式中的自訂 NodePool 和 NodeClass 佈建問題進行疑難排解？](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ) 
+  [如何對狀態不明的 EKS 自動模式內建節點集區進行故障診斷？](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)