Esta página foi traduzida pela API Cloud Translation.

Coloque pods do GKE em zonas específicas

Autopilot Padrão

Esta página mostra como indicar ao Google Kubernetes Engine (GKE) para executar os seus pods em nós em zonas específicas através da topologia zonal. Google Cloud Este tipo de posicionamento é útil em situações como as seguintes:

Os pods têm de aceder a dados armazenados num disco persistente do Compute Engine zonal.
Os pods têm de ser executados juntamente com outros recursos zonais, como instâncias do Cloud SQL.

Também pode usar o posicionamento zonal com o encaminhamento de tráfego com reconhecimento da topologia para reduzir a latência entre clientes e cargas de trabalho. Para ver detalhes sobre o encaminhamento de tráfego com reconhecimento da topologia, consulte o artigo Encaminhamento com reconhecimento da topologia.

A utilização da topologia zonal para controlar o posicionamento de pods é um mecanismo avançado do Kubernetes que só deve usar se a sua situação exigir que os pods sejam executados em zonas específicas. Na maioria dos ambientes de produção, recomendamos que use recursos regionais, que é a predefinição do GKE, sempre que possível.

Métodos de posicionamento zonal

A topologia zonal está integrada no Kubernetes com a etiqueta de nó topology.kubernetes.io/zone: ZONE. Para indicar ao GKE que coloque um pod numa zona específica, use um dos seguintes métodos:

nodeAffinity: especifique uma regra nodeAffinity na especificação do pod para uma ou mais Google Cloud zonas. Este método é mais flexível do que um nodeSelector porque permite colocar pods em várias zonas.
nodeSelector: especifique um nodeSelector na especificação do pod para uma única Google Cloud zona.
Classes de computação: configure o seu pod para usar uma classe de computação do GKE. Esta abordagem permite-lhe definir uma lista prioritária de conjuntos de zonas Google Cloud . Permite que a carga de trabalho seja movida dinamicamente para o conjunto de zonas mais preferido quando os nós estão disponíveis nestas zonas. Para mais informações, consulte o artigo Acerca das classes de computação personalizadas.

Considerações

O posicionamento de pods zonais com topologia zonal tem as seguintes considerações:

O cluster tem de estar na mesma Google Cloud região que as zonas pedidas.
Nos clusters padrão, tem de usar o aprovisionamento automático de nós ou criar pools de nós com nós nas zonas pedidas. Os clusters do Autopilot gerem automaticamente este processo por si.
Os clusters padrão têm de ser clusters regionais.

Preços

A topologia zonal é uma capacidade de agendamento do Kubernetes e é oferecida sem custos adicionais no GKE.

Para ver detalhes dos preços, consulte os preços do GKE.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

Ative a API Google Kubernetes Engine.

Ative a API Google Kubernetes Engine

Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Certifique-se de que tem um cluster do GKE existente na mesma Google Cloud região que as zonas nas quais quer colocar os seus pods. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.

Coloque pods em várias zonas através de nodeAffinity

O nodeAffinity do Kubernetes oferece um mecanismo de controlo de agendamento flexível que suporta vários seletores de etiquetas e operadores lógicos. Use nodeAffinity se quiser permitir que os pods sejam executados numa de um conjunto de zonas (por exemplo, em us-central1-a ou us-central1-f).

Guarde 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

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

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

Crie a implementação:
```
kubectl create -f multi-zone-affinity.yaml
```
O GKE cria os pods em nós numa das zonas especificadas. Podem ser executados vários pods no mesmo nó. Opcionalmente, pode usar a antafinidade de pods para indicar ao GKE que coloque cada pod num nó separado.

Coloque pods numa única zona com um nodeSelector

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

Guarde 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

Este manifesto indica ao GKE para colocar todas as réplicas na zona us-central1-a.

Crie a implementação:

kubectl create -f single-zone-selector.yaml

Dê prioridade ao posicionamento de pods em zonas selecionadas através de uma classe de computação

As classes de computação do GKE oferecem um mecanismo de controlo que lhe permite definir uma lista de prioridades de configuração de nós. As preferências zonais permitem-lhe definir as zonas nas quais quer que o GKE coloque os pods. A definição de preferências zonais em classes de computação requer a versão 1.33.1-gke.1545000 ou posterior do GKE.

O exemplo seguinte cria uma classe de computação que especifica uma lista de zonas preferenciais para pods.

Estes passos pressupõem que o seu cluster está na região us-central1. Se o seu cluster estiver numa região diferente, altere os valores das zonas no manifesto para zonas válidas na região do cluster.

Guarde o seguinte manifesto 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
```
Esta classe de computação altera o comportamento de escalabilidade da seguinte forma:
1. O GKE tenta colocar pods em us-central1-a ou em us-central1-b.
2. Se us-central1-a e us-central1-b não tiverem capacidade disponível, o GKE tenta colocar os pods em us-central1-c.
3. Se us-central1-c não tiver capacidade disponível, o campo whenUnsatisfiable: ScaleUpAnyway faz com que o GKE coloque os pods em qualquer zona disponível na região.
4. Se uma zona com uma prioridade mais elevada na classe de computação ficar disponível mais tarde, o campo activeMigration.optimizeRulePriority: true faz com que o GKE mova os pods para essa zona a partir de zonas de prioridade inferior. Esta migração usa o orçamento de interrupção de pods para garantir a disponibilidade do serviço.
Crie a classe de computação personalizada:
```
kubectl create -f zones-custom-compute-class.yaml
```
O GKE cria uma classe de computação personalizada que as suas cargas de trabalho podem referenciar.

Guarde o seguinte manifesto 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

Crie a implementação:

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

Valide o posicionamento do Pod

Para validar o posicionamento do pod, liste os pods e verifique as etiquetas dos nós. Vários pods podem ser executados num único nó, pelo que pode não ver pods distribuídos por várias zonas se tiver usado nodeAffinity.

Apresente uma lista dos seus agrupamentos:
```
kubectl get pods -o wide
```
O resultado é uma lista de pods em execução e o nó do GKE correspondente.

Descreva os nós:

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

Substitua NODE_NAME pelo nome do nó.

O resultado é semelhante ao seguinte:

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

Se quiser que o GKE distribua os seus pods uniformemente por várias zonas para melhorar a comutação por falha em vários domínios de falha, use topologySpreadConstraints.