Se usó la API de Cloud Translation para traducir esta página.

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 esas 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 gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de 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).

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.

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.

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.

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. Para definir preferencias zonales en las clases de procesamiento, se requiere la versión 1.33.1-gke.1545000 o posterior de GKE.

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.

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 más adelante está disponible una zona que tiene mayor prioridad en la clase de procesamiento, 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.
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.

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

Crea el Deployment:

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

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.

Enumera los Pods:
```
kubectl get pods -o wide
```
El resultado es una lista de Pods en ejecución y el nodo de GKE correspondiente.

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.