Ein Kubernetes-Paket muss installiert werden? Helm-Chart installieren und konfigurieren

#kubernetes #aks #helm

Eine Anwendung kann mehrere Kubernetes-Ressourcen benötigen, die gemeinsam installiert und konfiguriert werden sollen. Helm ist ein Paketmanager für Kubernetes. Es kombiniert Ressourcenvorlagen mit Konfigurationswerten und verwaltet die daraus entstehende Installation.

Begriff	Bedeutung in diesem Trip
Chart	Das Paket cloudtrips-web mit Vorlagen für ein NGINX-Deployment und einen ClusterIP-Service
Values	Einstellungen für die Vorlagen, beispielsweise die Replikatanzahl
Release	Eine Installation eines Charts, hier mit dem Namen ct-helm-web
Revision	Ein aufgezeichneter Installations-, Upgrade- oder Rollback-Schritt dieses Releases

Das Chart ist kein Container-Image. Es beschreibt Kubernetes-Ressourcen; das Deployment lädt weiterhin nginx:stable-alpine, um den Webserver zu starten. Ein Chart kann aus einem Repository, einer OCI-Registry oder einem lokalen Archiv stammen. Dieses Lab verwendet ein kleines vorbereitetes Archiv, damit du dich auf Helm konzentrieren kannst.

Verwende aks-ctlab-weu in UK West und deinen Kubernetes-Administrationszugriff. Starte den Cluster bei Bedarf. Entferne ct-capacity-check aus dem vorherigen Trip, falls es noch existiert, damit dessen hohe CPU-Requests keine Lab-Kapazität belegen. Die bisherige Anwendung ct-web kann bleiben.

Die Helm-Befehle laufen in Azure Cloud Shell → Bash. Der YAML-Editor im Portal wendet Manifeste an, erstellt aber kein Helm-Release. Anschließend prüfen wir die Ressourcen im Portal. Dieses Chart erstellt weder öffentliche IP noch persistenten Datenträger. Für die vorhandenen AKS-Nodes fallen weiterhin Kosten an.

Chart herunterladen und verbinden

Lade cloudtrips-web-0.1.0.tgz auf deinen Computer herunter. Öffne Cloud Shell → Bash und lade das Archiv über Upload/Download files → Upload hoch. Lasse es komprimiert. Die folgenden Befehle erwarten es unter ~/cloudtrips-web-0.1.0.tgz. Verwende bei Bedarf den von Cloud Shell angezeigten Pfad.

Verbinde dich vor dem Ausführen von Helm mit dem richtigen AKS-Cluster:

az account set --subscription "CloudTrips TEST"
az aks get-credentials \
  --resource-group rg-cloudtrips-aks-test-weu \
  --name aks-ctlab-weu \
  --overwrite-existing
kubelogin convert-kubeconfig -l azurecli
kubectl get nodes
helm version --short

Prüfe, ob die Nodes Ready sind und Helm seine Version ausgibt. Die Befehle verwenden deine aktuelle Azure-Anmeldung und Benutzerzugangsdaten; ein Download von Cluster-Admin-Zugangsdaten ist nicht nötig. Das Lab verwendet Chart-API v2 und Befehle, die Helm 3 und Helm 4 unterstützen.

Paket konfigurieren und Vorschau prüfen

Führe Folgendes aus:

mkdir -p ~/cloudtrips-helm
cp ~/cloudtrips-web-0.1.0.tgz ~/cloudtrips-helm/
cd ~/cloudtrips-helm

helm show chart ./cloudtrips-web-0.1.0.tgz
helm show values ./cloudtrips-web-0.1.0.tgz

cat > lab-values.yaml <<'EOF'
replicaCount: 2
EOF

helm template ct-helm-web ./cloudtrips-web-0.1.0.tgz \
  --namespace ct-helm \
  --values lab-values.yaml

Die Standard-Replikatanzahl des Charts beträgt 1. Deine lab-values.yaml überschreibt sie mit 2. Nicht überschriebene Einstellungen, einschließlich Image und Ressourcenanforderungen, behalten ihre Chart-Standardwerte.

helm show chart zeigt die Paketmetadaten. Chart-Version 0.1.0 bezeichnet das Paket; appVersion stable-alpine beschreibt den verwendeten Image-Tag. helm template gibt das erzeugte Kubernetes-YAML aus, ohne etwas zu installieren. Suche nach replicas: 2, einem Deployment namens ct-helm-web und einem gleichnamigen ClusterIP-Service.

Cloud Shell mit Values-Anpassung und gerendertem Chart mit zwei Replikaten.

Release installieren

helm install ct-helm-web ./cloudtrips-web-0.1.0.tgz \
  --namespace ct-helm \
  --create-namespace \
  --values lab-values.yaml \
  --wait --timeout 5m

helm list --namespace ct-helm
helm get values ct-helm-web --namespace ct-helm
kubectl get deployments,pods,services --namespace ct-helm

