¿Kubernetes o CloudRun?

Ya hemos hablado en artículos anteriores sobre por qué Kubernetes es una gran opción para orquestar tus contenedores y lanzar tus servicios y aplicaciones a producción. También hemos hablado de las ventajas de CloudRun en GCP y cómo al fin de cuentas es una especie de Kubernetes customizado por Google con una capa de KNative encima para facilitar la gestión y la manutención de tus cargas de trabajo. Sin embargo, cuándo estamos diseñando la arquitectura en la nube para nuestros servicios, ¿cómo sabemos cuál de las opciones es verdaderamente la mejor opción computacional? ¿Kubernetes o CloudRun?

Pues bien, en este artículo os traigo que premisas sigo yo para saber cuál es la mejor opción dependiendo de cada caso en particulas, pues aquí como en todo “no existen balas de plata”.

Disponibilidad

La disponibilidad de nuestra carga de trabajo es una parte muy importante; ya que dependiendo desde dónde se realicen las peticiones podremos tener mayor o menor latencia, llegando a poder perjudicar a nuestros usuarios finales.

Mientras que Kubernetes, GKE en Google Cloud, nos permite tener el cluster con nodos en diferentes regiones y zonas, cuándo desplegamos un servicio en CloudRun sólo podemos hacerlo en una región en particular. Este problema podría resolverse desplegando dos veces el mismo servicio en dos regiones diferentes y luego balanceando el tráfico con un balanceador de carga, pero esto ya nos presupone un gasto adicional además de más configuración y mantenimiento por nuestra parte.

Kubernetes, definitivamente es la mejor opción para tener gran disponibilidad por múltiples zonas.

Otro punto a tener en cuenta es el número de contenedores vivos, mientras que Kubernetes garantiza que al menos habrá un pod de nuestra aplicación, CloudRun puede escalar a 0 contenedores por falta de tráfico. Esto puede ser perjudicial, pues la siguiente petición que tenga que proveer una respuesta, tardará más tiempo mientras el nodo se provee y se sirve la aplicación.

Escalabilidad

Ambas opciones ofrecen fuertes sistemas de escalados para garantizar la salud de tu aplicación; sin embargo, en Kubernetes nosotros tenemos que configurar los sitemas de autoescalado mediante Escalados Horizontales o Escalados Verticale, mientras que en CloudRun el escalado es automático en base al tráfico recibido y uso de CPU. Tan sólo tendríamos que indicar cuáles son el mínimo y el máximo de contenedores que deseamos.

CloudRun de manera automática siempre nos garantiza el número de instancias acorde a las demandas del contenedor.

Precio

Mientras que Kubernetes siempre tiene un costo mínimo garantizado por el cluster y sus nodos, el precio de CloudRun puede disminuir drásticamente si tenemos poco tráfico y los contenedores minimizan en número hasta 0. Incluso podemos contar con un par de configuraciones que nos permitan ahorrar mucho más dinero como puede ser:

Usar la primera generación de CPU
Asignar 0 al número mínimo de instancias
Usar los mínimos recursos posibles (CPU y RAM)
No dejar la CPU siempre asignada

Incluso, debido a la rápida puesta en marcha de CloudRun y la poca configuración que necesita, se podría llegar a automatizar alguna acción que borrase los servicios cuándo no se usasen (por ejemplo, borrar el entorno de desarrollo durante los fines de semana y festivos) y los re-desplegase una vez se necesiten.

Sin embargo, si vamos a hacer un uso extenso computacionalmente hablando, GKE podría llegar a ser una mejor opción a nivel económico.

Para más información sobre los precios, consulta los siguientes enlaces

Integración con otros recursos de GCP

Aunque es totalmente posible esto en ambos recuros, una vez más con CloudRun es muchísimo más sencillo. Con CloudRun todo es por y para Google Cloud.

En CloudRun bastaría con asignar los permisos y roles necesarios a la Service Account que nuestro servicio de CloudRun está usando, y eso sería todo. Es decir, si queremos acceder a CloudSQL desde nuestra instancia, sólo tendríamos que darle esos permisos, nada más.

Sin embargo, en GKE tendríamos que hacer un binding de la Service Account usada en el cluster con la Service Account en GCP con los permisos necesarios. Esto es un simple paso y se podría automatizar con Helm, pero hay que hacerlo. De lo contrario, nuestras cargas de trabajo no tendrán permisos. Además tenemos que asegurarnos de que nuestros pods están detrás del NAT y accediendo con la IP del cluster, de lo contrario tendríamos que estar añadiendo permisos y excepciones a nivel de firewall por cada IP de cada pod, por no hablar de que estás cambiarían con el tiempo. Una tarea tediosa si no se tiene en cuenta.

Acceso a los pods.

En el caso de que algo no funcione bien en nuestras aplicaciones, tanto Kubernetes como CloudRun se encargarán de terminar los pods problemáticos y proporcionar nuevos automáticamente. En el caso de que queramos ver los logs, en ambos recursos podemos tener acceso a todos los logs con Cloud Logging. Pero en el caso de que queramos entrar en algún pod a ver qué está sucediendo, con CloudRun será imposible. No hay modo de acceder a un pod de CloudRun. Con Kubernetes siempre podremos acceder a un pod para su análisis.

Configuración de las redes y seguridad

De nuevo, CloudRun vuelve a poner muchas más facilidades para exponer un servicio público a internet o para mantenerlo en nuestra red VPC privada. Al desplegar un servicio en CloudRun, este automáticamente tiene asignada una URL con un certificado TLS para poder acceder por HTTPS. Además, la fácil configuración nos permite exigir autenticación para mandar peticiones o incluso exponerla solamente internamente en nuestra VPC. No necesitariamos nada más. La misma URL redirigirá a nuestra instancia de CloudRun y el tráfico se puede dividir entre todas las revisiones de manera sencilla.

Para Kubernetes requerimos cambiar la configuración. Por defecto el servicio asignado es ClusterIP, con lo que no nos permitirá acceder a nuestras cargas de trabajo desde internet. Sin embargo, podemos cambiarlo (e incluso automatizarlo con Helm) para que use otro tipo de servicio y exponer nuestras aplicaciones. O incluso usar un balanceador de carga que redirija el trafíco a los puntos de acceso deseados, aunque en este caso los balanceadores de carga suponen un coste adicional.

Kubernetes o CloudRun

¿Y a ti se te ocurre alguna pauta más a tener en cuenta antes de decidir cuál usar? Déjame en los comentarios tu opinión, te leo.