Tema 4 de 11
Clústeres de GKE
El temario pide instalar y configurar kubectl, desplegar clústeres de GKE con distintas configuraciones (Autopilot, regionales y privados) y desplegar una aplicación en contenedores. La operación diaria del clúster (grupos de nodos, autoescalado de Pods, Artifact Registry) se ve en el dominio D3.
Contenido
Arquitectura de un clúster de GKE
Plano de control
Lo gestiona siempre GKE. Ejecuta el servidor de la API de Kubernetes (kube-apiserver), el scheduler, los controladores y el almacén del estado del clúster. Corre en VM de un proyecto gestionado por Google.
Nodos
VM de Compute Engine donde se ejecutan los Pods. Los gestiona GKE en Autopilot y tú en Standard.
Todo pasa por el servidor de la API: kubectl, la consola y los propios componentes del clúster son clientes suyos. Le dices a Kubernetes el estado deseado de los objetos y Kubernetes trabaja para mantenerlo.
Instalar y configurar kubectl
Cloud Shell ya trae gcloud y kubectl. En tu equipo, kubectl se instala como componente de gcloud o con apt/yum, y necesita el plugin de autenticación gke-gcloud-auth-plugin: sin él, kubectl no puede hablar con GKE.
gcloud components install kubectl gcloud components install gke-gcloud-auth-plugin kubectl version --client # Guardar las credenciales del clúster en kubeconfig gcloud container clusters get-credentials CLUSTER_NAME --location=us-central1 kubectl get namespaces
- Las credenciales se guardan en kubeconfig, por defecto en
$HOME/.kube/config. - kubeconfig contiene contextos (clúster + usuario + espacio de nombres opcional). kubectl usa el contexto actual.
get-credentialsañade la entrada y cambia el contexto actual. Crear el clúster con gcloud también lo hace.--locationes una región para clústeres regionales o una zona para zonales. Fijacompute/regionocompute/zonepor defecto para no tener que indicarla siempre.- Ver la configuración:
kubectl config view. Cambiar de clúster:kubectl config use-context.
Autopilot frente a Standard
Autopilot es el modo en el que Google gestiona nodos, escalado, seguridad y otros ajustes, y aprovisiona los recursos según tus manifiestos. Google lo recomienda para la mayoría de cargas de producción. En un clúster Standard también se pueden ejecutar cargas concretas en modo Autopilot con ComputeClasses.
| Autopilot | Standard | |
|---|---|---|
| Ubicación | Siempre regional | Regional o zonal |
| Nodos | Gestionados por GKE, que ajusta número y tamaño según los Pods | Tú creas y gestionas los grupos de nodos (opcional: cluster autoscaler, aprovisionamiento automático) |
| SO del nodo | Container-Optimized OS con containerd | Container-Optimized OS por defecto; también Ubuntu o Windows Server |
| Facturación | Por los recursos que piden los Pods | Por todos los recursos de los nodos |
| Seguridad preconfigurada | Workload Identity Federation for GKE, Shielded GKE Nodes, arranque seguro | Shielded GKE Nodes por defecto; el resto opcional |
| Pods por nodo | Máximo 256 | 110 por defecto, máximo 512 |
| Actualizaciones | Reparación y actualización automáticas de nodos preconfiguradas; siempre en un canal | Automáticas con canal; estrategias de actualización configurables |
| Cloud Marketplace | No | Sí |
| SLA | Cubre el plano de control y la capacidad de los Pods | Sin SLA a nivel de Pod |
- Si despliegas en Autopilot sin peticiones de CPU y memoria, GKE aplica valores por defecto y ajusta las peticiones.
- Las necesidades de hardware (GPU, Spot, Arm) se piden con ComputeClasses, sin configurar nodos.
- En Autopilot todo el tráfico de los Pods pasa por las reglas de firewall de la VPC, incluso entre Pods del clúster.
# Autopilot (siempre regional) gcloud container clusters create-auto hello-cluster --location=us-central1 # Standard regional gcloud container clusters create std-cluster --location=us-central1 --num-nodes=1
Clústeres regionales, zonales y multizona
| Tipo | Plano de control | Nodos por defecto |
|---|---|---|
| Regional | Réplicas en varias zonas de la región: sigue disponible si cae una zona y durante las actualizaciones | Multizona (tres zonas) |
| Zonal | Uno, en una zona. Las cargas siguen funcionando si cae, pero no se puede configurar el clúster hasta que vuelva | Una sola zona (se puede pasar a multizona) |
- Google recomienda los clústeres regionales para producción.
- Un clúster regional no se puede convertir después en zonal.
- El grupo de nodos por defecto de un clúster Standard regional tiene nueve nodos (tres por zona); se puede bajar a uno por zona. Las cuentas de facturación nuevas solo tienen ocho IP en uso por región, así que la creación puede fallar por cuota.
- El tráfico entre nodos de zonas distintas se cobra.
- Para GPU en un clúster regional, indica con
--node-locationslas zonas que tienen esa GPU. - Si añades almacenamiento persistente sin indicar zona, GKE pone el disco zonal en una zona aleatoria.
Clústeres privados: aislamiento de red
Lo que el temario llama «private clusters» la documentación actual lo trata como aislamiento de red, que controla tres tipos de acceso: al plano de control desde fuera, desde el servidor de la API a webhooks externos y a los nodos desde fuera.
Acceso al plano de control
- Endpoint basado en DNS (recomendado): un FQDN único e inmutable por clúster, accesible desde cualquier red que llegue a las APIs de Google. Se protege con IAM y, opcionalmente, VPC Service Controls. Evita bastiones y proxies.
- Endpoints basados en IP: público o interno, con redes autorizadas (lista de bloques CIDR que pueden acceder).
Nodos privados
- Los nodos solo tienen IP internas y no son accesibles desde internet.
- Sin NAT no pueden salir a internet: activa Cloud NAT.
- Se activan a nivel de clúster, de grupo de nodos (Standard) o de carga (Autopilot), y se pueden cambiar en cualquier momento.
- En VPC compartida hay que activar Private Google Access a mano.
Con o sin nodos privados, el plano de control se comunica con los nodos solo por IP internas. Si amplías una subred usada por un clúster con redes autorizadas, actualiza también la lista de redes autorizadas.
Canales de versiones
GKE actualiza todos los clústeres automáticamente. El canal decide el equilibrio entre novedades y estabilidad; las ventanas y exclusiones de mantenimiento controlan cuándo ocurre.
| Canal | Para qué |
|---|---|
| Rapid | Las versiones más nuevas, 1-2 semanas después de la GA de Kubernetes. Para preproducción; excluido del SLA de GKE |
| Regular (por defecto) | Equilibrio entre novedades y estabilidad. El recomendado para la mayoría |
| Stable | Prioriza la estabilidad; recibe los cambios los últimos |
| Extended | Soporte a largo plazo: mantener una versión menor el mayor tiempo posible |
«No channel» desaparece
No inscribir un clúster en un canal (antes «Static») está obsoleto, solo se permite a clientes existentes y se eliminará el 14 de junio de 2027; después, GKE inscribirá esos clústeres en Stable. Los clústeres Autopilot solo pueden estar en un canal.
Desplegar una aplicación en contenedores
El flujo del quickstart oficial: habilitar las APIs de GKE y Artifact Registry, tener el rol roles/container.admin, crear el clúster y desplegar.
Crear el clúster: gcloud container clusters create-auto hello-cluster --location=us-central1
Crear un Deployment: kubectl create deployment hello-server --image=IMAGEN (por ejemplo, de Artifact Registry)
Exponerlo: kubectl expose deployment hello-server --type LoadBalancer --port 80 --target-port 8080, que crea un balanceador de Compute Engine
Comprobar: kubectl get pods y kubectl get service hello-server para ver la EXTERNAL-IP
- Para producción se usan manifiestos YAML declarativos con
kubectl apply -fen lugar de comandos imperativos. - Un Service
LoadBalancerobtiene una IP externa efímera; para usar una IP estática ya reservada se indica enloadBalancerIP. Autopilot no admiteexternalIps. - Buena práctica de Google: usar Cloud Build, Cloud Deploy y Artifact Registry para la CI/CD.
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| El equipo no quiere gestionar nodos y solo pagar lo que piden los Pods | GKE Autopilot | Google gestiona los nodos; se paga por recursos solicitados. |
| Necesitas nodos Windows Server o instalar apps de Cloud Marketplace | GKE Standard | Autopilot no admite ninguna de las dos cosas. |
| El plano de control debe seguir disponible si cae una zona | Clúster regional | Replica el plano de control en varias zonas. |
| Los nodos no deben tener IP públicas pero sí descargar paquetes de internet | Nodos privados + Cloud NAT | Sin NAT no hay salida a internet. |
| kubectl debe apuntar al clúster recién creado por otro compañero | gcloud container clusters get-credentials | Añade la entrada al kubeconfig y cambia el contexto. |
| Mantener una versión menor de Kubernetes el mayor tiempo posible | Canal Extended | Soporte a largo plazo. |
| Exponer un Deployment a internet con una IP externa | kubectl expose --type LoadBalancer | Crea un balanceador de Compute Engine. |
Trampas frecuentes del examen
❓ ¿Se puede crear un clúster Autopilot zonal?
No. Los clústeres Autopilot son siempre regionales.
❓ ¿Un clúster regional se puede convertir en zonal?
No, después de crearlo no se puede cambiar.
❓ ¿Qué hace falta además de kubectl para conectar con GKE?
El plugin gke-gcloud-auth-plugin, que proporciona los tokens de autenticación.
❓ ¿Los nodos privados pueden descargar imágenes de internet por sí solos?
No. Necesitan Cloud NAT u otra solución de NAT para salir a internet.
❓ ¿Cuántos nodos crea por defecto un clúster Standard regional?
Nueve: tres por zona en tres zonas. Puede fallar por la cuota de IP en uso.
❓ ¿Cuál es el canal de versiones por defecto?
Regular.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa necesita un clúster de GKE cuyos nodos no tengan IP públicas ni sean accesibles desde internet, pero cuyas cargas deben llamar a una API externa. El equipo de plataforma quiere administrar el plano de control desde su red de oficina sin bastiones. ¿Qué configura?
¿Listo para poner a prueba "Clústeres de GKE"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro