Scaling, Releases & Upgrades

Bevor Sie starten

Sie haben einen bereitgestellten Pilotcluster, eine vertrauenswürdige kubeconfig, kubectl und Zugriff auf einen vereinbarten Namespace. Setzen Sie KUBECONFIG, CP_CONTEXT und CP_NAMESPACE über die Zugangsanleitung, bevor Sie Befehle ausführen. Die Beispiele verwenden eine POSIX-Shell und eine einzelne Zugangsdatei. Gruppierte Blöcke stoppen bei fehlenden Einstellungen, ohne Ihr Terminal zu schließen; sie stellen keine Infrastruktur bereit und vergeben keine Rechte. Mit dem Cluster verbinden →

Nutzen Sie ein geprüftes Manifest und einen bekannten Release-/Wiederherstellungsweg der Anwendung. Klären Sie, ob GitOps oder ein anderer Controller den Workload verwaltet: Direkte Änderungen können von ihm überschrieben werden.

Drei unterschiedliche Änderungen

Cloud-Oberfläche, automatisches Infrastruktur-Scaling und unterstützte Upgrade-Vorgänge müssen für den Pilot bestätigt werden. Diese Workload-Befehle versprechen keine Self-Service-Oberfläche für den Cloud-Lifecycle.

Zustandslose Anwendung gezielt skalieren

In der Wegwerfübung cloud-demo verändert der folgende Befehl das Deployment auf zwei Replikate, sofern die Anwendung mehrere Instanzen unterstützt und Quote bzw. Kapazität passen. Er fügt keinen Worker hinzu. Bei Controller-Verwaltung ändern Sie stattdessen dessen Quellkonfiguration.

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" scale deployment/cloud-demo --replicas=2
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout status deployment/cloud-demo --timeout=300s
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get pods -l app=cloud-demo
)

HPA benötigt geeignete Metriken und Grenzen und kann mit einer manuell verwalteten Replikatanzahl kollidieren. Bestätigen Sie Verfügbarkeit, maximale Skalierung und Kapazitäts-/Kostenbehandlung vor Aktivierung. Zwei Replikate in einer Ausfalldomäne sind keine HA-Garantie.

Release mit überprüfbarem Rückweg

1. 01

   Zielversion prüfen

   Freigegebenes Image festlegen, Konfiguration und Datenbankschema prüfen sowie Server-Dry-Run/Diff ausführen. Vorheriges Manifest und Image verfügbar halten.

2. 02

   Ergebnis beobachten

   Über den verantwortlichen Verwaltungsweg anwenden, Rollout prüfen und einen wesentlichen Nutzungsablauf testen. Ready ist notwendig, belegt aber kein fachlich korrektes Verhalten.

3. 03

   Wiederherstellung nach Fehler wählen

   Ein Deployment-Rollback stellt ein früheres Pod-Template wieder her. Er macht keine Datenbankmigration, Secret-Änderung oder externe Nebenwirkung rückgängig. Dafür gilt der anwendungsspezifische Wiederherstellungsplan.

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout history deployment/cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout status deployment/cloud-demo --timeout=300s
)

Nur bei einer manuell verwalteten zustandslosen Übung setzen Sie CP_REVISION auf die geprüfte vorherige Revision. Prüfen Sie zuerst die Kompatibilität und führen Sie anschließend die Änderung unten aus. Bei deklarativ verwalteten Workloads stellen Sie stattdessen das geprüfte Quellmanifest wieder her.

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
: "${CP_REVISION:?Set the verified prior revision}"
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout undo deployment/cloud-demo --to-revision="$CP_REVISION"
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout status deployment/cloud-demo --timeout=300s
)

Kubernetes-Wartung gemeinsam vorbereiten

• ✓
  Zielversion sowie Anwendungs-/API-Kompatibilität bestätigen; Zielkonfiguration vorher testen.
• ✓
  Unterbrechungsgrenzen, Wartungsfenster, Ansprechpartner und Beobachtung während des Vorgangs vereinbaren.
• ✓
  Replikate, Disruption-Regeln, planbare Reserve und Datenwiederherstellung vor Worker-Austausch prüfen.
• ✓
  Anwendungsabnahme nach Wartung und Wiederherstellungsverantwortung festlegen. Versions-Downgrade ist kein vorausgesetzter Rückweg.

Führen Sie anhand dieser Kundenanleitungen kein Node-Drain, Betriebssystemupdate oder Clusterupgrade aus. Fordern Sie den vereinbarten Managed-Vorgang an und dokumentieren Sie sein Ergebnis im Änderungsprotokoll.