Uppgraderingsmönster för tillståndsfulla arbetsbelastningar i Azure Kubernetes Service (AKS)

Note

Den här artikeln innehåller referenser till termen slav (replik), vilket är en term som Microsoft inte längre använder. När termen tas bort från Redis-programvaran tar vi bort den från den här artikeln.

Använd dessa mönster för att samordna databastillgängligheten med en löpande uppgradering av Azure Kubernetes Service (AKS) nodpool.

Procedurerna i den här artikeln är planeringsramverk, inte garantier för tillgänglighet eller datahållbarhet. Resultatet beror på din databastopologi, replikeringsläge, lagring, operatör, avbrottsinställningar, beteende för klientförsök och arbetsbelastning. Repetera hela proceduren i en representativ miljö och mät om den uppfyller ditt mål för återställningstid (RTO) och mål för återställningspunkt (RPO).

Mönster för databasuppgradering som beskrivs i den här artikeln

Den här artikeln innehåller databasspecifika uppgraderingsmönster för AKS-kluster med tillståndskänsliga arbetsbelastningar, inklusive:

  • PostgreSQL-kontrollerad omkoppling.
  • Redis Cluster replika-först-rullande uppgradering.
  • Stegvis uppgradering av MongoDB-replikuppsättning med sekundär nod först.
  • Checklistor för nöduppgradering för säkerhetsåtgärder.
  • Planering för validering och återgång.

Till skillnad från en standarduppgradering av AKS-nodpoolen samordnar dessa mönster databasreplikeringskontroller och rolländringar med Kubernetes-nodersättning. Databas- och AKS-administratörer kan använda dessa mönster. Använd den dokumenterade växlings- eller uppgraderingsåtgärden för den databasoperator som hanterar distributionen. Ersätt inte dessa mönster med operatorspecifika instruktioner.

Mer information finns i följande relaterade artiklar:

För en snabbstart väljer du mönstret för din distribuerade produkt och topologi:

Välj ett mönster för databasuppgradering

Databastyp Uppgraderingsmönster Tillgänglighetsövervägande Passar bäst för
PostgreSQL Kontrollerad övergång Skrivningar pausas under tömning av anslutningar och omställning. Mät intervallet i din miljö. Primära distributioner och vänteläge för direktuppspelning med en redundansmekanism som stöds
Redis-kluster Rullande uppgradering med repliker först Klienter kan få tillfälliga fel eller omdirigeringar under redundansväxlingen. Redis-klustret använder asynkron replikering. Redis-klusterdriftsättningar med en replik för varje primärnod
MongoDB Sekundär första löpande uppgradering Skrivningar misslyckas från steg ned tills en ny primär har valts. Replikuppsättningar med tre medlemmar eller större med en valbar sekundär

Checklista för nöduppgradering

Om du behöver en snabb uppgradering för att åtgärda ett säkerhetsproblem ska du inte hoppa över databashälsa och återställningskontroller.

  1. Kontrollera kraven för arbetsbelastningen och AKS-uppgraderingen:

    # 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}'

    Kontrollera även replikeringshälsan med hjälp av ett kommando som stöds av databasen eller operatorn. Återställ den senaste säkerhetskopian i en isolerad miljö och bekräfta att klienter försöker igen vid tillfälliga anslutningsfel och fel vid val av primärnod.

  2. Välj endast det mönster som matchar din produkt och topologi:

    För andra databasprodukter följer du uppgraderingsvägledningen för den produkten eller dess Kubernetes-operator.

  3. Kör med ett skyddsnät:

    • Testa alltid återställningsprocedurer i förväg.
    • Övervaka programmått under uppgraderingen.
    • Håll databasteamet i vänteläge.
    • Stoppa uppgraderingen om replikering, kvorum, facktäckning eller programhälsa försämras.

PostgreSQL-kontrollerad övergång

