W Kubernetesie, zarządzanie nawet prostą aplikacją wymaga stworzenia wielu powiązanych ze sobą manifestów YAML: Deployment, Service, które już poznaliśmy czy ConfigMap, Secret, Ingress, i innych, które dopiero zostaną przedstawione. Biorąc pod uwagę, że wdrożenie kompleksowej aplikacji, takiej jak WordPress z bazą danych, to już dziesiątki tych plików wyobraźmy sobie aktualizację tej aplikacji, zarządzanie różnymi środowiskami (dev, staging, prod) lub wersjami. Pojawiają się od razu problemy: Jak wersjonować konfigurację? Jak łatwo aktualizować lub wycofywać całą aplikację? Jak zarządzać zależnościami między komponentami? Tu właśnie Helm jest odpowiedzią na te wszystkie problemy i potrzeby.

To nie jest kolejne narzędzie do deployowania; to menedżer pakietów dla Kubernetesa, często nazywany „apt-get lub yum dla klastra”. Helm wprowadza koncepcję Chartów – spakowanych, wersjonowanych kolekcji prekonfigurowanych zasobów Kubernetes. Dzięki Helmowi, instalacja skomplikowanej aplikacji może być tak prosta, jak wykonanie jednego polecenia: helm install. Jego powstanie zrewolucjonizowało sposób, w jaki admini i deweloperzy wdrażają i zarządzają aplikacjami na Kubernetesie, stając się de facto standardem branżowym i projektem nadrzędnym CNCF, dlatego nie możemy pójść dalej bez omówienia sobie tego z jednej strony łatwego, a drugiej dość skomplikowanego zagadnienia.

