Modèles de mise à niveau de charge de travail avec état pour Azure Kubernetes Service (AKS)

Utilisez ces modèles pour coordonner la disponibilité de la base de données avec une mise à niveau propagée de pool de nœuds Azure Kubernetes Service (AKS).

Les procédures décrites dans cet article sont des infrastructures de planification, et non des garanties de durabilité des données ou de disponibilité. Le résultat dépend de la topologie de votre base de données, du mode de réplication, du stockage, de l’opérateur, des paramètres d’interruption, du comportement de nouvelle tentative du client et de la charge de travail. Répétez la procédure complète dans un environnement représentatif et mesurez si elle répond à votre objectif de temps de récupération (RTO) et à l’objectif de point de récupération (RPO).

Modèles de mise à niveau de base de données abordés dans cet article

Cet article présente des modèles de mise à niveau propres aux bases de données pour les clusters AKS exécutant des charges de travail avec état, notamment :

• Basculement contrôlé par PostgreSQL.
• Mise à niveau progressive du cluster Redis en commençant par les répliques.
• Mise à niveau progressive d'un jeu de réplicas MongoDB en commençant par les nœuds secondaires.
• Listes de contrôle de mise à niveau d’urgence pour les réponses de sécurité.
• Planification de la validation et du retour arrière.

Contrairement à une mise à niveau standard d’un pool de nœuds AKS, ces modèles coordonnent les vérifications de réplication de base de données et les modifications de rôle avec le remplacement des nœuds Kubernetes. Les administrateurs de base de données et AKS peuvent utiliser ces modèles. Utilisez l’opération de basculement ou de mise à niveau documentée pour l’opérateur de base de données qui gère votre déploiement. Ne remplacez pas ces modèles par des instructions spécifiques à l’opérateur.

Pour plus d’informations, consultez les articles suivants :

• Pour mettre à niveau vos clusters AKS de production, consultez les stratégies de mise à niveau de production AKS.
• Pour comparer les approches de mise à niveau pour votre cluster AKS, consultez les options et recommandations de mise à niveau.
• Pour utiliser le hub de scénarios pour vous aider à choisir la bonne approche de mise à niveau AKS, consultez les scénarios de mise à niveau AKS : Choisissez votre chemin d’accès.

Pour un démarrage rapide, sélectionnez la configuration correspondant à votre produit et à votre topologie déployés :

• Liste de contrôle de mise à niveau d’urgence
• Basculement contrôlé par PostgreSQL
• Mise à niveau progressive du cluster Redis en commençant par les réplicas
• Mise à niveau progressive du replica set MongoDB en commençant par les nœuds secondaires

Choisir un modèle de mise à niveau de base de données

Liste de contrôle de mise à niveau d’urgence

Si vous avez besoin d’une mise à niveau accélérée pour remédier à un problème de sécurité, ne faites pas l’impasse sur les vérifications de l’état de santé de la base de données et de récupération.

1. Vérifiez les prérequis de la charge de travail et de la mise à niveau 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}'
   

   Vérifiez également l’intégrité de la réplication à l’aide d’une commande prise en charge par la base de données ou l’opérateur. Restaurez la dernière sauvegarde dans un environnement isolé et vérifiez que les clients réessayent les erreurs de connexion temporaire et d’élection.

2. Choisissez uniquement le modèle qui correspond à votre produit et à votre topologie :

   • PostgreSQL : Utilisez le basculement contrôlé.
   • cluster Redis : utilisez la mise à niveau progressive en commençant par les réplicas.
   • Ensemble de réplicas MongoDB : utilisez une mise à niveau progressive en commençant par les nœuds secondaires.

   Pour d’autres produits de base de données, suivez les instructions de mise à niveau pour ce produit ou son opérateur Kubernetes.

3. Exécutez avec un filet de sécurité :

   • Testez toujours les procédures de restauration à l’avance.
   • Surveillez les métriques d’application pendant la mise à niveau.
   • Conservez l’équipe de base de données en veille.
   • Arrêtez la mise à niveau si la réplication, le quorum, la couverture de l’emplacement ou l’intégrité de l’application se dégrade.

