更新时间:2025-05-28 GMT+08:00
分享

工作负载异常:启动容器失败

问题定位

工作负载详情中,若事件中提示启动容器失败,请按照如下方式来初步排查原因:

  1. 登录异常工作负载所在的节点。
  2. 查看工作负载实例非正常退出的容器ID。

    如果节点为docker,请执行docker命令:

    docker ps -a | grep $podName
    如果节点为containerd,请执行containerd命令:
    crictl ps -a | grep $podName

  3. 查看退出容器的错误日志。

    如果节点为docker,请执行docker命令:

    docker logs $containerID
    如果节点为containerd,请执行containerd命令:
    crictl logs $containerID

    根据日志提示修复工作负载本身的问题。

  4. 查看操作系统的错误日志,例如查询日志中是否存在OOM信息。

    cat /var/log/messages | grep $containerID  | grep oom

    根据日志判断是否触发了系统OOM。

排查思路

根据具体事件信息确定具体问题原因,如表1所示。

表1 容器启动失败

日志或事件信息

问题原因

排查与解决方案

Pod日志中存在exit(0)

容器中无进程。

请调试容器是否能正常运行,详情请参见容器中无持续运行的进程(退出码:0)

  • Kubernetes事件信息:
    Liveness probe failed: Get http…
  • Pod日志中存在exit(137)

健康检查执行失败。

检查Pod中所配置的容器健康检查(Liveness Probe)策略是否符合预期,详情请参见健康检查执行失败(退出码:137)

  • Kubernetes事件信息如下:
    Thin Pool has 15991 free data blocks which is less than minimum required 16383 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior
  • Pod日志中存在no left space

磁盘空间不足。

您需要扩容或清理磁盘空间,详情请参见容器所在磁盘空间不足

Pod日志中存在OOM字眼

Pod内存不足。

检查Pod的资源配置是否正确,详情请参见容器资源配置过小

Pod日志中存在Address already in use

Pod中容器端口冲突。

检查Pod是否出现容器端口冲突,详情请参见同一Pod中container端口冲突

Kubernetes事件信息如下:

Error: failed to start container "filebeat": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"setenv: invalid argument\"": unknown

负载中挂载了Secret,Secret对应的值没有进行base64加密。

解决方案详情请参见工作负载挂载的密钥值不符合要求

Kubernetes事件信息如下:

the failed container exited with ExitCode: 255

可能是在ARM架构的节点上运行x86的容器镜像。

解决方案详情参见容器镜像版本与节点架构不符

Kubernetes事件信息如下:

the failed container exited with ExitCode: 141

containerd版本与tail版本不兼容导致。

解决方案详情参见容器启动命令中执行tail -f xx退出(退出码:141)

Kubernetes事件信息如下:

Created container init-pinpoint

Java探针的版本不兼容导致。

解决方案详情参见JAVA探针的版本不兼容

其他Pod日志

请结合业务进行排查。

排查方案请参见业务配置问题排查

容器中无持续运行的进程(退出码:0)

  1. 登录异常工作负载所在的节点。
  2. 查看容器状态。

    如果节点为docker,请执行docker命令:

    docker ps -a | grep $podName
    如果节点为containerd,请执行containerd命令:
    crictl ps -a | grep $podName

    如下图所示:

    当容器中无持续运行的进程时,会出现exit(0)的状态码,此时说明容器中无进程。

健康检查执行失败(退出码:137)

工作负载配置的健康检查会定时检查业务,异常情况下pod会报实例不健康的事件且pod一直重启失败。

工作负载若配置liveness型(工作负载存活探针)健康检查,当健康检查失败次数超过阈值时,会重启实例中的容器。在工作负载详情页面查看事件,若K8s事件中出现“Liveness probe failed: Get http…”时,表示健康检查失败。

解决方案:

请在工作负载详情页中,切换至“容器管理”页签,核查容器的“健康检查”配置信息,排查健康检查策略是否合理或业务是否已异常。

容器所在磁盘空间不足

如下磁盘为创建节点时选择的docker专用盘分出来的thinpool盘,以root用户执行lvs命令可以查看当前磁盘的使用量。

Thin Pool has 15991 free data blocks which is less than minimum required 16383 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior

解决方案:

方案一:清理镜像

您可以执行以下步骤清理未使用的镜像:
  • 使用containerd容器引擎的节点:
    1. 查看节点上的本地镜像。
      crictl images -v
    2. 确认镜像无需使用,并通过镜像ID删除无需使用的镜像。
      crictl rmi {镜像ID}
  • 使用docker容器引擎的节点:
    1. 查看节点上的本地镜像。
      docker images
    2. 确认镜像无需使用,并通过镜像ID删除无需使用的镜像。
      docker rmi {镜像ID}

