Trumpas Kustomize įvadas

Pastaba. vert.: Straipsnį parašė Scott Lowe, inžinierius, turintis didelę IT patirtį, kuris yra septynių spausdintų knygų (daugiausia apie VMware vSphere) autorius / bendraautoris. Dabar jis dirba jos VMware dukterinėje įmonėje Heptio (įsigytas 2016 m.), kurios specializacija yra debesų kompiuterija ir Kubernetes. Pats tekstas yra glausta ir lengvai suprantama įvadas į Kubernetes konfigūracijos valdymą naudojant technologiją Pritaikyti, kuris neseniai tapo K8s dalimi.

Kustomize yra įrankis, leidžiantis vartotojams „pritaikyti paprastus, be šablonų YAML failus įvairiems tikslams, paliekant originalų YAML nepažeistą ir tinkantį naudoti“ (aprašymas pasiskolintas tiesiogiai iš „kustomize“ saugykla „GitHub“.). Kustomize galima paleisti tiesiogiai arba naudoti, pradedant Kubernetes 1.14 kubectl -k pasiekti jo funkcionalumą (nors nuo Kubernetes 1.15 atskiras dvejetainis failas yra naujesnis nei kubectl įtaisytos galimybės). (Pastaba. vert.: Ir su naujausiu leidimu Kubernetas 1.16 pritaikyti remia taip pat kubeadm programoje.) Šiame įraše noriu supažindinti skaitytojus su kustomize pagrindais.

Paprasčiausia forma / programa „kustomize“ yra tiesiog išteklių rinkinys (YAML failai, apibrėžiantys „Kubernetes“ objektus: diegimai, paslaugos ir kt.) ir nurodymų, kaip atlikti šiuos išteklius pakeitimus, sąrašas. Kaip ir make naudoja instrukcijų rinkinį, esantį Makefile, o „Docker“ sukuria konteinerį pagal instrukcijas iš Dockerfile, pritaikyti naudojimui kustomization.yaml saugoti instrukcijas apie tai, kokius pakeitimus vartotojas nori atlikti išteklių rinkinyje.

Čia yra failo pavyzdys kustomization.yaml:

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

Nemėginsiu kalbėti apie visus galimus failo laukus. kustomization.yaml (apie tai gerai parašyta čia), bet trumpai paaiškinsiu konkretų pavyzdį:

• Laukas resources nurodo, ką (kurie ištekliai) kustomize pakeis. Tokiu atveju jis ieškos išteklių failuose deployment.yaml и service.yaml savo kataloge (jei reikia, galite nurodyti visus arba santykinius kelius).
• Laukas namePrefix nurodo kustomize pridėti tam tikrą priešdėlį (šiuo atveju - dev-) priskirti name visi lauke apibrėžti ištekliai resources. Taigi, jei diegimas turi name su prasme nginx-deployment, pritaikyti pavyks dev-nginx-deployment.
• Laukas namespace nurodo kustomize pridėti nurodytą vardų erdvę prie visų išteklių. Tokiu atveju diegimas ir aptarnavimas pateks į vardų erdvę development.
• Galiausiai laukas commonLabels yra etikečių rinkinys, kuris bus pridėtas prie visų išteklių. Mūsų pavyzdyje kustomize ištekliams priskirs etiketę su pavadinimu environment ir prasmė development.

Jei vartotojas tai daro kustomize build . kataloge su failu kustomization.yaml ir reikiamus išteklius (pvz., failus deployment.yaml и service.yaml), tada išvestyje jis gaus tekstą su nurodytais pakeitimais kustomization.yaml.

Pastaba. vert.: Iliustracija iš projekto dokumentacijos apie „paprastą“ kustomize naudojimą

Išvestis gali būti nukreipta, jei reikia atlikti pakeitimus:

kustomize build . > custom-config.yaml

Išvesties duomenys yra deterministiniai (tie patys įvesties duomenys duos tuos pačius išvesties rezultatus), todėl jums nereikia įrašyti rezultato į failą. Vietoj to, jis gali būti tiesiogiai perduodamas kitai komandai:

kustomize build . | kubectl apply -f -

Kustomize funkcijas taip pat galima pasiekti per kubectl -k (nuo Kubernetes 1.14 versijos). Tačiau atminkite, kad atskiras „kustomize“ paketas atnaujinamas greičiau nei integruotas „kubectl“ paketas (bent jau taip yra „Kubernetes 1.15“ leidimo atveju).