Instalacja Helma

    Helm działa w architekturze klient-serwer. Klient helm komunikuje się z serwerem tiller (w wersji 2) lub bezpośrednio z API Kubernetesa (w wersji 3+, która jest obecnym standardem).

    Pobranie binarnego pliku helm i dodanie go do ścieżki systemowej.

    curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

    chmod 700 get_helm.sh

    ./get_helm.sh

    Podstawy pracy z Helmem

    Helm składa się z:

    1. Helm CLI – narzędzie wiersza poleceń,
    2. Chart – paczka z definicjami zasobów K8s,
    3. Repository – miejsce, w którym przechowuje się charty (np. ArtifactHub, Bitnami).

    Podstawowe komendy

    Wiemy, że to nie to nie będzie kompletna lista, ale do codziennej pracy.

    helm repo add <nazwa> <url>

    Dodaje nowe repozytorium chartów do lokalnej konfiguracji.
    Przykład: helm repo add bitnami https://charts.bitnami.com/bitnami

    helm repo list

    Wyświetla wszystkie dodane repozytoria.

    helm repo update

    Aktualizuje listę dostępnych chartów ze wszystkich repozytoriów.

    helm search repo <fraza>

    Wyszukiwanie chartów w lokalnie skonfigurowanych repozytoriach.
    Przykład: helm search repo nginx

    helm install <release-name> <repo/chart> [opcje]

    Instaluje nową aplikację (release) z chartu.
    Przykład: helm install my-nginx bitnami/nginx

    helm list [–all-namespaces]

    Lista wszystkich zainstalowanych release’ów (aplikacji) w danym namespace lub całym klastrze.

    helm status <release-name>

    Szczegółowy status danego release – jakie zasoby utworzono, w jakim są stanie.

    helm upgrade <release-name> <repo/chart> -f values.yaml

    Aktualizacja istniejącego release do nowej wersji chartu lub z nowymi wartościami.
    Przykład: helm upgrade my-nginx bitnami/nginx -f custom-values.yaml

    helm rollback <release-name> <revision>

    Cofnięcie release do poprzedniej wersji.
    Przykład: helm rollback my-nginx 1

    helm uninstall <release-name>

    Usunięcie aplikacji (release) z klastra.
    Przykład: helm uninstall my-nginx

    helm get values <release-name>

    Pobranie wartości konfiguracyjnych (`values.yaml`) użytych przy instalacji release.

    helm get manifest <release-name>

    Wyświetla wygenerowane manifesty YAML, które Helm zastosował w klastrze.

    helm show values <repo/chart>

    Wyświetla domyślne wartości (`values.yaml`) chartu, które możesz nadpisać.
    Przykład: helm show values bitnami/nginx

    helm dependency update

    Pobiera i aktualizuje zależności chartu (jeśli nasz chart korzysta z innych chartów).

    helm template <release-name> <repo/chart> -f values.yaml

    Renderuje szablony chartu do zwykłych plików YAML, bez instalowania ich w klastrze.
    Przykład: helm template my-nginx bitnami/nginx -f custom-values.yaml

    Struktura Chart’ów

    Charty w Helm to nic innego jak paczki aplikacyjne dla Kubernetes, które zawierają wszystkie potrzebne manifesty (Deployment, Service, Ingress, ConfigMap, Secret itd.) spakowane w jeden zestaw i uzupełnione o plik konfiguracyjny values.yaml. Dzięki temu aplikacja nie jest wdrażana jako zbiór osobnych plików YAML, tylko jako spójna, przenośna paczka.

    Struktura katalogu:

    mój-chart/          # Nazwa charta

    ├── Chart.yaml          # Metadane charta (nazwa, wersja, zależności)

    ├── values.yaml         # Domyślne wartości konfiguracyjne

    ├── templates/          # Katalog na szablony manifestów

    │   ├── deployment.yaml

    │   ├── service.yaml

    │   ├── configmap.yaml

    │   └── _helpers.tpl    # Pomocnicze szablony

    └── charts/             # Podkatalog na zależności (subcharts)

    Tworzenie Chartu

    helm create moja-aplikacja

    To polecenie generuje pełną, działającą strukturę katalogów z przykładowymi plikami, która jest doskonałym punktem startowym. Szablony są renderowane przez silnik Helm, który korzysta z Go templates. Dzięki temu możemy pisać w dobrze znanej nam konwencji.

    Przykładowy plik yaml.

    apiVersion: apps/v1

    kind: Deploymen
    metadata:
      name: {{ .Release.Name }}
    spec:
      replicas: {{ .Values.replicaCount }}
      template:
        spec:
          containers:
          – name: nginx
            image: „{{ .Values.image.repository }}:{{ .Values.image.tag }}”

    Kluczem do tworzenia uniwersalnych, reużywalnych chartów jest separacja logiki (szablony) od konfiguracji (values.yaml). Plik values.yaml to jest miejsce gdzie definiujemy domyślne ustawienia charta. Działa to jak taka domyślna konfiguracja startowa.

    np.:

    replicaCount: 2
    image:
      repository: nginx
      tag: "latest"
      pullPolicy: IfNotPresent
    service:
      type: ClusterIP
      port: 80
    ingress:
      enabled: false
      host: "domena.pl"

    Co warto podkreślić możemy w jednym miejscu tworzyć pliki odpowiadające za różne środowiska jak -prod.yaml -dev.yaml czy stage.yaml.

    Podsumowanie

    Helm to niezastąpione narzędzie w ekosystemie Kubernetesa, które rozwiązuje realny problem zarządzania złożonymi manifestami YAML. Dzięki Helmowi nie musimy ręcznie utrzymywać dziesiątek plików YAML, możemy łatwo parametryzować aplikacje i dostosowywać je do środowisk, mamy dostęp do setek gotowych paczek w repozytoriach, tworzymy własne charty i dzielimy się nimi w zespołach. Helm daje Kubernetesowi to, co apt/yum dało Linuxowi – standaryzację i automatyzację wdrożeń. Bez niego zarządzanie aplikacjami w klastrze szybko staje się chaosem.