Name: Kubernetes Administre la plataforma de despliegue de sus aplicaciones en contenedores
Rating: 4.6667 (3 reviews)

Objetivos del capítulo y requisitos previos

El capítulo anterior fue una introducción al uso de Kubernetes; en particular, al uso del dashboard para desplegar una aplicación.

Este capítulo va a retomar este ejercicio. La diferencia se centrará en el modo de funcionamiento, ya que las operaciones se realizarán en la línea de comandos.

Gestión por kubectl de una aplicación

1. Eliminar un despliegue

Durante el capítulo anterior, se implementó la aplicación MailHog con ayuda del dashboard. Aunque no lo haya hecho, puede seguir igualmente las instrucciones que vienen a continuación.

El primer punto consiste en recuperar la lista de despliegues presentes en el servidor. Para hacer esto, lance el comando kubectl, seguido de la palabra clave get con el tipo de objeto deployment. A continuación, se muestra el comando correspondiente:

$ kubectl get deployment

He aquí el resultado devuelto:

NAME      READY   UP-TO-DATE   AVAILABLE   AGE 
mailhog   1/1     1            1           8d

El borrado del despliegue se realiza con el comando kubectl, seguido de los siguientes elementos:

La palabra clave delete.
El tipo de objeto que hay que eliminar (deployment).
El nombre del objeto que hay que eliminar (mailHog).

He aquí el comando que se debe lanzar:

$ kubectl delete deployment mailhog

He aquí el resultado que devuelve este comando:

deployment.extensions "mailhog" deleted

La consulta de la lista de pods devolverá el siguiente contenido:

NAME                       READY   STATUS        RESTARTS   AGE 
mailhog-69bd8f74cb-kl9p5   1/1     Terminating   2          8d

Después de unos momentos, el comando debería devolver el siguiente mensaje:

No resources found.

2. Crear un despliegue

El comando kubectl, además de las operaciones de consulta y borrado, soporta la creación de objetos. En el caso de un despliegue, el comando se debe ejecutar con las siguientes opciones:

La palabra clave create.
El tipo de objeto que hay que crear: deployment (o el acceso directo deploy).
El nombre del despliegue (mailhog).
El nombre de la imagen que hay que desplegar con la opción --image.

A continuación, se muestra el comando correspondiente a estas indicaciones:

$ kubectl create...

Exposición de servicios

1. ¿Por qué utilizar un servicio?

En los apartados anteriores, ha accedido a la aplicación MailHog usando el nombre de su pod. Si el pod desaparece, el administrador del despliegue creará de forma automática un nuevo pod. Desafortunadamente, el nombre habrá cambiado.

Para simplificar el acceso a un servicio alojado en un pod, es necesario utilizar un nombre de servicio. El servicio cumplirá varias funciones:

Creación de una entrada DNS estable en Kubernetes.
Actualización de la entrada DNS del servicio, en caso de cambio de pod.
Reparto de la carga, en caso de que el despliegue cree varios pods.

2. Exponer un despliegue a través de un servicio

La creación de un servicio se realiza con el comando kubectl, seguido de:

