Īss ievads par Kustomize

Piezīme. tulk.: rakstu ir uzrakstījis Skots Lovs, inženieris ar lielu pieredzi IT jomā, kurš ir septiņu drukātu grāmatu (galvenokārt par VMware vSphere) autors/līdzautors. Tagad viņš strādā tā VMware meitasuzņēmumā Heptio (iegādāts 2016. gadā), kas specializējas mākoņdatniecībā un Kubernetes. Pats teksts kalpo kā kodolīgs un viegli saprotams ievads Kubernetes konfigurācijas pārvaldībā, izmantojot tehnoloģiju Pielāgot, kas nesen kļuva par daļu no K8s.

Kustomize ir rīks, kas ļauj lietotājiem “pielāgot vienkāršus, bez veidnes YAML failus dažādiem mērķiem, atstājot sākotnējo YAML neskartu un lietojamu” (apraksts aizgūts tieši no kustomize repozitorijs vietnē GitHub). Kustomize var palaist tieši vai, sākot ar Kubernetes 1.14, izmantot kubectl -k lai piekļūtu tā funkcionalitātei (lai gan no Kubernetes 1.15 atsevišķais binārais fails ir jaunāks par kubectl iebūvētajām iespējām). (Piezīme. tulk.: Un ar neseno izlaidumu Kubernetes 1.16 pielāgot atbalsta arī utilītprogrammā kubeadm.) Šajā ierakstā es vēlos iepazīstināt lasītājus ar kustomize pamatiem.

Vienkāršākajā formā/lietojumprogrammā kustomize ir vienkārši resursu kolekcija (YAML faili, kas definē Kubernetes objektus: izvietošana, pakalpojumi utt.), kā arī saraksts ar norādījumiem par izmaiņām, kas jāveic šajos resursos. Tāpat kā make izmanto instrukciju kopu, kas ietverta Makefile, un Docker izveido konteineru, pamatojoties uz instrukcijām no Dockerfile, pielāgot lietojumus kustomization.yaml lai saglabātu norādījumus par to, kādas izmaiņas lietotājs vēlas veikt resursu kopā.

Šeit ir faila piemērs kustomization.yaml:

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

Es nemēģināšu runāt par visiem iespējamajiem faila laukiem. kustomization.yaml (par to ir labi uzrakstīts šeit), bet es sniegšu īsu paskaidrojumu par konkrētu piemēru:

• Lauks resources norāda, ko (kādus resursus) kustomize mainīs. Šajā gadījumā tas meklēs resursus failos deployment.yaml и service.yaml savā direktorijā (ja nepieciešams, varat norādīt pilnus vai relatīvus ceļus).
• Lauks namePrefix uzdod kustomize pievienot noteiktu prefiksu (šajā gadījumā - dev-), lai atribūtu name visi laukā definētie resursi resources. Tādējādi, ja Izvietošanai ir name ar nozīmi nginx-deployment, pielāgojiet to dev-nginx-deployment.
• Lauks namespace uzdod kustomize pievienot doto nosaukumvietu visiem resursiem. Šajā gadījumā izvietošana un apkalpošana tiks iekļauta nosaukumvietā development.
• Visbeidzot, lauks commonLabels satur iezīmju kopu, kas tiks pievienota visiem resursiem. Mūsu piemērā kustomize resursiem piešķirs etiķeti ar nosaukumu environment un nozīme development.

Ja lietotājs to dara kustomize build . direktorijā ar failu kustomization.yaml un nepieciešamie resursi (t.i., faili deployment.yaml и service.yaml), tad izejā tas saņems tekstu ar izmaiņām, kas norādītas kustomization.yaml.

Piezīme. tulk.: Ilustrācija no projekta dokumentācijas par kustomize “vienkāršo” lietošanu

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

kustomize build . > custom-config.yaml

Izvades dati ir deterministiski (vieni un tie paši ievades dati radīs tādus pašus izvades rezultātus), tāpēc jums nav jāsaglabā rezultāts failā. Tā vietā to var tieši nodot citai komandai:

kustomize build . | kubectl apply -f -

Kustomize funkcijām var piekļūt arī, izmantojot kubectl -k (kopš Kubernetes versijas 1.14). Tomēr ņemiet vērā, ka atsevišķā kustomize pakotne tiek atjaunināta ātrāk nekā integrētā kubectl pakotne (vismaz tas attiecas uz Kubernetes 1.15 versiju).

