Migrazione senza tempi di inattività a Servizio Azure Kubernetes (AKS)

Questo articolo descrive approcci pratici incentrati sulla produzione per la migrazione di carichi di lavoro esistenti a Servizio Azure Kubernetes (AKS) e il rilascio di nuove versioni di applicazioni in un cluster del servizio Azure Kubernetes esistente con tempi di inattività minimi o zero.

In breve: per una migrazione, eseguire in parallelo l’ambiente di origine e quello AKS e spostare gradualmente il traffico. Per una versione ricorrente dell'applicazione in un singolo cluster AKS, usare un aggiornamento in sequenza, una distribuzione canary o una distribuzione blue-green interna al cluster con probe di idoneità, spostamenti controllati del traffico, controlli di osservabilità e un rollback testato.

Guida rapida: 5 passaggi per la migrazione di AKS senza tempi di inattività

1. Eseguire il provisioning del servizio Azure Kubernetes di destinazione, dei certificati, della rete e dell'osservabilità.
2. Distribuire l'app con probe di idoneità e di attività, PodDisruptionBudget e richieste di risorse.
3. Sincronizzare i dati tramite la replica, gli snapshot CSI o Velero.
4. Spostare progressivamente il traffico usando pesi DNS relativi con Gestione traffico o percentuali precise delle richieste con il routing di ingresso o mesh di servizio.
5. Validare i gate SLO e dismettere la vecchia infrastruttura quando i criteri di stabilità sono soddisfatti.

Scopri come:

• Rilasciare una nuova versione dell'applicazione in un cluster del servizio Azure Kubernetes esistente senza sostituire il cluster.
• Confronta le strategie di migrazione DNS Blue-Green, Canary e Rolling.
• Esegui una lista di controllo di preparazione alla migrazione con comandi specifici di AKS.
• Eseguire una migrazione completa del cluster Blue-Green utilizzando AKS e Gestione traffico di Azure.
• Eseguire la migrazione di dati persistenti usando snapshot CSI, File di Azure o Velero.
• Preparare un piano di rollback prima del cutover.

Confronto tra strategie di migrazione

Usa questo confronto per scegliere un approccio di migrazione che si adatti alla tua tolleranza al rischio, alla maturità dell'osservabilità e ai requisiti di rollback.

Strategy	Impatto sul traffico	Velocità di rollback	Complexity	Funzionalità di AKS e servizi di Azure
Blue-Green (cluster o spazio dei nomi)	Minimo, perché il traffico passa solo quando il verde è integro	Molto rapidamente, riportando il traffico sul blu	Moderata, perché richiede ambienti duplicati e instradamento del traffico	Gestione traffico di Azure, IP pubblici di LoadBalancer, ingresso
Canary	Molto basso, perché il traffico si sposta gradualmente	Rapido, riducendo il peso del canary o i pod canary	Medio-alto, perché richiede la suddivisione e l'osservabilità del traffico	Ingress (nginx o Gateway API), service mesh (Istio o Linkerd), componenti aggiuntivi di Ingress di AKS
DNS in sequenza (basato su TTL)	Dipende dal TTL DNS; un TTL più breve riduce l'impatto	Medio, perché le cache DNS possono ritardare il rollback	Basso, perché la configurazione è semplice ma meno precisa	DNS di Azure, record con TTL basso, LoadBalancer o ingresso

Matrice delle decisioni del carico di lavoro

Usare questa tabella quando è necessaria una raccomandazione di strategia rapida per tipo di carico di lavoro.

Tipo di carico di lavoro	Strategia consigliata	Perché	Costi e complessità
WEB/API senza stato	Canary, quindi Blue-Green per il cutover finale	Riduzione progressiva dei rischi con rollback rapido	Medium
App con stato supportata da database	Blu-verde e percorso dati con replica e promozione	Controllo di rollback più robusto e percorso di failback chiaro	High
Carichi di lavoro con un numero elevato di file	Blue-Green e copia/istantanea di File di Azure	Validazione più semplice della parità dei dati prima del passaggio	Medio-alto
Processi/ruoli di lavoro a esecuzione prolungata	Aggiornamento in sequenza o finestra di manutenzione con svuotamento delle code	Minore impatto percepito dall'utente, routing più semplice	Basso medio

