Stutt kynning á Kustomize

Athugið. þýð.: Greinin var skrifuð af Scott Lowe, verkfræðingi með mikla reynslu í upplýsingatækni, sem er höfundur/meðhöfundur sjö prentaðra bóka (aðallega á VMware vSphere). Hann vinnur nú fyrir VMware dótturfyrirtæki þess Heptio (keypt árið 2016), sem sérhæfir sig í skýjatölvu og Kubernetes. Textinn sjálfur þjónar sem hnitmiðuð og auðskiljanleg kynning á stillingarstjórnun fyrir Kubernetes með tækni Sérsníða, sem nýlega varð hluti af K8s.

Kustomize er tól sem gerir notendum kleift að „sníða einfaldar, sniðmátlausar YAML skrár í mismunandi tilgangi, þannig að upprunalega YAML sé ósnortið og nothæft“ (lýsing fengin að láni beint frá kustomize geymslu á GitHub). Kustomize er hægt að keyra beint eða, frá og með Kubernetes 1.14, nota kubectl -k til að fá aðgang að virkni þess (þó að frá og með Kubernetes 1.15 sé aðskilinn tvöfaldur nýrri en hæfileikarnir sem eru innbyggðir í kubectl). (Athugið. þýð.: Og með nýlegri útgáfu Kubernetes 1.16 sérsníða stutt af einnig í kubeadm tólinu.) Í þessari færslu vil ég kynna lesendum grunnatriði kustomize.

Í sínu einfaldasta formi/forriti er kustomize einfaldlega safn auðlinda (YAML skrár sem skilgreina Kubernetes hluti: Dreifingar, Þjónusta osfrv.) auk lista yfir leiðbeiningar um breytingar sem þarf að gera á þessum auðlindum. Rétt eins og gera notar leiðbeiningasettið sem er að finna í Makefile, og Docker byggir ílátið út frá leiðbeiningum frá Dockerfile, sérsníða notkun kustomization.yaml til að geyma leiðbeiningar um hvaða breytingar notandinn vill gera á tilföngum.

Hér er dæmi um skrá kustomization.yaml:

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

Ég ætla ekki að reyna að tala um alla mögulega reiti í skránni. kustomization.yaml (þetta er vel skrifað um hér), en ég mun gefa stutta skýringu á tilteknu dæmi:

• Field resources gefur til kynna hvað (hvaða auðlindir) kustomize mun breytast. Í þessu tilviki mun það leita að auðlindum í skrám deployment.yaml и service.yaml í möppunni þinni (þú getur tilgreint fulla eða hlutfallslega slóða ef þörf krefur).
• Field namePrefix skipar kustomize að bæta við ákveðnu forskeyti (í þessu tilfelli - dev-) að eigna name allar auðlindir sem eru skilgreindar á sviði resources. Þannig ef Deployment hefur name með merkingu nginx-deployment, sérsníða mun gera það dev-nginx-deployment.
• Field namespace skipar kustomize að bæta uppgefnu nafnrými við öll tilföng. Í þessu tilviki mun dreifing og þjónusta falla inn í nafnrýmið development.
• Loksins völlurinn commonLabels inniheldur sett af merkjum sem verður bætt við öll tilföng. Í dæminu okkar mun kustomize úthluta merki til auðlindanna með nafninu environment og merkingu development.

Ef notandinn gerir það kustomize build . í möppunni með skránni kustomization.yaml og nauðsynleg úrræði (þ.e. skrár deployment.yaml и service.yaml), þá mun það fá texta við úttakið með þeim breytingum sem tilgreindar eru í kustomization.yaml.

Athugið. þýð.: Myndskreyting úr verkefnisgögnum um „einfalda“ notkun kustomize

Hægt er að beina úttakinu ef gera þarf breytingar:

kustomize build . > custom-config.yaml

Úttaksgögnin eru ákveðin (sömu inntaksgögnin gefa sömu framleiðsluniðurstöður), svo þú þarft ekki að vista niðurstöðuna í skrá. Í staðinn er hægt að senda það beint í aðra skipun:

kustomize build . | kubectl apply -f -

Einnig er hægt að nálgast kustomize eiginleikana í gegnum kubectl -k (frá Kubernetes útgáfu 1.14). Hins vegar hafðu í huga að sjálfstæði kustomize pakkinn er uppfærður hraðar en samþætti kubectl pakkinn (að minnsta kosti er þetta raunin með Kubernetes 1.15 útgáfuna).

