K8s/Kubernetes: AWS frente a GCP frente a Azure

Kubernetes (a menudo denominados "K8") ganó la batalla de las herramientas de orquestación de contenedores hace años. Sin embargo, todavía hay muchas formas de implementar Kubernetes hoy y hacer que funcione con varias infraestructuras y muchas herramientas, algunas mejor mantenidas que otras. Sin embargo, quizás el desarrollo más interesante en ese frente es que los principales proveedores de la nube han decidido lanzar sus propias versiones administradas de Kubernetes:

• Microsoft Azure ofrece Azure Kubernetes Service (AKS)
• AWS ofrece Amazon Elastic Kubernetes Service (EKS)
• Google Cloud ofrece Google Kubernetes Engine (GKE)

Desde una perspectiva de DevOps, ¿qué ofrecen estas plataformas? ¿Cumplen sus promesas? ¿Cómo se comparan su tiempo de creación y otros puntos de referencia? ¿Qué tan bien se integran con sus respectivas plataformas, especialmente con sus herramientas CLI? ¿Cómo es mantenerlos y trabajar con ellos? A continuación, profundizaremos en estas preguntas y más.

Nota: Para los lectores a quienes les gustaría que se explicaran los conceptos de un clúster de Kubernetes antes de seguir leyendo, Dmitriy Kononov ofrece una excelente introducción.

AKS frente a EKS frente a GKE: funciones anunciadas

Hemos decidido agrupar las diferentes funciones disponibles para cada versión administrada de Kubernetes en silos:

• Resumen mundial
• Redes
• Escalabilidad y rendimiento
• Seguridad y Monitoreo
• Ecosistema
• Precios

Nota: estos detalles pueden cambiar con el tiempo, ya que los proveedores de la nube actualizan periódicamente sus productos.

Resumen mundial

Kubernetes en sí fue un proyecto de Google, por lo que tiene sentido que fueran los primeros en proponer una versión alojada en 2014.

De los tres que se comparan aquí, Azure fue el siguiente con AKS y ha tenido algo de tiempo para mejorar: si recuerda acs-engine, que se usó para aprovisionar Kubernetes en Azure hace unos años, apreciará el esfuerzo de Microsoft en su reemplazo, aks-motor.

AWS fue el último en implementar su propia versión, EKS, por lo que a veces puede parecer que está atrasado en el frente de funciones, pero se está poniendo al día.

En términos de precios, por supuesto, las cosas siempre están cambiando, y Google decidió unirse a AWS en su punto de precio de $0.10/hora, a partir de junio de 2020. Azure es el forastero aquí al brindar el servicio AKS de forma gratuita, pero no está claro cómo mucho que puede durar.

Otra diferencia principal radica en la función de actualización del clúster. Las actualizaciones más automatizadas están en GKE y están activadas de forma predeterminada. Sin embargo, AKS y EKS son similares entre sí aquí, en el sentido de que ambos requieren solicitudes manuales para poder actualizar los nodos maestro o trabajador.

Redes

En el lado de la red, los tres proveedores de la nube están muy cerca el uno del otro. Todos permiten a los clientes implementar políticas de red con Calico, por ejemplo. Con respecto al balanceo de carga, todos implementan su integración con sus propios recursos de balanceador de carga y dan a los ingenieros la opción de qué usar.

La principal diferencia encontrada aquí se basa en el valor agregado de la red de servicios. AKS no admite ninguna malla de servicio lista para usar (aunque los ingenieros pueden instalar Istio manualmente). AWS ha desarrollado su propia red de servicios llamada App Mesh. Finalmente, Google lanzó su propia integración con Istio (aunque todavía en versión beta) que los clientes pueden agregar directamente al crear el clúster.

Mejor apuesta: GKE

Escalabilidad y rendimiento

Con respecto al rendimiento y la escalabilidad de GKE frente a AKS frente a EKS, GKE parece estar a la cabeza. De hecho, admite la mayor cantidad de nodos (5000) y ofrece una amplia documentación sobre cómo escalar correctamente un clúster. Todas las características de alta disponibilidad están disponibles y son fáciles de ajustar. Además, GKE lanzó recientemente Anthos, un proyecto para crear un ecosistema alrededor de GKE y sus funcionalidades; con Anthos, puedes implementar GKE en las instalaciones.

Sin embargo, AWS tiene una ventaja clave: es el único que permite que los nodos completos ejecuten su clúster de Kubernetes.

A partir de junio de 2020, AKS carece de alta disponibilidad para el maestro, lo cual es un aspecto importante a tener en cuenta. Pero, como siempre, eso podría cambiar pronto.

Mejor apuesta: GKE

Seguridad y Monitoreo

En términos de cumplimiento, los tres proveedores de la nube son equivalentes. Sin embargo, en términos de seguridad, EKS y GKE brindan otra capa de seguridad con sus servicios integrados de administración de claves.

