EKS 自動模式疑難排解 - Amazon EKS
節點監控代理程式使用 AWS EC2 CLI 從 EC2 受管執行個體取得主控台輸出使用偵錯容器和 kubectl CLI 取得節點日誌在 AWS 主控台中檢視與 EKS 自動模式關聯的資源在您的 AWS 帳戶中檢視 IAM 錯誤對 Pod 無法排程到自動模式節點進行疑難排解對未加入叢集的節點進行疑難排解跨 Pod 共用磁碟區在控制平面日誌中檢視 Karpenter 事件對自動模式中包含的控制器進行疑難排解相關資源

協助改進此頁面

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

EKS 自動模式疑難排解

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

您必須使用 AWS 和 Kubernetes API 來對節點進行疑難排解。您可以：

注意

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

您可能會遇到以下特定於 EKS 自動模式元件的問題及解決方案：

您可使用以下方法對 EKS 自動模式元件進行疑難排解：

節點監控代理程式

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

使用 AWS EC2 CLI 從 EC2 受管執行個體取得主控台輸出

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

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

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

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

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

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

    kubectl get pod <pod-name> -o wide

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

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

使用偵錯容器和 kubectl CLI 取得節點日誌

要從 EKS 自動模式節點擷取日誌，建議的方法是使用 NodeDiagnostic 資源。相關步驟請參閱 使用 kubectl 及 S3 擷取受管節點的節點日誌。

但是，您可以使用 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#

  2. 從 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 自動模式關聯的資源

您可以使用 AWS 主控台來檢視與您的 EKS 自動模式叢集關聯的資源狀態。

  • EBS 磁碟區

    • 透過搜尋標籤鍵 eks:eks-cluster-name 來檢視 EKS 自動模式磁碟區

  • 負載平衡器

    • 搜尋標籤索引鍵 eks:eks-cluster-name 來檢視 EKS 自動模式負載平衡器

  • EC2 執行個體

    • 透過搜尋標籤鍵 eks:eks-cluster-name 來檢視 EKS 自動模式執行個體

在您的 AWS 帳戶中檢視 IAM 錯誤

  1. 導覽至 CloudTrail 主控台

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

  3. 套用錯誤碼篩選條件：

    • AccessDenied

    • UnauthorizedOperation

    • InvalidClientTokenId

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

對 Pod 無法排程到自動模式節點進行疑難排解

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

對未加入叢集的節點進行疑難排解

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

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

    kubectl get nodeclaim

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

    kubectl describe nodeclaim <node_claim>

常見錯誤訊息：

Error getting launch template configs

如果您使用預設叢集 IAM 角色許可在 NodeClass 中設定自訂標籤，可能會收到此錯誤。請參閱 了解 EKS 自動模式中的身分和存取。

Error creating fleet

從 EC2 API 呼叫 RunInstances 時可能存在某些授權問題。檢查 AWS CloudTrail 是否有錯誤，並請參閱 Amazon EKS 自動模式叢集 IAM 角色 以取得所需的 IAM 許可。

使用 VPC Reachability Analyzer 檢測節點連線問題

注意

您需要為 VPC Reachability Analyzer 執行的每次分析付費。如需定價的詳細資訊，請參閱 Amazon VPC 定價。

執行個體無法加入叢集的一個原因是網路連線問題阻止其連線到 API 伺服器。要診斷此問題，您可以使用 VPC Reachability Analyzer，對無法加入叢集的節點與 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. 按一下「建立並分析路徑」

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

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

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

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

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

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

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

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

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

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

跨 Pod 共用磁碟區

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 事件

對於啟用了控制平面日誌的 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 相關事件。這些事件包括各種中斷狀態、排程失敗、容量問題及節點相關問題。透過分析這些日誌，您可以更好地了解：

  • Karpenter 採取某些動作的原因。

  • 阻止正常節點佈建、擴展或終止的任何問題。

  • 與執行個體類型相關的潛在容量或相容性問題。

  • 節點生命週期事件，如中斷、移出或終止。

要使用此查詢：

  1. 導覽至 CloudWatch 主控台

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

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

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

  5. 視需要調整時間範圍

  6. 執行查詢

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

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

要使用此查詢，必須在您的 EKS 叢集上啟用控制平面日誌。如果您還未這麼做，請參閱 將控制平面日誌傳送至 CloudWatch Logs。

對自動模式中包含的控制器進行疑難排解

如果控制器出現問題，您應該研究：

相關資源

使用以下 AWS re:Post 文章進行進階疑難排解步驟：