為什麼 Amazon EKS Pod 卡在 ContainerCreating 狀態，並顯示「failed to create pod sandbox」錯誤？

解決方法

先決條件

判斷哪個 Pod 發生問題。請完成以下步驟：

1. 執行以下命令以列出叢集中的 Pod，以識別處於 ContainerCreating 狀態的 Pod：

   kubectl get pods --all-namespaces -o wide

2. 執行以下命令以擷取每個處於 ContainerCreating 狀態之 Pod 的詳細資料：

   kubectl describe pod pod-name -n pod-namespace

   **注意：**將 pod-name 替換為您的 Pod 名稱，並將 pod-namespace 替換為您的 Pod 所在命名空間。

3. 在 Events (事件) 中檢閱輸出以識別 Pod，然後使用以下各節對問題進行疑難排解。

「Resource temporarily unavailable」錯誤

如果您為 PID 或檔案所設定的核心設定超出作業系統 (OS) 的最大限制，那麼您會收到類似以下的錯誤訊息：

「kubelet, ip-192-168-0-1.us-east-1.compute.internal Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for Pod "example_pod": Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown」

若要暫時解決此問題，請重新啟動節點。

若要疑難排解問題，請完成以下步驟：

1. 收集 Containerd 和 Kubelet 的節點日誌。
   若為 Windows，請連線至您的執行個體。開啟 PowerShell 命令提示字元，然後使用 Windows EKS 日誌收集指令碼來收集器工作節點日誌。如需詳細資訊，請參閱 GitHub 網站上的 EKS 日誌收集器 (Windows)。執行以下命令：

   Invoke-WebRequest -OutFile eks-log-collector.ps1 https://raw.githubusercontent.com/awslabs/amazon-eks-ami/main/log-collector-script/windows/eks-log-collector.ps1
   .\eks-log-collector.ps1

   若為 Linux，請連線至您的執行個體。然後，使用 Linux EKS 日誌收集器指令碼收集工作節點日誌。如需詳細資訊，請參閱 GitHub 網站上的 EKS 日誌收集器 (Linux)。執行以下命令以下載日誌收集器指令碼：

   curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh

2. 接著，執行下載的指令碼：

   sudo bash eks-log-collector.sh

3. 檢閱 Kubelet 日誌中是否有以下錯誤回應：
   「kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)""kubelet[5267]: runtime: may need to increase max user processes (ulimit -u)」

4. 識別殭屍程序，然後停止不必要的程序。
   若為 Windows，請開啟 Task Manager，然後選擇 Details (詳細資料) 索引標籤。檢查顯示 Not responding (沒有回應) 狀態的程序，以識別殭屍程序。
   若為 Linux，請執行以下 ps 命令以檢查列於 Z 狀態的殭屍程序：

   ps aux | egrep "Z|defunct"

   如需更多資訊，請參閱 Linux Journal 網站上的如何在 Linux 中終止殭屍程序。

「Network plugin cni failed to set up pod network」錯誤

如果容器網路介面 (CNI) 無法為新建立的 Pod 指派 IP 位址，您可能會收到以下錯誤訊息：

「Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container」

此錯誤可能由多種原因造成，主要分為三類：

資源限制：

• 子網路 IP 已耗盡
• 已達到最大 ENI 附加限制

組態問題：

• 工作節點缺少 IAM CNI 政策
• VPC CNI (aws-node) Pod 未處於 Running (執行中) 狀態
• VPC CNI、kube-proxy 或 CoreDNS 版本過舊
• 安全群組或存取控制清單設定錯誤

架構特定挑戰：

• VPC CNI 組態與您的使用案例不一致
• 缺少 OpenID Connect (OIDC) 組態
• 使用自我管理附加元件而非 EKS 管理附加元件

如需詳細疑難排解步驟，請參閱如何解決 Amazon EKS 的 kubelet 或 CNI 外掛程式問題？

建議的最佳實務包括：

• 使用 VPC CNI 自訂網路以允許您在替代子網路上部署 Pod。
• 開啟首碼委派模式。如需詳細資訊，請參閱 Windows 的首碼模式。
• 使用 Pod 的安全群組透過工作節點的分支 ENI，為多個 Pod 指派自訂安全群組。

**注意：**如果您對 CNI 組態進行任何更改，必須重新啟動受影響的節點，變更才會生效。

「Error while dialing」錯誤

如果 aws-node Pod 因 aws-node Pod 無法在節點上執行而無法與 IPAM 通訊，那麼您會收到類似以下的錯誤訊息：

「Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused」

此錯誤會在以下情況發生：

VPC CNI 處於待處理狀態

