public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-14 10:16:27 +00:00
Code Issues Releases Wiki Activity

Add Velero and snapshot controller for backups

Browse Source 
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2023-10-20 13:02:27 +13:00
parent c592669148
commit c2d06a38ec
12 changed files with 597 additions and 307 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
_snippets/kubernetes-why-not-full-values-in-configmap.md Normal file
View File

@@ -0,0 +1,11 @@
??? question "Why not put values in a separate ConfigMap?"
> Didn't you previously advise to put helm chart values into a separate ConfigMap?
Yes, I did. And in practice, I've changed my mind.
Why? Because having the helm values directly in the HelmRelease offers the following advantages:
1. If you use the [YAML](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) extension in VSCode, you'll see a full path to the YAML elements, which can make grokking complex charts easier.
2. When flux detects a change to a value in a HelmRelease, this forces an immediate reconciliation of the HelmRelease, as opposed to the ConfigMap solution, which requires waiting on the next scheduled reconciliation.
3. Renovate can parse HelmRelease YAMLs and create PRs when they contain docker image references which can be updated.
4. In practice, adapting a HelmRelease to match upstream chart changes is no different to adapting a ConfigMap, and so there's no real benefit to splitting the chart values into a separate ConfigMap, IMO.