An explanation of the fields in a kustomization.yaml file.
What existing things should be customized.
Field | Type | Explanation |
---|---|---|
resources | list | completely specified k8s API objects, e.g. deployment.yaml, configmap.yaml, etc |
bases | list | paths or github URLs specifying directories containing a kustomization. These bases may be subjected to more customization, or merely included in the output. |
CRDs | list | custom resource definition files, to allow specification of the custom resources in the resources list. |
What things should be created (and optionally subsequently customized)?
Field | Type | Explanation |
---|---|---|
configMapGenerator | list | Each entry in this list results in the creation of one ConfigMap resource (it's a generator of n maps). |
secretGenerator | list | Each entry in this list results in the creation of one Secret resource (it's a generator of n secrets) |
generatorOptions | string | generatorOptions modify behavior of all ConfigMap and Secret generators |
generators | list | plugin configuration files |
What transformations (customizations) should be applied?
Field | Type | Explanation |
---|---|---|
commonLabels | string | Adds labels and some corresponding label selectors to all resources. |
commonAnnotations | string | Adds annotions (non-identifying metadata) to add all resources. |
images | list | Images modify the name, tags and/or digest for images without creating patches. |
inventory | struct | Specify an object who's annotations will contain a build result summary. |
namespace | string | Adds namespace to all resources |
namePrefix | string | Prepends value to the names of all resources |
nameSuffix | string | The value is appended to the names of all resources. |
replicas | list | Replicas modifies the number of replicas of a resource. |
patchesStrategicMerge | list | Each entry in this list should resolve to a partial or complete resource definition file. |
patchesJson6902 | list | Each entry in this list should resolve to a kubernetes object and a JSON patch that will be applied to the object. |
transformers | list | plugin configuration files |
Field | Type | Explanation |
---|---|---|
vars | string | Vars capture text from one resource's field and insert that text elsewhere. |
apiVersion | string | k8s metadata field. |
kind | string | k8s metadata field. |
If missing, this field's value defaults to
apiVersion: kustomize.config.k8s.io/v1beta1
Each entry in this list should resolve to a directory containing a kustomization file, else the customization fails.
The entry could be a relative path pointing to a local directory or a url pointing to a directory in a remote repo. The url should follow hashicorp/go-getter URL format https://github.com/hashicorp/go-getter#url-format
The presence of this field means this file (the file you a reading) is an overlay that further customizes information coming from these bases.
Typical use case: a dev, staging and production environment that are mostly identical but differing crucial ways (image tags, a few server arguments, etc. that differ from the common base).
bases:
- ../../base
- github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6
- github.com/kubernets-sigs/kustomize//examples/helloWorld?ref=test-branch
Adds labels to all resources and selectors
commonLabels:
someName: someValue
owner: alice
app: bingo
Adds annotions (non-identifying metadata) to add all resources. Like labels, these are key value pairs.
commonAnnotations:
oncallPager: 800-555-1212
Each entry in this list results in the creation of one ConfigMap resource (it's a generator of n maps).
The example below creates two ConfigMaps. One with the names and contents of the given files, the other with key/value as data.
Each configMapGenerator item accepts a parameter of
behavior: [create|replace|merge]
.
This allows an overlay to modify or
replace an existing configMap from the parent.
configMapGenerator:
- name: myJavaServerProps
files:
- application.properties
- more.properties
- name: myJavaServerEnvVars
literals:
- JAVA_HOME=/opt/java/jdk
- JAVA_TOOL_OPTIONS=-agentlib:hprof
Each entry in this list should be a relative path to a file for custom resource definition (CRD).
The presence of this field is to allow kustomize be aware of CRDs and apply proper transformation for any objects in those types.
Typical use case: A CRD object refers to a ConfigMap object. In a kustomization, the ConfigMap object name may change by adding namePrefix, nameSuffix, or hashing. The name reference for this ConfigMap object in CRD object need to be updated with namePrefix, nameSuffix, or hashing in the same way.
The annotations can be put into openAPI definitions are:
- "x-kubernetes-annotation": ""
- "x-kubernetes-label-selector": ""
- "x-kubernetes-identity": ""
- "x-kubernetes-object-ref-api-version": "v1",
- "x-kubernetes-object-ref-kind": "Secret",
- "x-kubernetes-object-ref-name-key": "name",
crds:
- crds/typeA.yaml
- crds/typeB.yaml
Modifies behavior of all ConfigMap and Secret generators.
generatorOptions:
# labels to add to all generated resources
labels:
kustomize.generated.resources: somevalue
# annotations to add to all generated resources
annotations:
kustomize.generated.resource: somevalue
# disableNameSuffixHash is true disables the default behavior of adding a
# suffix to the names of generated resources that is a hash of
# the resource contents.
disableNameSuffixHash: true
A list of generator plugin configuration files.
generators:
- mySecretGeneratorPlugin.yaml
- myAppGeneratorPlugin.yaml
Images modify the name, tags and/or digest for images without creating patches. E.g. Given this kubernetes Deployment fragment:
containers:
- name: mypostgresdb
image: postgres:8
- name: nginxapp
image: nginx:1.7.9
- name: myapp
image: my-demo-app:latest
- name: alpine-app
image: alpine:3.7
one can change the image
in the following ways:
postgres:8
tomy-registry/my-postgres:v1
,- nginx tag
1.7.9
to1.8.0
, - image name
my-demo-app
tomy-app
, - alpine's tag
3.7
to a digest value
all with the following kustomization:
images:
- name: postgres
newName: my-registry/my-postgres
newTag: v1
- name: nginx
newTag: 1.8.0
- name: my-demo-app
newName: my-app
- name: alpine
digest: sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3
See inventory object.
If missing, this field's value defaults to
kind: Kustomization
Adds namespace to all resources
namespace: my-namespace
Prepends value to the names of all resources
Ex. a deployment named wordpress
would become alices-wordpress
namePrefix: alices-
The value is appended to the names of all
resources. Ex. A deployment named wordpress
would become wordpress-v2
.
The suffix is appended before content has if resource type is ConfigMap or Secret.
nameSuffix: -v2
Each entry in this list should be a relative path resolving to a partial or complete resource definition file.
The names in these (possibly partial) resource files
must match names already loaded via the resources
field or via resources
loaded transitively via the
bases
entries. These entries are used to patch
(modify) the known resources.
Small patches that do one thing are best, e.g. modify a memory request/limit, change an env var in a ConfigMap, etc. Small patches are easy to review and easy to mix together in overlays.
patchesStrategicMerge:
- service_port_8888.yaml
- deployment_increase_replicas.yaml
- deployment_increase_memory.yaml
Each entry in this list should resolve to a kubernetes object and a JSON patch that will be applied to the object. The JSON patch is documented at https://tools.ietf.org/html/rfc6902
target field points to a kubernetes object within the same kustomization by the object's group, version, kind, name and namespace. path field is a relative file path of a JSON patch file. The content in this patch file can be either in JSON format as
[
{"op": "add", "path": "/some/new/path", "value": "value"},
{"op": "replace", "path": "/some/existing/path", "value": "new value"}
]
or in YAML format as
- op: add path: /some/new/path value: value
- op:replace path: /some/existing/path value: new value
patchesJson6902:
- target:
version: v1
kind: Deployment
name: my-deployment
path: add_init_container.yaml
- target:
version: v1
kind: Service
name: my-service
path: add_service_annotation.yaml
Replicas modified the number of replicas for a resource.
E.g. Given this kubernetes Deployment fragment:
metadata:
name: deployment-name
spec:
replicas: 3
one can change the number of replicas to 5 by adding the following to your kustomization:
replicas:
- name: deployment-name
count: 5
This field accepts a list, so many resources can be modified at the same time.
Each entry in this list must resolve to an existing resource definition in YAML. These are the resource files that kustomize reads, modifies and emits as a YAML string, with resources separated by document markers ("---").
resource:
- some-service.yaml
- sub-dir/some-deployment.yaml
Each entry in this list results in the creation of one Secret resource (it's a generator of n secrets).
secretGenerator:
- name: app-tls
files:
- secret/tls.cert
- secret/tls.key
type: "kubernetes.io/tls"
- name: app-tls-namespaced
# you can define a namespace to generate secret in, defaults to: "default"
namespace: apps
files:
- tls.crt=catsecret/tls.cert
- tls.key=secret/tls.key
type: "kubernetes.io/tls"
- name: env_file_secret
envs:
- env.txt
type: Opaque
Vars are used to capture text from one resource's field and insert that text elsewhere - a reflection feature.
For example, suppose one specifies the name of a k8s Service object in a container's command line, and the name of a k8s Secret object in a container's environment variable, so that the following would work:
containers:
- image: myimage
command: ["start", "--host", "$(MY_SERVICE_NAME)"]
env:
- name: SECRET_TOKEN
value: $(SOME_SECRET_NAME)
To do so, add an entry to vars:
as follows:
vars:
- name: SOME_SECRET_NAME
objref:
kind: Secret
name: my-secret
apiVersion: v1
- name: MY_SERVICE_NAME
objref:
kind: Service
name: my-service
apiVersion: v1
fieldref:
fieldpath: metadata.name
- name: ANOTHER_DEPLOYMENTS_POD_RESTART_POLICY
objref:
kind: Deployment
name: my-deployment
apiVersion: apps/v1
fieldref:
fieldpath: spec.template.spec.restartPolicy
A var is a tuple of variable name, object reference and field reference within that object. That's where the text is found.
The field reference is optional; it defaults to
metadata.name
, a normal default, since kustomize
is used to generate or modify the names of
resources.
At time of writing, only string type fields are supported. No ints, bools, arrays etc. It's not possible to, say, extract the name of the image in container number 2 of some pod template.
A variable reference, i.e. the string '$(FOO)', can only be placed in particular fields of particular objects as specified by kustomize's configuration data.
The default config data for vars is at https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/transformers/config/defaultconfig/varreference.go Long story short, the default targets are all container command args and env value fields.
Vars should not be used for inserting names in places where kustomize is already handling that job. E.g., a Deployment may reference a ConfigMap by name, and if kustomize changes the name of a ConfigMap, it knows to change the name reference in the Deployment.