Coloca Pods de GKE en zonas específicas

Autopilot estándar

En esta página, se muestra cómo indicarle a Google Kubernetes Engine (GKE) que ejecute tus Pods en nodos en Google Cloud zonas específicas con la topología zonal. Este tipo de posición es útil en situaciones como las siguientes:

• Los Pods deben acceder a los datos almacenados en un disco persistente zonal de Compute Engine.
• Los Pods deben ejecutarse junto con otros recursos zonales como las instancias de Cloud SQL.

También puedes usar la ubicación zonal con enrutamiento de tráfico adaptado a la topología para reducir la latencia entre los clientes y las cargas de trabajo. Para obtener detalles sobre el enrutamiento de tráfico adaptado de la topología, consulta Enrutamiento compatible con la topología.

Usar la topología zonal para controlar la ubicación de Pods es un mecanismo avanzado de Kubernetes que solo debes usar si tu situación requiere que los Pods se ejecuten en zonas específicas. En la mayoría de los entornos de producción, recomendamos que uses recursos regionales, que es el valor predeterminado de GKE, cuando sea posible.

Métodos de posición zonal

La topología zonal está integrada en Kubernetes con la etiqueta de nodo topology.kubernetes.io/zone: ZONE. Para indicarle a GKE que coloque un Pod en una zona específica, usa uno de los siguientes métodos:

• nodeAffinity: Especifica una regla de nodeAffinity en la especificación del Pod para una o más zonas de Google Cloud . Este método es más flexible que un nodeSelector porque te permite colocar Pods en varias zonas.

• nodeSelector: Especifica un nodeSelector en tu especificación de Pod para una sola zona Google Cloud .

• Clases de procesamiento: Configura tu Pod para que use una clase de procesamiento de GKE. Este enfoque te permite definir una lista priorizada de conjuntos de zonas Google Cloud . Permite que la carga de trabajo se mueva de forma dinámica al conjunto de zonas más preferido cuando hay nodos disponibles en estas zonas. Para obtener más información, consulta Acerca de las clases de procesamiento personalizadas.

Consideraciones

La posición de Pod zonal mediante topología zonal tiene las siguientes consideraciones:

• El clúster debe estar en la misma Google Cloud región que las zonas solicitadas.
• En los clústeres Standard, debes usar el aprovisionamiento automático de nodos o crear grupos de nodos con nodos en las zonas solicitadas. Los clústeres de Autopilot administran este proceso de forma automática.
• Los clústeres de Standard deben ser clústeres regionales.

Precios

La topología zonal es una función de programación de Kubernetes y se ofrece sin costo adicional en GKE.

Para obtener detalles sobre los precios, consulta Precios de GKE.

Antes de comenzar

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

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste la gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de la gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras 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 debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

• Asegúrate de tener un clúster de GKE existente en la mismaGoogle Cloud región que las zonas en las que deseas colocar tus Pods. Para crear un clúster nuevo, consulta Crea un clúster de Autopilot.

Coloca Pods en varias zonas mediante nodeAffinity

El nodo afinidad de Kubernetes de Kubernetes proporciona un mecanismo de control de programación flexible que admite varios selectores de etiquetas y operadores lógicos. Usa nodeAffinity si deseas permitir que los Pods se ejecuten en un conjunto de zonas (por ejemplo, en us-central1-a o us-central1-f).

1. Guarda el siguiente manifiesto como multi-zone-affinity.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deployment
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-multi-zone
     template:
       metadata:
         labels:
           app: nginx-multi-zone
       spec:
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: topology.kubernetes.io/zone
                   operator: In
                   values:
                   - us-central1-a
                   - us-central1-f
   

   En este manifiesto, se crea una implementación con tres réplicas y se colocan los Pods en us-central1-a o us-central1-f según la disponibilidad del nodo.

   Asegúrate de que tu clúster esté en la región us-central1. Si tu clúster está en una región diferente, cambia las zonas en el campo de valores del manifiesto por zonas válidas en la región de tu clúster.

   Opcional: Si aprovisionas VMs de TPU, usa una zona de IA, como us-central1-ai1a. Las zonas de IA son ubicaciones especializadas y optimizadas para cargas de trabajo de IA/AA dentro de las Google Cloud regiones.

