所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

FusionCloud 6.3.1 故障处理 06

评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
组件pod处于CrashLoopBackOff状态故障

组件pod处于CrashLoopBackOff状态故障

现象描述

  • 平台组件pod处于CrashLoopBackOff状态,无法正常启动。
  • 组件相应功能异常。

可能原因

docker umount devicemapper失败,导致Docker挂载设备无法正常卸载,影响相应pod启动。

处理方法

  1. 使用PuTTY,登录om_core1_ip节点。

    默认帐号:paas,默认密码:QAZ2wsx@123!

  2. 执行以下命令检查pod是否正常。

    kubectl get pods --all-namespaces|grep CrashLoopBackOff

    manage        alm-website-1825011304-c7v32                     0/1       CrashLoopBackOff   205        11h

    如上所示,alm-website-1825011304-c7v32处于异常状态。

  3. 登录平台运维管理节点,执行以下命令获取异常组件所在节点IP。

    kubectl get pods PODNAME -o yaml -n NAMESPACE|grep hostIP

    其中,PODNAME为异常pod的名称;NAMESPACE为异常pod的namespace。

    hostIP: 10.109.220.168

    如上所示,节点IP为10.109.220.168。

  4. 判断组件异常是否由docker umount devicemapper失败问题引起。

    使用paas用户登录异常pod所在节点,再切换至root用户,执行以下命令。

    journalctl -n

    确认是否存在形如umount docker-thinpool failed的错误。

    • 如不存在,这说明pod处于CrashLoopBackOff不是由docker umount失败引起。
    • 如存在,记录删除失败的devicemapper文件系统编号,执行后续步骤。

  5. 执行以下命令,查询删除失败设备信息。

    mount|grep 文件系统编号

    其中,“文件系统编号”步骤 4中查询到的文件系统编号。

    记录删除失败的设备号。

  6. 卸载异常设备。

    umount 设备号

    其中,“设备号”步骤 5中查询到的设备号。

  7. 执行以下命令,获取状态为dead的容器的id。

    docker ps -a|grep dead

  8. 执行以下命令,删除容器。

    docker rm -f 容器id

    其中,“容器id步骤 7中获取到的容器id。

  9. 执行步骤 2的命令检查pod是否恢复正常,如正常,则无返回结果;否则,请联系技术支持处理。
翻译
下载文档
更新时间:2019-08-19

文档编号:EDOC1100043088

浏览量:18380

下载量:439

平均得分:
本文档适用于这些产品
相关版本
相关文档
Share
上一页 下一页