Ku­be­r­ne­tes De­plo­y­me­nt

Desplegar Ku­be­r­ne­tes co­rre­c­ta­me­n­te es de­te­r­mi­na­n­te para poder ad­mi­ni­s­trar de manera eficiente las apli­ca­cio­nes de co­n­te­ne­dor. En este tutorial podrás conocer los pasos básicos y aprender las mejores prácticas para montar un de­plo­y­me­nt robusto en un entorno de Ku­be­r­ne­tes.

¿Qué es un Ku­be­r­ne­tes De­plo­y­me­nt?

Ku­be­r­ne­tes De­plo­y­me­nt es un concepto esencial dentro de la pla­ta­fo­r­ma de Ku­be­r­ne­tes que si­m­pli­fi­ca el de­s­plie­gue y la gestión de apli­ca­cio­nes en co­n­te­ne­do­res. Este mecanismo de control hace las veces de in­te­r­me­dia­rio entre la co­n­fi­gu­ra­ción y la ejecución real en el clúster de Ku­be­r­ne­tes. Aquí se define el estado deseado de la apli­ca­ción, incluidos los detalles de re­pli­ca­ción, las imágenes de co­n­te­ne­dor y la co­n­fi­gu­ra­ción.

El Ku­be­r­ne­tes De­plo­y­me­nt se encarga del de­s­plie­gue au­to­ma­ti­za­do, organiza los co­n­te­ne­do­res en Ku­be­r­ne­tes Pods y los di­s­tri­bu­ye entre los recursos di­s­po­ni­bles en el clúster. Además, permite las rolling updates para realizar ac­tua­li­za­cio­nes por pasos y minimizar los tiempos de inac­ti­vi­dad. Las funciones de auto-scaling ga­ra­n­ti­zan el ajuste dinámico de la cantidad de in­s­ta­n­cias en fu­n­cio­na­mie­n­to basándose en la carga del momento.

La creación de Ku­be­r­ne­tes De­plo­y­me­nts puede basarse pri­n­ci­pa­l­me­n­te en dos métodos:

• Método im­pe­ra­ti­vo
• Método de­cla­ra­ti­vo

Crear un de­s­plie­gue de Ku­be­r­ne­tes con el método im­pe­ra­ti­vo

Con el método im­pe­ra­ti­vo in­tro­du­ces comandos para llevar a cabo las acciones deseadas. De esta manera, puedes crear recursos como pods y servicios, o ac­tua­li­zar la co­n­fi­gu­ra­ción. La modalidad im­pe­ra­ti­va es ideal para ne­ce­si­da­des si­tua­cio­na­les o ex­pe­ri­me­n­ta­les.

El siguiente comando crea un Ku­be­r­ne­tes De­plo­y­me­nt llamado nginx-deployment y lo configura para desplegar un servidor web Nginx en un co­n­te­ne­dor a partir de la imagen oficial de Nginx del puerto 80.

$ kubectl create deployment nginx-deployment --image nginx --port=80

Aunque el enfoque im­pe­ra­ti­vo se ejecuta rá­pi­da­me­n­te, tiene ciertos in­co­n­ve­nie­n­tes. Los pasos del método están di­re­c­ta­me­n­te vi­n­cu­la­dos a la situación del momento, lo que complica la re­pe­ti­ción de acciones. Esto significa que ejecutar de nuevo el mismo comando no tiene por qué dar pie siempre el mismo estado, sobre todo cuando ha cambiado la situación de salida.

Guía paso por paso del método de­cla­ra­ti­vo

En co­m­pa­ra­ción con el im­pe­ra­ti­vo, el método de­cla­ra­ti­vo tiene un enfoque más abstracto. Se determina el estado deseado de la apli­ca­ción en un archivo de co­n­fi­gu­ra­ción y Ku­be­r­ne­tes se encarga de que el clúster lo contenga. Aquí se describe lo que se pretende conseguir y Ku­be­r­ne­tes se encarga de im­ple­me­n­tar y realizar el ma­n­te­ni­mie­n­to de este estado.

Paso 1: crear archivo de co­n­fi­gu­ra­ción de YAML

Primero, se abre el editor de texto y crea el archivo YAML nginx-deployment.yaml para definir la co­n­fi­gu­ra­ción del Ku­be­r­ne­tes De­plo­y­me­nt:

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

En la sección spec se indica la co­n­fi­gu­ra­ción deseada. Con replicas: 3 se ordena al de­plo­y­me­nt que cree tres réplicas (Pods) de la apli­ca­ción. En la sección selector se define cómo se eligen los pods mientras que app=nginx sirve como criterio de selección. template es la plantilla de los pods que se van a crear, in­clu­ye­n­do las etiquetas. Dentro de containers se configura el co­n­te­ne­dor que usa la imagen Nginx y escucha al puerto 80.

Paso 2: aplicar la co­n­fi­gu­ra­ción

Ejecuta el siguiente comando en la línea de comandos para aplicar la co­n­fi­gu­ra­ción del clúster:

kubectl apply -f nginx-deployment.yaml

