kubectl api-resources: Usage, Options & CI Errors
List every resource type the cluster actually understands.
kubectl api-resources enumerates the kinds the API server serves - built-ins and CRDs alike - with their short names and groups. It is the way to confirm a custom resource exists before you apply a manifest that uses it.
What it does
kubectl api-resources lists each resource type with its NAME, SHORTNAMES, APIVERSION, NAMESPACED flag, and KIND. Filter with --api-group, --namespaced=true/false, or --verbs=list. Its sibling kubectl api-versions lists the served group/versions. Together they tell you exactly what the cluster can accept.
Common usage
kubectl api-resources
kubectl api-resources --namespaced=true
kubectl api-resources --api-group=networking.k8s.io
kubectl api-resources | grep -i certificate # is cert-manager installed?
kubectl api-versionsCommon errors in CI
When kubectl apply fails with "unable to recognize ...: no matches for kind \"X\" in version \"Y\"", the cluster does not serve that kind. Confirm with kubectl api-resources | grep X. Almost always a CRD (cert-manager Certificate, an Ingress on an old apiVersion, an operator type) is not installed or the controller has not registered it yet. Gate manifest application on the CRD being present, or apply the CRD/operator first and kubectl wait for its establishment before applying resources that depend on 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