Kustomize

Kustomize Basics

Kustomize ApiVersion Kind

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

Note

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?

BenefitDescription
StabilityPrevents defaults from shifting in newer Kustomize versions
ClarityMakes the file self-descriptive and easier to review
CompatibilityEnsures tools and CI/CD pipelines that parse your manifest won’t break later

Further Reading

Watch Video

Watch video content

Previous
Kustomize Output