No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


FusionCloud Troubleshooting Guide 02

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Pod Start Failures

Pod Start Failures


A pod fails to be started. ­­The pod is in the CrashLookBack, ExecuteCommandFailed, or ErrPackagePull state.

Possible Causes

  • The health check rules are set for the application. Because the health check fails, the pod is in the CrashLookBack state and restarts continuously.
  • When a non-containerized application is started (the pod is in the ExecuteCommandFailed state), the script fails to be executed.
  • The paths of the image and software packages are incorrect when the pod is in the ErrPackagePull state.

Troubleshooting Method

  1. Locate the CrashLookBack fault.

    1. Use PuTTY to log in to the om_core1_ip node.

      The default username is paas, and the default password is QAZ2wsx@123!.

    2. Run the following command to check whether the container is in the unhealthy state:

      kubectl describe pod {podname} -n {namespace}

    3. Run the following command to check the execution of the health check script:

      kubectl get pod {podname} -n {namespace} -oyaml

  2. Locate the ExecuteCommandFailed fault.

    Run the following command:

    kubectl describe pod {podname} -n {namespace}

    Run the following command to query the IP address of the node where the pod locates.

    kubectl get pod podname -n namespace -owide

    Information similar to the following is displayed.

    Log in to the node as user paas and switch to the directory where the pod locates, for example, /var/lib/kubelet/pods/9eb4b065-3a3f-11e7-ba5b-286ed48926f2/processes/{Process name}/log/

    Query the *.stderr log information to locate the cause.

  3. Locate the ErrPackagePull fault.

    Run the following command to check whether the pod is in the ErrPackagePull state:

    kubectl get pod {podname} -n {namespace}

    Run the following command to view the software package or image path and the version number:

    kubectl describe pod {podname} -n {namespace}

    1. Check whether the software or image exists in the software or image repository. If the software or image does not exist, upload it.
    2. Send a request to curl -k (IP address of the software repository in the red box) using curl -k to check whether the network connection is normal. If the fault persists, check the network.
    3. If the fault still cannot be solved, contact technical support for assistance.

Updated: 2019-06-10

Document ID: EDOC1100063248

Views: 22802

Downloads: 37

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Previous Next