A megszokáson kívül miért jó egy external nem K8s-nativ template rendszer használata?
Átfogalmazom, mert ez lehet félrement.
Ha kevés dolgot kell változtatni (ingress, DB URL) akkor a helm chart kezelése, verzió managmentje, buildje, checkje plusz felesleges effort, nem egyszerűbbé hanem komplexebbé teszi a dolgokat. 2-3 fix égetett változó behelyettesítésnél (ahol fix helyre, ifezés és bármiféle átalakítás nélkül kell berakni a változókat) lényegében nincs a Helm-nek komoly benefitje (hiszen a values-t külön nem tudja validálni, ami legalább minimális értelmet adna ebben a speciális esetben), cserébe rak egy karbatartási terhet a projektre, tekintettel arra, hogy ez egy különálló csomaggá válik amit azért legalább semver szinten verziózni illik, plusz egy csomó metaadatot, egyebet kell kitölteni és karbantartani - anélkül, hogy érdemi hasznot hozna. Magyarul kis vagy egyszerű alkalmazásokhoz nem érdemes használni.
Abban a pillanatban, hogy komplex kezd lenni a dolog, if-else szerkezetek vagy feature kapcsolók megjelennek, már van értelme a Helm-nek.
Összefoglalva: Én csak azt mondom, hogy a Helmnek megvan az az alsó komplexitási küszöbe, ami után validálódik az alkalamzása, de nem kellene ész nélkül mindenre is Helmet használni, puszátn csak azért, mert ez ma a trendy.
(abba bele se menjünk, hogy a Helm K8s-natív-e vagy sem. Szűken értelmezve amúgy nem az, lényegében egy földbuta build eszköz: fogalma sincsen a Kubernetesről, legenerál YAML-öket a templatek alapján, aztán hozzávágja a Kubernetes API szerverhez, kezdjen vele amit tud. Ha szar, az se derül ki az ő szintjén, majd visszaköpi amit a K8s visszadobott. Lényegében a template processingen + egy nagyon alap YAML szintaxis validáláson kívül semmit nem csinál a Helm a Kubernetes szempontjából. Nem véletlen, hogy a Flux/ArgoCD azok, amik beszélgetnek is a Kubernetessel és objektumkövetést végeznek, illetve hogy a legenerált Kuberenets objektumok bármiféle validálása csak és kizárólag plugineken keresztül lehetséges).