Krótki wstęp do Kustomize

Przyp. tłum.: Artykuł napisał Scott Lowe — doświadczony inżynier IT, autor lub współautor siedmiu książek drukowanych (głównie o VMware vSphere). Obecnie pracuje w jej spółce córce VMware — Heptio (przejęta w 2016 roku), specjalizując się w obliczeniach w chmurze i Kubernetes. Tekst ten jest zwięzłym i zrozumiałym wprowadzeniem do zarządzania konfiguracjami dla Kubernetes przy użyciu technologii Kustomize, która niedawno dołączyła do K8s.

Kustomize to narzędzie, które pozwala użytkownikom „dostosować proste pliki YAML bez szablonów do różnych celów, pozostawiając oryginalny YAML nienaruszony i gotowy do użycia” (opis pochodzi bezpośrednio z repozytorium kustomize na GitHubie). Kustomize można uruchamiać bezpośrednio lub, zaczynając od Kubernetes 1.14, używać kubectl -k do uzyskania dostępu do jego funkcji (choć w Kubernetes 1.15 oddzielny binarny plik jest nowszy od wbudowanych możliwości w kubectl). (Przyp. tłum.: A w związku z ostatnim wydaniem Kubernetes 1.16 kustomize jest wspierana jest także dostępny w narzędziu kubeadm.) W tym artykule chciałbym zapoznać czytelników z podstawami kustomize.

W najprostszym zastosowaniu kustomize to po prostu zestaw zasobów (pliki YAML, które definiują obiekty Kubernetes: Deployments, Services itp.) plus lista instrukcji dotyczących zmian, które należy wprowadzić w tych zasobach. Podobnie jak make używa zestawu instrukcji zawartego w Makefile, a Docker buduje kontener na podstawie instrukcji z Dockerfile, kustomize używa kustomization.yaml do przechowywania zaleceń dotyczących zmian, które użytkownik chce wprowadzić w zestawie zasobów.

Oto przykład pliku kustomization.yaml:

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

Nie będę próbował opisywać wszystkich możliwych pól w pliku kustomization.yaml (na ten temat dobrze napisano tutaj), ale przedstawię krótki opis konkretnego przykładu:

• Pole resources wskazuje, które zasoby będą zmieniane przez kustomize. W tym przypadku będzie szukać zasobów w plikach deployment.yaml i service.yaml w swoim katalogu (w razie potrzeby można podać pełne lub względne ścieżki).
• Pole namePrefix poleca kustomize’owi dodać określony prefiks (w tym przypadku — dev-) do atrybutu name wszystkich zasobów zdefiniowanych w polu resources. W ten sposób, jeśli w Deployment jest name o wartości nginx-deployment, kustomize przekształci to w dev-nginx-deployment.
• Pole namespace nakazuje kustomize dodawanie określonej przestrzeni nazw do wszystkich zasobów. W tym przypadku, Deployment i Service trafią do przestrzeni nazw rozwoju.
• W końcu pole commonLabels zawiera zestaw etykiet, które będą dodawane do wszystkich zasobów. W naszym przykładzie kustomize przypisze zasobom etykietę z nazwą environment i wartością rozwoju.

Jeśli użytkownik wykona kustomize build . w katalogu z plikiem kustomization.yaml i niezbędnymi zasobami (tj. plikami deployment.yaml i service.yaml), to na wyjściu uzyska tekst ze zmianami zapisanymi w kustomization.yaml.

Przyp. tłum.: Ilustracja z dokumentacji projektu dotycząca 'prostej' obsługi kustomize

Wynik można przekierować, jeśli trzeba zarejestrować zmiany:

kustomize build . > custom-config.yaml

Wyniki są deterministyczne (przy tych samych danych wejściowych, wyniki wyjściowe będą zawsze te same), więc nie ma potrzeby zapisywania wyniku w pliku. Zamiast tego można go od razu przekazać do innego polecenia:

kustomize build . | kubectl apply -f -

Dostęp do funkcji kustomize można również uzyskać przez kubectl -k (od wersji 1.14 Kubernetes). Jednak należy pamiętać, że oddzielny pakiet kustomize jest szybciej aktualizowany niż zintegrowany z kubectl (przynajmniej tak jest w przypadku wydania Kubernetes 1.15).

