Por qué GKE se diferencia de otros Kubernetes gestionados
Google Kubernetes Engine (GKE) es el servicio de Kubernetes gestionado de Google Cloud, y compite directamente con AWS EKS y Azure AKS en el mercado de la nube pública. La diferencia fundamental no es solo técnica: Google creó el proyecto Kubernetes, y GKE es el servicio que más tiempo lleva acumulando experiencia operacional real sobre esa plataforma.
Con GKE, Google se encarga del plano de control: el servidor de API, etcd y el planificador. En un clúster Regional, el plano de control se distribuye entre tres zonas, por lo que la API de Kubernetes sigue respondiendo incluso cuando una zona completa falla. GKE Autopilot va un paso más allá: Google gestiona también los nodos, lo que reduce drásticamente la carga operacional del equipo de ingeniería. El examen GCP-ACE pone especial énfasis en las diferencias entre estos modelos operativos, las estrategias de escalado y los patrones de integración de seguridad.
---
GKE Standard vs GKE Autopilot: cómo elegir
La primera decisión importante que enfrenta cualquier equipo al adoptar GKE es si usar GKE Standard o GKE Autopilot. Ambos modos exponen la misma API de Kubernetes, pero difieren fundamentalmente en quién es responsable de la infraestructura de nodos.
| Característica | GKE Standard | GKE Autopilot | |---------------|-------------|---------------| | Aprovisionamiento de nodos | Gestionado por el operador | Gestionado por Google | | Parcheo del SO del nodo | Responsabilidad del operador (actualización automática disponible) | Responsabilidad de Google | | Configuración del Node Pool | Totalmente personalizable | No disponible (usar resource requests por Pod) | | Base de facturación | Tiempo de VM del nodo | CPU/memoria solicitada por Pod | | Contenedores privilegiados | Permitidos | Prohibidos | | DaemonSets personalizados | Permitidos | Restringidos (solo DaemonSets del sistema) | | Carga operacional | Alta | Baja | | Nodos Spot | Configurados por Node Pool | Configurados mediante anotaciones del Pod |
GKE Autopilot es ideal para equipos con poca experiencia en operaciones de Kubernetes y para startups en etapa inicial donde la velocidad de entrega tiene prioridad sobre el control de infraestructura. Si tus cargas de trabajo necesitan contenedores privilegiados o DaemonSets personalizados, GKE Standard es la única opción viable. Una trampa recurrente en el examen: GKE Autopilot exige que cada Pod declare resource requests explícitos. Sin esos requests, GKE Autopilot rechaza la programación del Pod.
!GKE Standard vs Autopilot
Topología del clúster: Zonal vs Regional, Público vs Privado
Los clústeres de GKE se clasifican según dos ejes independientes: alcance de disponibilidad (Zonal vs Regional) y nivel de exposición de red (Público vs Privado).
| Tipo de clúster | Ubicación del plano de control | Ubicación de nodos | Característica principal | |----------------|-------------------------------|-------------------|-------------------------| | Zonal | Zona única | Zona única | Menor costo; falla total si la zona cae | | Regional | Distribuido en 3 zonas | Distribuido en 3 zonas | Alta disponibilidad; SLA del plano de control 99.95% | | Público (por defecto) | Endpoint público | IP pública asignada | Acceso desde internet permitido | | Privado | Endpoint interno a la VPC | Sin IP externa | Aislado de internet; requiere Cloud NAT |
Con un clúster Regional, el plano de control está distribuido en tres zonas. Una falla en una zona no interrumpe kubectl ni la programación de Pods. El plano de control de un clúster Zonal deja de responder si su zona falla, causando una interrupción operacional completa. Para cargas de trabajo productivas, los clústeres Regionales son el estándar recomendado.
Los clústeres Privados aíslan los nodos y el plano de control dentro de una VPC. Los contenedores que necesitan conectividad saliente a internet requieren Cloud NAT. Para restringir el acceso al plano de control únicamente desde el tráfico interno de la VPC, habilita el Endpoint Privado y usa Authorized Networks para limitar qué rangos CIDR pueden alcanzar el servidor de API.
Los clústeres VPC-native con Alias IP también aparecen en el examen. En modo VPC-native, las IPs de los Pods se asignan directamente desde un rango de IP secundario de la subred de la VPC, lo que permite enrutamiento directo entre IPs de Pods y otros recursos de la VPC. A diferencia del modelo legacy basado en rutas, las reglas de firewall a nivel de VPC se pueden aplicar directamente a IPs de Pods, otorgando un control de red más granular.
---
Node Pools y estrategias de aislamiento de cargas de trabajo
Un Node Pool es un grupo de nodos dentro de un clúster que comparten la misma configuración. Ejecutar múltiples Node Pools en un solo clúster de GKE es un patrón común en producción para aislar diferentes tipos de cargas de trabajo.
| Patrón de uso | Ejemplo de configuración del Node Pool | Propósito | |--------------|----------------------------------------|----------| | Aislamiento de cargas GPU | Node Pool separado con nodos n1-standard con GPU | Limitar Pods de entrenamiento ML exclusivamente a nodos GPU | | Reducción de costos con Spot | Node Pool Spot junto a Node Pool On-demand | Usar Spot para trabajos batch que toleran interrupciones | | Cargas de trabajo de alta memoria | Node Pool separado con instancias optimizadas para memoria | Aislar bases de datos en memoria y servidores de caché | | Contenedores Windows | Agregar Node Pool con Windows Server | Soporte para aplicaciones basadas en Windows | | Aislamiento de componentes del sistema | Node Pool dedicado de tamaño reducido | Ejecutar solo componentes de kube-system |
Para fijar un Pod a un Node Pool específico, usa nodeSelector o nodeAffinity. Las combinaciones de Taints y Tolerations son otro mecanismo habitual. Al aplicar un Taint a un Node Pool de GPU, los Pods regulares sin la Toleration correspondiente no podrán consumir recursos GPU.
Una característica crítica de los Node Pools que debes tener presente: los Node Pools de GKE son inmutables. No se puede cambiar el tipo de máquina de un Node Pool existente directamente. El procedimiento estándar es crear un nuevo Node Pool con la configuración deseada, hacer cordon del Node Pool antiguo para bloquear la programación de nuevos Pods, hacer drain para desalojar y reprogramar los Pods existentes, y finalmente eliminar el pool antiguo. Configurar un PodDisruptionBudget durante este proceso garantiza un número mínimo de réplicas disponibles durante toda la migración.
---
El trío de escalado: HPA, VPA y Cluster Autoscaler
El escalado en GKE opera en tres capas independientes, cada una orientada a una dimensión diferente del problema.
| Escalador | Qué ajusta | Métrica clave | Caso de uso principal | |----------|-----------|--------------|----------------------| | HPA (Horizontal Pod Autoscaler) | Número de réplicas de Pod | CPU, memoria, métricas personalizadas | Gestionar picos de tráfico | | VPA (Vertical Pod Autoscaler) | CPU/memoria requests y limits del Pod | Datos históricos de uso | Ajuste automático de resource requests | | Cluster Autoscaler | Número de nodos | Pods no programables / nodos inactivos | Reducir costos fuera del horario pico |
HPA escala el número de réplicas de Pods en ejecución hacia arriba o hacia abajo. La métrica predeterminada es la utilización de CPU, pero también puedes usar métricas personalizadas basadas en Stackdriver o métricas externas. El número mínimo de réplicas de HPA es 1; para escalar a cero se necesita KEDA (Kubernetes Event-driven Autoscaling).
VPA analiza los patrones de consumo real de CPU y memoria de un Pod y recomienda o aplica automáticamente valores de request actualizados. Existen tres modos: Off (solo recomendaciones), Auto (aplica actualizaciones reiniciando Pods) e Initial (aplica solo en la primera programación). Evita ejecutar VPA y HPA en el mismo Pod cuando HPA escala por CPU: los dos controladores entran en conflicto. Reserva VPA para cargas de trabajo donde HPA no usa CPU como señal de escalado.
Cluster Autoscaler opera a nivel de Node Pool, con conteos mínimo y máximo de nodos configurables. Cuando los Pods no pueden programarse por recursos insuficientes, Cluster Autoscaler aprovisiona nodos adicionales. Cuando los nodos están inactivos, migra los Pods y elimina los nodos ociosos. Combinar HPA con Cluster Autoscaler crea un bucle de automatización de dos capas: HPA ajusta el conteo de réplicas y Cluster Autoscaler ajusta el conteo de nodos para acompañarlo.
La confusión más común en el examen se resuelve de forma clara: el ajuste automático del número de nodos usa Cluster Autoscaler; el ajuste automático del número de Pods usa HPA; el ajuste automático del tamaño de los resource requests del Pod usa VPA. Mantén estos tres roles bien diferenciados.
---
Integración de identidad segura con Workload Identity
Las aplicaciones que se ejecutan en GKE frecuentemente necesitan acceder a servicios de GCP como Cloud Storage, BigQuery y Cloud SQL. La forma en que configuras la autenticación para ese acceso es una pregunta de seguridad central.
| Método de autenticación | Descripción | Riesgo de seguridad | |------------------------|-------------|--------------------| | Montaje de archivo de clave de cuenta de servicio | Montar un archivo de clave JSON en un Pod como Kubernetes Secret | La exposición de la clave compromete todos los permisos; la rotación de claves es una carga de gestión | | Cuenta de servicio compartida del nodo | Todos los Pods de un nodo heredan los permisos de la cuenta de servicio del nodo | Viola el principio de mínimo privilegio; concede permisos excesivos en todo el clúster | | Workload Identity | Vincula un Kubernetes Service Account (KSA) a un GCP IAM Service Account (GSA) | Sin archivos de clave; acceso de mínimo privilegio por Pod |
Workload Identity vincula un Kubernetes Service Account a un GCP IAM