Krótkie wprowadzenie do Kustomize

Notatka. przeł.: Artykuł został napisany przez Scotta Lowe’a, inżyniera z dużym doświadczeniem w IT, który jest autorem/współautorem siedmiu drukowanych książek (głównie na temat VMware vSphere). Obecnie pracuje w spółce zależnej VMware Heptio (przejętej w 2016 roku), specjalizującej się w chmurze obliczeniowej i Kubernetesie. Sam tekst stanowi zwięzłe i łatwe do zrozumienia wprowadzenie do zarządzania konfiguracją dla Kubernetesa z wykorzystaniem technologii Dostosuj, który niedawno stał się częścią K8s.

Kustomize to narzędzie, które pozwala użytkownikom „dostosowywać proste, wolne od szablonów pliki YAML do różnych celów, pozostawiając oryginalny YAML nienaruszony i użyteczny” (opis zapożyczony bezpośrednio z kustomize w repozytorium GitHub). Kustomize można uruchomić bezpośrednio lub, od wersji Kubernetes 1.14, użyć kubectl -k aby uzyskać dostęp do jego funkcjonalności (chociaż od wersji Kubernetes 1.15 oddzielny plik binarny jest nowszy niż możliwości wbudowane w kubectl). (Notatka. przeł.: I z najnowszą wersją Kubernetes 1.16 dostosować wspierany przez także w narzędziu kubeadm.) W tym poście chcę przedstawić czytelnikom podstawy kustomize.