Använd det här kontrollerade växlingsmönstret för en PostgreSQL-primär med väntelägen för direktuppspelning. Exemplen visar hälsokontroller, men de kommandon som befordrar, avgränsar och återansluter medlemmar beror på din PostgreSQL-operator eller implementering med hög tillgänglighet.

Important

Höj inte upp ett vänteläge förrän programskrivningarna har pausats, kandidaten har fastnat och din mekanism för hög tillgänglighet kan avgränsa eller konfigurera om den gamla primära filen. Att befordra en standby-server medan den tidigare primära noden fortfarande tar emot skrivningar kan skapa divergerande databastidslinjer.

Prerequisites

  • Använd en PostgreSQL-version som stöds och en operator som stöds eller implementering med hög tillgänglighet.
  • Placera medlemmar i feldomäner. Konfigurera störningsbudgetar för poddar och topologiska spridningsbegränsningar för din driftsättning.
  • Verifiera en säkerhetskopia nyligen genom att återställa den i en isolerad miljö.
  • Bekräfta att programmet återansluts efter en primär ändring.
  • Registrera de operatorspecifika kommandona för övergång, återställning och återkoppling innan du startar AKS-uppgraderingen.

Steg 1: Verifiera replikeringstopologin

Kör följande fråga på den aktuella primära noden:

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

Den avsedda övergångskandidaten måste vara i tillståndet streaming . Om ditt RPO kräver synkron replikering bör du också kontrollera att kandidaten har den förväntade sync_state för din konfiguration.

Kör följande fråga i det avsedda vänteläget:

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

Bekräfta att pg_is_in_recovery() returnerar true och att mottagnings- och återspelningsplatserna uppfyller tröskelvärdet för testad övergång. PostgreSQL-strömningsreplikering är asynkron som standard, så en podd som är redo innebär i sig inte att standbyn har kommit ikapp.

Steg 2: Pausa skrivningar och växla primärval

Om all programtrafik passerar genom PgBouncer ansluter du till PgBouncer-administrationsdatabasen och pausar programdatabasen:

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

PAUSE väntar på att serveranslutningar ska släppas enligt det konfigurerade poolläget. Kontrollera att programskrivningar inte kan kringgå PgBouncer innan du förlitar dig på den här kontrollen.

Med skrivningar pausade utför du följande åtgärder med hjälp av din operator eller hög tillgänglighetsimplementering:

  1. Kontrollera kandidatens WAL-mottagnings- och reprispositioner igen.
  2. Kör den växelåtgärd som stöds.
  3. Kontrollera att exakt en skrivbar primär finns.
  4. Kontrollera att den tidigare primärnoden är isolerad eller omkonfigurerad till en standbynod.
  5. Kontrollera att skrivartjänsten eller slutpunkten matchar den nya primära.

Återuppta PgBouncer först efter att dessa kontroller har godkänts:

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

Steg 3: Verifiera övergången

# 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;"

Testa programläsningar, skrivningar, transaktioner och återanslutningsbeteende. Jämför hur länge skrivningar inte var tillgängliga och replikeringsresultatet med din RTO och RPO innan du fortsätter.

Valfri konfiguration för synkron replikering

Synkron replikering kan minska RPO för bekräftade transaktioner, men den lägger till fördröjning för incheckning och kan minska skrivtillgängligheten om de nödvändiga väntelägena inte är tillgängliga. I följande exempel väntar systemet på att två namngivna, direkt anslutna standbyservrar ska återspela varje genomförd transaktion:

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

Välj synchronous_standby_names och synchronous_commit baserat på uppmätt svarstid, placering av feldomäner och hållbarhetskrav. Den här konfigurationen garanterar inte någon specifik varaktighet för övergången.

Validering av att det lyckades

Använd följande checklista för att verifiera förloppet:

  • Den nya primärnoden hanterar läs- och skrivåtgärder.
  • Alla repliker visar felfri replikering.
  • Programmet återansluts automatiskt.
  • Kontroller av dataintegritet och programkonsekvens har godkänts.
  • Säkerhetskopierings- och återställningstesterna lyckas på den nya primärnoden.

