🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Migración de WordPress a Kubernetes: Guía 2025

Actualizado el 15 de diciembre de 2025

Introducción: ¿Por qué Kubernetes para WordPress en 2025?

La infraestructura tradicional de WordPress, basada en un servidor LAMP/LEMP único o en un par de servidores con balanceo de carga, se ha quedado obsoleta para muchos escenarios. La necesidad de alta disponibilidad WordPress, la capacidad de manejar picos de tráfico sin intervención manual y la búsqueda de una gestión más eficiente de los recursos han llevado a las empresas a explorar la orquestación contenedores WordPress.

Kubernetes (K8s) se ha consolidado como el estándar de facto para la orquestación de contenedores. Migrar WordPress Kubernetes no es un simple cambio de hosting; es una transformación arquitectónica. En esta guía de 2025, desglosaremos el proceso, los desafíos y las mejores prácticas para realizar esta migración con éxito.

## Análisis Previo: ¿Es Kubernetes la Solución Correcta?

Antes de lanzarse a la migración, es crucial evaluar si el esfuerzo vale la pena. K8s WordPress aporta enormes beneficios, pero también introduce una complejidad operativa significativa.

### Beneficios Clave de la Migración

  • Escalado WordPress Automático: Kubernetes puede escalar horizontalmente los pods de WordPress (los contenedores que ejecutan PHP y un servidor web) basándose en métricas de CPU, memoria o peticiones HTTP. Durante un pico de tráfico, se crean nuevas réplicas automáticamente.
  • Alta Disponibilidad WordPress: Si un pod falla, Kubernetes lo reinicia o lo reemplaza inmediatamente. Al distribuir los pods entre varios nodos (máquinas físicas o virtuales), se garantiza que no haya un único punto de fallo.
  • Actualizaciones sin Tiempo de Inactividad (Rolling Updates): Puedes actualizar la imagen de WordPress (plugins, temas o el core) o la configuración del servidor web sin interrumpir el servicio. K8s reemplaza los pods gradualmente.
  • Gestión de Configuración Centralizada: Variables de entorno, configuraciones de PHP (php.ini) y archivos como wp-config.php se gestionan mediante ConfigMaps y Secrets, evitando configuraciones inconsistentes entre entornos.

### Desafíos a Considerar

  • Persistencia de Datos: WordPress es una aplicación con estado. La base de datos (MySQL/MariaDB) y los archivos multimedia (uploads) deben gestionarse cuidadosamente con volúmenes persistentes (PersistentVolumeClaims).
  • Complejidad Operativa: Necesitas un equipo con conocimientos de Kubernetes, Helm (gestor de paquetes para K8s) y monitorización de clústeres.
  • Coste de Infraestructura: Un clúster gestionado (EKS, AKS, GKE) tiene un coste base, aunque a largo plazo suele ser más eficiente que servidores sobredimensionados.

[WARNING] No migres un blog personal con 100 visitas al día a Kubernetes. La complejidad no se justifica. Esta solución es para sitios con alto tráfico, picos predecibles o necesidades de compliance estrictas.

## Preparación del Entorno: Herramientas y Configuración Inicial

Para comenzar, necesitas un clúster de Kubernetes. Las opciones más populares en 2025 son los servicios gestionados en la nube: Amazon EKS, Google GKE o Azure AKS. Para este tutorial, asumiremos un clúster genérico.

### Prerrequisitos Técnicos

  1. kubectl: Cliente de línea de comandos para interactuar con el clúster.
  2. Helm v3: Para desplegar paquetes complejos como el chart de WordPress.
  3. Un registro de contenedores: Docker Hub, Amazon ECR, Google Container Registry, etc., para almacenar las imágenes personalizadas.
  4. Almacenamiento Persistente: Un StorageClass configurado en tu clúster (por ejemplo, gp2 en AWS, standard en GKE).

### Estrategia de Imágenes de Contenedor

No uses la imagen oficial de WordPress directamente para producción. Es mejor construir una imagen personalizada.

# Dockerfile para WordPress personalizado
FROM wordpress:6.7-php8.3-apache

# Instalar extensiones PHP necesarias
RUN docker-php-ext-install pdo_mysql mysqli

# Copiar configuración personalizada de PHP
COPY config/php.ini /usr/local/etc/php/conf.d/custom.ini

# Copiar plugins y temas (o gestionarlos vía volumen)
COPY plugins/ /var/www/html/wp-content/plugins/
COPY themes/ /var/www/html/wp-content/themes/

[TIP] Construye esta imagen y súbela a tu registro privado. Así te aseguras de que todas las réplicas tengan exactamente la misma configuración.

## Despliegue de la Base de Datos: El Talón de Aquiles

La base de datos (MySQL o MariaDB) es el componente más crítico y difícil de gestionar en K8s WordPress. Kubernetes no está diseñado para bases de datos con estado de la misma manera que para aplicaciones sin estado.

### Opción 1: Base de Datos Externa (Recomendada)

Es la opción más sensata para producción. Usa un servicio gestionado como Amazon RDS, Google Cloud SQL o Azure Database for MySQL. Tu clúster se conectará a él mediante una IP privada.

Ventajas: Backups automáticos, alta disponibilidad nativa, escalado vertical sencillo.
Desventajas: Dependencia de un servicio externo, latencia de red (mínima si está en la misma VPC).

# Secret para conectar a RDS (ejemplo)
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:
  WORDPRESS_DB_HOST: "wordpress-db.cluster-xxxxx.us-east-1.rds.amazonaws.com"
  WORDPRESS_DB_USER: "wp_user"
  WORDPRESS_DB_PASSWORD: "strong_password"
  WORDPRESS_DB_NAME: "wordpress_db"

### Opción 2: StatefulSet y Operadores

Si debes tener la base de datos dentro del clúster (por ejemplo, en un entorno on-premise), usa un StatefulSet. Herramientas como el MySQL Operator o KubeDB automatizan la creación de réplicas, backups y failover.

# Fragmento de un StatefulSet para MariaDB (simplificado)
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mariadb
spec:
  serviceName: mariadb
  replicas: 3
  selector:
    matchLabels:
      app: mariadb
  template:
    metadata:
      labels:
        app: mariadb
    spec:
      containers:
      - name: mariadb
        image: mariadb:11.4
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: root-password
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 20Gi

[INFO] Un StatefulSet garantiza identidades de red estables (nombres de host predecibles) y almacenamiento persistente único para cada réplica. Es la forma correcta de desplegar bases de datos en K8s.

## Despliegue de WordPress: El Chart de Helm

El método más eficiente y mantenible para desplegar WordPress Kubernetes es usar el chart oficial de Bitnami o uno personalizado. Helm abstrae toda la complejidad de los Deployments, Services, Ingress y PersistentVolumeClaims.

### Instalación con Helm

# Añadir el repositorio de Bitnami
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Crear un archivo values-custom.yaml para personalizar el despliegue
# (ver ejemplo abajo)

# Instalar el chart
helm install wordpress-prod bitnami/wordpress \
  --namespace wordpress \
  --create-namespace \
  -f values-custom.yaml

### Archivo values-custom.yaml (Ejemplo)

# Configuración personalizada para el chart de WordPress
wordpressUsername: admin
wordpressPassword: "my-secure-password"
wordpressEmail: admin@example.com
wordpressFirstName: Admin
wordpressLastName: User
wordpressBlogName: "Mi Blog en K8s"

# Usar base de datos externa (RDS)
externalDatabase:
  host: "wordpress-db.cluster-xxxxx.us-east-1.rds.amazonaws.com"
  user: "wp_user"
  password: "strong_password"
  database: "wordpress_db"
  port: 3306

# Configurar recursos
resources:
  requests:
    memory: 256Mi
    cpu: 250m
  limits:
    memory: 512Mi
    cpu: 500m

# Habilitar autoescalado
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

# Almacenamiento persistente para uploads
persistence:
  enabled: true
  storageClass: "gp2"  # Ajustar según tu nube
  size: 10Gi
  accessModes:
    - ReadWriteOnce

# Configurar Ingress (para exponer el sitio)
ingress:
  enabled: true
  hostname: "www.mi-sitio.com"
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
  tls: true

## Gestión de Archivos Multimedia: El Desafío de la Persistencia

Los archivos subidos por los usuarios (imágenes, PDFs, etc.) deben ser accesibles por todos los pods. Usar un PersistentVolumeClaim con modo ReadWriteOnce (RWO) solo permite que un pod escriba a la vez. Para un escalado WordPress real, necesitas un almacenamiento compartido.

### Soluciones de Almacenamiento Compartido

  1. NFS / EFS (AWS): Un sistema de archivos de red (Network File System) que puede ser montado por múltiples pods en modo ReadWriteMany (RWX). Es la opción más sencilla.
  2. Object Storage (S3 / GCS) con Plugin: Usar un plugin como WP Offload Media o el Official Amazon S3 Offload para que WordPress guarde los archivos directamente en un bucket de S3. Esto elimina la necesidad de un volumen compartido y mejora la entrega de contenido.
  3. MinIO: Un servidor de almacenamiento de objetos compatible con S3, desplegado dentro del propio clúster. Ideal para entornos on-premise.

[TIP] La opción 2 (Object Storage) es la más escalable y recomendada para 2025. Configura el plugin para que reescriba las URLs de los archivos hacia el CDN de S3/CloudFront.

