Gera Tools

Kubernetes Resource Types

All Kubernetes API resource types with shortnames, API group and scope.

Searchable Kubernetes resource-type reference listing each kind with its API group and version, shortname aliases, whether it is namespaced or cluster-scoped, and a plain-English description.

What is the difference between namespaced and cluster-scoped resources?

Namespaced resources like Pods, Services and Deployments live inside a namespace and are isolated by it. Cluster-scoped resources like Nodes, PersistentVolumes, StorageClasses and ClusterRoles exist once for the whole cluster and are not tied to a namespace.

Know your Kubernetes kinds

Kubernetes exposes dozens of object types through its API, each identified by a kind and an apiVersion. This reference lists the common built-in resources with their shortname aliases, API group and version, and whether they are namespaced or cluster-scoped. Search by kind, shortname or group, or filter by scope.

How it works

The Kubernetes API is organised into groups (apps, batch, networking.k8s.io, rbac.authorization.k8s.io, and so on) and versions (v1, v2). A manifest must declare both via apiVersion, plus the kind. The core group has no name, so its resources use a bare version like v1 — that is why a Pod is apiVersion: v1 but a Deployment is apiVersion: apps/v1.

Every resource type also has a scope. Namespaced resources are partitioned by namespace, so two namespaces can each hold a Service called web. Cluster-scoped resources — Nodes, PersistentVolumes, StorageClasses, CustomResourceDefinitions and the cluster-level RBAC objects — exist once across the whole cluster. The scope filter in this tool mirrors kubectl api-resources --namespaced=true|false.

Tips and examples

  • Use shortnames to move faster, for example:
kubectl get deploy        # Deployment
kubectl get sts           # StatefulSet
kubectl get pvc           # PersistentVolumeClaim
  • Discover what your specific cluster supports, including CRDs, with kubectl api-resources and kubectl explain <kind> for field documentation.
  • When writing manifests, always match kind to the correct apiVersion; a mismatch (for example apiVersion: v1 with kind: Deployment) is rejected by the API server.
  • Custom resources installed by operators appear here too once their CustomResourceDefinition is applied, and they follow the same namespaced/cluster-scoped rules.