Configurar la separación de cargas de trabajo en GKE

Autopilot Standard

---

En esta página se explica cómo indicar a Google Kubernetes Engine (GKE) que programe tus pods juntos, por separado o en ubicaciones específicas.

La separación de cargas de trabajo te permite usar intolerancias y tolerancias para indicar a GKE que separen los pods en diferentes nodos, que coloquen los pods en nodos que cumplan criterios específicos o que programen cargas de trabajo específicas juntas. Lo que debes hacer para configurar la separación de cargas de trabajo depende de la configuración de tu clúster de GKE. En la siguiente tabla se describen las diferencias:

Configuración de la separación de cargas de trabajo
Autopilot Estándar con aprovisionamiento automático de nodos	Añade una tolerancia para un par clave-valor específico a la especificación de tu pod y selecciona ese par clave-valor mediante un nodeSelector. GKE crea nodos, aplica el taint de nodo correspondiente y programa el pod en el nodo. Para obtener instrucciones, consulta la sección Separar cargas de trabajo en clústeres de Autopilot de esta página.
Estándar sin aprovisionamiento automático de nodos	Crear un grupo de nodos con un taint y una etiqueta de nodo Añade una tolerancia para esa intolerancia a la especificación del pod Para obtener instrucciones, consulta Aísla tus cargas de trabajo en grupos de nodos dedicados. Precaución: Con este método, si los nodos dañados no tienen suficientes recursos para admitir un pod con una tolerancia, el pod permanecerá en el estado Pending.

En esta guía se usa un ejemplo en el que tienes dos cargas de trabajo (un trabajo por lotes y un servidor web) que quieres separar.

Cuándo usar la separación de cargas de trabajo en GKE

La separación de cargas de trabajo es útil cuando tienes cargas de trabajo que desempeñan funciones diferentes y no deberían ejecutarse en las mismas máquinas subyacentes. Estos son algunos ejemplos de situaciones:

• Tienes una carga de trabajo de coordinador de lote que crea trabajos que quieres mantener separados.
• Tienes un servidor de juegos con una carga de trabajo de emparejamiento que quieres separar de los pods de sesión.
• Quieres separar partes de tu pila, como un servidor de una base de datos.
• Quieres separar algunas cargas de trabajo por motivos de cumplimiento o de políticas.

Advertencia: La separación de cargas de trabajo nunca debe usarse como límite de seguridad principal. No es un método para aislar cargas de trabajo no fiables y no mitiga todas las rutas de escalada. La separación de cargas de trabajo no se debe usar como mecanismo de defensa. Para obtener información sobre los riesgos de usar la programación de Kubernetes como método de aislamiento, consulta Evitar ataques de escalada de privilegios.

Precios

En los clústeres Autopilot, se te facturan los recursos que solicitan tus pods mientras se ejecutan. Para obtener más información, consulta los precios de Autopilot. Los pods que usan la separación de cargas de trabajo tienen solicitudes de recursos mínimos más altas que los pods normales.

En los clústeres estándar, se te cobra en función de la configuración de hardware y el tamaño de cada nodo, independientemente de si los pods se están ejecutando en los nodos. Para obtener más información, consulta los precios estándar.

Antes de empezar

Antes de empezar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
  Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

• Asegúrate de tener un clúster de GKE. Para saber cómo crear un clúster, utiliza una de las siguientes opciones:

  • Crear un clúster de Autopilot (opción recomendada)
  • Crear un clúster estándar con aprovisionamiento automático de nodos
  • Crear un clúster estándar

Separar cargas de trabajo en clústeres de Autopilot

Para separar las cargas de trabajo entre sí, añade una tolerancia y un selector de nodos a cada especificación de carga de trabajo que defina el nodo en el que se debe ejecutar la carga de trabajo. Este método también funciona en clústeres estándar que tienen habilitado el aprovisionamiento automático de nodos.

1. Guarda el siguiente archivo de manifiesto como web-server.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-server
   spec:
     replicas: 6
     selector:
       matchLabels:
         pod: nginx-pod
     template:
       metadata:
         labels:
           pod: nginx-pod
       spec:
         tolerations:
         - key: group
           operator: Equal
           value: "servers"
           effect: NoSchedule
         nodeSelector:
           group: "servers"
         containers:
         - name: web-server
           image: nginx
   

   Este manifiesto incluye los siguientes campos:

   • spec.tolerations: GKE puede colocar los pods en nodos que tengan el taint group=servers:NoSchedule. GKE no puede programar pods que no tengan esta tolerancia en esos nodos.
   • spec.nodeSelector: GKE debe colocar los pods en nodos que tengan la etiqueta de nodo group: servers.

   GKE añade las etiquetas y las intolerancias correspondientes a los nodos que aprovisiona automáticamente para ejecutar estos pods.

2. Guarda el siguiente archivo de manifiesto como batch-job.yaml:

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: batch-job
   spec:
     completions: 5
     backoffLimit: 3
     ttlSecondsAfterFinished: 120
     template:
       metadata:
         labels:
           pod: pi-pod
       spec:
         restartPolicy: Never
         tolerations:
         - key: group
           operator: Equal
           value: "jobs"
           effect: NoSchedule
         nodeSelector:
           group: "jobs"
         containers:
         - name: pi
           image: perl
           command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
   

   Este manifiesto incluye los siguientes campos:

   • spec.tolerations: GKE puede colocar los pods en nodos que tengan el taint group=jobs:NoSchedule. GKE no puede programar pods que no tengan esta tolerancia en esos nodos.
   • spec.nodeSelector: GKE debe colocar los pods en nodos que tengan la etiqueta de nodo group: jobs.

   GKE añade las etiquetas y las intolerancias correspondientes a los nodos que aprovisiona automáticamente para ejecutar estos pods.