Basculement contrôlé par PostgreSQL

Utilisez ce modèle de basculement contrôlé pour un serveur principal PostgreSQL avec des secours de streaming. Les exemples montrent des vérifications d’intégrité, mais les commandes qui favorisent, clôturent et rejoignent les membres dépendent de votre opérateur PostgreSQL ou de votre implémentation de haute disponibilité.

Prerequisites

• Utilisez une version PostgreSQL prise en charge et un opérateur pris en charge ou une implémentation de haute disponibilité.
• Répartissez les membres sur plusieurs domaines de défaillance. Configurez les budgets d’interruption de pod et les contraintes de répartition de topologie pour votre déploiement.
• Vérifiez une sauvegarde récente en la restaurant dans un environnement isolé.
• Vérifiez que l’application se reconnecte après une modification principale.
• Enregistrez les commandes spécifiques à l’opérateur pour le basculement, la restauration et la réintégration avant de commencer la mise à niveau d’AKS.

Étape 1 : Valider la topologie de réplication

Exécutez la requête suivante sur le principal actuel :

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

Le candidat de basculement prévu doit être dans l’état streaming . Si votre RPO nécessite une réplication synchrone, vérifiez également que le candidat a la configuration attendue sync_state .

Exécutez la requête suivante sur le serveur de secours prévu :

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

Vérifiez que pg_is_in_recovery() renvoie true et que les emplacements de réception et de relecture respectent le seuil de basculement que vous avez testé. La réplication en continu de PostgreSQL est asynchrone par défaut, donc le seul fait qu’un pod soit prêt ne permet pas de conclure que le serveur de secours a rattrapé son retard.

Étape 2 : Suspendre les écritures et changer de primaires

Si tout le trafic d’application passe par PgBouncer, connectez-vous à la base de données d’administration PgBouncer et suspendez la base de données d’application :

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

PAUSE attend que les connexions de serveur soient libérées en fonction du mode de regroupement configuré. Vérifiez que les opérations d’écriture de l’application ne peuvent pas contourner PgBouncer avant de vous appuyer sur ce contrôle.

Avec les écritures suspendues, effectuez ces actions à l’aide de votre opérateur ou de votre implémentation de haute disponibilité :

1. Revérifiez les positions de réception et de rejeu du WAL du candidat.
2. Exécutez l’opération de basculement prise en charge.
3. Vérifiez qu’il existe exactement un principal accessible en écriture.
4. Vérifiez que l’ancien nœud principal est isolé ou reconfiguré comme nœud de secours.
5. Vérifiez que le service d’écriture ou le point de terminaison pointe vers le nouveau principal.

Reprendre PgBouncer uniquement après la réussite de ces vérifications :

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

Étape 3 : Valider le basculement

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

Testez les lectures, les écritures, les transactions et le comportement de reconnexion de l’application. Comparez la durée d’indisponibilité des écritures et le résultat de la réplication avec votre RTO et votre RPO avant de continuer.

Configuration de réplication synchrone facultative

La réplication synchrone peut réduire le RPO pour les transactions reconnues, mais elle ajoute une latence de validation et peut réduire la disponibilité de l’écriture si les secours requis ne sont pas disponibles. L’exemple suivant attend que deux personnes nommées, directement connectées, relectent chaque transaction validée :

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

Choisissez synchronous_standby_names et synchronous_commit en fonction de la latence mesurée, de l’emplacement du domaine d’échec et des exigences de durabilité. Cette configuration ne garantit pas une durée de basculement spécifique.

Validation réussie

Pour valider votre progression, utilisez la liste de contrôle suivante :

• Le nouveau nœud principal accepte les opérations de lecture et d’écriture.
• Toutes les répliques affichent une réplication en bon état.
• L’application se reconnecte automatiquement.
• Les vérifications de l’intégrité des données et de la cohérence des applications sont réussies.
• Les tests de sauvegarde et de restauration sont réussis sur le nouveau serveur principal.

Mettre à niveau le pool de nœuds AKS

