Kustomize ApiVersion Kind - KodeKloud

Kustomize: Specifying `apiVersion` and `kind`

When authoring your kustomization.yaml, explicitly declaring the apiVersion and kind fields is a recommended best practice. Although Kustomize infers sensible defaults when they’re omitted, specifying them ensures compatibility with future Kustomize releases and helps prevent unexpected breaking changes.

Example `kustomization.yaml`

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

# List of Kubernetes manifests managed by Kustomize
resources:
  - nginx-depl.yaml
  - nginx-service.yaml

# Apply these labels to every resource
commonLabels:
  company: KodeKloud

Defining apiVersion and kind in your kustomization.yaml locks in the schema and ensures that Kustomize processes your resources exactly as intended, even after upgrades.

Why Declare `apiVersion` and `kind`?

Benefit	Description
Stability	Prevents defaults from shifting in newer Kustomize versions
Clarity	Makes the file self-descriptive and easier to review
Compatibility	Ensures tools and CI/CD pipelines that parse your manifest won’t break later

Further Reading

Watch Video