kustomize is a manifest customization tool built into kubectl. It allows performing template-free, structured customizations of Kubernetes manifests through generators and transformers defined in kustomization files.
The example below demonstrates how to use kustomize to automatically add custom labels to all objects that compose a Bridge at deployment time, without touching the original List-manifest.
Consider the project structure below, where:
my-bridge-manifest.jsonis a Bridge List-manifest generated by
kustomization.yamlis a kustomization file describing the desired transformations to perform on Kubernetes objects which compose the Bridge.
project ├── kustomization.yaml └── my-bridge-manifest.json
In the kustomization file, we define:
- The labels to be injected under a
commonLabelsfield (in this case, an ID and a revision).
- The resources these transformations apply to under a
resourcesfield (the generated Bridge List-manifest).
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization commonLabels: bridges.triggermesh.io/id: my-bridge bridges.triggermesh.io/revision: "1" resources: - my-bridge-manifest.json
The resulting Kubernetes manifests can either be generated to standard output using the command:
$ kubectl kustomize project/ apiVersion: example/v1 kind: SomeKind metadata: labels: bridges.triggermesh.io/id: my-bridge bridges.triggermesh.io/revision: "1" name: some-name [...]
Or they can be deployed directly to the destination cluster using the command:
$ kubectl create -k project/ somekind.example/some-name created otherkind.example/other-name created [...]
To undo the deployment of a Bridge, simply delete its Kubernetes objects:
$ kubectl delete -k project/ somekind.example/some-name deleted otherkind.example/other-name deleted [...]
Please note that using kustomize for deploying complex applications, including TriggerMesh Bridges, has the same limitations as the ones described in the kubectl page.