Lasītāji var jautāt: "Kāpēc šī sarežģītība, ja failus var rediģēt tieši?" Lielisks jautājums. Mūsu piemērā patiešām viens var modificēt failus deployment.yaml и service.yaml tieši, bet ja tie ir kāda cita projekta dakša? Mainot failus tieši, ir grūti (ja ne neiespējami) mainīt dakšu, kad tiek veiktas izmaiņas izcelsmē/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 oriģinālo failu atkārtotu bāzi, ja nepieciešams.

Kustomize priekšrocības kļūst acīmredzamas sarežģītākos lietošanas gadījumos. Iepriekš minētajā piemērā kustomization.yaml un resursi atrodas tajā pašā direktorijā. Tomēr kustomize atbalsta lietošanas gadījumus, kad ir bāzes konfigurācija un daudzi tās varianti, kas pazīstami arī kā Pārklājumi. Piemēram, lietotājs vēlējās izmantot nginx izvietošanu un pakalpojumu, ko izmantoju kā piemēru, un izveidot šo failu izstrādes, iestudēšanas un ražošanas versijas (vai variantus). Lai to izdarītu, viņam būs nepieciešami iepriekš minētie pārklājumi un faktiski arī paši pamata resursi.

Lai ilustrētu ideju par pārklājumiem un pamatā esošajiem resursiem (bāzes resursi), pieņemsim, ka direktorijiem ir šāda struktūra:

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

Failā base/kustomization.yaml lietotāji, kas izmanto lauku resources vienkārši deklarējiet resursus, kas jāiekļauj kustomizei.

Katrā no failiem overlays/{dev,staging,prod}/kustomization.yaml lietotāji atsaucas uz pamata konfigurāciju laukā resourcesun pēc tam norādiet konkrētas izmaiņas dotā vide. Piemēram, fails overlays/dev/kustomization.yaml varētu izskatīties kā iepriekš sniegtais piemērs:

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

Šajā gadījumā fails overlays/prod/kustomization.yaml varētu būt pavisam savādāk:

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

Kad lietotājs darbojas kustomize build . katalogā overlays/dev, kustomize ģenerēs izstrādes iespēju. Ja tu skrien kustomize build . katalogā overlays/prod - jūs saņemat ražošanas iespēju. Un tas viss – neveicot nekādas izmaiņas oriģinālā (bāze) failus deklaratīvā un deterministiskā veidā. Pamatkonfigurācijas un pārklājuma direktorijus varat pievienot tieši versijas kontrolei, zinot, ka, pamatojoties uz šiem failiem, jūs jebkurā laikā varat reproducēt vēlamo konfigurāciju.

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

Pielāgot var daudz vairāk nekā šajā rakstā. Tomēr es ceru, ka tas kalpos kā labs ievads.

Papildu resursi

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

• Mainiet pamata YAML konfigurāciju dažādām vidēm prod/test, izmantojot Kustomize;
• Kustomize — pareizais veidņu veidošanas veids programmā Kubernetes;
• Kubernetes objektu deklaratīvā pārvaldība, izmantojot pielāgošanu;
• Augšupējo stūres diagrammu pielāgošana ar Customize.

Piezīme. tulk.: varat arī ieteikt saišu bloku, kas publicēts kā resursi utilīta vietnē, kam seko videoklipu kolekcija ar jaunākajiem ziņojumiem par kustomize.

Ja jums ir jautājumi vai ieteikumi šī materiāla uzlabošanai, vienmēr esmu atvērts atsauksmēm. Jūs varat sazināties ar mani pa tālr Twitter vai Kubernetes Slack kanāls. Izklaidējieties, modificējot savus manifestus, izmantojot kustomize!

PS no tulka

Lasi arī mūsu emuārā:

• «Rīki lietojumprogrammu izstrādātājiem, kas darbojas Kubernetes";
• «Kubernetes 1.14: Jaunumi svarīgākie";
• «Pieci galvenie Helm Summit 2019 rezultāti Amsterdamā";
• «Praktisks ievads par Kubernetes pakotņu pārvaldnieku - Helm'.

Avots: www.habr.com