🥇Rövid bevezetés a Kustomize-ba

Megjegyzés fordítás.: A cikket Scott Lowe írta — tapasztalt IT mérnök, aki hét nyomtatott könyv (főként a VMware vSphere-ről) szerzője vagy társszerzője. Jelenleg a VMware leányvállalatánál, a Heptiónál (2016-ban megszerezték) dolgozik, amely a felhőalapú számítástechnikára és a Kubernetes-re specializálódott. Maga a szöveg tömör és könnyen érthető bevezető a Kubernetes konfigurációkezelésébe a Kustomize technológián keresztül. Kustomize, amely nemrégiben került a K8s részeként.

A Kustomize egy eszköz, amely lehetővé teszi a felhasználók számára, hogy "egyszerű, sablonoktól mentes YAML fájlokat konfiguráljanak különféle célokra, miközben az eredeti YAML érintetlen és felhasználható marad" (a leírás közvetlenül a kustomize GitHub tárolójából származik.) A Kustomize közvetlenül futtatható, vagy a Kubernetes 1.14-től kezdve a kubectl -k parancsot használva a funkcióinak elérésére (bár a Kubernetes 1.15 állapotában egy külön bináris frissebb, mint a kubectl beépített funkciói). (Megjegyzés fordítás.: A legfrissebb kiadással Kubernetes 1.16 kustomize támogatott a kubeadm eszközben is.) Ebben a publikációban szeretném megismertetni az olvasókat a kustomize alapjaival.

Legsimplebb formájában a kustomize egyszerűen egy erőforrásegyüttes (YAML fájlok, amelyek Kubernetes objektumokat definiálnak: Bevezetések, Szolgáltatások, stb.) és egy változtatási utasítások listája, amelyet ezekhez az erőforrásokhoz kell alkalmazni. Hasonlóan ahhoz, ahogyan a make egy utasításkészletet használ, ami található a Makefile, míg a Docker egy alkalmazást készít a Dockerfileutasításai alapján, a kustomize a kustomization.yaml fájlt használja a felhasználó által kívánt változtatások meghatározására az erőforrásegyütteshez.

Íme egy példa fájlra kustomization.yaml:

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

Nem fogom megpróbálni elmesélni az összes lehetséges mezőt a fájlban kustomization.yaml (erről jól írtak itt), de egy rövid magyarázatot adok egy konkrét példáról:

Mező resources megmutatja, hogy (mely erőforrásokat) fogja módosítani a kustomize. Ebben az esetben az erőforrásokat a deployment.yaml és service.yaml fájlokban keresi a saját könyvtárában (szükség esetén teljes vagy relatív útvonalakat is megadhat).
Mező namePrefix előírja a kustomize-nak, hogy hozzáadjon egy adott előtagot (ebben az esetben — dev-) az összes erőforrás névattribútumához, amelyeket a name mező határoz meg. resourcesÍgy, ha a Deployment-ben van name az értékkel nginx-deployment, a kustomize-ból dev-nginx-deployment lesz..
Mező namespace előírja a kustomize-nak, hogy minden erőforráshoz hozzáadja a megadott névtér. Ebben az esetben a Deployment és a Service a névtérbe fog kerülni fejlesztés.
Végül a mező commonLabels tartalmaz egy halmaz címkét, amelyet minden erőforráshoz hozzáadnak. Példánkban a kustomize címkét fog hozzárendelni az erőforrásokhoz e névvel környezet és az értékkel fejlesztés.

Ha a felhasználó futtatja a kustomize build . a fájlnak megfelelő mappában kustomization.yaml és a szükséges erőforrásokkal (azaz a fájlokkal deployment.yaml és service.yaml), akkor a kimenetet a módosításokkal fogja megkapni, amelyeket a kustomization.yaml.

Megjegyzés fordítás.: A kustomize "egyszerű" használatáról szóló projekt dokumentációjának ábrája

A kimenet átirányítható, ha szükséges rögzíteni a módosításokat:

kustomize build . > custom-config.yaml

A kimenet determinisztikus (ugyanazon bemeneti adatok esetén ugyanazokat az eredményeket kapjuk kimenetként), ezért nem szükséges az eredményt fájlba menteni. Ehelyett azonnal átadhatja egy másik parancsnak:

