A Kustomize rövid bemutatása

Jegyzet. ford.: A cikket Scott Lowe, nagy informatikai tapasztalattal rendelkező mérnök írta, aki hét nyomtatott könyv szerzője/társszerzője (főleg a VMware vSphere-ről). Jelenleg a VMware leányvállalatánál, a Heptio-nál dolgozik (2016-ban vásárolták), és a számítási felhőre és a Kubernetesre szakosodott. Maga a szöveg tömör és könnyen érthető bevezetésként szolgál a Kubernetes technológiát használó konfigurációkezeléséhez. Testreszab, amely nemrégiben a K8s része lett.

A Kustomize egy olyan eszköz, amely lehetővé teszi a felhasználók számára, hogy „egyszerű, sablonmentes YAML-fájlokat testreszabjanak különböző célokra, így az eredeti YAML érintetlen és használható” (a leírás közvetlenül a kustomize adattár a GitHubon). A Kustomize közvetlenül futtatható, vagy a Kubernetes 1.14-től kezdve használható kubectl -k funkcióinak eléréséhez (bár a Kubernetes 1.15-től a különálló bináris fájl újabb, mint a kubectl-be épített képességek). (Jegyzet. ford.: És a legutóbbi kiadással Kubernetes 1.16 testreszab támogatta a kubeadm segédprogramban is.) Ebben a bejegyzésben szeretném megismertetni az olvasókkal a kustomize alapjait.

A legegyszerűbb formában/alkalmazásban a kustomize egyszerűen erőforrások gyűjteménye (YAML fájlok, amelyek Kubernetes objektumokat határoznak meg: Telepítések, Szolgáltatások stb.), valamint az erőforrásokon végrehajtandó változtatásokra vonatkozó utasítások listája. Csakúgy, mint a make használja a benne található utasításkészletet Makefile, és a Docker az instrukciók alapján felépíti a tárolót Dockerfile, szabja testre a felhasználást kustomization.yaml utasítások tárolására arról, hogy a felhasználó milyen változtatásokat szeretne végrehajtani egy erőforráskészleten.

Itt van egy példafájl kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Nem próbálok meg beszélni a fájl összes lehetséges mezőjéről. kustomization.yaml (erről jól van írva itt), de röviden kifejtem egy konkrét példát:

• Mező resources jelzi, hogy a kustomize mit (mely erőforrásokat) fog megváltoztatni. Ebben az esetben az erőforrásokat a fájlokban keresi deployment.yaml и service.yaml a könyvtárában (szükség esetén megadhat teljes vagy relatív elérési utat).
• Mező namePrefix utasítja a kustomize-t egy bizonyos előtag hozzáadására (ebben az esetben - dev-) tulajdonítani name a területen meghatározott összes erőforrás resources. Így, ha a Telepítés rendelkezik name jelentéssel nginx-deployment, a testreszabással sikerülni fog dev-nginx-deployment.
• Mező namespace utasítja a kustomize-t, hogy adja hozzá a megadott névteret az összes erőforráshoz. Ebben az esetben a Telepítés és a Szolgáltatás a névtérbe kerül development.
• Végül a mező commonLabels címkekészletet tartalmaz, amely minden erőforráshoz hozzáadódik. Példánkban a kustomize címkét rendel az erőforrásokhoz a névvel environment és jelentése development.

Ha a felhasználó megteszi kustomize build . a fájllal rendelkező könyvtárban kustomization.yaml és a szükséges erőforrásokat (azaz fájlokat deployment.yaml и service.yaml), akkor a kimeneten egy szöveget kap a pontban megadott változtatásokkal kustomization.yaml.

Jegyzet. ford.: Illusztráció a projektdokumentációból a kustomize „egyszerű” használatáról

A kimenet átirányítható, ha változtatásokat kell végrehajtani:

kustomize build . > custom-config.yaml

A kimeneti adatok determinisztikusak (ugyanaz a bemeneti adat ugyanazt a kimeneti eredményt adja), így nem kell fájlba mentenie az eredményt. Ehelyett közvetlenül átadható egy másik parancsnak:

kustomize build . | kubectl apply -f -

A kustomize funkciók ezen keresztül is elérhetők kubectl -k (a Kubernetes 1.14-es verziója óta). Ne feledje azonban, hogy az önálló kustomize csomag gyorsabban frissül, mint az integrált kubectl csomag (legalábbis ez a helyzet a Kubernetes 1.15-ös kiadással).

