Helm és Kustomize: a konfigurációkezelés újabb módjai

Nézzünk egy újabb fejezetet a Kubernetes világából. Eddig szó volt arról, mi történik valójában egy Deployment mögött, aztán körbejártuk a workloadokat – a DaemonSeteket, StatefulSeteket és az autoscalingot -, majd a namespace-ek rendteremtő szerepét is megnéztük. A mai témám szorosan kapcsolódik mindehhez: mi történik akkor, amikor egy alkalmazás már nem egy-két manifestből áll, hanem tucatnyiból, és ezeket kell valahogy kezelhető állapotban tartani.

Ez a kérdés az utóbbi időben egyre fontosabb, ahogy egyre több AI szolgáltatás működik a Kubernetes cluster-eken is. Egy ilyen rendszer – modell-kezelő szolgáltatás, adatfeldolgozó pipeline, külső API, felügyelet – könnyen tíz-húsz külön manifestet igényel, ezek pedig gyorsan elburjánzanak, ha nincs mögöttük rendszerezettség. Erre a problémára született két, ma is aktívan használt eszköz: a Helm és a Kustomize.

Mielőtt összecsapnak a fejünk felett a hullámok

Egy éles, több komponensből álló alkalmazásnak szinte mindig van saját Deployment, Service, ConfigMap, Secret és gyakran Ingress manifestje is. Ez fejlesztői gépen még átlátható, de amint verziózni, több környezetben – fejlesztés, teszt, éles – telepíteni, majd frissíteni is kell ezeket, a kézi YAML szerkesztés hamar kezelhetetlenné és problémaforrássá válik. Ennek megoldására használjuk a két, egymástól eltérő filozófiájú eszközt a Kubernetes világában: a Helm és a Kustomize.

A Helm mint csomagkezelő

A Helm működési modellje sokat emlékeztet a hagyományos csomagkezelőkre, mint amilyen a yum vagy az apt Linux alatt. Egy Helm chart egy archivált gyűjteménye azoknak a Kubernetes manifest-eknek, amelyek együtt alkotnak egy alkalmazást. Ahelyett, hogy külön-külön kellene alkalmazni a Deployment, a Service és a ConfigMap fájlokat, a Helm ezeket egyetlen állományba csomagolja, amit egyetlen paranccsal lehet telepíteni, frissíteni vagy visszaállítani egy korábbi verzióra.

Ez a megközelítés több gyakorlati előnnyel jár. A chartok verziózhatók, tehát pontosan tudni lehet, melyik alkalmazásverzió fut a clusterben. Ha egy frissítés problémát okoz, a rollback paranccsal gyorsan vissza lehet állni egy stabil állapotra, minimalizálva a leállást és a kieséset. A konfiguráció a values.yaml fájlon vagy parancssori paramétereken keresztül környezetenként testreszabható, így ugyanaz a chart más beállításokkal futtatható fejlesztői és éles környezetben is. A Helm emellett jól illeszkedik a CI/CD folyamatokba, mögötte pedig egy aktív közösség áll, amely rengeteg előre elkészített chartot biztosít gyakori alkalmazásokhoz.

A Helm mára a Cloud Native Computing Foundation egyik projektje.

Mi van egy chart belsejében

Egy tipikus chart felépítése viszonylag egyszerű logikát követ. A Chart.yaml fájl a metaadatokat tartalmazza, mint a chart neve, verziója és kulcsszavai.

apiVersion: v2
name: hello-world
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"

A values.yaml azokat az alapértelmezett kulcs-érték párokat tartja, amelyeket a telepítés során lehet felülírni.

replicaCount: 1
image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: ""

nameOverride: ""
fullnameOverride: ""

serviceAccount:
  create: true
  annotations: {}
fullname template
  name: ""

service:
  type: ClusterIP
  port: 80

A templates mappa tartalmazza magukat a manifesteket – például egy deployment.yaml, egy svc.yaml, egy configmap.yaml vagy egy secrets.yaml fájlt -, amelyek Go templating szintaxist használnak. Ez azt jelenti, hogy a manifestekben szereplő változók, mint egy jelszó vagy egy név, a values.yaml-ból töltődnek be a telepítés pillanatában. Egy jó chart README.md fájlt is tartalmaz, amiben gyakran olyan előfeltételek szerepelnek, mint egy szükséges persistent volume megléte, ezért telepítés előtt mindig érdemes ezt átolvasni.

