Crear un Kubernetes con az para el Global Azure Bootcamp Sciene Lab 2019

Sitio dedicado a Microsoft Azure y otras tecnologías Cloud

En el artículo anterior, me he unido entusiasta en la búsqueda de exoplanetas propuesta en el laboratorio científico de la Global Azure Bootcamp del 2019.

Recordar que David Rodriguez nos notifico la apertura del GitHub del laboratorio, y se ha currado la documentación necesaria para instalar el contenedor Docker en Azure Instance Container, y en cualquier otro motor Docker.

Por mi parte, me he puesto a jugar para instalarlo en Kubernetes y han surgido cosas interesantes que quiero compartir contigo.

Subiendo la apuesta con az CLI

Además, para salir de mi zona de confort, le he añadido que lo quiero hacer en az CLI, en vez de con powershell (que me ha fallado una y otra vez), para lo que me instalo las dependencias en mi sistema, y así conseguir poder seguir utilizando ISE como editor y depurador de mi script.

Aprovecho para agradecer a Gisela Torres, y su magnífico blog sobre Azure, de donde he sacado mucha información útil y básica para construir mi Kubernetes e instanciar el contenedor.

#Login manual, y luego defino cual es la suscripción que quiero utilizar.
az login
az account set -s 'xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx'

#Parámetros globales: El grupo de recursos, la localización y el nombre del AKS
$RESOURCE_GROUP="GlobalAzureBootcamp"
$LOCATION="westeurope"
$AKS_NAME="GAB2019AKS"

#Creo el grupo de recursos y luego creo el cluster de AKS
#El tamaño de la VM es la mínima que me deja en westeurope.
az group create -n ${RESOURCE_GROUP} -l ${LOCATION}
az aks create -g ${RESOURCE_GROUP} -n ${AKS_NAME} --node-vm-size 'Standard_A1_v2' --node-count 1 --generate-ssh-keys

#Instalo kubectl (imprescindible)
set "%PATH%;C:\Users\<tu_usuario>\.azure-kubectl"
az aks install-cli

#Configura kubectl para comunicarse con el cluster AKS
az aks get-credentials -g ${RESOURCE_GROUP} -n ${AKS_NAME}

#Me aseguro que está corréctamente instalado recuperando la versión.
kubectl version --short

#Instancio GABSL con un fichero de variables de contexto
kubectl apply -f "C:\Users\Administrador\.azure-kubectl\envars.yaml"

#Creo el servicio que me permite acceder al contenedor desde Inet.
kubectl apply -f "C:\Users\Administrador\.azure-kubectl\service.yaml"

#Cuando he terminado el laboratorio, lo borro todo.
az group delete -n ${RESOURCE_GROUP}
az aks delete -g ${RESOURCE_GROUP} -n ${AKS_NAME}

Como ves, este no es un script muy complejo. Lo más interesante, una vez construido el cluster, es que voy a tener dos grupos de recursos diferenciados. Por un lado el del servicio AKS, y luego otro en donde está toda la infraestructura.

La línea que he resaltado en negrita, es la que realiza la instancia del contenedor en AKS, y que utiliza el fichero ‘envars.yaml’ para buscar la imagen correcta y configurar las variables de contexto.

apiVersion: v1
kind: Pod
metadata:
  name: gbsal-jqa
  labels:
    app: gbsal
    purpose: GBASL
spec:
  containers:
  - name: gbsal-jqa
    image: globalazurebootcamp/sciencelab2019:latest
    ports:
    - containerPort: 80
    env:
    - name: BatchClient__Email
      value: "jc_quijano@hotmail.com"
    - name: BatchClient__TeamName
      value: "Juan Quijano"
    - name: BatchClient__CompanyName
      value: "Juan Quijano"
    - name: BatchClient__CountryCode
      value: "ES"            
    - name: BatchClient__LabKeyCode
      value: "THE-GAB-ORG"

Por cierto, te aviso, olvídate de las expectativas de tiempo real. La creación del Cluster tarda entre 5 a 30 minutos. Luego, la creación de los contenedores si que va como un tiro.

El siguiente paso es conseguir poder acceder desde Internet a mi contenedor, para lo cual montó un servicio de Kubernetes de tipo Balanceador de carga, que describo dentro de su propio YAML llamado ‘service.yaml’, y que responde por el puerto 80.

#Creo el servicio que me permite acceder al contenedor desde Inet.
kubectl apply -f "C:\Users\Administrador\.azure-kubectl\service.yaml"
apiVersion: v1
kind: Service
metadata:
  name: gbsal
  labels:
    app: gbsal
spec:
  selector:
    app: gbsal
  ports:
    - protocol: TCP
      port: 80
  type: LoadBalancer

Más cosas interesantes en esta infraestructura:

  • Utilizo una etiqueta para decirle al servicio sobre que aplicaciones debe trabajar:  app: gbsal
  • He abierto los puertos tanto del servicio como del contenedor: port: 80
  • El tipo es de LoadBalancer, lo cual me va a construir un Balanceador de carga de Azure y le va a poner una IP fija.

Utilidad y costes

Una vez montado el AKS y el Pod con el contenedor, puedo escalar fácilmente el número de instancias de máquinas virtuales en el cluster. De hecho, es tan fácil que tengo que tener cuidado con los límites por defecto de vCpu en mi suscripción.

Pero, en este caso específico, la utilidad no pasa más allá de probar mis conocimientos y aprender. Y eso es debido a que la imagen docker del laboratorio está pensada para trabajar sobre un único núcleo.

Es decir -como puedes comprobar- si pongo 18 Pods en el cluster, solamente funciona el primero que se engancha al servidor, y el resto se quedan durmiendo el sueño de los justos.

Sobre costes, para una único contenedor, no merece la pena utilizar esta infraestructura. A grosso modo son unos 46€/mes, en comparación con un servicio de Instancia de contenedor que no supera los 38€ al mes (si lo tengo encendido 730 horas al mes).

Es decir, este es un artículo de I+D sin una aplicación real útil.

Pero aún así, espero que sea de utilidad.

 

 

Una respuesta

  1. Buenas! Oye, ¿llegaste a probar con el parámetro “replicas” en el yaml? Eso debería darte la posibilidad de desplegar más de una réplica (instancia) del contenedor, pudiendo llegar a consumir todos los cores del cluster

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.