ClusterOperator Degraded Troubleshooting¶
Introduction¶
ClusterOperators report health for core OpenShift components. A Degraded or Progressing operator should be investigated with its status message, related pods, and namespace events.
Why This Matters¶
OpenShift administration relies on operators and cluster-scoped resources. A bad change can affect many projects, so inspect status and events before applying fixes.
Practical Examples¶
oc get clusteroperators
oc describe clusteroperator ingress
oc get pods -n openshift-ingress-operator
oc get events -n openshift-ingress-operator --sort-by=.lastTimestamp
Example output:
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
ingress 4.15.12 True False False 8d The ingress operator is available.
Verification¶
oc get co ingress
oc describe co ingress
oc get pods -n openshift-ingress-operator
Troubleshooting¶
Read the operator message, check the namespace where the component runs, inspect related events, and confirm whether the condition is Available, Progressing, or Degraded.
Common Mistakes¶
- Reacting only to the table status and ignoring the message.
- Checking application namespaces for platform operator pods.
- Restarting operator pods before reading events.
Quick Checklist¶
- Confirm the active project.
- Inspect the exact object named in the error.
- Read recent events.
- Apply one focused fix.
- Verify status after the change.
Related Guides¶
Summary¶
ClusterOperator Degraded Troubleshooting is an administration task that should be driven by cluster status, operator conditions, and component logs instead of broad restarts.