kubectl api-resources

When to Use kubectl api-resources

kubectl api-resources lists every resource type the Kubernetes API server supports. This includes built-in types like Pods, Services, and Deployments, as well as any Custom Resource Definitions (CRDs) installed in the cluster. It is essential for discovering what a cluster supports and for working with unfamiliar or extended clusters.

Understanding the Output

NAME                  SHORTNAMES   APIVERSION   NAMESPACED   KIND
pods                  po           v1           true         Pod
services              svc          v1           true         Service
deployments           deploy       apps/v1      true         Deployment
nodes                 no           v1           false        Node
namespaces            ns           v1           false        Namespace

• NAME: The resource name used in kubectl commands.
• SHORTNAMES: Abbreviations you can use instead of the full name.
• APIVERSION: The API group and version.
• NAMESPACED: Whether the resource lives inside a namespace.
• KIND: The resource kind used in YAML manifests.

Filtering by Scope

Cluster-scoped resources (Nodes, Namespaces, ClusterRoles) behave differently from namespaced resources:

# Only namespaced resources
kubectl api-resources --namespaced=true

# Only cluster-scoped resources
kubectl api-resources --namespaced=false

This distinction matters for RBAC. ClusterRoles grant access to cluster-scoped resources, while Roles only work within a namespace.

Filtering by Verb

Not all resources support all operations. To find resources you can create:

# Resources that support create
kubectl api-resources --verbs=create

# Resources that support list and delete
kubectl api-resources --verbs=list,delete

This is useful when writing RBAC policies — you can see which resources support which verbs.

Exploring API Groups

Kubernetes organizes resources into API groups. Core resources are in the empty group (v1), while newer resources are in named groups:

# Core API resources
kubectl api-resources --api-group=""

# Apps group (Deployments, StatefulSets, DaemonSets, ReplicaSets)
kubectl api-resources --api-group=apps

# Networking group (Ingress, NetworkPolicy)
kubectl api-resources --api-group=networking.k8s.io

# Custom resources (e.g., from Istio)
kubectl api-resources --api-group=networking.istio.io

Discovering CRDs

When you install operators or controllers, they register CRDs. Use api-resources to discover them:

# After installing cert-manager
kubectl api-resources --api-group=cert-manager.io
# Output shows: certificates, issuers, clusterissuers, etc.

# After installing Prometheus Operator
kubectl api-resources --api-group=monitoring.coreos.com
# Output shows: prometheuses, servicemonitors, alertmanagers, etc.

Using Short Names

Short names save keystrokes in daily work:

# These are equivalent
kubectl get pods
kubectl get po

kubectl get services
kubectl get svc

kubectl get deployments
kubectl get deploy

Find all short names with:

kubectl api-resources -o wide | grep -v "^NAME" | awk '$2 != "" {print $1, $2}'

Scripting and Automation

For comprehensive resource auditing:

# List all resources across all types in a namespace
for resource in $(kubectl api-resources --namespaced=true --verbs=list -o name); do
  echo "--- $resource ---"
  kubectl get "$resource" -n my-namespace --no-headers 2>/dev/null
done

This finds every resource in a namespace, something kubectl get all cannot do.

Comparing Cluster Capabilities

To compare what two clusters support:

kubectl api-resources --context=cluster-a -o name | sort > /tmp/a.txt
kubectl api-resources --context=cluster-b -o name | sort > /tmp/b.txt
diff /tmp/a.txt /tmp/b.txt

Differences indicate different Kubernetes versions, installed CRDs, or API server configurations.