Which API Group in k8s
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
In Kubernetes, the correct API group depends on the resource you are creating or querying. The practical answer is to look up the resource's apiVersion, because Kubernetes organizes resources by group and version, such as apps/v1, batch/v1, or the core group v1.
Understand Group And Version Together
Kubernetes does not use API group names in isolation. In manifests and API calls, you identify a resource with an apiVersion string.
Examples:
- '
v1for core resources' - '
apps/v1for Deployments' - '
batch/v1for Jobs and CronJobs' - '
rbac.authorization.k8s.io/v1for Roles and RoleBindings'
So when someone asks "which API group," the real question is usually "which apiVersion should this resource use?"
The Core Group Is Special
Some of the oldest and most fundamental resources belong to the core group, which is represented without a named prefix. That is why a Pod manifest uses:
There is no core/v1 string in manifests. The absence of a group prefix means the resource belongs to the legacy core API group.
Common core resources include:
- Pods
- Services
- ConfigMaps
- Secrets
- Namespaces
Common Non-Core API Groups
Most higher-level or specialized resources live in named groups.
A Deployment uses the apps group:
A Job uses the batch group:
This pattern is why memorizing one universal API group does not work. The group is tied to the resource family.
How To Discover The Right Group
The fastest way in a live cluster is kubectl api-resources.
That command shows resource names, short names, whether they are namespaced, and which API group they belong to.
To inspect available versions in more detail:
If you already know the kind, the Kubernetes documentation or an existing manifest is often enough. For example, if you know you need a Deployment, you can confidently use apps/v1 on modern clusters.
Custom Resources Have Their Own Groups
Custom Resource Definitions use API groups that you define yourself, usually under a domain-like name. For example:
This keeps custom APIs separate from built-in ones and avoids collisions.
When dealing with CRDs, the correct group is whatever the CRD author registered. That is another reason the answer is always resource-specific.
Version Matters Too
Do not stop at the group name alone. Version changes can deprecate older APIs. For example, many clusters used older beta versions for some resources in the past, but modern manifests usually target stable v1 APIs where available.
So the real checklist is:
- Identify the resource kind.
- Find the current supported
apiVersion. - Use that exact value in the manifest.
That is safer than guessing from memory.
Common Pitfalls
The biggest mistake is assuming every resource belongs to apps/v1 just because Deployments do. Pods, Services, Jobs, Ingresses, Roles, and CRDs all use different groups.
Another mistake is writing core/v1 for core resources. In Kubernetes manifests, core resources use plain v1.
People also copy old examples from blogs that use deprecated beta API versions. A manifest may look valid but fail on a newer cluster because that version is no longer served.
Finally, custom resources are not discoverable by intuition alone. Always inspect the CRD or the cluster output before writing the manifest.
Summary
- The correct Kubernetes API group depends on the resource kind.
- In manifests, you usually care about the full
apiVersion, not just the group name. - Core resources use plain
v1, while many others use named groups such asapps/v1orbatch/v1. - '
kubectl api-resourcesandkubectl api-versionsare the fastest discovery tools.' - For CRDs, use the exact group and version defined by the custom resource author.
Related reading
- Which kubernetes version is supported in docker version 18.09
- Whitelist kube-system namespace using NetworkPolicy
- Who starts kube-apiserver and how to configure its start up parameters?
- Why 10251 and 10252 port not used in k8s control plane?
- Why are Docker container images so large?
- Why are heaps in c implemented as algorithms instead of containers?
- Which jmx metric should be used to monitor the status of a connector in kafka connect?
- Which metrics should I use for an alarm HTTPCode_Target_5XX_Count or HTTPCode_ELB_5XX_Count?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.