協助改善此頁面
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要提供此使用者指南，請選擇位於每個頁面右窗格中的 GitHub 上編輯此頁面連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
透過 EKS Auto 模式， 會對您 AWS 帳戶中的 EC2 執行個體 AWS 承擔更多責任。EKS 負責節點上的容器執行期、節點上的作業系統，以及特定控制器。這包括區塊儲存控制器、負載平衡控制器和運算控制器。
您必須使用 AWS 和 Kubernetes APIs 對節點進行故障診斷。您可以：
-
使用 Kubernetes
NodeDiagnostic資源來擷取節點日誌節點監控代理程式。如需更多步驟，請參閱 使用 kubectl 和 S3 擷取受管節點的節點日誌。 -
使用 AWS EC2 CLI 命令從節點
get-console-output擷取主控台輸出。如需更多步驟，請參閱 使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出。 -
使用 Kubernetes 除錯容器來擷取節點日誌。如需更多步驟，請參閱 使用除錯容器和 CLI kubectl 取得節點日誌。
注意
EKS Auto Mode 使用 EC2 受管執行個體。您無法直接存取 EC2 受管執行個體，包括 SSH 的執行個體。
您可能會遇到以下問題，這些問題具有 EKS Auto Mode 元件特定的解決方案：
-
Pod 停滯在
Pending狀態，但未排程到自動模式節點。如需解決方案，請參閱故障診斷 Pod 無法排程到自動模式節點。 -
未將叢集加入為 Kubernetes 節點的 EC2 受管執行個體。如需解決方案，請參閱未加入叢集的節點故障診斷。
-
Services使用包含在 EKS Auto Mode 中的控制器的NodePools、PersistentVolumes和 的錯誤和問題。如需解決方案，請參閱對自動模式下包含的控制器進行故障診斷。 -
增強的 Pod 安全性可防止跨 Pod 共用磁碟區。如需解決方案，請參閱跨 Pod 共用磁碟區。
您可以使用下列方法來疑難排解 EKS Auto Mode 元件：
節點監控代理程式
EKS Auto 模式包含 Amazon EKS 節點監控代理程式。您可以使用此代理程式來檢視節點的疑難排解和偵錯資訊。節點監控代理程式會發佈 Kubernetes events和節點 conditions。如需詳細資訊，請參閱啟用節點自動修復並調查節點運作狀態問題。
使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出
此程序有助於疑難排解開機時間或核心層級的問題。
首先，您需要判斷與工作負載相關聯的執行個體 EC2 執行個體 ID。其次，使用 AWS CLI 擷取主控台輸出。
-
確認您
kubectl已安裝並連線至叢集 -
（選用） 使用 Kubernetes 部署的名稱來列出相關聯的 Pod。
kubectl get pods -l app=<deployment-name> -
使用 Kubernetes Pod 的名稱來判斷相關聯節點的 EC2 執行個體 ID。
kubectl get pod <pod-name> -o wide -
使用 EC2 執行個體 ID 擷取主控台輸出。
aws ec2 get-console-output --instance-id <instance id> --latest --output text
使用除錯容器和 CLI kubectl 取得節點日誌
從 EKS Auto Mode 節點擷取日誌的建議方法是使用 NodeDiagnostic 資源。如需這些步驟，請參閱 使用 kubectl 和 S3 擷取受管節點的節點日誌。
不過，您可以使用 kubectl debug node命令，從執行個體即時串流日誌。此命令會在您要偵錯的節點上啟動新的 Pod，然後以互動方式使用。
-
啟動偵錯容器。下列命令使用
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# -
您現在可以從 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 相關聯的資源
您可以使用 AWS 主控台來檢視與 EKS Auto Mode 叢集相關聯的資源狀態。
檢視您 AWS 帳戶中的 IAM 錯誤
-
導覽至 CloudTrail 主控台
-
從左側導覽窗格中選取「事件歷史記錄」
-
套用錯誤碼篩選條件：
-
AccessDenied
-
UnauthorizedOperation
-
InvalidClientTokenId
-
尋找與您的 EKS 叢集相關的錯誤。使用錯誤訊息來更新您的 EKS 存取項目、叢集 IAM 角色或節點 IAM 角色。您可能需要使用 EKS Auto Mode 的許可，將新的政策連接至這些角色。
故障診斷 Pod 無法排程到自動模式節點
如果 Pod 處於 Pending 狀態且未排程到自動模式節點，請確認您的 Pod 或部署資訊清單是否具有 nodeSelector。如果nodeSelector存在 ，請確保在 EKS Auto Mode 建立的節點上使用 eks.amazonaws.com/compute-type: auto來排程。如需 EKS Auto Mode 所使用的節點標籤的詳細資訊，請參閱 控制工作負載是否部署在 EKS Auto Mode 節點上。
未加入叢集的節點故障診斷
EKS Auto Mode 會自動設定具有正確資訊的新 EC2 執行個體來加入叢集，包括叢集端點和叢集憑證授權單位 (CA)。不過，這些執行個體仍然無法以節點形式加入 EKS 叢集。執行下列命令來識別未加入叢集的執行個體：
-
執行
kubectl get nodeclaim以檢查NodeClaims是否為Ready = False。kubectl get nodeclaim -
在狀態下執行
kubectl describe nodeclaim <node_claim>並查看，以尋找任何使節點無法加入叢集的問題。kubectl describe nodeclaim <node_claim>
常見錯誤訊息：
-
Error getting launch template configs -
如果您使用預設叢集 IAM 角色許可在 中設定自訂標籤
NodeClass，則可能會收到此錯誤。請參閱 了解 EKS Auto 模式的身分和存取。 -
Error creating fleet -
從
RunInstancesEC2 API 呼叫 時，可能會有一些授權問題。Check AWS CloudTrail 是否有錯誤，請參閱 Amazon EKS Auto Mode 叢集 IAM 角色 以取得必要的 IAM 許可。
偵測 的節點連線問題 VPC Reachability Analyzer
注意
每個執行 VPC Reachability Analyzer 的分析都會向您收取費用。如需定價詳細資訊，請參閱 Amazon VPC 定價
執行個體未加入叢集的一個原因，是網路連線問題，導致執行個體無法連線到 API 伺服器。若要診斷此問題，您可以使用 VPC Reachability Analyzer 來執行節點之間無法加入叢集和 API 伺服器之間的連線分析。您需要兩份資訊：
-
無法加入叢集之節點的執行個體 ID
-
Kubernetes API 伺服器端點的 IP 地址
若要取得執行個體 ID，您需要在叢集上建立工作負載，讓 EKS Auto 模式啟動 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
您可以執行 來判斷 Kubernetes API 伺服器端點kubectl get endpoint kubernetes -o yaml。地址位於地址欄位中：
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
使用這兩項資訊，您可以執行 分析。首先導覽至 中的 VPC Reachability Analyzer AWS Management Console。
-
按一下「建立和分析路徑」
-
提供分析的名稱 （例如「節點聯結失敗」)
-
針對「來源類型」，選取「執行個體」
-
輸入失敗節點的執行個體 ID 做為「來源」
-
對於「路徑目的地」，選取「IP 地址」
-
輸入 API 伺服器的其中一個 IP 地址做為「目的地地址」
-
展開「額外封包標頭組態」區段
-
輸入 443 的「目的地連接埠」
-
如果尚未選取，請選取「通訊協定」做為 TCP
-
按一下「建立和分析路徑」
-
完成分析可能需要幾分鐘的時間。如果分析結果指出連線失敗，則表示故障在網路路徑中的位置，以便您解決問題。
跨 Pod 共用磁碟區
EKS Auto Mode Nodes 是以強制執行模式使用 SELinux 設定，可在相同節點上執行的 Pod 之間提供更多隔離。啟用 SELinux 時，大多數非特殊權限 Pod 會自動套用自己的多類別安全 (MCS) 標籤。此 MCS 標籤每個 Pod 都是唯一的，旨在確保一個 Pod 中的程序無法操作任何其他 Pod 或主機上的程序。即使已標記的 Pod 以根目錄執行，並可存取主機檔案系統，也無法操作檔案、對主機進行敏感系統呼叫、存取容器執行時間，或取得 kubelet 的私密金鑰材料。
因此，您在嘗試在 Pod 之間共用資料時可能會遇到問題。例如，PersistentVolumeClaim具有 存取模式的 ReadWriteOnce仍不允許多個 Pod 同時存取磁碟區。
若要在 Pod 之間啟用此共用，您可以使用 Pod 的 seLinuxOptions在這些 Pod 上設定相同的 MCS 標籤。在此範例中，我們將三個類別指派給 c123,c456,c789 Pod。這不會與自動指派給節點上 Pod 的任何類別衝突，因為它們只會指派給兩個類別。
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"對自動模式下包含的控制器進行故障診斷
如果控制器發生問題，您應該研究：
-
如果與該控制器相關聯的資源格式正確且有效。
-
如果已為您的叢集正確設定 AWS IAM 和 Kubernetes RBAC 資源。如需詳細資訊，請參閱了解 EKS Auto 模式的身分和存取。
