- Command Line Options -
-Usage of command line options
-diff --git a/docs/api-reference/glossary/index.html b/docs/api-reference/glossary/index.html index 861eeedb1..463591d1c 100644 --- a/docs/api-reference/glossary/index.html +++ b/docs/api-reference/glossary/index.html @@ -702,37 +702,6 @@ - - @@ -769,331 +738,6 @@
An application is a group of k8s resources related by -some common purpose, e.g. a load balancer in front of a -webserver backed by a database. -Resource labelling, naming and metadata schemes have -historically served to group resources together for -collective operations like list and remove.
-This proposal describes a new k8s resource called -application to more formally describe this idea and -provide support for application-level operations and -dashboards.
-kustomize configures k8s resources, and the proposed -application resource is just another resource.
-The verb apply in the context of k8s refers to a -kubectl command and an in-progress API -endpoint for mutating a -cluster.
-One applies a statement of what one wants to a -cluster in the form of a complete resource list.
-The cluster merges this with the previously applied -state and the actual state to arrive at a new desired -state, which the cluster’s reconciliation loop attempts -to create. This is the foundation of level-based state -management in k8s.
-A base is a kustomization referred to -by some other kustomization.
-Any kustomization, including an overlay, can be a base to -another kustomization.
-A base has no knowledge of the overlays that refer to it.
-For simple gitops management, a base configuration -could be the sole content of a git repository -dedicated to that purpose. Same with overlays. -Changes in a repo could generate a build, test and -deploy cycle.
-A bespoke configuration is a kustomization and some -resources created and maintained internally by some -organization for their own purposes.
-The workflow associated with a bespoke config is -simpler than the workflow associated with an -off-the-shelf config, because there’s no notion of -periodically capturing someone else’s upgrades to the -off-the-shelf config.
-One can extend the k8s API by making a -Custom Resource Definition (CRD spec).
-This defines a custom resource (CD), an entirely -new resource that can be used alongside native -resources like ConfigMaps, Deployments, etc.
-Kustomize can customize a CD, but to do so -kustomize must also be given the corresponding CRD -so that it can interpret the structure correctly.
-Kustomize aspires to support Declarative Application Management, -a set of best practices around managing k8s clusters.
-In brief, kustomize should
-A generator makes resources that can be used as is, -or fed into a transformer.
-Devops or CICD workflows that use a git repository as a -single source of truth and take action (e.g., build, -test or deploy) when that truth changes.
-The term kustomization refers to a
-kustomization.yaml file, or more generally to a
-directory (the root) containing the
-kustomization.yaml file and all the relative file
-paths that it immediately references (all the local
-data that doesn’t require a URL specification).
I.e. if someone gives you a kustomization for use -with kustomize, it could be in the form of
-kustomization.yaml,A kustomization file contains fields -falling into four categories:
-resources - what existing resources are to be customized. -Example fields: resources, crds.
-generators - what new resources should be created. -Example fields: configMapGenerator (legacy), -secretGenerator (legacy), generators (v2.1).
-transformers - what to do to the aforementioned resources. -Example fields: namePrefix, nameSuffix, images, -commonLabels, patchesJson6902, etc. and the more -general transformers (v2.1) field.
-meta - fields which may influence all or some of -the above. Example fields: vars, namespace, -apiVersion, kind, etc.
-The directory that immediately contains a
-kustomization.yaml file.
When a kustomization file is processed, it may or may -not be able to access files outside its root.
-Data files like resource YAML files, or text files -containing name=value pairs intended for a ConfigMap -or Secret, or files representing a patch to be used in -a patch transformation, must live within or below the -root, and as such are specified via relative -paths exclusively.
-A special flag (in v2.1), --load_restrictions none,
-is provided to relax this security feature, to, say,
-allow a patch file to be shared by more than one
-kustomization.
Other kustomizations (other directories containing a
-kustomization.yaml file) may be referred to by URL, by
-absolute path, or by relative path.
If kustomization A depends on kustomization B, then
-A may contain B, but in this case it might be -simplest to have A directly depend on B’s -resources and eliminate B’s kustomization.yaml file -(i.e. absorb B into A).
-Conventionally, B is in a directory that’s sibling -to A, or B is off in a completely independent -git repository, referencable from any kustomization.
-A common layout is
---├── base -│ ├── deployment.yaml -│ ├── kustomization.yaml -│ └── service.yaml -└── overlays - ├── dev - │ ├── kustomization.yaml - │ └── patch.yaml - ├── prod - │ ├── kustomization.yaml - │ └── patch.yaml - └── staging - ├── kustomization.yaml - └── patch.yaml -
The three roots dev, prod and staging
-(presumably) all refer to the base root. One would
-have to inspect the kustomization.yaml files to be
-sure.
Kubernetes is an open-source -system for automating deployment, scaling, and -management of containerized applications.
-It’s often abbreviated as k8s.
-An object, expressed in a YAML or JSON file, with the -fields required by kubernetes. Basically just a -kind field to identify the type, a metadata/name -field to identify the particular instance, and an -apiVersion field to identify the version (if there’s -more than one version).
-kustomize is a command line tool supporting -template-free, structured customization of declarative -configuration targeted to k8s-style objects.
-Targeted to k8s means that kustomize has some -understanding of API resources, k8s concepts like -names, labels, namespaces, etc. and the semantics of -resource patching.
-kustomize is an implementation of DAM.
-An off-the-shelf configuration is a kustomization and -resources intentionally published somewhere for others -to use.
-E.g. one might create a github repository like this:
---github.com/username/someapp/ - kustomization.yaml - deployment.yaml - configmap.yaml - README.md -
Someone could then fork this repo (on github) and -clone their fork to their local disk for -customization.
-This clone could act as a base for the user’s -own overlays to do further customization.
-An overlay is a kustomization that depends on -another kustomization.
-The kustomizations an overlay refers to (via file -path, URI or other method) are called bases.
-An overlay is unusable without its bases.
-An overlay may act as a base to another overlay.
-Overlays make the most sense when there is more than -one, because they create different variants of a -common base - e.g. development, QA, staging and -production environment variants.
-These variants use the same overall resources, and vary -in relatively simple ways, e.g. the number of replicas -in a deployment, the CPU to a particular pod, the data -source used in a ConfigMap, etc.
-One configures a cluster like this:
---kustomize build someapp/overlays/staging |\ - kubectl apply -f - - - kustomize build someapp/overlays/production |\ - kubectl apply -f - -
Usage of the base is implicit - the overlay’s -kustomization points to the base.
-See also root.
-The word package has no meaning in kustomize, as -kustomize is not to be confused with a package -management tool in the tradition of, say, apt or -rpm.
-General instructions to modify a resource.
-There are two alternative techniques with similar -power but different notation - the -strategic merge patch -and the JSON patch.
-A patchStrategicMerge is strategic-merge-style patch (SMP).
-An SMP looks like an incomplete YAML specification of
-a k8s resource. The SMP includes TypeMeta
-fields to establish the group/version/kind/name of the
-resource to patch, then just enough remaining fields
-to step into a nested structure to specify a new field
-value, e.g. an image tag.
By default, an SMP replaces values. This is -usually desired when the target value is a simple -string, but may not be desired when the target -value is a list.
-To change this -default behavior, add a directive. Recognized -directives in YAML patches are replace (the default) -and delete (see these notes).
-Note that for custom resources, SMPs are treated as -json merge patches.
-Fun fact - any resource file can be used as -an SMP, overwriting matching fields in another -resource with the same group/version/kind/name, -but leaving all other fields as they were.
-TODO(monopole): add ptr to example.
-A patchJson6902 refers to a kubernetes resource and -a JSONPatch specifying how to change the resource.
-A patchJson6902 can do almost everything a -patchStrategicMerge can do, but with a briefer -syntax. See this example.
-A chunk of code used by kustomize, but not necessarily -compiled into kustomize, to generate and/or transform a -kubernetes resource as part of a kustomization.
-Details here.
-A resource in the context of a REST-ful API is the -target object of an HTTP operation like GET, PUT or -POST. k8s offers a REST-ful API surface to interact -with clients.
-A resource, in the context of a kustomization, is a -root relative path to a YAML or JSON file -describing a k8s API object, like a Deployment or a -ConfigMap, or it’s a path to a kustomization, or a URL -that resolves to a kustomization.
-More generally, a resource can be any correct YAML file -that defines an object -with a kind and a metadata/name field.
-See kustomization root.
-A sub-whatever is not a thing. There are only -bases and overlays.
-The target is the argument to kustomize build, e.g.:
--kustomize build $target -
$target must be a path or a url to a kustomization.
The target contains, or refers to, all the information -needed to create customized resources to send to the -apply operation.
-A target can be a base or an overlay.
-A transformer can modify a resource, or merely
-visit it and collect information about it in the
-course of a kustomize build.
A variant is the outcome, in a cluster, of applying -an overlay to a base.
-E.g., a staging and production overlay both modify -some common base to create distinct variants.
-The staging variant is the set of resources exposed -to quality assurance testing, or to some external users -who’d like to see what the next version of production -will look like.
-The production variant is the set of resources -exposed to production traffic, and thus may employ -deployments with a large number of replicas and higher -cpu and memory requests.
Moved to https://github.com/kubernetes-sigs/cli-experimental
+The bases field was deprecated in v2.1.0
Move entries into the resources -field. This allows bases - which are still a -central concept - to be -ordered relative to other input resources.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Add annotations to all resources. If the annotation key is already present on the resource, -the value will be overridden.
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-commonAnnotations:
- oncallPager: 800-555-1212
-# kustomization.yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-commonAnnotations:
- oncallPager: 800-555-1212
-
-resources:
-- deploy.yaml
-# deploy.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: example
-spec:
- ...
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: example
- annotations:
- oncallPager: 800-555-1212
-spec:
- ...
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+Add labels and selectors to all resources. If the label key already is present on the resource, -the value will be overridden.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
- -Selectors for resources such as Deployments and Services shouldn’t be changed once the -resource has been applied to a cluster.
-Changing commonLabels to live resources could result in failures.
- -apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-commonLabels:
- someName: someValue
- owner: alice
- app: bingo
-# kustomization.yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-commonLabels:
- someName: someValue
- owner: alice
- app: bingo
-
-resources:
-- deploy.yaml
-- service.yaml
-# deploy.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: example
-# service.yaml
-apiVersion: v1
-kind: Service
-metadata:
- name: example
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- app: bingo
- owner: alice
- someName: someValue
- name: example
-spec:
- selector:
- app: bingo
- owner: alice
- someName: someValue
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- labels:
- app: bingo
- owner: alice
- someName: someValue
- name: example
-spec:
- selector:
- matchLabels:
- app: bingo
- owner: alice
- someName: someValue
- template:
- metadata:
- labels:
- app: bingo
- owner: alice
- someName: someValue
-Coming soon
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Each entry in this list results in the creation of -one ConfigMap resource (it’s a generator of n maps).
-The example below creates four ConfigMaps:
-literalsoptions for that single ConfigMapEach 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.
apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-# These labels are added to all configmaps and secrets.
-generatorOptions:
- labels:
- fruit: apple
-
-configMapGenerator:
-- name: my-java-server-props
- behavior: merge
- files:
- - application.properties
- - more.properties
-- name: my-java-server-env-file-vars
- envs:
- - my-server-env.properties
- - more-server-props.env
-- name: my-java-server-env-vars
- literals:
- - JAVA_HOME=/opt/java/jdk
- - JAVA_TOOL_OPTIONS=-agentlib:hprof
- options:
- disableNameSuffixHash: true
- labels:
- pet: dog
-- name: dashboards
- files:
- - mydashboard.json
- options:
- annotations:
- dashboard: "1"
- labels:
- 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.
apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-configMapGenerator:
-- name: app-whatever
- files:
- - myFileName.ini=whatever.ini
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+whatever.ini.
- 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:
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-crds:
-- crds/typeA.yaml
-- crds/typeB.yaml
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+Additionally, generatorOptions can be set on a per resource level within each -generator. For details on per-resource generatorOptions usage see -field-name-configMapGenerator and See field-name-secretGenerator.
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-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
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+Images modify the name, tags and/or digest for images without creating patches. E.g. Given this -kubernetes Deployment fragment:
-kind: Deployment
-...
-spec:
- template:
- spec:
- 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 to my-registry/my-postgres:v1,1.7.9 to 1.8.0,my-demo-app to my-app,3.7 to a digest valueall with the following kustomization:
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: 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
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+Moved to https://github.com/kubernetes-sigs/cli-experimental
apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-namePrefix: alices-
-A deployment named wordpress would become alices-wordpress.
Moved to https://github.com/kubernetes-sigs/cli-experimental
apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-namespace: my-namespace
-Will override the existing namespace if it is set on a resource, or add it -if it is not set on a resource.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-nameSuffix: -v2
-A deployment named wordpress would become wordpress-v2.
Note: The suffix is appended before the content hash if the resource type is ConfigMap or Secret.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Patches (also call overlays) add or override fields on resources. They are provided using the
-patches Kustomization field.
The patches field contains a list of patches to be applied in the order they are specified.
Each patch may:
-The patch target selects resources by group, version, kind, name, namespace, labelSelector and -annotationSelector. Any resource which matches all the specified fields has the patch applied -to it (regular expressions).
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-patches:
-- path: patch.yaml
- target:
- group: apps
- version: v1
- kind: Deployment
- name: deploy.*
- labelSelector: "env=dev"
- annotationSelector: "zone=west"
-- patch: |-
- - op: replace
- path: /some/existing/path
- value: new value
- target:
- kind: MyKind
- 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$.
Consider the following deployment.yaml common for both the examples:
apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: the-deployment
-spec:
- replicas: 5
- template:
- containers:
- - name: the-container
- image: registry/conatiner:latest
-To Make the container image point to a specific version and not to the latest container in the -registry.
-# kustomization.yaml
-resources:
-- deployment.yaml
-
-patches:
-- path: patch.yaml
-# patch.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: the-deployment
-spec:
- template:
- containers:
- - name: the-container
- image: registry/conatiner:1.0.0
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: the-deployment
-spec:
- replicas: 5
- template:
- containers:
- - image: registry/conatiner:1.0.0
- name: the-container
-To Make the container image point to a specific version and not to the latest container in the -registry.
-# kustomization.yaml
-resources:
-- deployment.yaml
-
-patches:
-- target:
- kind: Deployment
- name: the-deployment
- path: patch.json
-# patch.json
-[
- {"op": "replace", "path": "/spec/template/containers/0/image", "value": "registry/conatiner:1.0.0"}
-]
-
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: the-deployment
-spec:
- replicas: 5
- template:
- containers:
- - image: registry/container:1.0.0
- name: the-container
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+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
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-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
-The patch content can be an inline string as well:
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-patchesJson6902:
-- target:
- version: v1
- kind: Deployment
- name: my-deployment
- patch: |-
- - op: add
- path: /some/new/path
- value: value
- - op: replace
- path: /some/existing/path
- value: "new value"
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+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.
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-patchesStrategicMerge:
-- service_port_8888.yaml
-- deployment_increase_replicas.yaml
-- deployment_increase_memory.yaml
-The patch content can be a inline string as well.
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-patchesStrategicMerge:
-- |-
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: nginx
- spec:
- template:
- spec:
- containers:
- - name: nginx
- 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.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Given this kubernetes Deployment fragment:
-# deployment.yaml
-kind: Deployment
-metadata:
- name: deployment-name
-spec:
- replicas: 3
-one can change the number of replicas to 5 -by adding the following to your kustomization:
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-replicas:
-- name: deployment-name
- 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:
DeploymentReplicationControllerReplicaSetStatefulSetFor more complex use cases, revert to using a patch.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Each entry in this list must be a path to a file, or a path (or URL) referring to another -kustomization directory, e.g.
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-resources:
-- myNamespace.yaml
-- sub-dir/some-deployment.yaml
-- ../../commonbase
-- github.com/kubernetes-sigs/kustomize/examples/multibases?ref=v1.0.6
-- deployment.yaml
-- github.com/kubernets-sigs/kustomize/examples/helloWorld?ref=test-branch
-Resources will be read and processed in depth-first order.
-Files should contain k8s resources in YAML form. A file may contain multiple resources separated by
-the document marker ---. File paths should be specified relative to the directory holding the
-kustomization file containing the resources field.
Directory specification can be relative, absolute, or part of a URL. URL specifications should
-follow the hashicorp URL format. The directory must contain a kustomization.yaml file.
Moved to https://github.com/kubernetes-sigs/cli-experimental
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.
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-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
- # a 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
-- name: secret-with-annotation
- files:
- - app-config.yaml
- type: Opaque
- options:
- annotations:
- app_config: "true"
- labels:
- app.kubernetes.io/name: "app2"
-Moved to https://github.com/kubernetes-sigs/cli-experimental
+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:
-# consider it is a deployment
-containers:
- - image: myimage
- command: ["start", "--host", "$(MY_SERVICE_NAME)"]
- env:
- - name: SECRET_TOKEN
- value: $(SOME_SECRET_NAME)
- livenessProbe:
- httpGet:
- path: /healthz
- # it enables the parser to lookup this field
- port: $(APP_PORT)
-To do so, add an entry to vars: as follows:
apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-configMapGenerator:
-- name: my-config
- literals:
- - MY_PORT=8080
-
-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
-# it exports a value as `APP_PORT`
-# from `ConfigMap` named `my-config`
-# in `data.MY_PORT`
-- name: APP_PORT
- objref:
- kind: ConfigMap
- name: my-config
- apiVersion: v1
- fieldref:
- fieldpath: data.MY_PORT
-
-configurations:
- - lookup.yaml
-Define the consuming resource(s) and the field(s) inside need to lookup.
-# lookup.yaml
-varReference:
- # the path of field that you want the parser to lookups and replace.
- - path: spec/template/spec/containers/livenessProbe/httpGet/port
- kind: Deployment
-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 /api/konfig/builtinpluginconsts/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.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
File issues as desired, but if you’ve found a problem
-with how kustomize build works, please report
kustomize version,kustomization.yaml
-and any files it refers to),go installedkustomize has a simple test harness in the krusty -package for specifying a kustomization’s input and the -expected output.
-Copy one of those tests, e.g. this reusable custom -transformer test, to a new test file in the -krusty package.
-Insert the inputs you want to use, and run it as -you’d run the reusable custom transformer test:
-(cd api; go test -run TestReusableCustomTransformers ./krusty)
-The output will demonstrate the bug or missing feature.
-Record this output in the test file in a call to
-AssertActualEqualsExpected, per all the other tests
-in the krusty package. This makes the test pass,
-albeit with output demonstrating behavior you
-presumably want to change.
Send the new test in a PR, along with commentary (in -the test) on what you’d prefer to see.
-The person who fixes the bug then has a clear bug -reproduction and a test to modify when the bug is -fixed.
-Any bug fix first requires a test demonstrating the bug -(so we have permanent regression coverage), so if the -bug reporter does this, it saves time and avoids -misunderstandings.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Kustomize is a sub project of the Kubernetes CLI special interest group and follows the Kubernetes -project contributor roles.
-If you are interested in contributing towards Kustomize or getting more involved with the community:
-Moved to https://github.com/kubernetes-sigs/cli-experimental
Kustomize uses Docsy for the site, and was -forked from the docsy-example
-git clone git@github.com:kubernetes-sigs/kustomize && cd kustomize/The doc input files are in the site directory. The site can be hosted locally using
-hugo serve.
cd site/
-hugo serve
-...
-Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
-Web Server is available at http://localhost:1313/kustomize/ (bind address 127.0.0.1)
-Hugo compiles the files under site Hugo into html which it puts in the docs folder:
cd site/
-hugo
- | EN
--------------------+-----
- Pages | 99
- Paginator pages | 0
- Non-page files | 0
- Static files | 47
- Processed images | 0
- Aliases | 2
- Sitemaps | 1
- Cleaned | 0
-Add the site/ and docs/ folders to a commit, then create a PR.
It is possible to have the kustomize docs published to your forks github pages.
-Changes must be pushed to the fork’s master branch to be served as the fork’s GitHub Page.
- -site/contenthugo from the site/ directorysite and docs directories to the master branchMoved to https://github.com/kubernetes-sigs/cli-experimental
Following is the process for proposing a new Kustomize feature:
-api and kustomize modulesMoved to https://github.com/kubernetes-sigs/cli-experimental
To build kustomize using the locally modified modules, replace statements must be added to
-the kustomize/go.mod.
e.g. if code in api was modified, a replace statement would need to be added for the
-kustomize/api module.
Call stack when running kustomize build, with links to code.
Moved to https://github.com/kubernetes-sigs/cli-experimental
kustomize/go.mod.
- First install the tools to build and run tests
-Add go to your PATH
go get github.com/instrumenta/kubeval
-Add kubeval to your PATH
brew install coreutils wget gnu-sed tree
-Add the new tools to your PATH
-Verify your install by running make:
make
-Be default, this runs all tests needed to qualify a pull request.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
This is the PowerShell script to run all go tests for Kustomize on a windows based platform which mimics /build/pre-commit.sh
-This script should output to the current console and return an exit code if all tests are successful(0) or any failed(1).
-Assume:
-src directory
-go get -u github.com/golangci/golangci-lint/cmd/golangci-lintgo get github.com/monopole/mdripYou should now be able to issue these commands and see comparable responses
-C:\...> golangci-lint --help
-Smart, fast linters runner. Run it in cloud for every GitHub pull request on https://golangci.com
-...
-
-C:\...> mdrip --help
-Usage: C:\_go\bin\mdrip.exe {fileName}...
-...
-Example: C:\_go\srctravis directory
-Example: C:\_go\src\sigs.k8s.io\kustomize\scripts.\Invoke-PreCommit.ps1This should run all pre-commit tests thus defined in the script.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
The maintainers established this list to -place bounds on the kustomize feature -set. The bounds can be changed with -a consensus on the risks.
-For a bigger picture about why kustomize -does some things and not others, see the -glossary entry for DAM.
-kustomize supports configurations that can be reasoned about as
-compositions or mixins - concepts that are widely accepted as
-a best practice in various programming languages.
To this end, kustomize offers various addition directives.
-One may add labels, annotations, patches, resources, bases, etc.
-Corresponding removal directives are not offered.
Removal semantics would introduce many possibilities for -inconsistency, and the need to add code to detect, report and -reject it. It would also allow, and possibly encourage, -unnecessarily complex configuration layouts.
-When faced with a situation where removal is desirable, it’s -always possible to remove things from a base like labels and -annotations, and/or split multi-resource manifests into individual -resource files - then add things back as desired via the -kustomization.
-If the underlying base is outside of one’s control, an OTS -workflow is the recommended best practice. Fork the base, remove -what you don’t want and commit it to your private fork, then use -kustomize on your fork. As often as desired, use git rebase to -capture improvements from the upstream base.
-Structured edits are changes controlled by -knowledge of the k8s API, and YAML or JSON syntax.
-Most edits performed by kustomize can be expressed as
-JSON patches or SMP patches.
-Those can be verbose, so common patches,
-like adding labels or annotatations, get dedicated
-transformer plugins - LabelTransformer,
-AnnotationsTransformer, etc.
-These accept relatively simple YAML configuration
-allowing easy targeting of any number of resources.
Another class of edits take data from one specific -object’s field and use it in another (e.g. a service -object’s name found and copied into a container’s -command line). These reflection-style edits -are called replacements.
-The above edits create valid output given valid input, -and can provide syntactically and semantically -informed error messages if inputs are invalid.
-Unstructured edits, edits that don’t limit -themselves to a syntax or object structure, -come in many forms. A common one in the -configuration domain is the template or -parameterization approach.
-In this technique, the source
-material is sprinkled with strings of the
-form ${VAR}. A scanner replaces them
-with a value taken from a map using VAR
-as the map key. It’s trivial to implement.
kustomize eschews parameterization, because
-$VARs
-and can no longed be applied as is
-to the cluster (it must be processed).Kustomizations are meant to be sharable and stackable. -Imagine tracing down a problem rooted in a -clever set of stacked regexp replacements -performed by various overlays on some remote base. -We’ve used such systems, and never want to again.
-Other tools (sed, jinja, erb, envsubst, kafka, helm, ksonnet, -etc.) provide varying degrees of unstructured editting -and/or embedded languages, and can be used instead -of, or in a pipe with, kustomize. If you want to -go all-in on configuration as a language, consider cue.
-kustomize is going to stick to YAML in / YAML out.
-kustomize supports the best practice of storing one’s
-entire configuration in a version control system.
Changing kustomize build configuration output as a result
-of additional arguments or flags to build, or by
-consulting shell environment variable values in build
-code, would frustrate that goal.
kustomize insteads offers kustomization file edit
-commands. Like any shell command, they can accept
-environment variable arguments.
For example, to set the tag used on an image to match an -environment variable, run
-kustomize edit set image nginx:$MY_NGINX_VERSION
-as part of some encapsulating work flow executed before
-kustomize build.
kustomize supports the best practice of storing one’s
-entire configuration in a version control system.
Globbing the local file system for files not explicitly
-declared in the kustomization file at kustomize build time
-would violate that goal.
Allowing globbing in a kustomization file would also introduce -the same problems as allowing globbing in java import -declarations or BUILD/Makefile dependency rules.
-kustomize will instead provide kustomization file editting
-commands that accept globbed arguments, expand them at edit
-time relative to the local file system, and store the resulting
-explicit names into the kustomization file.
Moved to https://github.com/kubernetes-sigs/cli-experimental
TLDR: This is blocked on either moving kubectl into its own repo, or changing its dependencies. ETA k8s ~1.20.
-The adoption of go modules in the kubernetes/kubernetes repo broke the update process for kustomize. -This is due to the kustomize libraries depending on the kubernetes apimachinery libraries, which are -published out of the kubernetes staging directory.
-2 pieces of work are underway which will allow kustomize to be updated in kubectl:
-Once either of these issues is resolved we will then update kubectl with the latest kustomize version.
-v2.0 added a security check that prevents -kustomizations from reading files outside their own -directory root.
-This was meant to help protect the person inclined to -download kustomization directories from the web and use -them without inspection to control their production -cluster -(see #693, -#700, -#995 and -#998)
-Resources (including configmap and secret generators)
-can still be shared via the recommended best practice
-of placing them in a directory with their own
-kustomization file, and referring to this directory as a
-base from any kustomization that
-wants to use it. This encourages modularity and
-relocatability.
To disable this, use v3, and the load_restrictor flag:
kustomize build --load_restrictor none $target
-Example: #1319, #1322, #1347 and etc.
-The fields transformed by kustomize is configured explicitly in defaultconfig. The configuration itself can be customized by including configurations in kustomization.yaml, e.g.
apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-configurations:
-- kustomizeconfig.yaml
-The configuration directive allows customization of the following transformers:
-commonAnnotations: []
-commonLabels: []
-nameprefix: []
-namespace: []
-varreference: []
-namereference: []
-images: []
-replicas: []
-To persist the changes to default configuration, submit a PR like #1338, #1348 and etc.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Running kustomize means one is running a
-particular version of a program (a CLI), using a
-particular version of underlying packages (a Go
-API), and reading a particular version of a
-kustomization file.
--If you’re having trouble with
-go get, please -read Go API Versioning -and be patient.
The command kustomize version prints a three
-field version tag (e.g. v3.0.0) that aspires to
-semantic versioning.
This notion of semver applies only to the CLI; -the command names, their arguments and their flags.
-The major version changes when some backward -incompatibility appears in how the commands -behave.
-See the installation docs.
-The public methods in the public packages
-of module sigs.k8s.io/kustomize/api constitute
-the kustomize Go API.
In kustomize/v3 (and preceding major versions), the
-kustomize program and the API live the same Go
-module at sigs.k8s.io/kustomize, at import path
-sigs.k8s.io/kustomize/v3.
This has been fine for the CLI, but it presents a -problem for the Go API.
-The process around Go modules, in particular the -notion of minimal version selection, demands -that the module respect semver.
-Almost all the code in module
-sigs.k8s.io/kustomize/v3 is exposed (not in a
-directory named internal). Even a minor
-refactor changing a method name or argument type
-in some deeply buried (but still public) method is
-a backward incompatible change. As a result, Go
-API semver hasn’t been followed. This was a mistake.
Some options are
-continue to ignore Go API semver and stick to -CLI semver (eliminating the usefullness of -minimal version selection),
-obey semver, and increment the module’s major -version number with every release (drastically -reducing the usefullness of minimal version -selection - since virtually all releases will -be major),
-slow down change in the huge API in favor of -stability, yet somehow continue to deliver -features,
-drastically reduce the API surface, stabilize on
-semver there, and refactor as needed inside
-internal.
The last option seems the most appealing.
-The first stable API version will launch -as the Go module
-sigs.k8s.io/kustomize/api
-The kustomize program itself (main.go
-and CLI specific code) will have moved out of
-sigs.k8s.io/kustomize and into the new module
-sigs.k8s.io/kustomize/kustomize. This is a
-submodule in the same repo, and it will retain its
-current notion of semver (e.g. a backward
-incompatible change in command behavior will
-trigger a major version bump). This module will
-not export packages; it’s just home to a main
-package.
The sigs.k8s.io/kustomize/api module will
-obey semver with a sustainable public
-surface, informed by current usage. Clients
-should import packages from this module, i.e.
-from import paths prefixed by
-sigs.k8s.io/kustomize/api/ at first,
-and later by sigs.k8s.io/kustomize/api/v2/.
-The kustomize binary
-itself is an API client requiring this module.
The clients and API will evolve independently.
-The kustomization file is a struct that is part of
-the kustomize Go API (the sigs.k8s.io/kustomize
-module), but it also evolves as a k8s API object -
-it has an apiVersion field containing its
-own version number.
apiVersion.edit fix CommandThis kustomize command reads a Kustomization
-file, converts deprecated fields to new
-fields, and writes it out again in the latest
-format.
This is a type version upgrade mechanism that -works within major API revisions. There is no -downgrade capability, as there’s no use case for -it (see discussion below).
-With the 2.0.0 release, there were three field -removals:
-imageTag was deprecated when images was
-introduced, because the latter offers more
-general features for image data manipulation.
-imageTag was removed in v2.0.0.patches was deprecated and replaced by
-patchesStrategicMerge when patchesJson6902
-was introduced, to make a clearer
-distinction between patch specification formats.
-patches was removed in v2.0.0.secretGenerator/commands was removed
-due to security concerns in v2.0.0
-with no deprecation period.The edit fix command in a v2.0.x binary
-will no longer recognize these fields.
The k8s API has specific conventions and a -process for making changes.
-The presence of an apiVersion field in a k8s
-native type signals:
The k8s API promises a lossless conversion -between versions over a specific range. This -means that a recent client can write an object -bearing the newest possible value for its version, -the server will accept it and store it in -“versionless” JSON form in storage, and can -convert it to a range of older versions should -an older client request data.
-For native k8s types, this all requires writing Go -code in the kubernetes core repo, to provide -defaulting and conversions.
-For CRDs, there’s a proposal on how to manage -versioning (e.g. a remote service can offer type -defaulting and conversions).
-kustomize edit fix command only moves
-forward within a major API
-version.At the time of writing, the YAML in a -kustomization file does not represent a k8s API -object, and the kustomize command and associated -library is neither a server of, nor a client to, -the k8s API.
-In addition to the field change policy described -above, kustomization files conform to -the following rules.
-Field names with dedicated meaning in k8s
-(metadata, spec, status, etc.) aren’t used.
-This is enforced via code review.
kind and apiVersionIn v3 or below, the two special k8s
-resource fields kind and apiVersion may
-be omitted from the kustomization file.
If either field is present, they both must be.
-If present, the value of kind must be:
--kind: Kustomization -
If missing, the value of apiVersion defaults to
-+apiVersion: kustomize.config.k8s.io/v1beta1 -
Moved to https://github.com/kubernetes-sigs/cli-experimental
-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.
-kustomization.yamlcommonAnnotationsAdds annotions (non-identifying metadata) to add -all resources. Like labels, these are key value -pairs.
-commonAnnotations:
- oncallPager: 800-555-1212
---Annotations map[string]string
-FieldSpecs []config.FieldSpec
-
--apiVersion: builtin -kind: AnnotationsTransformer -metadata: - name: not-important-to-example -annotations: - app: myApp - greeting/morning: a string with blanks -fieldSpecs: -- path: metadata/annotations - create: true -
kustomization.yamlconfigMapGeneratorEach 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.
# These labels are added to all configmaps and secrets.
-generatorOptions:
- labels:
- fruit: apple
-
-configMapGenerator:
-- name: my-java-server-props
- behavior: merge
- files:
- - application.properties
- - more.properties
-- name: my-java-server-env-vars
- literals:
- - JAVA_HOME=/opt/java/jdk
- - JAVA_TOOL_OPTIONS=-agentlib:hprof
- options:
- disableNameSuffixHash: true
- labels:
- pet: dog
-- name: dashboards
- files:
- - mydashboard.json
- options:
- annotations:
- dashboard: "1"
- labels:
- 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.
configMapGenerator:
-- name: app-whatever
- files:
- - myFileName.ini=whatever.ini
-- --
--apiVersion: builtin -kind: ConfigMapGenerator -metadata: - name: mymap -envs: -- devops.env -- uxteam.env -literals: -- FRUIT=apple -- VEGETABLE=carrot -
kustomization.yamlimagesImages 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 to my-registry/my-postgres:v1,1.7.9 to 1.8.0,my-demo-app to my-app,3.7 to a digest valueall 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
---ImageTag image.Image
-FieldSpecs []config.FieldSpec
-
--apiVersion: builtin -kind: ImageTagTransformer -metadata: - name: not-important-to-example -imageTag: - name: nginx - newTag: v2 -
kustomization.yamlcommonLabelsAdds labels to all resources and selectors
-commonLabels:
- someName: someValue
- owner: alice
- app: bingo
---Labels map[string]string
-FieldSpecs []config.FieldSpec
-
--apiVersion: builtin -kind: LabelTransformer -metadata: - name: not-important-to-example -labels: - app: myApp - env: production -fieldSpecs: -- path: metadata/labels - create: true -
kustomization.yamlnamespaceAdds namespace to all resources
-namespace: my-namespace
-- --FieldSpecs []config.FieldSpec
-
--apiVersion: builtin - kind: NamespaceTransformer - metadata: - name: not-important-to-example - namespace: test - fieldSpecs: - - path: metadata/namespace - create: true - - path: subjects - kind: RoleBinding - group: rbac.authorization.k8s.io - - path: subjects - kind: ClusterRoleBinding - group: rbac.authorization.k8s.io -
kustomization.yamlpatchesJson6902Each 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
-The patch content can be an inline string as well:
-patchesJson6902:
-- target:
- version: v1
- kind: Deployment
- name: my-deployment
- patch: |-
- - op: add
- path: /some/new/path
- value: value
- - op: replace
- path: /some/existing/path
- value: "new value"
---Target types.PatchTarget
-Path string
-JsonOp string
-
--apiVersion: builtin -kind: PatchJson6902Transformer -metadata: - name: not-important-to-example -target: - group: apps - version: v1 - kind: Deployment - name: my-deploy -path: jsonpatch.json -
kustomization.yamlpatchesStrategicMergeEach 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.
-patchesStrategicMerge:
-- service_port_8888.yaml
-- deployment_increase_replicas.yaml
-- deployment_increase_memory.yaml
-The patch content can be a inline string as well.
-patchesStrategicMerge:
-- |-
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: nginx
- spec:
- template:
- spec:
- containers:
- - name: nginx
- 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.
---Paths []types.PatchStrategicMerge
-Patches string
-
--apiVersion: builtin -kind: PatchStrategicMergeTransformer -metadata: - name: not-important-to-example -paths: -- patch.yaml -
kustomization.yamlpatchesEach 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.
-patches:
-- path: patch.yaml
- target:
- group: apps
- version: v1
- kind: Deployment
- name: deploy.*
- labelSelector: "env=dev"
- annotationSelector: "zone=west"
-- patch: |-
- - op: replace
- path: /some/existing/path
- value: new value
- target:
- kind: MyKind
- 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$.
--Path string
-Patch string
-Target *types.Selector
-
--apiVersion: builtin -kind: PatchTransformer -metadata: - name: not-important-to-example -patch: '[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value": "nginx:latest"}]' -target: - name: .*Deploy - kind: Deployment -
kustomization.yamlnamePrefix, nameSuffixPrepends 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.
namePrefix: alices-
-nameSuffix: -v2
-The suffix is appended before the content hash if -the resource type is ConfigMap or Secret.
---Prefix string
-Suffix string
-FieldSpecs []config.FieldSpec
-
--apiVersion: builtin -kind: PrefixSuffixTransformer -metadata: - name: not-important-to-example -prefix: baked- -suffix: -pie -fieldSpecs: - - path: metadata/name -
kustomization.yamlreplicasReplicas modified the number of replicas for a resource.
-E.g. Given this kubernetes Deployment fragment:
-kind: Deployment
-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.
-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:
DeploymentReplicationControllerReplicaSetStatefulSetFor more complex use cases, revert to using a patch.
---Replica types.Replica
-FieldSpecs []config.FieldSpec
-
--apiVersion: builtin -kind: ReplicaCountTransformer -metadata: - name: not-important-to-example -replica: - name: myapp - count: 23 -fieldSpecs: -- path: spec/replicas - create: true - kind: Deployment -- path: spec/replicas - create: true - kind: ReplicationController -
kustomization.yamlsecretGeneratorEach 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.
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
- # a 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
-- name: secret-with-annotation
- files:
- - app-config.yaml
- type: Opaque
- options:
- annotations:
- app_config: "true"
- labels:
- app.kubernetes.io/name: "app2"
-- - --
--apiVersion: builtin -kind: SecretGenerator -metadata: - name: my-secret - namespace: whatever -behavior: merge -envs: -- a.env -- b.env -files: -- obscure=longsecret.txt -literals: -- FRUIT=apple -- VEGETABLE=carrot -
kustomization.yamlhelmChartInflationGeneratorEach 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.helmChartInflationGenerator:
-- chartName: minecraft
- chartRepoUrl: https://kubernetes-charts.storage.googleapis.com
- chartVersion: v1.2.0
- releaseName: test
- releaseNamespace: testNamespace
---ChartName string
-ChartVersion string
-ChartRepoURL string
-ChartHome string
-ChartRepoName string
-HelmBin string
-HelmHome string
-Values string
-ReleaseName string
-ReleaseNamespace string
-
-+apiVersion: builtin -kind: HelmChartInflationGenerator -metadata: - name: myMap -chartName: minecraft -chartRepoUrl: https://kubernetes-charts.storage.googleapis.com -chartVersion: v1.2.0 -helmBin: /usr/bin/helm -helmHome: /tmp/helmHome -releaseName: test -releaseNamespace: testNamespace -values: values.yaml -
Moved to https://github.com/kubernetes-sigs/cli-experimental
-This is a (no reading allowed!) 60 second copy/paste guided -example. Full plugin docs here.
-This demo writes and uses a somewhat ridiculous
-exec plugin (written in bash) that generates a
-ConfigMap.
This is a guide to try it without damaging your -current setup.
-DEMO=$(mktemp -d)
-Make a kustomization directory to -hold all your config:
-MYAPP=$DEMO/myapp
-mkdir -p $MYAPP
-Make a deployment config:
-cat <<'EOF' >$MYAPP/deployment.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: the-deployment
-spec:
- replicas: 3
- template:
- spec:
- containers:
- - name: the-container
- image: monopole/hello:1
- command: ["/hello",
- "--port=8080",
- "--date=$(THE_DATE)",
- "--enableRiskyFeature=$(ENABLE_RISKY)"]
- ports:
- - containerPort: 8080
- env:
- - name: THE_DATE
- valueFrom:
- configMapKeyRef:
- name: the-map
- key: today
- - name: ALT_GREETING
- valueFrom:
- configMapKeyRef:
- name: the-map
- key: altGreeting
- - name: ENABLE_RISKY
- valueFrom:
- configMapKeyRef:
- name: the-map
- key: enableRisky
-EOF
-Make a service config:
-cat <<EOF >$MYAPP/service.yaml
-kind: Service
-apiVersion: v1
-metadata:
- name: the-service
-spec:
- type: LoadBalancer
- ports:
- - protocol: TCP
- port: 8666
- targetPort: 8080
-EOF
-Now make a config file for the plugin -you’re about to write.
-This config file is just another k8s resource
-object. The values of its apiVersion and kind
-fields are used to find the plugin code on your
-filesystem (more on this later).
cat <<'EOF' >$MYAPP/cmGenerator.yaml
-apiVersion: myDevOpsTeam
-kind: SillyConfigMapGenerator
-metadata:
- name: whatever
-argsOneLiner: Bienvenue true
-EOF
-Finally, make a kustomization file -referencing all of the above:
-cat <<EOF >$MYAPP/kustomization.yaml
-commonLabels:
- app: hello
-resources:
-- deployment.yaml
-- service.yaml
-generators:
-- cmGenerator.yaml
-EOF
-Review the files
-ls -C1 $MYAPP
-Plugins must live in a particular place for -kustomize to find them.
-This demo will use the ephemeral directory:
-PLUGIN_ROOT=$DEMO/kustomize/plugin
-The plugin config defined above in
-$MYAPP/cmGenerator.yaml specifies:
--apiVersion: myDevOpsTeam -kind: SillyConfigMapGenerator -
This means the plugin must live in a directory -named:
-MY_PLUGIN_DIR=$PLUGIN_ROOT/myDevOpsTeam/sillyconfigmapgenerator
-
-mkdir -p $MY_PLUGIN_DIR
-The directory name is the plugin config’s -apiVersion followed by its lower-cased kind.
-A plugin gets its own directory to hold itself, -its tests and any supplemental data files it -might need.
-There are two kinds of plugins, exec and Go.
-Make an exec plugin, installing it to the
-correct directory and file name. The file name
-must match the plugin’s kind (in this case,
-SillyConfigMapGenerator):
cat <<'EOF' >$MY_PLUGIN_DIR/SillyConfigMapGenerator
-#!/bin/bash
-# Skip the config file name argument.
-shift
-today=`date +%F`
-echo "
-kind: ConfigMap
-apiVersion: v1
-metadata:
- name: the-map
-data:
- today: $today
- altGreeting: "$1"
- enableRisky: "$2"
-"
-EOF
-By definition, an exec plugin must be executable:
-chmod a+x $MY_PLUGIN_DIR/SillyConfigMapGenerator
-Per the instructions:
-curl -s "https://raw.githubusercontent.com/\
-kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
-mkdir -p $DEMO/bin
-mv kustomize $DEMO/bin
-tree $DEMO
-XDG_CONFIG_HOME=$DEMO $DEMO/bin/kustomize build --enable_alpha_plugins $MYAPP
-Above, if you had set
---PLUGIN_ROOT=$HOME/.config/kustomize/plugin -
there would be no need to use XDG_CONFIG_HOME in the
-kustomize command above.
Moved to https://github.com/kubernetes-sigs/cli-experimental
-A Go plugin is a compilation artifact described -by the Go plugin package. It is built with -special flags and cannot run on its own. -It must be loaded into a running Go program.
---A normal program written in Go might be usable -as exec plugin, but is not a Go plugin.
-
Go plugins allow kustomize extensions that run -without the cost marshalling/unmarshalling all -resource data to/from a subprocess for each plugin -run. The Go plugin API assures a certain level of -consistency to avoid confusing downstream -transformers.
-Go plugins work as described in the plugin -package, but fall short of common notions -associated with the word plugin.
-Go plugin compilation creates an ELF formatted
-.so file, which by definition has no information
-about the provenance of the object code.
Skew between the compilation conditions (versions
-of package dependencies, GOOS, GOARCH) of the
-main program ELF and the plugin ELF will cause
-plugin load failure, with non-helpful error
-messages.
Exec plugins also lack provenance, but won’t fail -due to compilation skew.
-In either case, the only sensible way to share a
-plugin is as some kind of bundle (a git repo
-URL, a git archive file, a tar file, etc.)
-containing source code, tests and associated data,
-unpackable under
-$XDG_CONFIG_HOME/kustomize/plugin.
In the case of a Go plugin, an end user -accepting a shared plugin must compile both -kustomize and the plugin.
-This means a one-time run of
-# Or whatever is appropriate at time of reading
-GOPATH=${whatever} GO111MODULE=on go get sigs.k8s.io/kustomize/api
-and then a normal development cycle using
-go build -buildmode plugin \
- -o ${wherever}/${kind}.so ${wherever}/${kind}.go
-with paths and the release version tag (e.g. v3.0.0)
-adjusted as needed.
For comparison, consider what one -must do to write a tensorflow plugin.
-The Go plugin developer sees the same API offered -to native kustomize operations, assuring certain -semantics, invariants, checks, etc. An exec -plugin sub-process dealing with this via -stdin/stdout will have an easier time screwing -things up for downstream transformers and -consumers.
-Minor point: if the plugin reads files via
-the kustomize-provided file Loader interface, it
-will be constrained by kustomize file loading
-restrictions. Of course, nothing but a code audit
-prevents a Go plugin from importing the io package
-and doing whatever it wants.
A Go plugin developer can debug the plugin in -situ, setting breakpoints inside the plugin and -elsewhere while running a plugin in feature tests.
-To get the best of both worlds (shareability and safety),
-a developer can write an .go program that functions
-as an exec plugin, but can be processed by go generate
-to emit a Go plugin (or vice versa).
All the builtin generators and transformers -are themselves Go plugins. This means that -the kustomize maintainers can promote a contributed -plugin to a builtin without needing code changes -(beyond those mandated by normal code review).
-Tooling could ease Go plugin sharing, but this -requires some critical mass of Go plugin -authoring, which in turn is hampered by -confusion around sharing. Go modules, once they -are more widely adopted, will solve the -biggest plugin sharing difficulty: ambiguous -plugin vs host dependencies.
+Moved to https://github.com/kubernetes-sigs/cli-experimental
-This is a (no reading allowed!) 60 second copy/paste guided -example.
-Full plugin docs here. -Be sure to read the Go plugin caveats.
-This demo uses a Go plugin, SopsEncodedSecrets,
-that lives in the sopsencodedsecrets repository.
-This is an inprocess Go plugin, not an
-sub-process exec plugin that happens to be written
-in Go (which is another option for Go authors).
This is a guide to try it without damaging your -current setup.
-For encryption
-Or
-# Keeping these separate to avoid cluttering the DEMO dir.
-DEMO=$(mktemp -d)
-tmpGoPath=$(mktemp -d)
-Need v3.0.0 for what follows, and you must compile -it (not download the binary from the release page):
-GOPATH=$tmpGoPath go install sigs.k8s.io/kustomize/kustomize
-A kustomize plugin is fully determined by -its configuration file and source code.
-Kustomize plugin configuration files are formatted
-as kubernetes resource objects, meaning
-apiVersion, kind and metadata are required
-fields in these config files.
The kustomize program reads the config file
-(because the config file name appears in the
-generators or transformers field in the
-kustomization file), then locates the Go plugin’s
-object code at the following location:
--$XDG_CONFIG_HOME/kustomize/plugin/$apiVersion/$lKind/$kind.so -
where lKind holds the lowercased kind. The
-plugin is then loaded and fed its config, and the
-plugin’s output becomes part of the overall
-kustomize build process.
The same plugin might be used multiple times in -one kustomize build, but with different config -files. Also, kustomize might customize config -data before sending it to the plugin, for whatever -reason. For these reasons, kustomize owns the -mapping between plugins and config data; it’s not -left to plugins to find their own config.
-This demo will house the plugin it uses at the -ephemeral directory
-PLUGIN_ROOT=$DEMO/kustomize/plugin
-and ephemerally set XDG_CONFIG_HOME on a command
-line below.
At this stage in the development of kustomize
-plugins, plugin code doesn’t know or care what
-apiVersion or kind appears in the config file
-sent to it.
The plugin could check these fields, but it’s the -remaining fields that provide actual configuration -data, and at this point the successful parsing of -these other fields are the only thing that matters -to a plugin.
-This demo uses a plugin called SopsEncodedSecrets, -and it lives in the SopsEncodedSecrets repository.
-Somewhat arbitrarily, we’ll chose to install -this plugin with
-apiVersion=mygenerators
-kind=SopsEncodedSecrets
-By convention, the ultimate home of the plugin -code and supplemental data, tests, documentation, -etc. is the lowercase form of its kind.
-lKind=$(echo $kind | awk '{print tolower($0)}')
-In this case, the repo name matches the lowercase -kind already, so we just clone the repo and get -the proper directory name automatically:
-mkdir -p $PLUGIN_ROOT/${apiVersion}
-cd $PLUGIN_ROOT/${apiVersion}
-git clone git@github.com:monopole/sopsencodedsecrets.git
-Remember this directory:
-MY_PLUGIN_DIR=$PLUGIN_ROOT/${apiVersion}/${lKind}
-Plugins may come with their own tests. -This one does, and it hopefully passes:
-cd $MY_PLUGIN_DIR
-go test SopsEncodedSecrets_test.go
-Build the object code for use by kustomize:
-cd $MY_PLUGIN_DIR
-GOPATH=$tmpGoPath go build -buildmode plugin -o ${kind}.so ${kind}.go
-This step may succeed, but kustomize might -ultimately fail to load the plugin because of -dependency skew.
-On load failure
-be sure to build the plugin with the same
-version of Go (go1.13) on the same $GOOS
-(linux) and $GOARCH (amd64) used to build
-the kustomize being used in this demo.
change the plugin’s dependencies in its go.mod
-to match the versions used by kustomize (check
-kustomize’s go.mod used in its tagged commit).
Lacking tools and metadata to allow this to be -automated, there won’t be a Go plugin ecosystem.
-Kustomize has adopted a Go plugin architecture as -to ease accept new generators and transformers -(just write a plugin), and to be sure that native -operations (also constructed and tested as -plugins) are compartmentalized, orderable and -reusable instead of bizarrely woven throughout the -code as a individual special cases.
-Make a kustomization directory to -hold all your config:
-MYAPP=$DEMO/myapp
-mkdir -p $MYAPP
-Make a config file for the SopsEncodedSecrets plugin.
-Its apiVersion and kind allow the plugin to be
-found:
cat <<EOF >$MYAPP/secGenerator.yaml
-apiVersion: ${apiVersion}
-kind: ${kind}
-metadata:
- name: mySecretGenerator
-name: forbiddenValues
-namespace: production
-file: myEncryptedData.yaml
-keys:
-- ROCKET
-- CAR
-EOF
-This plugin expects to find more data in
-myEncryptedData.yaml; we’ll get to that shortly.
Make a kustomization file referencing the plugin -config:
-cat <<EOF >$MYAPP/kustomization.yaml
-commonLabels:
- app: hello
-generators:
-- secGenerator.yaml
-EOF
-Now generate the real encrypted data.
-We’re going to use sops to encode a file. Choose either GPG or Google Cloud KMS as the secret provider to continue.
-Try this:
-gpg --list-keys
-If it returns a list, presumably you’ve already created keys. If not, try import test keys from sops for dev.
-curl https://raw.githubusercontent.com/mozilla/sops/master/pgp/sops_functional_tests_key.asc | gpg --import
-SOPS_PGP_FP="1022470DE3F0BC54BC6AB62DE05550BC07FB1A0A"
-Try this:
-gcloud kms keys list --location global --keyring sops
-If it succeeds, presumably you’ve already created keys and placed them in a keyring called sops. If not, do this:
-gcloud kms keyrings create sops --location global
-gcloud kms keys create sops-key --location global \
- --keyring sops --purpose encryption
-Extract your keyLocation for use below:
-keyLocation=$(\
- gcloud kms keys list --location global --keyring sops |\
- grep GOOGLE | cut -d " " -f1)
-echo $keyLocation
-sopsGOPATH=$tmpGoPath go install go.mozilla.org/sops/cmd/sops
-Create raw data to encrypt:
-cat <<EOF >$MYAPP/myClearData.yaml
-VEGETABLE: carrot
-ROCKET: saturn-v
-FRUIT: apple
-CAR: dymaxion
-EOF
-Encrypt the data into file the plugin wants to read:
-With PGP
-$tmpGoPath/bin/sops --encrypt \
- --pgp $SOPS_PGP_FP \
- $MYAPP/myClearData.yaml >$MYAPP/myEncryptedData.yaml
-Or GCP KMS
-$tmpGoPath/bin/sops --encrypt \
- --gcp-kms $keyLocation \
- $MYAPP/myClearData.yaml >$MYAPP/myEncryptedData.yaml
-Review the files
-tree $DEMO
-This should look something like:
---/tmp/tmp.0kIE9VclPt -├── kustomize -│ └── plugin -│ └── mygenerators -│ └── sopsencodedsecrets -│ ├── go.mod -│ ├── go.sum -│ ├── LICENSE -│ ├── README.md -│ ├── SopsEncodedSecrets.go -│ ├── SopsEncodedSecrets.so -│ └── SopsEncodedSecrets_test.go -└── myapp - ├── kustomization.yaml - ├── myClearData.yaml - ├── myEncryptedData.yaml - └── secGenerator.yaml -
XDG_CONFIG_HOME=$DEMO $tmpGoPath/bin/kustomize build --enable_alpha_plugins $MYAPP
-This should emit a kubernetes secret, with
-encrypted data for the names ROCKET and CAR.
Above, if you had set
---PLUGIN_ROOT=$HOME/.config/kustomize/plugin -
there would be no need to use XDG_CONFIG_HOME in the
-kustomize command above.
Moved to https://github.com/kubernetes-sigs/cli-experimental
-Kustomize offers a plugin framework allowing people to write their own resource generators -and transformers.
-Write a plugin when changing generator options -or transformer configs doesn’t meet your needs.
-A generator plugin could be a helm chart -inflator, or a plugin that emits all the -components (deployment, service, scaler, -ingress, etc.) needed by someone’s 12-factor -application, based on a smaller number of free -variables.
-A transformer plugin might perform special
-container command line edits, or any other
-transformation beyond those provided by the
-builtin (namePrefix, commonLabels, etc.)
-transformers.
kustomization.yamlStart by adding a generators and/or transformers
-field to your kustomization.
Each field accepts a string list:
---generators: -- relative/path/to/some/file.yaml -- relative/path/to/some/kustomization -- /absolute/path/to/some/kustomization -- https://github.com/org/repo/some/kustomization +Moved to https://github.com/kubernetes-sigs/cli-experimental
-transformers: -- {as above} -
The value of each entry in a generators or
-transformers list must be a relative path to a
-YAML file, or a path or URL to a kustomization.
-This is the same format as demanded by the
-resources field.
YAML files are read from disk directly. Paths or -URLs leading to kustomizations trigger an -in-process kustomization run. Each of the -resulting objects is now further interpreted by -kustomize as a plugin configuration object.
-A kustomization file could have the following lines:
-generators:
-- chartInflator.yaml
-Given this, the kustomization process would expect
-to find a file called chartInflator.yaml in the
-kustomization root.
This is the plugin’s configuration file; -it contains a YAML configuration object.
-The file chartInflator.yaml could contain:
apiVersion: someteam.example.com/v1
-kind: ChartInflator
-metadata:
- name: notImportantHere
-chartName: minecraft
-The apiVersion and kind fields are
-used to locate the plugin.
Thus, these fields are required. They are also -required because a kustomize plugin configuration -object is also a k8s object.
-To get the plugin ready to generate or transform, -it is given the entire contents of the -configuration file.
-For more examples of plugin configuration YAML, -browse the unit tests below the plugins root, -e.g. the tests for ChartInflator or -NameTransformer.
-Each plugin gets its own dedicated directory named
-$XDG_CONFIG_HOME/kustomize/plugin
- /${apiVersion}/LOWERCASE(${kind})
-The default value of XDG_CONFIG_HOME is
-$HOME/.config.
The one-plugin-per-directory requirement eases -creation of a plugin bundle (source, tests, plugin -data files, etc.) for sharing.
-In the case of a Go plugin, it also
-allows one to provide a go.mod file for the
-single plugin, easing resolution of package
-version dependency skew.
When loading, kustomize will first look for an -executable file called
-$XDG_CONFIG_HOME/kustomize/plugin
- /${apiVersion}/LOWERCASE(${kind})/${kind}
-If this file is not found or is not executable,
-kustomize will look for a file called ${kind}.so
-in the same directory and attempt to load it as a
-Go plugin.
If both checks fail, the plugin load fails the overall
-kustomize build.
Plugins are only used during a run of the
-kustomize build command.
Generator plugins are run after processing the
-resources field (which itself can be viewed as a
-generator, simply reading objects from disk).
The full set of resources is then passed into the
-transformation pipeline, wherein builtin
-transformations like namePrefix and
-commonLabel are applied (if they were specified
-in the kustomization file), followed by the
-user-specified transformers in the transformers
-field.
The order specified in the transformers field is
-respected, as transformers cannot be expected to
-be commutative.
Kustomize plugins do not run in any kind of -kustomize-provided sandbox. There’s no notion -of “plugin security”.
-A kustomize build that tries to use plugins but
-omits the flag
---
--enable_alpha_plugins
will not load plugins and will fail with a -warning about plugin use.
-The use of this flag is an opt-in acknowledging -the unstable (alpha) plugin API, the absence of -plugin provenance, and the fact that a plugin -is not part of kustomize.
-To be clear, some kustomize plugin downloaded
-from the internet might wonderfully transform
-k8s config in a desired manner, while also
-quietly doing anything the user could do to the
-system running kustomize build.
There are two kinds of plugins, exec and Go.
-A exec plugin is any executable that accepts a -single argument on its command line - the name of -a YAML file containing its configuration (the file name -provided in the kustomization file).
---TODO: restrictions on plugin to allow the same exec -plugin to be targeted by both the -
-generatorsandtransformersfields.-
-- first arg could be the fixed string -
-generateortransform, -(the name of the configuration file moves to -the 2nd arg), or- or by default an exec plugin behaves as a tranformer -unless a flag
--gis provided, switching the -exec plugin to behave as a generator.
A generator plugin accepts nothing on stdin, but emits
-generated resources to stdout.
A transformer plugin accepts resource YAML on stdin,
-and emits those resources, presumably transformed, to
-stdout.
kustomize uses an exec plugin adapter to provide
-marshalled resources on stdin and capture
-stdout for further processing.
A generator exec plugin can adjust the generator options for the resources it emits by setting one of the following internal annotations.
---NOTE: These annotations are local to kustomize and will not be included in the final output.
-
kustomize.config.k8s.io/needs-hash
Resources can be marked as needing to be processed by the internal hash transformer by including the needs-hash annotation. When set valid values for the annotation are "true" and "false" which respectively enable or disable hash suffixing for the resource. Omitting the annotation is equivalent to setting the value "false".
Hashes are determined as follows:
-ConfigMap resources, hashes are based on the values of the name, data, and binaryData fields.Secret resources, hashes are based on the values of the name, type, data, and stringData fields.Example:
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: cm-test
- annotations:
- kustomize.config.k8s.io/needs-hash: "true"
-data:
- foo: bar
-kustomize.config.k8s.io/behavior
The behavior annotation will influence how conflicts are handled for resources emitted by the plugin. Valid values include “create”, “merge”, and “replace” with “create” being the default.
Example:
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: cm-test
- annotations:
- kustomize.config.k8s.io/behavior: "merge"
-data:
- foo: bar
-Be sure to read Go plugin caveats.
-A .go file can be a Go plugin if it declares
-‘main’ as it’s package, and exports a symbol to
-which useful functions are attached.
It can further be used as a kustomize plugin if
-the symbol is named ‘KustomizePlugin’ and the
-attached functions implement the Configurable,
-Generator and Transformer interfaces.
A Go plugin for kustomize looks like this:
---package main - -import ( -"sigs.k8s.io/kustomize/api/resmap" - ... -) - -type plugin struct {...} - -var KustomizePlugin plugin - -func (p *plugin) Config( - h *resmap.PluginHelpers, - c []byte) error {...} - -func (p *plugin) Generate() (resmap.ResMap, error) {...} - -func (p *plugin) Transform(m resmap.ResMap) error {...} -
Use of the identifiers plugin, KustomizePlugin
-and implementation of the method signature
-Config is required.
Implementing the Generator or Transformer
-method allows (respectively) the plugin’s config
-file to be added to the generators or
-transformers field in the kustomization file.
-Do one or the other or both as desired.
metadata/name as the prefix.
-This particular example exists to show how a plugin can
-transform the behavior of a plugin. See the
-TestTransformedTransformers test in the target package.A Go plugin can be both a generator and a
-transformer. The Generate method will run along
-with all the other generators before the
-Transform method runs.
Here’s a build command that sensibly assumes the
-plugin source code sits in the directory where
-kustomize expects to find .so files:
d=$XDG_CONFIG_HOME/kustomize/plugin\
-/${apiVersion}/LOWERCASE(${kind})
-
-go build -buildmode plugin \
- -o $d/${kind}.so $d/${kind}.go
-
Binaries at various versions for linux, MacOs and Windows are published on the releases page.
-The following script detects your OS and downloads the appropriate kustomize binary to your -current working directory.
-curl -s "https://raw.githubusercontent.com/\
-kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
-
+Moved to https://github.com/kubernetes-sigs/cli-experimental
+choco install kustomize
-For support on the chocolatey package -and prior releases, see:
- +Moved to https://github.com/kubernetes-sigs/cli-experimental
For Homebrew users:
-brew install kustomize
-For MacPorts users:
-sudo port install kustomize
-
+Moved to https://github.com/kubernetes-sigs/cli-experimental
+Moved to https://github.com/kubernetes-sigs/cli-experimental
Requires Go to be installed.
-GOBIN=$(pwd)/ GO111MODULE=on go get sigs.k8s.io/kustomize/kustomize/v3
-# Need go 1.13 or higher
-unset GOPATH
-# see https://golang.org/doc/go1.13#modules
-unset GO111MODULES
+Moved to https://github.com/kubernetes-sigs/cli-experimental
-# clone the repo
-git clone git@github.com:kubernetes-sigs/kustomize.git
-# get into the repo root
-cd kustomize
-
-# Optionally checkout a particular tag if you don't
-# want to build at head
-git checkout kustomize/v3.2.3
-
-# build the binary
-(cd kustomize; go install .)
-
-# run it
-~/go/bin/kustomize version
-