La estrategia de actualización progresiva (Rolling Update) en Kubernetes permite actualizar la versión de una aplicación de manera incremental, reemplazando los pods antiguos por nuevos de uno en uno. Este enfoque garantiza una disponibilidad continua del servicio, ya que siempre hay instancias activas durante el proceso de transición, evitando tiempos de inactividad.

A continuación, se demostrará este proceso mediante el despliegue de una aplicación web con tres réplicas, iniciando con una imagen específica y actualizándola a una versión superior.

Despliegue Inicial y Actualización

Se creará un despliegue utilizando una imagen de Nginx en su versión 1.24. La definición del recurso se muestra a continuación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webserver
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24
        ports:
        - containerPort: 80

Se aplica la configuración y se verifica el estado de los recursos:

kubectl apply -f webserver.yaml
deployment.apps/webserver created

kubectl get deployment webserver
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
webserver   3/3     3            3           30s

kubectl get replicaset
NAME                   DESIRED   CURRENT   READY   AGE
webserver-7d5b8f9c4    3         3         3       35s

Kuberntees ha creado un ReplicaSet que gestiona tres pods. Para simular una actualización de software, se modifica el manifiesto cambiando la imagen a nginx:1.25 y se ejecuta nuevamente el comando de aplicación.

kubectl apply -f webserver.yaml
deployment.apps/webserver configured

Durante la actualización, se puede observar la transición detallada mediante el comando de descripción:

kubectl describe deployment webserver
...
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  5m     deployment-controller  Scaled up replica set webserver-7d5b8f9c4 to 3
  Normal  ScalingReplicaSet  1m     deployment-controller  Scaled up replica set webserver-8b6c4d7e1 to 1
  Normal  ScalingReplicaSet  1m     deployment-controller  Scaled down replica set webserver-7d5b8f9c4 to 2
  Normal  ScalingReplicaSet  45s    deployment-controller  Scaled up replica set webserver-8b6c4d7e1 to 2
  Normal  ScalingReplicaSet  45s    deployment-controller  Scaled down replica set webserver-7d5b8f9c4 to 1
  Normal  ScalingReplicaSet  30s    deployment-controller  Scaled up replica set webserver-8b6c4d7e1 to 3
  Normal  ScalingReplicaSet  30s    deployment-controller  Scaled down replica set webserver-7d5b8f9c4 to 0

El sistema ha creado un nuevo ReplicaSet asociado a la versión 1.25. La estrategia por defecto aumenta progresivamente las réplicas del nuevo conjunto mientras reduce las del antiguo. Finalmente, el ReplicaSet original mantiene un estado de cero réplicas, permitiendo una posible reversión.

Gestión de Revisiones y Rollback

Kubernetes mantiene un historial de revisiones de los despliegues, lo que permite revertir cambios no deseados. Para ilustrar esto, se realizarán tres actualizaciones consecutivas utilizando archivos de configuración diferentes (v1, v2, v3) y se registrará la causa del cambio mediante anotaciones.

kubectl apply -f webserver_v1.yaml --record
deployment.apps/webserver created

kubectl apply -f webserver_v2.yaml --record
deployment.apps/webserver configured

kubectl apply -f webserver_v3.yaml --record
deployment.apps/webserver configured

Para visualizar el historial de cambios:

kubectl rollout history deployment webserver
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=webserver_v1.yaml --record=true
2         kubectl apply --filename=webserver_v2.yaml --record=true
3         kubectl apply --filename=webserver_v3.yaml --record=true

Si la última versión presenta fallos, se puede revertir a una revisión específica, por ejemplo, la revisión 1:

kubectl rollout undo deployment webserver --to-revision=1
deployment.apps/webserver rolled back

Al verificar nuevamente el historial, se observa que la revisión 1 ha sido promovida a la revisión 4, manteniendo el registro de las versiones intermedias:

kubectl rollout history deployment webserver
REVISION  CHANGE-CAUSE
2         kubectl apply --filename=webserver_v2.yaml --record=true
3         kubectl apply --filename=webserver_v3.yaml --record=true
4         kubectl apply --filename=webserver_v1.yaml --record=true

Este mecanismo ofrece una red de seguridad robusta para la gestión de ciclos de vida de aplicaciones en entornos de producción.