En cuanto al monitoreo, Azure y Google Cloud brindan su propio ecosistema de monitoreo en torno a Kubernetes. Vale la pena señalar que el de Google se actualizó recientemente para usar Kubernetes Engine Monitoring, que está diseñado específicamente para Kubernetes.

Azure proporciona su propio sistema de supervisión de contenedores, que se creó originalmente para un ecosistema de contenedores básico que no es de Kubernetes. Agregaron monitoreo para algunas métricas y recursos específicos de Kubernetes (estado del clúster, implementaciones), en modo de vista previa, a partir de junio de 2020.

AWS ofrece un monitoreo ligero para el plano de control directamente en Cloudwatch. Para monitorear a los trabajadores, puede usar las métricas de Kubernetes Container Insights proporcionadas a través de un agente de CloudWatch específico que puede instalar en el clúster.

Mejor apuesta: GKE

Ecosistema

En términos de ecosistemas, los tres proveedores tienen diferentes puntos fuertes y activos. AKS ahora tiene una documentación muy completa sobre su plataforma y es el segundo en términos de publicaciones en Stack Overflow. EKS tiene la menor cantidad de publicaciones en Stack Overflow, pero se beneficia de la solidez de AWS Marketplace. GKE, como la plataforma más antigua, tiene la mayor cantidad de publicaciones en Stack Overflow y una cantidad decente de aplicaciones en su mercado, pero también la documentación más completa.

Mejores apuestas: GKE y EKS

Precios

Con respecto al precio general, incluso con el movimiento de GKE para implementar el punto de precio de $0.10/hora para cualquier clúster, sigue siendo, con mucho, la nube más barata. Esto se debe a algo específico de Google: los descuentos por uso sostenido, que se aplican siempre que el uso mensual de los recursos bajo demanda alcanza un cierto mínimo.

Es importante tener en cuenta que la fila de precios de ejemplo no tiene en cuenta el tráfico al clúster de Kubernetes por el que puede cobrar el proveedor de la nube.

La razón por la que AWS no permite el uso de su nivel gratuito para probar un clúster de EKS es que EKS requiere máquinas más grandes que el nivel tX.micro y el precio por hora de EKS no está en el nivel gratuito.

Sin embargo, aún puede ser económico probar cualquiera de estas opciones administradas de Kubernetes con una carga decente usando los nodos de reserva/nodos preferenciales de cada proveedor de la nube; esa táctica ahorrará fácilmente entre un 80 y un 90 por ciento en el precio final. (¡Por supuesto, no se recomienda ejecutar cargas de producción con estado en tales máquinas!)

Funciones anunciadas y ventaja de Google

Al observar las diferentes funciones anunciadas en línea, parece que existe una correlación entre el tiempo que la versión administrada de Kubernetes ha estado en el mercado y la cantidad de funciones. Como se mencionó, el hecho de que Google haya sido el iniciador del proyecto Kubernetes parece ser una ventaja innegable, lo que resulta en una mejor y más sólida integración con su propia plataforma en la nube.

Pero AKS y EKS no deben subestimarse a medida que maduran; ambos pueden aprovechar sus características únicas. Por ejemplo, AWS es el único que tiene una integración de nodos completa y también cuenta con la mayor cantidad de aplicaciones en su mercado.

Ahora que las características anunciadas para cada oferta de Kubernetes están claras, profundicemos más con algunas pruebas prácticas.

Kubernetes: AWS frente a GCP frente a Azure en la práctica

La publicidad es una cosa, pero ¿cómo se comparan las diferentes plataformas cuando se trata de servir cargas de producción? Como ingeniero de la nube, conozco la importancia del tiempo que se tarda en generar y desactivar un clúster cuando se aplica la infraestructura como código. Pero también quería explorar las posibilidades de cada CLI y comentar qué tan fácil (o no) lo hace cada proveedor de la nube para generar un clúster.

Experiencia de usuario de creación de clústeres

AKS

En AKS, generar un clúster es similar a crear una instancia en AWS. Simplemente busque el menú AKS y recorra una sucesión de menús diferentes. Una vez que se valida la configuración, se puede crear el clúster, un proceso de dos pasos. Es muy sencillo y los ingenieros pueden lanzar un clúster de manera fácil y rápida con la configuración predeterminada.

EKS

La creación de clústeres es definitivamente más compleja en EKS que en AKS. En primer lugar, y de forma predeterminada, AWS requiere un viaje a IAM primero para crear un nuevo rol para el plano de control de Kubernetes y asignarle el ingeniero. También es importante tener en cuenta que la creación de este clúster no incluye la creación de los nodos, por lo que cuando medí 11 minutos en promedio, esto es solo para la creación maestra. La creación del grupo de nodos es otro paso para el administrador, que nuevamente necesita un rol para los trabajadores con tres políticas necesarias para realizar a través del panel de control de IAM.

GKE

