Zero-Downtime-Migration zu Azure Kubernetes Service (AKS)

In diesem Artikel werden praktische, produktionsorientierte Ansätze für die Migration vorhandener Workloads zu Azure Kubernetes Service (AKS) und die Veröffentlichung neuer Anwendungsversionen in einem vorhandenen AKS-Cluster mit minimaler oder null Ausfallzeit beschrieben.

Schnelle Antwort: Führen Sie für eine Migration die Quell- und AKS-Umgebungen parallel aus und verschieben Sie den Datenverkehr schrittweise. Verwenden Sie für eine regelmäßige Anwendungsbereitstellung in einem AKS-Cluster ein rollierendes Update, eine Canary-Bereitstellung oder eine Blue-Green-Bereitstellung innerhalb des Clusters mit Bereitschaftstests, kontrollierten Traffic-Verlagerungen, Observability-Gates und einem getesteten Rollback.

Quick Runbook: 5 Schritte für Zero-Downtime AKS-Migration

1. Stellen Sie Ziel-AKS, Zertifikate, Netzwerke und Observability bereit.
2. Stellen Sie die App mit Readiness- und Liveness-Tests, PodDisruptionBudget und Ressourcenanforderungen bereit.
3. Daten mit Replikation, CSI-Snapshots oder Velero synchronisieren.
4. Verschieben Sie den Datenverkehr schrittweise, indem Sie relative DNS-Gewichtungen mit Traffic Manager oder genaue Anfrageprozentsätze mit Eingangs- oder Dienst-Mesh-Routing verwenden.
5. Überprüfen Sie SLO-Gates, und nehmen Sie die alte Infrastruktur außer Betrieb, wenn die Stabilitätskriterien erfüllt sind.

Hier erfahren Sie, wie Sie:

• Veröffentlichen Sie eine neue Anwendungsversion in einem vorhandenen AKS-Cluster, ohne den Cluster zu ersetzen.
• Vergleichen Sie Strategien für die Migration von Blue-Green, Canary und Rolling DNS.
• Führen Sie eine Prüfliste für die Vorbereitung vor der Migration mit AKS-spezifischen Befehlen aus.
• Führen Sie eine vollständige Blue-Green Clustermigration mithilfe von AKS und Azure Traffic Manager aus.
• Migrieren Sie persistente Daten mithilfe von CSI-Momentaufnahmen, Azure Files oder Velero.
• Erstellen Sie vor der Umstellung einen Rollback-Plan.

Vergleich der Migrationsstrategie

Verwenden Sie diesen Vergleich, um einen Migrationsansatz auszuwählen, der Ihrer Risikotoleranz, der Feststellbarkeitsfälligkeit und den Rollbackanforderungen entspricht.

Strategy	Auswirkung auf den Datenverkehr	Rollbackgeschwindigkeit	Complexity	AKS-Features und Azure-Dienste
Blue-Green (Cluster oder Namespace)	Minimal, da der Datenverkehr nur umgeschaltet wird, wenn die grüne Umgebung fehlerfrei ist	Sehr schnell, indem der Datenverkehr wieder auf die blaue Umgebung umgeschaltet wird	Mittel, da duplizierte Umgebungen und Verkehrsweiterleitung erforderlich sind	Azure Traffic Manager, öffentliche IP-Adressen für Load Balancer, Ingress
Canary	Sehr niedrig, da sich der Verkehr allmählich verschiebt	Schnell, indem die Canary-Gewichtung reduziert oder Canary-Pods herunterskaliert werden	Mittelhoch, da es eine Verkehrsteilung und Observierbarkeit erfordert	Ingress (nginx oder Gateway-API), Dienstgitter (Istio oder Linkerd), AKS-Eingangs-Add-Ons
Roll-DNS (TTL-basiert)	Hängt vom DNS-TTL ab; ein kürzerer TTL verringert die Auswirkungen	Mittel, da DNS-Caches das Rollback verzögern können	Niedrig, da die Einrichtung einfach, aber weniger präzise ist	Azure DNS, niedrige TTL-Datensätze, LoadBalancer oder Ingress

Arbeitsauslastungsentscheidungsmatrix