Opzioni di strumenti per la distribuzione progressiva

• Instradamento manuale ponderato (Traffic Manager più Ingress o LoadBalancer): ideale quando si desidera un controllo esplicito da parte dell'operatore e dipendenze ridotte.
• Routing della rete mesh di servizi (Istio o Linkerd): ideale quando servono routing con granularità fine, nuovi tentativi e controlli dei criteri.
• Implementazioni di Argo o Flagger: meglio quando si vuole il recapito progressivo automatizzato, l'analisi delle metriche e il rollback automatico.

Usa Traffic Manager per il bilanciamento globale a livello DNS e combinalo con Argo Rollouts o Flagger quando hai bisogno di un'analisi automatizzata della distribuzione all'interno del cluster.

Distribuire un'applicazione in un cluster AKS esistente

Le versioni ricorrenti dell'applicazione non richiedono un secondo cluster o un cutover DNS. Per un'applicazione senza stato già in esecuzione in AKS, usare un elemento Kubernetes Deployment con più repliche e una strategia RollingUpdate. Kubernetes crea pod di nuova versione nello stesso cluster, attende che diventino pronti e quindi rimuovono gradualmente i pod versione precedente.

L'esempio seguente mantiene disponibili tutte le repliche esistenti mentre Kubernetes avvia un pod aggiuntivo alla volta:

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

Assicurarsi che il cluster disponga della capacità necessaria per il pod di picco. Applicare il manifesto, monitorare l'implementazione e verificare la nuova immagine:

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

Per le versioni successive, aggiornare l'immagine e monitorare l'implementazione della distribuzione:

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

Monitorate il tasso di errore, la latenza, la prontezza dei pod e le transazioni aziendali durante la distribuzione. Se un controllo non riesce, interrompere o annullare la versione:

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

Un PodDisruptionBudget protegge le repliche durante le operazioni di rimozione volontaria, ad esempio gli svuotamenti dei nodi, ma non controlla il modo in cui un elemento Deployment sostituisce i pod durante l'implementazione di un'applicazione. Usa maxUnavailable e maxSurge per gestire la disponibilità della versione. Per le applicazioni che necessitano di percentuali di traffico per singola richiesta o di analisi automatica delle metriche, eseguire le versioni stabile e canary nello stesso cluster e usare un controller Ingress, un service mesh, Argo Rollouts o Flagger per reindirizzare progressivamente il traffico.

Prima di iniziare

• interfaccia della riga di comando di Azure versione 2.59.0 o successiva.
• kubectl connesso al cluster di origine.
• Autorizzazioni di AKS per creare e gestire cluster, rete e identità.
• Un endpoint di controllo dello stato dell'applicazione testato, ad esempio /healthz.
• Un proprietario del rollback e un elenco di controllo del rollback approvati prima del cutover del traffico.
• Piano di riduzione del TTL del DNS preparato almeno 24-48 ore prima del cutover.

TLS e preconfigurazione dei certificati

Eseguire il provisioning dei certificati nell'ambiente verde prima dello spostamento del traffico. Se l'ambiente corrente termina TLS, esportare e importare certificati nei segreti Kubernetes (o configurare cert-manager) prima di eseguire il cutover.

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

