Minikube en AWS EC2 Spot Instances
Ayer estaba investigando un poco sobre GitLab y necesitaba un cluster de kubernetes para probar unas cosas. ¿Qué hago ahora? ¡Minikube, por supuesto!
El problema es que estaba trabajando desde mi PC de escritorio, que es un poco vieja y tiene Windows 7 todavía (ya sé, debería actualizar…). La primera opción que se me ocurrió fue levantarme de la silla, caminar 4 metros, agarrar mi notebook (más nueva, Windows 10, Minikube funcionando), volver a la silla y seguir trabajando desde la notebook. Pero pensé que tenía que existir una solución más fácil que caminar 4 metros.
¡Puedo agarrar mi vieja y confiable instancia t2.micro del free tier de Amazon Web Services e instalar Minikube ahí! Abrí MobaXterm, arranqué la sesión SSH a esa máquina, instalé Minikube, pero no funcionó: Minikube se quejó de que no tenía suficientes cores, necesitaba como mínimo 2 y mi pobre t2.micro apenas tiene uno. Necesitaba como mínimo una t3.medium, que está fuera del free tier.
Me gustó como solución, me pareció barata, pero quise optimizar un poco los costos. La forma de conseguir una máquina más barata es mediante Spot Instances, un sistema a través del cual AWS subasta a precio reducido su capacidad ociosa, reservándose el derecho de terminar tu instancia si ya no tiene suficiente capacidad ociosa para prestarte servicio. El precio bajaba de $0.0416 per Hour a $0.0125 per Hour para Linux (un 70% menos!!). No es mucho dinero para el tiempo que la voy a usar, pero Cost Optimization es uno de los pilares del Well-Architected Framework y quise ponerlo en práctica y probar este camino (además, no es como si tuviese algo mejor a lo que dedicar mi tiempo, como un empleo y esas cosas).
El problema de las Spot Instances es que no se las puede tener reservadas para siempre, se destruyen, y hay que hacer muchos clicks para crearla de nuevo. Con una instancia normal, si está detenida se la puede iniciar con 3 clicks. Pero con una Spot Instance no se puede detenerla hoy e iniciarla la semana que viene, hay que crear una instancia nueva. Claramente alguien que no quiere caminar 4 metros tampoco quiere hacer todos esos clicks, así que opté por la solución simple de AWS para crear instancias con 3 clicks: Launch Templates. Podría haber usado cualquier herramienta de IaC como Terraform o CloudFormation, pero me pareció innecesario.
Nota aparte: Por defecto el disco asociado a la instancia se destruye cuando se destruye la instancia, pero este comportamiento se puede cambiar cuando se crea el disco. Yo podría guardar el mismo disco y asociarlo a una nueva instancia cada vez que lo quiero usar, pagando sólo el costo de mantenimiento del disco. Con 1 GB me alcanza, y el costo es $0.10 per GB-month, así que pagaría 10 centavos por mes. Un monto totalmente despreciable, pero consideré si realmente necesito guardar ese disco y concluí que no, por lo que opté por crear un disco nuevo cada vez que creo una instancia y borrarlo cuando se borra la instancia, reduciendo costos. Eso introduce el problema de volver a instalar Minikube cada vez que ejecuto la instancia, el cual vamos a resolver más adelante, al final de la creación del Launch Template.
Para crear un Launch Template primero nos logueamos en AWS, vamos al servicio EC2, clickeamos en Launch Templates y luego en este botón azul.
Inicialmente nos pide un nombre y una descripción de la versión. Para cada template se pueden tener distintas versiones, sea por cambios incrementales (como en mi caso que fui probando y lo dejé andando en la versión 4), o por alguna diferencia como incluir o no un par de claves SSH. Cuando creamos un Template estamos al mismo tiempo creando la versión 1 de ese template. Source template en nuestro caso no es necesario, simplemente nos permite copiar las opciones de otro template ya creado (adivinen quién lo está usando para escribir este artículo).
AMI ID es el ID de la Amazon Machine Image a partir de la cual se van a lanzar las instancias. Ese ID corresponde a la AMI oficial de Ubuntu Server 18.04, y para encontrarlo (o elegir otro) pueden clickear en Search for AMI, ingresar «unbutu» o las palabras claves que quieran y seleccionar desde ahí la imagen. Instance type es t3.medium en nuestro caso porque, como habíamos discutido antes, Minikube requiere 2 cores y esa es la instancia más barata que ofrece EC2 con 2 cores. Key pair name es el nombre del par de claves SSH que queremos asociar a la instancia, y se puede seleccionar un par de claves existente o no especificar este valor en el template (habrá que definirlo luego al crear la instancia). En nuestro caso, para jugar con Minikube necesitamos acceso SSH, y el objetivo era tener la instancia lista con el mínimo esfuerzo posible, así que yo asocié un par de claves que ya tengo descargado en mi PC. Network type permite elegir entre la implementación moderna de redes llamada Virtual Private Cloud y la implementación clásica donde todo estaba asociado a un mismo router; elijan VPC. Security Groups nos permite agregar las instancias creadas a un security group o varios previamente existentes. En mi caso, tengo un security group creado con la regla de permitir conexiones TCP por el puerto 22 (es decir conexiones SSH) desde la IP de mi casa, y cada vez que quiero acceder a una máquina la agrego a ese grupo. Como la idea de esta máquina es crearla cuando quiera usar Minikube y destruirla cuando deje de usarlo, voy a querer acceder a ella apenas esté creada, así que me conviene agregarla de entrada a ese Security Group.
En Network no necesitamos agregar nada, pero en Storage (Volumes) tenemos que configurar nuestro disco. Esa es la configuración estándar, y me pareció aceptable para este caso. Nótese el flag Delete on termination con valor YES, esto hace que cuando se borre la instancia nuestros datos se pierdan, pero no nos van a seguir cobrando por el disco.
Dentro de Advanced details es donde más tenemos que configurar. Para empezar, tildamos Request Spot instances, que era el motivo por el que estábamos haciendo un Launch Template. En mi caso opté por no incluir el precio máximo en el template porque estoy dispuesto a pagar cualquier precio hasta el precio de la misma instancia On-Demand. Request type indica qué pasa con el pedido de instancia si la instancia se muere por algún motivo. Básicamente cuando se «crea» una Spot Instance en realidad se crea una Spot Request, con el tipo de instancia, la región y el precio máximo. Si se pueden satisfacer estas tres condiciones, la Spot Request se considera Fulfilled y se crea la Spot Instance propiamente dicha (es decir, la VM). Si la Spot Request no puede ser satisfecha, no se crea la Spot Instance. La opción Request type nos permite elegir qué ocurre con la Spot Request una vez que fue satisfecha. Si la Spot Request es One-time, una vez satisfecha se cancela. Si la Spot Request es Persistent, se considera satisfecha mientras la Spot Instance viva, y si la Spot Instance es destruida la Spot Request vuelve al estado Pending-fulfillment e intenta crear una nueva Spot Instance para reemplazar la que se acaba de destruir. Esto es particularmente útil cuando se usan Spot Instances para servidores, y en mi caso lo agregué simplemente para ahorrarme un par de clicks en el extraño caso en que mi VM se destruya. Interruption behavior en Stop significa que la VM puede ser apagada sin ser destruida (sólo es válido para Persistent Spot Requests). Block duration permite reservar la instancia por un período mínimo garantizado, en bloques de 60 minutos, hasta 6 horas. Es una feature útil para asegurarse de tener las Spot Instances reservadas durante ese tiempo, pero no conozco el valor a la hora de crear el template.
Las opciones que siguen no son relevantes para el uso que planteamos para nuestro template, yo opté por dejarlas en Don’t include in launch template, excepto por: Shutdown behavior: Stop, indica que cuando ejecutemos sudo poweroff (es decir, una órden de apagado a nivel OS) la máquina se va a detener en vez de destruirse; Stop – Hibernate behavior: Disable, deshabilitamos la opción de hibernar porque esto no es compatible con Spot Instances; Termination protection: Disable, si estuviese habilitado no podríamos destruir la máquina manualmente, deberíamos deshabilitarlo primero; Monitoring: Disable, no nos interesan las métricas, y cuestan dinero.
El campo final es User Data, donde podemos cargar un shell script que se ejecutará cuando se inicie por primera vez la VM. Dado que la VM se va a destruir cuando la dejemos de usar y crearse nuevamente cuando querramos usarla, éste es el lugar para ejecutar el script de instalación de Minikube, y así ahorrarnos instalarlo manualmente cada vez que queremos usarlo. Voy a optar por simplemente pegar el script para Ubuntu con un procesador de 64 bits, y si hay alguna duda o algún problema podemos discutirlo.
#!/bin/bash
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
&& chmod +x ./kubectl
&& sudo mv ./kubectl /usr/local/bin/kubectl
&& sudo apt-get update
&& sudo apt-get install docker.io -y
&& curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
&& sudo minikube start –vm-driver=none
¡Y eso es todo! Ahora, cada vez que querramos crear una instancia tendremos que hacer click derecho en el template, click en Launch instance from template, elegir la versión, click en Launch instance from template, y tendremos la Spot Request creada, que una vez satisfecha (suele tardar no más de un par de segundos) nos va a crear la instancia.
Si entramos por SSH a la máquina, vamos a ver que Minikube está instalado y funcionando.
Para destruir la instancia, sólo tenemos que cancelar la Spot Request.
¡Y eso es todo! Un Minikube a 5 clicks de distancia, por el precio más bajo (y no es oferta de Black Friday). Espero les sirva a todos los que no tienen ganas de levantarse y caminar 4 metros, o les interesa aprender a crear Launch Templates.