Skaitytojai gali paklausti: „Kodėl toks sudėtingumas, jei failus galima redaguoti tiesiogiai? Puikus klausimas. Mūsų pavyzdyje tikrai vienas gali keisti failus deployment.yaml и service.yaml tiesiogiai, bet ką daryti, jei jie yra kažkieno projekto šakutė? Tiesiogiai pakeitus failus tampa sunku (jei ne neįmanoma) iš naujo nustatyti šakę, kai atliekami kilmės / šaltinio pakeitimai. Naudodami „kustomize“ galite centralizuoti šiuos pakeitimus faile kustomization.yaml, palikdami originalius failus nepažeistus ir taip palengvindami, jei reikia, pakeisti pradinius failus.

Kustomize pranašumai išryškėja sudėtingesniais naudojimo atvejais. Aukščiau pateiktame pavyzdyje kustomization.yaml ir ištekliai yra tame pačiame kataloge. Tačiau „kustomize“ palaiko naudojimo atvejus, kai yra pagrindinė konfigūracija ir daug jos variantų, taip pat žinomų kaip Perdangos. Pavyzdžiui, vartotojas norėjo paimti Deployment and Service for nginx, kurį naudojau kaip pavyzdį, ir sukurti tų failų kūrimo, sustojimo ir gamybos versijas (arba variantus). Tam jam reikės minėtų perdangų ir, tiesą sakant, pačių pagrindinių išteklių.

Iliustruoti perdangų ir pagrindinių išteklių idėją (baziniai ištekliai), tarkime, kad katalogai turi tokią struktūrą:

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

Byloje base/kustomization.yaml lauką naudojantys vartotojai resources tiesiog deklaruokite išteklius, kuriuos turėtų apimti kustomize.

Kiekviename faile overlays/{dev,staging,prod}/kustomization.yaml vartotojai nurodo pagrindinę konfigūraciją lauke resources, tada nurodykite konkrečius pakeitimus duota aplinka. Pavyzdžiui, failas overlays/dev/kustomization.yaml gali atrodyti kaip anksčiau pateiktas pavyzdys:

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

Šiuo atveju failas overlays/prod/kustomization.yaml gali būti visiškai kitoks:

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

Kai vartotojas veikia kustomize build . kataloge overlays/dev, kustomize sukurs kūrimo parinktį. Jei bėgate kustomize build . kataloge overlays/prod - gausite gamybos variantą. Ir visa tai – neatliekant jokių originalo pakeitimų (bazė) bylas – deklaratyviu ir deterministiniu būdu. Bazinę konfigūraciją ir persidengiančius katalogus galite tiesiogiai priskirti versijos valdymui, žinodami, kad remdamiesi šiais failais galite bet kada atkurti norimą konfigūraciją.

Pastaba. vert.: Iliustracija iš projekto dokumentacijos apie perdangų naudojimą „kustomize“.

Tinkinti gali daug daugiau nei aprašyta šiame straipsnyje. Tačiau tikiuosi, kad tai bus gera įžanga.

Papildomi resursai

Yra daug gerų straipsnių ir publikacijų apie kustomize. Štai keletas, kurie man pasirodė ypač naudingi:

• Pakeiskite pagrindinę YAML konfigūraciją skirtingoms aplinkoms prod / test naudodami Kustomize;
• Kustomize – teisingas būdas kurti šablonus „Kubernetes“.;
• Deklaratyvus „Kubernetes“ objektų valdymas naudojant „Customize“.;
• Prieš srovę esančių vairo diagramų pritaikymas naudojant „Customize“..

Pastaba. vert.: Taip pat galite rekomenduoti nuorodų bloką, paskelbtą kaip Ištekliai komunalinės paslaugos svetainėje, o po to pateikiamas vaizdo įrašų rinkinys su naujausiomis ataskaitomis apie kustomize.

Jei turite klausimų ar pasiūlymų, kaip patobulinti šią medžiagą, visada laukiu atsiliepimų. Su manimi galite susisiekti adresu Twitter arba Kubernetes Slack kanalas. Smagiai keiskite savo manifestus su kustomize!

PS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

• «Įrankiai, skirti programų, veikiančių Kubernetes, kūrėjams»;
• «Kubernetes 1.14: pagrindinių naujovių apžvalga»;
• «Penki pagrindiniai Helm Summit 2019 Amsterdame rezultatai»;
• «Praktinis įvadas į Kubernetes paketų tvarkyklę – Helm".

Šaltinis: www.habr.com