Deployment Rolling Update y Rollback en Kubernetes

Después de ver en la entrada anterior sobre kubernetes de generar de manera declarativa los diferentes objetos, vamos a ver como podemos hacer un Deployment Rolling Update y Rollback en Kubernetes. Este ejemplo práctico mostrará como podemos volver a la versión anterior de un deployment.

A continuación vamos a crear diferentes versiones de un deployment, haciendo uso de una imagen de mynginx, y vamos a ver como ver su historial de despliegues y como podemos volver hacia la versión anterior.

Para centrarnos en la idea de update y rollback, vamos a hacer el ejemplo de manera empírica.

1. Crear Deployment

Para empezar vamos a crear un Deployment con una imagen de nginx, en lugar de usarlo a través de fichero .YAML, vamos a utilizar Kubectl para crearlo:

kubectl create deployment mynginx --image=nginx:1.15-alpine

Una vez creado vamos a ver los deployment, las replica set y los pods creados, para nginx.

 kubectl get deploy,rs,po -l app=mynginx

Como se puede ver estamos haciendo uso de la etiqueta app=mynginx, con esto evitamos que nos muestre todos los pods, replicaset y deployments y únicamente nos muestre aquellos que tienen esta etiqueta.

2. Escalar el deployment a 3 réplicas

A continuación el deployment realizado anteriormente, vamos a escalarlo a 3 réplicas.

kubectl scale deploy mynginx --replicas=3

y volvemos a listar el los deployment, replicaSet y los Pods:

 kubectl get deploy,rs,po -l app=mynginx

Tras ejecutar la línea de comando anterior vemos como el número de Pods ha aumentado a 3.

Nota: Vamos a guardar el nombre del ReplicaSet para después en nuestro caso es, replicaset.apps/mynginx-76bcb97766

Ahora vamos a asegurarnos de la versión de nginx que hemos desplegado, para ello podemos utilizar el siguiente comando:

kubectl describe deployment

Al desplegar este comando podréis ver algo así:

Name:                   mynginx
Namespace:              default
CreationTimestamp:      Sun, 24 May 2020 17:48:27 +0200
Labels:                 app=mynginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=mynginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=mynginx
  Containers:
   nginx:
    Image:        nginx:1.15-alpine

Y en efecto la imagen previamente desplegada es la 1.15

3. Rollout en Kubernetes

En este punto vamos a ver un rolling update a una versión superior de nginx, sin necesidad de borrar o eliminar el anterior deployment.

Para empezar vamos a ver rollout history, para ello vamos a usar el siguiente comando:

kubectl rollout history deploy mynginx

Podemos ver como por ahora solo hay una Revision:

Podemos ver como hay una revisión, que coincide con lo que aparece en el campo annotations del comando describe del punto anterior.

Ahora vamos a ver los detalles de esta Revision, para ello ejecutamos el siguiente comando:

kubectl rollout history deploy mynginx --revision=1

Y obtendremos algo como lo siguiente

deployment.apps/mynginx with revision #1
 Pod Template:
   Labels:    app=mynginx
     pod-template-hash=76bcb97766
   Containers:
    nginx:
     Image:    nginx:1.15-alpine
     Port:    
     Host Port:    
     Environment:    
     Mounts:    
   Volumes:    

Como podemos observar, volvemos a ver la imágen 1.15, a continuación vamos a realizar una actualización de esta imagen, para ellos introducimos el siguiente comando:

kubectl set image deployment mynginx nginx=nginx:1.16-alpine

Ahora si volvemos a mirar el historial, tendremos 2 Revision, la primera que es la original y la segunda que es la que acabamos de crear.

Si miramos otra vez, los deployment, los pods, y los ReplicaSet con el siguiente comando:

kubectl get deploy,rs,po -l app=mynginx

Veremos, como la el objeto ReplicaSet origina ha sido escalado a 0, en nuestro caso corresponde al nombre, replicaset.apps/mynginx-76bcb97766, y se ha creado un nuevo.

Esa Replicaset que ha sido escalada a 0, mantiene guardado el registro del original deployment.

Este nuevo Replicaset esta asociado a la Version 2, que vimos anteriormente.

4. Rollback en Kubernetes

Después de realizar la actualización anterior, hemos visto que no la deberíamos de haber realizado, por lo que queremos volver a la Version 1 de nuestro Deployment, por lo que vamos a introducir el siguiente comando:

kubectl rollout undo deployment mynginx --to-revision=1

Ahora vamos a ver de nuevo el historial y veremos que ahora la Version 1 ha desaparecido y tenemos una nueva la 3, esto es porque la 1 se asocia ahora a la 3. Es decir, se crea una nueva versión que se podría decir que un clon de la 1. Y por supuesto, la Version 2, esta asociada a la versión 1.16 de nginx.

Si volvemos de nuevo a ejecutar el siguiente comando:

kubectl get deploy,rs,po -l app=mynginx

Veremos que la Replicaset inicial vuelve a estar levantada (replicaset.apps/mynginx-76bcb97766) , y la creada con la versión 2 se encuentra a 0.

Conclusión.

En esta entrada hemos visto como hacer mediante un ejemplo un Deployment Rolling Update y Rollback en Kubernetes, y como podemos ir volviendo atrás en el historial de despliegues para volver a versiones anteriores sin problema.