Merge branch 'master' of code.ungleich.ch:ungleich-public/ungleich-k8s

README.md

@@ -22,6 +22,8 @@ This project is testing, deploying and using IPv6 only k8s clusters.
 * argocd (?) for CI and upgrades
 * Maybe LoadBalancer support (our ClusterIP already does that though)
 * (Other) DNS entrys for services
+* Internal backup / snapshots
+* External backup (rsync, rbd mirror, etc.)
 
 ## Cluster setup
 

apps/README.md

@@ -112,3 +112,86 @@ Disadvantage: the Job pod needs to modify cluster resources.
 
 Both kustomize and helm seem to support adjusting the namespace for
 resources easily.
+
+## Helm specific notes
+
+* Should we use the {{ .Release.name }} for matching on pods?
+* What is the best strategy for naming deployments?
+* What is the best strategy for naming configmaps?
+* What is the best strategy for naming volumes?
+
+Generally speaking, which resources
+
+* stay the same when upgrading?
+* should be different for different deployments?
+
+Objective for a deployment is to continue functioning with rollover of
+pods.
+
+
+### Relevant objects
+
+* .Release.Name = "per installation name"
+. .Chart.Name = "name of the application (chart)"
+* .Chart.Version = "version of the application (chart)"
+
+### .Release (.Name) assumptions
+
+Per release (name) we will include a specific service that should be
+kept running and keep the same name even when the charts change
+(upgrade).
+
+### General identifier
+
+#### v2
+
+The .Release.Name includes the .Chart.name if we are using
+--generate-name. However if we manually specify a release name
+(like "rrrrrrrr") the .Chart.Name is not included.
+
+As the admin of the cluster decides on the naming, it seems to make
+sense to use .Release.Name alone as an identifier, as it can be
+directly influenced by the admin.
+
+#### v1
+
+Using something like **{{ .Chart.Name }}-{{ .Release.Name }} as an
+identifier or prefix for most "static" objects seems to make sense:
+
+- .Chart.Name introduces the admin to where that objects belongs to
+- .Release.Name makes it unique per release
+
+In theory .Chart.Name could be omitted, but including it should make
+maintaining the apps more easy.
+
+
+### Service
+
+The service name steers the DNS name
+
+** If externally exposed, should probably stay the same during upgrade
+** Should probably not change depending on the release
+*** Or should it? Depends on the intent.
+
+The service selector
+
+* should probably target the .Release.Name and also something like
+`use-as-service: true` to exclude other pods that might be around.
+
+### Deployment
+
+* Should probably be **named** depending on .Release.Name to allow
+  multiple
+* Should probably **match** on .Release.Name to select/create correct pods
+
+If there are multiple deployments within one release, probably suffix
+them (for name and matching).
+
+### Volumes
+
+* Should probably be **named** depending on .Release.Name to allow
+  multiple: {{ .Release.name }}-volumename
+* Will usually contain release specific data or persistent data we
+  want to keep
+* ... unless the release is removed, then data / volumes / PV / PVC can be
+  deleted, too