# kubectl api-resources: Usage, Options & CI Errors

> kubectl api-resources lists the resource types a cluster serves, with short names and API groups. How to confirm a CRD is installed before you apply.

Source: https://latchkey.dev/learn/command-reference/kubectl-api-resources  
Updated: 2026-06-25

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

```Terminal
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-versions
```

## Common 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.

```Terminal
# 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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl api-resources: Usage, Options & CI Errors?

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 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

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt