Kubernetes se convirtió en el estándar de facto para orquestación de contenedores en entornos de producción a escala. Aplicarlo a WordPress puede parecer un overkill para la mayoría de los sitios, pero para instalaciones de alto tráfico con miles de visitas concurrentes, la combinación de WordPress + Kubernetes ofrece escalabilidad horizontal casi ilimitada y resiliencia ante fallos que ninguna solución de servidor único puede igualar.

¿Por qué WordPress y Kubernetes?

WordPress fue diseñado como aplicación en un único servidor. Su arquitectura clásica asume que todos los archivos de plugins, temas y subidas están en el mismo sistema de archivos que el PHP. Esta asunción es incompatible con Kubernetes, donde múltiples réplicas de un pod corren en servidores distintos y no comparten sistema de archivos.

Superar esta limitación requiere modificar la arquitectura: los archivos de subidas (wp-content/uploads) deben ir a almacenamiento compartido (S3, GCS o NFS), la base de datos debe ser externa al cluster (RDS, Cloud SQL), la caché de objetos debe ser un servicio separado (Redis) y las sesiones de usuario deben almacenarse en la base de datos o en Redis en lugar de en archivos locales.

Componentes de una instalación WordPress en Kubernetes

• Deployment de PHP-FPM: Los pods de WordPress corriendo PHP-FPM, con imagen Docker inmutable y configuración via ConfigMaps/Secrets.
• Nginx como Ingress: Un Ingress Controller (Nginx, Traefik) que distribuye el tráfico entre las réplicas de WordPress.
• MySQL/MariaDB externo: Base de datos como servicio gestionado fuera del cluster para persistencia y backup.
• Redis para caché de objetos: Desplegado como StatefulSet dentro del cluster o como servicio gestionado externo.
• Persistent Volume para uploads:
• Horizontal Pod Autoscaler:

Horizontal Pod Autoscaler: escalar según la demanda

El Horizontal Pod Autoscaler (HPA) de Kubernetes aumenta automáticamente el número de réplicas del Deployment de WordPress cuando la CPU o memoria superan los umbrales definidos. Para sitios con tráfico variable (campañas de marketing, links virales, cobertura de noticias), este mecanismo garantiza que el sitio absorba picos de tráfico sin configuración manual.

Combinado con el cluster autoscaler (que agrega nodos al cluster cuando los pods no caben en los nodos existentes), se puede configurar un sistema que escala desde 2 réplicas en tráfico normal hasta 50 o más en picos, y vuelve a escalar hacia abajo automáticamente.

¿Cuándo tiene sentido este nivel de complejidad?

Kubernetes para WordPress tiene sentido cuando el tráfico es suficientemente alto y variable como para que la escalabilidad automática justifique el overhead operativo, cuando el equipo tiene experiencia con Kubernetes y la curva de aprendizaje ya está superada, y cuando el costo de downtime es lo suficientemente alto como para justificar la infraestructura de alta disponibilidad.

Para la mayoría de los proyectos, un hosting gestionado de calidad es más eficiente. Pero si tu WordPress recibe millones de visitas mensuales y el crecimiento es predecible, vale la pena la conversación. En Octopus Agencia Digital evaluamos cada caso antes de recomendar una arquitectura. Hablemos.