![](https://azurespain-7ce76a448ae4d94a-endpoint.azureedge.net/blobazurespain022060bcbe/wp-content/uploads/2019/04/GABSL19.jpg)
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
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