为什么我的 Amazon EKS 容器组卡滞在 ContainerCreating 状态并出现“failed to create pod sandbox”(无法创建容器组沙盒)错误?

3 分钟阅读
0

我的 Amazon Elastic Kubernetes Service (Amazon EKS) 容器组(pod)停留在 ContainerCreating 状态并出现“failed to create pod sandbox”错误。

解决方法

当出现网络问题或系统资源限制配置不正确时,就会出现此错误。

如果您遇到此错误,并且您的容器组处于 ContainerCreating 状态,请首先检查容器组的状态。然后,运行以下命令以获取更多详细信息。将 podname 替换为您的容器组(pod)的名称:

kubectl describe pod podname

根据输出,有关故障排除步骤,请参阅以下部分。

“Resource temporarily unavailable”(资源暂时不可用)错误响应

如果您遇到资源问题,则会收到一条类似于以下内容的错误消息:

"kubelet, ip-##-##-##-##.##-#####-#.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"

当为最大 PID 或最大文件数定义的内核设置导致操作系统限制时,就会出现此错误响应。

要暂时解决此问题,请重启节点。

要彻底解决此问题,请完成以下任务:

  • 收集节点日志。
  • 查看 Docker 日志中是否有**“dockerd[4597]: runtime/cgo: pthread_create failed: Resource temporarily unavailable”**(dockerd[4597]: runtime/cgo: pthread_create 失败:资源暂时不可用)错误响应。
  • 查看 Kubelet 日志中是否有以下错误响应:
    “kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)” (kubelet[5267]: 运行时:无法创建新的操作系统线程(已有 2 个;errno=11)) “kubelet[5267]: runtime: may need to increase max user processes (ulimit -u)”(kubelet[5267]: 运行时:可能需要增加最大用户进程 (ulimit -u))
  • 运行 ps 命令来识别僵尸进程。输出中列出的进程中,所有 Z 状态的进程都是僵尸进程。

“Network plugin cni failed to set up pod network”(网络插件 cni 无法设置容器组网络)错误响应

如果您遇到网络问题,则会收到一条类似于以下内容的错误消息:

“Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container”(网络插件 cni 无法设置容器组网络:添加 cmd:无法向容器分配 ID 地址)

此错误响应意味着容器网络接口 (CNI) 无法为新创建的容器组(pod)分配 IP 地址。

使用最大允许弹性网络接口和 IP 地址的实例可能会导致此错误响应。当 Amazon Virtual Private Cloud (Amazon VPC) 子网的 IP 地址数为零时,也会收到此错误响应。

以下是最大网络接口 IP 地址的示例:

Instance type    Maximum network interfaces    Private IPv4 addresses per interface    IPv6 addresses per interfacet3.medium        3                             6                                       6

在前面的示例中,t3.medium 实例最多有三个网络接口,每个网络接口最多有六个 IP 地址。第一个 IP 地址用于节点,您无法分配该地址。然后,该网络接口有 17 个 IP 地址可供分配。

当网络接口耗尽 IP 地址时,本地 IP 地址管理进程守护程序 (iPamD) 日志会显示以下消息:

"ipamd/ipamd.go:1285","msg":"Total number of interfaces found: 3 ""AssignIPv4Address: IP address pool stats: total: 17, assigned 17" "AssignPodIPv4Address: ENI eni-abc123 does not have available addresses"

例如,请参阅以下输出:

Warning FailedCreatePodSandBox 23m (x2203 over 113m) kubelet, ip-##-##-##-##.##-#####-#.compute.internal (combined from similar events): Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "provisioning-XXXXXXXXXXXXXXX": networkPlugin cni failed to set up pod "provisioning-XXXXXXXXXXXXXXX" network: add cmd: failed to assign an IP address to container

检查子网以确定子网是否耗尽空闲的 IP 地址。您可以在 Amazon VPC 控制台子网部分下查看每个子网的可用 IP 地址。

Subnet: ##########IPv4 CIDR Block 10.2.1.0/24   Number of allocated ips 254  ; Free address count 0

