Configura la separación de cargas de trabajo en GKE

Autopilot Estándar

---

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

La separación de cargas de trabajo te permite usar taints y tolerancias para indicarle a GKE que separe los Pods en diferentes nodos y colocarlos en los nodos que cumplan con criterios específicos o para programar cargas de trabajo específicas. Lo que necesitas 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	Agrega una tolerancia para un par clave-valor específico a tu especificación de Pod y selecciona ese par clave-valor con un nodeSelector. GKE crea nodos, aplica el taint de nodo correspondiente y programa el Pod en el nodo. Para obtener instrucciones, consulta Cargas de trabajo independientes en clústeres de Autopilot en esta página.
Estándar sin aprovisionamiento automático de nodos	Crea un grupo de nodos con un taint de nodo y una etiqueta de nodo Agrega una tolerancia para ese taint 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 con taints existentes no tienen suficientes recursos para admitir un Pod con una tolerancia, el Pod permanece en estado Pendiente.

En esta guía, se usa una situación de ejemplo en la que tienes dos cargas de trabajo, un trabajo por lotes y un servidor web, que deseas separar entre sí.

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 realizan diferentes funciones y no deben ejecutarse en las mismas máquinas subyacentes. A continuación, se muestran algunas situaciones de ejemplo:

• Tienes una carga de trabajo de coordinador por lotes que crea trabajos que deseas mantener separados.
• Ejecutas un servidor para videojuegos con una carga de trabajo de creación de partidas que deseas separar de los Pods de la sesión.
• Deseas separar partes de la pila entre sí, como separar un servidor de una base de datos.
• Deseas separar algunas cargas de trabajo por motivos de cumplimiento o de políticas.

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

Precios

En los clústeres de Autopilot, se te factura por los recursos que los Pods solicitan mientras se ejecutan. Para obtener más información, consulta Precios de Autopilot. Los Pods que usan la separación de cargas de trabajo tienen solicitudes de recursos mínimas más altas que los Pods normales.

En los clústeres estándar, se te factura según la configuración de hardware y el tamaño de cada nodo, sin importar si los Pods se ejecutan en los nodos. Para obtener más información, consulta Precios de estándar.

Antes de comenzar

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

• Habilita la API de Kubernetes Engine de Google.
Habilitar la API de Kubernetes Engine de Google
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

• Asegúrate de tener un clúster de GKE en ejecución. Para aprender a crear un clúster, usa una de las siguientes opciones:

  • Crea un clúster de Autopilot (recomendado)
  • Crea un clúster de Standard con aprovisionamiento automático de nodos
  • Crea un clúster estándar

Cargas de trabajo independientes en clústeres de Autopilot

Para separar las cargas de trabajo, agrega una tolerancia y un selector de nodos a cada especificación de carga de trabajo que defina el nodo en el que debe ejecutarse 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 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 los nodos que tienen 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 los nodos que tienen la etiqueta de nodo group: servers.

   GKE agrega las etiquetas y los taints correspondientes a los nodos que GKE aprovisiona de forma automática para ejecutar estos Pods.

2. Guarda el siguiente 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 los nodos que tienen 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 los nodos que tienen la etiqueta de nodo group: jobs.

   GKE agrega las etiquetas y los taints correspondientes a los nodos que GKE aprovisiona de forma automática para ejecutar estos Pods.

3. Implementa las cargas de trabajo:

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

Cuando implementas las cargas de trabajo, GKE hace lo siguiente para cada carga de trabajo:

1. GKE busca nodos existentes que tengan el taint de nodo y la etiqueta de nodo correspondientes especificados en el manifiesto. Si los nodos existen y tienen recursos disponibles, GKE programa la carga de trabajo en el nodo.
2. Si GKE no encuentra un nodo existente apto para programar la carga de trabajo, GKE crea un nodo nuevo y aplica el taint y la etiqueta de nodo correspondientes en función del manifiesto. GKE coloca el Pod en el nodo nuevo.

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

Verifica la separación de la carga de trabajo

Enumera tus Pods para encontrar los nombres de los nodos:

kubectl get pods --output=wide

El resultado es similar a este:

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

En este resultado, se 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 taints y tolerancias

No puedes usar los siguientes prefijos de clave para la separación de carga 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 la separación de cargas de trabajo.

Cargas de trabajo independientes en clústeres estándar sin aprovisionamiento automático de nodos

Separar las cargas de trabajo en clústeres estándar sin aprovisionamiento automático de nodos requiere que crees grupos de nodos de forma manual con las taints y las etiquetas de nodo adecuadas para adaptar tus cargas de trabajo. Para obtener instrucciones, consulta Aísla tus cargas de trabajo en grupos de nodos dedicados. Usa este enfoque solo si tienes requisitos específicos que requieren que administres tus grupos de nodos de forma manual.

¿Qué sigue?

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