What's the difference between resources and bases in a kustomization.yaml?

`resources` lists plain Kubernetes manifest files (or other kustomization directories) to include directly. `bases` specifically lists other kustomization directories meant to be layered on and customized, the classic pattern for an overlay (e.g. a 'production' kustomization that bases off a shared 'base' directory and patches it). Recent kustomize versions actually treat `bases` as deprecated in favor of just listing base directories under `resources`, but many existing repos and tutorials still use the separate `bases` field, so this tool supports both.

What does commonLabels actually do?

It injects the given key/value pairs as labels (and matching selector labels, where applicable) onto every resource kustomize processes, without you needing to edit each individual manifest file. It's the standard way to stamp a consistent label like `team: platform` or `environment: staging` across an entire set of resources from one place.

How does the namespace field differ from setting namespace in each manifest?

Setting `namespace` in the kustomization.yaml overrides (or sets) the namespace on every namespaced resource kustomize processes, in one place, rather than requiring you to edit metadata.namespace in every individual YAML file. It's especially useful for overlays that deploy the same base manifests into different namespaces per environment.

What does configMapGenerator with literals produce?

It has kustomize generate a ConfigMap on the fly (rather than you hand-writing one) from the literal key=value pairs you provide, and by default appends a content hash to the ConfigMap's name so that changing a value produces a new ConfigMap and correctly triggers a rolling update of anything referencing it, rather than silently updating in place.

kustomization.yaml Generator

Overview

Introduction

Kustomize's own file is famously light on required fields, but remembering the exact top-level keys, resources vs bases, commonLabels, the configMapGenerator's literals array, without a reference open is still a common source of typos.

This tool builds a kustomization.yaml from a form covering the fields most overlays actually use: a resources list, optional bases, commonLabels, a namespace override, and a configMapGenerator with literal values.

What Is Kustomization YAML Generator?

A form-based generator for `kustomization.yaml`, the file that tells `kubectl apply -k` or the standalone `kustomize` CLI which manifests to combine and how to customize them, without needing a templating engine.

It covers the fields that appear in the overwhelming majority of real kustomization files: which resource files and base directories to include, labels to stamp everywhere, a namespace override, and a simple generated ConfigMap.

How Kustomization YAML Generator Works

Each resource file path and base directory path you add becomes one entry in the `resources` and `bases` lists respectively; commonLabels key/value rows become entries under `commonLabels`, and the namespace field becomes a top-level `namespace: <value>` override.

If you fill in a configMapGenerator name, a `configMapGenerator` block is added with that name, and each key=value literal row is rendered as one entry in its `literals` list, exactly the syntax kustomize expects for inline ConfigMap generation.

When To Use Kustomization YAML Generator

Use it when setting up a new kustomize overlay or base directory and you need the kustomization.yaml that ties its manifest files together.

It's especially useful for the common 'base + per-environment overlay' pattern, generate a base kustomization listing your core resources, then generate per-environment overlays that set commonLabels and namespace differently while sharing the same bases.

Features

Advantages

Covers both the resources and bases fields, so it works whether you're describing a flat resource list or a layered base/overlay structure.
Renders the configMapGenerator's literals in the exact `KEY=value` syntax kustomize expects, avoiding a common formatting mistake.
Skips empty sections entirely rather than emitting empty placeholder keys, keeping the generated file close to what you'd hand-write for the same inputs.

Limitations

Supports one configMapGenerator block with literals only; workloads needing multiple generators, file-based ConfigMaps (`files:`), or a secretGenerator will need those added by hand.
Doesn't generate patches (`patchesStrategicMerge`/`patches`), the actual customization step in most real overlays, only the resource/base/label/namespace scaffolding around them.

Examples

A production overlay with a namespace override and a generated ConfigMap

Input

resources: [ingress.yaml], bases: [../base], commonLabels: [{key: environment, value: production}], namespace: production, configMapGeneratorName: app-config, configMapLiterals: [{key: LOG_LEVEL, value: warn}]

Output

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

resources:
  - ingress.yaml

bases:
  - ../base

commonLabels:
  environment: production

namespace: production

configMapGenerator:
  - name: app-config
    literals:
      - LOG_LEVEL=warn

Layers an ingress.yaml on top of a shared base, stamps environment: production everywhere, forces the production namespace, and generates an app-config ConfigMap with one literal value.

Best Practices & Notes

Best Practices

Keep a shared base directory listing the environment-agnostic resources, and use per-environment overlay kustomizations (with their own bases entry) to vary namespace, labels, and generated config.
Rely on configMapGenerator instead of hand-writing ConfigMaps whenever the values are simple key/value pairs, its automatic name-hashing correctly forces a rollout when a value changes.
Use commonLabels for labels that should truly apply everywhere (team ownership, environment); reach for per-resource labels or patches for anything that varies resource to resource.

Developer Notes

Trailing blank lines between sections are trimmed from the end of the generated output but preserved between populated sections, matching the loosely-spaced style most hand-written kustomization.yaml files use for readability. configMapGenerator literals are only emitted once a generator name is present; supplying literals without a name is treated as a validation error rather than silently generating an unnamed (and therefore invalid) ConfigMap.