Se si usa ACME (ad esempio, Let's Encrypt), completare la convalida del dominio prima del cutover per evitare errori HTTPS.

Elenco di controllo per la preparazione pre-migrazione

Eseguire questi controlli prima di eseguire la migrazione. Salvare tutte le esportazioni nel controllo della versione o nell'archiviazione sicura.

Esportare risorse Kubernetes dal cluster di origine

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

Importante

Considerare i manifesti segreti esportati come dati sensibili. Archiviarli solo in sistemi sicuri.

Convalidare i prerequisiti di sottoscrizione, quote e rete

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

Convalidare i requisiti dell'identità e del controllo degli accessi in base al ruolo (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

Prima di continuare, verificare gli elementi seguenti:

• Gruppi di amministrazione del cluster e Entra ID modello di integrazione.
• Ambiti di identità gestiti e assegnazioni di ruolo.
• Registrazione, metriche e avvisi abilitati nell'ambiente di destinazione.

Guide alla strategia

Le sezioni successive presentano un esempio blu-verde completo e due schemi più sintetici (canary e DNS in sequenza) che è possibile adattare al proprio carico di lavoro.

migrazione del cluster Blue-Green

In questo scenario, il traffico di produzione è attualmente gestito da un ambiente legacy in app.example.com. Si crea un nuovo cluster AKS (aks-green), si distribuisce il carico di lavoro, si registrano in Gestione traffico di Azure sia gli endpoint esistenti sia quelli green e si sposta gradualmente il traffico.

Per indicazioni sulla migrazione di base, vedere Panoramica della migrazione per Servizio Azure Kubernetes (AKS).

1. Crea il cluster AKS verde

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

Ottenere le credenziali del cluster:

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

2. Distribuire il carico di lavoro con controlli di integrità e interruzione

Creare 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

Le richieste di risorse sono esempi. Dimensionare le richieste di CPU e memoria in base all'utilizzo osservato del carico di lavoro e ai risultati delle prove di carico, in modo che il cluster di destinazione rispecchi il comportamento di pianificazione e di capacità dell'ambiente di produzione.

externalTrafficPolicy: Local mantiene l'INDIRIZZO IP di origine, ma può ridurre gli endpoint back-end utilizzabili per ogni nodo. Per le applicazioni con sticky session, esternalizzare lo stato della sessione (ad esempio, cache di Azure per Redis) prima della migrazione per evitare interruzioni dovute all'affinità durante gli spostamenti di traffico.

Creare manifests/pdb.yaml.

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

Applicare le risorse e verificare l'implementazione:

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. Ottenere l'endpoint verde

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

Usare l'indirizzo IP restituito nei passaggi successivi.

4. Creare un profilo di Gestione traffico di Azure e gli endpoint

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

Aggiungere l'endpoint precedente:

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

Aggiungere l'endpoint verde:

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

Per informazioni dettagliate sui comandi, vedere az network traffic-manager profile e az network traffic-manager endpoint.

5. Instrada gradualmente il traffico verso l'ambiente verde

Iniziare con un peso basso e monitorare lo stato di salute e la latenza.

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

Continuare con spostamenti graduali del peso relativo, ad esempio 50:50 e poi 10:90 per la versione precedente e quella green. Gestione traffico sceglie un endpoint per ogni query DNS in base a questi pesi relativi; i pesi non garantiscono percentuali di richiesta esatte. Le risposte DNS vengono memorizzate nella cache dai client e dai resolver ricorsivi, che possono inclinare la distribuzione osservata. Mantenere ogni fase per almeno il TTL del profilo, più il tempo necessario per misurare un traffico dell'applicazione rappresentativo prima di continuare. Utilizzare un ingress L7 o un service mesh quando si richiede una distribuzione precisa per ogni richiesta.

Criteri di cutover, attività di controllo di monitoraggio e playbook per rollback

Definire attività di controllo esplicite prima di ogni aumento del traffico.

Porte di esempio

• Eseguire il rollback se HTTP 5xx supera l'1% per 3 minuti consecutivi.
• Eseguire il rollback se la latenza p95 supera la baseline di oltre 200 ms per 5 minuti.
• Sospendere l'implementazione se il ritardo di replica del database supera la soglia RPO.
• Sospendere l'implementazione se la frequenza di riavvio del pod supera la baseline normale.

Sequenza di avanzamento

1. Aumentare il peso del traffico in piccoli incrementi.
2. Convalidare le attività di controllo SLO e gli smoke test aziendali.
3. Continuare solo se tutte le attività di controlli vengono superate durante il periodo di attesa.

Sequenza di ripristino

1. Instradare nuovamente verso l'endpoint precedente. I client possono continuare a usare le risposte DNS memorizzate nella cache fino alla scadenza del TTL.
2. Annullare la distribuzione o ridimensionare il verde su zero, se necessario.
3. Riconvalidare lo stato dell'ambiente precedente e l'integrità dei dati.

# 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. Eseguire il rollback rapidamente, se necessario

Se gli errori aumentano o le soglie SLO non vengono rispettate:

• Impostare di nuovo il peso del vecchio endpoint su 100 e quello verde su 0.
• Mettere in pausa l'ulteriore implementazione e, facoltativamente, ridimensionare i pod verdi.

kubectl scale deployment myapp --replicas=0

Migrazione di tipo canary (breve procedura dettagliata)

Usare canary quando si vuole un controllo di rilascio incrementale con un'infrastruttura duplicata minima.

1. Distribuire un carico di lavoro stabile e un carico di lavoro di tipo canary.
2. Instradare una piccola percentuale di traffico verso canary.
3. Monitorare i segnali chiave, quindi aumentare o tornare indietro.

Annotazioni di ingresso di esempio per 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

Aumentare canary-weight gradualmente se le condizioni restano stabili.

Migrazione DNS in sequenza (breve procedura dettagliata)

Usare il DNS in sequenza quando il cambio DNS è il meccanismo di controllo del traffico primario.

Impostare il TTL DNS su un valore basso almeno 24-48 ore prima del cutover, in modo che le cache possano scadere. Dopo che la migrazione si è stabilizzata, ripristinare un TTL più alto per ridurre il volume delle query e il churn dei resolver.

1. TTL DNS più basso (ad esempio, 30 secondi).
2. Distribuisci l'endpoint di AKS.
3. Aggiorna i record DNS A/CNAME.
4. Osservare la propagazione e l'integrità.

Esempio di aggiornamento di un record:

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

Migrazione dei dati per volumi persistenti

La migrazione con stato è in genere l'area di rischio più elevata. Scegliere il percorso dati che corrisponde ai requisiti di coerenza e del tipo di archiviazione.

Strategie di database

Scegli un modello di migrazione del database in linea con i requisiti di tempi di inattività e coerenza.

Modello	Pros	Tradeoffs	Uso tipico
Database esterno (condiviso)	Percorso di migrazione dell'app più semplice, nessun cutover del database durante lo spostamento delle app	Area di impatto condivisa, potenziale interdipendenza delle prestazioni	Database PaaS gestito esistente condiviso dalla vecchia e dalla nuova app
Replicare e promuovere	Cutover controllato e punto di rollback	Sovraccarico operativo per la replica e la promozione	Carichi di lavoro con stato critico con RPO rigoroso
Doppia scrittura (temporanea)	Consente il cutover delle applicazioni con tempi di inattività prossimi allo zero	Requisiti di riconciliazione e idempotenza complessi	Sistemi basati su eventi con pipeline di dati mature

Per l'orchestrazione della CDC e della migrazione, valutare Azure Servizio Migrazione del database e Debezium. Utilizzare le modifiche dello schema expand -> migrate -> contract per mantenere compatibili durante la transizione le versioni precedenti e quelle nuove dell'applicazione.

Snapshot CSI del disco di Azure

Utilizzare gli snapshot CSI per i volumi a blocchi quando sono installate le CRD e il controller degli snapshot.

Esempio VolumeSnapshotClass:

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

Istantanea di esempio di un PVC esistente:

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

Esempio di ripristino di PVC dallo 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

Importante

Gli snapshot sono in genere coerenti con l'arresto anomalo, non coerenti con le applicazioni. Per i database, utilizzare la replica oppure il backup e il ripristino compatibili con l'applicazione.

File di Azure

Per i carichi di lavoro basati su file:

• Creare piani di snapshot o di copia per le condivisioni di file di origine.
• Copiare dati con strumenti come AzCopy.
• Aggiornare la configurazione di StorageClass e PVC per la condivisione di destinazione.

Modello di copia di esempio:

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

Backup e ripristino di Velero

Usare Velero per il backup e il ripristino delle risorse del cluster, inclusi i dati PV quando configurati con il plug-in 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

Consultare la documentazione di Velero e usare le istantanee CSI di Azure Disk con AKS.

Osservabilità e rollback automatizzato

Instrumentare questi segnali prima di qualsiasi spostamento del traffico:

• Frequenza delle richieste HTTP e frequenza di esito positivo.
• Percentuale di errori HTTP 5xx.
• latenza della richiesta p95 e p99.
• Frequenza di riavvio dei pod e errori di prontezza.
• Pressione del nodo e numero di pod in sospeso.
• Ritardo della replica del database.
• Profondità della coda per carichi di lavoro asincroni.

Esempio di condizioni di avviso di tipo 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

Collegare gli avvisi al controller dell'implementazione (runbook manuale, implementazioni di Argo o Flagger) in modo che gli errori delle attività di controllo attivino automaticamente una pausa o un rollback.

Test e ricette di convalida

Traffico ombra

Eseguire il mirroring di una sezione del traffico di produzione verso il verde senza restituire risposte verdi agli utenti finali. Questo consente di convalidare il comportamento con un carico realistico con un basso rischio utente.

Test di fumo

Eseguire controlli critici per l'azienda dopo ogni incremento di peso, ad esempio:

• Flusso di accesso
• Pagamento o flusso di check out
• Percorso API di lettura e scrittura
• Completamento del processo in background

Test di carico

Usare strumenti come k6, hey o Test di carico di Azure per convalidare la capacità e il comportamento di scalabilità automatica prima del cutover finale.

Indicatori di funzionalità

Utilizza i flag di funzionalità per separare la distribuzione dal rilascio. I flag di funzionalità possono fornire un secondo livello di sicurezza quando è necessario disabilitare i percorsi di codice rischiosi senza ridistribuire.

Elenco di controllo per il cutover di produzione

• [ ] Verificare che le probe di idoneità e attività riflettano l'effettiva capacità del servizio di rispondere alle richieste.
• [ ] Convalida i valori di preStop e terminationGracePeriodSeconds sotto carico.
• [ ] Verificare i valori del PodDisruptionBudget per gli eventi di aggiornamento e di evizione.
• [ ] Confermare le impostazioni di scalabilità automatica per i picchi di traffico di migrazione previsti.
• [ ] Verificare i controlli di integrità end-to-end tramite il punto di ingresso del traffico.
• [ ] Convalidare log, metriche, avvisi e controlli sintetici prima del cutover.
• [ ] Confermare il proprietario del rollback, i criteri di attivazione del rollback e il runbook per il rollback.
• [ ] Verificare le regole del gruppo di sicurezza di rete, del firewall e della probe di integrità per i nuovi endpoint.
• [ ] Verificare che il comportamento della terminazione TLS e le impostazioni CORS corrispondano all'ambiente precedente.
• [ ] Convalidare il piano di costo per il periodo di sovrapposizione blu-verde temporaneo.

Elenco di controllo per il rollback

1. Spostare il traffico verso il vecchio endpoint (pesi di Gestione traffico o rollback DNS).
2. Sospendere o ridimensionare la distribuzione verde.
3. Ripristinare la configurazione o i segreti precedenti, se necessario.
4. Riconvalidare l'integrità dell'ambiente precedente prima di riprendere le normali operazioni.

Passaggi successivi

• Vedere Panoramica della migrazione per Servizio Azure Kubernetes (AKS).
• Vedere le strategie di aggiornamento della produzione del servizio Azure Kubernetes.
• Vedere gli aggiornamenti del pool di nodi blu-verde nel servizio Azure Kubernetes.
• Consultare la documentazione di Gestione traffico di Azure.