2. Crea el Deployment:

   kubectl create -f multi-zone-affinity.yaml
   

   GKE crea los Pods en nodos en una de las zonas especificadas. Es posible que varios Pods se ejecuten en el mismo nodo. De manera opcional, puedes usar la antiafinidad del Pod para que GKE coloque cada Pod en un nodo independiente.

Coloca Pods en una sola zona con un nodeSelector

Para colocar Pods en una sola zona, usa un nodeSelector en la especificación del Pod. Un nodeSelector es equivalente a una regla de nodeAffinity requiredDuringSchedulingIgnoredDuringExecution que tiene una sola zona especificada.

Precaución: Es posible que los Pods que coloques en una sola zona mediante la topología zonal no estén cubiertos por el Acuerdo de Nivel de Servicio (ANS) de Autopilot, que abarca los Pods de Autopilot en varias zonas. Se sigue aplicando el ANS de Compute Engine.

1. Guarda el siguiente manifiesto como single-zone-selector.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-singlezone
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-singlezone
     template:
       metadata:
         labels:
           app: nginx-singlezone
       spec:
         nodeSelector:
           topology.kubernetes.io/zone: "us-central1-a"
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
   

   Este manifiesto le indica a GKE que coloque todas las réplicas en el Deployment en la zona us-central1-a.

2. Crea el Deployment:

   kubectl create -f single-zone-selector.yaml
   

Prioriza la colocación de Pods en las zonas seleccionadas con una clase de procesamiento

Las clases de procesamiento de GKE proporcionan un mecanismo de control que te permite definir una lista de prioridades de configuración de nodos. Las preferencias zonales te permiten definir las zonas en las que deseas que GKE coloque los Pods.

Precaución: No recomendamos combinar las preferencias zonales en las clases de procesamiento con los métodos anteriores de topología zonal en Kubernetes.

Cómo usar la prioridad de zonas de ubicación

Para definir preferencias zonales en las clases de procesamiento con la prioridad de zonas de ubicación, se requiere la versión 1.33.1-gke.1545000 de GKE o una posterior.

En el siguiente ejemplo, se crea una clase de procesamiento que especifica una lista de zonas preferidas para los Pods.

En estos pasos, se supone que tu clúster está en la región us-central1. Si tu clúster está en una región diferente, cambia los valores de las zonas en el manifiesto por zonas válidas en la región de tu clúster.

1. Guarda el siguiente manifiesto como zones-custom-compute-class.yaml:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: zones-custom-compute-class
   spec:
     priorities:
     - location:
       zones: [us-central1-a, us-central1-b]
     - location:
       zones: [us-central1-c]
     activeMigration:
       optimizeRulePriority: true
     nodePoolAutoCreation:
       enabled: true
     whenUnsatisfiable: ScaleUpAnyway
   

   Este manifiesto de clase de procesamiento cambia el comportamiento de ajuste de escala de la siguiente manera:

   1. GKE intenta colocar los Pods en us-central1-a o en us-central1-b.
   2. Si us-central1-a y us-central1-b no tienen capacidad disponible, GKE intenta colocar los Pods en us-central1-c.
   3. Si us-central1-c no tiene capacidad disponible, el campo whenUnsatisfiable: ScaleUpAnyway hace que GKE coloque los Pods en cualquier zona disponible de la región.
   4. Si una zona que tiene mayor prioridad en la clase de procesamiento está disponible más adelante, el campo activeMigration.optimizeRulePriority: true hace que GKE mueva los Pods a esa zona desde cualquier zona de menor prioridad. Esta migración usa el presupuesto de interrupción de Pods para garantizar la disponibilidad del servicio.

