ungleich-k8s/apps
Nico Schottelius 8110edc659 ++readme for apps 2021-06-20 09:19:48 +02:00
..
etherpadlite Add first app 2021-06-10 01:09:29 +02:00
nginx-certbot Need to add commonLabels so that the selector of service matches 2021-06-19 18:09:31 +02:00
nginx-certbot-helm Fix labeling 2021-06-19 23:38:52 +02:00
README.md ++readme for apps 2021-06-20 09:19:48 +02:00

README.md

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).