RousselTMLEARNING

TP · DevOps: del descubrimiento a la experiencia

Práctica: Rolling update, canary y vuelta atrás en Kubernetes

Lo que vas a aprender en este TP
  • Configurar un rolling update seguro
  • Hacer un despliegue canary
  • Volver atrás con kubectl

Introducción #

Lo que vas a aprender en esta sección
  • Configurar un rolling update seguro
  • Hacer un despliegue canary
  • Volver atrás con kubectl

Contexto. El equipo migra a Kubernetes y quiere despliegues progresivos. Validas en un clúster local el comportamiento de las actualizaciones y vueltas atrás.

Requisitos previos: Docker, kubectl y kind instalados en tu equipo  ·  Duración estimada: 50 min

Despliegues progresivos controlados y una vuelta atrás en un comando.

Puesta en práctica #

Pasos guiados, con su corrección.

  1. 1. Crear el clúster y desplegar la v1

    ¿Por qué? maxUnavailable: 0 y una readiness probe garantizan que ninguna petición llegue a un pod no listo.

    Crea un clúster kind y despliega 4 réplicas de hashicorp/http-echo que muestren «v1», con una estrategia RollingUpdate prudente y una readiness probe, expuestas por un Service.
  2. 2. Rolling update sin interrupción

    ¿Por qué? Se observa el reemplazo de los pods uno a uno mientras el tráfico continúa.

    Lanza un bucle de peticiones desde el pod client y pasa a v2 con una anotación de causa. Sigue el despliegue y el historial.
  3. 3. Bloquear una versión rota

    ¿Por qué? Una imagen inexistente o un pod que nunca está listo detiene el rolling update: los pods antiguos siguen sirviendo.

    Despliega una imagen inexistente, comprueba que rollout status falla tras un tiempo y que el servicio sigue respondiendo v2.
  4. 4. Volver atrás

    ¿Por qué? Kubernetes conserva los ReplicaSets anteriores: la vuelta atrás es inmediata.

    Deshaz la última revisión, comprueba que todos los pods están listos y vuelve explícitamente a la revisión 1.
  5. 5. Despliegue canary

    ¿Por qué? Sin service mesh, un canary se aproxima repartiendo las réplicas detrás del mismo Service.

    Crea un Deployment web-canary (1 réplica, texto «v3-canary», etiqueta track: canary) que comparta la etiqueta app: web. Mide su parte del tráfico y después promueve o elimina el canary.

Nivel de dificultad : ●●●○○ (3/5)

Mi seguimiento

  • ⏱ Duración estimada : ≈ 50 min

Inicia sesión para seguir tu progreso y tomar notas. Iniciar sesión

✉️ Hacer una pregunta

Artículos recomendados

CI/CD de bout en bout (4/5) : stratégies de déploiement et retour arrière

Déployer sans interruption et sans risque : recreate, rolling update, blue/green, canary, feature...