Czytelnicy mogą zapytać: 'Po co te wszystkie komplikacje, skoro można edytować pliki bezpośrednio?'. Doskonałe pytanie. W naszym przykładzie rzeczywiście można zmieniać pliki deployment.yaml i service.yaml bezpośrednio, ale co, jeśli są forkiem czyjegoś projektu? Bezpośrednia zmiana plików utrudnia (jeśli nie czyni niemożliwym) rebase forka, gdy wprowadzane są zmiany w źródle. Użycie kustomize pozwala na scentralizowanie tych zmian w pliku kustomization.yaml, pozostawiając oryginalne pliki nietknięte, a tym samym ułatwiając w razie potrzeby rebase plików źródłowych.

Zalety kustomize stają się oczywiste w bardziej złożonych przypadkach użycia. W powyższym przykładzie kustomization.yaml i zasoby znajdują się w tym samym katalogu. Jednak kustomize wspiera scenariusze, w których istnieje podstawowa konfiguracja i wiele jej wariantów, znanych również jako overlays. Na przykład, użytkownik chciał wziąć Deployment i Service dla nginx, które używałem jako przykład, i stworzyć wersje (lub warianty) tych plików dla środowisk development, staging i production. W tym celu potrzebne będą wspomniane wcześniej overlays oraz same podstawowe zasoby.

Aby zilustrować pomysł na overlays i zasoby podstawowe (zasoby podstawowe), załóżmy, że katalogi mają następującą strukturę:

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

W pliku base/kustomization.yaml użytkownicy za pomocą pola resources po prostu deklarują zasoby, które kustomize powinien uwzględnić.

W każdym z plików overlays/{dev,staging,prod}/kustomization.yaml użytkownicy odwołują się do podstawowej konfiguracji w polu resources, a następnie wskazują konkretne zmiany dla tej konkretnej przestrzeni. Na przykład, plik overlays/dev/kustomization.yaml może wyglądać jak przykład podany wcześniej:

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

Przy tym plik overlays/prod/kustomization.yaml może być zupełnie inny:

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

Gdy użytkownik uruchomi kustomize build . w katalogu overlays/dev, kustomize wygeneruje wariant development. Jeśli jednak uruchomi kustomize build . w katalogu overlays/prod , otrzyma wariant production. I wszystko to — bez wprowadzania jakichkolwiek zmian w pierwotnych (zasoby podstawowe) plikach, i wszystko to – w sposób deklaratywny i deterministyczny. Można commitować podstawową konfigurację oraz katalogi overlayowe bezpośrednio do systemu kontroli wersji, wiedząc, że na podstawie tych plików w każdej chwili można odtworzyć wymaganą konfigurację.

Przyp. tłum.: Ilustracja z dokumentacji projektu dotycząca użycia overlays w kustomize

Kustomize potrafi znacznie więcej, niż to opisano w tym artykule. Mimo to, mam nadzieję, że będzie to dobre wprowadzenie.

Dodatkowe zasoby

Jest wiele dobrych artykułów i publikacji na temat kustomize. Oto kilka, które uznałem za szczególnie pomocne:

• Zmień podstawową konfigurację YAML dla różnych środowisk prod/test przy użyciu Kustomize;
• Kustomize — właściwy sposób na szablonowanie w Kubernetes;
• Deklaratywne zarządzanie obiektami Kubernetes za pomocą Kustomize;
• Dostosowywanie upstreamowych Helm Charts za pomocą Kustomize.

Przyp. tłum.: Można też polecić blok linków opublikowany jako Zasoby na stronie narzędzia oraz kolekcję wideo z najnowszymi wystąpieniami na temat kustomize.

Jeśli masz pytania lub sugestie dotyczące poprawy tego materiału, zawsze jestem otwarty na informacje zwrotne. Możesz się skontaktować ze mną w Twitter lub na kanale Slack Kubernetes. Ciesz się modyfikowaniem swoich manifestów przy użyciu kustomize!

P.S. od tłumacza

Przeczytaj także na naszym blogu:

• «Narzędzia dla programistów aplikacji działających w Kubernetes»;
• «Kubernetes 1.14: przegląd głównych nowości»;
• «Pięć głównych wniosków z Helm Summit 2019 w Amsterdamie»;
• «Praktyczne wprowadzenie do menedżera pakietów dla Kubernetes — Helm».

Źródło: habr.com