Actualizaciones y retrocesos en Kubernetes

Una de las ventajas de utilizar un Despliegue es la posibilidad de realizar actualizaciones rodantes. Las rolling updates nos permiten actualizar la configuración de los pods de forma gradual.

La estrategia de actualización es la opción más importante para configurar las actualizaciones rodantes. En la definición del Despliegue, spec.strategy.type tiene dos valores posibles:

• RollingUpdate: Los nuevos pods se añaden gradualmente y los antiguos se eliminan gradualmente.
• Recrear: Todos los pods antiguos se terminan de una vez antes de añadir nuevos pods.

Hay 2 opciones más al actualizar el despliegue utilizando RollingUpdate.

• maxSurge: El número de pods que se pueden crear por encima del número deseado de pods durante una actualización.
• maxUnavailable: El número de pods que pueden no estar disponibles durante el proceso de actualización.

Utilizando las actualizaciones rodantes del despliegue podemos actualizar la imagen utilizada por un despliegue. El estado del despliegue se guarda, lo que nos permite retroceder a cualquier versión anterior del despliegue.

Cuando una aplicación falla debido a una imagen incorrecta o el despliegue es inestable, podemos querer revertir el Despliegue. Por defecto, todo el historial de despliegue del Despliegue se guarda en el sistema y se puede utilizar posteriormente para revertirlo en caso de despliegue inestable. Podemos utilizar este historial para hacer un rollback en cualquier momento que queramos.

Para saber más sobre Rolling update y Rollback, visita la documentación oficial de Kubernetes aquí.

En este artículo, actualizaremos el despliegue con la estrategia de actualización por defecto y revertiremos el despliegue. Para revertir el despliegue, utilizaremos la imagen incorrecta en una de las actualizaciones del despliegue.

Requisitos previos

1. Cluster Kubernetes con al menos 1 nodo trabajador.
   Si quieres aprender a crear un clúster de Kubernetes. Esta guía te ayudará a crear un cluster de Kubernetes con 1 Maestro y 2 Nodos en Instancias EC2 de AWS Ubuntu.

¿Qué vamos a hacer?

1. Actualización y reversión
   

Actualización y retroceso

Crea un archivo de definición de despliegue para Nginx. En él, hemos especificado la versión de Nginx como «nginx:1.14.2».

vim my-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-demo
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Comprobemos los pods existentes y creemos un despliegue.

kubectl get pods

kubectl create -f my-deployment.yml

Obtén los detalles del despliegue que acabamos de crear. Este despliegue ha creado 4 pods y está controlado por el conjunto de réplicas.

kubectl get deployments

kubectl get pods

kubectl  get replicaset

En la captura de pantalla anterior, puedes ver que tenemos 1 despliegue bajo el cual tenemos 1 replicaset y 4 pods controlados por el replicaset.

Ahora vamos a cambiar la versión de Nginx de «nginx:1.14.2» a «nginx:1.61.1».

vim my-deployment.yml

Aplica el cambio al despliegue y obtén los detalles de los pods, el conjunto de réplicas y el despliegue.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

kubectl get replicaset

En la captura de pantalla anterior, se puede ver que se ha creado un nuevo conjunto de réplicas y tiene 4 pods bajo él. Pero seguimos viendo el antiguo replicaset con 0 pods.

Ahora, si volvemos a cambiar la versión de Nginx pero esta vez damos una Versión de Nginx errónea, el despliegue fallará ya que la Imagen de Nginx no existe para la versión errónea.

vim my-deployment.yml

Apliquemos el cambio al despliegue.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

Ahora, intentemos obtener los detalles del conjunto de réplicas.

kubectl get replicaset

En la captura de pantalla anterior, se puede ver que los nuevos Pods están fallando con el error «ErrImagePull». Los pods están fallando porque la imagen de Nginx no existe para la versión «ngin:1.1.1».

Ahora, si queremos volver a las imágenes anteriores que funcionaban, podemos hacer un rollback.

Para hacer un rollback, primero podemos obtener el historial de rollouts de las implantaciones utilizando el siguiente comando.

kubectl rollout history deployments rolling-update-demo

Ahora, utilizando el siguiente comando con «–revision=2» podemos comprobar los detalles del despliegue que tenemos en «–revision=2»

kubectl rollout history deployments rolling-update-demo --revision=2

En la captura de pantalla anterior, puedes ver que la revisión-2 tiene la versión de la imagen de Nginx «nginx:1.16.1» que estaba funcionando antes de que actualizáramos nuestro despliegue con la versión de Nginx «ngin:1.1» que falló.

Ahora, vamos a revertir el despliegue a la última revisión que tenemos antes del actual despliegue fallido.

kubectl get deployments

kubectl rollout undo deployment rolling-update-demo

kubectl get pods

kubectl get replicaset

En la captura de pantalla anterior, puedes ver que hemos revertido el último despliegue y ahora tenemos una revisión del despliegue que funcionaba antes de la última actualización.

Para saber más sobre el despliegue, se puede describir utilizando el siguiente comando.

kubectl get deployments

kubectl describe deployment rolling-update-demo

Conclusión

En este artículo hemos visto los pasos para crear un despliegue y actualizarlo. Hemos visto cómo se puede revertir un despliegue si falla por alguna razón, aquí el error que vimos para el despliegue fallido fue «ErrImagePull». Vimos cómo el despliegue mantiene su revisión a la que se puede revertir en caso de que no queramos mantener las últimas actualizaciones en el despliegue.