Generator Helm chart

Generator Helm chart

Helm pakuje manifesty Kubernetes w chart — wielokrotnie używalny szablon konfigurowany przez values.yaml. Generator Helm chart składa taki pakiet z formularza: dostajesz Chart.yaml, values.yaml oraz szablony Deployment i Service, a po zaznaczeniu opcji także Ingress. To standardowy punkt wyjścia do wdrażania aplikacji w klastrze.

Struktura chartu

Przykład szablonu

Fragment templates/deployment.yaml. Wartości nie są wpisane na sztywno, tylko pobierane z values.yaml:

replicas: {{ .Values.replicaCount }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
containerPort: {{ .Values.service.targetPort }}

Instalacja

Pod wynikiem generator podaje polecenia dopasowane do nazwy chartu. Dla nazwy myapp wyglądają tak:

helm lint ./myapp
helm template myapp ./myapp
helm install myapp ./myapp --dry-run
helm install myapp ./myapp

Późniejsza zmiana wersji obrazu bez edycji plików: helm upgrade myapp ./myapp --set image.tag=1.1.0.

Jak działa generator chartu Helm

Podajesz nazwę chartu, wersję chartu i wersję aplikacji, repozytorium i tag obrazu, liczbę replik (1–100), port kontenera i typ Service, a opcjonalnie host Ingressu. Narzędzie rozdziela te dane na dwa rodzaje plików: wartości trafiają do values.yaml, a szablony do katalogu templates/. Bez Ingressu powstają 4 pliki, z Ingressem 5. Każdy skopiujesz osobno, wszystkie naraz albo jako skrypt bash, który poleceniem mkdir -p i blokami cat > plik <<'HELM_EOF' tworzy katalog o nazwie chartu z podkatalogiem templates/. Nic nie jest przy tym instalowane w klastrze — powstaje wyłącznie tekst, który wgrywasz do repozytorium i uruchamiasz lokalnie lub w potoku CI.

Formularz sprawdza dane, zanim cokolwiek wygeneruje. Nazwa chartu może zawierać tylko małe litery, cyfry i myślniki (bez myślnika na początku i końcu, do 63 znaków), wersja chartu musi być w formacie SemVer, np. 0.1.0 albo 1.2.3-rc.1, port mieści się w zakresie 1–65535, a host Ingressu musi być poprawną domeną. Tag latest jest odrzucany. Jeśli któreś pole jest błędne, komunikat pojawia się przy nim, a chart nie powstaje.

Trzy szablony startowe ustawiają typowe warianty jednym kliknięciem: Web (Service ClusterIP, port 8080), API + Ingress (ClusterIP i włączony Ingress) oraz Worker (3 repliki i Service headless). Zmieniają tylko wymienione pola, resztę formularza zostawiają bez zmian.

Mechanizm opiera się na rozdzieleniu danych od szablonu. Wartości są podstawiane z values.yaml w momencie renderowania, więc jeden plik templates/deployment.yaml obsługuje dowolne środowisko — zmieniasz dane w values, a nie strukturę manifestu.

Helm scala wartości w ustalonej kolejności: najpierw domyślne z values.yaml, potem plik wskazany flagą -f, a na końcu pojedyncze nadpisania z --set. Wygrywa wartość stojąca najpóźniej, więc --set jest najsilniejszym źródłem. Chart.yaml trzyma metadane: nazwę chartu, wersję chartu i wersję aplikacji. Jest wymagany przy publikacji chartu w repozytorium i przy pracy z zależnościami.

Ustawienia bezpieczeństwa i zasobów w wygenerowanym chartcie

Deployment ma od razu zaostrzone ustawienia: runAsNonRoot: true, profil seccomp RuntimeDefault, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true i usunięte wszystkie capabilities. Sonda gotowości sprawdza połączenie TCP na porcie kontenera. W values.yaml zasoby są ustawione na requests 100m CPU i 128Mi pamięci oraz limits 500m CPU i 512Mi.

Te ustawienia mają skutki dla obrazu. Kontener musi działać jako użytkownik inny niż root, najlepiej z numerycznym USER w Dockerfile, bo przy nazwie użytkownika Kubernetes nie zweryfikuje runAsNonRoot. Aplikacja, która zapisuje do /tmp albo do katalogu cache, potrzebuje wolumenu emptyDir — chart go nie zawiera, więc dopisz go w templates/deployment.yaml. Service zawsze nasłuchuje na porcie 80 i przekazuje ruch na port kontenera (service.targetPort).

Przykład krok po kroku: chart myapp

1. Zostawiasz dane przykładowe: myapp, chart 0.1.0, aplikacja 1.0.0, obraz registry.example.com/myapp:1.0.0, 2 repliki, port 8080, ClusterIP, bez Ingressu. Powstają 4 pliki: Chart.yaml, values.yaml, templates/deployment.yaml i templates/service.yaml.
2. W Chart.yaml lądują metadane: name: myapp, version: 0.1.0 i appVersion: "1.0.0".
3. W values.yaml zapisane są wartości domyślne: replicaCount: 2, image.repository, image.tag: "1.0.0", service.port: 80 i service.targetPort: 8080.
4. Wklejasz skrypt w terminalu, co tworzy katalog myapp/, i uruchamiasz helm install myapp ./myapp. W klastrze powstaje Deployment z 2 replikami i Service na porcie 80.
5. Wdrażasz nowszą wersję obrazu bez dotykania plików: helm upgrade myapp ./myapp --set image.tag=1.1.0. Zmieniona zostaje dokładnie 1 wartość, a szablony pozostają nietknięte.
6. Gdy aplikacja ma być dostępna z zewnątrz, zaznaczasz „Dodaj Ingress” z hostem app.example.com. Pojawia się templates/ingress.yaml, a values.yaml dostaje sekcję ingress z enabled: true i hostem.

Tabela referencyjna: elementy chartu i skutki nadpisania

Praktyczne wskazówki

• Trzymaj dane wdrażane w values.yaml. Obraz, tag i liczbę replik definiuj raz, w values, a nie w treści szablonu. Wtedy zmiana środowiska sprowadza się do podmiany jednego pliku, a templates/deployment.yaml zostaje bez zmian.
• Nadpisuj przez -f dla środowisk, przez --set dla wyjątków. Osobny plik wartości dla stagingu i produkcji jest czytelniejszy niż długie polecenia, a --set nie zapisuje się w historii projektu.
• Podnoś version w Chart.yaml przy każdej zmianie szablonów, a appVersion przy zmianie wersji aplikacji. Ułatwia to wycofanie wdrożenia i publikację w repozytorium.
• Renderuj chart przed instalacją: helm template myapp ./myapp pokazuje gotowe manifesty bez dotykania klastra, a helm lint ./myapp wyłapuje błędy w strukturze chartu.
• Nie wklejaj sekretów do values.yaml. Wartości z tego pliku trafiają do repozytorium i do historii zmian. Hasła i klucze trzymaj poza chartem i wstrzykuj je przy wdrożeniu.

Ograniczenia generatora

• Sprawdza tylko dane z formularza. Narzędzie pilnuje formatu nazwy, wersji, tagu, portu i domeny, ale nie sprawdza, czy wyrenderowany Deployment przejdzie walidację API twojego klastra. Przed wdrożeniem użyj helm lint, helm template albo helm install --dry-run.
• Nie zna twojej infrastruktury. Ingress nie ma ingressClassName ani sekcji TLS i obsługuje jedną ścieżkę / z pathType Prefix. Klasę kontrolera, certyfikaty, klasy storage i polityki sieciowe dopisz samodzielnie.
• Brakuje subchartów, sekcji dependencies w Chart.yaml oraz hooków wdrożeniowych i migracyjnych. Przy złożonych aplikacjach chart z generatora jest punktem wyjścia.
• Chart nie zawiera zmiennych środowiskowych, wolumenów, sondy liveness, autoskalowania (HPA) ani obiektów Secret. Wartości wrażliwe musisz dostarczyć własnym mechanizmem, poza wygenerowanym chartem.