要解决此问题,请采用以下解决方案:

  • 确保使用 VPC CNI 的最新可用版本
  • 缩减工作负载以释放使用的 IP 地址。
  • 如果子网中有更多可用的 IP 地址,则纵向扩展节点数。
  • 为容器组使用自定义网络
  • 打开前缀委托模式。有关详细信息,请参阅 GitHub 网站上的 AWS 账户中的 ](https://github.com/aws/aws-eks-best-practices/blob/master/content/networking/prefix-mode/index_windows.md#replace-all-nodes-during-migration-from-secondary-ip-mode-to-prefix-delegation-mode-or-vice-versa)Windows 前缀模式[。

“Error while dialing”(拨号时出错)错误响应

如果您遇到拨号问题,则会收到类似以下内容的错误:

“Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused”(拨号 tcp 127.0.0.1:50051 时出错:连接:连接被拒绝)

此错误表明 aws-node 容器组无法与 IPAM 通信,因为 aws-node 容器组无法在该节点上运行。

要解决此问题,请确保您运行的 VPC CNI 插件的版本正确,适用于集群版本。

由于“Liveness”和“Readiness”探针错误,容器组可能处于 Pending(待处理)状态。确保您拥有最新的 VPC CNI 插件版本。

此问题也可能是由于 Dockershim(最高 EKS 版本 1.23)挂载点无法挂载而导致的。以下示例消息表明容器组(pod)未挂载 var/run/dockershim.sock

Getting running pod sandboxes from \"unix:///var/run/dockershim.sock\Not able to get local pod sandboxes yet (attempt 1/5): rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or director

要解决此问题,请完成以下任务:

  • 重新启动 aws-node 容器组(pod)以重新映射挂载点。
  • 封锁节点,并扩展节点组中的节点。
  • 将 Amazon VPC 网络接口升级到支持的最新集群版本。

如果您在 AWS 管理控制台中将 CNI 添加为托管插件,则 aws-node 会令探针失效。托管插件会覆盖服务账户。但是,没有为服务账户配置所选的角色。要解决此问题,请从 AWS 管理控制台关闭该插件,然后使用清单文件创建服务账户。或者,编辑当前 aws-node 服务账户以添加在托管插件上使用的角色。

“Pod does not have label”(容器组没有标签)错误响应

如果您遇到标签问题,则会收到与以下内容类似的错误:

“Failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address”(无法解析 Kubernetes args:容器组没有标签 vpc.amazonaws.com/PrivateIPv4Address)或“Pod does not have label vpc.amazonaws.com/PrivateIPv4Address”(容器组没有标签 vpc.amazonaws.com/PrivateIPv4Address)

当容器组在 Windows 节点上没有计划的 nodeSelector 时,就会出现此问题。

要解决此问题,请确保在 nodeSelectorPodSpec 中包含以下标签:

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

安全组错误

如果您遇到安全组问题,则会收到与以下内容类似的错误:

"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

AWS 官方
AWS 官方已更新 10 个月前
2评论

在eks(v1.30)node 上部署deployment报错:Failed to create pod sandbox: rpc error: code = Unknown desc = failed to get sandbox image ".dkr.ecr.us-west-1.amazonaws.com/eks/pause:3.5": failed to pull image ".dkr.ecr.us-west-1.amazonaws.com/eks/pause:3.5": failed to pull and unpack image ".dkr.ecr.us-west-1.amazonaws.com/eks/pause:3.5": failed to resolve reference ".dkr.ecr.us-west-1.amazonaws.com/eks/pause:3.5": pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials


解决方案: 因为 containerd 无法获取 ECR 凭证来拉取沙箱容器映像。您可以 systemctl restart sandbox-image 来触发拉取,但仍然需要调查为什么image被删除。 比如可能的原因: 1.使用在每个节点上运行的自定义脚本来清理节点上未使用的图像并退出容器,这也将删除节点上的pause image。可以修改脚本,排除节点上的一些image。 2.使用类似 crictl rmi --prune命令手动删除了image,应避免类似操作,交由kubelet进行image回收。

kubelet 会每两分钟对未使用的镜像执行一次垃圾收集, 每分钟对未使用的容器执行一次垃圾收集。 你应该避免使用外部的垃圾收集工具,因为外部工具可能会破坏 kubelet 的行为,移除应该保留的容器。

profile pictureAWS
支持工程师
已回复 8 个月前

感谢您的评论。我们将会根据需要审核和更新知识中心文章。

profile pictureAWS
审核人员
已回复 8 个月前