Kustomize: Template-Free Kubernetes Configuration

WHY IT EXISTS: Managing Kubernetes YAML across different environments like dev, staging, and prod is repetitive and error-prone. Copy-pasting files leads to configuration drift, while full templating engines like Helm can introduce unwanted complexity. Kustomize was created to solve this middle ground.

THE MENTAL MODEL: Kustomize is a declarative YAML patcher, not a templating engine. You start with a "base" set of standard Kubernetes resource files. Then, for each environment, you create an "overlay" that specifies patches—changes to apply to the base—like modifying an image tag or increasing replica counts.

HOW IT WORKS: A project using Kustomize has a base directory with common YAML files and a kustomization.yaml listing them. It also has an overlays directory with subdirectories for each environment (e.g., staging, production). Each overlay has its own kustomization.yaml that references the base and defines patches. Running kubectl apply -k overlays/production merges the base and the production overlay to generate and apply the final configuration.

WHEN TO USE IT: Use Kustomize when you need to maintain slight variations of a core application configuration for different environments or tenants. It excels at keeping your configurations DRY (Don't Repeat Yourself) without adding the complexity of a full templating language.

WHEN NOT TO USE IT: If your configuration requires complex logic, conditionals, or loops, Kustomize is not the right tool; a templating engine like Helm would be more appropriate. For single, simple deployments with no variations, it can be unnecessary overhead.

ONE CANONICAL EXAMPLE: A base configuration defines a Deployment with replicas: 1. The overlays/production kustomization file includes a patch to change this value to replicas: 5 and adds a nodeSelector for production nodes. The overlays/staging kustomization might only patch the container image tag to use a v2.0-rc1 build.