Uppgradera AKS-nodpoolen

En az aks nodepool upgrade åtgärd uppgraderar hela nodpoolen. AKS lägger till överspänningskapacitet, avspärrningar och tömmer gamla noder, återskapar dem och upprepar processen enligt inställningarna för nodpoolens uppgradering. Kör inte kommandot en gång för varje nod eller töm noderna manuellt före den hanterade åtgärden.

  1. Lista de uppgraderingsmål som stöds för klustret:

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

  2. Bekräfta att kontrollplanet redan finns i den valda målversionen. Konfigurera nodpoolens inställningar för löpande uppgradering baserat på testad arbetsbelastningsbeteende, kvot och tillgängliga undernätsadresser. I följande exempel används det rekommenderade produktionsvärdet maxSurge :

    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. Starta en hanterad uppgradering för nodpoolen med hjälp av ett mål som returneras av 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. Övervaka AKS-uppgraderingshändelser och databashälsa under hela åtgärden:

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

    Övervaka replikering, databastillgänglighet, programfel, svarstid och lagringshälsa i ditt observerbarhetssystem. Om en Pod Disruption Budget hindrar tömning av en nod ska du åtgärda tillgänglighetsproblemet för arbetslasten i stället för att kringgå budgeten.

Verifiera och återställa

När den hanterade uppgraderingen är klar kontrollerar du nodversionerna, PostgreSQL-topologin och programmets beteende:

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 stöder inte nedgradering av en kluster- eller nodpool till en tidigare Kubernetes-version. Om databasen inte är felfri stoppar du programskrivningar och använder databasoperatorns återställnings- eller växlingsprocedur som stöds. Omdirigera inte skrivningar till den tidigare PostgreSQL-primären om den inte på ett säkert sätt återansluter till den aktuella tidslinjen och befordrades av mekanismen för hög tillgänglighet. Om Kubernetes-uppgraderingen orsakar ett oåterkalleligt kompatibilitetsproblem återställer du tjänsten genom att flytta arbetsbelastningen till ett testat kluster eller en nodpool och återställa eller replikera data enligt återställningsplanen.

Redis-klusterreplik–första löpande uppgradering

Använd det här mönstret för ett Redis-kluster med minst tre primära noder och minst en replik för varje primär. Den dokumenterade uppgraderingsordningen för Redis-klusternoder innebär att man först uppgraderar replikerna, manuellt genomför failover för varje primärnod till en uppgraderad replika och sedan uppgraderar den tidigare primärnod som har nedgraderats. Redis-klustret kan returnera tillfälliga fel eller omdirigeringar under topologiändringar. Eftersom Redis-klustret använder asynkron replikering kan det förlora bekräftade skrivningar. Verifiera klientens återförsöksbeteende och det acceptabla RPO:t före uppgraderingen.

Note

Om en Redis-operatör hanterar klustret använder du det dokumenterade arbetsflödet för löpande uppgradering. Kombinera inte manuella klusterkommandon med en aktiv operatör om inte dokumentationen instruerar dig att göra det.

Steg 1: Registrera och verifiera topologin

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

Anteckna varje nod-ID, roll, tilldelning från primär till replik och intervall för hash-slotar. Fortsätt inte om inte alla 16 384 slotar är täckta, varje primär har en frisk replik i en annan feldomän och klustret rapporterar cluster_state:ok.

Steg 2: Uppgradera repliker

För varje replika, en i taget:

  1. Använd distributionsmekanismen för operatören eller arbetsbelastningen för att ersätta eller starta om repliken på den uppgraderade AKS-kapaciteten.
  2. Vänta tills podden är klar och att replikeringen hinner ifatt.
  3. Bekräfta med CLUSTER NODES att den fortfarande är tilldelad den förväntade primära enheten.

Kör inte CLUSTER FORGET för en omstart av en podd som bevarar Redis-nodens identitet. Om ersättningen har en ny nodidentitet använder du redis-cli --cluster add-node med --cluster-slave och --cluster-master-id för att lägga till den som en replik av den avsedda primärnoden. Vänta tills den nya repliken visas i klustertopologin.

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>

