kubectl get componentstatuses: Usage & Common CI Errors
Check scheduler, controller-manager, and etcd health - with caveats.
kubectl get componentstatuses (short name cs) reports the health of core control-plane components. It is a legacy, deprecated check that behaves inconsistently on managed clusters, so know what it does and does not tell you.
What it does
kubectl get componentstatuses queries the deprecated ComponentStatus API for scheduler, controller-manager, and etcd, printing Healthy/Unhealthy. The mechanism predates modern health endpoints and is unreliable; the supported replacement is the /healthz, /livez, and /readyz endpoints on each component.
Common usage
kubectl get componentstatuses
kubectl get cs
kubectl get --raw='/readyz?verbose' # the modern replacement
kubectl get --raw='/livez?verbose'Common errors in CI
On managed clusters (EKS, GKE, AKS) the control plane is hidden, so componentstatuses often returns empty, Unknown, or "did not check" health-check entries - that is not a cluster fault, it is the API being deprecated and unsupported there. Do not gate CI on cs; it can report Unhealthy due to a removed insecure port even on a perfectly healthy cluster. Use kubectl get --raw='/readyz?verbose' against the API server, or the provider's own health surface, for a real control-plane check. Treat any cs script as legacy and migrate it.