Lühiline sissejuhatus Kustomize'i

Märk. tõlge.: Artikli autor on Scott Lowe — IT valdkonna kogenud insener ja seitsme trükise autori/kaasautori (peamiselt VMware vSphere'i kohta) autor. Praegu töötab ta VMware'i tütarettevõttes Heptio (osta 2016. aastal), keskendudes pilvandmetöötlusele ja Kubernetes'ile. Artikli eesmärk on pakkuda lühikest ja arusaadavat sissejuhatust Kubernetes'e konfiguratsioonide haldamiseks Kustomize'i abil Kustomize, mis on hiljuti saanud osaks K8s-ist.

Kustomize on tööriist, mis võimaldab kasutajatel "kohandada lihtsaid ja šabloonidest vabasid YAML faile erinevateks eesmärkideks, jättes originaalse YAML puutumatuks ja kasutusvalmis" (kirjeldus on võetud otse kustomize'i GitHub'i repositooriumist). Kustomize'i saab kasutada otse või alates Kubernetes 1.14-st kasutada kubectl -k selle funktsioonidele juurdepääsuks (kuigi Kubernetes 1.15 puhul on eraldi binaar uusim, kui kubectl'i sisseehitatud funktsioonid). (Märk. tõlge.: Ja koos hiljutise väljaandega Kubernetes 1.16 kustomize toetatakse ka kubeadm tööriistas.) Selles postituses tutvustan lugejatele kustomize'i aluseid.

