El error de actualizar Docker y Kubernetes a la vez

El error que más caídas provoca en un WordPress contenerizado no suele estar en el core ni en un plugin: ocurre al actualizar la imagen, Docker, Kubernetes y los nodos como si fueran un único cambio. Una alerta de seguridad puede exigir rapidez, pero reiniciar sin aislar capas convierte una corrección necesaria en un riesgo de indisponibilidad, datos inconsistentes o un rollback imposible.

Las actualizaciones en entornos Docker/Kubernetes exigen separar la imagen de WordPress, Compose, el runtime, el clúster y los nodos. Con inventario, staging, copias restaurables, etiquetas inmutables, probes y un rollback probado, puedes desplegar sin downtime.

Separa las capas antes de cambiar nada

Divide la actualización y reduce el alcance del fallo.

Un WordPress en contenedores incluye más que WordPress Core. Puede incluir PHP, Nginx, plugins, temas, MySQL o MariaDB, Redis, volúmenes persistentes y un ingress, que es la puerta que recibe visitas desde internet. Actualizar PHP puede romper un plugin aunque el núcleo de WordPress siga intacto.

El error más frecuente es actualizar el clúster y WordPress en la misma ventana de cambio. Si después fallan los pedidos de WooCommerce, no queda una causa clara que revisar.

Ordena las cinco capas de cambio

Actualiza primero lo más cercano a WordPress y deja los nodos para otra ventana.

1. Aplicación e imagen: WordPress, PHP, plugins, temas y dependencias dentro de la imagen.
2. Definición: archivo docker-compose.yml, manifiestos YAML o valores de Helm.
3. Despliegue: contenedores, pods y réplicas que ejecutan la nueva imagen.
4. Runtime y orquestador: Docker Engine, containerd, Kubernetes o K3s.
5. Nodos: sistema operativo, kernel y paquetes de cada servidor.

Una actualización de imagen tarda entre 10 y 30 minutos si staging ya está preparado. Una actualización de nodos puede requerir entre 30 y 90 minutos por nodo, porque exige drenarlo sin dejar servicios sin capacidad.

Distingue reiniciar de actualizar

Usa un reinicio solo para recrear procesos, no para corregir versiones vulnerables.

Documenta versiones y prueba la restauración

Registra la versión exacta y valida una copia restaurada antes de tocar producción.

Fija imágenes que puedas reconocer

Guarda el digest de cada imagen aprobada en Git y en el registro del cambio.

Un digest comienza normalmente por sha256: y actúa como la huella dactilar del archivo. Dos tags pueden apuntar a contenidos distintos; un digest siempre señala el mismo contenido mientras exista en el registro.

YAML services: wordpress: image: registry.ejemplo.es/wordpress@sha256:REEMPLAZA_POR_EL_DIGEST_APROBADO

Restaura staging antes de autorizar

Restaura en staging los datos y secretos necesarios para arrancar el sitio.

La copia debe contener base de datos MySQL o MariaDB, ficheros subidos, volúmenes persistentes, configuración de WordPress y secretos recuperables. Si faltan las claves de autenticación o la contraseña de la base de datos, el contenedor puede arrancar, pero WordPress no funcionará.

Elige rolling, blue-green o canary

Escoge la estrategia según tus réplicas, sesiones y cambios de base de datos.

Define el momento de abortar

Fija umbrales de error, latencia y salud antes de iniciar el rollout.

Aborta si los errores HTTP 5xx superan el nivel habitual durante entre 3 y 5 minutos, si el tiempo de respuesta se duplica de forma sostenida o si fallan checkout, login o formularios. Consulta logs de PHP-FPM, Nginx, WordPress y eventos de Kubernetes durante todo el cambio.

Despliega una capa y valida el resultado

Aplica el cambio de aplicación por separado y comprueba lo que está ejecutándose.

Cambia compose con trazabilidad

Valida el archivo antes de descargar una sola imagen.

bash docker compose config docker compose pull wordpress docker compose up -d --no-deps wordpress docker compose ps docker compose logs --tail=100 wordpress

El primer comando detecta variables ausentes y errores de sintaxis. Después, compara el digest descargado con el aprobado, abre el sitio y revisa que las conexiones con la base de datos, Redis y Nginx siguen activas. Este proceso suele tardar entre 10 y 20 minutos si no hay migraciones.

Despliega Kubernetes con control

Compara el manifiesto y espera al rollout antes de cerrar la ventana.

Después, comprueba kubectl rollout status deployment/wordpress, kubectl get pods y kubectl describe pod cuando haya reinicios. kubectl rollout undo solo sirve si la revisión anterior sigue disponible y la base de datos acepta volver a la versión anterior.

Programa Docker Engine, containerd, kubelet, Kubernetes y el sistema operativo en otra ventana. Antes de actualizar un nodo, usa kubectl cordon y kubectl drain, revisando réplicas, volúmenes y PodDisruptionBudgets, que limitan cuántos pods pueden parar a la vez.

El Ingress y HTTPS también forman parte de la validación posterior al rollout, porque un pod sano no garantiza que los visitantes puedan acceder al sitio. Comprueba que el recurso Ingress mantiene el host correcto, la ruta hacia el servicio de WordPress y la clase de controlador esperada, como NGINX Ingress o Traefik. Valida el certificado TLS, su fecha de caducidad y la cadena de confianza desde fuera del clúster, además de probar la redirección de HTTP a HTTPS.

Si empleas cert-manager, revisa los recursos Certificate y Challenge antes de cambiar anotaciones o dominios. Una prueba funcional debe incluir la URL pública, el login, una página sin caché y, si existe, el checkout.

Dudas habituales

Comprueba estas respuestas antes de abrir una ventana de cambio.

¿Puedo usar latest en WordPress docker?

No conviene usar latest en producción porque no identifica una versión concreta. Usa un tag versionado o digest SHA256 y registra la referencia anterior para revertirla.

¿Kubectl rollout restart actualiza WordPress?

No, kubectl rollout restart solo recrea pods con la imagen definida actualmente. Debes cambiar el campo image a un digest o versión nueva para corregir una vulnerabilidad.

¿Qué debe incluir un backup de WordPress?

La copia debe incluir base de datos, ficheros subidos, volúmenes persistentes y configuración recuperable. Prueba una restauración en staging entre 30 y 60 minutos antes de autorizar producción.

¿Cuándo sirve un rolling update?

Un rolling update sirve con dos o más réplicas y datos compartidos fuera de los pods. No basta si una migración de base de datos no permite volver atrás.

¿Cómo sé si debo abortar el despliegue?

Debes abortar si aumentan los errores 5xx, falla el checkout o las readiness probes no quedan sanas. Define el umbral antes del cambio y revierte con la referencia de imagen ya registrada.

¿Puedo guardar secretos en docker-compose.yml?

No debes guardar contraseñas o tokens en docker-compose.yml ni en Git. Usa Docker Secrets, Secrets de Kubernetes o un gestor de secretos con acceso limitado.

¿Cuándo actualizo los nodos de Kubernetes?

Actualiza los nodos en una ventana distinta a la de WordPress y sus plugins. Drena cada nodo, valida la capacidad restante y actualiza uno cada vez si el clúster tiene pocas réplicas.

Cierra el cambio con evidencia verificable

Documenta el resultado y conserva la ruta de reversión.

Guarda el digest desplegado, hora del cambio, resultado de probes, capturas de alertas y pruebas funcionales. Ese registro convierte la siguiente actualización en un proceso repetible.

• Un rollback puede borrar pedidos posteriores al snapshot
• Actualiza WooCommerce sin perder ventas ni datos

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.