Migracja bez przestojów do Azure Kubernetes Service (AKS)

W tym artykule opisano praktyczne, skoncentrowane na środowisku produkcyjnym podejścia do migrowania istniejących obciążeń do Azure Kubernetes Service (AKS) i wydawania nowych wersji aplikacji w istniejącym klastrze usługi AKS z minimalnym lub zerowym przestojem.

Szybka odpowiedź: Na potrzeby migracji uruchom równolegle środowisko źródłowe i środowisko AKS oraz stopniowo przekierowuj ruch. W przypadku cyklicznego wdrażania nowej wersji aplikacji w jednym klastrze AKS należy zastosować aktualizację stopniową, wdrożenie kanarkowe lub wdrożenie blue-green w obrębie klastra z sondami gotowości, kontrolowanym przekierowywaniem ruchu, kryteriami observability i przetestowaną procedurą wycofania.

Krótki przewodnik: 5 kroków migracji AKS bez przestojów

1. Wdróż docelowy klaster AKS, certyfikaty, sieci i monitorowanie.
2. Wdróż aplikację z sondami gotowości i żywotności, ustawieniem PodDisruptionBudget oraz żądaniami zasobów.
3. Synchronizuj dane za pomocą replikacji, migawek CSI lub Velero.
4. Stopniowo przekierowuj ruch za pomocą względnych wag DNS w usłudze Traffic Manager lub dokładnie określonych procentowych udziałów żądań przy użyciu routingu opartego na zasobie Ingress lub siatce usług.
5. Zweryfikuj progi SLO i wycofaj starą infrastrukturę, gdy kryteria stabilności zostaną spełnione.

Uczysz się, jak:

• Wdróż nową wersję aplikacji w istniejącym klastrze AKS bez zastępowania klastra.
• Porównaj strategie migracji Blue-Green, Canary i Rolling DNS.
• Uruchom listę kontrolną gotowości przed migracją przy użyciu poleceń specyficznych dla usługi AKS.
• Wykonaj pełną migrację klastra Blue-Green przy użyciu usługi AKS i Azure Traffic Manager.
• Migrowanie trwałych danych przy użyciu migawek CSI, Azure Files lub Velero.
• Przygotuj plan wycofania przed przełączeniem.

Porównanie strategii migracji

Użyj tego porównania, aby wybrać podejście do migracji, które odpowiada Twojej tolerancji ryzyka, dojrzałości w zakresie obserwowalności oraz wymaganiom dotyczącym wycofania zmian.

Strategy	Wpływ ruchu	Szybkość wycofywania	Complexity	Funkcje usługi AKS i usługi Azure
Blue-Green (klaster lub przestrzeń nazw)	Minimalny, ponieważ ruch przełącza się tylko wtedy, gdy zielony jest w dobrej kondycji	Bardzo szybko, przełączając ruch z powrotem na niebieski	Średni, ponieważ wymaga zduplikowanych środowisk i routingu ruchu	Azure Traffic Manager, publiczne adresy IP modułu LoadBalancer, ruch przychodzący
Kanarkowe	Bardzo niskie, ponieważ ruch przesuwa się stopniowo	Szybko, zmniejszając wagę wersji kanarkowej lub zmniejszając liczbę podów kanarkowych	Średnio-wysoki, ponieważ wymaga podziału ruchu i możliwości obserwacji	Warstwa wejściowa (nginx lub Gateway API), siatka usług (Istio lub Linkerd), dodatki warstwy wejściowej AKS
Rotacyjny DNS (oparty na TTL)	Zależy od wartości TTL DNS; krótszy TTL zmniejsza wpływ	Średni, ponieważ pamięci podręczne DNS mogą opóźniać wycofywanie	Niska, ponieważ konfiguracja jest prosta, ale mniej precyzyjna	Azure DNS, rekordy DNS o niskim TTL, LoadBalancer lub Ingress

Macierz podejmowania decyzji o obciążeniu

Użyj tej tabeli, jeśli potrzebujesz szybkiego zalecenia dotyczącego strategii według typu obciążenia.

Typ obciążenia	Zalecana strategia	Dlaczego	Koszt i złożoność
Bezstanowy interfejs WWW/API	Canary, a następnie Blue-Green na potrzeby końcowego przełączenia	Stopniowe zmniejszanie ryzyka z szybkim wycofywaniem	Medium
Aplikacja stanowa oparta na bazie danych	Blue-Green i ścieżka danych replikacji i promowania	Najsilniejsza kontrola cofania zmian i przejrzysta ścieżka przywracania po awarii	High
Obciążenia z dużym obciążeniem plików	Blue-Green plus kopia/migawka Azure Files	Łatwiejsza walidacja parzystości danych przed przełączeniem	Średnio-wysoki
Długotrwałe zadania/procesy robocze	Stopniowe aktualizowanie lub okno obsługi z opróżnianiem kolejki	Mniejszy wpływ na użytkownika, prostszy routing	Nisko-średni

