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

5 分的閱讀內容

我的 Amazon Elastic Kubernetes Service (Amazon EKS) Pod 卡在 ContainerCreating 狀態中，並顯示「failed to create pod sandbox」錯誤。

解決方法

先決條件

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

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

kubectl get pods --all-namespaces -o wide

執行以下命令，擷取每個處於 ContainerCreating 狀態的 Pod 詳細資訊：
```
kubectl describe pod pod-name -n pod-namespace
```
**注意：**將 pod-name 替換為您的 Pod 名稱，並將 pod-namespace 替換為您的 Pod 所在命名空間。
在 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」

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

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

收集 Containerd 和 Kubelet 的節點日誌。
若為 Windows，請連線到您的執行個體。開啟 PowerShell 命令提示字元，然後使用 Windows EKS 日誌收集器指令碼來收集工作節點日誌。如需更多資訊，請參閱 GitHub 網站上的 EKS Logs Collector (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 Logs Collector (Linux)。執行以下命令以下載日誌收集器指令碼：

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

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

sudo bash eks-log-collector.sh

檢閱 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)」
找出殭屍程序，然後停止不必要的程序。
若為 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」錯誤

如果 Container Network Interface (CNI) 無法將 IP 位址指派給您新建立的 Pod，您可能會收到以下錯誤訊息：

「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 無法與 IPAM 通訊，原因是 aws-node Pod 無法在節點上執行，您會收到類似以下內容的錯誤：

「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 位址容量不一致。這種情況可能會影響該節點上的未來工作負載。若要解決此問題，請依照使用首碼將更多 IP 位址指派給 Amazon EKS 節點中的步驟操作。

「Container image authentication」錯誤

如果容器執行時期沒有提取映像所需的權限，您可能會收到類似以下內容的錯誤訊息：

「pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials」

若要解決此錯誤，請檢查以下項目：

檢閱附加到 EKS 工作節點的 IAM 角色。如果缺少 IAM 政策 AmazonEC2ContainerRegistryReadOnly，請附加該政策。
如果您從跨帳戶的 ECR 儲存庫提取映像，請參閱如何允許次要帳戶在我的 Amazon ECR 映像儲存庫中推送或提取映像？確定儲存庫層級政策已設定適當的權限。
如果您使用 ECR VPC 端點來提取映像。接著，請確定 VPC 端點安全群組允許來自 EKS 節點安全群組的連接埠 443 HTTPS 傳入流量。如需更多資訊，請參閱 Amazon ECR 介面 VPC 端點 (AWS PrivateLink)。
對於 containerd，pause 映像只會在 bootstrap 期間提取。之後，該映像必須保留在執行個體上。請勿使用自訂清理指令碼或手動刪除命令，例如 crictl rmi —prune，來移除 pause 映像。請讓 kubelet 處理垃圾收集 (gc)，其每 1-2 分鐘會自動執行一次。當您移除 containerd pause 容器映像時，新的 Pod 會無法啟動。目前的 Pod 可在節點上正常執行，而 kubelet 日誌會顯示錯誤「Failed to create pod sandbox」。

如果您從 EKS 工作節點刪除了 pause 容器映像，請完成以下步驟：

若要檢查您的 EKS 工作節點是否具有 pause 映像，請執行以下命令：

ctr -n k8s.io images ls | grep -o "602401143452.dkr.ecr.YOUR-REGION.amazonaws.com/eks/pause:3.10"

**注意：**請將 YOUR-REGION 替換為您的 AWS 區域。

如果 EKS 工作節點具有 pause 映像，輸出會如下所示：

602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10
602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10

若要檢查您的 EKS 工作節點是否已刪除，請執行以下命令：

ctr -n k8s.io images ls | grep -o "localhost/kubernetes/pause:latest"

如果映像已刪除，輸出會如下所示：

ctr -n k8s.io images list |grep -i pause

若要提取映像並取得 ECR 驗證權杖，請執行以下命令：

ECR_REGION=YOUR-REGION
ECR_PASSWORD=$(aws ecr get-login-password --region $ECR_REGION)

**注意：**請將 YOUR-REGION 替換為您的 AWS 區域。

從 ECR 提取 pause 映像。請確定您使用正確的 pause 映像版本。如果您不確定映像版本，請登入任一工作節點並選取該映像版本。

例如：

sudo ctr -n k8s.io image pull --user "AWS:$ECR_PASSWORD" 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion>

**注意：**您可以從 GitHub 網站上的版本中選取最新的映像版本。

將該映像標記為 localhost 供 EKS 使用。

例如：

sudo ctr -n k8s.io image tag 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion> localhost/kubernetes/pause:latest

當 pause 映像恢復後，新的 Pod 即可正常啟動並執行，不會再有任何問題。

「Container image authentication」錯誤

如果容器執行時期沒有提取映像所需的權限，您可能會收到類似以下內容的錯誤訊息：

「pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials」

若要解決此錯誤，請檢查以下項目：

檢閱附加到 EKS 工作節點的 IAM 角色。如果缺少 IAM 政策 AmazonEC2ContainerRegistryReadOnly，請附加該政策。
如果您從跨帳戶的 ECR 儲存庫提取映像，請參閱如何允許次要帳戶在我的 Amazon ECR 映像儲存庫中推送或提取映像？確定儲存庫層級政策已設定適當的權限。
如果您使用 ECR VPC 端點提取映像，請確定 VPC 端點安全群組允許來自 EKS 節點安全群組的連接埠 443 HTTPS 傳入流量。如需更多資訊，請參閱 Amazon ECR 介面 VPC 端點 (AWS PrivateLink)。
對於 containerd，pause 映像只會在 bootstrap 期間提取。之後，該映像必須保留在執行個體上。請勿使用自訂清理指令碼或手動刪除命令，例如 crictl rmi —prune，來移除 pause 映像。請讓 kubelet 處理垃圾收集 (gc)，其每 1-2 分鐘會自動執行一次。當您移除 containerd pause 容器映像時，新的 Pod 會無法啟動。目前的 Pod 可在節點上正常執行，而 kubelet 日誌會顯示錯誤「Failed to create pod sandbox」。

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 configmap 中，將 enable-windows-ipam 參數設為 true。

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

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。