Check for Pending or Crashing Pods with OpenShift 4.x

Environment

• Red Hat OpenShift Container Platform
  • 4.x

Issue

• I have pods in a pending state and would like to know why?

Diagnostic Steps

• You can investigate any pods listed as Pending with:

  $ oc --config=${INSTALL_DIR}/auth/kubeconfig describe -n openshift-cluster-api pod/machine-api-operator-586bd5b6b9-bxq9s
  

  • which may show events with warnings like

    Warning  FailedScheduling  1m (x10 over 1m)  default-scheduler  0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
    

• You can get the image used for a crashing pod with:

  $ oc --config=${INSTALL_DIR}/auth/kubeconfig get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" -n openshift-cluster-api machine-api-operator-586bd5b6b9-bxq9s
  

  • which should show you something like:

    machine-api-operator	map[running:map[startedAt:2018-11-13T19:04:50Z]]	registry.svc.ci.openshift.org/openshift/origin-v4.0-20181113175638@sha256:c97d0b53b98d07053090f3c9563cfd8277587ce94f8c2400b33e246aa08332c7
    

  • You may be asked by support to also supply the following:

    • Note: The release (registry.svc.ci.openshift.org/openshift/origin-release:v4.0-20181113175638) will need to be substituted with the release image specified by the command above!

    $ oc adm release info registry.svc.ci.openshift.org/openshift/origin-release:v4.0-20181113175638 --commits
    

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.