文档首页> 云容器引擎 CCE> 常见问题> 工作负载> 工作负载异常> 工作负载异常:启动容器失败
更新时间:2022-05-06 GMT+08:00
分享

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

问题定位

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

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

    docker ps -a | grep $podName

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

    docker logs $containerID

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

  4. 查看操作系统的错误日志。

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

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

排查思路

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

表1 容器启动失败

日志或事件信息

问题原因与解决方案

日志中存在exit(0)

容器中无进程。

请调试容器是否能正常运行。

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

事件信息:Liveness probe failed: Get http…

日志中存在exit(137)

健康检查执行失败。

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

事件信息:

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

磁盘空间不足,需要清理磁盘空间。

排查项三:容器所在磁盘空间不足

日志中存在OOM字眼

内存不足。

排查项四:达到容器资源上限

排查项五:工作负载的容器规格设置较小导致

Address already in use

Pod中容器端口冲突

排查项六:同一pod中container端口冲突导致

出上述可能原因外,还可能存在如下原因,请根据顺序排查。

图1 排查思路

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

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

    docker 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

解决方案:

  1. 清理磁盘空间:
    docker rmi -f `docker images | grep myhuaweicloud | awk '{print $3}'` 
  2. 扩容磁盘:节点数据盘扩容方法请参见扩容节点数据盘(docker专用)

排查项四:达到容器资源上限

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

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

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

排查项五:工作负载的容器规格设置较小导致

工作负载的容器规格设置较小导致,若创建工作负载时,设置的限制资源少于实际所需资源,会导致启动容器失败。

排查项六:同一pod中container端口冲突导致

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

    docker ps -a | grep $podName

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

    docker logs $containerID

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

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

解决方案:

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

排查项七:容器启动命令配置有误导致

错误信息如下图所示:

解决方案:

核查“工作负载详情>更新升级页签>高级配置>启动命令”中的信息,确保启动命令配置正确。

排查项八:JAVA探针的版本选择latest导致

K8S事件为Created container init-pinpoint

解决方案:

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

  2. 如果工作负载创建时的JAVA探针版本已经选择了latest版本,可以更新工作负载配置,将JAVA探针版本请选择为最新的版本(例如:1.0.36)。

排查项九:用户自身业务BUG

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

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

    docker ps -a | grep $podName

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

    docker logs $containerID

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

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

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

解决方案:

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

分享:

工作负载异常 所有常见问题

more

关闭导读