kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-05-17 18:25:26 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Add consistency to ConfigMap spelling

Browse Source
This commit is contained in:
Timo Furrer
2021-09-27 09:11:56 +02:00
parent 12d1771bb3
commit c455215f55
1 changed files with 14 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
examples/configGeneration.md
View File

@@ -21,11 +21,11 @@ Kustomize provides two ways of adding ConfigMap in one `kustomization`, either b
The ConfigMaps declared as [resource] are treated the same way as other resources. Kustomize doesn't append any hash to the ConfigMap name. The ConfigMap declared from a ConfigMapGenerator is treated differently. A hash is appended to the name and any change in the ConfigMap will trigger a rolling update. The ConfigMaps declared as [resource] are treated the same way as other resources. Kustomize doesn't append any hash to the ConfigMap name. The ConfigMap declared from a ConfigMapGenerator is treated differently. A hash is appended to the name and any change in the ConfigMap will trigger a rolling update.
In this demo, the same [hello_world](helloWorld/README.md) is used while the ConfigMap declared as [resources] is replaced by a ConfigMap declared from a ConfigmapGenerator. The change in this ConfigMap will result in a hash change and a rolling update. In this demo, the same [hello_world](helloWorld/README.md) is used while the ConfigMap declared as [resources] is replaced by a ConfigMap declared from a ConfigMapGenerator. The change in this ConfigMap will result in a hash change and a rolling update.
### Establish base and staging ### Establish base and staging
Establish the base with a configMapGenerator Establish the base with a `configMapGenerator`:
<!-- @establishBase @test --> <!-- @establishBase @test -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -85,7 +85,7 @@ EOF
### Review ### Review
The _hello-world_ deployment running in this cluster is The _hello-world_ deployment running in this cluster is
configured with data from a configMap. configured with data from a ConfigMap.
The deployment refers to this map by name: The deployment refers to this map by name:
@@ -95,26 +95,26 @@ The deployment refers to this map by name:
grep -C 2 configMapKeyRef $BASE/deployment.yaml grep -C 2 configMapKeyRef $BASE/deployment.yaml
``` ```
Changing the data held by a live configMap in a cluster Changing the data held by a live ConfigMap in a cluster
is considered bad practice. Deployments have no means is considered bad practice. Deployments have no means
to know that the configMaps they refer to have to know that the ConfigMaps they refer to have
changed, so such updates have no effect. changed, so such updates have no effect.
The recommended way to change a deployment's The recommended way to change a deployment's
configuration is to configuration is to
1. create a new configMap with a new name, 1. create a new ConfigMap with a new name,
1. patch the _deployment_, modifying the name value of 1. patch the _deployment_, modifying the name value of
the appropriate `configMapKeyRef` field. the appropriate `configMapKeyRef` field.
This latter change initiates rolling update to the pods This latter change initiates rolling update to the pods
in the deployment. The older configMap, when no longer in the deployment. The older ConfigMap, when no longer
referenced by any other resource, is eventually garbage referenced by any other resource, is eventually garbage
collected. collected.
### How this works with kustomize ### How this works with kustomize
The _staging_ [variant] here has a configMap [patch]: The _staging_ [variant] here has a ConfigMap [patch]:
<!-- @showMapPatch @test --> <!-- @showMapPatch @test -->
``` ```
@@ -125,7 +125,7 @@ This patch is by definition a named but not necessarily
complete resource spec intended to modify a complete complete resource spec intended to modify a complete
resource spec. resource spec.
The ConfigMap it modifies is declared from a configMapGenerator. The ConfigMap it modifies is declared from a `configMapGenerator`.
<!-- @showMapBase @test --> <!-- @showMapBase @test -->
``` ```
@@ -146,11 +146,11 @@ kustomize build $OVERLAYS/staging |\
grep -B 8 -A 1 staging-the-map grep -B 8 -A 1 staging-the-map
``` ```
The configMap name is prefixed by _staging-_, per the The ConfigMap name is prefixed by _staging-_, per the
`namePrefix` field in `namePrefix` field in
`$OVERLAYS/staging/kustomization.yaml`. `$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 _hhhhkfmgmk_:
@@ -174,7 +174,7 @@ kustomize build $OVERLAYS/staging |\
grep -B 2 -A 3 kiwi grep -B 2 -A 3 kiwi
``` ```
Run kustomize again to see the new configMap names: Run kustomize again to see the new ConfigMap names:
<!-- @grepStagingName @test --> <!-- @grepStagingName @test -->
``` ```
@@ -182,9 +182,9 @@ kustomize build $OVERLAYS/staging |\
grep -B 8 -A 1 staging-the-map grep -B 8 -A 1 staging-the-map
``` ```
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 _khk45ktkd9_ - 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 -->