Steg 3: Växla över och uppgradera primära noder

För varje primärenhet, en i taget:

  1. Välj en uppgraderad, fångad replik av den primära.

  2. Kör CLUSTER FAILOVERpå den replik som du vill höja upp, inte på den aktuella primära:

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

  3. Polla ROLE, INFO REPLICATION eller CLUSTER NODES tills kandidaten är primär och den tidigare primären är dess replika. Ett OK svar innebär bara att Redis accepterade redundansbegäran.

  4. Ersätt eller starta om den tidigare primära noden i den uppgraderade AKS-kapaciteten.

  5. Vänta tills den returneras som en uppfångad replik innan du går vidare till nästa primära.

Använd inte CLUSTER FAILOVER FORCE eller TAKEOVER under en planerad uppgradering. Dessa alternativ kringgår normal samordning och kräver separata procedurer för haveriberedskap.

Steg 4: Verifiera Redis-kluster

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

Kontrollera slot-täckning, tilldelningar mellan primär och replika, replikeringsstatus, programmets läsningar och skrivningar, omdirigeringshantering och det observerade RPO-värdet.

MongoDB-replikuppsättning sekundär första löpande uppgradering

Använd det här mönstret för en mongoDB-replikuppsättning med tre medlemmar eller större som har en valbar sekundär. När primärnoden avgår och en ny primärnod väljs misslyckas skrivåtgärder tills den nya primärnoden har valts. Program måste försöka igen med berättigade skrivningar och tillfälliga transaktioner enligt mongoDB-drivrutinsvägledningen.

Note

Om en MongoDB-operator hanterar replikuppsättningen använder du dess dokumenterade arbetsflöde för rullande uppgradering och beredskapskontroller.

Steg 1: Verifiera replikuppsättningen

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

Bekräfta att alla förväntade medlemmar är felfria, identifiera den aktuella primära och kontrollera att minst en valfri sekundär är ikapp. Kontrollera även den senaste säkerhetskopieringen via en teståterställning.

Steg 2: Uppgradera sekundärfiler

För varje sekundär, en i taget:

  1. Ersätt eller starta om medlemmen på uppgraderad AKS-kapacitet med hjälp av distributionsmekanismen för operatören eller arbetsbelastningen.

  2. Vänta tills podden är redo.

  3. Kontrollera att medlemmen återvänder till SECONDARY staten och kommer ikapp innan du uppdaterar en annan medlem.

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

Steg 3: Sänk den primära

Kör rs.stepDown() endast mot den aktuella primära noden. Det första argumentet anger hur länge den tidigare primära inte kan bli omvald. Det andra argumentet anger hur länge en valbar sekundär måste komma ikapp. Välj värden baserat på ditt testade valbeteende.

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

Kommandot kan kopplas från eller returnera ett fel när den primära noden kliver ned. Kontrollera statusen för replikuppsättningen från en annan medlem tills exakt en ny primär har utsetts:

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

Om ingen valbar sekundärnod hinner ikapp inom den konfigurerade perioden kliver primärnoden inte ned. Åtgärda problem med replikeringens hälsa innan du försöker igen. Tvinga inte ned steget under en planerad uppgradering.

Steg 4: Uppgradera och verifiera den tidigare primära

Ersätt eller starta om den tidigare primärnoden i den uppgraderade AKS-kapaciteten. Vänta tills den returneras som en felfri sekundär och verifiera sedan:

  • Exakt en medlem är PRIMARY.
  • Alla andra databärande medlemmar är SECONDARY och i synk.
  • Programläsningar, skrivningar, återförsöksbara skrivningar och transaktioner fungerar som förväntat.
  • Det uppmätta omvalsintervallet uppfyller applikationens RTO.
  • Kontroller av säkerhetskopiering och återställning godkänns.
  • Last updated on