Une az aks nodepool upgrade opération met à niveau l’intégralité du pool de nœuds. AKS ajoute une capacité d’augmentation, des cordons et draine les anciens nœuds, les réimage et répète le processus en fonction des paramètres de mise à niveau du pool de nœuds. N’exécutez pas la commande une fois pour chaque nœud et ne drainez pas manuellement les nœuds avant l’opération gérée.

1. Répertoriez les cibles de mise à niveau prises en charge pour le cluster :

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

2. Vérifiez que le plan de contrôle est déjà à la version cible sélectionnée. Configurez les paramètres de mise à niveau propagée du pool de nœuds en fonction du comportement de charge de travail testé, du quota et des adresses de sous-réseau disponibles. L’exemple suivant utilise la valeur de production maxSurge recommandée :

   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. Démarrez une mise à niveau gérée pour le pool de nœuds à l’aide d’une cible retournée par 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. Surveillez les événements de mise à niveau AKS et l’intégrité de la base de données tout au long de l’opération :

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

   Surveillez la réplication, la disponibilité de la base de données, les erreurs d’application, la latence et l’intégrité du stockage dans votre système d’observabilité. Si un Pod Disruption Budget bloque un drain, corrigez le problème de disponibilité de la charge de travail au lieu de contourner ce budget.

Valider et récupérer

Une fois la mise à niveau gérée terminée, vérifiez les versions de nœud, la topologie PostgreSQL et le comportement de l’application :

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 ne prend pas en charge la rétrogradation d’un cluster ou d’un pool de nœuds vers une version antérieure de Kubernetes. Si la base de données n’est pas saine, arrêtez les écritures d’application et utilisez la procédure de récupération ou de basculement prise en charge par l’opérateur de base de données. Ne redirigez pas les écritures vers l’ancien serveur principal PostgreSQL, sauf si elle a rejoint en toute sécurité la chronologie actuelle et a été promue par le mécanisme de haute disponibilité. Si la mise à niveau de Kubernetes provoque un problème de compatibilité irrécupérable, restaurez le service en déplaçant la charge de travail vers un cluster ou un pool de nœuds testé et en restaurant ou réplicant des données en fonction de votre plan de récupération.

Mise à niveau progressive du cluster Redis en commençant par les répliques

Utilisez ce modèle pour un cluster Redis avec au moins trois nœuds principaux et au moins un réplica pour chaque cluster principal. L’ordre documenté de mise à niveau des nœuds d’un cluster Redis consiste à mettre d’abord à niveau les réplicas, à faire basculer manuellement chaque nœud primaire vers un réplica mis à niveau, puis à mettre à niveau l’ancien nœud primaire rétrogradé. Redis Cluster peut renvoyer des erreurs temporaires ou des redirections lors de changements de topologie. Étant donné que le cluster Redis utilise la réplication asynchrone, il peut perdre les écritures reconnues. Validez le comportement de nouvelle tentative du client et le RPO acceptable avant la mise à niveau.

Étape 1 : Enregistrer et valider la topologie

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

Enregistrez l’identifiant de chaque nœud, son rôle, l’association principal-réplique et la plage de slots de hachage. Ne continuez pas tant que les 16 384 emplacements ne sont pas tous couverts, que chaque nœud principal ne dispose pas d’un réplica sain dans un domaine de défaillance distinct et que le cluster indique cluster_state:ok.

Étape 2 : Mettre à niveau les réplicas

Pour chaque réplique, une à la fois :

1. Utilisez votre mécanisme de déploiement d’opérateur ou de charge de travail pour remplacer ou redémarrer le réplica sur une capacité AKS mise à niveau.
2. Attendez que le pod soit prêt et que la réplication rattrape son retard.
3. Confirmez avec CLUSTER NODES qu’elle est toujours affectée au nœud principal attendu.

N’exécutez pas CLUSTER FORGET lors d’un redémarrage de pod qui préserve l’identité du nœud Redis. Si le remplacement a une nouvelle identité de nœud, utilisez redis-cli --cluster add-node avec --cluster-slave et --cluster-master-id pour l’ajouter en tant que réplica du nœud principal prévu. Attendez que la nouvelle réplique apparaisse dans la topologie du 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>