3. Despliega las cargas de trabajo:

   kubectl apply -f batch-job.yaml web-server.yaml
   

Cuando despliega las cargas de trabajo, GKE hace lo siguiente con cada una de ellas:

1. GKE busca nodos que tengan el taint de nodo y la etiqueta de nodo correspondientes especificados en el manifiesto. Si existen nodos y tienen recursos disponibles, GKE programa la carga de trabajo en el nodo.
2. Si GKE no encuentra un nodo apto para programar la carga de trabajo, crea un nodo y aplica el taint y la etiqueta de nodo correspondientes según el manifiesto. GKE coloca el pod en el nuevo nodo.

La presencia del efecto NoSchedule en el taint del nodo asegura que las cargas de trabajo sin tolerancia no se coloquen en el nodo.

Verificar la separación de las cargas de trabajo

Lista tus pods para encontrar los nombres de los nodos:

kubectl get pods --output=wide

El resultado debería ser similar al siguiente:

NAME                          READY   ...   NODE
batch-job-28j9h               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-78rcn               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-gg4x2               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-qgsxh               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-v4ksf               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
web-server-6bb8cd79b5-dw4ds   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm
web-server-6bb8cd79b5-g5ld6   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-jcdx5   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-pxdzw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-s66rw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-zq8hh   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm

Esta salida muestra que los pods batch-job y web-server siempre se ejecutan en nodos diferentes.

Limitaciones de la separación de cargas de trabajo con tolerancias y taints

No puedes usar los siguientes prefijos de clave para separar las cargas de trabajo:

• Claves específicas de GKE y Kubernetes
• *cloud.google.com/
• *kubelet.kubernetes.io/
• *node.kubernetes.io/

Debes usar tus propias claves únicas para separar las cargas de trabajo.

Separar cargas de trabajo en clústeres estándar sin aprovisionamiento automático de nodos

Para separar las cargas de trabajo en clústeres estándar sin aprovisionamiento automático de nodos, debes crear manualmente grupos de nodos con las etiquetas y los taints de nodo adecuados para tus cargas de trabajo. Para obtener instrucciones, consulta Aísla tus cargas de trabajo en grupos de nodos dedicados. Utiliza este método solo si tienes requisitos específicos que te obliguen a gestionar manualmente tus grupos de nodos.

Crear un clúster con taints de nodos

Cuando creas un clúster en GKE, puedes asignarle taints de nodo. De esta forma, se asignan los taints a todos los nodos creados con el clúster.

Si creas un grupo de nodos, este no hereda los taints del clúster. Si quieres aplicar taints al grupo de nodos, debes usar la marca --node-taints al crear el grupo de nodos.

Si creas un clúster estándar con taints de nodo que tengan el efecto NoSchedule o NoExecute, GKE no podrá programar algunos componentes gestionados de GKE, como kube-dns o metrics-server, en el grupo de nodos predeterminado que GKE crea al crear el clúster. GKE no puede programar estos componentes porque no tienen las tolerancias correspondientes a las intolerancias de tus nodos. Debes añadir un grupo de nodos que cumpla una de las siguientes condiciones:

• No hay intolerancias
• Un taint que tiene el efecto PreferNoSchedule
• La intolerancia components.gke.io/gke-managed-components=true:NoSchedule

Cualquiera de estas condiciones permite a GKE programar componentes gestionados de GKE en el nuevo grupo de nodos.

Para obtener instrucciones, consulta el artículo Aislar cargas de trabajo en nodos dedicados.

gcloud

Crea un clúster con etiquetas de nodo:

gcloud container clusters create CLUSTER_NAME \
    --node-taints KEY=VALUE:EFFECT

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del nuevo clúster.
• EFFECT: uno de los siguientes efectos: PreferNoSchedule, NoSchedule o NoExecute.
• KEY=VALUE: par clave-valor asociado a EFFECT.

Consola

Crea un clúster con etiquetas de nodo:

1. En la Google Cloud consola, ve a la página Crear un clúster de Kubernetes.

   Ir a Crear un clúster de Kubernetes

2. Configura el clúster a tu gusto.

3. En el panel de navegación, vaya a Grupos de nodos, despliegue el grupo de nodos que quiera modificar y, a continuación, haga clic en Metadatos.

4. En la sección Taints de nodo, haz clic en Añadir taint.

5. En la lista desplegable Efecto, selecciona el efecto que quieras.

6. Introduce el par clave-valor que quieras en los campos Clave y Valor.

7. Haz clic en Crear.

API

Cuando uses la API para crear un clúster, incluye el campo nodeTaints en `nodeConfig:

POST https://container.googleapis.com/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/clusters

{
  'cluster': {
    'name': 'example-cluster',
    'nodeConfig': {
      'nodeTaints': [
        {
          'key': 'special',
          'Value': 'gpu',
          'effect': 'PreferNoSchedule'
        }
      ]
      ...
    }
    ...
  }
}

Quitar todas las marcas de un grupo de nodos

Para quitar todas las marcas de un grupo de nodos, ejecuta el siguiente comando:

gcloud beta container node-pools update POOL_NAME \
    --node-taints="" \
    --cluster=CLUSTER_NAME

Haz los cambios siguientes:

• POOL_NAME: el nombre del grupo de nodos que se va a cambiar.
• CLUSTER_NAME: el nombre del clúster del grupo de nodos.

Siguientes pasos

• Aplicar políticas de seguridad predefinidas mediante el controlador de admisión PodSecurity
• Ejecutar una carga de trabajo de pila completa a gran escala