kubectl api-resources: List Available Types
kubectl api-resources prints the resource types the API server exposes, including their short names, API group, and whether they are namespaced.
When an apply fails with "no matches for kind", api-resources tells you what the cluster actually serves and under which group/version.
What it does
kubectl api-resources enumerates every served resource, with columns for NAME, SHORTNAMES, APIVERSION, NAMESPACED, and KIND. Filters narrow it: --namespaced, --api-group, and --verbs restrict to types supporting specific verbs.
Common usage
kubectl api-resources
# only namespaced types in one group
kubectl api-resources --namespaced=true --api-group=apps
# types you can list and watch (e.g. for RBAC design)
kubectl api-resources --verbs=list,watch -o name
# confirm a CRD kind is served
kubectl api-resources | grep -i certificateOptions
| Flag | What it does |
|---|---|
| --namespaced=true|false | Filter to namespaced or cluster-scoped types |
| --api-group=<group> | Restrict to one API group |
| --verbs=<list> | Only types supporting these verbs |
| -o name|wide | Name-only or extended output |
| --sort-by=name|kind | Sort the listing |
In CI
Run api-resources as a fast preflight: if a kind your manifests use is missing, the CRD is not installed and apply will fail with "no matches for kind". --verbs=list,watch -o name is handy when generating least-privilege RBAC rules from the real served types.
Common errors in CI
"error: unable to retrieve the complete list of server APIs: <group>/<version>: the server is currently unable to handle the request" means an aggregated API (often metrics or a flaky webhook) is down; the rest still lists. "couldn\'t get available api versions from server" points at a broken kubeconfig or unreachable API server, not at api-resources itself.