update docs, examples, comments

This commit is contained in:
zoncoen
2018-11-26 14:19:30 +09:00
parent 7dc8ef1028
commit 59df8a0dda
7 changed files with 31 additions and 16 deletions

View File

@@ -150,7 +150,7 @@ Here's an [example](kustomization.yaml).
A kustomization contains fields falling into these categories: A kustomization contains fields falling into these categories:
* _Customization operators_ for modifying operands, e.g. * _Customization operators_ for modifying operands, e.g.
_namePrefix_, _commonLabels_, _patches_, etc. _namePrefix_, _nameSuffix_, _commonLabels_, _patches_, etc.
* _Customization operands_: * _Customization operands_:
* [resources] - completely specified k8s API objects, * [resources] - completely specified k8s API objects,

View File

@@ -40,6 +40,13 @@ namespace: my-namespace
# "wordpress" becomes "alices-wordpress". # "wordpress" becomes "alices-wordpress".
namePrefix: alices- namePrefix: alices-
# Value of this field is appended to the
# names of all resources, e.g. a deployment named
# "wordpress" becomes "wordpress-v2".
# The suffix is appended before content hash
# if resource type is ConfigMap or Secret.
nameSuffix: -v2
# Labels to add to all resources and selectors. # Labels to add to all resources and selectors.
commonLabels: commonLabels:
someName: someValue someName: someValue
@@ -205,9 +212,9 @@ patchesJson6902:
# transformation for any objects in those types. # transformation for any objects in those types.
# #
# Typical use case: A CRD object refers to a ConfigMap object. # Typical use case: A CRD object refers to a ConfigMap object.
# In kustomization, the ConfigMap object name may change by adding namePrefix or hashing # In 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 # The name reference for this ConfigMap object in CRD object need to be
# updated with namePrefix or hashing in the same way. # updated with namePrefix, nameSuffix, or hashing in the same way.
crds: crds:
- crds/typeA.yaml - crds/typeA.yaml
- crds/typeB.yaml - crds/typeB.yaml

View File

@@ -194,6 +194,7 @@ cat <<EOF >$OVERLAYS/development/kustomization.yaml
bases: bases:
- ../../base - ../../base
namePrefix: dev- namePrefix: dev-
nameSuffix: -v1
configMapGenerator: configMapGenerator:
- name: my-configmap - name: my-configmap
behavior: merge behavior: merge
@@ -215,11 +216,12 @@ kustomize build $OVERLAYS/development
The name of the generated `ConfigMap` is visible in this The name of the generated `ConfigMap` is visible in this
output. output.
The name should be something like `dev-my-configmap-b5m75ck895`: The name should be something like `dev-my-configmap-v1-2gccmccgd5`:
* `"dev-"` comes from the `namePrefix` field, * `"dev-"` comes from the `namePrefix` field,
* `"my-configmap"` comes from the `configMapGenerator/name` field, * `"my-configmap"` comes from the `configMapGenerator/name` field,
* `"-b5m75ck895"` comes from a deterministic hash that `kustomize` * `"-v1"` comes from the `nameSuffix` field,
* `"-2gccmccgd5"` comes from a deterministic hash that `kustomize`
computes from the contents of the configMap. computes from the contents of the configMap.
The hash suffix is critical. If the configMap content The hash suffix is critical. If the configMap content

View File