Étape 3 : Effectuer le basculement et mettre à niveau les serveurs principaux

Pour chaque élément principal, un à la fois :

1. Choisissez une réplique mise à niveau et à jour de ce primaire.

2. Exécutez cette commande CLUSTER FAILOVERsur le réplica que vous souhaitez promouvoir, et non sur l'instance primaire actuelle :

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

3. Interrogez ROLE, INFO REPLICATION ou CLUSTER NODES jusqu’à ce que le candidat devienne le primaire et que l’ancien primaire devienne sa réplique. Une réponse OK signifie seulement que Redis a accepté la demande de basculement.

4. Remplacez ou redémarrez l’ancien nœud principal rétrogradé sur la capacité AKS mise à niveau.

5. Attendez qu’il soit de nouveau synchronisé avant de passer au primaire suivant.

N’utilisez pas CLUSTER FAILOVER FORCE ou TAKEOVER pendant une mise à niveau planifiée. Ces options contournent la coordination normale et nécessitent des procédures distinctes de récupération d’échec.

Étape 4 : Valider le 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

Vérifiez la couverture des slots, les assignations du primaire aux réplicas, l’état de santé de la réplication, les opérations de lecture et d’écriture de l’application, la gestion de la redirection et le RPO observé.

Mise à niveau progressive d’un jeu de réplicas MongoDB en commençant par les nœuds secondaires

Utilisez cette configuration pour un jeu de réplicas MongoDB de trois membres ou plus comportant un secondaire susceptible d’être élu. Lors de la rétrogradation du nœud primaire et de l’élection, les opérations d’écriture échouent jusqu’à ce qu’un nouveau nœud primaire soit élu. Les applications doivent réessayer les écritures éligibles et les transactions temporaires en fonction des instructions du pilote MongoDB.

Étape 1 : Valider le jeu de réplicas

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

Vérifiez que tous les membres attendus sont sains, identifiez le principal actuel et vérifiez qu’au moins un secondaire pouvant être choisi est rattrapé. Vérifiez également la dernière sauvegarde via une restauration de test.

Étape 2 : Mettre à niveau les fichiers secondaires

Pour chaque secondaire, une à la fois :

1. Remplacez ou redémarrez le membre sur la capacité AKS mise à niveau à l’aide du mécanisme de déploiement d’opérateur ou de charge de travail.

2. Attendez que le pod soit prêt.

3. Vérifiez que le membre revient à l’état SECONDARY et ait rattrapé son retard avant de mettre à jour un autre membre.

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

Étape 3 : Descendre dans la hiérarchie principale

Exécutez rs.stepDown() uniquement sur le serveur principal actuel. Le premier argument indique pendant combien de temps l’ancien primaire ne peut pas être réélu. Le deuxième argument spécifie la durée pendant laquelle un secondaire pouvant être choisi doit rattraper. Choisissez des valeurs en fonction de votre comportement d’élection testé.

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

La commande peut déconnecter ou renvoyer une erreur en tant que étapes principales. Interrogez l’état de l’ensemble de réplicas depuis un autre membre jusqu’à ce qu’exactement un nouveau primaire soit élu :

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

Si aucun secondaire éligible ne rattrape son retard dans le délai configuré, le primaire ne se retire pas. Résolvez les problèmes de réplication avant de réessayer. Ne forcez pas la rétrogradation lors d’une mise à niveau planifiée.

Étape 4 : Mettre à niveau et valider l’ancien principal

Remplacez ou redémarrez le nœud principal précédent dans la capacité AKS mise à niveau. Attendez qu’elle redevienne une base de données secondaire saine, puis validez :

• Un seul membre est PRIMARY.
• Tous les autres membres contenant des données sont SECONDARY et à jour.
• Les opérations de lecture et d’écriture de l’application, les écritures pouvant faire l’objet d’une nouvelle tentative et les transactions se comportent comme prévu.
• L’intervalle d’élection mesuré respecte le RTO de l’application.
• Les vérifications de sauvegarde et de restauration ont réussi.