Lühike sissejuhatus Kustomize'i

Märkus tõlke kohta.: Artikli autor on Scott Lowe, kogenud IT-insener, kes on seitse raamatut (enamasti VMware vSphere'ist) autor või kaasautor. Praegu töötab ta VMware tütarfirma Heptio (omandatud 2016. aastal) juures ning spetsialiseerub pilvetehnoloogiatele ja Kubernetes'ele. Artikli sisu on lühike ja arusaadav sissejuhatus Kubernetes'e konfiguratsioonihalduse teemal. Kustomize, mis on hiljuti lisandunud K8s'i koosseisu.

Kustomize on tööriist, mis võimaldab kasutajatel "kohandada lihtsaid ja mallideta YAML-faile erinevate eesmärkide jaoks, jättes originaali puutumata ja kasutamiseks sobivaks" (kirjeldus on otse võetud kustomize GitHub'i hoidlast). Kustomize'i saab käivitada otse või, alates Kubernetes 1.14, kasutada kubectl -k selle funktsioonide juurde pääsemiseks (kuigi Kubernetes'e 1.15 puhul on eraldi binaarfail uuem kui kubectl'i integreeritud funktsioonid). (Märkus tõlke kohta.: Ja hiljuti välja antud Kubernetes 1.16 kustomize toetatud ka kubeadm'i utiliidis.) Selles väljaandes soovin tutvustada lugejatele kustomize'i põhialuseid.

Koheselt kasutatuna on kustomize lihtsalt ressursside kogum (YAML-failid, mis määratlevad Kubernetes'e objekte: Deployments, Services jne) koos loendiga muudatustest, mida tuleb neisse ressurssidesse teha. Sarnaselt sellele, nagu make kasutab juhiseid, mis sisalduvad Makefile, ja Docker koostab konteineri, tuginedes juhistele, mis on pärit Dockerfile, kustomize kasutab kustomization.yaml kasutaja soovitud muudatuste määratlemiseks ressursside kogumisse.

Siin on näide failist: kustomization.yaml:

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

Ma ei püüa rääkida kõigist võimalustest failis kustomization.yaml (sellest on kirjutatud hea artikkel siin), aga annan lühikese seletuse konkreetse näite kohta:

• Väli ressursid tähendab, et (milliseid ressursse) kustomize muudab. Antud juhul otsib ta ressursse failidest deployment.yaml ja service.yaml oma kataloogis (vajadusel võib kasutada täielikke või suhtelisi radu).
• Väli namePrefix määrab kustomize'ile, et ta lisab kindla eesliite (antud juhul - dev-) kõigi ressursside atribuudile, mis on määratletud väljas nimi . Seega, kui Deployment'is on ressursidnginx-deployment nimi väärtusega , muudab kustomize selledev-nginx-deployment määrab kustomize'ile, et ta lisab määratud nimeserva kõigile ressurssidele. Antud juhul, Deployment ja Service sattuvad nimetuse alla.
• Väli namespace nõuab kustomize'ilt, et see lisaks määratud nimedele kõigile ressurssidele. Antud juhul kuuluvad Deployment ja Service määratud nimesse areng.
• Lõpuks, väli commonLabels sisaldab märgiste kogumit, mis lisatakse kõigile ressurssidele. Meie näites omistab kustomize ressurssidele märgise nimega keskkond ja väärtusega areng.

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

Märkus tõlke kohta.: Illustratsioon projekti dokumentatsioonist "lihtsa" kustomize kasutamise kohta

Väljundit saab suunata, kui on vajalik muudatuste fikseerimine:

kustomize build . > custom-config.yaml

Väljund on deterministlik (kui sisenedes on andmed samad, saadakse väljundis samad tulemused), seega ei pea tulemust faili salvestama. Selle asemel saab selle kohe edastada teisele käsurile:

kustomize build . | kubectl apply -f -

Kustomize'i funktsioonidele pääseb ligi ka läbi kubectl -k (alates Kubernetes versioonist 1.14). Kuid pidage meeles, et eraldi kustomize'i pakk uuendatakse kiiremini kui kubectl'isse integreeritud (vähemalt on see nii Kubernetes 1.15 väljaande puhul).

Lugejad võivad küsida: "Miks on kõik need keerukused vajalikud, kui faile saab otse redigeerida?" Suurepärane küsimus. Meie näites on tõesti saab failide deployment.yaml ja service.yaml otse muutmine võimalik, kuid mis siis, kui need on kellegi teise projekti fork? Failide otsene muutmine muudab harva (kui mitte võimatuks) fork'i rebase, kui lähte/koodi muudetakse. Kustomize'i kasutamine võimaldab neid muutusi keskenduda faili kustomization.yaml, jättes originaalfailid puutumatuks ja muutes vajadusel lähtefailide rebase'i lihtsamaks.

Kustomize'i eelised muutuvad ilmsiks keerukamates kasutusjuhtudes. Ülaltoodud näites kustomization.yaml ja ressursid on samas kaustas. Kuid kustomize toetab kasutusjuhte, kus on põhiline konfigureerimine ja palju selle variante, tuntud ka kui kubectl create cronjob. Näiteks soovis kasutaja võtta Deployment ja Service nginx'ist, mida kasutasin näitena, ja luua development-, staging- ja production-versioonid (või variandid) nendest failidest. Selleks on tal vaja ülalmainitud overlay'd ja sama põhiressursse.

Kasutades overlay'de ja põhiressurside ideed (base resources), oletame, et kaustadel on järgmine struktuur:

- baas
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlayd
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Failis baas/kustomization.yaml kasutajad kasutavad valikut ressursid lihtsalt kuulutavad ressursid, mida kustomize peab sisaldama.

Igas failis overlayd/{dev,staging,prod}/kustomization.yaml kasutajad viitavad põhikonfiguratsioonile valikus ressursid, ja seejärel määravad spetsiifilised muudatused antud keskkonnale. Näiteks võib fail overlayd/dev/kustomization.yaml näha välja nagu eelnevalt näidatud näide:

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

Selle puhul võib fail overlayd/prod/kustomization.yaml olla täiesti erinev:

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

Kui kasutaja käivitab kustomize build . kaustas overlayd/dev, kustomize genereerib arenduse variandi. Kui aga käivitada kustomize build . kaustas overlayd/prod , siis saadakse tootmisvariant. Ja kõik see toimub ilma algsete muutmisteta (baas) failides, ja see kõik toimub deklaratiivse ja määratletud viisi kaudu. Võib commtiida põhikonfiguratsiooni ja overlaydirektorid otse versioonihaldussüsteemi, teades, et nende failide alusel on igal ajal võimalik soovitud konfiguratsiooni taastada.

Märkus tõlke kohta.: Illustratsioon projekti dokumentatsioonist overlays'i kasutamise kohta kustomizes

Kustomize oskab märksa rohkem, kui selles artiklis räägitakse. Loodetavasti on see hea sissejuhatus.

Lisainfo

On palju häid artikleid ja väljaandeid kustomize'i kohta. Siin on mõned, mida pean eriti kasulikeks:

• Muuda baasi YAML konfiguratsiooni erinevates keskkondades prod/test Kustomize'i abil;
• Kustomize — Õige viis templaatide tegemiseks Kubernetes'is;
• Deklaratiivne Kubernetes'i objektide haldamine Kustomize'i abil;
• Ülesvoolu Helm i diagrammide kohandamine Kustomize'i abil.

Märkus tõlke kohta.: Samuti võiks soovitada linkide plokki, mis on avaldatud Ressursid utiliidi veebilehel, ja sellele järgnev videokogum viimaste kustomize'i esitluste kohta.

Kui teil on küsimusi või ettepanekuid selle materjali täiustamiseks, olen alati tagasiside saamiseks avatud. Võite minuga ühendust võtta Twitteris või Kubernetes'i Slack-kanalis. Nautige oma manifeestide muutmist kustomize'i abil!

P.S. tõlkijalt

Lugege ka meie blogist:

• «Rakenduste arendamise tööriistad, mis käivitatakse Kuberneteses»;
• «Kubernetes 1.14: ülevaade peamistest uuendustest»;
• «Viis peamist järeldust Helm Summit 2019 Amsterdamis»;
• «Praktiline tutvumine Kubernetes'e paketihalduriga — Helm».

Allikas: habr.com