由於安全規則組態或應用程式錯誤，可能會發生 Liveness 與 Readiness 探查失敗。資源耗盡也可能導致延遲。通常，如果 POD_SECURITY_GROUP_ENFORCING_MODE 處於嚴格模式，而 DISABLE_TCP_EARLY_DEMUX 設為 false，就可能會發生失敗。

如果您對每個 Pod 使用安全群組，並且啟用了 Liveness 或 Readiness 探查，請在嚴格模式下將 DISABLE_TCP_EARLY_DEMUX 設為 true。這可以讓 kubelet 使用 TCP 連線到分支網路介面上的 Pod。

CNI 受管外掛程式問題

當 aws-node 作為 AWS 管理主控台中的受管外掛程式新增時，會導致探查失敗。這是因為受管外掛程式會覆寫服務帳戶。

若要解決此問題，請執行以下其中一項操作：

• 從 AWS 管理主控台移除受管附加元件。然後，使用提供所需 AmazonEKS_CNI_Policy IAM 政策的正確 IAM 角色重新建立它。
• 編輯現有 aws-node 服務帳戶，將其與具有所需 CNI 權限的正確 IAM 角色建立關聯。
• 如果您在叢集上使用 Pod 身分識別，請建立必要的 Pod 身分識別關聯，將 aws-node 服務帳戶與 VPC CNI 將使用的 IAM 角色繫結。

其他建議：

• 使用最新版的 VPC CNI (aws-node)、kube-proxy 與 coredns。

「Failed to setup network for sandbox」錯誤

如果您在 VPC-CNI (aws-node) Pod 中使用「啟用首碼委派」，可能會收到以下錯誤訊息：

「Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox」

如需此問題的更多詳細資訊，請檢查工作節點上 /var/log/aws-routed-eni/ipamd.log 中的 IP 位址管理常駐程式 (IPAMD) 日誌。

即使您的子網路有可用 IP 位址，如果子網路沒有任何連續 /28 區塊的可用 IP，也會發生錯誤。當現有次要 IP 位址分散於整個子網路時，會發生此錯誤。此錯誤會出現在 Kubernetes 的 Amazon VPC CNI 外掛程式日誌中，或受影響工作節點的 CloudTrail 事件中。您可能會收到以下錯誤訊息：

「InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request」

若要解決此錯誤，請完成以下其中一項操作：

建立一個新的子網路，然後在該子網路上啟動 Pod。

-或-

使用 Amazon EC2 子網路 CIDR 保留在子網路內預留空間，以便用於首碼指派。

如果您從 IP 位址指派轉換為 IP 首碼指派，請建立新的節點群組。然後，您可以增加可用 IP 位址數量，而無需對現有節點進行滾動替換。

如果您在同時指派了 IP 位址和首碼的節點上執行 Pod，可能會導致通告的 IP 位址容量不一致。此情況可能影響節點上未來的工作負載。若要解決此問題，請遵循為 Amazon EKS 節點指派更多帶有首碼的 IP 位址中的步驟操作。

Windows 節點上出現「Pod does not have label」錯誤

如果 Pod 在 Windows 節點上沒有排程 nodeSelector，則可能會收到類似以下的錯誤訊息：

「Failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address」或「Pod does not have label vpc.amazonaws.com/PrivateIPv4Address」

若要解決此問題，請確保在 PodSpec 中的 nodeSelector 參數包含以下標籤：

nodeSelector:
    kubernetes.io/os: windows
    kubernetes.io/arch: amd64

確認您在 amazon-vpc-cni 組態表中將 enable-windows-ipam 參數設為 true。

如果您沒有 amazon-vpc-cni 組態表，請使用以下範本並上傳到您的叢集：

apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"

重新啟動 aws-node 與 node-windows Pod。

如需有關如何在 Amazon EKS 叢集上部署 Windows 節點的更多資訊，請參閱在 EKS 叢集上部署 Windows 節點。

安全群組錯誤

如果您有安全群組問題，則會收到類似以下錯誤：

"Plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container
Vpc-resource-controller failed to allocate branch ENI to pod: creating network interface, NoCredentialProviders: no valid providers in chain.Deprecated."

此錯誤回應可能表示 health.kubernetes 控制平面存在問題。若要解決此問題，請聯絡 AWS Support。

相關資訊

如何解決 Amazon EKS 的 kubelet 或 CNI 外掛程式問題？

如何對 Amazon EKS 中的 OIDC 供應商和 IRSA 進行疑難排解？

如何對 Amazon EKS 中的 IRSA 錯誤進行疑難排解？

設定 Amazon VPC CNI 外掛程式以使用 IRSA - Amazon EKS

服務帳戶的 IAM 角色