Crear y desplegar apps en GKE

Desplegar Kubernetes desde cero implica lidiar con nodos, kubelet, worker nodes y un sinfín de piezas que pueden volverse inmanejables. Google Kubernetes Engine (GKE) resuelve esa complejidad con un Kubernetes administrado, autoescalado, autoreparación y un sistema operativo optimizado para contenedores. Es una guía pensada para quien ya entendió los fundamentos y quiere llevarlos a producción en Google Cloud.

¿Qué ofrece Google Kubernetes Engine frente a una instalación manual?

La diferencia central está en cuánto trabajo operativo te ahorras. Con GKE no tienes que preocuparte por mantener el plano de control ni por parchar los nodos a mano.

• Kubernetes totalmente administrado: tú solo lo usas, Google lo opera [0:55].
• Container Optimized OS: un sistema operativo hardenizado y diseñado para correr contenedores de forma eficiente [1:05].
• Autoescalado: ajusta recursos según la demanda real [1:15].
• Auto-upgrade: actualiza versiones de Kubernetes, una de las tareas más complejas en una instalación tradicional [1:20].
• Auto-repair: si un nodo del cluster falla, GKE lo reemplaza automáticamente [1:25].

También soporta nodos preemptibles, máquinas virtuales mucho más baratas que Google puede retirar sin aviso. Suena riesgoso, pero la autorreparación de Kubernetes los hace viables para cargas tolerantes a interrupciones [1:45].

¿Qué es un nodo preemptible en GKE? Es una máquina virtual de bajo costo que Google puede recuperar sin previo aviso. Funciona bien en Kubernetes porque el cluster reemplaza el nodo automáticamente.

¿Qué tipos de cluster puedes crear en GKE?

Aquí se decide cuánto control quieres y cuánto pagas. Hay dos modos principales y dos dimensiones extra que aplican sobre ambos.

¿Cuál es la diferencia entre Autopilot y Standard?

• Autopilot: pagas solo por la CPU y memoria que consumen tus pods. Es el principal diferencial frente a otros competidores [2:25].
• Standard: pagas por el total de nodos. Tienes que definir worker nodes y sus tamaños, pero ganas control fino sobre la infraestructura [2:50].

¿Cuándo elegir un cluster zonal o regional, privado o público?

Un cluster zonal vive en una sola zona de disponibilidad dentro de una región. Un cluster regional distribuye las réplicas en varias zonas de la misma región, lo que te da alta disponibilidad si una zona cae [3:10].

En cuanto a exposición, los clusters pueden ser públicos o privados. La recomendación es siempre privados: sin IPs públicas hacia el plano de control, y conectándote con las herramientas que Google provee [3:30].

¿Cómo crear un cluster Autopilot desde la consola?

Entra al menú principal de Google Cloud, busca Kubernetes Engine y habilita la API la primera vez. Una vez dentro, haz clic en Crear cluster [4:00].

Asígnale un nombre, por ejemplo Platzi Cluster Auto, define la región y revisa las opciones disponibles:

• Nivel del cluster: GKE Enterprise agrega características avanzadas de seguridad.
• Registro de flotas: agrupa varios clusters para verlos en un solo lugar.
• Redes: puedes dejar la configuración por defecto.
• Servicios avanzados: como Anthos Service Mesh, una implementación de Istio [4:45].

Deja el modo en Autopilot y haz clic en Crear. La provisión tarda entre 10 y 15 minutos [5:15]. Al terminar verás que el costo de CPU y memoria arranca en cero, porque aún no hay cargas corriendo.

¿Cómo desplegar una aplicación con kubectl en GKE?

Google te da una Cloud Shell integrada con un editor parecido a Visual Studio Code. Ábrela, clona el repositorio del curso y abre los manifiestos en una ventana nueva para ver los recursos en paralelo mientras los aplicas [6:00].

¿Qué define un Deployment, un Service y un Ingress?

El Deployment describe la aplicación: versión de API (apps/v1), tipo, metadata con el nombre y labels, número de réplicas y configuración del contenedor. En el ejemplo se usa una imagen prediseñada de Google llamada Hello World que responde por el puerto 8080 [7:00].

El Service expone el Deployment dentro del cluster. Necesitas el puerto del servicio, el target port hacia el contenedor y el tipo, en este caso ClusterIP [7:30].

El Ingress es lo que te entrega una IP pública. Defines los paths y el backend, que apunta al servicio Hello World Service en el puerto 80 [7:45].

¿Qué es un Ingress en Kubernetes? Es el objeto que enruta tráfico HTTP externo hacia tus servicios internos. En GKE genera automáticamente un balanceador de carga con IP pública.

¿Cómo conectar kubectl al cluster y aplicar los manifiestos?

Vuelve a la consola del cluster, abre el menú de tres puntos y elige Conectar. Copia el comando de acceso por línea de comandos y pégalo en la Cloud Shell. Listo, ya tienes contexto contra el cluster [8:20].

Ahora aplica los manifiestos en este orden:

1. kubectl apply -f deployment.yaml.
2. kubectl apply -f service.yaml.
3. kubectl apply -f ingress.yaml.

En la consola, Cargas de trabajo mostrará el Deployment y Puertas de enlace, Ingress y Servicios mostrará el Ingress. El balanceador de carga tarda unos minutos en quedar listo [9:00].

Cuando responda, recuerda que el Ingress de ejemplo solo escucha en el puerto 80, así que entra con http:// al frente. Verás el contenedor Hello World y el nombre del pod que atendió la petición. Si recargas, el nombre cambia: el Service balancea entre los tres pods desplegados [10:00].

¿Vas a probar Autopilot o prefieres Standard para tener control fino sobre los nodos? Cuéntame en los comentarios cuál se ajusta mejor a tu caso.