Builtin Plugins

Builtin Plugins

Builtin Plugins

A list of kustomize’s builtin plugins - both generators and transformers.

For each plugin, an example is given for

  • implicitly triggering the plugin via a dedicated kustomization file field (e.g. the AnnotationsTransformer is triggered by the commonAnnotations field).

  • explicitly triggering the plugin via the generators or transformers field (by providing a config file specifying the plugin).

The former method is convenient but limited in power as most of the plugins arguments must be defaulted. The latter method allows for complete plugin argument specification.

AnnotationTransformer

Usage via kustomization.yaml

field name: commonAnnotations

Adds annotions (non-identifying metadata) to add all resources. Like labels, these are key value pairs.

  1. commonAnnotations:
  2. oncallPager: 800-555-1212

Usage via plugin

Arguments

Annotations map[string]string

FieldSpecs []config.FieldSpec

Example

  1. apiVersion: builtin
  2. kind: AnnotationsTransformer
  3. metadata:
  4. name: not-important-to-example
  5. annotations:
  6. app: myApp
  7. greeting/morning: a string with blanks
  8. fieldSpecs:
  9. - path: metadata/annotations
  10. create: true

ConfigMapGenerator

Usage via kustomization.yaml

field name: configMapGenerator

Each entry in this list results in the creation of one ConfigMap resource (it’s a generator of n maps).

The example below creates three ConfigMaps. One with the names and contents of the given files, one with key/value as data, and a third which sets an annotation and label via options for that single ConfigMap.

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.

Also, each entry has an options field, that has the same subfields as the kustomization file’s generatorOptions field.

This options field allows one to add labels and/or annotations to the generated instance, or to individually disable the name suffix hash for that instance. Labels and annotations added here will not be overwritten by the global options associated with the kustomization file generatorOptions field. However, due to how booleans behave, if the global generatorOptions field specifies disableNameSuffixHash: true, this will trump any attempt to locally override it.

  1. # These labels are added to all configmaps and secrets.
  2. generatorOptions:
  3. labels:
  4. fruit: apple
  5. configMapGenerator:
  6. - name: my-java-server-props
  7. behavior: merge
  8. files:
  9. - application.properties
  10. - more.properties
  11. - name: my-java-server-env-vars
  12. literals:
  13. - JAVA_HOME=/opt/java/jdk
  14. - JAVA_TOOL_OPTIONS=-agentlib:hprof
  15. options:
  16. disableNameSuffixHash: true
  17. labels:
  18. pet: dog
  19. - name: dashboards
  20. files:
  21. - mydashboard.json
  22. options:
  23. annotations:
  24. dashboard: "1"
  25. labels:
  26. app.kubernetes.io/name: "app1"

It is also possible to define a key to set a name different than the filename.

The example below creates a ConfigMap with the name of file as myFileName.ini while the actual filename from which the configmap is created is whatever.ini.

  1. configMapGenerator:
  2. - name: app-whatever
  3. files:
  4. - myFileName.ini=whatever.ini

Usage via plugin

Arguments

types.ConfigMapArgs

Example

  1. apiVersion: builtin
  2. kind: ConfigMapGenerator
  3. metadata:
  4. name: mymap
  5. envs:
  6. - devops.env
  7. - uxteam.env
  8. literals:
  9. - FRUIT=apple
  10. - VEGETABLE=carrot

ImageTagTransformer

Usage via kustomization.yaml

field name: images

Images modify the name, tags and/or digest for images without creating patches. E.g. Given this kubernetes Deployment fragment:

  1. containers:
  2. - name: mypostgresdb
  3. image: postgres:8
  4. - name: nginxapp
  5. image: nginx:1.7.9
  6. - name: myapp
  7. image: my-demo-app:latest
  8. - name: alpine-app
  9. image: alpine:3.7

one can change the image in the following ways:

  • postgres:8 to my-registry/my-postgres:v1,
  • nginx tag 1.7.9 to 1.8.0,
  • image name my-demo-app to my-app,
  • alpine’s tag 3.7 to a digest value

all with the following kustomization:

  1. images:
  2. - name: postgres
  3. newName: my-registry/my-postgres
  4. newTag: v1
  5. - name: nginx
  6. newTag: 1.8.0
  7. - name: my-demo-app
  8. newName: my-app
  9. - name: alpine
  10. digest: sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3

Usage via plugin

Arguments

ImageTag image.Image

FieldSpecs []config.FieldSpec

Example

  1. apiVersion: builtin
  2. kind: ImageTagTransformer
  3. metadata:
  4. name: not-important-to-example
  5. imageTag:
  6. name: nginx
  7. newTag: v2

LabelTransformer

Usage via kustomization.yaml

field name: commonLabels

Adds labels to all resources and selectors

  1. commonLabels:
  2. someName: someValue
  3. owner: alice
  4. app: bingo

Usage via plugin

Arguments

Labels map[string]string

FieldSpecs []config.FieldSpec

Example

  1. apiVersion: builtin
  2. kind: LabelTransformer
  3. metadata:
  4. name: not-important-to-example
  5. labels:
  6. app: myApp
  7. env: production
  8. fieldSpecs:
  9. - path: metadata/labels
  10. create: true