2. Crea la clase de procesamiento personalizada:

   kubectl create -f zones-custom-compute-class.yaml
   

   GKE crea una clase de procesamiento personalizada a la que pueden hacer referencia tus cargas de trabajo.

3. Guarda el siguiente manifiesto como custom-compute-class-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-zonal-preferences
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-zonal-preferences
     template:
       metadata:
         labels:
           app: nginx-zonal-preferences
       spec:
         nodeSelector:
           cloud.google.com/compute-class: "zones-custom-compute-class"
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
   

4. Crea el Deployment:

   kubectl create -f custom-compute-class-deployment.yaml
   

Cómo usar la prioridad de zoneTypes de ubicación

Para definir preferencias zonales en las clases de procesamiento con la prioridad de los tipos de zonas de ubicación, se requiere la versión 1.35.2-gke.1842000 o posterior de GKE. Si seleccionas un tipo de zona para tus pods, según tu configuración, se usará o creará un nuevo grupo de nodos que abarque todas las zonas de un tipo determinado.

Puedes especificar los siguientes tipos de zonas en tu clase de procesamiento:

• STANDARD: Zonas de uso general, Google Cloud en una región. Se recomienda para cargas de trabajo que no son de AA.
• AI: Son zonas especializadas y optimizadas para la capacidad de IA y aceleradores. Se recomiendan para cargas de trabajo de IA/AA.
• CLUSTER_DEFAULT: Son las zonas especificadas en autoprovisioning-locations del clúster (o las ubicaciones del clúster si está vacío).

Para obtener más información sobre las zonas estándar y de IA, consulta Acerca de las zonas de IA.

Restricciones para combinar campos

No puedes combinar el campo zoneTypes con el campo location.zones o el campo reservations.specific en la misma entrada de prioridad. Puedes usar los campos zoneTypes y location.zones en la misma clase de procesamiento, siempre y cuando los coloques en entradas de prioridad separadas.

Además, el campo priorityDefaults se aplica a cada prioridad de la clase de procesamiento. Una consecuencia de esta regla es que establecer el campo zoneTypes en el campo priorityDefaults impide que uses el campo location.zones o el campo reservations.specific en cualquier prioridad.

Ejemplo válido: Prioridades separadas

El siguiente ejemplo es válido porque zones y zoneTypes se especifican en entradas de prioridad separadas:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: valid-zonal-preferences
spec:
  priorities:
  - location:
      zones: [us-central1-a]
  - location:
      zoneTypes: [AI]

Ejemplo no válido: Misma prioridad

El siguiente ejemplo no es válido porque zones y zoneTypes se especifican en la misma entrada de prioridad:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: invalid-same-priority
spec:
  priorities:
  - location:
      zones: [us-central1-a]
      zoneTypes: [AI] # Error: mutually exclusive

Ejemplo no válido: Conflicto con los valores predeterminados

El siguiente ejemplo no es válido porque la configuración del campo zoneTypes en la sección priorityDefaults entra en conflicto con el campo zones en la entrada de prioridad:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: invalid-defaults-conflict
spec:
  priorityDefaults:
    location:
      zoneTypes: [AI]
  priorities:
  - location:
      zones: [us-central1-a] # Error: merges with defaults

Ejemplo de uso

En el siguiente ejemplo, se crea una clase de procesamiento que especifica una lista de tipos de zonas preferidos para los Pods.