## Escalado Automático y Alta Disponibilidad

Una vez desplegado, el verdadero poder de K8s WordPress se manifiesta en su capacidad de reacción.

### Horizontal Pod Autoscaler (HPA)

El HPA ajusta el número de réplicas de WordPress en función de la carga. En el values-custom.yaml de arriba, ya lo hemos habilitado. Puedes verificarlo con:

kubectl get hpa -n wordpress
# Output esperado:
# NAME              REFERENCE                    TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
# wordpress-prod    Deployment/wordpress-prod    45%/70%   2         10        4          10m

### Cluster Autoscaler

El HPA escala los pods, pero si el clúster se queda sin recursos (nodos), los nuevos pods quedarán en estado Pending. El Cluster Autoscaler (disponible en EKS, GKE, AKS) añade nuevos nodos al clúster automáticamente.

### Health Checks (Liveness y Readiness Probes)

Kubernetes monitoriza la salud de los pods. Si un pod de WordPress deja de responder, se reinicia automáticamente.

# Fragmento del Deployment (gestionado por Helm)
livenessProbe:
  httpGet:
    path: /wp-admin/install.php  # Un endpoint que siempre debe responder
    port: http
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /wp-login.php
    port: http
  initialDelaySeconds: 5
  periodSeconds: 5

## Seguridad en K8s WordPress

La seguridad es un aspecto crítico. Un clúster mal configurado puede exponer tu sitio a ataques.

  • Secrets Management: Nunca pongas contraseñas en el código. Usa Secrets de Kubernetes o herramientas externas como HashiCorp Vault.
  • Network Policies: Aísla los pods. Por ejemplo, solo los pods de WordPress deben poder hablar con el pod de la base de datos.
  • Actualizaciones de Imagen: Escanea tus imágenes en busca de vulnerabilidades con herramientas como Trivy o Snyk. Actualiza regularmente la imagen base de WordPress.
  • Ingress Seguro: Usa TLS (cert-manager con Let's Encrypt) y considera un Web Application Firewall (WAF) como Cloudflare o AWS WAF delante del clúster.

## Monitorización y Logging

No puedes gestionar lo que no mides. Para un entorno de producción, necesitas un stack de observabilidad.

  • Métricas: Prometheus + Grafana. El chart de Bitnami incluye un exportador de métricas de WordPress (wp-exporter) que expone datos como el número de visitas, tiempo de carga, etc.
  • Logs: Loki (de Grafana Labs) o Elasticsearch + Fluentd + Kibana (EFK). Centraliza los logs de todos los pods para depurar errores.
  • Alertas: Configura alertas en Prometheus para cuando el número de pods esté cerca del máximo, el uso de CPU supere el 90% o haya errores 5xx en el Ingress.

## Migración Paso a Paso: De un Servidor a K8s

Finalmente, el proceso de migración real.

  1. Respaldar todo: Base de datos, archivos wp-content/, y wp-config.php.
  2. Preparar la imagen Docker: Como se mostró anteriormente, incluye los plugins y temas esenciales.
  3. Configurar la base de datos externa: Crea la instancia de RDS/Cloud SQL y restaura el backup.
  4. Desplegar con Helm: Usa el archivo values-custom.yaml apuntando a la base de datos externa.
  5. Sincronizar archivos: Copia los archivos de wp-content/uploads/ al almacenamiento persistente (NFS, EFS o S3).
  6. Configurar el plugin de almacenamiento: Si usas S3, instala y configura el plugin correspondiente.
  7. Probar el sitio: Cambia el archivo /etc/hosts de tu máquina local para apuntar al dominio de prueba del Ingress.
  8. Migrar el DNS: Cuando todo funcione, cambia los registros DNS de tu dominio para que apunten al Load Balancer de Kubernetes.

[WARNING] Durante la migración, el sitio puede estar en modo solo lectura o mostrar una página de mantenimiento. Planifica una ventana de mantenimiento corta.

## Conclusión: El Futuro es Orquestado

Migrar WordPress a Kubernetes en 2025 no es una moda, es una necesidad para aquellos que buscan alta disponibilidad WordPress y un escalado WordPress eficiente y automático. La complejidad inicial se ve recompensada con una plataforma robusta, auto-reparable y preparada para el futuro.

Si tu sitio recibe millones de visitas al mes o necesitas garantías de uptime del 99.99%, K8s es el camino. Empieza con un clúster pequeño, automatiza todo con Helm y CI/CD, y monitoriza cada métrica. El viaje es desafiante, pero el destino es una infraestructura de nivel empresarial para tu WordPress.

![Equipo de DevOps trabajando en la

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel