kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-05-17 10:15:22 +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.
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 the base with a configMapGenerator
Establish the base with a `configMapGenerator`:
<!-- @establishBase @test -->
```
DEMO_HOME=$(mktemp -d)
@@ -85,7 +85,7 @@ EOF
### Review
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:
@@ -95,26 +95,26 @@ The deployment refers to this map by name:
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
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.
The recommended way to change a deployment's
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
the appropriate `configMapKeyRef` field.
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
collected.
### How this works with kustomize
The _staging_ [variant] here has a configMap [patch]:
The _staging_ [variant] here has a ConfigMap [patch]:
<!-- @showMapPatch @test -->
```
@@ -125,7 +125,7 @@ This patch is by definition a named but not necessarily
complete resource spec intended to modify a complete
resource spec.
The ConfigMap it modifies is declared from a configMapGenerator.
The ConfigMap it modifies is declared from a `configMapGenerator`.
<!-- @showMapBase @test -->
```
@@ -146,11 +146,11 @@ kustomize build $OVERLAYS/staging |\
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
`$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
is _hhhhkfmgmk_:
@@ -174,7 +174,7 @@ kustomize build $OVERLAYS/staging |\
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 -->
```
@@ -182,9 +182,9 @@ kustomize build $OVERLAYS/staging |\
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
configMap name itself, and two in the deployment that
ConfigMap name itself, and two in the deployment that
uses the map:
<!-- @countHashes @test -->