Upgradepatronen voor statusbehoudende workloads in Azure Kubernetes Service (AKS)

Gebruik deze patronen om de beschikbaarheid van databases te coördineren tijdens een doorlopende upgrade van een knooppool van Azure Kubernetes Service (AKS).

De procedures in dit artikel zijn planningsframeworks, geen garanties voor beschikbaarheid of duurzaamheid van gegevens. Het resultaat is afhankelijk van uw databasetopologie, replicatiemodus, opslag, operator, onderbrekingsinstellingen, gedrag voor opnieuw proberen van clients en workload. Oefen de volledige procedure in een representatieve omgeving en meet of deze voldoet aan uw beoogde hersteltijd (RTO) en RPO (Recovery Point Objective).

Patronen voor database-upgrades die in dit artikel aan bod komen

Dit artikel biedt databasespecifieke upgradepatronen voor AKS-clusters met statusbehoudende workloads, waaronder:

• PostgreSQL-gestuurde switchover.
• Rollende upgrade van het Redis-cluster, waarbij eerst de replica's worden bijgewerkt.
• Rolling upgrade van MongoDB-replicaset met prioriteit voor secondaries.
• Controlelijsten voor noodupgrades voor beveiligingsreacties.
• Planning voor validatie en terugdraaien.

In tegenstelling tot een standaard upgrade van een AKS-knooppuntgroep coördineren deze patronen databasereplicatiecontroles en rolwijzigingen met vervanging van Kubernetes-knooppunt. Database- en AKS-beheerders kunnen deze patronen gebruiken. Gebruik de gedocumenteerde switchover- of upgradebewerking voor de databaseoperator die uw implementatie beheert. Vervang deze patronen niet door operatorspecifieke instructies.

Zie de volgende verwante artikelen voor meer informatie:

• Als u uw AKS-productieclusters wilt upgraden, raadpleegt u de strategieën voor de productie-upgrade van AKS.
• Zie Upgradeopties en aanbevelingen voor het vergelijken van upgrademethoden voor uw AKS-cluster.
• Als u de scenariohub wilt gebruiken om u te helpen de juiste AKS-upgradebenadering te kiezen, raadpleegt u AKS-upgradescenario's: Kies uw pad.

Selecteer voor een quickstart het patroon voor uw geïmplementeerde product en topologie:

• Controlelijst voor noodupgrades
• Door PostgreSQL gestuurde switchover
• Replica-eerst rolling upgrade van Redis Cluster
• Secundaire rolling upgrade van MongoDB-replicaset

Een upgradepatroon voor een database kiezen

Controlelijst voor noodupgrades

Als u een versnelde upgrade nodig hebt om een beveiligingsprobleem op te lossen, slaat u de databasestatus- en herstelcontroles niet over.

1. Controleer de vereisten voor de workload en AKS-upgrade:

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

   Controleer ook de replicatiestatus met behulp van een opdracht die wordt ondersteund door de database of operator. Herstel de meest recente back-up in een geïsoleerde omgeving en bevestig dat clients tijdelijke verbindings- en verkiezingsfouten opnieuw proberen.

2. Kies alleen het patroon dat overeenkomt met uw product en topologie:

   • PostgreSQL: Gebruik een gecontroleerde overschakeling.
   • Redis-cluster: gebruik de rolling upgrade van replica-first.
   • MongoDB-replicaset: Gebruik secondary-first rolling upgrade.

   Voor andere databaseproducten volgt u de upgraderichtlijnen voor dat product of de Bijbehorende Kubernetes-operator.

3. Werk met een veiligheidsnet:

   • Test altijd vooraf terugdraaiprocedures.
   • Bewaak metrische toepassingsgegevens tijdens de upgrade.
   • Houd het databaseteam stand-by.
   • Stop de upgrade als replicatie, quorum, sitedekking of toepassingsstatus verslechtert.

Door PostgreSQL beheerde omschakeling

Gebruik dit beheerde switchover-patroon voor een PostgreSQL-primaire met streaming stand-bys. In de voorbeelden worden statuscontroles weergegeven, maar de opdrachten die leden promoten, omheinen en opnieuw lid worden, zijn afhankelijk van uw PostgreSQL-operator of implementatie met hoge beschikbaarheid.