NamespaceTransformer

Usage via kustomization.yaml

field name: namespace

Adds namespace to all resources

  1. namespace: my-namespace

Usage via plugin

Arguments

types.ObjectMeta

FieldSpecs []config.FieldSpec

Example

  1. apiVersion: builtin
  2. kind: NamespaceTransformer
  3. metadata:
  4. name: not-important-to-example
  5. namespace: test
  6. fieldSpecs:
  7. - path: metadata/namespace
  8. create: true
  9. - path: subjects
  10. kind: RoleBinding
  11. group: rbac.authorization.k8s.io
  12. - path: subjects
  13. kind: ClusterRoleBinding
  14. group: rbac.authorization.k8s.io

PatchesJson6902

Usage via kustomization.yaml

field name: patchesJson6902

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

  1. [
  2. {"op": "add", "path": "/some/new/path", "value": "value"},
  3. {"op": "replace", "path": "/some/existing/path", "value": "new value"}
  4. ]

or in YAML format as

  1. - op: add
  2. path: /some/new/path
  3. value: value
  4. - op: replace
  5. path: /some/existing/path
  6. value: new value
  1. patchesJson6902:
  2. - target:
  3. version: v1
  4. kind: Deployment
  5. name: my-deployment
  6. path: add_init_container.yaml
  7. - target:
  8. version: v1
  9. kind: Service
  10. name: my-service
  11. path: add_service_annotation.yaml

The patch content can be an inline string as well:

  1. patchesJson6902:
  2. - target:
  3. version: v1
  4. kind: Deployment
  5. name: my-deployment
  6. patch: |-
  7. - op: add
  8. path: /some/new/path
  9. value: value
  10. - op: replace
  11. path: /some/existing/path
  12. value: "new value"

Usage via plugin

Arguments

Target types.PatchTarget

Path string

JsonOp string

Example

  1. apiVersion: builtin
  2. kind: PatchJson6902Transformer
  3. metadata:
  4. name: not-important-to-example
  5. target:
  6. group: apps
  7. version: v1
  8. kind: Deployment
  9. name: my-deploy
  10. path: jsonpatch.json

PatchesStrategicMerge

Usage via kustomization.yaml

field name: patchesStrategicMerge

Each entry in this list should be either a relative file path or an inline content resolving to a partial or complete resource definition.

The names in these (possibly partial) resource files must match names already loaded via the resources field. 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.

  1. patchesStrategicMerge:
  2. - service_port_8888.yaml
  3. - deployment_increase_replicas.yaml
  4. - deployment_increase_memory.yaml

The patch content can be a inline string as well.

  1. patchesStrategicMerge:
  2. - |-
  3. apiVersion: apps/v1
  4. kind: Deployment
  5. metadata:
  6. name: nginx
  7. spec:
  8. template:
  9. spec:
  10. containers:
  11. - name: nginx
  12. image: nignx:latest

Note that kustomize does not support more than one patch for the same object that contain a delete directive. To remove several fields / slice elements from an object create a single patch that performs all the needed deletions.

Usage via plugin

Arguments

Paths []types.PatchStrategicMerge

Patches string

Example

  1. apiVersion: builtin
  2. kind: PatchStrategicMergeTransformer
  3. metadata:
  4. name: not-important-to-example
  5. paths:
  6. - patch.yaml

PatchTransformer

Usage via kustomization.yaml

field name: patches

Each entry in this list should resolve to an Patch object, which includes a patch and a target selector. The patch can be either a strategic merge patch or a JSON patch. it can be either a patch file or an inline string. The target selects resources by group, version, kind, name, namespace, labelSelector and annotationSelector. A resource which matches all the specified fields is selected to apply the patch.

  1. patches:
  2. - path: patch.yaml
  3. target:
  4. group: apps
  5. version: v1
  6. kind: Deployment
  7. name: deploy.*
  8. labelSelector: "env=dev"
  9. annotationSelector: "zone=west"
  10. - patch: |-
  11. - op: replace
  12. path: /some/existing/path
  13. value: new value
  14. target:
  15. kind: MyKind
  16. labelSelector: "env=dev"

The name and namespace fields of the patch target selector are automatically anchored regular expressions. This means that the value myapp is equivalent to ^myapp$.

Usage via plugin

Arguments

Path string

Patch string

Target *types.Selector

Example

  1. apiVersion: builtin
  2. kind: PatchTransformer
  3. metadata:
  4. name: not-important-to-example
  5. patch: '[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value": "nginx:latest"}]'
  6. target:
  7. name: .*Deploy
  8. kind: Deployment

PrefixSuffixTransformer

Usage via kustomization.yaml

field names: namePrefix, nameSuffix

Prepends or postfixes the value to the names of all resources.

E.g. a deployment named wordpress could become alices-wordpress or wordpress-v2 or alices-wordpress-v2.

  1. namePrefix: alices-
  2. nameSuffix: -v2

The suffix is appended before the content hash if the resource type is ConfigMap or Secret.

Usage via plugin

Arguments

