Colocar pods do GKE em zonas específicas

Nesta página, mostramos como instruir o Google Kubernetes Engine (GKE) a executar pods em nós em zonas específicas do Google Cloud usando a topologia zonal. Esse tipo de posicionamento é útil em situações como as seguintes:

  • Os pods precisam acessar dados armazenados em um disco permanente zonal do Compute Engine.
  • Os pods precisam ser executados com outros recursos zonais, como instâncias do Cloud SQL.

Também é possível usar a colocação zonal com roteamento de tráfego com reconhecimento de topologia para reduzir a latência entre clientes e cargas de trabalho. Para detalhes sobre o roteamento de tráfego com reconhecimento de topologia, consulte Roteamento ciente de topologia.

O uso de topologia zonal para controlar a colocação de pods é um mecanismo avançado do Kubernetes que só deve ser usado se a situação exigir que os pods sejam executados em zonas específicas. Na maioria dos ambientes de produção, recomendamos o uso de recursos regionais, que é o padrão do GKE, quando possível.

Métodos de posicionamento por zona

A topologia zonal é integrada ao Kubernetes com o rótulo de nó topology.kubernetes.io/zone: ZONE. Para instruir o GKE a colocar um pod em uma zona específica, use um dos seguintes métodos:

  • nodeAffinity: especifica uma regra de nodeAffinity na especificação do pod para uma ou mais zonas do Google Cloud. Esse método é mais flexível que um nodeSelector porque permite colocar pods em várias zonas.
  • nodeSelector: especifique um nodeSelector na especificação do pod para uma única zona do Google Cloud.

Considerações

O posicionamento do pod zonal usando a topologia zonal tem as seguintes considerações:

  • O cluster precisa estar na mesma região do Google Cloud que as zonas solicitadas.
  • Em clusters padrão, é preciso usar o provisionamento automático de nós ou criar pools de nós com zonas nas zonas solicitadas. Os clusters do Autopilot gerenciam esse processo automaticamente para você.
  • Os clusters padrão precisam ser regionais.

Preços

A topologia zonal é um recurso de programação do Kubernetes e é oferecida sem nenhum custo extra no GKE.

Para detalhes sobre preços, consulte Preços do GKE.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
  • Verifique se você tem um cluster do GKE na mesma região do Google Cloud que as zonas em que quer colocar os pods. Para criar um novo cluster do Autopilot, consulte Criar um cluster do Autopilot.

Colocar pods em várias zonas usando nodeAffinity

O nodeAffinity do Kubernetes fornece um mecanismo de controle de programação flexível compatível com vários seletores de rótulos e operadores lógicos. Use nodeAffinity se quiser permitir que os pods sejam executados em uma de um conjunto de zonas (por exemplo, em us-central1-a ou us-central1-f).

  1. Salve o seguinte manifesto 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

    Esse manifesto cria uma implantação com três réplicas e coloca os pods em us-central1-a ou us-central1-f com base na disponibilidade do nó.

    Verifique se o cluster está na região us-central1. Se o cluster estiver em uma região diferente, altere as zonas no campo de valores do manifesto para zonas válidas na região do cluster.

  2. Crie a implantação:

    kubectl create -f multi-zone-affinity.yaml

    O GKE cria os pods em nós em uma das zonas especificadas. Vários pods podem ser executados no mesmo nó. Opcionalmente, é possível usar a antiafinidade de pods para instruir o GKE a colocar cada pod em um nó separado.

Colocar pods em uma única zona usando um nodeSelector

Para colocar pods em uma única zona, use um nodeSelector na especificação do pod. Um nodeSelector é equivalente a uma regra de nodeAffinity requiredDuringSchedulingIgnoredDuringExecution que tem uma única zona especificada.

  1. Salve o seguinte manifesto 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

    Esse manifesto informa ao GKE para colocar todas as réplicas na implantação na zona us-central1-a.

  2. Crie a implantação:

    kubectl create -f single-zone-selector.yaml

Verificar o posicionamento do pod

Para verificar o posicionamento do pod, liste os pods e verifique os rótulos dos nós. Vários pods podem ser executados em um único nó. Portanto, talvez você não veja pods espalhados por várias zonas se tiver usado nodeAffinity.

  1. Liste os pods:

    kubectl get pods -o wide

    A saída é uma lista de pods em execução e o nó do GKE correspondente.

  2. Descreva os nós:

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

    Substitua NODE_NAME pelo nome do nó.

    O resultado será assim:

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

Se você quiser que o GKE distribua os pods uniformemente entre várias zonas para melhorar o failover em vários domínios de falha, use topologySpreadConstraints.

A seguir