Les upgrades sont le moment où la fiabilité de la base est prouvée ou brisée. Cet article fournit un runbook rythmé, adapté au support, pour upgrader Couchbase Server sous le Couchbase Autonomous Operator (CAO), en utilisant le champ natif spec.paused pour freiner la progression entre nœuds. Résultat : un nœud à la fois, une fenêtre de stabilisation entre swaps, des signaux plus clairs et une fenêtre de rollback plus large.
Topologie de référence
La boucle d'upgrade rythmée
Objectifs
- Upgrader Couchbase Server avec un risque minimal.
- Garder une fenêtre délibérée pause + stabiliser + health check entre nœuds.
- Maintenir des options de rollback aussi longtemps que possible.
Checklist pre-upgrade (ne pas sauter)
- Tout au vert : phase cluster
Available, pas de rebalance actif, pas d'événements Warning. - Backups à jour et restaurables : backup complet terminé ; drill de restore fait ou délai compris.
- Tag de rollback enregistré : vérifier que l'ancienne image existe encore et peut être tirée.
- Décision XDCR enregistrée : désactiver pendant les upgrades prod pour un signal propre (recommandé), ou garder en pre-prod pour exercer le comportement.
Commandes de vérification rapides
export ENV=dev
export REGION=west
export NS=couchbase-${ENV}-${REGION}
kubectl -n "$NS" get couchbasecluster -o wide
kubectl -n "$NS" get pods -l app=couchbase
kubectl -n "$NS" get events --field-selector type=Warning | tail -20
kubectl -n "$NS" get couchbasecluster "$NS" -o jsonpath='paused={.spec.paused} phase={.status.phase} rebalance={.status.rebalanceProgress}{"\n"}'
Chemins d'exécution
- Préféré : lancer l'upgrade depuis votre workflow CI (dry-run d'abord, puis réel).
- Repli : lancer le script d'upgrade rythmé depuis une workstation (dry-run d'abord, puis réel).
Signaux de monitoring (ce que le support doit surveiller)
- Images des pods : passage ancien → nouveau ; un swap à la fois est idéal.
- État de pause :
spec.pausedpasse à true pendant la stabilisation ; jamais laissé true sans surveillance. - Rebalance : revient à none entre swaps ; investiguer les rebalances persistants.
- XDCR :
changes_leftmonte pendant le rebalance et se draine pendant la stabilisation ; l'absence de drain est un signal d'incident. - Redémarrages : tout redémarrage inattendu post-swap est un drapeau rouge.
Déclencheurs de rollback
- Le nœud ne devient pas healthy dans la fenêtre de timeout.
- Le rebalance échoue et ne se résout pas avec un seul retry après investigation.
- Le taux d'erreur applicatif dépasse la tolérance convenue.
- XDCR ne se rétablit pas après la fenêtre de récupération convenue.
- Tout bucket indisponible (vbuckets manquants) — traiter en P1.
Validation post-upgrade (clôture)
- Tous les pods sur l'image cible
- Phase cluster
Available - Pas de nouveaux événements Warning pendant 30+ minutes
- Backup réussi post-upgrade
- XDCR en régime stable récupéré (si utilisé)
- Tableaux de bord applicatifs au vert pendant 30+ minutes
Astuce : Pour une version narrative plus courte d'abord, commencez par le résumé du blog : Upgrades Couchbase avec portes de pause CAO.