@@ -60,6 +60,7 @@ mkdir -p $OVERLAYS/staging
cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml
namePrefix: staging- namePrefix: staging-
nameSuffix: -v1
commonLabels: commonLabels:
variant: staging variant: staging
org: acmeCorporation org: acmeCorporation
@@ -150,13 +151,17 @@ The configMap name is prefixed by _staging-_, per the
`namePrefix` field in `namePrefix` field in
`$OVERLAYS/staging/kustomization.yaml`. `$OVERLAYS/staging/kustomization.yaml`.
The configMap name is suffixed by _-v1_, per the
`nameSuffix` field in
`$OVERLAYS/staging/kustomization.yaml`.
The suffix to the configMap name is generated from a The suffix to the configMap name is generated from a
hash of the maps content - in this case the name suffix hash of the maps content - in this case the name suffix
is _hhhhkfmgmk_: is _k25m8k5k5m_:
<!-- @grepStagingHash @test --> <!-- @grepStagingHash @test -->
``` ```
kustomize build $OVERLAYS/staging | grep hhhhkfmgmk kustomize build $OVERLAYS/staging | grep k25m8k5k5m
``` ```
Now modify the map patch, to change the greeting Now modify the map patch, to change the greeting
@@ -183,20 +188,20 @@ kustomize build $OVERLAYS/staging |\
``` ```
Confirm that the change in configMap content resulted Confirm that the change in configMap content resulted
in three new names ending in _khk45ktkd9_ - one in the in three new names ending in _cd7kdh48fd_ - one in the
configMap name itself, and two in the deployment that configMap name itself, and two in the deployment that
uses the map: uses the map:
<!-- @countHashes @test --> <!-- @countHashes @test -->
``` ```
test 3 == \ test 3 == \
$(kustomize build $OVERLAYS/staging | grep khk45ktkd9 | wc -l); \ $(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \
echo $? echo $?
``` ```
Applying these resources to the cluster will result in Applying these resources to the cluster will result in
a rolling update of the deployments pods, retargetting a rolling update of the deployments pods, retargetting
them from the _hhhhkfmgmk_ maps to the _khk45ktkd9_ them from the _k25m8k5k5m_ maps to the _cd7kdh48fd_
maps. The system will later garbage collect the maps. The system will later garbage collect the
unused maps. unused maps.

View File

@@ -2,7 +2,7 @@
Kustomize computes the resources by applying a series of transformers: Kustomize computes the resources by applying a series of transformers:
- namespace transformer - namespace transformer
- prefix transformer - prefix/suffix transformer
- label transformer - label transformer
- annotation transformer - annotation transformer
- name reference transformer - name reference transformer
@@ -22,8 +22,8 @@ create: false
``` ```
If `create` is set to true, it indicates the transformer to create the path if it is not found in the resources. This is most useful for label and annotation transformers, where the path for labels or annotations may not be set before the transformation. If `create` is set to true, it indicates the transformer to create the path if it is not found in the resources. This is most useful for label and annotation transformers, where the path for labels or annotations may not be set before the transformation.
## prefix transformer ## prefix/suffix transformer
Name prefix transformer adds prefix to the `metadata/name` field for all resources with following configuration: Name prefix suffix transformer adds prefix and suffix to the `metadata/name` field for all resources with following configuration:
``` ```
namePrefix: namePrefix:
- path: metadata/name - path: metadata/name

View File

@@ -25,7 +25,7 @@ type Json6902 struct {
// applied to. It must refer to a Kubernetes resource under the // applied to. It must refer to a Kubernetes resource under the
// purview of this kustomization. Target should use the // purview of this kustomization. Target should use the
// raw name of the object (the name specified in its YAML, // raw name of the object (the name specified in its YAML,
// before addition of a namePrefix). // before addition of a namePrefix and a nameSuffix).
Target *Target `json:"target" yaml:"target"` Target *Target `json:"target" yaml:"target"`
// relative file path for a json patch file inside a kustomization // relative file path for a json patch file inside a kustomization

View File

@@ -17,8 +17,9 @@ limitations under the License.
package types package types
import ( import (
"sigs.k8s.io/kustomize/pkg/gvk"
"strings" "strings"
"sigs.k8s.io/kustomize/pkg/gvk"
) )
// Var represents a variable whose value will be sourced // Var represents a variable whose value will be sourced
@@ -31,7 +32,7 @@ type Var struct {
// ObjRef must refer to a Kubernetes resource under the // ObjRef must refer to a Kubernetes resource under the
// purview of this kustomization. ObjRef should use the // purview of this kustomization. ObjRef should use the
// raw name of the object (the name specified in its YAML, // raw name of the object (the name specified in its YAML,
// before addition of a namePrefix). // before addition of a namePrefix and a nameSuffix).
ObjRef Target `json:"objref" yaml:"objref"` ObjRef Target `json:"objref" yaml:"objref"`
// FieldRef refers to the field of the object referred to by // FieldRef refers to the field of the object referred to by