In koarte ynlieding foar Kustomize

Noat. transl.: It artikel is skreaun troch Scott Lowe, in yngenieur mei wiidweidige ûnderfining yn IT, wa is de skriuwer / co-auteur fan sân printe boeken (benammen op VMware vSphere). Hy wurket no foar har VMware-dochterûndernimming Heptio (oankocht yn 2016), spesjalisearre yn cloud computing en Kubernetes. De tekst sels tsjinnet as in koarte en maklik te begripen ynlieding foar konfiguraasjebehear foar Kubernetes mei technology Oanpasse, dy't koartlyn diel útmakke fan K8s.

Kustomize is in ark wêrmei brûkers "ienfâldige, sjabloanfrije YAML-bestannen kinne oanpasse foar ferskate doelen, wêrtroch it orizjinele YAML yntakt en brûkber bliuwt" (beskriuwing direkt liend fan kustomisearje repository op GitHub). Kustomize kin direkt wurde útfierd of, as fan Kubernetes 1.14, brûkt kubectl -k om tagong te krijen ta syn funksjonaliteit (hoewol as fan Kubernetes 1.15, de aparte binary is nijer as de mooglikheden ynboud yn kubectl). (Noat. transl.: En mei de resinte release Kubernetes 1.16 oanpasse stipe troch ek yn it kubeadm-hulpprogramma.) Yn dizze post wol ik lêzers yntrodusearje oan de basis fan kustomize.

