Declarative specification of Kubernetes objects is the recommended way to manage Kubernetes production workloads, however gaps in the kubectl tooling force users to write their own scripting and tooling to augment the declarative tools with preprocessing transformations. While most of these transformations already exist as imperative kubectl commands, they are not natively accessible from a declarative workflow.
This KEP describes how
kustomize addresses this problem by providing a declarative format for users to access
the imperative kubectl commands they are already familiar natively from declarative workflows.
The kubectl command provides a cli for:
Generate a configmap or secret from a text or binary file
kubectl create configmap,
kubectl create secret
Create or update fields that cut across other fields and objects
Transform an existing declarative configuration without forking it
Transform live resources arbitrarily without auditing
To create a Secret from a binary file, users must first base64 encode the binary file and then create a Secret yaml config from the resulting data. Because the source of truth is actually the binary file, not the config, users must write scripting and tooling to keep the 2 sources consistent.
Instead, users should be able to access the simple, but necessary, functionality available in the imperative kubectl commands from their declarative workflow.
Kustomize addresses a number of long standing issues in kubectl.
The scope of kustomize is limited only to functionality gaps that would otherwise prevent users from
defining their workloads in a purely declarative manner (e.g. without writing scripts to perform pre-processing
or linting). Commands such as
kubectl create deployment and
kubectl edit are unnecessary
in a declarative workflow because a Deployment can easily be managed as declarative config.
The community has developed a number of facades in front of the Kubernetes APIs using templates or DSLs. Attempting to provide an alternative interface to the Kubernetes API is a non-goal. Instead the focus is on:
Note: This proposal has already been implemented in
Define a new meta config format called kustomization.yaml.
kubectl apply -f <file>)
kubectl apply -f <url>)
kubectl create configmap)
kubectl create secret)
Kustomize will also contain subcommands to facilitate authoring kustomization.yaml.
The edit subcommands will allow users to modify the kustomization.yaml through cli commands containing helpful messaging and documentation.
kubectl create configmapbut declarative in kustomization.yaml
kubectl create secretbut declarative in kustomization.yaml
The diff subcommand will allow users to see a diff of the original and transformed configuration files
Kustomize has already been implemented in the
github.com/kubernetes/kubectl repo, and should be moved to a
separate repo for the subproject.
Kustomize was initially developed as its own cli, however once it has matured, it should be published as a subcommand of kubectl or as a statically linked plugin. It should also be more tightly integrated with apply.
By not providing a viable option for working directly with Kubernetes APIs as json or yaml config, we risk the ecosystem becoming fragmented with various bespoke API facades. By ensuring the raw Kubernetes API json or yaml is a usable approach for declaratively managing applications, even tools that do not use the Kubernetes API as their native format can better work with one another through transformation to a common format.
kustomize was implemented in the kubectl repo before subprojects became a first class thing in Kubernetes. The code has been fully implemented, but it must be moved to a proper location.