GKE Autopilot: cómo ejecutar un clúster de Kubernetes para producción.

Seguramente, si sigues nuestro blog, ya sabrás que Kubernetes es la plataforma elegida por muchas compañías a la hora de ejecutar sus cargas. También habrás oído hablar de su complejidad y de lo importante que es configurar de forma adecuada la plataforma en entornos productivos (node pools, machine types, HPA, etc.).

Sabiendo la complejidad que supone para muchos proyectos el arranque y la curva de aprendizaje tan fuerte que tiene Kubernetes, aparecen en escena nuevas herramientas que nos permiten de una forma más sencilla ejecutar con éxito un clúster de GKE (Google Kubernetes Engine) en producción, sin la necesidad de ser un experto: GKE Autopilot.

A continuación vamos a revisar las principales características y limitaciones de Autopilot, y nuestras recomendaciones sobre cuándo usar esta herramienta.

¿Qué es GKE Autopilot?

Podemos decir que GKE Autopilot es un servicio de Kubernetes gestionado (“fully managed”). Que sea un servicio gestionado no significa que esté limitado en funciones.

Las principales características son:

• Aplica todas las buenas prácticas de seguridad by default.
• Reduce las operaciones y el mantenimiento del “Day 2” (Google es tu SRE)
  • Plano de control & data gestionado.
  • Auto health monitoring, health checks y auto-repair.
• No es necesario calcular la cantidad de capacidad de cómputo que requieren sus cargas de trabajo.
• Pago por uso (billing per-pod): por recursos de pod solicitados (no máquinas virtuales/nodos).
• Optimización de recursos. Los nodos están gestionados por Google.
• Sigue siendo Kubernetes, sigue siendo GKE.

Podríamos decir que GKE Autopilot ofrece lo mejor de ambos mundos Serverless + GKE, serverless como la facilidad de administración y la elasticidad de escala, y GKE con la flexibilidad de poder desplegar cualquier tipo de carga: Stateless applications, Stateful applications, Batch jobs, etc. Todo esto complementado con una fuerte apuesta por la seguridad y buenas prácticas testadas en entornos productivos.

Podéis echar un vistazo de cómo se crea un cluster a través de la consola:

Puedes crear también un cluster de GKE Autopilot a través del siguiente comando de gcloud:

gcloud container clusters create-auto "gke-autopilot-cluster"\
--region="REGION" \
--project "PROJECT_ID"

Puedes encontrar todas las opciones de configuración en el siguiente link.

¿GKE Standard vs GKE Autopilot?

Con GKE Standard la gestión de los workers y la especificación y configuración de los nodos siguen siendo responsabilidad del usuario. Esto significa que los usuarios tienen que lidiar con la configuración de los node pool (cantidad de nodos, escalado, tipos de máquinas, etc.), además de ejecutar las aplicaciones en GKE.

A diferencia de Autopilot, donde toda la gestión y configuración de los nodos recae en Google, Node auto scaling, node auto-provisioning y pod auto scaling son totalmente gestionados. Esto permite a Autopilot escalar a nivel de pod, a nivel de nodo e incluso a nivel de node pool, todo automáticamente.

La manera de facturar que tiene Google estos servicios es diferente: mientras que en GKE Standard se factura por nodo (VM), en Autopilot se factura por pod. En ambos casos se aplica un fee de $0.10/hour por cluster. Todos los detalles relativos al pricing los podéis encontrar en este link.

Otro punto clave es el tipo de cargas que podemos desplegar, GKE standard permite todo tipo de cargas, mientras que Autopilot tiene algunas limitaciones de las que hablaremos en el siguiente punto, relacionado con el plano de control.

Limitaciones de GKE Autopilot

Algunas de las limitaciones que encontramos a la hora de usar Autopilot son:

• kube-system namespace es read-only.
• No tienes control sobre los nodos.
• Limitaciones sobre afinidad de nodos. Separación de cargas con Pod affinity.
• Seguridad: configuraciones de seguridad integradas que no pueden ser modificadas.
• El escalado no es inmediato (puede tardar hasta algún minuto en el peor de los casos +500 nodos). Cuando se solicitan más recursos generalmente supone que Autopilot aprovisione más nodos para el clúster, aprovisionar nuevos nodos es más lento que simplemente activar nuevos procesos en máquinas “inactivas”.

