kustomization.yaml & resources

The file that ties it together.

Intermediate12 min · lesson 2 of 12

Every Kustomize directory has a kustomization.yaml — the control file that declares which resources to include and how to transform them. At minimum it lists resources (the manifest files or directories to pull in). Beyond that it can add common labels and annotations, set a namespace or name prefix/suffix, generate ConfigMaps and Secrets, apply patches, and pull in other kustomizations. It is the single entry point Kustomize reads.

kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
namespace: payments
namePrefix: prod-
commonLabels:
app.kubernetes.io/part-of: payments
environment: prod

Declarative cross-cutting edits

Notice what the file above does without touching the manifests: it puts every resource in the payments namespace, prefixes every name with prod-, and stamps common labels on all of them. These are transformers (covered in depth later) applied declaratively across the whole set. This is the core idea — you describe the transformation in kustomization.yaml, and Kustomize rewrites the plain manifests accordingly at build time.

terminal
$ kustomize build .
# deployment + service, now namespaced payments, named prod-*, with the common labels
apiVersion: apps/v1
kind: Deployment
metadata:
name: prod-payments-api
namespace: payments
labels: { environment: prod, app.kubernetes.io/part-of: payments }
commonLabels also change selectors — mind existing workloads
commonLabels adds labels to metadata AND to selectors (Deployment matchLabels, Service selector), which is usually what you want for new resources but can break an existing Deployment: selectors are immutable, so applying a new common label to a live Deployment can be rejected. Set label strategy deliberately (commonLabels vs the newer labels transformer with includeSelectors:false) when retrofitting Kustomize onto running apps.