Verwenden Sie diese Tabelle, wenn Sie eine schnelle Strategieempfehlung nach Workloadtyp benötigen.

Workload-Typ	Empfohlene Strategie	Warum?	Kosten und Komplexität
Zustandslose Web/API	Canary, dann Blue-Green für die endgültige Umstellung	Progressive Risikoreduzierung mit schnellem Rollback	Medium
Zustandsbehaftete datenbankgestützte App	Blue-Green plus Replizieren-und-Heraufstufen-Datenpfad	Maximale Rollback-Kontrolle und ein klarer Failback-Weg	Hoch
Dateilastige Workloads	Blue-Green plus Azure Files Kopieren/Momentaufnahme	Einfachere Überprüfung der Datenparität vor dem Wechsel	Mittelhoch
Langfristige Aufträge/Mitarbeiter	Fortlaufendes Update oder Wartungsfenster mit Warteschlangenleerung	Geringere Auswirkungen auf benutzerorientiertes Routing, einfacheres Routing	Low-medium

Optionen für Tools zur progressiven Bereitstellung

• Manuelles gewichtetes Routing (Traffic Manager plus Ingress oder LoadBalancer): am besten, wenn Sie explizite Operatorsteuerung und einfache Abhängigkeiten benötigen.
• Service-Mesh-Routing (Istio oder Linkerd): am besten, wenn Sie feinkörniges Routing, Wiederholungen und Richtlinienkontrollen benötigen.
• Argo Rollouts oder Flagger: am besten, wenn Sie automatisierte progressive Zustellung, Metrikanalyse und automatisches Rollback wünschen.

Verwenden Sie Traffic Manager für die gewichtung auf globaler DNS-Ebene und kombinieren Sie sie mit Argo Rollouts oder Flagger, wenn Sie eine automatisierte Rolloutanalyse innerhalb des Clusters benötigen.

Freigeben einer Anwendung in einem vorhandenen AKS-Cluster

Für regelmäßige Anwendungs-Releases sind weder ein zweiter Cluster noch eine DNS-Umschaltung erforderlich. Verwenden Sie für eine zustandslose Anwendung, die bereits in AKS läuft, ein Kubernetes Deployment mit mehreren Replikas und einer RollingUpdate-Strategie. Kubernetes erstellt neue Pods im selben Cluster, wartet darauf, dass sie bereit sind, und entfernt dann schrittweise alte Pods.

Im folgenden Beispiel bleiben alle vorhandenen Replikate verfügbar, während Kubernetes jeweils einen zusätzlichen Pod startet:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  minReadySeconds: 10
  progressDeadlineSeconds: 600
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]

Stellen Sie sicher, dass der Cluster über genügend Kapazität für den Surge-Pod verfügt. Wenden Sie das Manifest an, überwachen Sie das Rollout, und überprüfen Sie das neue Image:

kubectl apply -f manifests/app-deployment.yaml
kubectl rollout status deployment/myapp --timeout=10m
kubectl get pods -l app=myapp -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready

Aktualisieren Sie bei späteren Releases das Image und überwachen Sie den Deployment-Rollout:

kubectl set image deployment/myapp myapp=myregistry.azurecr.io/myapp:v3
kubectl rollout status deployment/myapp --timeout=10m

Überwachen Sie während des Rollouts Fehlerrate, Latenz, Pod-Bereitschaft und Geschäftstransaktionen. Wenn ein Gate fehlschlägt, beenden Sie die Freigabe oder machen Sie sie rückgängig:

kubectl rollout pause deployment/myapp
kubectl rollout undo deployment/myapp
kubectl rollout status deployment/myapp --timeout=10m

Ein PodDisruptionBudget schützt Replikate während freiwilliger Entfernungsvorgänge wie z. B. dem Leeren von Knoten, aber es steuert nicht, wie eine Deployment Pods während des Rollouts einer Anwendung ersetzt. Verwenden Sie maxUnavailable und maxSurge, um die Releaseverfügbarkeit zu steuern. Für Anwendungen, die eine prozentuale Verteilung des Datenverkehrs auf Anfrageebene oder eine automatisierte Metrik-Analyse benötigen, lassen Sie stabile und Canary-Versionen im selben Cluster laufen und verwenden Sie einen Ingress-Controller, ein Service Mesh, Argo Rollouts oder Flagger, um den Datenverkehr schrittweise umzuleiten.

