Actualizaciones continuas y reversiones en Kubernetes

Uno de los beneficios de usar un Deployment es la capacidad de realizar actualizaciones continuas y crear una estrategia de actualizaciones continuas. Las actualizaciones continuas nos permiten actualizar la configuración de los pods gradualmente.

Una estrategia de actualización (k8s rollingupdate, k8s update strategy) es la opción más importante para configurar actualizaciones continuas. En la definición del Deployment, spec.strategy.type tiene dos valores posibles:

• RollingUpdate: Se añaden nuevos pods gradualmente y los pods antiguos se terminan gradualmente.
• Recreate: Todos los pods antiguos se terminan de una vez antes de que se añadan nuevos pods.

Hay 2 opciones más al actualizar el deployment usando 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 estar no disponibles durante el proceso de actualización.

Usando actualizaciones continuas de deployment podemos actualizar la imagen utilizada por un deployment. El estado del deployment (kubectl rollout status) se guarda, lo que nos permite revertir a cualquier versión anterior del deployment.

Cuando una aplicación falla debido a una imagen incorrecta o el deployment es inestable, es posible que queramos revertir el Deployment (k8s rollback). Por defecto, todo el historial de despliegue del Deployment se mantiene en el sistema que se puede usar más tarde para revertir en caso de un despliegue inestable. Podemos usar este historial para revertir en cualquier momento que queramos.

Para saber más sobre Actualización continua y Reversión, visita la documentación oficial de Kubernetes aquí.

En este artículo, actualizaremos el deployment con la estrategia de actualización continua predeterminada y revertiremos el deployment. Para revertir el deployment, utilizaremos la imagen incorrecta en una de las actualizaciones al deployment.

Requisitos previos

1. Clúster de Kubernetes con al menos 1 nodo trabajador.
   Si quieres aprender a crear un Clúster de Kubernetes, haz clic aquí. Esta guía te ayudará a crear un clúster de Kubernetes con 1 Master y 2 Nodos en Instancias EC2 de AWS Ubuntu 18.04.

¿Qué haremos?

1. Actualización continua y reversión

Actualización continua y reversión

Crea un archivo de definición de deployment para Nginx con la plantilla de pod del deployment. En esto, 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

Verifiquemos los pods existentes y creemos un deployment.

kubectl get pods

kubectl create -f my-deployment.yml

Obtén los detalles del deployment que acabamos de crear. Este deployment creó 4 pods y está controlado por el replicaset.

kubectl get deployments

kubectl get pods

kubectl get replicaset

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

Ahora, cambiemos la versión de Nginx de “nginx:1.14.2” a “nginx:1.61.1”

vim my-deployment.yml

Aplica el cambio al deployment y obtén detalles de los pods, replicaset y deployment.

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 replicaset y tiene 4 pods bajo él. Pero aún vemos el replicaset anterior con 0 pods.

Ahora, si cambiamos nuevamente la versión de Nginx pero esta vez damos una versión incorrecta de Nginx, el deployment fallará ya que la imagen de Nginx no existe para la versión incorrecta.

vim my-deployment.yml

Vamos a aplicar el cambio al deployment.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

Ahora, intentemos obtener los detalles del replicaset.

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 ya que 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 revertir a una revisión anterior si el estado de rollout no está bien.

Para revertir, primero podemos obtener el historial de rollout del deployment usando el siguiente comando.

kubectl rollout history deployments rolling-update-demo

Ahora, usando el siguiente comando con “–revision=2” podemos verificar los detalles del deployment 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 imagen de Nginx “nginx:1.16.1” que estaba funcionando antes de que actualizáramos nuestro deployment con la versión de Nginx “ngin:1.1.1” que falló.

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

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 deployment y ahora tenemos una revisión de deployment que estaba funcionando antes de la última actualización.

Para saber más sobre el deployment, se puede describir usando el siguiente comando.

kubectl get deployments

kubectl describe deployment rolling-update-demo

Conclusión

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