Opcje narzędzi progresywnego dostarczania

• Ręczne routowanie z wagami (Traffic Manager plus ingress lub LoadBalancer): najlepsze, gdy zależy Ci na bezpośredniej kontroli operatora oraz prostych zależnościach.
• Routing w siatce usług (Istio lub Linkerd): najlepszy wybór, gdy potrzebujesz precyzyjnego routingu, mechanizmów ponawiania i kontroli zasad.
• Argo Rollouts lub Flagger: najlepszy wybór, gdy chcesz wdrożyć zautomatyzowane wdrażanie progresywne, analizę metryk i automatyczne wycofywanie zmian.

Użyj usługi Traffic Manager do globalnego równoważenia ruchu na poziomie DNS i połącz ją z Argo Rollouts lub Flagger, gdy potrzebujesz automatycznej analizy procesu wdrażania w klastrze.

Wydawanie aplikacji w istniejącym klastrze usługi AKS

Regularne wdrożenia aplikacji nie wymagają drugiego klastra ani przełączenia DNS. W przypadku aplikacji bezstanowej, która jest już uruchomiona w usłudze AKS, użyj rozwiązania Kubernetes Deployment z wieloma replikami i strategią RollingUpdate . Platforma Kubernetes tworzy zasobniki nowej wersji w tym samym klastrze, czeka na ich gotowość, a następnie stopniowo usuwa zasobniki starej wersji.

Poniższy przykład sprawia, że wszystkie istniejące repliki pozostają dostępne, podczas gdy Kubernetes uruchamia po jednym dodatkowym zasobniku:

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"]

Upewnij się, że klaster ma wystarczające zasoby dla dodatkowego poda. Zastosuj manifest, monitoruj wdrożenie i sprawdź nowy obraz:

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

W przypadku kolejnych wydań zaktualizuj obraz i monitoruj postęp wdrażania obiektu Deployment:

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

Monitoruj wskaźnik błędów, latencję, gotowość podów i transakcje biznesowe podczas wdrożenia. Jeśli brama zakończy się niepowodzeniem, zatrzymaj lub cofnij wydanie:

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

Zasobnik PodDisruptionBudget chroni repliki podczas dobrowolnych operacji eksmisji, takich jak opróżnianie węzłów, ale nie kontroluje Deployment sposobu zastępowania zasobników podczas wdrażania aplikacji. Użyj funkcji maxUnavailable i maxSurge , aby kontrolować dostępność wersji. W przypadku aplikacji, które wymagają procentowego podziału ruchu na poziomie żądań lub zautomatyzowanej analizy metryk, uruchom stabilne i canary wersje w tym samym klastrze i użyj kontrolera Ingress, siatki usług, Argo Rollouts lub Flagger do stopniowego przekierowywania ruchu.

Zanim rozpoczniesz

• Azure CLI w wersji 2.59.0 lub nowszej.
• kubectl połączony z Twoim klastrem źródłowym.
• Uprawnienia usługi AKS do tworzenia klastrów, sieci i tożsamości oraz zarządzania nimi.
• Przetestowany punkt końcowy kondycji aplikacji, taki jak /healthz.
• Osoba odpowiedzialna za wycofanie oraz lista kontrolna wycofania zostały zatwierdzone przed przełączeniem ruchu.
• Plan redukcji wartości TTL DNS przygotowano co najmniej 24–48 godzin przed przełączeniem.

Wstępna konfiguracja TLS i certyfikatów

Skonfiguruj certyfikaty w środowisku zielonym przed przełączeniem ruchu. Jeśli bieżące środowisko zakończy protokół TLS, przed przecięciem wyeksportuj i zaimportuj certyfikaty do wpisów tajnych platformy Kubernetes (lub skonfiguruj menedżera certyfikatów).

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