Itt találsz egy egyszerű példát: https://github.com/helm/examples

Chart repository-k és a Hub

A chartokat repository-k tárolják, amelyek technikailag egyszerű HTTP szerverek egy index fájllal és a chartok tarballjaival. Mielőtt hozzáadnál egy repository-t, a helm search hub paranccsal az Artifact Hubon kereshetsz. Ha hozzáadtál egy repository-t, például a helm repo add paranccsal, utána a helm search repo segítségével kereshetsz benne, majd a talált chartot egyetlen helm install paranccsal telepítheted. A telepítés kimenetét mindig érdemes alaposan átnézni, mert gyakran ez tartalmazza az első nyomokat arra, ha egy szükséges cluster-erőforrás hiányzik.

A Kustomize más filozófiája

A Kustomize más utat választott. Míg a Helm templating nyelvet használ a változók behelyettesítésére, a Kustomize semmilyen sablon szintaxist nem igényel. Ehelyett egy alap, úgynevezett base konfigurációt definiálsz, majd overlay-ekkel írod felül vagy egészíted ki azt környezetenként – mondjuk a replikák számát, az image taget vagy egy címkét. A módosítások stratégiai merge és patch technikákkal történnek, nem szöveghelyettesítéssel.

Ennek gyakorlati előnye, hogy a Kustomize a kubectl része 1.14-es verziótól kezdve, tehát nincs szükség külön telepítésre – bár egy önálló bináris is elérhető, ha fejlettebb funkciókra van szükséged. A kubectl kustomize dir paranccsal megnézheted a végeredményt, a kubectl apply -k dir paranccsal pedig alkalmazhatod a clusteren.

A kustomization.yaml és a bázis-overlay felépítés

A Kustomize szíve a kustomization.yaml fájl, amely felsorolja, mely erőforrásokat kell kezelni, és milyen módosításokat kell rájuk alkalmazni. A jól szervezett projekt mappastruktúrája jellemzően egy base mappát tartalmaz a közös konfigurációval, illetve külön overlays/dev és overlays/prod mappákat a környezet-specifikus eltérésekkel, elkerülve ezzel a YAML fájlok másolgatását. A kustomization.yaml-ban beállítható például egy namePrefix, ami minden erőforrás nevéhez hozzáfűz egy előtagot – egy myapp-deployment nevű erőforrásból így lesz lf-myapp-deployment -, illetve közös címkék és annotációk is hozzáadhatók minden erőforráshoz, ami a clusteren belüli szűréshez és szervezéshez hasznos. A patchek finomhangolt, egyedi módosításokra valók, mint egy környezeti változó hozzáadása, míg a transzformerek szélesebb körű, minden erőforrásra vonatkozó módosításokat végeznek. A Kustomize emellett generátorokat is kínál ConfigMapek és Secretek dinamikus létrehozására, akár literál értékekből, akár fájlokból.

Itt találsz különböző példákat: https://github.com/kubernetes-sigs/kustomize/tree/master/examples

Melyiket válaszd

Nincs egyetlen helyes válasz. A Helm akkor kiváló választás, amikor egy alkalmazást csomagként szeretnél telepíteni, verziózni és mások számára újrafelhasználhatóvá tenni – gondolj például egy adatbázis motorra. A Kustomize akkor kényelmesebb, amikor saját, meglévő YAML fájljaidat szeretnéd környezetenként kis mértékben testre szabni, sablonok használata nélkül.

A kettő egyébként nem is zárja ki egymást: gyakori előfordul, hogy egy Helm chartot Kustomize-zal utólag testre szabnak.

Amit tapasztalatból mindenképp kiemelnék: sokan telepítenek egy közösségi chartot anélkül, hogy elolvasnák a README-t vagy átnéznék a values.yaml alapértelmezett értékeit. Ez ott szokott fájni, amikor kiderül, hogy egy alapértelmezett jelszó vagy egy nem megfelelő erőforrásigény került éles környezetbe. Ugyanígy a Kustomize overlay-eknél is érdemes tudatosan megtervezni az alap és a környezet-specifikus rétegek határát, különben pont az a rugalmasság vész el, amiért ezeket az eszközöket eredetileg bevezették: az átláthatóság és a megismételhetőség.