Az olvasók feltehetik a kérdést: „Miért ez a bonyolultság, ha közvetlenül szerkesztheti a fájlokat?” Remek kérdés. A mi példánkban valóban tud fájlok módosítása deployment.yaml и service.yaml közvetlenül, de mi van akkor, ha valaki más projektjének villája? A fájlok közvetlen megváltoztatása megnehezíti (ha nem lehetetlen) az elágazás újraindítását, amikor az eredetet/forrást módosítják. A kustomize használata lehetővé teszi, hogy ezeket a változtatásokat egy fájlba központosítsa kustomization.yaml, érintetlenül hagyva az eredeti fájlokat, és így szükség esetén megkönnyítve az eredeti fájlok újrabázisát.

A kustomize előnyei bonyolultabb felhasználási esetekben válnak nyilvánvalóvá. A fenti példában kustomization.yaml és az erőforrások ugyanabban a könyvtárban vannak. A kustomize azonban támogatja azokat az eseteket, amikor létezik egy alapkonfiguráció és annak számos változata, más néven rátétek. Például egy felhasználó el akarta venni az általam példaként használt Deployment and Service for nginx-et, és létrehozni a fájlok fejlesztési, állomásoztatási és éles verzióit (vagy változatait). Ehhez szüksége lesz a fent említett átfedésekre, és valójában magukra az alapvető erőforrásokra.

Az átfedések és a mögöttes erőforrások ötletének illusztrálására (alapforrások), tegyük fel, hogy a könyvtárak szerkezete a következő:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Fájlban base/kustomization.yaml a mezőt használó felhasználók resources egyszerűen deklarálja azokat az erőforrásokat, amelyeket a kustomize-nak tartalmaznia kell.

Mindegyik fájlban overlays/{dev,staging,prod}/kustomization.yaml a felhasználók az alapkonfigurációra hivatkoznak a mezőben resources, majd jelezze a konkrét változtatásokat a következőhöz: adott környezet. Például fájl overlays/dev/kustomization.yaml így nézhet ki a korábban említett példa:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Ebben az esetben a fájl overlays/prod/kustomization.yaml teljesen más lehet:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Amikor a felhasználó fut kustomize build . a katalógusban overlays/dev, a kustomize generálja a fejlesztési lehetőséget. Ha futsz kustomize build . a katalógusban overlays/prod - megkapja a gyártási lehetőséget. És mindez - anélkül, hogy bármilyen változtatást végezne az eredetin (bázis) fájlokat, mindezt deklaratív és determinisztikus módon. Az alapkonfigurációt és az átfedő könyvtárakat közvetlenül a verziókezeléshez rendelheti, tudva, hogy ezek alapján a fájlok alapján bármikor reprodukálhatja a kívánt konfigurációt.

Jegyzet. ford.: Illusztráció a projektdokumentációból a overlayek használatáról a kustomize-ban

Testreszabható lehet több több, mint amit ebben a cikkben tárgyalunk. Remélem azonban jó bevezetőként szolgál.

További források

Sok jó cikk és publikáció található a kustomize-ről. Íme néhány, amit különösen hasznosnak találtam:

• Módosítsa az alap YAML-konfigurációt a különböző környezetekhez, prod/teszthez a Kustomize használatával;
• Kustomize – A sablonkészítés helyes módja a Kubernetesben;
• Kubernetes-objektumok deklaratív kezelése a testreszabással;
• Az Upstream Helm diagramok testreszabása a Customize segítségével.

Jegyzet. ford.: A következő néven közzétett hivatkozások blokkját is ajánlhatja Tudástár a segédprogram honlapján, majd egy videógyűjtemény a kustomize-ről szóló legfrissebb jelentésekkel.

Ha kérdése vagy javaslata van ennek az anyagnak a javítására, mindig nyitott vagyok a visszajelzésekre. Felveheti velem a kapcsolatot a címen Twitter vagy Kubernetes Slack csatorna. Jó szórakozást a manifesztek módosításához a kustomize segítségével!

PS a fordítótól

Olvassa el blogunkon is:

• «Eszközök Kubernetesen futó alkalmazások fejlesztői számára";
• «Kubernetes 1.14: a főbb újítások áttekintése";
• «Az amszterdami Helm Summit 2019 öt fő eredménye";
• «Gyakorlati bevezetés a Kubernetes - Helm csomagkezelőjébe".

Forrás: will.com