Prerequisites

• Gebruik een ondersteunde PostgreSQL-versie en een ondersteunde operator of implementatie met hoge beschikbaarheid.
• Plaats leden in foutdomeinen. Configureer budgetten voor podonderbrekingen en topologiespreidingsbeperkingen voor uw implementatie.
• Controleer een recente back-up door deze te herstellen in een geïsoleerde omgeving.
• Controleer of de toepassing opnieuw verbinding maakt na een primaire wijziging.
• Noteer de operatorspecifieke opdrachten voor overschakeling, terugdraaien en opnieuw deelnemen voordat u de AKS-upgrade start.

Stap 1: De replicatietopologie valideren

Voer de volgende query uit op de huidige primaire server:

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

De beoogde overschakelingskandidaat moet de streaming status hebben. Als voor uw RPO synchrone replicatie is vereist, controleert u ook of de kandidaat de verwachte configuratie sync_state heeft.

Voer de volgende query uit op de beoogde stand-by:

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

Controleer of pg_is_in_recovery()true retourneert en of de ontvangst- en replaylocaties voldoen aan uw geteste omschakeldrempel. PostgreSQL-streamingreplicatie is standaard asynchroon, dus een pod die gereed is, betekent nog niet dat de standby-replica is bijgewerkt.

Stap 2: Schrijfbewerkingen onderbreken en schakelen tussen primaries

Als al het toepassingsverkeer via PgBouncer wordt doorgegeven, maakt u verbinding met de PgBouncer-beheerdatabase en onderbreekt u de toepassingsdatabase:

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

PAUSE wacht tot serververbindingen worden vrijgegeven volgens de geconfigureerde poolmodus. Controleer of schrijfacties van applicaties PgBouncer niet kunnen omzeilen voordat u op deze controle vertrouwt.

Als schrijfbewerkingen zijn onderbroken, voert u deze acties uit met behulp van uw operator of implementatie met hoge beschikbaarheid:

1. Controleer de receive- en replayposities van de kandidaat opnieuw.
2. Voer de ondersteunde switchover-bewerking uit.
3. Controleer of er precies één beschrijfbare primaire bestaat.
4. Controleer of de voormalige primaire server is geïsoleerd of opnieuw is geconfigureerd als standby.
5. Controleer of de writer-service of het eindpunt naar de nieuwe primaire instantie verwijst.

Hervat PgBouncer pas nadat deze controles zijn geslaagd:

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

Stap 3: De switchover valideren

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

Test de lees-, schrijf-, transacties- en herverbindingsgedrag van toepassingen. Vergelijk hoe lang schrijfacties niet mogelijk waren en het resultaat van de replicatie met uw RTO en RPO voordat u doorgaat.

Optionele synchrone replicatieconfiguratie

Synchrone replicatie kan de RPO voor bevestigde transacties verlagen, maar het verhoogt de commitlatentie en kan de schrijfbeschikbaarheid verminderen als de vereiste stand-by’s niet beschikbaar zijn. In het volgende voorbeeld wordt gewacht op twee benoemde, rechtstreeks verbonden stand-bys om elke vastgelegde transactie opnieuw af te spelen:

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

Kies synchronous_standby_names en synchronous_commit op basis van gemeten latentie, plaatsing van foutendomeinen en duurzaamheidsvereisten. Deze configuratie garandeert geen specifieke overschakelingsduur.

Geslaagde validatie

Gebruik de volgende controlelijst om uw voortgang te valideren:

• Nieuwe primaire versie accepteert lees- en schrijfbewerkingen.
• Alle replica's geven een goede replicatie weer.
• De toepassing wordt automatisch opnieuw verbonden.
• Controles op gegevensintegriteit en applicatieconsistentie zijn geslaagd.
• Back-up- en hersteltests worden doorgegeven aan de nieuwe primaire server.

De AKS-knooppuntgroep upgraden