Lesendur gætu spurt: "Hvers vegna allt þetta flókið ef þú getur breytt skrám beint?" Frábær spurning. Í okkar dæmi, reyndar maður getur breyta skrám deployment.yaml и service.yaml beint, en hvað ef þeir eru gaffal af verkefni einhvers annars? Að breyta skrám beint gerir það erfitt (ef ekki ómögulegt) að endurskipuleggja gaffal þegar breytingar eru gerðar á uppruna/uppsprettu. Notkun kustomize gerir þér kleift að miðstýra þessum breytingum í skrá kustomization.yaml, skilja upprunalegu skrárnar eftir óbreyttar og þannig auðveldara að endurbæta upprunalegu skrárnar ef þörf krefur.

Ávinningurinn af kustomize kemur í ljós í flóknari notkunartilfellum. Í dæminu hér að ofan kustomization.yaml og auðlindirnar eru í sömu möppu. Hins vegar styður kustomize notkunartilvik þar sem grunnstilling er til og mörg afbrigði af henni, einnig þekkt sem yfirlag. Til dæmis vildi notandi taka Deployment and Service fyrir nginx, sem ég notaði sem dæmi, og búa til þróunar-, sviðsetningar- og framleiðsluútgáfur (eða afbrigði) af þessum skrám. Til þess þarf hann ofangreindar yfirlögn og í raun grunnúrræðin sjálf.

Til að sýna hugmyndina um yfirborð og undirliggjandi auðlindir (grunnauðlindir), gerum ráð fyrir að möppurnar hafi eftirfarandi uppbyggingu:

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

Í skrá base/kustomization.yaml notendur sem nota svæðið resources einfaldlega lýsa yfir auðlindunum sem kustomize ætti að innihalda.

Í hverri skrá overlays/{dev,staging,prod}/kustomization.yaml notendur vísa til grunnstillingar í reitnum resources, og tilgreindu síðan sérstakar breytingar fyrir gefnu umhverfi. Til dæmis, skrá overlays/dev/kustomization.yaml gæti litið út eins og dæmið sem gefið var áðan:

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

Í þessu tilviki skráin overlays/prod/kustomization.yaml gæti verið allt öðruvísi:

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

Þegar notandinn keyrir kustomize build . í vörulistanum overlays/dev, kustomize mun búa til þróunarmöguleikann. Ef þú hleypur kustomize build . í vörulistanum overlays/prod - þú færð framleiðslumöguleikann. Og allt þetta - án þess að gera nokkrar breytingar á frumritinu (grunnur) skrár, allt á yfirlýsandi og ákveðinn hátt. Þú getur skuldbundið grunnstillingar og yfirlagsmöppur beint til útgáfustýringar, vitandi að miðað við þessar skrár geturðu endurskapað viðeigandi stillingar hvenær sem er.

Athugið. þýð.: Myndskreyting úr verkefnisgögnum um notkun yfirborðs í kustomize

Sérsníða dós mikið meira en það sem fjallað er um í þessari grein. Hins vegar vona ég að það verði góð kynning.

Viðbótarauðlindir

Það eru margar góðar greinar og rit um kustomize. Hér eru nokkrar sem mér fannst sérstaklega gagnlegar:

• Breyttu grunn YAML stillingum fyrir mismunandi umhverfi framleiða/prófa með Kustomize;
• Kustomize - Rétta leiðin til að gera sniðmát í Kubernetes;
• Yfirlýsingastjórnun á Kubernetes hlutum með því að nota Customize;
• Sérsníða Upstream Helm Charts með Customize.

Athugið. þýð.: Þú getur líka mælt með blokk af tenglum sem birtar eru sem Resources á vefsíðu veitunnar, fylgt eftir með safni myndbanda með nýjustu skýrslum um kustomize.

Ef þú hefur spurningar eða tillögur til að bæta þetta efni, er ég alltaf opinn fyrir endurgjöf. Þú getur haft samband við mig á twitter eða Kubernetes Slack rás. Skemmtu þér við að breyta birtingarmyndum þínum með kustomize!

PS frá þýðanda

Lestu líka á blogginu okkar:

• «Verkfæri fyrir forritara forrita sem keyra á Kubernetes»;
• «Kubernetes 1.14: Hápunktar þess sem er nýtt»;
• «Fimm helstu niðurstöður Helm Summit 2019 í Amsterdam»;
• «Hagnýt kynning á pakkastjóranum fyrir Kubernetes - Helm'.

Heimild: www.habr.com