Kratek uvod v Kustomize

Op. prev.: Članek je napisal Scott Lowe, inženir z bogatimi izkušnjami na področju IT, ki je avtor oziroma soavtor sedmih tiskanih knjig (večinoma o VMware vSphere). Zdaj dela v hčerinski družbi VMware - Heptio (pridobljena leta 2016), specializirano za oblačne storitve in Kubernetes. Besedilo služi kot jedrnato in enostavno razumljivo uvod v upravljanje konfiguracij za Kubernetes z uporabo tehnologije Kustomize, ki je bila nedavno vključena v K8s.

Kustomize je orodje, ki uporabnikom omogoča "prilagajanje preprostih in brezpredložnih YAML datotek za različne namene, pri čemer originalni YAML ostane nedotaknjen in primeren za uporabo" (opis je neposredno prevzet iz repozitorija kustomize na GitHubu). Kustomize lahko zaženete neposredno ali, od različice Kubernetes 1.14, uporabite kubectl -k za dostop do njegovih funkcij (čeprav je v Kubernetes 1.15 ločena binarna različica novejša od funkcionalnosti vgrajenih v kubectl). (Op. prev.: Z nedavno izdajo Kubernetes 1.16 kustomize podprt tudi v orodju kubeadm.) V tej objavi želim bralce seznaniti z osnovami kustomize.

V svoji najpreprostejši obliki/uporabi je kustomize preprosto niz virov (YAML datoteke, ki določajo Kubernetes objekte: Deployments, Services itd.) ter seznam navodil o spremembah, ki jih je treba izvesti na teh virih. Tako kot make uporablja niz navodil iz Makefile, in Docker sestavi kontejner na podlagi navodil iz Dockerfile, kustomize uporablja kustomization.yaml za shranjevanje predpisov o tem, katere spremembe želi uporabnik uvesti v niz virov.

Tukaj je primer datoteke kustomization.yaml:

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

Ne bom poskušal opisati vseh možnih polj v datoteki kustomization.yaml (o tem je dobro napisano ovde), vendar bom podal kratko razlago konkretnega primera:

• Field resources določa, katere vire bo kustomize spremenil. V tem primeru bo iskala vire v datotekah deployment.yaml in service.yaml v svojem imeniku (po potrebi lahko navajate popolne ali relativne poti).
• Field namePrefix predpisuje kustomize’u, da doda določen predpona (v tem primeru - dev-) k atributu name vseh virov, določenih na področju resources. Tako bo, če v Deploymentu obstaja name z vrednostjo nginx-deployment, kustomize naredil iz njega dev-nginx-deployment.
• Field namespace predpisuje kustomize’u, da doda določeno ime prostora vsem virom. V tem primeru bosta Deployment in Service spadala v ime prostora razvoj.
• Konačno, polje commonLabels sadrži skup oznaka koje će biti dodane svim resursima. U našem primeru, kustomize će dodeliti resursima oznaku naziva okolje i vrednošću razvoj.

Ako korisnik izvrši kustomize build . u direktoriji sa fajlom kustomization.yaml i neophodnim resursima (tj. fajlovima deployment.yaml in service.yaml), izlaz će biti tekst sa izmenama navedenim u kustomization.yaml.

Op. prev.: Ilustracija iz dokumentacije projekta o "jednostavnom" korišćenju kustomize-a

Izlaz se može preusmeriti, ako je potrebno, da zabeleži promene:

kustomize build . > custom-config.yaml

Izlazni podaci su deterministički (sa istim ulaznim podacima dobijaju se isti izlazni rezultati), tako da nije potrebno čuvati rezultat u fajlu. Umesto toga, može se odmah proslediti drugoj komandi:

kustomize build . | kubectl apply -f -

Pristup funkcijama kustomize-a takođe se može ostvariti putem kubectl -k (počevši od verzije 1.14 Kubernetes-a). Imajte na umu da se posebni kustomize paket brže ažurira nego integrisani u kubectl (barem, tako je u slučaju izdanja Kubernetes-a 1.15).