kustomize build . | kubectl apply -f -

A kustomize funkcióihoz hozzáférhet a kubectl -k (a Kubernetes 1.14-es verziójától kezdve). De vegye figyelembe, hogy a külön csomagként a kustomize gyorsabban frissül, mint a kubectl-be integrálva (legalábbis a Kubernetes 1.15 kiadásának esetében így van).

Olvasók kérdezhetik: „Miért van szükség ezekre a bonyodalmakra, ha közvetlenül is módosíthatom a fájlokat?“. Remek kérdés. Példánkban valóban lehetővé teszi a fájlokat deployment.yaml és service.yaml közvetlenül módosítani, de mi van, ha ezek valakinek a projektjének a forkjai? A fájlok közvetlen módosítása megnehezíti (ha nem lehetetlenné teszi) a fork rebaselését, amikor a forráson változások történnek. A kustomize használata lehetővé teszi, hogy ezeket a változásokat egy fájlban centralizáljuk kustomization.yaml, a meglévő fájlokat érintetlenül hagyva, így megkönnyítve a forrásfájlok rebaselését, ha szükséges.

A kustomize előnyei a bonyolultabb felhasználási esetekben válnak nyilvánvalóvá. A fent említett példában kustomization.yaml és az erőforrások ugyanabban a mappában találhatók. A kustomize azonban támogatja azokat a használati forgatókönyveket, ahol van egy alap konfiguráció és annak számos változata, más néven overlays. Például a felhasználó meg akarta venni a Deployment és a Service szolgáltatásokat az nginx-hez, amelyeket példaként használtam, és létrehozni a fejlesztési-, staging- és production-verziókat (vagy variációkat) azokból a fájlokból. Ehhez szüksége lesz a fent említett overlays-ra és magukra az alapvető erőforrásokra.

Az overlays és az alapvető erőforrások ötletének illusztrálásához (alapvető erőforrások), tegyük fel, hogy a könyvtárak a következő struktúrával rendelkeznek:

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

A fájlban base/kustomization.yaml a felhasználók a mező segítségével resources egyszerűen bejelentik azokat az erőforrásokat, amelyeket a kustomize-nak tartalmaznia kell.

Minden egyes fájlban overlays/{dev,staging,prod}/kustomization.yaml a felhasználók hivatkoznak az alap konfigurációra a mezőben resources, majd konkrét változtatásokat jeleznek az adott környezetre. Például a fájl overlays/dev/kustomization.yaml így nézhet ki, mint az előző példa:

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

Ezért 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ó elindítja kustomize build . a könyvtárban overlays/dev, a kustomize generálni fog egy development változatot. Ha elindítja kustomize build . a könyvtárban overlays/prod — akkor pedig production változatot kap. Ráadásul mindez — anélkül, hogy bármilyen módosítást végeznének az eredeti (alap) fájlokon, és mindez — deklaratív és determinisztikus módon. Az alap konfigurációt és az overlay könyvtárakat közvetlenül a verziókezelő rendszerbe lehet kötelezni, tudva, hogy ezekből a fájlokból bármikor reprodukálható a szükséges konfiguráció.

Megjegyzés fordítás.: Illusztráció a kustomize overlays használatáról szóló projekt dokumentációjából

A Kustomize sokkal többre képes, mint amit ebben a cikkben elmondtunk. Remélem, hogy ez jó bevezetésként szolgál. További erőforrások

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

Change base YAML config for different environments prod/test using Kustomize

Megjegyzés fordítás.az eszköz oldalán, és az azt követő videógyűjteményt az utolsó kustomize előadásokról. Erőforrások Ha kérdéseid vagy javaslataid vannak ezen anyag javítására, mindig nyitott vagyok a visszajelzésekre. Kapcsolatba léphetsz velem a

Twitteren vagy a Kubernetes Slack-csatornáján. Élvezd a manifesztjeid módosítását a kustomize segítségével!P.S. a fordítótól

Fejlesztési eszközök, amelyek Kubernetesben futnak

Olvasson további információkat a blogunkban:

Forrás: habr.com