Prefix string

Suffix string

FieldSpecs []config.FieldSpec

Example

  1. apiVersion: builtin
  2. kind: PrefixSuffixTransformer
  3. metadata:
  4. name: not-important-to-example
  5. prefix: baked-
  6. suffix: -pie
  7. fieldSpecs:
  8. - path: metadata/name

ReplicaCountTransformer

Usage via kustomization.yaml

field name: replicas

Replicas modified the number of replicas for a resource.

E.g. Given this kubernetes Deployment fragment:

  1. kind: Deployment
  2. metadata:
  3. name: deployment-name
  4. spec:
  5. replicas: 3

one can change the number of replicas to 5 by adding the following to your kustomization:

  1. replicas:
  2. - name: deployment-name
  3. count: 5

This field accepts a list, so many resources can be modified at the same time.

As this declaration does not take in a kind: nor a group: it will match any group and kind that has a matching name and that is one of:

  • Deployment
  • ReplicationController
  • ReplicaSet
  • StatefulSet

For more complex use cases, revert to using a patch.

Usage via plugin

Arguments

Replica types.Replica

FieldSpecs []config.FieldSpec

Example

  1. apiVersion: builtin
  2. kind: ReplicaCountTransformer
  3. metadata:
  4. name: not-important-to-example
  5. replica:
  6. name: myapp
  7. count: 23
  8. fieldSpecs:
  9. - path: spec/replicas
  10. create: true
  11. kind: Deployment
  12. - path: spec/replicas
  13. create: true
  14. kind: ReplicationController

SecretGenerator

Usage via kustomization.yaml

field name: secretGenerator

Each entry in the argument list results in the creation of one Secret resource (it’s a generator of n secrets).

This works like the configMapGenerator field described above.

  1. secretGenerator:
  2. - name: app-tls
  3. files:
  4. - secret/tls.cert
  5. - secret/tls.key
  6. type: "kubernetes.io/tls"
  7. - name: app-tls-namespaced
  8. # you can define a namespace to generate
  9. # a secret in, defaults to: "default"
  10. namespace: apps
  11. files:
  12. - tls.crt=catsecret/tls.cert
  13. - tls.key=secret/tls.key
  14. type: "kubernetes.io/tls"
  15. - name: env_file_secret
  16. envs:
  17. - env.txt
  18. type: Opaque
  19. - name: secret-with-annotation
  20. files:
  21. - app-config.yaml
  22. type: Opaque
  23. options:
  24. annotations:
  25. app_config: "true"
  26. labels:
  27. app.kubernetes.io/name: "app2"

Usage via plugin

Arguments

types.ObjectMeta

types.SecretArgs

Example

  1. apiVersion: builtin
  2. kind: SecretGenerator
  3. metadata:
  4. name: my-secret
  5. namespace: whatever
  6. behavior: merge
  7. envs:
  8. - a.env
  9. - b.env
  10. files:
  11. - obscure=longsecret.txt
  12. literals:
  13. - FRUIT=apple
  14. - VEGETABLE=carrot

HelmChartInflationGenerator

Usage via kustomization.yaml

field name: helmChartInflationGenerator

Each entry in the argument list results in the pulling and rendering of a helm chart.

Each entry can have following fields:

  • chartName: The name of the chart that you want to use.
  • chartRepoUrl: [Optional] The URL of the repository which contains the chart. If this is provided, the plugin will try to fetch remote charts. Otherwise it will try to load local chart in chartHome.
  • chartVersion: [Optional] Version of the chart. Will use latest version if this is omitted.
  • chartHome: [Optional] Provide the path to the parent directory for local chart.
  • chartRelease: [Optional] The name of the repo where to find the chart.
  • values: [Optional] A path to the values file.
  • releaseName: [Optional] The release name that will be set in the chart.
  • releaseNamespace: [Optional] The namespace which will be used by --namespace flag in helm template command.
  • helmBin: [Optional] Path to helm binary. Default is helm.
  • helmHome: [Optional] Path to helm home directory.
  • extraArgs: [Optional] A list of additional argumetns that will be passed into helm template command.
  1. helmChartInflationGenerator:
  2. - chartName: minecraft
  3. chartRepoUrl: https://kubernetes-charts.storage.googleapis.com
  4. chartVersion: v1.2.0
  5. releaseName: test
  6. releaseNamespace: testNamespace

Usage via plugin

Arguments

ChartName string

ChartVersion string

ChartRepoURL string

ChartHome string

ChartRepoName string

HelmBin string

HelmHome string

Values string

ReleaseName string

ReleaseNamespace string

ExtraArgs []string

Example

  1. apiVersion: builtin
  2. kind: HelmChartInflationGenerator
  3. metadata:
  4. name: myMap
  5. chartName: minecraft
  6. chartRepoUrl: https://kubernetes-charts.storage.googleapis.com
  7. chartVersion: v1.2.0
  8. helmBin: /usr/bin/helm
  9. helmHome: /tmp/helmHome
  10. releaseName: test
  11. releaseNamespace: testNamespace
  12. values: values.yaml
  13. extraArgs:
  14. - --include-crds