Helm – manager pakietów w Kubernetesie

07-10-2021

Zdefiniowany jako menadżer pakietów aplikacji w orkiestratorze Kubernetes – Helm jest, jak podkreślają sami jego twórcy, „najlepszym sposobem na wyszukiwanie, udostępnianie i używanie oprogramowania stworzonego dla Kubernetes”. Warte podkreślenia jest to, że Helm umożliwia wdrażanie aplikacji w bardzo prosty sposób, w zasadzie jednym kliknięciem. To znacznie ułatwia pracę, zwłaszcza wtedy, gdy nie mamy dużego doświadczenia w zakresie kontenerów.

Helm a charty

Wdrożenie aplikacji na klastrze Kubernetesa wiąże się z definicją różnego rodzaju obiektów, reprezentujących komponenty potrzebne do poprawnego działania aplikacji na środowisku tegoż orkiestratora.

W zależności z jakim typem aplikacji pracujemy, także ilość plików może być mniejsza lub większa, ale gdy myślimy o wielu środowiskach, to już staje się to przytłaczające dla osoby, która musi dokonać modyfikacji.

Helm pozwala na definiowanie tzw. chartów czyli pakietów zawierających plik – szablony i wartości definiujące daną aplikację, w rezultacie pomaga w instalowaniu i aktualizacji nawet najbardziej złożonych aplikacji.

Tak jak przypadku Dockera to nie tylko samo narzędzie, ale duże community (https://artifacthub.io/) dostarczające gotowe konfiguracje, dlatego ich zaaplikowanie na klaster to kwestia zaledwie kilku minut.

Każde wdrożenie charts/aplikacji zapisuje się w secrets kubernetesa danego namespace, dzięki czemu jesteśmy w stanie np. wersjonować, udostepniać, hostować czy zrobić rollback.

Dzięki Helm udostępnimy charty własnych aplikacji, ale także przygotujemy odtwarzalne kompilacje tych aplikacji. Możemy również zarządzać release’ami pakietów Helm. Utworzony i przetestowany chart możemy ponownie wykorzystać w wielu grupach w organizacji i poza nią. 

Architektura Helm 3

Architektura Helm 3

Helm bazuje na kilku kluczowych komponentach. Są to:

  • Charty – czyli wstępnie skonfigurowane zasoby Kubernetes – niezbędne do uruchomienia aplikacji;
  • Release – instancja charta uruchomiona w klastrze Kubernetes;
  • Repozytorium – miejsce, w którym gromadzony są i udostępniane charty. 

W Helm 3, klient Helm współdziała bezpośrednio z serwerem API Kubernetes (w Helm 2 pośrednikiem pomiędzy klientem a API był Tiller). 

Biorąc pod uwagę development, charty w Helm 3 są łatwe w utrzymaniu i zabezpieczeniu. Od strony operacyjnej zyskujemy m.in. automatycznie aktualizowane wdrożenia, czy zabezpieczenie zasobów przed usunięciem.

Instalacja klienta lokalnie

Helm ułatwia pracę
Helm ułatwia pracę zwłaszcza wtedy, gdy nie mamy dużego doświadczenia w zakresie kontenerów.

Windows:

choco install kubernetes-helm

MacOS:

brew install helm

Linux (Debian/Ubuntu):

curl https://baltocdn.com/helm/signing.asc | sudo apt-key add –

sudo apt-get install apt-transport-https –yes

echo „deb https://baltocdn.com/helm/stable/debian/ all main” | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list

sudo apt-get update

sudo apt-get install helm

Inicjacja pierwszego charta

helm create test-chart

Po wykonaniu powyższej komendy powinniśmy otrzymać strukturę folderu jak poniżej:

struktura folderu

Jako pierwszy – Chart.yaml – opisujący chart jak nazwa, wersja.

Następnie – Charts – pusty folder, mogący zawierać inne charty od których ten będzie zależny.

Ponadto – Templates, który zawiera definicje obiektów kubernetesowych w postaci Helma i jest kluczowy w jego tworzeniu

Na koniec – Values.yaml – czyli wartości, które będą podstawiane do templates, dzięki czemu nie musimy np. tworzyć oddzielnych obiektów k8s dla danego środowiska.

Przykładowy template dla obiektu service

apiVersion: v1

kind: Service

metadata:

  name: {{ .Release.Name }}

spec:

  type: {{ .Values.service.type }}

  ports:

    – port: {{ .Values.service.port }}

      targetPort: http

      protocol: TCP

      name: http

  selector:

    {{- include „test-chart.selectorLabels” . | nindent 4 }}

Wszystkie elementy od Helma są zamykane w klamerkach {{ }} – składnia Golang.

Do wartości, które zdefiniujemy w values.yaml, odwołujemy się poprzez zmienną .Values. np.:

values.yaml

service:

  type: ClusterIP

  port: 80

odwołania w template service.yaml

{{ .Values.service.type }}

{{ .Values.service.port }}

…zostaną podstawione w miejsce ich definicji.

Cała składnia jak i przykłady, dobrze są opisane na oficjalnej stronie https://helm.sh/docs/chart_template_guide/getting_started/