« On veut passer notre site WordPress sur Kubernetes » revient régulièrement dans les discussions avec des clients qui ont entendu parler de scalabilité automatique et de haute disponibilité, sans toujours mesurer ce que WordPress, par nature, rend compliqué dans ce genre d’architecture. La question n’est pas de savoir si c’est possible — cela l’est, de nombreuses entreprises le font — mais si le gain justifie la complexité ajoutée, sur un projet donné, à un moment donné.
Ce chapitre n’explique pas comment installer WordPress sur Kubernetes pas à pas, mais aide à répondre à la question qui devrait précéder toute mise en œuvre : est-ce que ce projet en a vraiment besoin ?
Ce que Kubernetes attend d’une application : l’absence d’état
Kubernetes excelle à faire tourner des applications sans état (stateless) : des conteneurs interchangeables, qu’on peut détruire et recréer à volonté sans perte, parce qu’aucune donnée importante n’y réside localement. Le problème, c’est que WordPress, dans sa configuration par défaut, n’est pas sans état du tout : les fichiers médias uploadés atterrissent dans wp-content/uploads, sur le disque du conteneur, et les sessions PHP par défaut sont stockées localement sur le système de fichiers du serveur qui a traité la requête.
Trois dépendances à externaliser avant même de penser à Kubernetes
La base de données
C’est la dépendance la plus évidente et la plus souvent déjà externalisée, même hors Kubernetes : une base MySQL ou MariaDB managée, séparée des conteneurs applicatifs, à laquelle chaque pod WordPress se connecte comme n’importe quel client distant.
Les médias
Sans intervention, chaque pod WordPress qui redémarre ou se multiplie perd ou duplique de façon incohérente les fichiers médias stockés localement. La solution standard consiste à stocker les médias sur un stockage objet compatible S3 (ou un volume réseau partagé de type NFS), via une extension qui réécrit les URL de médias pour pointer vers ce stockage externe plutôt que vers le système de fichiers local.
Les sessions et le cache
Les sessions PHP et le cache objet doivent être déplacés vers un service partagé entre tous les pods — typiquement Redis — pour qu’un utilisateur ne perde pas sa session de connexion selon le pod qui traite sa requête suivante.
Ce que Kubernetes apporte réellement une fois ces dépendances externalisées
Une fois ces trois obstacles levés, Kubernetes apporte des mécanismes que peu d’architectures WordPress traditionnelles offrent nativement : mise à l’échelle automatique du nombre de pods selon la charge (Horizontal Pod Autoscaler), redémarrage automatique d’un pod en erreur sans intervention humaine, et déploiements progressifs qui limitent l’exposition d’une version défectueuse à une fraction du trafic seulement.
Le seuil de pertinence : les pics, pas la moyenne
Le critère qui distingue un projet où Kubernetes se justifie d’un projet où il ajoute de la complexité sans bénéfice réel n’est pas le trafic moyen, mais la variabilité de ce trafic. Un site avec un trafic stable, même élevé, se gère très bien avec deux ou trois serveurs classiques et un équilibreur de charge simple. Un site qui subit des pics ponctuels et imprévisibles — une opération commerciale relayée massivement, une actualité qui multiplie le trafic par dix en quelques minutes — tire un bénéfice réel de la capacité de Kubernetes à ajouter et retirer des pods automatiquement selon la demande.
| Situation | Kubernetes pertinent ? |
|---|---|
| Trafic stable, même élevé, sans pic marqué | Rarement nécessaire |
| Pics ponctuels et imprévisibles importants | Vrai bénéfice |
| Équipe sans compétence Kubernetes en interne | Coût opérationnel à anticiper |
| Un seul site, sans mutualisation d’infrastructure | Complexité rarement justifiée seule |
Le coût caché : l’expertise opérationnelle
Au-delà de la complexité technique de migration, Kubernetes exige une expertise opérationnelle continue : comprendre les manifestes, déboguer un pod qui redémarre en boucle, gérer les certificats et l’ingress, surveiller les ressources allouées. Une équipe qui n’a pas cette expertise en interne, ou qui ne la maintient pas dans la durée, se retrouve à dépendre fortement d’un prestataire externe pour la moindre intervention, ce qui peut annuler une partie du bénéfice recherché en autonomie.
Nous ne recommandons jamais Kubernetes à un client qui gère un seul site WordPress, aussi gros soit-il. Le calcul devient différent pour une plateforme qui héberge des dizaines de sites mutualisés sur la même infrastructure, où le coût d’apprentissage se répartit sur beaucoup plus de projets.
En résumé
Kubernetes n’est ni une solution miracle ni une complexité inutile en soi pour WordPress : c’est un outil dont la pertinence dépend directement de la variabilité du trafic à absorber et du nombre de projets sur lesquels répartir le coût opérationnel d’apprentissage. Avant d’envisager la migration, la vraie question à se poser reste presque toujours plus simple : est-ce que les médias, les sessions et le cache sont déjà externalisés, et le trafic connaît-il des pics que l’infrastructure actuelle peine à absorber ?