1. Guarda el siguiente manifiesto como zone-types-custom-compute-class.yaml:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: zone-types-custom-compute-class
   spec:
     priorities:
     - location:
       zones: [us-central1-c]
     - location:
       zoneTypes:
       - AI
     - location:
       zoneTypes:
       - CLUSTER_DEFAULT
     activeMigration:
       optimizeRulePriority: true
     nodePoolAutoCreation:
       enabled: true
     whenUnsatisfiable: ScaleUpAnyway
   

   Este manifiesto de clase de procesamiento cambia el comportamiento de ajuste de escala de la siguiente manera:

   1. GKE intenta colocar los Pods en la zona us-central1-c.
   2. Si us-central1-c no tiene capacidad disponible, GKE intenta colocar los Pods en cualquier zona AI de la región.
   3. Si ninguna de las zonas AI tiene capacidad disponible, GKE intenta colocar los Pods en cualquiera de las zonas CLUSTER_DEFAULT.
   4. Si ninguna de las zonas CLUSTER_DEFAULT tiene capacidad disponible, el campo whenUnsatisfiable: ScaleUpAnyway hace que GKE coloque los Pods en cualquier zona disponible de la región.
   5. Si una zona que tiene mayor prioridad en la clase de procesamiento está disponible más adelante, el campo activeMigration.optimizeRulePriority: true hace que GKE mueva los Pods a esa zona desde cualquier zona de menor prioridad. Esta migración usa el presupuesto de interrupción de Pods para garantizar la disponibilidad del servicio.

2. Crea la clase de procesamiento personalizada:

   kubectl create -f zone-types-custom-compute-class.yaml
   

   GKE crea una clase de procesamiento personalizada a la que pueden hacer referencia tus cargas de trabajo.

3. Guarda el siguiente manifiesto como custom-compute-class-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-zonal-preferences
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-zonal-preferences
     template:
       metadata:
         labels:
           app: nginx-zonal-preferences
       spec:
         nodeSelector: cloud.google.com/compute-class: "zone-types-custom-compute-class"
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
   

4. Crea el Deployment:

   kubectl create -f custom-compute-class-deployment.yaml
   

Nota: Cuando uses el campo zoneTypes, en especial con un campo reservation.affinity establecido en el valor AnyBestEffort, te recomendamos que establezcas el campo locationPolicy en ANY. Especificar locationPolicy: ANY permite que el orquestador de expansión use indicadores de capacidad en tiempo real para lograr una colocación óptima.

Cómo evalúa el NAP zoneTypes

Cuando se determina si se debe reutilizar un grupo de nodos existente o crear uno nuevo, el aprovisionamiento automático de nodos (NAP) suele requerir una coincidencia exacta entre las zonas existentes del grupo de nodos y tu zoneTypes solicitado. Si actualizas una prioridad para incluir tipos de zonas más amplios (p.ej., pasar de [AI] a [AI, STANDARD]), NAP aprovisionará un nuevo grupo de nodos para que coincida con la nueva forma exacta.

Nota: Debido a que las configuraciones de colocación compacta y de varios hosts de TPU son estrictamente de una sola zona, siguen una regla diferente. NAP reutilizará un grupo de nodos de una sola zona existente siempre que su zona sea un subconjunto de los zoneTypes seleccionados. No intentará crear un grupo de nodos nuevo solo porque la prioridad define un rango más amplio de zonas aceptables.

Recorte que tiene en cuenta el tipo de máquina

Si un tipo de máquina (como h3-standard-88) solo está disponible en un subconjunto de las zonas definidas por un tipo (por ejemplo, solo en us-central1-a), GKE recorta automáticamente la lista de ubicaciones del grupo de nodos para incluir solo las zonas en las que ese hardware está físicamente presente.

Zonas de IA objetivo

Las zonas de IA son zonas especializadas que se usan para cargas de trabajo de inferencia y entrenamiento de IA/AA. Estas zonas proporcionan una capacidad significativa de aceleradores de AA. Para obtener más información, consulta la documentación de las zonas de IA.

En este documento y en la documentación de GKE, las "zonas estándar" o "zonas" hacen referencia a las zonas que no son de IA dentro de una región de Google Cloud .

Importante: El acceso a las zonas de IA está restringido, a menos que las hayas habilitado para tu proyecto deGoogle Cloud . Para usarlas, habilita las zonas de IA (vista previa).

Antes de usar una zona de IA en GKE, ten en cuenta las siguientes características:

