Operar GKE

Google separa dos tipos de herramientas: las de Google Cloud (consola y gcloud container) para gestionar el clúster, y las de Kubernetes (kubectl) para lo que pasa dentro. En la consola, la página de GKE muestra clústeres, nodos y cargas de trabajo.

gcloud container clusters list
gcloud container clusters get-credentials CLUSTER --location=us-central1
kubectl get nodes
kubectl get pods --all-namespaces
kubectl get services
kubectl describe pod POD_NAME

Cada nodo lleva la etiqueta cloud.google.com/gke-nodepool con el nombre de su grupo de nodos, útil para filtrar.

GKE descarga imágenes directamente de los repositorios Docker de Artifact Registry. La clave es la identidad de los nodos:

• Por defecto los nodos usan la cuenta de servicio predeterminada de Compute Engine.
• Si esa cuenta ya no tiene el rol Editor (la restricción iam.automaticIamGrantsForDefaultServiceAccounts se aplica por defecto en organizaciones creadas desde el 3 de mayo de 2024), hay que darle Artifact Registry Reader (roles/artifactregistry.reader).
• Con eso, GKE descarga imágenes de repositorios del mismo proyecto. Para otro proyecto, para subir imágenes o para usar una cuenta de servicio propia, hay que configurar el acceso de forma explícita.
• Los ámbitos de acceso de los nodos existentes no se pueden cambiar.

Google recomienda sustituir el rol Editor de la cuenta predeterminada por roles menos permisivos, usando Policy Simulator para ver el impacto.

Grupos de nodos

Un grupo de nodos es un conjunto de nodos de un clúster Standard con la misma configuración. En Autopilot no se configuran: GKE gestiona los nodos.

• El grupo por defecto tiene tres nodos en cada zona del clúster, con la imagen cos_containerd.
• Se añaden grupos con otras máquinas, Local SSD, Spot VMs u otra imagen para Pods con necesidades distintas, y se dirigen los Pods con nodeSelector o taints.
• No se configura un nodo suelto: cualquier cambio afecta a todos los nodos del grupo.
• Cada grupo se crea, actualiza, redimensiona y borra por separado; por defecto usa la versión del plano de control.

gcloud container node-pools create highmem-pool --cluster=CLUSTER \
  --location=us-central1 --machine-type=n2-highmem-4 --service-account=SA_EMAIL
gcloud container clusters resize CLUSTER --node-pool=highmem-pool --num-nodes=2 --location=us-central1
gcloud container node-pools update highmem-pool --cluster=CLUSTER --location=us-central1 ...
gcloud container node-pools delete highmem-pool --cluster=CLUSTER --location=us-central1

Cluster autoscaler

Ajusta automáticamente el número de nodos de un grupo entre un mínimo y un máximo. Se basa en las peticiones de recursos de los Pods, no en su uso real:

• Si hay Pods que no caben en ningún nodo (unschedulable), añade nodos.
• Si los nodos están infrautilizados y todos los Pods caben en menos nodos, quita nodos hasta el mínimo.
• --min-nodes/--max-nodes son por zona; --total-min-nodes/--total-max-nodes son para todo el grupo.
• Al quitar nodos los Pods se reprograman: Google recomienda usar controladores con varias réplicas, como un Deployment.
• En Autopilot no hace falta: los nodos se aprovisionan y escalan solos.

gcloud container node-pools update default-pool --cluster=CLUSTER --location=us-central1 \
  --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

Recursos de Kubernetes

En un StatefulSet, las IP de las réplicas pueden cambiar si GKE reprograma un Pod: hay que usar Services en lugar de IP fijas. Para aplicaciones sin estado, Google indica usar Deployments.

Tipos de Service

Horizontal Pod Autoscaler

Aumenta o reduce el número de Pods de una carga. No cambia el número de nodos: para eso está el cluster autoscaler.

• Para usar porcentajes de CPU o memoria, todos los contenedores deben tener peticiones de ese recurso; si no, el HPA no actúa sobre esa métrica.
• Con varias métricas, evalúa cada una por separado y calcula la escala para cada una.
• Google desaconseja usar el HPA y el VPA estándar a la vez sobre CPU o memoria.

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10
kubectl get hpa
kubectl scale deployment nginx --replicas=3   # escalado manual

Vertical Pod Autoscaler

Analiza el uso histórico y ajusta las peticiones y límites de CPU y memoria de los contenedores. Funciona mejor con cargas homogéneas de larga duración; para picos repentinos Google recomienda el HPA. Está activado por defecto en los clústeres Autopilot.

La implementación de GKE tiene en cuenta el tamaño máximo de nodo y las cuotas, avisa al cluster autoscaler y usa datos históricos de antes de activarlo.

Peticiones de recursos en Autopilot

En Autopilot se paga por lo que piden los Pods, así que las peticiones importan. Autopilot usa esas peticiones para configurar los nodos y las valida:

• Si no indicas peticiones, aplica valores por defecto: en las clases General-purpose, Balanced y Scale-Out, 0,5 vCPU y 2 GiB de memoria; 1 GiB de almacenamiento efímero para los contenedores normales. Los contenedores de DaemonSets reciben 50 mCPU, 100 MiB de memoria y 100 MiB de almacenamiento efímero.
• Si las peticiones están por debajo del mínimo, Autopilot las sube automáticamente.
• Si están por encima del máximo, rechaza la carga con un error.
• Los mínimos y máximos dependen de la clase de cómputo o del hardware (por ejemplo, GPU). Si indicas solo CPU o solo memoria, completa la otra según la proporción permitida.
• Google recomienda fijar las peticiones de cada contenedor de forma explícita, porque los valores por defecto pueden no bastar.

Actualizaciones y reparto de tráfico

Escenarios de examen

Trampas frecuentes del examen