Cómo trabajar con el objeto Deployment en Kubernetes

Cómo trabajar con el objeto Deployment en Kubernetes

En uno de los primeros artículos que escribí sobre Kubernetes te dije, sin entrar en detalle, que la forma recomendada de desplegar los pods sobre tu clúster era a través del objeto Deployment, debido a que este gestiona los objetos ReplicaSet por nosotros y nos ayuda no solo en el despliegue sino también es posteriores actualizaciones. En este artículo quiero contarte todo lo que deberías saber sobre este objeto.

Cómo funciona un Deployment

Los deployments se definen como objetos de alto nivel que te ayudan no solo en el despliegue de tus aplicaciones en Kubernetes sino que también te permiten hacer actualizaciones de forma declarativa. En versiones anteriores, esta tarea se realizaba gestionando directamente el objeto ReplicationController, de forma más manual, pero ahora se ha delegado en estos y los ReplicaSets, de los que ya te hablé en un articulo anterior.

Como siempre, vamos a verlo con un ejemplo que siempre se entiende mejor  . En este caso voy a desplegar un servidor web con tres replicas, inicialmente de Nginx:

 
  
#web-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - name: http
              containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: http
 

Además del Deployment voy a crear un objeto de tipo Service para poder acceder al servidor web desde fuera del clúster, y ver de forma sencilla lo que va ocurriendo con él mismo durante el artículo.

Por lo tanto, cuando despliegues este manifiesto tendrás 6 objetos nuevos en tu entorno: un Deployment, un ReplicaSet, tres pods y un servicio de tipo LoadBalancer.

 
  
kubectl apply -f web-deployment.yaml --record
 

En el comando anterior he añadido el parámetro –record, el cual verás para qué sirve más adelante

En esta primera fase la salida esperada será la siguiente:

 
  
deployment.apps/web-deployment created
service/web-service created
 

Puedes comprobar todos los objetos creados a través del siguiente comando:

 
  
kubectl get deploy,rs,po,svc
#or kubectl get deployments,replicasets,pods,services
 

y el resultado será parecido a este:

 
  
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/web-deployment   3/3     3            3           70s

NAME                                              DESIRED   CURRENT   READY   AGE
replicaset.extensions/web-deployment-6646b5b476   3         3         3       70s

NAME                                  READY   STATUS    RESTARTS   AGE
pod/web-deployment-6646b5b476-6f6sz   1/1     Running   0          70s
pod/web-deployment-6646b5b476-m9hjh   1/1     Running   0          70s
pod/web-deployment-6646b5b476-mglhs   1/1     Running   0          70s

NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
service/kubernetes    ClusterIP      10.0.0.1      none         443/TCP        70s
service/web-service   LoadBalancer   10.0.82.126   52.155.177.3   80:31717/TCP   70s
 

En mi caso, si accedo a través del navegador a la IP 52.155.177.3 veré el servidor de Nginx funcionando.

Ahora bien, cuando se dice que gracias a los deployments tenemos una actualización de manera declarativa ¿esto qué significa? Pues básicamente que podemos hacer modificaciones en el YAML que define el despliegue, ya sea volviendo a enviar todo él o a través de kubectl patch/edit, y el controlador de los deployments determinará si dicho cambio conlleva una actualización de los pods (esto es, cuando se ha modificado la sección template del pod dentro del objeto Deployment). Para comprobar esto, cambia la imagen nginx utilizada en la creación por mcr.microsoft.com/dotnet/core/samples:aspnetapp:

 
  
#web-deployment.v2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          #image: nginx:latest
          image: mcr.microsoft.com/dotnet/core/samples:aspnetapp
          ports:
            - name: http
              containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: http
 

y aplica los nuevos cambios:

 
  
kubectl apply -f web-deployment.v2.yaml --record
 

Al tratarse del mismo objeto Deployment creado anteriormente, el resultado ya no será created sino configured esta vez:

 
  
deployment.apps/web-deployment configured
service/web-service configured
 

Como es la segunda vez que mandas información acerca del mismo Deployment, si vuelves a comprobar el listado de ReplicaSets comprobarás que ahora tienes dos para el mismo despliegue:

 
  
$kubectl get rs

NAME                        DESIRED   CURRENT   READY   AGE
web-deployment-5b5f4f975    3         3         3       92s
web-deployment-6646b5b476   0         0         0       4m24s
 

Pero sigues teniendo el mismo número de pods:

 
  
$kubectl get po

NAME                             READY   STATUS    RESTARTS   AGE
web-deployment-5b5f4f975-kvh9k   1/1     Running   0          2m3s
web-deployment-5b5f4f975-mflx9   1/1     Running   0          2m5s
web-deployment-5b5f4f975-r8c9p   1/1     Running   0          2m7s
 

En el artículo sobre los ReplicaSet expliqué que estos crean los pods con el nombre del ReplicaSet (el cual está compuesto por el nombre del despliegue más un literal aleatorio) y un literal aleatorio por cada pod. Si comparas el nombre que tenían tus pods la primera vez y el nombre que tienen ahora podemos deducir que el ReplicaSet que está gestionando los pods no es el mismo que al principio, sino el nuevo que vemos con el literal 5b5f4f975. Esto es así porque el Deployment utiliza un nuevo ReplicaSet cada vez que haces una actualización, el cual tiene la versión actualizada de la plantilla que tiene que utilizar para los pods.

¿Pero por qué se queda el anterior con cero pods? Muy sencillo: en el caso de que necesitemos dar marcha atrás, porque la actualización no esté funcionando correctamente por ejemplo, el Deployment volverá a utilizar dicho ReplicaSet para recrear los pods con la configuración anterior. Puedes comprobarlo utilizando el comando rollout undo:

 
  
kubectl rollout undo deployment web-deployment
 

Kubernetes responderá con el siguiente mensaje:

 
  
deployment.extensions/web-deployment rolled back
 

y podrás ver que vuelves a tener un Nginx funcionando, en lugar de la aplicación de ejemplo de ASP.NET Core. De hecho, si vuelves a revisar los ReplicaSets comprobarás que ahora el que controla los pods es, de nuevo, el primero que se generó:

 
  
$kubectl get rs

NAME                        DESIRED   CURRENT   READY   AGE
web-deployment-5b5f4f975    0         0         0       10m
web-deployment-6646b5b476   3         3         3       13m
 

Llegados a este punto es posible que te preguntes ¿entonces voy a tener tantos ReplicaSet como todas las actualizaciones que esta aplicación haya tenido en su vida? La respuesta es no  Por defecto sólo se guardan las 10 últimas revisiones, aunque es configurable a través de revisionHistoryLimit, dentro del apartado spec del deployment:

 
  
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  labels:
    app: web
spec:
  revisionHistoryLimit: 5
  replicas: 3
  selector:
[...]
 

Por otro lado, si quisieras ir a una revisión en concreto podrías hacerlo añadiendo al comando el parámetro –to-revision=N, siempre dentro de las revisiones disponibles:

 
  
kubectl rollout undo deployment web-deployment --to-revision=2
 

Otro dato importante es poder ver el estado en el que se encuentra una actualización. En este ejemplo los cambios son demasiado rápidos, por lo que voy a ralentizar el tiempo que tardan los pods en estar listos.

 
  
#Slow downkubectl patch deployment web-deployment -p '{"spec": {"minReadySeconds" : 5}}'
 

El resultado de esta acción será el siguiente:

 
  
deployment.extensions/web-deployment patched
 

Nota: Este cambio en el deployment no hará que se actualicen los pods, al estar fuera del apartado template.

Ahora voy a actualizar de nuevo el objeto Deployment, pero esta vez a través de set image:

 
  
#Update the image
kubectl set image deployment web-deployment nginx=httpd:latest --record
 

El resultado será que la imagen ha sido actualizada:

 
  
deployment.extensions/web-deployment image updated
 

En este caso, sí generará un redespliegue de pods con la nueva imagen. Para conocer el estado de esta actualización puedes utilizar rollout status:

 
  
#See the status of the rollout
kubectl rollout status deployment web-deployment
 

Este último se quedará a la espera hasta que finalice la actualización, mostrando el avance de la misma:

 
  
Waiting for deployment "web-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "web-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "web-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "web-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "web-deployment" successfully rolled out
 

Una vez que termine el proceso, comprobarás que ahora lo que tienes es un servidor Apache ejecutándose en tus pods

Para ver el histórico de las últimas actualizaciones que has llevado a cabo sobre tu despliegue inicial utiliza el comando rollout history:

 
  
kubectl rollout history deployment web-deployment
 

El resultado debería de ser como el que sigue:

 
  
REVISION  CHANGE-CAUSE
3         kubectl apply --filename=web-deployment.yaml --record=true
4         kubectl apply --filename=web-deployment.v2.yaml --record=true
5         kubectl set image deployment web-deployment nginx=httpd:latest --record=true
 

Gracias a el parámetro –record puedes ver qué comando se lanzó para este deployment cada vez que se actualizó, de tal manera que será más sencillo poder determinar a qué versión tienes que ir si fuera necesario. Sin embargo, lo habitual es que utilicemos el mismo nombre de archivo, si estamos trabajando con un despliegue automatizado, pero este tendrá diferentes versiones del contenido. Si es el caso, podemos ver el detalle de cada actualización indicando la revisión:

 
  
kubectl rollout history deployment web-deployment --revision=4
 

De hecho, en la misma podrás ver que solo se muestra el contenido de la plantilla a utilizar para los pods:

deployment.extensions/web-deployment with revision #4

 
  
deployment.extensions/web-deployment with revision #4
Pod Template:
  Labels:       app=web
        pod-template-hash=5b5f4f975
  Annotations:  kubernetes.io/change-cause: kubectl apply --filename=web-deployment.v2.yaml --record=true
  Containers:
   nginx:
    Image:      mcr.microsoft.com/dotnet/core/samples:aspnetapp
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        none
    Mounts:     none
  Volumes:      none
 

Diferentes estrategias de despliegue

Por último, es importante saber que los Deployments nos permiten llevar a cabo la actualización a través de dos estrategias. Por defecto se utiliza la llamada RollingUpdate la cual va remplazando los pods, evitando la pérdida de servicio, basándose en los valores maxSurge (cuantos pods puede haber por encima del valor deseado) y maxUnavailable (cuántos como máximo pueden no estar disponibles). Por defecto, ambas propiedades tienen un valor del 25%, aunque se puede especificar un número exacto en lugar de un porcentaje. Debes tener en cuenta que para poder utilizar esta estrategia tu aplicación debe de ser capaz de convivir con versiones diferentes.

Por otro lado, también es posible utilizar el modo Recreate que lo que haces es eliminar primero todos los pods antiguos y después crea los nuevos. En este caso sí que hay pérdida de servicio.

Esta configuración se hace a través del apartado strategy:

 
  
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  labels:
    app: web
spec:
  revisionHistoryLimit: 5
  strategy:
    type: Recreate

[...]
 

Escalar un deployment

Por último, si solo quieres aumentar o disminuir el número de réplicas puedes hacerlo a través de scale:

 
  
kubectl scale deployment web-deployment --replicas=50
 

En un próximo artículo te mostraré cómo hacer esto de manera automática.

¡Saludos!