Kubernetes Helm Charts w 2026: Pakietowanie, Wdrażanie i Pytania Rekrutacyjne

Kubernetes Helm Charts upraszczają wdrażanie aplikacji poprzez pakowanie wszystkich zasobów Kubernetes w pojedynczy, wersjonowany artefakt. Helm 3, aktualna stabilna wersja, eliminuje potrzebę używania Tillera i wprowadza wsparcie dla rejestrów OCI, co czyni dystrybucję chartów bardziej bezpieczną i zestandaryzowaną. Ten poradnik obejmuje tworzenie chartów, templating, strategie wdrożeń oraz najczęściej zadawane pytania rekrutacyjne.

Struktura i Komponenty Helm Chart

Helm chart to katalog o predefiniowanej strukturze. Nazwa chartu staje się nazwą katalogu, a każdy plik pełni określoną funkcję w procesie pakowania i wdrażania.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

apiVersion: v2 wskazuje kompatybilność z Helm 3. Pole version śledzi zmiany chartu, podczas gdy appVersion odzwierciedla wersję wdrożonej aplikacji. Zależności deklarują inne charty wymagane przez ten chart, z opcjonalnymi warunkami do ich włączania lub wyłączania.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

Wartości definiują domyślną konfigurację, którą użytkownicy nadpisują podczas instalacji. Zagnieżdżanie wartości pod znaczącymi kluczami utrzymuje konfiguracje uporządkowane i samodokumentujące się.

Tworzenie Deploymentów Kubernetes z Szablonami Helm

Szablony Helm używają Go templating z funkcjami Sprig do dynamicznego generowania manifestów Kubernetes. Obiekt {{ .Values }} zapewnia dostęp do zawartości values.yaml, podczas gdy {{ .Release }} zawiera metadane wdrożenia.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Funkcja nindent dodaje nową linię i wcięcie, co jest krytyczne dla generowania YAML. Użycie include z nazwanymi szablonami (zdefiniowanymi w _helpers.tpl) utrzymuje szablony zgodne z zasadą DRY i łatwe w utrzymaniu.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Szablony pomocnicze standaryzują konwencje nazewnictwa i etykiety dla wszystkich zasobów, zapewniając spójność z zalecanymi etykietami Kubernetes.

Zależności i Subcharty Helm

Złożone aplikacje często zależą od baz danych, cache'y lub kolejek wiadomości. Zależności Helm pozwalają osadzać je jako subcharty, zarządzane automatycznie podczas instalacji.

# Aktualizacja zależności przed pakietowaniem
helm dependency update ./my-application

# Budowanie zależności (tworzy katalog charts/)
helm dependency build ./my-application

Polecenie helm dependency update pobiera zależności do katalogu charts/. Zależności warunkowe używają wartości do przełączania włączenia:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Ten wzorzec umożliwia konfiguracje specyficzne dla środowiska, gdzie produkcja używa usług zarządzanych, podczas gdy development korzysta z baz danych w klastrze.

Wdrażanie Helm Charts z Zarządzaniem Release'ami

Helm śledzi wdrożenia jako release'y, umożliwiając wersjonowane rollbacki i aktualizacje. Każdy release zachowuje historię dla celów audytu i odtwarzania.

# Instalacja chartu z niestandardowymi wartościami
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Aktualizacja istniejącego release'u
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

Flaga --atomic zapewnia automatyczny rollback nieudanych aktualizacji. Flaga --timeout określa, jak długo Helm czeka na gotowość zasobów przed ogłoszeniem niepowodzenia.

# Wyświetlanie historii release'u
helm history my-release -n production

# Rollback do poprzedniej rewizji
helm rollback my-release 2 -n production

# Odinstalowanie release'u
helm uninstall my-release -n production --keep-history

Flaga --keep-history zachowuje rekordy release'u nawet po odinstalowaniu, co jest przydatne dla zgodności z regulacjami i debugowania.

Strategie Testowania i Walidacji Helm Charts

Testowanie chartów Helm przed wdrożeniem wyłapuje błędy szablonów i problemy konfiguracyjne na wczesnym etapie. Helm dostarcza wbudowane narzędzia do lintowania i testów dry-run.

