Helm Charts: Pakethantering för Kubernetes
Kubernetes-distributioner med Helm-pakethantering
Helm har revolutionerat Kubernetes-anslutna applikationsdistributioner genom att introducera pakethanteringskoncept som är bekanta från traditionella operativsystem.
När antalet Kubernetes ökar blir det utmanande att hantera komplexa applikationer med dussintals YAML-filer. Helm Charts löser detta problem genom att paketera alla resurser i versionerade, konfigurerbara paket.
Det här trevliga bilden är genererad av AI-modellen Flux 1 dev.
Förstå Helm: Kubernetes Pakethanterare
Helm är för Kubernetes vad apt är för Debian, yum för RedHat, eller Homebrew för macOS. Det paketerar Kubernetes-applikationer i Charts – samlingar av filer som beskriver relaterade Kubernetes-resurser. En enda Chart kan distribuera en komplett applikationsstack: webbservrar, databaser, cache-lager, ingress-regler och övervakningskomponenter. För de som är nya för Kubernetes, erbjuder en Kubernetes Cheatsheet essentiella kommandon och koncept för att komma igång.
Varför Helm är viktigt i modern DevOps
Minskad komplexitet: Istället för att hantera 20+ YAML-filer, hanterar du en Chart med anpassningsbara värden.
Reproducerbarhet: Distribuera identiska konfigurationer över utveckling, test och produktion med miljöspecifika värdeöverskridningar. Detta är särskilt värdefullt när du distribuerar komplexa mikrotjänstarkitekturer där konsistens är viktigt.
Versionshantering: Charts är versionerade, vilket möjliggör enkla återställningar och uppgraderingsspårning.
Gemenskapsökosystem: Tusenvis av färdiga Charts tillgängliga via Artifact Hub (tidigare Helm Hub) för populära applikationer som PostgreSQL, Redis, NGINX, Prometheus och fler.
Mallningskraft: Go-mallar möjliggör dynamisk resursgenerering baserat på inmatningsvärden, vilket minskar upprepning.
Helm Arkitektur och Grundläggande Begrepp
Helm 3 Arkitektur
Helm 3 förenklade arkitekturen genom att ta bort Tiller, den problematiska serversidokomponenten från Helm 2:
- Helm Klient: CLI-verktyg som interagerar direkt med Kubernetes API
- Chart: Paketformat som innehåller mallar och metadata
- Release: En instans av en Chart som körs i en Kubernetes-kluster
- Repository: Lagringsplats för Charts (HTTP-server eller OCI-register)
Nyckelkomponenter i en Helm Chart
my-app-chart/
├── Chart.yaml # Chart metadata och version
├── values.yaml # Standardkonfigurationsvärden
├── charts/ # Beroende charts
├── templates/ # Kubernetes-resursmallar
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── _helpers.tpl # Mallhjälpmedel
│ └── NOTES.txt # Post-installationsanteckningar
├── .helmignore # Filer att ignorera vid paketering
├── README.md
└── LICENSE
Skapa Din Första Helm Chart
Initiera en Ny Chart
helm create my-application
cd my-application
Det här genererar en start-Chart med exempelmallar för en distribution, tjänst och ingress.
Chart.yaml: Definiera Metadata
apiVersion: v2
name: my-application
description: En produktionsklar applikationschart
type: application
version: 1.0.0 # Chart-version
appVersion: "2.4.1" # Version av applikationen
maintainers:
- name: Ditt Team
email: team@company.com
dependencies:
- name: postgresql
version: "12.x.x"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
Values.yaml: Konfigurationshantering
Filen values.yaml definierar standardkonfigurationer som användare kan överskrida. Denna tillvägagångssätt separerar konfiguration från mallar, vilket gör det enkelt att hantera olika miljöer (utveckling, test, produktion) och anpassa distributioner utan att ändra mallfiler.
replicaCount: 3
image:
repository: myapp/backend
tag: "1.0.0"
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 80
ingress:
enabled: true
className: "nginx"
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
hosts:
- host: myapp.example.com
paths:
- path: /
pathType: Prefix
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 250m
memory: 256Mi
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 80
Mallar: Dynamiska Kubernetes Manifest
Mallar använder Go-mallningssyntax för att dynamiskt generera Kubernetes-resurser. Dessa mallar kan generera vilken typ av Kubernetes-resurs som helst, från enkla Distributionser till komplexa StatefulSets för tillståndsbaserade applikationer som kräver permanent lagring. För applikationer som behöver stabila identiteter och permanenta volymer, vill du använda StatefulSets istället för Distributionser, som beskrivs i vår guide om StatefulSets och Permanent Lagring i Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "my-application.fullname" . }}
labels:
{{- include "my-application.labels" . | nindent 4 }}
spec:
{{- if not .Values.autoscaling.enabled }}
replicas: {{ .Values.replicaCount }}
{{- end }}
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 | default .Chart.AppVersion }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- containerPort: 8080
protocol: TCP
resources:
{{- toYaml .Values.resources | nindent 10 }}
Mallhjälpmedel (_helpers.tpl)
Skapa återanvändbara mallfunktioner för att undvika upprepning:
{{/*
Utöka namnet på charten.
*/}}
{{- define "my-application.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}
{{/*
Skapa ett standard fullständigt applikationsnamn.
*/}}
{{- 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 }}
{{/*
Gemensamma etiketter
*/}}
{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
{{ include "my-application.selectorLabels" . }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}
Hantera Helm Charts: Installation och Operationer
Installera en Chart
# Installera från ett repository
helm install my-release bitnami/postgresql
# Installera från lokal katalog
helm install my-app ./my-application
# Installera med anpassade värden
helm install my-app ./my-application -f values-production.yaml
# Installera med inline-värdeöverskridningar
helm install my-app ./my-application \
--set replicaCount=5 \
--set image.tag=2.0.0
Uppgradera Releases
# Uppgradera med nya värden
helm upgrade my-app ./my-application -f values-production.yaml
# Uppgradera med atomisk återställning vid misslyckande
helm upgrade my-app ./my-application --atomic --timeout 5m
# Tvinga resursuppdateringar
helm upgrade my-app ./my-application --force
Återställning och Historia
# Visa release-historia
helm history my-app
# Återställ till tidigare version
helm rollback my-app
# Återställ till specifik revision
helm rollback my-app 3
Testning och Felsökning
# Torkörning för att se genererade manifest
helm install my-app ./my-application --dry-run --debug
# Mallrendering utan installation
helm template my-app ./my-application
# Lint chart för problem
helm lint ./my-application
# Testa release med testkrokar
helm test my-app
Avancerade Helm Funktioner
Chartberoenden
Helm Charts kan bero på andra Charts, vilket möjliggör att komponera komplexa applikationer från återanvändbara komponenter. Detta är särskilt användbart när du distribuerar mikrotjänster som behöver databaser, meddelandeköer eller andra stödjande tjänster. Definiera beroenden i Chart.yaml:
dependencies:
- name: redis
version: "17.x.x"
repository: "https://charts.bitnami.com/bitnami"
condition: redis.enabled
- name: postgresql
version: "12.x.x"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
Uppdatera beroenden:
helm dependency update ./my-application
Helm Krokar för Livscykelhantering
Krokar körs vid specifika punkter i release-livscykeln:
apiVersion: batch/v1
kind: Job
metadata:
name: {{ include "my-application.fullname" . }}-db-migration
annotations:
"helm.sh/hook": pre-upgrade,pre-install
"helm.sh/hook-weight": "5"
"helm.sh/hook-delete-policy": before-hook-creation
spec:
template:
spec:
containers:
- name: db-migrate
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
command: ["python", "manage.py", "migrate"]
restartPolicy: Never
Kroktyper inkluderar:
pre-install: Innan resurser installeraspost-install: Efter att alla resurser har installeratspre-upgrade: Innan uppgraderingpost-upgrade: Efter uppgraderingpre-delete: Innan borttagningpost-delete: Efter borttagningpre-rollback: Innan återställningpost-rollback: Efter återställning
Villkorlig Logik och Flödesstyrning
{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: {{ include "my-application.fullname" . }}
{{- with .Values.ingress.annotations }}
annotations:
{{- toYaml . | nindent 4 }}
{{- end }}
spec:
{{- if .Values.ingress.className }}
ingressClassName: {{ .Values.ingress.className }}
{{- end }}
rules:
{{- range .Values.ingress.hosts }}
- host: {{ .host | quote }}
http:
paths:
{{- range .paths }}
- path: {{ .path }}
pathType: {{ .pathType }}
backend:
service:
name: {{ include "my-application.fullname" $ }}
port:
number: {{ $.Values.service.port }}
{{- end }}
{{- end }}
{{- end }}
OCI Registry Support: Modern Chart Distribution
Sedan Helm 3.8 är OCI (Open Container Initiative) registry-stöd stabilt, vilket gör det möjligt att lagra Charts tillsammans med containrar.
Publicering till OCI Registry
# Logga in på registret
helm registry login registry.example.com
# Paketera charten
helm package ./my-application
# Skicka till OCI registry
helm push my-application-1.0.0.tgz oci://registry.example.com/charts
# Installera från OCI registry
helm install my-app oci://registry.example.com/charts/my-application --version 1.0.0
Fördelar med OCI Registrar
- Förenklad lagring: Charts och bilder på samma plats
- Standardverktyg: Använd befintlig registry-infrastruktur
- Bättre säkerhet: Utnyttja registry-autentisering och skanning
- Enklare hantering: Inget separat Chart-repository-server behövs
Bäst praxis för produktions Helm Charts
1. Values Struktur och Dokumentation
Dokumentera alla värden med kommentarer:
# -- Antalet repliker för applikationen
replicaCount: 3
# -- Bildkonfiguration
image:
# -- Bildrepository
repository: myapp/backend
# -- Bildhämtningspolicy
pullPolicy: IfNotPresent
# -- Bildtagg (standard till chart appVersion)
tag: ""
2. Resurshantering
Ange alltid resursbehov och gränser:
resources:
limits:
cpu: 1000m
memory: 1Gi
requests:
cpu: 500m
memory: 512Mi
3. Säkerhetskontexter
Definiera säkerhetskontexter för containrar:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
4. Hälsokontroller
Inkludera livs- och beredskapsprover:
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
5. Hantering av ConfigMap och Secrets
Rätt hantering av hemligheter är kritiskt för produktionsdistributioner. Använd externa hemlighetshanterare (Sealed Secrets, External Secrets Operator eller Vault) istället för att lagra hemligheter i värdefiler. Detta säkerställer att känslig data som databaslösenord, API-nycklar och certifikat hanteras säkert:
envFrom:
- secretRef:
name: {{ include "my-application.fullname" . }}-secrets
- configMapRef:
name: {{ include "my-application.fullname" . }}-config
6. Schema Validering
Skapa values.schema.json för att validera användarinmatning:
{
"$schema": "https://json-schema.org/draft-07/schema#",
"properties": {
"replicaCount": {
"type": "integer",
"minimum": 1
},
"image": {
"type": "object",
"properties": {
"repository": {
"type": "string"
},
"tag": {
"type": "string"
}
},
"required": ["repository"]
}
},
"required": ["image"]
}
7. NOTES.txt för Användarvägledning
Ge post-installationsinstruktioner:
1. Hämta applikations-URL genom att köra:
{{- if .Values.ingress.enabled }}
https://{{ (index .Values.ingress.hosts 0).host }}
{{- else if contains "NodePort" .Values.service.type }}
export NODE_PORT=$(kubectl get --namespace {{ .Release.Namespace }} -o jsonpath="{.spec.ports[0].nodePort}" services {{ include "my-application.fullname" . }})
export NODE_IP=$(kubectl get nodes --namespace {{ .Release.Namespace }} -o jsonpath="{.items[0].status.addresses[0].address}")
echo http://$NODE_IP:$NODE_PORT
{{- end }}
2. Övervaka distributionen:
kubectl --namespace {{ .Release.Namespace }} get pods -l "app.kubernetes.io/name={{ include "my-application.name" . }}"
Helm Chart Testning och CI/CD Integration
Chart Testning med chart-testing (ct)
# Installera chart-testing
brew install chart-testing
# Kontrollera charts
ct lint --config ct.yaml
# Installera och testa charts
ct install --config ct.yaml
GitHub Actions Exempel
name: Helm Chart CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
lint-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: Konfigurera Helm
uses: azure/setup-helm@v3
with:
version: 3.12.0
- name: Konfigurera chart-testing
uses: helm/chart-testing-action@v2
- name: Kontrollera charts
run: ct lint --config ct.yaml
- name: Skapa kind-kluster
uses: helm/kind-action@v1
- name: Installera charts
run: ct install --config ct.yaml
GitOps med Helm: ArgoCD och Flux
GitOps-verktyg som ArgoCD och Flux integreras smidigt med Helm Charts, vilket möjliggör deklarativa, automatiserade distributioner. Dessa verktyg övervakar ditt Git-repository för ändringar och synkroniserar automatiskt Helm-releases, vilket gör kontinuerlig distribution enkelt. För komplexa mikrotjänstarkitekturer, överväg hur distribuerade transaktionsmönster som Saga-mönstret kan hjälpa till att hantera konsistens över tjänster distribuerade via Helm.
ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-application
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/myorg/my-app-chart
targetRevision: main
path: charts/my-application
helm:
valueFiles:
- values-production.yaml
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
Flux HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: my-application
namespace: flux-system
spec:
interval: 5m
chart:
spec:
chart: my-application
version: '1.x.x'
sourceRef:
kind: HelmRepository
name: my-charts
values:
replicaCount: 5
image:
tag: "2.0.0"
Felsökning av vanliga Helm-problem
Problem: Misslyckad uppgradering fast i väntande
# Kontrollera release-status
helm list --all-namespaces
# Hämta releaseinformation
helm status my-app -n namespace
# Tvinga bort om nödvändigt (använd försiktigt)
kubectl delete secret -n namespace -l owner=helm,name=my-app
Problem: Mallrenderingsfel
# Felsök mallrendering
helm template my-app ./my-application --debug
# Validera mot Kubernetes
helm template my-app ./my-application | kubectl apply --dry-run=client -f -
Problem: Värden inte tillämpade
# Kontrollera sammanslagna värden
helm get values my-app
# Visa alla beräknade värden
helm get values my-app --all
Helm Ecosystem och Verktyg
Helm-ecosystemet inkluderar många verktyg som utökar dess kapacitet och integrerar med andra Kubernetes-teknologier. När du distribuerar applikationer som kräver avancerade nätverksfunktioner som kommunikation mellan tjänster, trafikhantering och säkerhetspolicys, överväg att integrera med en Service Mesh med Istio och Linkerd, som kan distribueras och hanteras genom Helm Charts.
Väsentliga Verktyg
- Helmfile: Deklarativ specifikation för att distribuera Helm Charts
- Helm Diff: Förhandsgranska ändringar innan uppgradering
- Helm Secrets: Hantera hemligheter med SOPS
- Nova: Hitta föråldrade Helm Charts
- Pluto: Detektera föråldrade Kubernetes-API:er
Exempel Helmfile
repositories:
- name: bitnami
url: https://charts.bitnami.com/bitnami
releases:
- name: postgresql
namespace: database
chart: bitnami/postgresql
version: 12.x.x
values:
- postgresql:
auth:
database: myapp
username: appuser
- name: my-app
namespace: production
chart: ./charts/my-application
values:
- values-production.yaml
needs:
- database/postgresql
Framtiden för Helm
Helm-ecosystemet fortsätter att utvecklas:
- OCI-Nativ: Full övergång till OCI-registrar som standard
- Förbättrad säkerhet: Bättre hantering av hemligheter och signering
- Prestanda: Snabbare rendering och installation för stora Charts
- WASM-stöd: WebAssembly för Chart-plugins och tillägg
- Bättre validering: Förbättrad schemavalidering och policygenomförande
Slutsats
Helm har blivit standarden för Kubernetes-pakethantering, och att behärska det är avgörande för moderna DevOps-praxis. Genom att förstå Chart-struktur, mallning, värdeshantering och bäst praxis kan du skapa underhållbara, säkra och skalbara Kubernetes-distributioner.
Börja med enkla Charts, inför gradvis avancerade funktioner som hooks och beroenden, och integrera med GitOps-verktyg för produktionsnivåinfrastruktur. Helm-communityn erbjuder tusentals färdiga Charts, men den verkliga kraften ligger i att skapa anpassade Charts som är anpassade efter din organisations behov. Oavsett om du distribuerar stateless-applikationer eller stateful-workloads som kräver permanent lagring, förenklar Helm komplexiteten i Kubernetes-resurshantering. För team som sätter upp nya Kubernetes-kluster, överväg att installera Kubernetes med Kubespray eller utforska Kubernetes-distributioner som k3s eller MicroK8s för utvecklingsmiljöer. Om du utvärderar vilken distribution som passar dina homelab- eller småklusterbehov, se vår omfattande jämförelse av Kubernetes-distributioner för detaljerad analys.
Användbara länkar
- Officiell Helm-dokumentation
- Artifact Hub - Upptäck Helm Charts
- Helm GitHub-repository
- Helm bästa praxis guide
- Chart testverktyg
- Helmfile
- ArgoCD
- Flux CD
- Bitnami Charts-repository
- Kubernetes snabbkommandon
- Installera Kubernetes med Kubespray
- Jämförelse av Kubernetes-distributioner för en 3-nod homelab
- Kubernetes-distributioner - snabb översikt av kubeadm, k3s, MicroK8s, Minikube, Talos Linux och RKE2
- Service Mesh med Istio och Linkerd
- StatefulSets och permanent lagring i Kubernetes
- Saga-mönster i distribuerade transaktioner