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:

• 'v1 for core resources'
• 'apps/v1 for Deployments'
• 'batch/v1 for Jobs and CronJobs'
• 'rbac.authorization.k8s.io/v1 for 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:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: demo-pod
5spec:
6  containers:
7    - name: app
8      image: nginx:1.27

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:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: web
10  template:
11    metadata:
12      labels:
13        app: web
14    spec:
15      containers:
16        - name: nginx
17          image: nginx:1.27

A Job uses the batch group:

1apiVersion: batch/v1
2kind: Job
3metadata:
4  name: report-job
5spec:
6  template:
7    spec:
8      restartPolicy: Never
9      containers:
10        - name: worker
11          image: python:3.12
12          command: ["python", "-c", "print('done')"]

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.

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:

kubectl api-versions

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:

1apiVersion: platform.example.com/v1alpha1
2kind: BackupPolicy
3metadata:
4  name: nightly

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:

1. Identify the resource kind.
2. Find the current supported apiVersion.
3. 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 as apps/v1 or batch/v1.
• 'kubectl api-resources and kubectl api-versions are the fastest discovery tools.'
• For CRDs, use the exact group and version defined by the custom resource author.