Browse Source

++readme/doc update

master
Nico Schottelius 1 year ago
parent
commit
82b2caa6e6
  1. 2
      README.md
  2. 83
      apps/README.md

2
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

83
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

Loading…
Cancel
Save