Yn syn ienfâldichste foarm/applikaasje is kustomize gewoan in samling boarnen (YAML-bestannen dy't Kubernetes-objekten definiearje: Deployments, Tsjinsten, ensfh.) Plus in list mei ynstruksjes foar feroarings dy't moatte wurde makke oan dy boarnen. Krekt as meitsje brûkt de ynstruksjeset befette yn Makefile, en Docker bout de kontener basearre op ynstruksjes fan Dockerfile, gebrûk oanpasse kustomization.yaml om ynstruksjes op te slaan oer hokker feroarings de brûker wol meitsje oan in set fan boarnen.

Hjir is in foarbyldbestân kustomization.yaml:

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

Ik sil net besykje te praten oer alle mooglike fjilden yn it bestân. kustomization.yaml (dit is goed skreaun oer hjir), mar ik sil in koarte útlis jaan fan in spesifyk foarbyld:

• fjild resources jout oan wat (hokker middels) kustomize sil feroarje. Yn dit gefal sil it sykje nei boarnen yn bestannen deployment.yaml и service.yaml yn jo map (jo kinne folsleine of relative paden opjaan as it nedich is).
• fjild namePrefix ynstruearret kustomize om in bepaald foarheaksel ta te foegjen (yn dit gefal - dev-) taskriuwe name alle boarnen definiearre yn it fjild resources. Sa, as Deployment hat name mei de betsjutting nginx-deployment, oanpasse sil it meitsje dev-nginx-deployment.
• fjild namespace opdracht kustomize om de opjûne nammeromte ta te foegjen oan alle boarnen. Yn dit gefal sil Ynset en tsjinst yn 'e nammeromte falle development.
• As lêste, it fjild commonLabels befettet in set fan labels dy't sille wurde tafoege oan alle boarnen. Yn ús foarbyld sil kustomize in label tawize oan de boarnen mei de namme environment en betsjutting development.

As de brûker docht kustomize build . yn de map mei de triem kustomization.yaml en de nedige boarnen (d.w.s. bestannen deployment.yaml и service.yaml), dan sil it by de útfier in tekst ûntfange mei de wizigingen spesifisearre yn kustomization.yaml.

Noat. transl.: Yllustraasje út de projektdokumintaasje oer it "ienfâldige" gebrûk fan kustomize

De útfier kin omlaat wurde as wizigingen moatte wurde ynset:

kustomize build . > custom-config.yaml

De útfiergegevens binne deterministysk (deselde ynfiergegevens sille deselde útfierresultaten produsearje), sadat jo it resultaat net hoege te bewarjen yn in bestân. Ynstee dêrfan kin it direkt nei in oar kommando trochjûn wurde:

kustomize build . | kubectl apply -f -

De kustomize-funksjes kinne ek tagonklik wurde fia kubectl -k (sûnt Kubernetes ferzje 1.14). Hâld lykwols yn gedachten dat it standalone kustomize-pakket rapper wurdt bywurke as it yntegreare kubectl-pakket (teminsten is dit it gefal mei de Kubernetes 1.15-release).

Lêzers kinne freegje: "Wêrom al dizze kompleksiteit as jo de bestannen direkt kinne bewurkje?" Geweldige fraach. Yn ús foarbyld, yndied kin wizigje triemmen deployment.yaml и service.yaml direkt, mar wat as se binne in foarke fan in oar syn projekt? It wizigjen fan bestannen direkt makket it lestich (as net ûnmooglik) om in foarke te rebasearjen as feroarings wurde makke oan 'e oarsprong / boarne. It brûken fan kustomize lit jo dizze wizigingen sintralisearje yn in bestân kustomization.yaml, de orizjinele bestannen yntakt te litten en sadwaande it makliker meitsje om de orizjinele bestannen as nedich te rebasearjen.

De foardielen fan kustomize wurde dúdlik yn mear komplekse gebrûksgefallen. Yn it boppesteande foarbyld kustomization.yaml en de boarnen binne yn deselde map. Kustomize stipet lykwols gebrûk fan gefallen wêr't in basiskonfiguraasje is en in protte farianten dêrfan, ek wol bekend as overlays. Bygelyks, in brûker woe Deployment and Service nimme foar nginx, dat ik brûkte as foarbyld, en meitsje ûntwikkeling, staging en produksje ferzjes (as farianten) fan dy triemmen. Om dit te dwaan, sil hy de boppeneamde overlays nedich hawwe en, yn feite, de basisboarnen sels.

Om it idee fan overlays en ûnderlizzende boarnen te yllustrearjen (basis boarnen), lit ús oannimme dat de mappen de folgjende struktuer hawwe:

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

Yn triem base/kustomization.yaml brûkers mei help fan it fjild resources gewoan ferklearje de middels dy't kustomize moatte befetsje.

Yn elk fan de triemmen overlays/{dev,staging,prod}/kustomization.yaml brûkers ferwize nei de basis konfiguraasje yn it fjild resources, en dan oanjaan spesifike feroarings foar jûn omjouwing. Bygelyks, triem overlays/dev/kustomization.yaml kin lykje op it earder jûn foarbyld:

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

Yn dit gefal de triem overlays/prod/kustomization.yaml kin folslein oars:

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

As de brûker rint kustomize build . yn 'e katalogus overlays/dev, kustomize sil generearje de ûntwikkeling opsje. As jo ​​rinne kustomize build . yn 'e katalogus overlays/prod - jo krije de produksjeopsje. En dit alles - sûnder feroaringen oan it orizjineel te meitsjen (basis) bestannen, allegear op in deklarative en deterministyske manier. Jo kinne de basiskonfiguraasje- en overlay-mappen direkt ynsette foar ferzjekontrôle, wittende dat jo op basis fan dizze bestannen op elk momint de winske konfiguraasje kinne reprodusearje.

Noat. transl.: Yllustraasje út it projekt dokumintaasje op it brûken fan overlays yn kustomize

Oanpasse kin folle mear dan wat wurdt behannele yn dit artikel. Ik hoopje lykwols dat it tsjinnet as in goede ynlieding.

Oanfoljende boarnen

D'r binne in protte goede artikels en publikaasjes oer kustomize. Hjir binne in pear dy't ik benammen nuttich fûn:

• Feroarje basis YAML-konfiguraasje foar ferskate omjouwings prod / test mei Kustomize;
• Kustomize - De juste manier om sjabloanen te dwaan yn Kubernetes;
• Declarative Management of Kubernetes Objects Using Customize;
• Oanpasse Upstream Helm Charts mei Customize.

Noat. transl.: Jo kinne ek oanbefelje in blok fan keppelings publisearre as Resources op de webside fan it nut, folge troch in samling fideo's mei de lêste rapporten oer kustomize.

As jo ​​fragen of suggestjes hawwe foar it ferbetterjen fan dit materiaal, bin ik altyd iepen foar feedback. Jo kinne kontakt mei my op Twitter of Kubernetes Slack kanaal. Have fun mei it wizigjen fan jo manifesten mei kustomize!

PS fan oersetter

Lês ek op ús blog:

• «Ark foar ûntwikkelders fan applikaasjes dy't rinne op Kubernetes";
• «Kubernetes 1.14: oersjoch fan 'e wichtichste ynnovaasjes";
• «Fiif haadresultaten fan Helm Summit 2019 yn Amsterdam";
• «Praktyske ynlieding ta de pakketbehearder foar Kubernetes - Helm".

Boarne: www.habr.com