Bevor Sie anfangen

• Azure CLI Version 2.59.0 oder höher.
• kubectl mit Ihrem Quell-Cluster verbunden.
• AKS-Berechtigungen zum Erstellen und Verwalten von Clustern, Netzwerken und Identitäten.
• Ein getesteter Anwendungsintegritätsendpunkt, z. B. /healthz.
• Ein Rollbackbesitzer und eine Rollbackcheckliste, die vor der Datenverkehrsumstellung genehmigt wurden.
• Der Plan zur Reduzierung der DNS-TTL wurde mindestens 24 bis 48 Stunden vor der Umschaltung vorbereitet.

TLS- und Zertifikatvorbereitstellung

Stellen Sie Zertifikate in der grünen Umgebung vor der Datenverkehrsverlagerung bereit. Wenn die aktuelle Umgebung TLS beendet, exportieren und importieren Sie Zertifikate in Kubernetes-Geheimnisse (oder konfigurieren Sie cert-manager), bevor Sie die Umstellung durchführen.

# Example: create a TLS secret in the target namespace
kubectl create secret tls myapp-tls \
  --cert ./tls.crt \
  --key ./tls.key \
  --namespace production

Wenn Sie ACME (zum Beispiel Let's Encrypt) verwenden, schließen Sie die Domänenvalidierung vor der Umschaltung ab, um HTTPS-Fehler zu vermeiden.

Checkliste zur Vorbereitung auf die Migration

Führen Sie diese Prüfungen vor der Migration aus. Speichern Sie alle Exporte in der Versionssteuerung oder sicheren Speicher.

Exportieren von Kubernetes-Ressourcen aus dem Quellcluster

kubectl --context=current-prod-cluster get all --all-namespaces -o yaml > exports/all-namespaces-all-resources.yaml
kubectl --context=current-prod-cluster get deployments,statefulsets,daemonsets --all-namespaces -o yaml > exports/workloads.yaml
kubectl --context=current-prod-cluster get svc --all-namespaces -o yaml > exports/services.yaml
kubectl --context=current-prod-cluster get configmap,secret --all-namespaces -o yaml > exports/configs-secrets.yaml
kubectl --context=current-prod-cluster get pvc --all-namespaces -o yaml > exports/pvcs.yaml
kubectl --context=current-prod-cluster get ingress --all-namespaces -o yaml > exports/ingress.yaml

Important

Behandeln sie exportierte geheime Manifeste als vertrauliche Daten. Speichern Sie sie nur in sicheren Systemen.

Überprüfen von Abonnement-, Kontingent- und Netzwerkvoraussetzungen

az account show --query "{name:name, id:id, tenantId:tenantId}" -o table
az configure --defaults location=eastus resource_group=rg-aks-migration
az vm list-usage --location eastus -o table
az network public-ip list --resource-group rg-aks-migration -o table

Überprüfen von Identitäts- und RBAC-Anforderungen

az aks show --resource-group rg-aks-migration --name existing-aks --query aadProfile
az role assignment list --resource-group rg-aks-migration -o jsonc
az identity list --resource-group rg-aks-migration -o table

Bestätigen Sie die folgenden Elemente, bevor Sie fortfahren:

• Clusteradministratorgruppen und Entra ID Integrationsmodell.
• Verwaltete Identitätsbereiche und Rollenzuweisungen.
• Protokollierung, Metriken und Alarmierung sind in der Zielumgebung aktiviert.

Strategie-Anleitungen

Die nächsten Abschnitte enthalten ein vollständiges Blue-Green Beispiel und zwei kürzere Muster (Canary und Rolling DNS), die Sie an Ihre Workload anpassen können.

Migration eines Blue-Green-Clusters

In diesem Szenario wird der Produktionsdatenverkehr derzeit von einer Legacyumgebung unter app.example.com bereitgestellt. Sie erstellen einen neuen AKS-Cluster (aks-green), stellen die Workload bereit, registrieren sowohl alte als auch grüne Endpunkte in Azure Traffic Manager und verschieben den Datenverkehr schrittweise.

Grundlegende Anleitungen zur Migration finden Sie in der Migrationsübersicht für Azure Kubernetes Service (AKS).

1. Erstellen des grünen AKS-Clusters

RG=rg-aks-migration
LOCATION=eastus
CLUSTER=aks-green
NODE_COUNT=3

az group create --name $RG --location $LOCATION

az aks create \
  --resource-group $RG \
  --name $CLUSTER \
  --location $LOCATION \
  --node-count $NODE_COUNT \
  --enable-managed-identity \
  --network-plugin azure \
  --load-balancer-sku standard \
  --generate-ssh-keys \
  --enable-addons monitoring \
  --attach-acr <yourACRName> \
  --yes

Abrufen von Clusteranmeldeinformationen:

az aks get-credentials --resource-group $RG --name $CLUSTER --overwrite-existing
kubectl config use-context $CLUSTER

2. Bereitstellen der Workload mit Integritäts- und Unterbrechungssteuerungen

Erstellen Sie manifests/app-deployment.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:green
        resources:
          requests:
            cpu: 250m
            memory: 256Mi
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-lb
  labels:
    app: myapp
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  externalTrafficPolicy: Local

Die Ressourcenanforderungen sind Beispiele. Dimensionieren Sie CPU- und Speicheranforderungen anhand der beobachteten Workload-Nutzung und der Ergebnisse von Lasttests so, dass der Zielcluster das Scheduling- und Kapazitätsverhalten der Produktionsumgebung abbildet.

externalTrafficPolicy: Local behält Quell-IP bei, kann aber verwendbare Back-End-Endpunkte pro Knoten reduzieren. Externalisieren Sie bei Anwendungen mit persistenter Sitzung den Sitzungsstatus (z. B. Azure Cache for Redis) vor der Migration, um affinitätsbezogene Ausfälle während Datenverkehrsverlagerungen zu vermeiden.

Erstellen Sie manifests/pdb.yaml.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Ressourcen anwenden und Rollout überprüfen:

kubectl apply -f manifests/app-deployment.yaml
kubectl apply -f manifests/pdb.yaml
kubectl rollout status deployment/myapp
kubectl get svc myapp-lb -o wide

3. Rufen Sie den grünen Endpoint ab

kubectl get svc myapp-lb -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Verwenden Sie die zurückgegebene IP in den nächsten Schritten.

4. Erstellen Sie ein Azure Traffic Manager-Profil und Endpunkte

TM_PROFILE=myapp-tm

az network traffic-manager profile create \
  --name $TM_PROFILE \
  --resource-group $RG \
  --routing-method Weighted \
  --unique-dns-name myapp-tm-$RANDOM \
  --ttl 30 \
  --protocol http \
  --path /healthz \
  --interval 30 \
  --timeout 10

Fügen Sie den alten Endpunkt hinzu:

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name old-endpoint \
  --target old.example.com \
  --endpoint-status Enabled \
  --weight 100

Fügen Sie den grünen Endpunkt hinzu:

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name green-endpoint \
  --target <green-endpoint-ip> \
  --endpoint-status Disabled \
  --weight 0

Details zu Befehlen finden Sie unter az network traffic-manager profile and az network traffic-manager endpoint.

5. Hochfahren des Datenverkehrs auf die grüne Umgebung

Beginnen Sie mit einer niedrigen Gewichtung und beobachten Sie den Systemzustand und die Latenz.

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.endpointStatus=Enabled \
  --weight 10

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=90

Fahren Sie mit stufenweisen relativen Gewichtungsverschiebungen fort, wie etwa 50:50 und dann 10:90 für „alt“ und „grün“. Traffic Manager wählt einen Endpunkt für jede DNS-Abfrage basierend auf diesen relativen Gewichtungen aus. die Gewichtungen garantieren keine genauen Anforderungsprozentsätze. DNS-Antworten werden von Clients und rekursiven Resolvern zwischengespeichert, wodurch die beobachtete Verteilung schief werden kann. Halten Sie jede Phase mindestens so lange an, wie die im Profil festgelegte TTL beträgt, zuzüglich ausreichend Zeit, um repräsentativen Anwendungsdatenverkehr zu messen, bevor Sie fortfahren. Verwenden Sie ein L7-Eingangs- oder Dienstgitter, wenn Sie eine präzise Verteilung pro Anforderung benötigen.

Umstellungskriterien, Überwachungsgates und Rollback-Playbook

Definieren Sie explizite Gates vor jeder Erhöhung des Datenverkehrs.

Beispieltore

• Rollback durchführen, wenn der Anteil der HTTP-5xx-Fehler 1 % während drei aufeinanderfolgender Minuten überschreitet.
• Führe ein Rollback durch, wenn die p95-Latenz die Baseline 5 Minuten lang um mehr als 200 ms überschreitet.
• Pausieren Sie den Rollout, wenn die Verzögerung der Datenbankreplikation den RPO-Schwellenwert überschreitet.
• Setzen Sie den Rollout aus, wenn die Neustartrate der Pods sprunghaft über den normalen Basiswert ansteigt.

Rollforwardsequenz

1. Erhöhen Sie die Datenverkehrsgewichtung in kleinen Schritten.
2. Überprüfen Sie SLO-Gates und geschäftliche Smoke-Tests.
3. Fahren Sie nur fort, wenn alle Gates für die Haltezeit erfolgreich sind.

Rollback-Sequenz

1. Starten Sie die Rückleitung zum alten Endpunkt. Clients können weiterhin zwischengespeicherte DNS-Antworten verwenden, bis ihre TTL abläuft.
2. Das Deployment rückgängig machen oder bei Bedarf die grüne Umgebung auf null skalieren.
3. Überprüfen Sie den Zustand der alten Umgebung und die Datenintegrität erneut.

# Restore old endpoint to 100
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=100

# Set green endpoint to 0
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.weight=0

# Optional Kubernetes rollback options
kubectl rollout undo deployment/myapp
kubectl scale deployment myapp --replicas=0

6. Schnelles Zurücksetzen bei Bedarf

Wenn Fehler zunehmen oder SLO-Schwellenwerte nicht eingehalten werden:

• Legen Sie die alte Endpunktgewichtung wieder auf 100 und grün auf 0.
• Stoppen Sie den weiteren Rollout und skalieren Sie grüne Pods optional herunter.

kubectl scale deployment myapp --replicas=0

Canary-Migration (kurze Einführung)

Verwenden Sie Canary, wenn Sie eine inkrementelle Freigabesteuerung mit minimaler doppelter Infrastruktur benötigen.

1. Stellen Sie eine stabile Workload und eine Canary-Workload bereit.
2. Leiten Sie einen kleinen Prozentsatz des Datenverkehrs an Canary weiter.
3. Beobachten Sie wichtige Signale, und erhöhen Sie dann oder führen Sie ein Rollback durch.

Beispiel für Ingress-Anmerkungen für nginx-Canary:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

canary-weight stufenweise erhöhen, solange der Gesundheitszustand stabil bleibt.

Schrittweise DNS-Migration (kurze Anleitung)

Verwenden Sie gestaffeltes DNS, wenn die DNS-Umschaltung Ihr primärer Mechanismus zur Datenverkehrssteuerung ist.

Legen Sie die DNS-TTL mindestens 24 bis 48 Stunden vor der Umstellung auf einen niedrigen Wert fest, damit Caches ablaufen können. Stellen Sie nach der Stabilisierung der Migration eine höhere TTL wieder her, um das Abfragevolumen und die Resolverabwanderung zu reduzieren.

1. DNS-TTL verringern (z. B. 30 Sekunden).
2. Stellen Sie den AKS-Endpunkt bereit.
3. Aktualisieren sie DNS-A/CNAME-Einträge.
4. Beobachten Sie die Weitergabe und Integrität.

Beispiel für eine Datensatzaktualisierung:

RG=rg-aks-migration

az network dns record-set a update \
  --resource-group $RG \
  --zone-name example.com \
  --name app \
  --set ttl=30

az network dns record-set a remove-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 13.78.1.2

az network dns record-set a add-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 52.160.1.100

Datenmigration für persistente Volumes

Die zustandsbehaftete Migration ist in der Regel der Bereich mit dem höchsten Risiko. Wählen Sie den Datenpfad aus, der Ihrem Speichertyp und den Konsistenzanforderungen entspricht.

Datenbankstrategien

Wählen Sie ein Datenbankmigrationsmuster aus, das ihren Ausfallzeiten und Konsistenzanforderungen entspricht.

Muster	Pros	Kompromisse	Typische Nutzung
Externe Datenbank (gemeinsam genutzt)	Einfachster Migrationspfad für Apps, keine DB-Umschaltung während der App-Migration	Gemeinsamer Explosionsradius, potenzielle Leistungskopplung	Vorhandene verwaltete PaaS DB, die von der alten und neuen App freigegeben wurde
Replizieren und hochstufen	Kontrollierter Umschaltungs- und Rollback-Punkt	Betriebsaufwand für Replikation und Förderung	Kritische zustandsbehaftete Workloads mit strengem RPO
Doppelschreiben (vorübergehend)	Ermöglicht eine Anwendungsumstellung mit nahezu keinen Ausfallzeiten	Komplexe Abstimmungs- und Idempotenzanforderungen	Ereignisgesteuerte Systeme mit ausgereiften Datenpipelines

Bewerten Sie Azure Database Migration Service und Debezium für CDC und Migrations-Orchestrierung. Verwenden Sie Schemaänderungen vom Typ „Erweitern -> Migrieren -> Reduzieren“, um alte und neue App-Versionen während des Übergangs kompatibel zu halten.

Azure Disk CSI-Momentaufnahmen

Verwenden Sie CSI-Momentaufnahmen für Blockvolumes, wenn Momentaufnahme-CRDs und der Momentaufnahmecontroller installiert sind.

Beispiel VolumeSnapshotClass:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-azuredisk-snapclass
driver: disk.csi.azure.com
deletionPolicy: Delete

Beispiel für eine Momentaufnahme aus einem vorhandenen PVC:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mydata-snapshot
spec:
  volumeSnapshotClassName: csi-azuredisk-snapclass
  source:
    persistentVolumeClaimName: mydata-pvc

Beispiel für die Wiederherstellung eines PVC aus einem Snapshot:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mydata-pvc-restored
spec:
  storageClassName: managed-csi
  dataSource:
    name: mydata-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Important

Momentaufnahmen sind in der Regel absturzkonsistent, nicht anwendungskonsistent. Verwenden Sie für Datenbanken eine Replikation oder eine anwendungskonsistente Sicherung und Wiederherstellung.

Azure Files

Für dateibasierte Workloads:

• Erstellen Sie Momentaufnahmen oder Kopierpläne für Quelldateifreigaben.
• Kopieren sie Daten mit Tools wie AzCopy.
• Aktualisieren Sie die StorageClass- und PVC-Konfiguration für die Zielfreigabe.

Beispielkopiemuster:

az storage share snapshot --account-name mystorage --name myshare
azcopy copy "https://<src>/myshare" "https://<dest>/myshare" --recursive

Velero Sicherung und Wiederherstellung

Verwenden Sie Velero für die Sicherung und Wiederherstellung von Clusterressourcen, einschließlich PV-Daten, wenn sie mit dem Azure-Plug-In konfiguriert sind.

RG=rg-aks-migration

velero install \
  --provider azure \
  --bucket my-velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config resourceGroup=$RG,storageAccount=myvelerostorage,subscriptionId=<subscription-id>

velero backup create pre-migration-backup --include-namespaces my-namespace
velero restore create --from-backup pre-migration-backup

Siehe Velero-Dokumentation und Verwenden von Azure Disk CSI-Momentaufnahmen mit AKS.

Beobachtbarkeit und automatisiertes Rollback

Instrumentieren Sie diese Signale vor jeder Verkehrsverlagerung:

• HTTP-Anforderungsrate und Erfolgsrate.
• HTTP 5xx-Fehlerrate.
• P95- und p99-Anforderungslatenz.
• Pod-Neustartrate und Readiness-Fehler.
• Knotendruck und Anzahl ausstehender Pods.
• Datenbankreplikationsverzögerung.
• Warteschlangentiefe für asynchrone Arbeitslasten.

Beispiel für Warnungsbedingungen im PromQL-Stil:

# Rollback gate: 5xx error rate over 1%
sum(rate(http_requests_total{status=~"5.."}[3m]))
/
sum(rate(http_requests_total[3m])) > 0.01

# Rollback gate: p95 latency exceeds 200ms over baseline target
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.2

Verknüpfen Sie Warnungen mit Ihrem Rolloutcontroller (manuelles Runbook, Argo Rollouts oder Flagger), damit Gatefehler eine automatische Pause oder ein Rollback auslösen.

Testen und Überprüfen von Rezepten

Schattenverkehr

Spiegeln Sie einen Teil des Produktionsdatenverkehrs auf die grüne Umgebung, ohne grüne Antworten an Endbenutzer zurückzugeben. Dadurch wird das Verhalten unter realistischer Belastung mit geringem Benutzerrisiko überprüft.

Rauchtests

Führen Sie geschäftskritische Prüfungen nach jeder Gewichtserhöhung aus, z. B.:

• Anmeldeablauf
• Zahlungs- oder Checkout-Ablauf
• Lese- und Schreib-API-Pfad
• Abschluss eines Hintergrundauftrags

Auslastungstests

Verwenden Sie Tools wie k6, hey oder Azure Load Testing, um das Kapazitäts- und automatische Skalierungsverhalten vor der endgültigen Übernahme zu überprüfen.

Featureflags

Verwenden Sie Featurekennzeichnungen, um die Bereitstellung von der Veröffentlichung zu entkoppeln. Featurekennzeichnungen können eine zweite Sicherheitsebene bereitstellen, wenn Sie riskante Codepfade ohne erneute Bereitstellung deaktivieren müssen.

Prüfliste für die Produktionskürzung

• [ ] Bestätigen Sie, dass Readiness- und Liveness-Tests die tatsächliche Bereitstellungsbereitschaft widerspiegeln.
• [ ] Werte von preStop und terminationGracePeriodSeconds unter Last überprüfen.
• [ ] Bestätigen Sie die PodDisruptionBudget-Werte für Upgrade- und Verdrängungsereignisse.
• [ ] Bestätigen Sie die Einstellungen für die Autoskalierung im Hinblick auf erwartete Verkehrsspitzen während der Migration.
• [ ] Überprüfen Sie End-to-End-Integritätsprüfungen über Ihren Datenverkehrseinstiegspunkt.
• [ ] Protokolle, Metriken, Warnungen und synthetische Prüfungen vor der Umschaltung validieren.
• [ ] Bestätigen Sie den Rollbackbesitzer, die Rollbacktriggerkriterien und das Rollback-Runbook.
• [ ] Überprüfen von NSG-, Firewall- und Integritätstestregeln für neue Endpunkte.
• [ ] Überprüfen Sie, ob das Verhalten der TLS-Terminierung und die CORS-Einstellungen der alten Umgebung entsprechen.
• [ ] Überprüfen des Kostenplans für einen temporären blaugrünen Überlappungszeitraum.

Checkliste für den Rollback

1. Leiten Sie den Datenverkehr zum alten Endpunkt um (Gewichtungen im Traffic Manager oder DNS-Rollback).
2. Pausieren Sie die grüne Bereitstellung, oder skalieren Sie sie herunter.
3. Stellen Sie vorherige Konfiguration oder geheime Schlüssel bei Bedarf wieder her.
4. Überprüfen Sie den Zustand der alten Umgebung erneut, bevor Sie den normalen Betrieb wieder aufnehmen.

Nächste Schritte

• Überprüfen Sie die Übersicht über die Migration für Azure Kubernetes Service (AKS).
• Überprüfen Sie die Strategien für AKS-Produktionsupgrades.
• Informieren Sie sich über Upgrades für Blau-Grün-Knotenpools in AKS.
• Lesen Sie Azure Traffic Manager Dokumentation.