kustomize

Create a kustomization file with resources and namespace

$ kustomize create --resources [deployment.yaml,service.yaml] --namespace [staging]

$ kustomize build . | kubectl apply [[-f|--filename]] -

$ kustomize edit set image [busybox=alpine:3.6]

$ kustomize create --autodetect

kustomize command [options] [arguments]

Common commands:
kustomize build kustomization_directory [options]
kustomize create [kustomization_directory]
kustomize edit subcommand [arguments]
kustomize diff [kustomization_directory] [options]

build
    Generates the customized Kubernetes manifests based on the kustomization.yaml file in the specified directory. This is the primary command for outputting final configurations.

--output, -o
    Used with build to write the generated manifests to a specified file instead of standard output.

--enable-helm
    An experimental flag for build to enable integration with Helm charts as bases for customization.

--load-restrictor
    Controls how files are loaded during build. Options include 'Static' (only allows files from the kustomization root), 'LoaderOnly', or 'None'.

create
    Initializes a new kustomization.yaml file in the current or specified directory, making it a kustomization root.

edit
    Provides subcommands to modify the kustomization.yaml file programmatically, such as adding resources, patches, or setting common fields.

edit add resource
    Adds a new resource (YAML file path) to the list of resources in the kustomization.yaml.

edit set nameprefix
    Sets a common name prefix for all resources defined in the kustomization.yaml.

edit set namespace
    Sets a common namespace for all resources defined in the kustomization.yaml, overriding individual resource namespaces.

diff []
    Compares a kustomization with another kustomization or with resources currently deployed in a cluster, showing differences.

kustomize is a standalone tool for customizing Kubernetes configurations declaratively. It enables users to manage multiple variations of an application's manifests without modifying the original base YAML files. Instead, it employs an overlay approach, defining transformations, patches, and modifications on top of immutable base configurations.

This method avoids the complexities of traditional templating engines by operating directly on structured YAML. It is widely used for managing different environments (e.g., development, staging, production) or specific deployment scenarios, promoting GitOps practices by making configurations composable and version-controllable. A significant aspect of kustomize is its integration directly into kubectl, making it a powerful and convenient built-in method for applying customized configurations.

kustomize is not a general-purpose templating engine; it does not support conditional logic, loops, or complex programmatic transformations like Go templates or Jinja2. It operates strictly on Kubernetes YAML manifest structure. Its power comes from its declarative nature and direct integration with kubectl, but this also means it's less flexible for highly dynamic, non-Kubernetes-specific configurations. Understanding Kubernetes YAML structure is crucial for effective use.

The central configuration file for kustomize. This YAML file, typically named kustomization.yaml (or kustomization.yml), defines all the customization rules, including lists of base resources, patches, common labels, common annotations, name prefixes, suffixes, image transformations, and other generators/transformers applied to the base manifests. It is the entry point for kustomize to understand how to build the final set of Kubernetes objects.

One of the most powerful features of kustomize is its direct integration into the kubectl command-line tool. Users can build and apply a kustomization directly by running kubectl apply -k . This seamless integration eliminates the need to run kustomize build separately and then pipe the output to kubectl apply, streamlining the deployment workflow for customized Kubernetes applications.

kustomize was developed by Google as part of the broader Kubernetes ecosystem. It emerged from the need for a simpler, declarative alternative to traditional templating engines for managing Kubernetes configurations across different environments. Initially released as a standalone command-line tool, its significance grew rapidly, leading to its integration directly into kubectl starting with Kubernetes 1.14 (via `kubectl apply -k`). This integration made it a de facto standard for configuration management within the Kubernetes community, solidifying its role as a core component for customizing Kubernetes applications without boilerplate or complex templating logic.

kubectl(1), helm(1), yq(1), jq(1)