Para mí, la experiencia de crear un clúster manualmente es más placentera en GKE. Después de encontrar Kubernetes Engine en Google Cloud Console, haga clic para crear un clúster. Diferentes categorías de configuraciones aparecen en un menú a la izquierda. Google completará previamente el nuevo clúster con un grupo de nodos predeterminado fácilmente modificable. Por último, pero no menos importante, GKE tiene el tiempo de generación de clústeres más rápido, lo que nos lleva a la siguiente tabla.

Hora de generar un clúster

Realicé estas pruebas en la misma región (Fráncfort y Europa occidental para AKS) para eliminar el posible impacto de esta diferencia en el tiempo de reproducción. También traté de seleccionar el mismo tamaño para los nodos del clúster: tres nodos, cada uno con dos vCPU y siete u ocho GB de memoria, un tamaño estándar para ejecutar una pequeña carga en Kubernetes y comenzar a experimentar. Creé cada grupo tres veces para calcular un promedio.

En estas pruebas, GKE se mantuvo muy por delante con un tiempo de generación siempre inferior a los tres minutos.

Kubernetes: descripción general de la CLI de AWS frente a GCP frente a Azure

No todas las CLI se crean de la misma manera, pero en este caso, las tres CLI son en realidad módulos de una CLI más grande. ¿Cómo es ponerse en marcha con la cadena de herramientas CLI de cada proveedor de nube?

CLI de AKS (a través de az )

Después de instalar az tooling, luego el módulo AKS (a través az aks install-cli ), los ingenieros deben autorizar la CLI para comunicarse con la cuenta de Azure del proyecto. Se trata de obtener las credenciales para actualizar el archivo kubeconfig local a través de un simple az aks get-credentials --resource-group myResourceGroup --name myAKSCluster .

De manera similar, para crear un clúster: az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI (a través de aws o eksctl )

En AWS, encontramos un enfoque diferente: hay dos herramientas CLI oficiales diferentes para administrar los clústeres de EKS. Como siempre, aws puede conectarse a los recursos de AWS, en particular a los clústeres. La obtención de credenciales en un kubeconfig local se puede realizar a través de: aws eks update-kubeconfig --name cluster-test .

Sin embargo, los ingenieros también pueden usar eksctl , desarrollado por Weaveworks y escrito en Go, para crear y administrar fácilmente un clúster de EKS. Una gran ventaja que EKS brinda a los ingenieros de nube es que pueden combinarlo con archivos de configuración YAML para crear infraestructura como código (IaC), ya que funciona con CloudFormation. Definitivamente es un activo a tener en cuenta al integrar un clúster de EKS en una infraestructura más grande en AWS.

Crear un clúster a través eksctl es tan fácil como eksctl create cluster , no se requieren otros parámetros.

GKE CLI (a través gcloud )

Para GKE, los pasos son muy similares: instala gcloud y luego autentícate a través gcloud init . Las posibilidades a partir de ahí: los ingenieros pueden crear, eliminar, describir, obtener credenciales, cambiar el tamaño, actualizar o actualizar un clúster o enumerar clústeres.

La sintaxis para crear un clúster con gcloud es sencilla: gcloud container clusters create myGCloudCluster --num-nodes=1

AKS frente a EKS frente a GKE: resultados de la versión de prueba

En la práctica, podemos ver que GKE es sin duda el más rápido en activar un clúster básico, tanto en términos de simplicidad de la consola como de tiempo de generación del clúster. En cuanto a UX, con el botón de conexión al lado del clúster, lo que también lo hace más sencillo para conectarse a un clúster.

En términos de herramientas CLI, los tres proveedores de la nube han implementado funcionalidades similares; sin embargo, podemos enfatizar la herramienta adicional proporcionada por Weaveworks para EKS. eksctl es la herramienta perfecta para implementar infraestructura como código sobre su infraestructura de AWS preexistente, combinando otros servicios con EKS.

Las ofertas administradas de Kubernetes avanzan: AWS frente a GCP frente a Azure

Para aquellos que recién comienzan en el mundo de Kubernetes, la implementación preferida para mí es GKE, ya que es la más sencilla. Es fácil de configurar, tiene una experiencia de usuario simple y rápida para generar y está bien integrado en el ecosistema de Google Cloud Platform.

Aunque AWS fue el último en unirse a la carrera, tiene algunas ventajas innegables, como los nodos bare metal y el simple hecho de que está integrado con el proveedor con la mayor participación mental.

Finalmente, AKS ha hecho un gran progreso desde su creación. Es probable que la paridad de herramientas y características no lleve mucho tiempo, mientras tanto deja espacio en el proceso para innovar. Y como con cualquier oferta de Kubernetes administrada, para aquellos que ya están en la plataforma principal, la integración será un punto de venta.

Una vez que un equipo ha elegido un proveedor de nube de Kubernetes, podría ser interesante observar las experiencias de otros equipos, en particular las fallas. Estas autopsias son un reflejo de casos del mundo real, siempre un buen punto de partida para desarrollar las mejores prácticas de vanguardia propias. ¡Espero tus comentarios a continuación!