# Lint chartu pod kątem błędów i najlepszych praktyk
helm lint ./my-application

# Renderowanie szablonów lokalnie bez wdrażania
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run przeciwko API klastra
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

Polecenie helm template renderuje manifesty lokalnie, co jest użyteczne w pipeline'ach CI walidujących wygenerowany YAML. Flaga --dry-run wysyła manifesty do serwera API Kubernetes w celu walidacji bez tworzenia zasobów.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Hooki Helm z helm.sh/hook: test uruchamiają się po helm test my-release, walidując poprawne działanie wdrożeń po instalacji.

Zaawansowane Techniki Templateowania Helm

Charty produkcyjne wymagają logiki warunkowej, pętli i transformacji danych. Funkcje Sprig rozszerzają szablony Go o narzędzia do manipulacji stringami, kodowania i sterowania przepływem.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

Funkcja range iteruje po mapach i listach. Funkcja b64enc koduje wartości w base64 dla sekretów Kubernetes. Operatory pipe łańcuchują funkcje do transformacji danych.

Pytania i Odpowiedzi Rekrutacyjne o Helm Charts

Rozmowy rekrutacyjne często testują wiedzę o Helm poprzez pytania koncepcyjne i praktyczne. Poniżej przedstawiono najczęściej poruszane tematy.

Jaka jest różnica między helm install a helm upgrade --install?

helm install tworzy nowy release i kończy się niepowodzeniem, jeśli release już istnieje. helm upgrade --install (z flagą --install) tworzy nowy release, jeśli nie istnieje, lub aktualizuje go, jeśli istnieje. Pipeline'y CI/CD zazwyczaj używają helm upgrade --install dla idempotentnych wdrożeń.

Jak przekazywać wrażliwe dane do chartów Helm?

Istnieją trzy podejścia: zewnętrzne menedżery sekretów (Vault, AWS Secrets Manager), zaszyfrowane pliki values (SOPS, sealed-secrets) lub sekrety Kubernetes tworzone poza Helm i referencowane w szablonach. Należy unikać przechowywania sekretów w jawnych plikach values.yaml commitowanych do systemu kontroli wersji.

Czym są hooki Helm i kiedy należy ich używać?

Hooki wykonują się w określonych punktach cyklu życia release'u: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback oraz test. Typowe zastosowania obejmują migracje baz danych przed aktualizacjami, wysyłanie powiadomień po wdrożeniach lub uruchamianie testów integracyjnych.

Jak obsługuje się wersjonowanie chartów?

Pole version w Chart.yaml śledzi zmiany chartu używając wersjonowania semantycznego. Pole appVersion śledzi wersję wdrożonej aplikacji. Należy inkrementować version dla każdej modyfikacji chartu, nawet jeśli wersja aplikacji pozostaje bez zmian.

Jaki jest cel .helmignore?

Podobnie jak .gitignore, .helmignore wyklucza pliki z pakowania chartu. Typowe wpisy obejmują *.tgz (unikanie pakowania poprzednich buildów), .git/, dokumentację *.md niepotrzebną w runtime oraz pliki konfiguracyjne CI.

Więcej informacji o przygotowaniu do rozmów kwalifikacyjnych z Kubernetes można znaleźć w modułach Kubernetes Podstawy oraz Kubernetes Zaawansowany na SharpSkill.

Podsumowanie

Praktyczne wnioski dotyczące pracy z chartami Helm:

• Strukturyzacja chartów z jasnym podziałem między metadanymi Chart.yaml, wartościami domyślnymi values.yaml i katalogiem templates zawierającym manifesty Kubernetes
• Używanie szablonów pomocniczych w _helpers.tpl do standaryzacji nazewnictwa i etykiet dla wszystkich zasobów
• Zarządzanie zależnościami przez Chart.yaml z warunkowym włączaniem dla konfiguracji specyficznych dla środowiska
• Testowanie chartów za pomocą helm lint, helm template i helm install --dry-run przed wdrożeniem na produkcję
• Śledzenie release'ów ze znaczącymi nazwami i używanie flagi --atomic dla automatycznego rollbacku przy nieudanych aktualizacjach
• Przechowywanie sekretów w zewnętrznych menedżerach zamiast w jawnych plikach values