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.

What does apiVersion mean for a resource?

apiVersion combines the API group and version, for example apps/v1 or networking.k8s.io/v1. Core resources such as Pod and Service have no group prefix and use just v1. You must set the matching apiVersion in every manifest.

What are kubectl shortnames?

Shortnames are aliases that save typing, such as po for Pod, svc for Service, deploy for Deployment and hpa for HorizontalPodAutoscaler. Run kubectl api-resources to see the full list available in your cluster.

How do I list every resource type in my cluster?

Run kubectl api-resources, which prints each kind with its shortnames, API group, namespaced flag and verbs. Add --namespaced=true or --namespaced=false to filter by scope, matching the toggle in this tool.

Why are RBAC resources split into Role and ClusterRole?

Role grants permissions within a single namespace, while ClusterRole grants permissions cluster-wide or for cluster-scoped resources. They are paired with RoleBinding and ClusterRoleBinding respectively to attach the permissions to users, groups or service accounts.

What is the Kubernetes Resource Types?

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. It runs free in your browser on Gera Tools, with nothing uploaded.

Kubernetes Resource Types

Name: Kubernetes Resource Types
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

The main API groups and what they contain

Understanding which group a resource belongs to saves time when writing manifests and setting RBAC rules:

API group	Typical resources
`v1` (core)	Pod, Service, ConfigMap, Secret, PersistentVolumeClaim, ServiceAccount
`apps/v1`	Deployment, StatefulSet, DaemonSet, ReplicaSet
`batch/v1`	Job, CronJob
`networking.k8s.io/v1`	Ingress, NetworkPolicy, IngressClass
`rbac.authorization.k8s.io/v1`	Role, ClusterRole, RoleBinding, ClusterRoleBinding
`storage.k8s.io/v1`	StorageClass, VolumeAttachment
`policy/v1`	PodDisruptionBudget
`autoscaling/v2`	HorizontalPodAutoscaler

Operator-installed CRDs slot into their own custom groups, such as cert-manager.io/v1 for Certificate and Issuer resources. Those resources follow exactly the same namespaced/cluster-scoped rules as the built-in types.

Common mistakes

Wrong apiVersion for the kind. The most frequent manifest error is pairing a kind with a stale or wrong group, for example writing apiVersion: extensions/v1beta1 for an Ingress that moved to networking.k8s.io/v1 in Kubernetes 1.19. The API server rejects any mismatch immediately.

Applying namespaced resources without a namespace. If you omit --namespace or metadata.namespace, kubectl targets the current context namespace, which may not be what you intend. For cluster-scoped resources the namespace field has no effect and should be left blank.

Missing RBAC for cluster-scoped resources. A Role only grants access within one namespace. To allow a service account to read Nodes or PersistentVolumes you need a ClusterRole paired with a ClusterRoleBinding.

Tips and examples

Use shortnames to move faster, for example:

kubectl get deploy        # Deployment
kubectl get sts           # StatefulSet
kubectl get pvc           # PersistentVolumeClaim
kubectl get hpa           # HorizontalPodAutoscaler
kubectl get ep            # Endpoints

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.
Run kubectl api-resources --verbs=list --namespaced -o name to see every resource your account can list in the current namespace — useful for auditing what a service account can reach.