• Las zonas de IA están separadas físicamente de las zonas estándar para proporcionar más espacio de almacenamiento y energía. Esta separación puede generar una latencia más alta, que suele ser tolerable para las cargas de trabajo de IA/AA.
• Las zonas de IA tienen un sufijo con la notación ai. Por ejemplo, una zona de IA en la región us-central1 se llama us-central1-ai1a.
• Actualmente, solo se admiten las VMs de TPU.
• El plano de control del clúster se ejecuta en una o más zonas estándar dentro de la misma región que la zona de IA.

• Solo puedes ejecutar VMs sin TPUs adjuntas en una zona de IA si cumples con los siguientes requisitos:

  • Ya ejecutas otras cargas de trabajo que usan VMs de TPU en la misma zona.
  • Las VMs que no son de TPU son VMs Spot, están vinculadas a una reserva o forman parte de un grupo de nodos con una proporción específica de VM de uso general por acelerador.
  Nota: Incluso si GKE te permite crear el grupo de nodos, Compute Engine aprovisiona las VMs solo si se cumplen estas condiciones. Para obtener más información, consulta Zonas de IA.

• Las zonas de IA comparten componentes, como conexiones de red y lanzamientos de software, con las zonas estándar que tienen el mismo sufijo dentro de la misma región. Para las cargas de trabajo de alta disponibilidad, te recomendamos que uses diferentes zonas. Por ejemplo, evita usar us-central1-ai1a y us-central1-a para la alta disponibilidad.

De forma predeterminada, GKE no implementa tus cargas de trabajo en zonas de IA. Para usar una zona de IA, debes configurar una de las siguientes opciones:

• (Recomendado) ComputeClasses: Establece tu prioridad más alta para solicitar TPU bajo demanda en una zona de IA. ComputeClasses te ayuda a definir una lista priorizada de configuraciones de hardware para tus cargas de trabajo. Para ver un ejemplo, consulta Acerca de ComputeClasses.
• Aprovisionamiento automático de nodos: Usa un nodeSelector o un nodeAffinity en la especificación del Pod para indicarle al aprovisionamiento automático de nodos que cree un grupo de nodos en la zona de IA. Si tu carga de trabajo no se orienta de forma explícita a una zona de IA, el aprovisionamiento automático de nodos solo considera las zonas estándar o las zonas de --autoprovisioning-locations cuando crea grupos de nodos nuevos. Esta configuración ayuda a garantizar que las cargas de trabajo que no ejecutan modelos de IA/AA permanezcan en zonas estándar, a menos que configures explícitamente lo contrario. Para ver un ejemplo de un manifiesto que usa un nodeSelector, consulta Cómo establecer las zonas predeterminadas para los nodos creados automáticamente.
• GKE Standard: Si administras directamente tus grupos de nodos, usa una zona de IA en la marca --node-locations cuando crees un grupo de nodos. Para ver un ejemplo, consulta Implementa cargas de trabajo de TPU en GKE Standard.

Verifica la posición del Pod

Para verificar la ubicación de los Pods, enumera los Pods y verifica las etiquetas de los nodos. Es posible que varios Pods se ejecuten en un solo nodo, por lo que es posible que no veas Pods distribuidos en varias zonas si usaste nodeAffinity.

1. Enumera los Pods:

   kubectl get pods -o wide
   

   El resultado es una lista de Pods en ejecución y el nodo de GKE correspondiente.

2. Describe los nodos:

   kubectl describe node NODE_NAME | grep "topology.kubernetes.io/zone"
   

   Reemplaza NODE_NAME por el nombre del conjunto de datos.

   El resultado es similar a este:

   topology.kubernetes.io/zone: us-central1-a
   

Si deseas que GKE distribuya tus Pods de manera uniforme entre varias zonas para mejorar la conmutación por error en varios dominios con fallas, usa topologySpreadConstraints.

¿Qué sigue?

• Cargas de trabajo independientes de GKE entre sí
• Mantén el tráfico de red en la misma topología que el nodo
• Distribuye Pods en varios dominios con fallas