Īss ievads Kustomize

Piezīme:: Rakstu uzrakstījis Skots Louts – IT inženieris ar daudz gadu pieredzi, kurš ir septiņu drukātu grāmatu (galvenokārt par VMware vSphere) autors/ līdzautors. Pašlaik viņš strādā pie VMware meitasuzņēmuma Heptio (iegādāts 2016. gadā), specializējoties mākoņdatošanā un Kubernetes. Pats teksts kalpo kā kodolīgs un viegli saprotams ievads konfigurācijas pārvaldībā Kubernetes, izmantojot tehnoloģiju Kustomize, kas nesen pievienota K8s.

Kustomize ir rīks, kas ļauj lietotājiem "pielāgot vienkāršus un šablonu brīvus YAML failus dažādiem mērķiem, atstājot oriģinālo YAML neskartu un izmantojamu" (apraksts ņemts tieši no kustomize repozitorija GitHub). Kustomize var palaist tieši vai, sākot ar Kubernetes 1.14, izmantot kubectl -k lai piekļūtu tā funkcijām (lai gan Kubernetes 1.15 atversionē atsevišķs binārais fails ir jaunāks par kubectl iebūvētām iespējām). (Piezīme:: Ar neseno izlaidumu Kubernetes 1.16 Vienkārša kustomization faila izmantošana atbalsta arī kubeadm rīka ietvaros.) Šajā publikācijā es vēlos iepazīstināt lasītājus ar kustomize pamatiem.

Savā vienkāršākajā formā/kontekstā kustomize ir vienkārši resursu komplekts (YAML faili, kuri definē Kubernetes objektus: Deployments, Services u.c.) plus izmaiņu instrukciju saraksts, kas jāveic šajos resursos. Līdzīgi kā make izmanto instrukciju kopumu, kas atrodas Makefile, un Docker izveido kontenerus, pamatojoties uz instrukcijām no Dockerfile, kustomize izmanto kustomization.yaml lai glabātu norādījumus par to, kādas izmaiņas lietotājs vēlas veikt resursu komplektā.

Šeit ir piemērs failam kustomization.yaml:

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

Es nepiedāvāšu stāstīt par visām iespējām failā kustomization.yaml (par to ir labi rakstīts šeit), bet es sniegšu īsu konkrēta piemēra skaidrojumu:

• Lauks resources norāda, kādus (kādus resursus) kustomize mainīs. Šajā gadījumā tas meklēs resursus failos deployment.yaml un service.yaml savā direktorijā (ja nepieciešams, var sniegt pilnas vai relatīvas ceļa).
• Lauks namePrefix norāda kustomize, ka ir jāpieliek noteikts prefikss (šajā gadījumā – dev-) visiem resursiem, kas definēti laukā name . Tādējādi, ja Deploymentā ir resourcesnginx-deployment name ar vērtību , kustomize to pārvērtīs pardev-nginx-deployment norāda kustomize, ka ir jānorāda piešķirtais namespaces visiem resursiem. Šajā gadījumā Deployment un Service nonāks namespaces.
• Lauks namespace nosaka Kustomize pievienot noteikto nosaukuma telpu visiem resursiem. Šajā gadījumā Deployment un Service tiks pievienoti nosaukuma telpai. izstrāde.
• Beidzot lauks commonLabels satur kopumu birku, kas tiks pievienota visiem resursiem. Mūsu piemērā kustomize piešķirs resursiem birku ar nosaukumu vidē un vērtību izstrāde.

Ja lietotājs izpildīs kustomize build . direktorijā ar failu kustomization.yaml un nepieciešamajiem resursiem (t.i., failiem deployment.yaml un service.yaml), tad rezultātā viņš saņems tekstu ar izmaiņām, kas norakstītas kustomization.yaml.

Piezīme:: Ilustrācija no projekta dokumentācijas par "vienkāršu" kustomize izmantošanu

Izvadi var novirzīt, ja nepieciešams fiksēt izmaiņas:

kustomize build . > custom-config.yaml

Izejas dati ir determinēti (ar vienādiem datiem ievadē tiks iegūti tie paši rezultāti izejā), tāpēc to nav nepieciešams saglabāt failā. Tā vietā to var nekavējoties nodot citai komandai:

kustomize build . | kubectl apply -f -

Piekļuve kustomize funkcijām ir iespējama arī caur kubectl -k (sākot ar Kubernetes 1.14 versiju). Tomēr ņemiet vērā, ka atsevišķs kustomize pakotnes atjaunošana notiek ātrāk nekā tas, kas ir integrēts kubectl (vismaz tā ir ar Kubernetes 1.15 izlaidumu).