Met een az aks nodepool upgrade bewerking wordt de hele knooppuntgroep bijgewerkt. AKS voegt extra capaciteit toe, markeert oude knooppunten als niet-planbaar en ontruimt ze, voorziet ze opnieuw van een image en herhaalt dit proces volgens de upgrade-instellingen van de knooppuntgroep. Voer de opdracht niet eenmaal uit voor elk knooppunt of maak de knooppunten handmatig leeg vóór de beheerde bewerking.

1. Vermeld de ondersteunde upgradedoelen voor het cluster:

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

2. Controleer of het besturingsvlak zich al in de geselecteerde doelversie bevindt. Configureer de rolling-upgrade-instellingen van de nodepool op basis van het geteste gedrag van workloads, quota en beschikbare subnetadressen. In het volgende voorbeeld wordt de aanbevolen productiewaarde maxSurge gebruikt:

   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. Start een beheerde upgrade voor de knooppuntgroep met behulp van een doel dat wordt geretourneerd door 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. Bewaak AKS-upgrade-gebeurtenissen en databasestatus tijdens de bewerking:

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

   Bewaak replicatie, beschikbaarheid van databases, toepassingsfouten, latentie en opslagstatus in uw waarneembaarheidssysteem. Als een Pod Disruption Budget een drain blokkeert, los dan het beschikbaarheidsprobleem van de workload op in plaats van het budget te omzeilen.

Valideren en herstellen

Nadat de beheerde upgrade is voltooid, controleert u de knooppuntversies, postgreSQL-topologie en het gedrag van de toepassing:

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 biedt geen ondersteuning voor het downgraden van een cluster of knooppuntgroep naar een eerdere Kubernetes-versie. Als de database niet in orde is, stopt u schrijfbewerkingen van de toepassing en gebruikt u de ondersteunde herstel- of schakelprocedure van de databaseoperator. Leid schrijfbewerkingen niet om naar de voormalige PostgreSQL-primaire, tenzij deze veilig opnieuw deel uitmaakt van de huidige tijdlijn en is gepromoveerd door het mechanisme voor hoge beschikbaarheid. Als de Kubernetes-upgrade een onherstelbaar compatibiliteitsprobleem veroorzaakt, herstelt u de service door de workload te verplaatsen naar een getest cluster of knooppuntgroep en gegevens te herstellen of te repliceren volgens uw herstelplan.

Rolling upgrade van Redis Cluster met eerst de replica's

Gebruik dit patroon voor een Redis-cluster met ten minste drie primaire knooppunten en ten minste één replica voor elke primaire. De gedocumenteerde upgradevolgorde voor Redis-clusters is om eerst replica's te upgraden, handmatig een failover uit te voeren voor elke primaire naar een bijgewerkte replica en vervolgens de gedegradeerde voormalige primaire replica bij te werken. Redis Cluster kan tijdens topologiewijzigingen tijdelijke fouten of doorverwijzingen geven. Omdat Redis-cluster asynchrone replicatie gebruikt, kunnen herkende schrijfbewerkingen verloren gaan. Valideer het client-opnieuwpogingsgedrag en de acceptabele RPO voorafgaand aan de upgrade.

Stap 1: de topologie vastleggen en valideren

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

Leg elke knooppunt-ID, rol, primaire-naar-replica-toewijzing en hash-slotbereik vast. Ga niet verder tenzij alle 16.384 slots zijn toegewezen, elke primaire een gezonde replica in een ander foutdomein heeft en het cluster cluster_state:ok meldt.

Stap 2: Replica’s bijwerken

Voor elke replica, één voor één:

1. Gebruik uw operator- of workloadimplementatiemechanisme om de replica te vervangen of opnieuw op te starten op bijgewerkte AKS-capaciteit.
2. Wacht totdat de pod gereed is en de replicatie weer bij is.
3. Bevestig met CLUSTER NODES dat deze toegewezen blijft aan de verwachte primaire server.

Voer CLUSTER FORGET niet uit voor een herstart van een pod waarbij de identiteit van het Redis-knooppunt behouden blijft. Als de vervanging een nieuwe knooppuntidentiteit heeft, gebruikt u redis-cli --cluster add-node met --cluster-slave en --cluster-master-id om de vervanging toe te voegen als replica van het beoogde primaire knooppunt. Wacht totdat de nieuwe replica wordt weergegeven in de clustertopologie.

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>

