Helm Charts w Kubernetes – zarządzanie aplikacjami i automatyzacja wdrożeń
Helm Charts w Kubernetes – zarządzanie aplikacjami i automatyzacja wdrożeń
Kubernetes jest niezwykle elastyczny, ale ta elastyczność ma swoją cenę.
Prosta aplikacja może wymagać kilku obiektów YAML:
- Deployment,
- Service,
- ConfigMap,
- Secret,
- Ingress,
- PersistentVolumeClaim,
- NetworkPolicy,
- ServiceAccount.
Przykładowa aplikacja produkcyjna:
Application
├── Deployment.yaml
├── Service.yaml
├── ConfigMap.yaml
├── Secret.yaml
├── Ingress.yaml
├── ServiceAccount.yaml
└── NetworkPolicy.yaml
Przy jednej aplikacji nie jest to duży problem.
Ale co, gdy mamy:
- 50 mikroserwisów,
- kilka środowisk,
- różne konfiguracje,
- wiele zespołów?
Wtedy ręczne zarządzanie manifestami YAML staje się trudne.
Rozwiązaniem jest Helm.
Czym jest Helm?
Helm to menedżer pakietów dla Kubernetes.
Można go porównać do:
aptw Debianie,dnfw Red Hat,npmdla Node.js,pipdla Python.
Zamiast instalować aplikację:
kubectl apply -f app.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
możemy użyć:
helm install my-app ./chart
Helm Chart – czym jest?
Chart to pakiet zawierający:
- szablony Kubernetes YAML,
- wartości konfiguracyjne,
- metadane aplikacji,
- zależności.
Struktura przykładowego Charta:
my-application/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ └── configmap.yaml
└── charts/
Architektura Helm
Schemat działania:
Developer
|
↓
Helm Chart
|
↓
Template Engine
|
↓
Kubernetes YAML
|
↓
Kubernetes API Server
|
↓
Pods / Services / Deployments
Helm Chart vs zwykłe YAML
Bez Helm:
replicas: 3
image: nginx:1.27
Każde środowisko wymaga osobnego pliku:
production.yaml
staging.yaml
development.yaml
Problem:
- duplikacja,
- trudne utrzymanie,
- błędy konfiguracji.
Z Helm:
Chart
+
values-production.yaml
+
values-staging.yaml
+
values-development.yaml
Jedna definicja aplikacji, wiele konfiguracji.
Instalacja Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
Sprawdzenie:
helm version
Tworzenie własnego Chartu
Nowy projekt:
helm create myapp
Powstanie:
myapp/
├── Chart.yaml
├── values.yaml
├── templates/
└── charts/
Chart.yaml
Zawiera informacje o aplikacji.
Przykład:
apiVersion: v2
name: myapp
description: My Kubernetes Application
type: application
version: 1.0.0
appVersion: "2.0"
values.yaml – konfiguracja
To najważniejszy plik użytkownika.
Przykład:
replicaCount: 3
image:
repository: nginx
tag: "1.27"
service:
type: ClusterIP
port: 80
Template wykorzystuje te wartości:
replicas: {{ .Values.replicaCount }}
Podczas instalacji Helm zamienia:
{{ .Values.replicaCount }}
na:
3
Helm Templates
Helm wykorzystuje silnik szablonów Go Template.
Przykład:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}
spec:
replicas: {{ .Values.replicaCount }}
Po renderowaniu:
metadata:
name: production-app
spec:
replicas: 3
Instalacja aplikacji
Przykład:
helm install nginx ./mychart
Sprawdzenie:
helm list
Rezultat:
NAME
nginx
STATUS
deployed
Helm Release
Każda instalacja Helm tworzy Release.
Przykład:
Chart
↓
Release
↓
Kubernetes Resources
Możemy mieć:
nginx-production
nginx-staging
nginx-test
z tego samego Chartu.
Aktualizacja aplikacji
Zmiana wartości:
replicaCount: 5
Aktualizacja:
helm upgrade nginx ./mychart
Helm wykona:
Old Version
↓
Compare
↓
Apply Changes
↓
New Version
Rollback
Jedna z największych zalet Helm.
Sprawdzenie historii:
helm history nginx
Przykład:
REVISION
1
2
3
Powrót:
helm rollback nginx 2
Helm Repository
Helm pozwala korzystać z gotowych repozytoriów.
Dodanie repo:
helm repo add bitnami https://charts.bitnami.com/bitnami
Aktualizacja:
helm repo update
Wyszukiwanie:
helm search repo nginx
Instalacja:
helm install database bitnami/mysql
Popularne Helm Charts
Najczęściej używane:
- NGINX,
- PostgreSQL,
- Redis,
- Prometheus,
- Grafana,
- Elasticsearch,
- RabbitMQ.
Helm i środowiska DevOps
Typowy pipeline:
Developer
↓
Git Repository
↓
CI/CD Pipeline
↓
Build Image
↓
Push Registry
↓
Helm Upgrade
↓
Kubernetes Cluster
Helm w środowisku produkcyjnym
Przykład:
Mamy trzy środowiska:
development
staging
production
Struktura:
charts/
└── application/
├── Chart.yaml
├── templates/
└── values.yaml
environments/
├── dev-values.yaml
├── stage-values.yaml
└── prod-values.yaml
Deployment:
Development:
helm upgrade app ./chart \
-f dev-values.yaml
Production:
helm upgrade app ./chart \
-f prod-values.yaml
Helm Security
Helm sam w sobie nie zabezpiecza aplikacji.
Może nawet ułatwić wdrożenie niebezpiecznej konfiguracji.
Przykład:
securityContext:
privileged: true
Dlatego Chart powinien uwzględniać:
- Pod Security Standards,
- RBAC,
- Network Policies,
- Security Context,
- Secrets Management.
Bezpieczny Security Context w Helm
values.yaml:
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
Template:
securityContext:
{{- toYaml .Values.securityContext | nindent 8 }}
Helm Secrets
Nie należy przechowywać haseł:
databasePassword: admin123
w:
values.yaml
Lepsze rozwiązania:
- Kubernetes Secrets,
- HashiCorp Vault,
- External Secrets Operator,
- Sealed Secrets.
Helm + GitOps
Nowoczesne środowiska często wykorzystują:
- ArgoCD,
- FluxCD.
Model:
Git Repository
↓
Helm Chart
↓
GitOps Controller
↓
Kubernetes
Git staje się źródłem prawdy.
Helm vs Kustomize
Częste pytanie:
Helm czy Kustomize?
| Cecha | Helm | Kustomize |
|---|---|---|
| Szablony | ✅ | ❌ |
| Package Manager | ✅ | ❌ |
| Reużywalność | ✅ | ✅ |
| Prostota | średnia | wysoka |
| Marketplace | duży | mały |
Często używa się obu:
Helm
+
Kustomize
+
GitOps
Najczęstsze błędy
❌ trzymanie haseł w values.yaml
❌ brak wersjonowania Chartów
❌ używanie latest dla obrazów
❌ zbyt duże monolityczne Charty
❌ brak testów przed wdrożeniem
❌ brak kontroli zmian
Helm Testing
Chart można testować:
helm lint ./chart
Renderowanie:
helm template ./chart
Test release:
helm test release-name
Najlepsze praktyki Helm
✅ wersjonuj Charty
✅ trzymaj konfigurację środowisk osobno
✅ używaj helm lint
✅ nie przechowuj sekretów w Git
✅ integruj z CI/CD
✅ stosuj GitOps
✅ dokumentuj wartości w values.yaml
✅ używaj konkretnych wersji obrazów
Helm w architekturze Kubernetes
Developer
|
↓
Git Repository
|
↓
Helm Chart
|
+------------+------------+
| |
values-prod.yaml values-dev.yaml
| |
+------------+------------+
|
↓
Kubernetes API
|
↓
+-----------------------+
| Cluster |
| |
| Deployments |
| Services |
| Ingress |
| ConfigMaps |
+-----------------------+
Podsumowanie
Helm stał się standardowym narzędziem zarządzania aplikacjami Kubernetes. Rozwiązuje problem powtarzalnych wdrożeń, pozwala tworzyć wersjonowane pakiety aplikacji i znacząco upraszcza pracę zespołów DevOps.
W dojrzałym środowisku Helm jest często elementem większego ekosystemu:
- Helm Charts – pakowanie aplikacji,
- CI/CD – automatyzacja wdrożeń,
- GitOps – kontrola zmian,
- RBAC – kontrola dostępu,
- Pod Security Standards – bezpieczeństwo kontenerów.
Najważniejsza zasada:
Helm nie zastępuje bezpieczeństwa Kubernetes – automatyzuje wdrażanie konfiguracji. Dlatego każdy Chart powinien być projektowany z myślą o bezpieczeństwie od pierwszej linii YAML.
Windows Server DHCP i NAT – Kompleksowy Przewodnik Windows Server to zaawansowana platforma, która oferuje wiele usług sieciowych, w tym Czytaj dalej
Dlaczego dysk SSD/HDD działa wolno mimo dobrego sprzętu – analiza problemów wydajności Wolne działanie dysku to jeden z najczęstszych problemów Czytaj dalej
