Challenge ·Easy

Recupera un Deployment con un rollback

Javier Vela
by  Javier Vela · on
Kubernetes
Alguien desplegó la versión 2 de la tienda y el rollout lleva media hora atascado: la nueva imagen no existe en el registro. El servicio aguanta a medias con los Pods antiguos. Diagnostica el rollout, recupera el Deployment con un rollback y deja las 3 réplicas disponibles. El procedimiento de emergencia más valioso que existe en Kubernetes.
#kubernetes-101#deployments#rollback

Son las 9:00 y el canal de incidencias arde: la tienda va lenta desde que anoche alguien desplegó "la versión 2". Nadie sabe muy bien qué se desplegó, solo que el despliegue "no terminó nunca". Te toca a ti.

Empieza por evaluar los daños desde la pestaña dev-machine:

kubectl get deployment tienda

kubectl get pods -l app=tienda

kubectl rollout status deployment/tienda

Observa el detalle interesante: hay Pods viejos que siguen sirviendo tráfico y Pods nuevos que no arrancan. Es la estrategia RollingUpdate del Deployment protegiendo el servicio: no mata lo viejo hasta que lo nuevo está listo. Por eso la tienda "va lenta" pero no está caída.

Tu misión tiene dos partes: averiguar por qué la versión 2 no arranca, y devolver el Deployment a un estado correcto con sus 3 réplicas disponibles. La forma profesional de hacerlo no es editar a mano, sino usar el mecanismo de rollback que el propio Deployment ofrece.

Pista 1

Los Pods nuevos están en ImagePullBackOff: kubectl describe sobre uno de ellos te dirá qué imagen intenta descargar. Compárala con la que usan los Pods viejos que sí funcionan.

Pista 2

Cada cambio en la plantilla de un Deployment genera una revisión numerada. El subcomando rollout de kubectl sabe listar ese historial y también deshacer el último cambio. Explora kubectl rollout --help.

Por qué importa

En producción, la velocidad de recuperación importa más que la elegancia del diagnóstico. Un rollout undo bien ejecutado devuelve el servicio a su último estado bueno en segundos, y te compra el tiempo para investigar con calma qué pasó con la versión 2. Este reflejo (detectar rollout atascado, deshacer, investigar después) es de lo más valioso que te llevas de este curso.

How to Author Challenges on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull challenge content

labctl content pull challenge recupera-un-deployment-con-rollback-db76fff5

This will create a local copy of the challenge content in a directory named recupera-un-deployment-con-rollback-db76fff5. You only need to do this once per challenge.

Stream your changes

labctl content push -fw challenge recupera-un-deployment-con-rollback-db76fff5

Run this command in a separate terminal to continuously upload your changes to the server while editing the challenge in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help

Start challenge