la instrucción expose seguida del despliegue que se ha de exponer (como deployment/NOMBRE_DESPLIEGUE,
la lista de puertos para exponer con la opción --port (1025 y 8025 en el caso de MailHog).

A continuación, se muestra el comando que se debe ejecutar en función de estas instrucciones:

kubectl expose deployment/mailhog --port 1025,8025

He aquí el resultado de este comando:

service/mailhog exposed

3. Verificar el servicio mailhog

El servicio ahora está creado, lo que se traduce en la creación de una nueva dirección DNS dentro del clúster de Kubernetes. Esta última debe apuntar al pod que ejecuta la aplicación MailHog.

Desde fuera del clúster, desafortunadamente no es posible consultar el servidor DNS de Kubernetes. Para hacer esto, debe ejecutar una petición de DNS desde el pod de MailHog en modo interactivo.

Para esto, utilice el comando kubectl, así como la instrucción exec. Esta última espera las siguientes opciones:

La activación de stdin (opción --stdin o su acceso directo -i).
El uso de un terminal con stdin (opción --tty o su acceso directo -t).
El nombre del pod en el que ejecutar el comando.
El indicador de fin de opciones (--).
Para terminar, el comando que se debe ejecutar: un shell sh.

Resumiendo (y concatenando las opciones -i y -t en -it), el comando será el siguiente:

$ kubectl exec -it mailhog-5dbc9c86c4-gsbk6 sh

Al igual que sucedía con la opción port-forward, es posible usar la referencia del despliegue en lugar del nombre del pod, de la siguiente manera:...

Automatización del despliegue usando un archivo YAML

1. Mecanismo de creación y actualización

En capítulos anteriores, se ha desplegado la aplicación MailHog con los siguientes mecanismos:

El dashboard de Kubernetes.
El comando kubectl con la opción create.

Para estos dos mecanismos, se envía a la API de Kubernetes de forma transparente una definición en formato YAML.

En el contexto de operaciones básicas de Kubernetes, este mecanismo es suficiente. Para operaciones de actualización o para usar funciones avanzadas (declaración de reglas de Ingress), es preferible conocer la estructura real utilizada.

A continuación, se utilizará el comando kubectl con la opción apply para administrar las creaciones y actualizaciones de objetos.

2. Estructura YAML de un despliegue

a. Algunos recordatorios

Se puede utilizar el comando kubectl para consultar los despliegues. La opción -o wide permitirá obtener información ampliada sobre los despliegues.

La opción describe funciona de la misma manera y permite obtener información ampliada sobre las características de los objetos.

b. Recuperación de una estructura con formato YAML

Además de consultar los objetos, la opción get permite recuperar la definición de los objetos en formato YAML (o JSON). Para hacer esto, puede usar la opción -output, seguida del formato esperado (no distingue entre mayúsculas y minúsculas). Así, la extracción de la definición del despliegue de mailhog se hará usando el comando kubectl, seguido de estas instrucciones:

Recuperar los despliegues (get deployment).
El nombre del despliegue (mailhog).
Especificar el formato deseado (-o yaml).

A continuación, se muestra el comando correspondiente:

$ kubectl get deployment mailhog -o yaml

He aquí un extracto de esta definición:

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
 annotations: 
   deployment.kubernetes.io/revision: "1" 
 creationTimestamp: "2019-03-10T02:53:49Z" 
 generation: 1 
 labels: 
   app: mailhog 
 name: mailhog 
 namespace: default 
 resourceVersion: "213785" 
 selfLink: ... 
 uid: ... 
spec: 
 progressDeadlineSeconds:...

Ingress y reverse proxy

1. Origen de la necesidad

En las secciones anteriores, se ha desplegado una aplicación. Desafortunadamente, esta última no es accesible desde el exterior, excepto si se utiliza el comando kubectl port-forward.

Por fortuna, Kubernetes ofrece un mecanismo especialmente diseñado para este tipo de operaciones: los objetos Ingress.

Estos últimos, como los despliegues o los servicios, se manejan mediante el comando kubectl y se pueden listar (get), describir (describe), crear (create) o administrar automáticamente (apply).

2. Rol de un proxy inverso

En informática, un proxy inverso designa un componente que se colocará antes que otro para ampliar sus capacidades. Es una arquitectura implementada muy habitualmente y se utiliza para dar respuesta a los siguientes problemas:

Acceder a un programa no accesible directamente desde Internet.
Distribuir la carga en varios servidores.
Soportar operaciones de encriptación o compresión.
Soportar la gestión de la seguridad.
Agrupar el acceso y reducir el uso de direcciones IP públicas.

Hay muchos programas en el mercado que soportan algunas o todas estas funciones: Apache, Nginx, Haproxy, Traefik, etc.

Cada una de estas herramientas tiene sus ventajas e inconvenientes. Sin embargo, estos aspectos están ocultos gracias a las capas de abstracción de Kubernetes. Por lo tanto, esta elección generalmente tiene poco impacto.

Minikube tiene un controlador Nginx listo para usar mediante una simple activación. Será el que se utilizará en el resto del capítulo.

3. Activación del controlador Ingress en Minikube

Lo primero que debe hacer (si aún no lo ha hecho) es habilitar el controlador Ingress predeterminado de Minikube.

Al igual que para otros addons de Minikube, el comando minikube recibirá como parámetros los siguientes argumentos:

La opción addons.
La acción enable.
Por último, el nombre del plugin que hay que activar: ingress.