请勿删除cce-pause等系统镜像,否则可能导致无法正常创建容器。

方案二:扩容磁盘

扩容磁盘的操作步骤如下:

  1. 在EVS控制台扩容数据盘。详情请参见扩容云硬盘容量

    在EVS控制台扩容成功后,仅扩大了云硬盘的存储容量,还需要执行后续步骤扩容逻辑卷和文件系统。

  2. 登录CCE控制台,进入集群,在左侧选择“节点管理”,单击节点后的“同步云服务器”
  3. 登录目标节点。
  4. 使用lsblk命令查看节点块设备信息。

    这里存在两种情况,根据容器存储Rootfs而不同。

容器资源配置过小

事件详情中有OOM字样。并且,在日志中也会有记录:

cat /var/log/messages | grep 96feb0a425d6 | grep oom

创建工作负载时,设置的限制资源若小于实际所需资源,会触发系统OOM,并导致容器异常退出。

同一Pod中container端口冲突

  1. 登录异常工作负载所在的节点。
  2. 查看工作负载实例非正常退出的容器ID。

    如果节点为docker,请执行docker命令:

    docker ps -a | grep $podName
    如果节点为containerd,请执行containerd命令:
    crictl ps -a | grep $podName

  3. 查看退出容器的错误日志。

    如果节点为docker,请执行docker命令:

    docker logs $containerID
    如果节点为containerd,请执行containerd命令:
    crictl logs $containerID

    根据日志提示修复工作负载本身的问题。如下图所示,即同一Pod中的container端口冲突导致容器启动失败。

    图1 container冲突导致容器启动失败

解决方案:

配置正确的容器端口,确保端口不冲突,然后重新创建工作负载。

如果Pod使用主机网络(即配置hostNetwork: true)也可能会出现容器端口冲突,这是因为Pod内的容器会直接与宿主机共享网络接口和端口空间,多个使用相同端口的Pod无法运行在同一节点上。

工作负载挂载的密钥值不符合要求

事件详情中出现以下错误:

Error: failed to start container "filebeat": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"setenv: invalid argument\"": unknown

出现以上问题的根因是由于工作负载中挂载了Secret,但Secret对应的值没有进行base64加密。

解决方案:

通过控制台创建Secret,Secret对应的值会自动进行base64加密。

如果通过YAML进行创建,需要手动对密钥值进行base64加密:

echo -n "待编码内容" | base64

容器镜像版本与节点架构不符

在ARM架构的节点上创建工作负载时未使用正确的镜像版本,使用正确的镜像版本即可解决该问题。

如果您需要构建x86和ARM双架构镜像,请参考CCE中使用x86和ARM双架构镜像

容器启动命令中执行tail -f xx退出(退出码:141)

Kubernetes事件为:

the failed container exited with ExitCode: 141

问题根因:

containerd历史版本和容器镜像中tail>=8.28版本不兼容,导致tail -f 命令退出,退出码为141。

短期解决方案:

将启动参数中的tail -f xx修改为sleep 2 && tail -f xx,重新创建工作负载。

长期解决方案:

  • 将集群升级到v1.25.16-r20、v1.27.16-r20、v1.28.15-r10、v1.29.10-r10、v1.30.6-r10、v1.31.4-r0版本及以上。
  • 重置节点,将容器引擎切换为docker。

JAVA探针的版本不兼容

Kubernetes事件为:

Created container init-pinpoint

解决方案:

  1. 在创建工作负载时,在“高级配置”步骤下的“性能管理配置”项目下,JAVA探针版本请选择最新的版本(例如:1.0.36),不要选择latest版本。
  2. 如果工作负载创建时的JAVA探针版本已经选择了latest版本,可以更新工作负载配置,将JAVA探针版本请选择为最新的版本(例如:1.0.36)。

业务配置问题排查

请检查工作负载启动命令是否正确执行,或工作负载本身bug导致容器不断重启。

  1. 登录异常工作负载所在的节点。
  2. 查看工作负载实例非正常退出的容器ID。

    如果节点为docker,请执行docker命令:

    docker ps -a | grep $podName
    如果节点为containerd,请执行containerd命令:
    crictl ps -a | grep $podName

  3. 查看退出容器的错误日志。

    如果节点为docker,请执行docker命令:

    docker logs $containerID
    如果节点为containerd,请执行containerd命令:
    crictl logs $containerID

    注意:这里的containerID为已退出的容器的ID

    图2 容器启动命令配置不正确

    如上图所示,容器配置的启动命令不正确导致容器启动失败。其他错误请根据日志提示修复工作负载本身的BUG问题。

解决方案:

重新创建工作负载,并配置正确的启动命令。

相关文档