Stap 3: Overschakelen en de primaire servers upgraden

Voor elke primaire, één voor één:

1. Kies een geüpgradede, bijgewerkte replica van die primaire.

2. Voer CLUSTER FAILOVERuit op de replica die u wilt promoveren, niet op de huidige primaire versie:

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

3. Controleer ROLE, INFO REPLICATION of CLUSTER NODES totdat de kandidaat de primaire is en de voormalige primaire de replica ervan is. Een OK antwoord betekent alleen dat Redis de failoveraanvraag heeft geaccepteerd.

4. Vervang of herstart de teruggezette voormalige primaire op de geüpgradede AKS-capaciteit.

5. Wacht tot deze weer een bijgewerkte replica is voordat u naar de volgende primaire server gaat.

Gebruik TAKEOVER of CLUSTER FAILOVER FORCE niet tijdens een geplande upgrade. Deze opties omzeilen normale coördinatie en vereisen afzonderlijke procedures voor foutherstel.

Stap 4: Redis-cluster valideren

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

Controleer slotdekking, toewijzingen van primair naar replica, de status van de replicatie, lees- en schrijfbewerkingen van applicaties, de afhandeling van omleidingen en de waargenomen RPO.

MongoDB-replicaset rolling upgrade waarbij eerst de secondaries worden bijgewerkt

Gebruik dit patroon voor een MongoDB-replicaset met drie of meer leden en een verkiesbaar secundair lid. Tijdens de primaire stap en verkiezing mislukken schrijfbewerkingen totdat een nieuwe primaire wordt gekozen. Toepassingen moeten in aanmerking komende schrijfbewerkingen en tijdelijke transacties opnieuw proberen volgens de richtlijnen van het MongoDB-stuurprogramma.

Stap 1: De replicaset valideren

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

Controleer of alle verwachte leden gezond zijn, identificeer de huidige primaire node en controleer of ten minste één verkiesbare secundaire node is bijgewerkt. Controleer ook de meest recente back-up via een testherstel.

Stap 2: secundaire bestanden upgraden

Voor elke secundaire, één voor één:

1. Vervang het lid of start het opnieuw op op de geüpgradede AKS-capaciteit met behulp van het operator- of workload-implementatiemechanisme.

2. Wacht totdat de pod gereed is.

3. Controleer of het lid terugkeert naar de SECONDARY staat en bijwerkt voordat u een ander lid bijwerkt.

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

Stap 3: Verlaag de primaire waarde

Voer rs.stepDown() alleen uit tegen de huidige primaire. Het eerste argument geeft aan hoe lang de voormalige primaire primaire kan niet opnieuw worden gekozen. Het tweede argument specificeert hoeveel tijd een verkiesbare secundaire nodig heeft om bij te lopen. Kies waarden op basis van uw geteste verkiezingsgedrag.

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

De opdracht kan de verbinding verbreken of een fout geven wanneer de primaire node terugtreedt. Controleer de status van de replicaset van een ander lid totdat precies één nieuwe primaire waarde is geselecteerd:

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

Als geen verkiesbare secondary binnen de geconfigureerde periode bijtrekt, treedt de primary niet af. Herstel de status van replicatie voordat u het opnieuw probeert. Forceer de verlaging niet tijdens een geplande upgrade.

Stap 4: De voormalige primaire upgraden en valideren

Vervang de vorige primaire versie of start deze opnieuw op bijgewerkte AKS-capaciteit. Wacht tot deze weer als een gezonde secundaire verschijnt en valideer:

• Precies één lid is PRIMARY.
• Alle andere gegevensdragende leden zijn SECONDARY en bijgewerkt.
• Leesbewerkingen, schrijfbewerkingen, opnieuw uitvoerbare schrijfbewerkingen en transacties van de toepassing werken zoals verwacht.
• Het gemeten verkiezingsinterval voldoet aan de RTO van de toepassing.
• Back-up- en herstelcontroles zijn geslaagd.