Algunas de las limitaciones anteriores, como la falta de control o no poder acceder al plano de control, no tienen por qué ser tales y dependen mucho de los requerimientos de las compañías y sus constrains a la hora de implementar requisitos de seguridad y granularidad de acceso, tanto que incluso pueden verse como una ventaja.

¿Cuándo usar Autopilot?

No creo que la elección de un servicio u otro dependa de un único factor, seleccionar cuándo usar autopilot o cuándo usar GKE Standard o Cloud Run u otros dependerá mucho del contexto de la aplicación, adopción cloud y madurez de los equipos de desarrollo y SRE dentro de la compañía. Pero para poder ayudar a tomar una decisión hemos destacado algunos aspectos que podrían ayudarte a tomar la decisión:

• Si estás pensando en ejecutar workloads en GKE y no eres “experto”. GKE Autopilot (managed Kubernetes) puede ayudarte a arrancar de forma rápida y estable.
• No tienes ninguna de las limitaciones anteriores (no necesariamente necesitas hacer uso del plano de control y las configuraciones por defecto aplican a tu carga de trabajo).
• No conoces qué tamaño y/o tipo de nodos se deben provisionar para las cargas de trabajo. El escalado automático y redimensionamiento en función de la carga (traffic) pueden ayudarte a mantener tu aplicación estable y con garantías.
• No tienes un equipo de operaciones con altos conocimientos en GKE que pueda mantener los entornos, aplicar “buenas prácticas de seguridad”, revisar la optimización de costes y el uso de recursos. GKE Autopilot te permite implementar Google SRE para administrar tus entornos de Kubernetes.
• Pago por uso (+ fee) te permitirá conocer el patrón de gasto en función de la carga que tenga tu aplicación (siempre es recomendable hacer uso de límites, quotas y las alarmas correspondientes para evitar sustos).

Autopilot en la práctica

A continuación, vamos a ver lo sencillo que puede resultar despegar nuestra primera carga en un cluster creado en modo Autopilot.

Como pasos previos tenemos que realizar las siguientes acciones en el proyecto de GCP seleccionado:

• Habilitar el API de Google Kubernetes Engine.
• Instalar e inicializar gcloud Google Cloud CLI o puedes usar cloud shell.

Paso 1:

Como hemos visto en el punto anterior, lo primero que tenemos que hacer es crear el cluster.

gcloud container --project "project-id" clusters create-auto "autopilot-cluster-1" --region "europe-west1" --release-channel "regular"

*Indica tu nombre de proyecto.

Paso 2:

Nos conectamos al cluster:

gcloud container clusters get-credentials autopilot-cluster-1 --region europe-west1 --project project-id

Paso 3:

Usando cloud shell + kubeclt desplegar una app sencilla: my-app (1.0).

El objetivo es aprender a desplegar una carga, por lo que vamos a usar un ejemplo de una aplicación muy sencilla y pública (us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0). El fichero de configuración es el siguiente:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
spec:
 replicas: 3
 selector:
   matchLabels:
     run: my-app
 template:
   metadata:
     labels:
       run: my-app
   spec:
     containers:
     - name: hello-app
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Para desplegar, usamos el siguiente comando:

kubectl apply -f hello-app.yaml

Paso 4:

Comprobar el despliegue:

kubectl describe deployment my-app
kubectl get pods -l run=my-app

Paso 5:

Exponer el servicio en el puerto 8080:

kubectl expose deployment my-app --type LoadBalancer --port 80 --target-port 8080 --name my-app-lb

kubectl get service my-app-lb

Y podemos probar el servicio a través de la IP pública que nos devuelve el comando anterior:

http://EXTERNAL_IP

Conclusiones

Con GKE Autopilot, Google ha reducido significativamente la cantidad de pasos de configuración necesarios para implementar el clúster de GKE. La capacidad de Autopilot para aprovisionar automáticamente recursos en función de los requisitos de la carga de trabajo puede mejorar la utilización de los recursos del cluster y reducir los desafíos de operación y mantenimiento del “Day 2”.

Definitivamente, es una opción a valorar para cargas productivas que no requieren hacer uso del plano de control y que permite a los equipos centrarse en el desarrollo de aplicaciones, evitando la complejidad de la configuración (productiva) de los clusters y su mantenimiento.