La opción -f indica la ruta del archivo YAML o JSON que contiene la co­n­fi­gu­ra­ción de los recursos de Ku­be­r­ne­tes.

Paso 3: comprobar el estado del de­s­plie­gue

Este paso te indica si el Ku­be­r­ne­tes De­plo­y­me­nt se ha creado co­rre­c­ta­me­n­te y cuántos pods hay di­s­po­ni­bles ac­tua­l­me­n­te.

kubectl get deployments nginx-deployment

Sale lo siguiente:

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment         3/3            3           3    2m

• READY: indica cuántos pods están en fu­n­cio­na­mie­n­to en ese momento en relación con el número deseado.
• UP-TO-DATE: indica cuántos pods se han ac­tua­li­za­do con la co­n­fi­gu­ra­ción nueva.
• AVAILABLE: indica cuántos pods hay di­s­po­ni­bles y pueden recibir so­li­ci­tu­des.
• AGE: indica cuánto tiempo lleva eje­cu­tá­n­do­se el de­s­plie­gue.

Paso 4: mostrar in­fo­r­ma­ción adicional

Con el siguiente comando recibes los detalles de tu de­s­plie­gue de Ku­be­r­ne­tes, las es­tra­te­gias uti­li­za­das, las re­pli­ca­cio­nes reales y deseadas y las etiquetas del Selector.

kubectl describe deployment nginx-deployment

Devuelve:

Name:                           nginx-deployment
Namespace:                      default
CreationTimestamp:              Thu, 22 Feb 2024 12:34:56 +0000
Labels:                         <none>
Annotations:                    deployment.kubernetes.io/revision: 1
Selector:                       app=nginx
Replicas:                       3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:                   RollingUpdate
MinReadySeconds:                0
RollingUpdateStrategy:          25% max unavailable, 25% max surge

La es­tra­te­gia de ac­tua­li­za­ción se configura como un rolling update, con una falta de di­s­po­ni­bi­li­dad máxima del 25 % y con un aumento de hasta el 25 % de pods adi­cio­na­les durante una ac­tua­li­za­ción.

Paso 5: escalar el de­s­plie­gue

Para ajustar el número de pods de un Ku­be­r­ne­tes De­plo­y­me­nt, usa el comando kubectl scale.

kubectl scale deployment nginx-deployment --replicas=2

Una vez ejecutado este comando, Ku­be­r­ne­tes ac­tua­li­za­rá el de­plo­y­me­nt y se asegurará de que disponga del número de réplicas deseadas. En el ejemplo se reduce el número de pods en fu­n­cio­na­mie­n­to a 2.

Es­tra­te­gias de de­s­plie­gue de Ku­be­r­ne­tes

Las es­tra­te­gias de de­s­plie­gue de Ku­be­r­ne­tes de­te­r­mi­nan cómo se im­ple­me­n­tan los cambios en una apli­ca­ción de un clúster.

• Rolling De­plo­y­me­nt (estándar): la es­tra­te­gia Rolling es el método de de­s­plie­gue de Ku­be­r­ne­tes por defecto. Los pods nuevos se van creando por etapas, mientras que los antiguos se van eli­mi­na­n­do gra­dua­l­me­n­te. Esto permite mantener una di­s­po­ni­bi­li­dad co­n­ti­nua­da durante el proceso de ac­tua­li­za­ción.
• Recreate De­plo­y­me­nt: en esta es­tra­te­gia primero se eliminan todos los pods exi­s­te­n­tes y luego se inician los pods ac­tua­li­za­dos. Con este método pueden perderse te­m­po­ra­l­me­n­te el servicio ya que durante el proceso de Recreate no hay ningún pod di­s­po­ni­ble.
• Blue/Green De­plo­y­me­nt: aquí se crean dos conjuntos de pods (azules y verdes): uno re­pre­se­n­ta la versión actual de la apli­ca­ción y el otro la versión nueva. Asignando etiquetas es­pe­cí­fi­cas a los pods, el tráfico puede dirigirse entre ambas versiones sin problema alguno. Puede al­te­r­nar­se entre ambas versiones y revertir de manera sencilla.

Revertir Ku­be­r­ne­tes De­plo­y­me­nt

Si surge un fallo en la versión más nueva de tu apli­ca­ción, es esencial que se revierta tan pronto como se pueda. En Ku­be­r­ne­tes puedes iniciar el proceso de rollback co­m­pro­ba­n­do el historial de re­vi­sio­nes de tu de­plo­y­me­nt y si es necesario volviendo a una versión anterior.

Controlar historial de revisión

Usa este comando para ver el historial de re­vi­sio­nes de tu de­plo­y­me­nt:

kubectl rollout history deployment/nginx-deployment

Volver a una versión anterior

Este comando te hace volver a la última revisión que considera estable:

kubectl rollout undo deployment/nginx-deployment

Volver a una versión concreta

Si quieres volver a una versión concreta, introduce el siguiente comando y el número de revisión deseado:

kubectl rollout undo deployment/nginx-deployment --to-revision=1