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.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes