Modelli di aggiornamento del carico di lavoro con stato per Servizio Azure Kubernetes (AKS)

Usare questi modelli per coordinare la disponibilità del database con un aggiornamento in sequenza del pool di nodi Servizio Azure Kubernetes (AKS).

Le procedure descritte in questo articolo sono framework di pianificazione, non garanzie di disponibilità o durabilità dei dati. Il risultato dipende dalla topologia del database, dalla modalità di replica, dall'archiviazione, dall'operatore, dalle impostazioni di interruzione, dal comportamento dei tentativi client e dal carico di lavoro. Ripetere la procedura completa in un ambiente rappresentativo e misurare se soddisfa l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO).

Modelli di aggiornamento del database illustrati in questo articolo

Questo articolo fornisce modelli di aggiornamento specifici del database per i cluster del servizio Azure Kubernetes con carichi di lavoro con stato, tra cui:

• Switchover controllato da PostgreSQL.
• Aggiornamento in sequenza della replica del cluster Redis.
• Aggiornamento progressivo del set di repliche MongoDB con priorità ai secondari.
• Elenchi di controllo per gli aggiornamenti di emergenza per le risposte alla sicurezza.
• Convalida e pianificazione del rollback.

A differenza di un aggiornamento standard di un pool di nodi AKS, questi schemi coordinano i controlli della replica del database e i cambi di ruolo con la sostituzione dei nodi Kubernetes. Gli amministratori del database e del servizio Azure Kubernetes possono usare questi modelli. Utilizzare la procedura documentata di commutazione o aggiornamento per l'operatore del database che gestisce la tua distribuzione. Non sostituire questi modelli per istruzioni specifiche dell'operatore.

Per altre informazioni, vedere questi articoli correlati:

• Per aggiornare i cluster del servizio Azure Kubernetes di produzione, vedere Strategie di aggiornamento della produzione del servizio Azure Kubernetes.
• Per confrontare gli approcci di aggiornamento per il cluster del servizio Azure Kubernetes, vedere Opzioni e consigli per l'aggiornamento.
• Per usare l'hub dello scenario per scegliere l'approccio appropriato per l'aggiornamento del servizio Azure Kubernetes, vedere Scenari di aggiornamento del servizio Azure Kubernetes: Scegliere il percorso.

Per iniziare rapidamente, selezionare lo schema per il prodotto distribuito e la topologia:

• Elenco di controllo per l'aggiornamento di emergenza
• Passaggio controllato da PostgreSQL
• Aggiornamento progressivo di Redis Cluster con priorità alle repliche
• Aggiornamento progressivo del set di repliche MongoDB partendo dai secondari

Scegliere un modello di aggiornamento del database

Elenco di controllo per l'aggiornamento di emergenza

Se è necessario un aggiornamento accelerato per risolvere un problema di sicurezza, non ignorare i controlli di integrità e ripristino del database.

1. Verifica il carico di lavoro e i prerequisiti per l'aggiornamento di AKS:

   # Verify the database pods and their node placement.
   kubectl get pods -l tier=database -o wide
   
   # Confirm that the latest backup job completed.
   kubectl get job backup-job -o jsonpath='{.status.completionTime}'
   

   Verificare anche l'integrità della replica usando un comando supportato dal database o dall'operatore . Ripristinare il backup più recente in un ambiente isolato e verificare che i client riprovano a errori temporanei di connessione ed elezione.

2. Scegliere solo il modello che corrisponde al prodotto e alla topologia:

   • PostgreSQL: usare il passaggio controllato.
   • Cluster di Redis: Usare l'aggiornamento progressivo che parte dalle repliche.
   • Set di replica MongoDB: Usare l'aggiornamento progressivo iniziando dai secondari.

   Per altri prodotti di database, seguire le indicazioni per l'aggiornamento per il prodotto o l'operatore Kubernetes.

3. Eseguire con una rete di sicurezza:

   • Testare sempre le procedure di rollback in anticipo.
   • Monitorare le metriche dell'applicazione durante l'aggiornamento.
   • Tenere in standby il team responsabile del database.
   • Interrompi l'aggiornamento se la replica, il quorum, la copertura degli slot o lo stato di salute dell'applicazione peggiorano.

Commutazione controllata di PostgreSQL

Usare questo modello di switchover controllato per un database PostgreSQL primario con standby di streaming. Gli esempi mostrano i controlli dello stato di integrità, ma i comandi che promuovono, isolano e reintegrano i membri dipendono dall'operatore di PostgreSQL o dall'implementazione di alta disponibilità.

Prerequisites

• Usare una versione di PostgreSQL supportata e un operatore supportato o un'implementazione a disponibilità elevata.
• Posiziona i membri nei domini di guasto. Configura i budget di interruzione per i pod e i vincoli di distribuzione topologica per il tuo deployment.
• Verificare un backup recente ripristinandolo in un ambiente isolato.
• Verificare che l'applicazione si riconnette dopo una modifica primaria.
• Annotare i comandi specifici dell'operatore per la commutazione, il rollback e la riconnessione prima di avviare l'aggiornamento di AKS.

Passaggio 1: Convalidare la topologia di replica

Eseguire la query seguente sul database primario corrente:

kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;"

Il candidato previsto per il passaggio deve essere nello stato streaming. Se il tuo RPO richiede la replica sincrona, verifica anche che il candidato disponga del sync_state previsto per la tua configurazione.

Eseguire la query seguente sullo standby designato:

kubectl exec <candidate-standby-pod> -- psql -X -c "
SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();"

Verificare che pg_is_in_recovery() restituisca true e che i percorsi di ricezione e di riproduzione soddisfino la soglia di passaggio testata. La replica di streaming PostgreSQL è asincrona per impostazione predefinita, quindi un pod pronto da solo non stabilisce che lo standby viene intercettato.

Passaggio 2: Sospendere le scritture e cambiare le primarie

Se tutto il traffico dell'applicazione passa attraverso PgBouncer, connettersi al database di amministrazione PgBouncer e sospendere il database dell'applicazione:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "PAUSE app_db;"

PAUSE attende il rilascio delle connessioni server in base alla modalità di pooling configurata. Verificare che le scritture dell'applicazione non possano aggirare PgBouncer prima di fare affidamento su questo controllo.

Con le operazioni di scrittura sospese, completare queste azioni utilizzando l'operatore o l'implementazione di disponibilità elevata:

1. Ricontrollare i percorsi di ricezione e riproduzione del WAL del candidato.
2. Eseguire l'operazione di switchover supportata.
3. Verificare che esista esattamente un primario scrivibile.
4. Verificare che il database primario precedente sia delimitato o riconfigurato come standby.
5. Verificare che il servizio writer o l'endpoint si risolva nel nuovo database primario.

Riprendere PgBouncer solo dopo il superamento di questi controlli:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "RESUME app_db;"

Passaggio 3: Convalidare il passaggio

# Verify the new primary is writable and no longer in recovery.
kubectl exec <new-primary-pod> -- psql -X -c "SELECT pg_is_in_recovery();"

# Verify all expected standbys stream from the new primary.
kubectl exec <new-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

Operazioni di lettura, scrittura, transazioni e comportamento di riconnessione dell'applicazione di test. Confronta per quanto tempo le scritture non sono state disponibili e l'esito della replica con i tuoi obiettivi di RTO e RPO prima di continuare.

Configurazione della replica sincrona facoltativa

La replica sincrona può ridurre l'RPO per le transazioni riconosciute, ma aggiunge la latenza di commit e può ridurre la disponibilità di scrittura se i standby necessari non sono disponibili. L'esempio seguente attende che due server standby direttamente connessi e specificati per nome ripetano ogni transazione confermata:

# Use synchronous replication with multiple standbys
# postgresql.conf
synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)'
synchronous_commit = 'remote_apply'

Scegliere synchronous_standby_names e synchronous_commit in base ai requisiti di latenza misurata, posizionamento del dominio di errore e durabilità. Questa configurazione non garantisce una durata di cambio specifica.

Convalida completata con successo

Per convalidare lo stato di avanzamento, usare l'elenco di controllo seguente:

• La nuova replica primaria accetta letture e scritture.
• Tutte le repliche mostrano una replicazione corretta.
• L'applicazione si riconnette automaticamente.
• Sono stati superati i controlli di integrità dei dati e di coerenza delle applicazioni.
• I test di backup e ripristino hanno esito positivo sul nuovo primario.

Aggiornare il pool di nodi di AKS

Un'operazione az aks nodepool upgrade aggiorna l'intero pool di nodi. AKS aggiunge capacità aggiuntiva, isola e svuota i nodi esistenti, ne rigenera l'immagine e ripete il processo in base alle impostazioni di aggiornamento del pool di nodi. Non eseguire il comando una volta per ogni nodo o svuotare manualmente i nodi prima dell'operazione gestita.

1. Elencare le destinazioni di aggiornamento supportate per il cluster:

   az aks get-upgrades \
      --resource-group <resource-group-name> \
      --name <cluster-name> \
      --output table
   

2. Verificare che il piano di controllo sia già nella versione di destinazione selezionata. Configurare le impostazioni di aggiornamento in sequenza del pool di nodi in base al comportamento del carico di lavoro testato, alla quota e agli indirizzi subnet disponibili. Nell'esempio seguente viene usato il valore di produzione maxSurge consigliato:

   az aks nodepool update \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --max-surge 33% \
      --drain-timeout <minutes> \
      --node-soak-duration <minutes>
   

3. Avviare un aggiornamento gestito per il pool di nodi usando una destinazione restituita da az aks get-upgrades:

   az aks nodepool upgrade \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --kubernetes-version <target-version>
   

4. Monitora gli eventi di aggiornamento di AKS e l'integrità del database durante l'operazione:

   kubectl events --all-namespaces
   kubectl get pods -l app=postgres -o wide --watch
   

   Monitorare la replica, la disponibilità del database, gli errori dell'applicazione, la latenza e l'integrità dell'archiviazione nel sistema di osservabilità. Se un Pod Disruption Budget impedisce un drain, correggi invece il problema di disponibilità del workload anziché aggirare il budget.

Convalidare e ripristinare

Al termine dell'aggiornamento gestito, verificare le versioni dei nodi, la topologia PostgreSQL e il comportamento dell'applicazione:

kubectl get nodes
kubectl get pods -l app=postgres -o wide
kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

AKS non supporta il downgrade di un cluster o di un pool di nodi a una versione precedente di Kubernetes. Se il database non è integro, arrestare le operazioni di scrittura dell'applicazione e usare la procedura di ripristino o cambio del database supportata dall'operatore di database. Non reindirizzare le scritture al precedente nodo primario PostgreSQL, a meno che non si sia riallineato in sicurezza alla timeline corrente e non sia stato promosso dal meccanismo di alta disponibilità. Se l'aggiornamento di Kubernetes causa un problema di compatibilità irreversibile, ripristinare il servizio spostando il carico di lavoro in un cluster o un pool di nodi testato e ripristinando o replicando i dati in base al piano di ripristino.

Aggiornamento in sequenza della replica del cluster Redis

Usare questo modello per un cluster Redis con almeno tre nodi primari e almeno una replica per ogni replica primaria. L'ordine documentato per l'aggiornamento dei nodi del cluster Redis prevede di aggiornare prima le repliche, eseguire manualmente il failover di ogni nodo primario verso una replica aggiornata e quindi aggiornare il precedente nodo primario retrocesso. Il cluster Redis può restituire errori temporanei o reindirizzamenti durante le modifiche della topologia. Poiché il cluster Redis usa la replica asincrona, può perdere le scritture riconosciute. Verificare il comportamento di ritentativo del client e l'RPO accettabile prima dell'aggiornamento.

Passaggio 1: Registrare e convalidare la topologia

kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Registrare l'ID di ciascun nodo, il ruolo, l'assegnazione primaria-replica e l'intervallo di slot hash. Non procedere a meno che tutti e 16.384 gli slot siano coperti, ogni primario disponga di una replica sana in un dominio di guasto diverso e il cluster segnali cluster_state:ok.

Passaggio 2: Aggiornare le repliche

Per ogni replica, una alla volta:

1. Usare il meccanismo di distribuzione dell'operatore o del carico di lavoro per sostituire o riavviare la replica sulla capacità di AKS aggiornata.
2. Attendere che il pod sia pronto e che la replica si sincronizzi.
3. Confermare con CLUSTER NODES che rimanga assegnato alla replica primaria prevista.

Non eseguire CLUSTER FORGET per un riavvio del pod che conserva l'identità del nodo Redis. Se la sostituzione ha una nuova identità del nodo, usare redis-cli --cluster add-node con --cluster-slave e --cluster-master-id per aggiungerla come replica del primario designato. Attendere che la nuova replica venga visualizzata nella topologia del cluster.

kubectl exec <existing-redis-pod> -- redis-cli --cluster add-node \
   <new-replica-ip>:6379 127.0.0.1:6379 \
   --cluster-slave \
   --cluster-master-id <primary-node-id>

Passaggio 3: Eseguire il failover e aggiornare le primarie

Per ogni primario, uno alla volta:

1. Scegliere una replica aggiornata e intercettata di tale database primario.

2. Eseguire CLUSTER FAILOVERsulla replica che si desidera promuovere, non sulla replica primaria corrente:

   kubectl exec <candidate-replica-pod> -- redis-cli CLUSTER FAILOVER
   

3. Esegui il polling di ROLE, INFO REPLICATION o CLUSTER NODES finché il candidato non diventa il primario e il precedente primario ne è la replica. Una OK risposta significa solo che Redis ha accettato la richiesta di failover.

4. Sostituire o riavviare la replica primaria precedente abbassata di livello nella capacità di AKS aggiornata.

5. Attendere che torni a essere una replica sincronizzata prima di passare al primario successivo.

Non usare CLUSTER FAILOVER FORCE o TAKEOVER durante un aggiornamento pianificato. Queste opzioni ignorano il normale coordinamento e richiedono procedure separate di ripristino degli errori.

Passaggio 4: Convalidare il cluster Redis

kubectl exec <redis-pod> -- redis-cli CLUSTER INFO
kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Controllare la copertura degli slot, le assegnazioni primaria-replica, lo stato di integrità della replica, le operazioni di lettura e scrittura dell'applicazione, la gestione del reindirizzamento e l'RPO osservato.

Aggiornamento progressivo del set di replica MongoDB a partire dai secondari

Usare questo modello per un set di repliche MongoDB a tre membri o di dimensioni maggiori con un database secondario selezionabile. Durante la retrocessione e l'elezione della replica primaria, le operazioni di scrittura non riescono finché non viene eletta una nuova replica primaria. Le applicazioni devono ritentare le operazioni di scrittura idonee e le transazioni temporanee in base alle indicazioni del driver MongoDB.

Passaggio 1: Convalidare il set di repliche

kubectl exec <mongodb-pod> -- mongosh --quiet --eval "rs.status()"

Verificare che tutti i membri previsti siano integri, identificare la replica primaria corrente e verificare che almeno una replica secondaria selezionabile venga intercettata. Verificare anche il backup più recente tramite un ripristino di test.

Passaggio 2: Aggiornare i database secondari

Per ogni secondario, uno alla volta:

1. Sostituire o riavviare il membro sulla capacità AKS aggiornata utilizzando il meccanismo di distribuzione dell'operatore o del carico di lavoro.

2. Attendere che il pod diventi pronto.

3. Verificare che il membro restituisca lo SECONDARY stato e venga aggiornato prima di aggiornare un altro membro.

   kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
      "rs.status().members.map(member => ({name: member.name, state: member.stateStr, optime: member.optimeDate}))"
   

Passaggio 3: Declassare il primario

Viene eseguito rs.stepDown() solo sull'oggetto primario corrente. Il primo argomento specifica per quanto tempo il precedente primario non può essere rieletto. Il secondo argomento specifica per quanto tempo deve essere aggiornato un database secondario selezionabile. Scegli i valori in base al comportamento di selezione verificato.

kubectl exec <current-primary-pod> -- mongosh --quiet --eval "rs.stepDown(60, 30)"

Il comando può disconnettersi o restituire un errore come passaggio principale. Verificare lo stato del replica set da un altro membro finché non viene eletto esattamente un nuovo nodo primario:

kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
   "rs.status().members.map(member => ({name: member.name, state: member.stateStr}))"

Se nessun secondario idoneo all'elezione raggiunge il primario entro il periodo configurato, il primario non si dimette. Risolvere i problemi di integrità della replica prima di ripetere il tentativo. Non forzare il passaggio indietro durante un aggiornamento pianificato.

Passaggio 4: Aggiornare e convalidare il database primario precedente

Sostituire o riavviare il database primario precedente nella capacità del servizio Azure Kubernetes aggiornata. Attendere che torni come secondario integro, quindi convalidare:

• Esattamente un membro è PRIMARY.
• Tutti gli altri membri che contengono dati sono SECONDARY e intercettati.
• Le letture, le scritture, le scritture ripetibili e le transazioni dell'applicazione si comportano come previsto.
• L'intervallo di elezione misurato rispetta l'RTO dell'applicazione.
• Le verifiche di backup e ripristino sono state completate correttamente.