Čitaoci se mogu pitati: "Zašto su sve te komplikacije potrebne, kada se fajlovi mogu direktno uređivati?". Odlično pitanje. U našem primeru zaista je možno modifikovati fajlove deployment.yaml in service.yaml direktno, ali šta ako su oni forkovani iz nečijeg projekta? Direktna promena fajlova otežava (ako ne i onemogućava) rebase forka kada se unose izmene u izvor. Korišćenje kustomize-a omogućava centralizovanje tih izmena u fajlu kustomization.yaml, ostavljajući originalne fajlove netaknute i time olakšavajući rebase izvornog fajla po potrebi.

Prednosti kustomize-a postaju očigledne u složenijim slučajevima korišćenja. U gornjem primeru kustomization.yaml i resursi se nalaze u istom direktorijumu. Međutim, kustomize podržava scenarije korišćenja kada postoji osnovna konfiguracija i mnoge njene varijante, poznate i kao overlays. Na primer, korisnik je želeo da uzme Deployment i Service za nginx, koje sam koristio kao primer, i da kreira development-, staging- i production-verzije (ili varijante) tih fajlova. Za to će mu biti potrebni gore pomenuti overlays i, zapravo, sami osnovni resursi.

Da ilustrujem ideju overlays i osnovnih resursa (base resources), pretpostavimo da direktorijumi imaju sledeću strukturu:

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

V datoteki base/kustomization.yaml пользователи с помощью поля resources просто объявляют ресурсы, которые должен включить kustomize.

В каждом из файлов overlays/{dev,staging,prod}/kustomization.yaml пользователи ссылаются на базовую конфигурацию в поле resources, а затем указывают конкретные изменения для данного окружения. Например, файл overlays/dev/kustomization.yaml может выглядеть как пример, приведенный ранее:

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

При этом файл overlays/prod/kustomization.yaml может быть совсем другим:

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

Когда пользователь запустит kustomize build . v imeniku overlays/dev, kustomize сгенерирует вариант development. Если же запустить kustomize build . v imeniku overlays/prod — получится вариант production. И все это — без внесения каких-либо изменений в изначальные (base) файлы, и все это — декларативным и детерминированным способом. Можно коммитить базовую конфигурацию и оверлейные директории прямо в систему управления версиями, зная, что на основе этих файлов в любой момент можно воспроизвести нужную конфигурацию.

Op. prev.: Иллюстрация из документации проекта по использованию overlays в kustomize

Kustomize умеет veliko больше, чем рассказано в этой статье. Впрочем, надеюсь, она послужит хорошим введением.

Dodatni resursi

Есть много хороших статей и публикаций о kustomize. Вот несколько, которые я посчитал особо полезными:

• Change base YAML config for different environments prod/test using Kustomize;
• Kustomize — The right way to do templating in Kubernetes;
• Declarative Management of Kubernetes Objects Using Kustomize;
• Customizing Upstream Helm Charts with Kustomize.

Op. prev.: Также можно посоветовать блок ссылок, опубликованных как Viri на сайте утилиты, и последующую за ними коллекцию видео с последними докладами про kustomize.

Если у вас есть вопросы или предложения по улучшению этого материала, я всегда открыт к обратной связи. Связаться со мной можно в Twitter ali v Slack-канале Kubernetes. Получайте удовольствие, модифицируя свои манифесты с помощью kustomize!

P.S. od prevajalca

Preberite tudi na našem blogu:

• «Orodja za razvijalce aplikacij, zagnanih v Kubernetesu»;
• «Kubernetes 1.14: pregled glavnih novosti»;
• «Пять главных итогов Helm Summit 2019 в Амстердаме»;
• «Praktické zoznámenie s správcom balíkov pre Kubernetes — Helm».

Izvor: habr.com