51 lines
1.5 KiB
Markdown
51 lines
1.5 KiB
Markdown
|
## Apps
|
||
|
|
|
||
|
|
This directory contains test applications which are using kustomize or
|
||
|
|
helm for testing. The objective of these apps is to create typical
|
||
|
|
flows for adding apps into clusters.
|
||
|
|
|
||
|
|
## Use case 1: common anchor
|
||
|
|
|
||
|
|
We want to achieve the following:
|
||
|
|
|
||
|
|
* have a common anchor to define the name of a service ("service1")
|
||
|
|
* That anchor steers generation of configuration files in config maps
|
||
|
|
("nginx config with hostname
|
||
|
|
service1.$namespace.svc.$clusterdomain")
|
||
|
|
|
||
|
|
Best case: $clusterdomain can be queried from the cluster.
|
||
|
|
|
||
|
|
### kustomize
|
||
|
|
|
||
|
|
It does not seem kustomize has a logical way to support this, as it
|
||
|
|
does not have variables that can be injected into fields.
|
||
|
|
|
||
|
|
One can use the name-prefix or similar for modifying the service name,
|
||
|
|
but that prefix is not automatically injected into the relevant
|
||
|
|
configuration within a configmap.
|
||
|
|
|
||
|
|
### helm
|
||
|
|
|
||
|
|
Helm seems to cope with the anchor case easily using values.yaml as the
|
||
|
|
anchor.
|
||
|
|
|
||
|
|
|
||
|
|
## Handling of configmap updates
|
||
|
|
|
||
|
|
Assuming one updates a configmap (new configuration), what happens to
|
||
|
|
the old configmap? Is it left alone, is it deleted automatically?
|
||
|
|
|
||
|
|
### kustomize
|
||
|
|
|
||
|
|
Kustomize usually generates the ConfigMaps and appends a hash to its
|
||
|
|
name. Thus the referencing objects (Pods mostly) will also get updated
|
||
|
|
and refer to a new configmap.
|
||
|
|
|
||
|
|
Untested, but the assumption is that kustomize will leave the old
|
||
|
|
configmap behind.
|
||
|
|
|
||
|
|
### helm
|
||
|
|
|
||
|
|
Helm does not have a concept of generating confimaps, so in theory it
|
||
|
|
would update the same configmap (depending on how you named it).
|