De Percona XtraDB Cluster sur Kubernetes à MySQL managé Scaleway

Sur une mission récente, la base MySQL d’un WordPress tournait dans le cluster Kubernetes (Scaleway Kapsule) avec l’opérateur Percona : un cluster Galera (PXC) de 3 nœuds par application, soit 3 clusters en prod (le site principal, un second site WordPress et Keycloak), plus un cluster partagé pour dev et staging. En septembre, je l’ai sortie vers du MySQL managé Scaleway. Voici pourquoi, comment, et ce que ça a changé.

Ce que PXC coûtait en ressources

En prod, PXC réservait 9 CPU, 18 Gi de mémoire et 186 Go de volumes block. Les données réelles tenaient en moins de 0,6 Go au total. Les datadirs faisaient 5 à 7 Go, remplis surtout par le cache Galera.

Les problèmes d’exploitation

C’est ce qui a décidé la sortie, plus que le prix.

• Les certificats. L’opérateur génère des certificats TLS valables environ 90 jours, et leur renouvellement automatique n’est pas fiable. En août, ceux du cluster principal avaient expiré depuis trois semaines. Un pod crashloopait, les deux autres tenaient sur une session TLS ouverte avant l’expiration, donc wsrep_cluster_size affichait 2 et tout avait l’air normal. Un redémarrage de plus et le cluster était perdu. Le correctif imposait un nouveau CA, donc un redémarrage coordonné de tous les nœuds : 1 à 2 minutes sans écriture, sans option sans coupure.
• La mémoire. Des pods tués en OOM pendant les imports, et des limits remontées jusqu’à 3 Gi.
• Le placement. Un bloc d’affinité « advanced » désactivait silencieusement l’anti-affinité sur le hostname et mettait tous les nœuds dans la même zone. Comme les volumes block sont zonaux, on ne corrige pas ça après coup sans laisser un pod en Pending.
• Le pool fr-par-3. Galera veut un pod par zone pour garder le quorum, donc il fallait un pool de nodes dans chacune des trois zones, y compris la plus chère.
• L’opérateur lui-même. De la dérive Terraform sur les secrets qu’il gère, et un namespace bloqué en Terminating par des Jobs de backup qui portaient encore son finalizer après la suppression du CR.

La cible

Une instance DB-GP-XS en HA (primaire + standby), MySQL 8, 50 Go de volume, un endpoint privé sur le VPC et aucune IP publique. Les backups sont quotidiens, conservés 7 jours et copiés dans une autre région. Une base par application et par environnement.

La migration

Elle s’est faite en une semaine, en dump/import logique, sans réplication. Un Job Kubernetes dans le namespace de l’application lance mysqldump --single-transaction en streaming vers mysql. La base cible est vidée avant l’import, les DEFINER sont retirés parce que l’utilisateur du managé n’a pas le privilège SUPER, puis les deux côtés sont comparés par comptage des tables et des lignes. La bascule passe par un flag Terraform par application : l’ancien cluster restait intact, donc revenir en arrière consistait à remettre le flag.

En prod, une base par apply, jamais en lot. Keycloak d’abord, en rolling update, sans coupure. Le second site ensuite, sans mode maintenance parce qu’il était calme. Le site principal en dernier : 5 minutes de mode maintenance, 141 tables sur 141 identiques, aucune ligne perdue.

Les pièges

• le mode maintenance de WordPress est un fichier par pod : il faut l’activer sur chaque pod, et un pod créé après coup n’est pas en maintenance ;
• il renvoie un 503 avec Retry-After en no-store, donc le CDN ne le met pas en cache, c’est ce qu’on veut ;
• WP-CLI et wp-cron l’ignorent, il faut suspendre le CronJob ;
• l’image WordPress embarque le client MariaDB et PXC le client Oracle, et leurs options SSL ne s’écrivent pas pareil ;
• avant de supprimer PXC, j’ai gardé un dump final de chaque base dans un préfixe S3 hors lifecycle.

Coûts

PXC n’avait pas de ligne de facture à lui, ses pods tournaient sur les nodes partagés. Sa réservation représentait l’équivalent d’environ deux nodes POP2-HC-8C-16G, soit ~310 €/mois de compute, plus 216 Go de volumes. L’instance managée en HA coûte ~200 €/mois. Ces deux chiffres sont des estimations, pas des factures.

Le gain chiffré, c’est le pool fr-par-3 qu’on a pu supprimer une fois PXC parti : un node POP2-4C-16G y coûte 161 €/mois, contre 107 € dans les deux autres zones. J’en parle dans l’article sur les performances de ce WordPress.

Latence et stabilité

Je n’ai pas mesuré de gain de latence, faute de mesure propre avant la bascule. Aux tests de charge sur le managé, la base n’a jamais été le facteur limitant : environ 12 threads actifs et 200 connexions au pic, pendant que le CPU des pods PHP saturait.

Le vrai gain est ailleurs : plus de certificats Galera à surveiller, plus d’OOM côté base, et des drains de nodes sans pods à états à replacer en gardant le quorum.

Mon avis

Faire tourner une base dans Kubernetes, c’est possible, mais il faut quelqu’un pour l’opérer. Pour moins d’un Go de données, un cluster Galera de 3 nœuds par application, c’est beaucoup de pièces mobiles pour pas grand-chose. Si ta base est petite et que personne n’a envie de surveiller des certificats Galera, le managé est le choix raisonnable.

Tu te poses la question pour ta propre base ? C’est le genre de sujet que je regarde pendant un audit de cluster Kubernetes.