W najprostszej formie/aplikacji kustomize to po prostu zbiór zasobów (pliki YAML definiujące obiekty Kubernetes: wdrożenia, usługi 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, dostosuj zastosowania kustomization.yaml do przechowywania instrukcji dotyczących zmian, jakie użytkownik chce wprowadzić w zestawie zasobów.

Oto przykładowy plik kustomization.yaml:

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

Nie będę się rozpisywał o wszystkich możliwych polach w pliku. kustomization.yaml (jest o tym dobrze napisane tutaj), ale podam krótkie wyjaśnienie konkretnego przykładu:

• Pole resources wskazuje, co (które zasoby) kustomize ulegnie zmianie. W tym wypadku będzie szukał zasobów w plikach deployment.yaml и service.yaml w swoim katalogu (w razie potrzeby możesz określić ścieżki pełne lub względne).
• Pole namePrefix instruuje kustomize, aby dodał określony przedrostek (w tym przypadku - dev-) przypisywać name wszystkie zasoby zdefiniowane w polu resources. Zatem, jeśli wdrożenie ma name ze znaczeniem nginx-deployment, dostosuj to zrobi dev-nginx-deployment.
• Pole namespace instruuje kustomize, aby dodał podaną przestrzeń nazw do wszystkich zasobów. W takim przypadku Deployment i Service będą należeć do przestrzeni nazw development.
• Wreszcie pole commonLabels zawiera zestaw etykiet, które zostaną dodane do wszystkich zasobów. W naszym przykładzie kustomize przypisze etykietę do zasobów z nazwą environment i znaczenie development.

Jeśli użytkownik to zrobi kustomize build . w katalogu z plikiem kustomization.yaml oraz niezbędne zasoby (tj. pliki deployment.yaml и service.yaml), to na wyjściu otrzyma tekst ze zmianami określonymi w kustomization.yaml.

Notatka. przeł.: Ilustracja z dokumentacji projektu dotycząca „prostego” użycia kustomize

Dane wyjściowe można przekierować, jeśli konieczne jest zatwierdzenie zmian:

kustomize build . > custom-config.yaml

Dane wyjściowe są deterministyczne (te same dane wejściowe dadzą takie same wyniki wyjściowe), więc nie musisz zapisywać wyniku w pliku. Zamiast tego można go przekazać bezpośrednio do innego polecenia:

kustomize build . | kubectl apply -f -

Dostęp do funkcji kustomize można również uzyskać za pośrednictwem kubectl -k (od wersji Kubernetes 1.14). Należy jednak pamiętać, że samodzielny pakiet kustomize jest aktualizowany szybciej niż zintegrowany pakiet kubectl (przynajmniej tak jest w przypadku wersji Kubernetes 1.15).

Czytelnicy mogą zapytać: „Po co ta cała złożoność, skoro możesz bezpośrednio edytować pliki?” Świetne pytanie. W naszym przykładzie rzeczywiście można modyfikować pliki deployment.yaml и service.yaml bezpośrednio, ale co jeśli są rozwidleniem czyjegoś projektu? Bezpośrednia zmiana plików utrudnia (jeśli nie uniemożliwia) zmianę bazy rozwidlenia, gdy wprowadzane są zmiany w źródle/źródle. Korzystanie z kustomize pozwala scentralizować te zmiany w pliku kustomization.yaml, pozostawiając oryginalne pliki nienaruszone, co ułatwia zmianę bazy oryginalnych plików, jeśli to konieczne.

Korzyści z kustomize stają się widoczne w bardziej złożonych przypadkach użycia. W powyższym przykładzie kustomization.yaml a zasoby znajdują się w tym samym katalogu. Jednak kustomize obsługuje przypadki użycia, w których istnieje konfiguracja podstawowa i wiele jej wariantów, znanych również jako Nakładki. Na przykład użytkownik chciał skorzystać z narzędzia Deployment and Service dla nginx, którego użyłem jako przykładu, i utworzyć wersje rozwojowe (lub warianty) tych plików w wersji rozwojowej, testowej i produkcyjnej. Do tego potrzebne będą mu wspomniane wyżej nakładki, a właściwie same podstawowe surowce.

Aby zilustrować ideę nakładek i zasobów bazowych (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żytkowników korzystających z pola resources po prostu zadeklaruj zasoby, które powinien zawierać kustomize.

W każdym z plików overlays/{dev,staging,prod}/kustomization.yaml użytkownicy odnoszą się do konfiguracji podstawowej w terenie resources, a następnie wskaż konkretne zmiany dla dane środowisko. 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

W tym przypadku plik overlays/prod/kustomization.yaml może być zupełnie inaczej:

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

Kiedy użytkownik działa kustomize build . w katalogu overlays/dev, kustomize wygeneruje opcję programowania. Jeśli biegniesz kustomize build . w katalogu overlays/prod - otrzymujesz opcję produkcyjną. A to wszystko - bez dokonywania jakichkolwiek zmian w oryginale (baza) plików, a wszystko to w sposób deklaratywny i deterministyczny. Możesz przekazać podstawową konfigurację i katalogi nakładek bezpośrednio kontroli wersji, wiedząc, że na podstawie tych plików możesz w dowolnym momencie odtworzyć żądaną konfigurację.

Notatka. przeł.: Ilustracja z dokumentacji projektu dotycząca użycia nakładek w kustomize

Dostosuj puszkę dużo więcej niż opisano w tym artykule. Mam jednak nadzieję, że będzie to dobre wprowadzenie.

Dodatkowe zasoby

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

• Zmień podstawową konfigurację YAML dla różnych środowisk, prod/test przy użyciu Kustomize;
• Kustomize — właściwy sposób tworzenia szablonów w Kubernetes;
• Deklaratywne zarządzanie obiektami Kubernetes za pomocą opcji Dostosuj;
• Dostosowywanie wykresów steru nadrzędnego za pomocą opcji Dostosuj.

Notatka. przeł.: Możesz także polecić blok linków opublikowanych jako Zasoby na stronie narzędzia, a następnie zbiór filmów z najnowszymi raportami na temat kustomize.

Jeśli masz pytania lub sugestie dotyczące ulepszenia tego materiału, zawsze jestem otwarty na uwagi. Możesz się ze mną skontaktować pod adresem Twitter lub Kanał Kubernetes Slack. Miłej zabawy podczas modyfikowania manifestów za pomocą kustomize!

PS od tłumacza

Przeczytaj także na naszym blogu:

• «Narzędzia dla programistów aplikacji działających na Kubernetesie";
• «Kubernetes 1.14: przegląd głównych innowacji";
• «Pięć głównych wyników Helm Summit 2019 w Amsterdamie";
• «Praktyczne wprowadzenie do menadżera pakietów dla Kubernetesa – Helm".

Źródło: www.habr.com