Der erste Befehl installiert das Release ct-helm-web im Namespace ct-helm und erstellt diesen bei Bedarf. --wait wartet auf die unterstützten Bereitschaftsbedingungen mit einem Zeitlimit von fünf Minuten. Erwarte den Release-Status deployed, Revision 1 und zwei bereite Anwendungs-Pods.

Falls die Installation das Zeitlimit überschreitet, prüfe Pods und Events. Ein Timeout entfernt das Release nicht automatisch. Prüfe vor einem erneuten Versuch helm status ct-helm-web -n ct-helm. Verwende nach dem Beheben der Ursache helm upgrade oder deinstalliere das fehlgeschlagene Release vor einer erneuten Installation.

Öffne im Portal aks-ctlab-weu → Kubernetes resources → Workloads → Deployments. Filtere nach ct-helm und öffne ct-helm-web. Prüfe die zwei bereiten Replikate. Unter Services and ingresses sollte der Service ct-helm-web den Typ ClusterIP und Port 80 haben.

AKS-Portal mit dem durch Helm installierten Deployment ct-helm-web und zwei bereiten Replikaten.

Anwendung prüfen

Führe diesen kleinen Client innerhalb des Clusters aus, um den internen Service aufzurufen:

kubectl run ct-helm-check --namespace ct-helm \
  --image=busybox:1.37 --restart=Never \
  --command -- sh -c 'wget -S -O - -T 15 http://ct-helm-web'

kubectl wait --for=jsonpath='{.status.phase}'=Succeeded \
  pod/ct-helm-check --namespace ct-helm --timeout=120s
kubectl logs ct-helm-check --namespace ct-helm
kubectl delete pod ct-helm-check --namespace ct-helm

Erwarte HTTP/1.1 200 OK und HTML mit Welcome to nginx!. Der Test-Pod beendet sich nach einem Aufruf und wird anschließend gelöscht. Er gehört nicht zum Helm-Release. Falls das Warten das Zeitlimit überschreitet, prüfe seine Logs und Events auf die Fehlerursache. Dieser ClusterIP-Service hat keine öffentliche Browseradresse.

Konfiguration mit Helm ändern

Erhöhe die Replikatanzahl über deine Values-Datei und aktualisiere das vorhandene Release:

cat > lab-values.yaml <<'EOF'
replicaCount: 3
EOF

helm upgrade ct-helm-web ./cloudtrips-web-0.1.0.tgz \
  --namespace ct-helm \
  --values lab-values.yaml \
  --wait --timeout 5m

helm history ct-helm-web --namespace ct-helm
kubectl get deployment ct-helm-web --namespace ct-helm

Erwarte 3 bereite Replikate und Revision 2. Die Chart-Version bleibt 0.1.0: Ein Upgrade kann die Konfiguration ändern, ohne die Chart-Version zu wechseln. Kubernetes setzt den daraus entstehenden gewünschten Zustand um.

Ändere die dauerhafte Konfiguration von Helm-verwalteten Ressourcen über die Values und helm upgrade. Eine direkte Änderung im Portal wird nicht in Helms Konfiguration aufgezeichnet und kann bei einem späteren Upgrade überschrieben werden.

Helm-Historie mit dem Upgrade und Deployment mit drei bereiten Replikaten.

Vorherige Konfiguration wiederherstellen

Wenn du die Schritte einmal ausgeführt hast, enthält Revision 1 die Konfiguration mit zwei Replikaten. Prüfe nach weiteren Upgrades zuerst helm history und wähle die passende Revision für den Rollback:

helm rollback ct-helm-web 1 --namespace ct-helm --wait --timeout 5m
helm history ct-helm-web --namespace ct-helm
kubectl get deployment ct-helm-web --namespace ct-helm

cat > lab-values.yaml <<'EOF'
replicaCount: 2
EOF

Das Deployment kehrt zu 2 Replikaten zurück. Helm zeichnet den Rollback als neue Revision auf und löscht die Historie nicht. Deine lokale Values-Datei wird dabei nicht verändert. Deshalb setzt der letzte Befehl auch lab-values.yaml wieder auf zwei Replikate zurück. Ein Helm-Rollback stellt die Release-Konfiguration wieder her, keine Datenbank oder Anwendungsdaten.

Release entfernen

helm uninstall ct-helm-web --namespace ct-helm
kubectl get deployments,pods,services --namespace ct-helm

Bei diesem Chart entfernt die Deinstallation Deployment, Pods und Service. Der Namespace ct-helm bleibt bestehen, weil er über --create-namespace erstellt wurde und keine Chart-Ressource ist. Lösche ihn unter Kubernetes resources → Namespaces, sobald er leer ist und nicht mehr gebraucht wird. Die bisherigen Ressourcen in ct-apps bleiben unberührt.

Behalte Chart-Archiv und Values-Datei, falls du die Übung wiederholen möchtest. Temporäre Cloud-Shell-Sitzungen bewahren lokale Dateien möglicherweise nicht auf. Stoppe den Cluster zwischen Sitzungen oder lösche seine Lab-Ressourcengruppe, wenn du AKS nicht mehr benötigst. Verbleibende Ressourcen können auch bei gestopptem Cluster Kosten verursachen.