Lasītāji var jautāt: "Kāpēc ir nepieciešamas visas šīs sarežģītības, ja failus var tieši rediģēt?" Lielisks jautājums. Mūsu piemērā tiešām var rediģēt failus deployment.yaml un service.yaml tieši, bet kas notiks, ja tie ir kāda projekta forks? Tieša failu maiņa apgrūtina (ja nepadara neiespējamu) forka pārbūvi, kad tiek veiktas izmaiņas avotā. Kustomize izmantošana ļauj centralizēt šīs izmaiņas failā kustomization.yaml, atstājot oriģinālos failus neskartus un tādējādi atvieglojot nepieciešamības gadījumā avota failu pārbūvi.

Kustomize priekšrocības kļūst acīmredzamas sarežģītākajos lietošanas gadījumos. Iepriekš minētajā piemērā kustomization.yaml un resursi atrodas vienā un tajā pašā direktorijā. Tomēr kustomize atbalsta lietošanas scenārijus, kad ir pamata konfigurācija un daudzi tās varianti, kas pazīstami arī kā , nosaukums runā pats par sevi.. Piemēram, lietotājs vēlējās ņemt Deployment un Service nginxa, ko es izmantoju kā piemēru, un izveidot attīstības-, sagatavošanas- un ražošanas versijas (vai variantus) šo failu. Tam būs nepieciešami iepriekš minētie overlays un paši pamata resursi.

Lai ilustrētu overlays un pamata resursu ideju (pamata resursi), pieņemsim, ka direktorijām ir šāda struktūra:

- bāze
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- pārklājumi
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Failā bāze/kustomization.yaml lietotāji izmanto lauku resources vienkārši deklarē resursus, kurus jāiekļauj kustomize.

Katrs fails pārklājumi/{dev,staging,prod}/kustomization.yaml lietotāji atsaucas uz pamata konfigurāciju laukā resources, pēc tam norādot konkrētas izmaiņas noteiktai videi. Piemēram, fails pārklājumi/dev/kustomization.yaml var izskatīties šādi:

resources:
- .. / .. /bāze
namePrefix: dev-
namespace: attīstība
commonLabels:
  vide: attīstība

Savukārt fails pārklājumi/prod/kustomization.yaml var būt pilnīgi cits:

resources:
- .. / .. /bāze
namePrefix: prod-
namespace: ražošana
commonLabels:
  vide: ražošana
  sre-team: blue

Kad lietotājs palaidīs kustomize build . mapē pārklājumi/dev, kustomize ģenerēs versiju attīstībai. Ja palaiž kustomize build . mapē pārklājumi/prod , tiks iegūta ražošanas versija. Un viss tas — bez jebkādām izmaiņām sākotnējos (bāze) failos, un tas viss — deklaratīvā un deterministiskā veidā. Varēsiet veikt komitēšanu pamata konfigurācijai un pārklājumu direktorijām tieši versiju kontroles sistēmā, zinot, ka, pamatojoties uz šiem failiem, jebkurā brīdī var atkārtot nepieciešamo konfigurāciju.

Piezīme:: Ilustrācija no projekta dokumentācijas par pārklājumu izmantošanu kustomize

Kustomize spēj krietni vairāk, nekā šajā rakstā ir aprakstīts. Tomēr ceru, ka tas kalpos kā labs ievads.

Papildu resursi

Ir daudz labu rakstu un publikāciju par kustomize. Šeit ir dažas, kas man šķita īpaši noderīgas:

• Mainīt pamata YAML konfigurāciju dažādām videi ražošanai/testēšanai, izmantojot Kustomize;
• Kustomize — pareizā metode veidņu izmantošanai Kubernetes;
• Deklaratīvā Kubernetes objektu pārvaldība, izmantojot Kustomize;
• Augšupielādes Helm diagrammu pielāgošana ar Kustomize.

Piezīme:: Tāpat var ieteikt saites bloku, kas publicēts kā Resursi uz instrumenta vietnes, un pēc tam sekojošu video kolekciju ar jaunākajiem ziņojumiem par kustomize.

Ja jums ir jautājumi vai ieteikumi šī materiāla uzlabošanai, es vienmēr esmu atvērts atsauksmēm. Sazinieties ar mani Twitter vai uz Kubernetes Slack kanālā. Baudiet modificējot savus manifestus, izmantojot kustomize!

P.S. no tulka

Lasiet arī mūsu emuāra rakstos:

• «Rīki lietotājiem, kas izstrādā lietotnes Kubernetes vidē»;
• «Kubernetes 1.14: galvenās jaunās iezīmes»;
• «Piecus galvenos secinājumus no Helm Summit 2019 Amsterdamā»;
• «Praktiska iepazīšanās ar paketēšanas manageri Kubernetes — Helm».

Avots: habr.com