Jeśli używasz programu ACME (na przykład Let's Encrypt), przed rozpoczęciem migracji jednorazowej zakończ walidację domeny, aby uniknąć błędów protokołu HTTPS.

Lista kontrolna gotowości przed migracją

Uruchom te testy przed przeprowadzeniem migracji. Zapisz wszystkie eksporty w kontroli wersji lub bezpiecznym magazynie.

Eksportowanie zasobów platformy Kubernetes z klastra źródłowego

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

Ważna

Traktuj wyeksportowane manifesty sekretów jako dane wrażliwe. Przechowuj je tylko w bezpiecznych systemach.

Weryfikowanie wymagań wstępnych dotyczących subskrypcji, przydziałów i sieci

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

Weryfikacja wymagań dotyczących tożsamości i mechanizmu RBAC

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

Przed kontynuowanie potwierdź następujące elementy:

• Grupy administracyjne klastra i model integracji Entra ID.
• Zakresy tożsamości zarządzanej i przypisania ról.
• Rejestrowanie, metryki i alerty włączone w środowisku docelowym.

Przewodniki dotyczące strategii

W kolejnych sekcjach przedstawiono jeden kompletny przykład wdrożenia Blue-Green oraz dwa krótsze schematy (Canary i Rolling DNS), które można dostosować do swojego obciążenia.

migracja klastra Blue-Green

W tym scenariuszu ruch produkcyjny obecnie jest obsługiwany ze starszego środowiska pod adresem app.example.com. Utworzysz nowy klaster usługi AKS (aks-green), wdrożysz obciążenie, zarejestrujesz zarówno stare, jak i zielone punkty końcowe w Azure Traffic Manager i stopniowo przesuwasz ruch.

Aby uzyskać podstawowe wskazówki dotyczące migracji, zobacz Omówienie migracji dla Azure Kubernetes Service (AKS).

1. Utwórz zielony klaster AKS

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

Uzyskaj dane uwierzytelniające klastra

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

2. Wdróż obciążenie robocze z mechanizmami kontroli kondycji i zakłóceń

Utwórz plik 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

Żądania zasobów są przykładami. Dobierz wartości żądań CPU i pamięci na podstawie obserwowanego wykorzystania zasobów przez obciążenia robocze oraz wyników testów obciążeniowych, tak aby klaster docelowy odzwierciedlał sposób harmonogramowania i charakterystykę pojemnościową środowiska produkcyjnego.

externalTrafficPolicy: Local zachowuje źródłowy adres IP, ale może zmniejszyć liczbę punktów końcowych zaplecza na węzeł. W przypadku aplikacji korzystających z sesji trwałych (sticky sessions) przed migracją przenieś stan sesji do zewnętrznego magazynu (na przykład Azure Cache for Redis), aby uniknąć awarii związanych z przypisaniem sesji podczas przełączania ruchu.

Utwórz plik manifests/pdb.yaml.

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

Zastosuj zasoby i zweryfikuj wdrożenie:

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. Pobierz zielony punkt końcowy

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

Użyj zwróconego adresu IP w następnych krokach.

4. Tworzenie profilu Azure Traffic Manager i punktów końcowych

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

Dodaj stary punkt końcowy:

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

Dodaj zielony punkt końcowy:

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

Aby uzyskać szczegółowe informacje o poleceniach, zobacz az network traffic-manager profile i az network traffic-manager endpoint.

5. Stopniowo kieruj ruch do wersji green

Zacznij od niskiej wagi i obserwuj kondycję i opóźnienie.

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

Kontynuuj, stopniowo zmieniając względną grubość, na przykład z 50:50 na 10:90 dla „old” i „green”. Usługa Traffic Manager wybiera punkt końcowy dla każdego zapytania DNS na podstawie tych względnych wag; wagi nie gwarantują dokładnych wartości procentowych żądań. Odpowiedzi DNS są buforowane przez klientów i rekursywne resolwery, co może zniekształcać obserwowany rozkład. Utrzymuj każdy etap przez co najmniej czas życia profilu (TTL) oraz wystarczająco długo, aby zmierzyć reprezentatywny ruch aplikacyjny, zanim przejdziesz dalej. Użyj siatki ruchu przychodzącego lub usługi L7, jeśli potrzebujesz dokładnej dystrybucji poszczególnych żądań.

Kryteria przełączenia, punkty kontrolne monitorowania i plan wycofania zmian

Zdefiniuj jawne bramy przed każdym wzrostem ruchu.

Przykładowe bramy

• Wycofaj, jeśli błąd HTTP 5xx przekracza 1% przez 3 kolejne minuty.
• Wycofaj, jeśli opóźnienie p95 przekracza punkt odniesienia o ponad 200 ms przez 5 minut.
• Wstrzymaj wdrożenie, jeśli opóźnienie w replikacji bazy danych przekracza próg RPO.
• Wstrzymaj wdrażanie, jeśli liczba restartów poda gwałtownie wzrośnie powyżej normalnego poziomu bazowego.

Sekwencja przewijania do przodu

1. Stopniowo zwiększaj udział ruchu.
2. Zweryfikuj progi SLO i biznesowe testy dymne.
3. Kontynuuj tylko wtedy, gdy wszystkie bramy przejdą na okres wstrzymania.

Sekwencja wycofywania

1. Zainicjuj routing z powrotem do starego punktu końcowego. Klienci mogą nadal używać odpowiedzi DNS zapisanych w pamięci podręcznej do czasu wygaśnięcia ich TTL.
2. Cofanie wdrożenia lub skalowanie na zielono do zera w razie potrzeby.
3. Ponownie zweryfikuj starą kondycję środowiska i integralność danych.

# 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. Szybkie wycofywanie w razie potrzeby

Jeśli liczba błędów wzrasta lub progi SLO nie są spełniane:

• Ustaw wagę starego punktu końcowego z powrotem na 100, a zielonego na 0.
• Wstrzymaj dalsze wdrożenie i opcjonalnie zmniejsz liczbę zielonych podów.

kubectl scale deployment myapp --replicas=0

Migracja kanaryjna (krótki przewodnik)

Użyj kanarku, jeśli chcesz uzyskać kontrolę wydania przyrostowego z minimalną zduplikowaną infrastrukturą.

1. Wdróż stabilne obciążenie i obciążenie kanarkowe.
2. Kieruj niewielki procent ruchu do wersji kanaryjnej.
3. Monitoruj kluczowe wskaźniki, a następnie zwiększaj skalę lub wycofuj zmiany.

Przykładowe adnotacje ruchu przychodzącego dla kanarku nginx:

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

Zwiększaj canary-weight stopniowo, o ile stan zdrowia pozostaje stabilny.

Migracja stopniowe DNS (krótki przewodnik)

Użyj stopniowego przełączania DNS, gdy przełączanie DNS jest podstawowym mechanizmem kontroli ruchu.

Ustaw TTL DNS na niską wartość co najmniej 24–48 godzin przed przełączeniem, aby wpisy w pamięci podręcznej mogły wygasnąć. Po ustabilizowaniu się sytuacji po migracji przywróć wyższy TTL, aby zmniejszyć liczbę zapytań i obciążenie resolverów.

1. Obniż DNS TTL (na przykład do 30 sekund).
2. Wdróż punkt końcowy usługi AKS.
3. Zaktualizuj rekordy A/CNAME systemu DNS.
4. Obserwuj propagację i kondycję.

Przykładowa aktualizacja rekordu A:

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

Migracja danych dla woluminów trwałych

Migracja stanowa jest zwykle obszarem najwyższego ryzyka. Wybierz ścieżkę danych zgodną z wymaganiami dotyczącymi typu magazynu i spójności.

Strategie bazy danych

Wybierz wzorzec migracji bazy danych, który jest zgodny z wymaganiami dotyczącymi przestojów i spójności.

Wzorzec	Zalety	Kompromisy	Typowe użycie
Zewnętrzna baza danych (udostępniona)	Najprostsza ścieżka migracji aplikacji, bez przełączenia bazy danych podczas przenoszenia aplikacji	Wspólny obszar oddziaływania, potencjalna współzależność wydajności	Istniejąca zarządzana baza danych PaaS udostępniona przez starą i nową aplikację
Powielaj i promuj	Kontrolowany punkt przecięcia i wycofywania	Narzut operacyjny związany z replikacją i promowaniem	Krytyczne stanowe obciążenia z rygorystycznym wskaźnikiem RPO
Podwójny zapis (tymczasowy)	Umożliwia przełączenie aplikacji przy niemal zerowym przestoju	Złożone wymagania dotyczące uzgadniania i idempotentności	Systemy sterowane zdarzeniami z dojrzałymi potokami danych

W przypadku orkiestracji CDC i migracji należy ocenić Azure Database Migration Service i Debezium. Użyj zmian schematu typu expand -> migrate -> contract, aby zachować kompatybilność starych i nowych wersji aplikacji podczas przejścia.

migawki csi dysku Azure

Użyj migawek CSI dla woluminów blokowych, gdy są zainstalowane migawki CRD i kontroler migawki.

Przykład VolumeSnapshotClass:

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

Przykładowa migawka z istniejącego PVC:

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

Przykład przywracania PVC z migawki:

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

Ważna

Migawki są zwykle spójne po awarii, a nie spójne na poziomie aplikacji. W przypadku baz danych użyj replikacji lub tworzenia i odtwarzania kopii zapasowych z uwzględnieniem aplikacji.

Azure Files

W przypadku obciążeń opartych na plikach:

• Utwórz plany tworzenia migawek lub kopiowania dla źródłowych udziałów plików.
• Kopiowanie danych za pomocą narzędzi, takich jak AzCopy.
• Zaktualizuj konfigurację StorageClass i PVC dla udziału docelowego.

Przykładowy wzorzec kopiowania:

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

Tworzenie kopii zapasowych i przywracanie w Velero

Użyj usługi Velero do tworzenia kopii zapasowej i przywracania zasobów klastra, w tym danych PV skonfigurowanych za pomocą wtyczki Azure.

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

Zobacz dokumentację platformy Velero i Używanie migawek CSI dysków Azure z usługą AKS.

Obserwowanie i automatyczne wycofywanie

Instrumentuj te sygnały przed zmianą ruchu:

• Szybkość żądań HTTP i współczynnik powodzenia.
• Szybkość błędów HTTP 5xx.
• Opóźnienie żądań p95 i p99.
• Szybkość ponownego uruchamiania zasobnika i niepowodzenia gotowości.
• Obciążenie węzła i liczba oczekujących zasobników.
• Opóźnienie replikacji bazy danych.
• Głębokość kolejki dla obciążeń asynchronicznych.

Przykładowe warunki alertów w stylu PromQL:

# 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

Powiąż alerty z kontrolerem wdrożenia (ręczną procedurą operacyjną, Argo Rollouts lub Flagger), tak aby niepowodzenia kontroli powodowały automatyczne wstrzymanie lub wycofanie.

Przepisy dotyczące testowania i walidacji

Ruch lustrzany

Kopiuj część ruchu produkcyjnego do środowiska zielonego bez zwracania użytkownikom końcowym odpowiedzi ze środowiska zielonego. Sprawdza to zachowanie pod realistycznym obciążeniem z niskim ryzykiem użytkownika.

Testy dymne

Uruchamiaj kontrole krytyczne dla działania firmy po każdym wzroście wagi, na przykład:

• Przepływ logowania
• Proces płatności lub finalizacji zakupu
• Ścieżka API do odczytu i zapisu
• Uzupełnianie zadania w tle

Testowanie obciążenia

Użyj narzędzi, takich jak k6, hey lub Azure Load Testing, aby zweryfikować wydajność i działanie automatycznego skalowania przed ostatecznym przełączeniem.

Flagi funkcjonalności

Użyj flag funkcjonalności, aby oddzielić wdrożenie od udostępnienia. Flagi funkcji mogą zapewnić drugą warstwę bezpieczeństwa, gdy trzeba wyłączyć ryzykowne ścieżki kodu bez ponownego wdrażania.

Lista kontrolna przełączenia produkcyjnego

• [ ] Potwierdź, że sondy gotowości i żywotności odzwierciedlają rzeczywistą gotowość do obsługi ruchu.
• [ ] Zweryfikować wartości preStop i terminationGracePeriodSeconds przy obciążeniu.
• [ ] Sprawdź wartości PodDisruptionBudget na potrzeby aktualizacji i eksmisji.
• [ ] Potwierdź ustawienia skalowania automatycznego dla spodziewanych skoków ruchu migracji.
• [ ] Zweryfikuj kompleksowe kontrole kondycji za pośrednictwem punktu wejścia ruchu.
• [ ] Zweryfikuj dzienniki, metryki, alerty i testy syntetyczne przed przełączeniem.
• [ ] Potwierdź właściciela wycofania zmian, kryteria uruchomienia wycofania zmian oraz runbook wycofania zmian.
• [ ] Zweryfikuj reguły NSG, zapory i sondy kondycji dla nowych punktów końcowych.
• [ ] Zweryfikuj, czy zachowanie terminacji TLS i ustawienia mechanizmu CORS są zgodne ze starym środowiskiem.
• [ ] Zweryfikuj plan kosztów dla tymczasowego okresu nakładania się na niebiesko-zielony.

Lista kontrolna wycofywania

1. Przenieś ruch do poprzedniego punktu końcowego (wagi w usłudze Traffic Manager lub wycofanie DNS).
2. Wstrzymaj lub zmniejsz skalę zielonego wdrożenia.
3. W razie potrzeby przywróć poprzednią konfigurację lub wpisy tajne.
4. Przed wznowieniem normalnej pracy ponownie zweryfikuj stan starego środowiska.

Następne kroki

• Zapoznaj się z omówieniem migracji dla Azure Kubernetes Service (AKS).
• Zapoznaj się z strategiami uaktualniania środowiska produkcyjnego usługi AKS.
• Zapoznaj się z uaktualnieniami puli węzłów blue-green w usłudze AKS.
• Przejrzyj dokumentację Azure Traffic Manager.