Esta página se ha traducido con Cloud Translation API.

Colocar pods de GKE en zonas específicas

Autopilot Standard

En esta página se explica cómo indicar a Google Kubernetes Engine (GKE) que ejecute tus pods en nodos de zonas específicas mediante la topología zonal. Google Cloud Este tipo de emplazamiento es útil en situaciones como las siguientes:

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

También puedes usar la colocación zonal con el enrutamiento de tráfico basado en la topología para reducir la latencia entre los clientes y las cargas de trabajo. Para obtener información sobre el enrutamiento de tráfico en función de la topología, consulta Enrutamiento en función de la topología.

Usar la topología zonal para controlar la colocación de pods es un mecanismo avanzado de Kubernetes que solo debes usar si necesitas que los pods se ejecuten en zonas específicas. En la mayoría de los entornos de producción, te recomendamos que utilices recursos regionales, que es el valor predeterminado de GKE, siempre que sea posible.

Métodos de emplazamiento por zonas

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

nodeAffinity: especifica una regla nodeAffinity en la especificación de tu pod para una o varias Google Cloud zonas. Este método es más flexible que nodeSelector porque te permite colocar pods en varias zonas.
nodeSelector: especifica un nodeSelector en la especificación de tu pod para una sola Google Cloud zona.
Clases de computación: configura tu pod para que use una clase de computación de GKE. Este enfoque te permite definir una lista priorizada de conjuntos de Google Cloud zonas. Permite que la carga de trabajo se mueva de forma dinámica al conjunto de zonas preferido cuando haya nodos disponibles en esas zonas. Para obtener más información, consulta el artículo Acerca de las clases de cálculo personalizadas.

Cuestiones importantes

La colocación de pods zonales mediante la 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 estándar, debes usar el aprovisionamiento automático de nodos o crear grupos de nodos con nodos en las zonas solicitadas. Los clústeres de Autopilot gestionan este proceso automáticamente.
Los clústeres estándar deben ser clústeres regionales.

Precios

La topología de zona es una función de programación de Kubernetes que se ofrece sin coste adicional en GKE.

Para obtener más información sobre los precios, consulta la página Precios de GKE.

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 que tienes un clúster de GKE en la misma región que las zonas en las que quieres colocar tus pods.Google Cloud Para crear un clúster, consulta Crear un clúster de Autopilot.

Colocar pods en varias zonas con nodeAffinity

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

Guarda el siguiente archivo de 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

Este manifiesto crea un Deployment con tres réplicas y coloca los pods en us-central1-a o us-central1-f en función de la disponibilidad de los nodos.

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

Crea el despliegue:
```
kubectl create -f multi-zone-affinity.yaml
```
GKE crea los pods en nodos de una de las zonas especificadas. Es posible que se ejecuten varios pods en el mismo nodo. También puedes usar la antiafinidad de pods para indicar a GKE que coloque cada pod en un nodo independiente.

Colocar pods en una sola zona mediante un nodeSelector

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

Guarda el siguiente archivo de 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 indica a GKE que coloque todas las réplicas del despliegue en la zona us-central1-a.

Crea el despliegue:

kubectl create -f single-zone-selector.yaml

Priorizar la colocación de pods en zonas seleccionadas mediante una clase de computación

Las clases de computación 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 quieres que GKE coloque los pods. Para definir preferencias zonales en clases de computación, se necesita la versión 1.33.1-gke.1545000 o posterior de GKE.

En el siguiente ejemplo se crea una clase de cálculo que especifica una lista de zonas preferidas para los pods.

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

Guarda el siguiente archivo de 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 computación cambia el comportamiento de escalado 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 una prioridad más alta en la clase de computación 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 asegurar la disponibilidad del servicio.
Crea la clase de computación personalizada:
```
kubectl create -f zones-custom-compute-class.yaml
```
GKE crea una clase de computación personalizada a la que pueden hacer referencia tus cargas de trabajo.

Guarda el siguiente archivo de 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 despliegue:

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

Verificar la colocación del Pod

Para verificar la colocación de los pods, enumera los pods y comprueba las etiquetas de los nodos. Es posible que se ejecuten varios pods en un solo nodo, por lo que puede que no veas pods distribuidos en varias zonas si has usado nodeAffinity.

Enumera tus 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"

Sustituye NODE_NAME por el nombre del nodo.

El resultado debería ser similar al siguiente:

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

Si quieres que GKE distribuya tus pods de forma uniforme en varias zonas para mejorar la conmutación por error en varios dominios de error, usa topologySpreadConstraints.