Kustimisel on kustomize oma kõige lihtsamas vormis lihtsalt hulk ressursse (YAML-failid, mis määratlevad Kubernetes'i objekte: Deployments, Services jne) pluss loetelu muudatustest, mida tuleb nende ressursside osas teha. Nagu make kasutab kogumit juhiseid, mis on. Makefile, ja Docker kogub konteineri vastavalt juhistele. Dockerfile, kasutab kustomize. kustomization.yaml et salvestada ettekirjutused selle kohta, milliseid muudatusi kasutaja soovib ressursside kogusse teha.

Siin on näide failist. kustomization.yaml:

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

Ma ei hakka proovima rääkida kõigist võimalikest väljadest failis. kustomization.yaml (sellest on hästi kirjutatud. siit), kuid annan lühikese selgituse konkreetse näite kohta:

• Väli resources osutab sellele, milliseid ressursse kustomize muudab. Antud juhul otsib ta ressursse failidest. deployment.yaml ja service.yaml oma kataloogis (vajadusel võib kasutada täis- või suhtelisi teid).
• Väli namePrefix määrab kustomize'ile, et ta lisab teatud prefiksi (antud juhul - dev-) kõikide ressursside atribuudile, mis on määratletud. name . Nii et kui Deployment'is on. resourcesnginx-deployment name väärtusega , teeb kustomize sellest.dev-nginx-deployment dev-nginx-deployment.
• Väli namespace kustomize nõuab antud nimelise ruumi lisamist kõigile ressurssidele. Antud juhul kuuluvad Deployment ja Service määratud ruumi. arendus.
• Lõpuks, väli commonLabels sisaldab komplekti silte, mis lisatakse kõigile ressurssidele. Meie näites määrab kustomize ressurssidele sildi nimega environment ja väärtusega arendus.

Kui kasutaja käivitab kustomize build . kaustas, kus on fail kustomization.yaml ja vajalikud ressursid (st failid deployment.yaml ja service.yaml), siis saab ta väljundina teksti muudatustega, mis on määratletud kustomization.yaml.

Märk. tõlge.: Illustratsioon projekti dokumentatsioonist kustomize "lihtsa" kasutamise kohta.

Väljundit saab suunata, kui on vajalik muudatused fikseerida:

kustomize build . > custom-config.yaml

Väljund on deterministlik (samade sisenditega saadakse sama väljund), seega ei pea tulemust faili salvestama. Selle asemel saab selle kohe edastada teisele käsule:

kustomize build . | kubectl apply -f -

Kaccess kustomize funktsioonidele on samuti võimalik läbi kubectl -k (alates Kubernetes 1.14 versioonist). Siiski, pidage meeles, et eraldi kustomize paketti uuendatakse kiiremini kui kubectl integreeritud versiooni (vähemalt tundub niimoodi Kubernetes 1.15 väljaandega).

Lugejad võivad küsida: „Miks peaks siis kõik need keerukused olema, kui faile saab otse redigeerida?”. Väga hea küsimus. Meie näites on tõepoolest võimalik saab faile deployment.yaml ja service.yaml otse redigeerida, kuid mis juhtub, kui need on kellegi projekti fork? Failide otse muutmine raskendab (või isegi muudab võimatuks) fork'i rebase'ida, kui allikas muudatusi teeb. Kustomize'i kasutamine võimaldab keskendada need muudatused faili kustomization.yaml, jättes originaalfailid puutumatuks ja seeläbi kergendades vajadusel originaalfailide rebase'imist.

Kustomize'i eelised muutuvad ilmseks keerulisemates kasutusjuhtumites. Ülaltoodud näites kustomization.yaml ja ressursid on samas kaustas. Kuid kustomize toetab kasutusstsenaariume, kus on põhikonfiguratsioon ja palju selle variante, mida tuntakse ka kui overlays. Näiteks soovis kasutaja võtta Deployment'i ja Service'i nginx'i jaoks, mida kasutasin näitena, ning luua nende failide development-, staging- ja production-versioonid (või variandid). Selleks vajab ta ülalmainitud overlays'i ja tegelikult ka põhialuseks olevad ressursid.

Illustreerimaks overlayde ja põhivara mõistet (põhivara), oletame, et direktoritel on järgmine struktuur:

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

Failis base/kustomization.yaml kasutajad, kasutades väljast resources lihtsalt deklareerida ressursid, mida kustomize peaks sisaldama.

Igas failis overlays/{dev,staging,prod}/kustomization.yaml kasutajad viitavad põhikonfiguratsioonile väljas resources, ning seejärel määravad konkreetseid muudatusi antud keskkonnale. Näiteks, fail overlays/dev/kustomization.yaml võib välja näha nagu eelnevalt toodud näide:

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

Samas, fail overlays/prod/kustomization.yaml võib olla täiesti erinev:

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

Kui kasutaja käivitab kustomize build . kaustas overlays/dev, kustomize genereerib arenduse variandi. Kui aga käivitada kustomize build . kaustas overlays/prod — saadakse tootmisvariant. Ja kõik see — ilma algsetesse (põhivara) muudatusteta. failid, ja kõik see - deklaratiivsel ja deterministlikul viisil. Aluskonfiguratsiooni ja overlay kaustasid saab otse versioonihaldussüsteemi kommitida, teades, et nende failide põhjal saab igal hetkel taastada soovitud konfiguratsiooni.

Märk. tõlge.: Illustratsioon projekti dokumentatsioonist overlays kasutamisest kustomizes

Kustomize oskab kaugelt rohkem, kui selles artiklis rääkida. Loodetavasti on see hea sissejuhatus.

Lisavahendid

On palju häid artikleid ja publikatsioone kustomize kohta. Siin on mõned, mida pean eriti kasulikuks:

• Muuda baas YAML konfiguratsiooni erinevate keskkondade prod/test jaoks kasutades Kustomize'i;
• Kustomize - õige viis templaatide tegemiseks Kuberneteses;
• Kubernetes objektide deklaratiivne haldamine Kustomize'i abil;
• Ülesvoolu Helm graafikute kohandamine Kustomize'iga.

Märk. tõlge.: Samuti võib soovitada linkide plokki, mis on avaldatud nagu Ressursid utiliidi veebilehel ning sellele järgnevat video kogu, kus on viimased ettekanded kustomize'i kohta.

Kui teil on küsimusi või ettepanekuid, kuidas seda materjali täiustada, olen alati tagasiside jaoks avatud. Minuga saab ühendust võtta Twitter või Kubernetes Slack-kanalis. Nautige oma manifestide kohandamist kustomize abil!

P.S. tõlkija märkused

Lugege ka meie blogist:

• «Arendustööriistad Kuberneteses töötavatele rakendustele»;
• «Kubernetes 1.14: peamiste uuenduste ülevaade»;
• «Helm Summiti 2019 viis peamist kokkuvõtet Amsterdamis»;
• «Praktiline tutvumine Kubernetes'e pakettide halduriga — Helm».

Allikas: habr.com