Configure a separação de cargas de trabalho no GKE

Esta página mostra como indicar ao Google Kubernetes Engine (GKE) que agende os seus pods em conjunto, separadamente ou em localizações específicas.

A separação de cargas de trabalho permite-lhe usar manchas e tolerâncias para indicar ao GKE que separe os pods em nós diferentes, coloque os pods em nós que cumpram critérios específicos ou agende cargas de trabalho específicas em conjunto. O que tem de fazer para configurar a separação de cargas de trabalho depende da configuração do cluster do GKE. A tabela seguinte descreve as diferenças:

Configuração da separação de cargas de trabalho

Adicione uma tolerância para um par de chave:valor específico à especificação do seu pod e selecione esse par de chave:valor através de um nodeSelector. O GKE cria nós, aplica a restrição de nó correspondente e agenda o pod no nó.

Para ver instruções, consulte o artigo Separe cargas de trabalho em clusters do Autopilot nesta página.
Padrão sem aprovisionamento automático de nós
  1. Crie um node pool com uma restrição de nó e uma etiqueta de nó
  2. Adicione uma tolerância para essa restrição à especificação do pod

Para ver instruções, consulte o artigo Isole as suas cargas de trabalho em pools de nós dedicados.

Este guia usa um cenário de exemplo em que tem duas cargas de trabalho, um trabalho em lote e um servidor Web, que quer separar um do outro.

Quando usar a separação de cargas de trabalho no GKE

A separação de cargas de trabalho é útil quando tem cargas de trabalho que desempenham funções diferentes e não devem ser executadas nas mesmas máquinas subjacentes. Alguns exemplos de cenários incluem o seguinte:

  • Tem uma carga de trabalho do coordenador de lotes que cria tarefas que quer manter separadas.
  • Executa um servidor de jogos com uma carga de trabalho de matchmaking que quer separar dos pods de sessão.
  • Quer separar partes da sua pilha, como separar um servidor de uma base de dados.
  • Quiser separar algumas cargas de trabalho por motivos de conformidade ou de políticas.

Preços

Nos clusters do Autopilot, a faturação é feita com base nos recursos que os seus pods pedem durante a execução. Para ver detalhes, consulte o artigo Preços do Autopilot. Os agrupamentos que usam a separação de cargas de trabalho têm pedidos de recursos mínimos mais elevados aplicados do que os agrupamentos normais.

Nos clusters padrão, a faturação baseia-se na configuração de hardware e no tamanho de cada nó, independentemente de os pods estarem a ser executados nos nós. Para detalhes, consulte os preços padrão.

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 gcloud components update para obter a versão mais recente.

Separe as cargas de trabalho em clusters do Autopilot

Para separar as cargas de trabalho, adicione uma tolerância e um seletor de nós a cada especificação de carga de trabalho que define o nó no qual a carga de trabalho deve ser executada. Este método também funciona em clusters padrão com o aprovisionamento automático de nós ativado.

  1. Guarde o seguinte manifesto como web-server.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 6
  selector:
    matchLabels:
      pod: nginx-pod
  template:
    metadata:
      labels:
        pod: nginx-pod
    spec:
      tolerations:
      - key: group
        operator: Equal
        value: "servers"
        effect: NoSchedule
      nodeSelector:
        group: "servers"
      containers:
      - name: web-server
        image: nginx

    Este manifesto inclui os seguintes campos:

    • spec.tolerations: o GKE pode colocar os pods em nós que tenham a contaminação group=servers:NoSchedule. O GKE não pode agendar pods que não tenham esta tolerância nesses nós.
    • spec.nodeSelector: o GKE tem de colocar os pods em nós que tenham a etiqueta de nó group: servers.

    O GKE adiciona as etiquetas e os taints correspondentes aos nós que o GKE aprovisiona automaticamente para executar estes pods.

  2. Guarde o seguinte manifesto como batch-job.yaml:

    apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  completions: 5
  backoffLimit: 3
  ttlSecondsAfterFinished: 120
  template:
    metadata:
      labels:
        pod: pi-pod
    spec:
      restartPolicy: Never
      tolerations:
      - key: group
        operator: Equal
        value: "jobs"
        effect: NoSchedule
      nodeSelector:
        group: "jobs"
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]

    Este manifesto inclui os seguintes campos:

    • spec.tolerations: o GKE pode colocar os pods em nós que tenham a contaminação group=jobs:NoSchedule. O GKE não pode agendar pods que não tenham esta tolerância nesses nós.
    • spec.nodeSelector: o GKE tem de colocar os pods em nós que tenham a etiqueta de nó group: jobs.

    O GKE adiciona as etiquetas e os taints correspondentes aos nós que o GKE aprovisiona automaticamente para executar estes pods.

  3. Implemente as cargas de trabalho:

    kubectl apply -f batch-job.yaml web-server.yaml

Quando implementa as cargas de trabalho, o GKE faz o seguinte para cada carga de trabalho:

  1. O GKE procura nós existentes que tenham a restrição de tolerância e a etiqueta do nó correspondentes especificadas no manifesto. Se existirem nós e tiverem recursos disponíveis, o GKE agenda a carga de trabalho no nó.
  2. Se o GKE não encontrar um nó existente elegível para agendar a carga de trabalho, o GKE cria um novo nó e aplica a restrição de nó e a etiqueta de nó correspondentes com base no manifesto. O GKE coloca o pod no novo nó.

A presença do efeito NoSchedule na contaminação do nó garante que as cargas de trabalho sem tolerância não são colocadas no nó.

Valide a separação da carga de trabalho

Liste os seus pods para encontrar os nomes dos nós:

kubectl get pods --output=wide

O resultado é semelhante ao seguinte:

NAME                          READY   ...   NODE
batch-job-28j9h               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-78rcn               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-gg4x2               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-qgsxh               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-v4ksf               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
web-server-6bb8cd79b5-dw4ds   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm
web-server-6bb8cd79b5-g5ld6   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-jcdx5   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-pxdzw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-s66rw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-zq8hh   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm

Este resultado mostra que os batch-job pods e os web-server pods são sempre executados em nós diferentes.

Limitações da separação de cargas de trabalho com taints e tolerâncias

Não pode usar os seguintes prefixos de chaves para a separação de cargas de trabalho:

  • Chaves específicas do GKE e do Kubernetes
  • *cloud.google.com/
  • *kubelet.kubernetes.io/
  • *node.kubernetes.io/

Deve usar as suas próprias chaves únicas para a separação de cargas de trabalho.

Separe cargas de trabalho em clusters padrão sem aprovisionamento automático de nós

A separação de cargas de trabalho em clusters padrão sem aprovisionamento automático de nós requer que crie manualmente pools de nós com as falhas de nós e as etiquetas de nós adequadas para acomodar as suas cargas de trabalho. Para ver instruções, consulte o artigo Isolar as cargas de trabalho em pools de nós dedicados. Use esta abordagem apenas se tiver requisitos específicos que exijam que faça a gestão manual dos seus conjuntos de nós.

Crie um cluster com restrições de nós

Quando cria um cluster no GKE, pode atribuir taints de nós ao cluster. Isto atribui as restrições a todos os nós criados com o cluster.

Se criar um node pool, este não herda as restrições do cluster. Se quiser taints no node pool, tem de usar a flag --node-taints quando criar o node pool.

Se criar um cluster padrão com taints de nós que tenham o efeito NoSchedule ou o efeito NoExecute, o GKE não pode agendar alguns componentes geridos do GKE, como kube-dns ou metrics-server, no conjunto de nós predefinido que o GKE cria quando cria o cluster. O GKE não consegue agendar estes componentes porque não têm as tolerâncias correspondentes para as restrições dos nós. Tem de adicionar um novo conjunto de nós que cumpra uma das seguintes condições:

  • Sem taints
  • Uma mancha que tenha o efeito PreferNoSchedule
  • A contaminação components.gke.io/gke-managed-components=true:NoSchedule

Qualquer uma destas condições permite que o GKE agende componentes geridos pelo GKE no novo conjunto de nós.

Para ver instruções, consulte o artigo Isole cargas de trabalho em nós dedicados.

gcloud

Crie um cluster com restrições de nós:

gcloud container clusters create CLUSTER_NAME \
    --node-taints KEY=VALUE:EFFECT

Substitua o seguinte:

  • CLUSTER_NAME: o nome do novo cluster.
  • EFFECT: um dos seguintes efeitos: PreferNoSchedule, NoSchedule ou NoExecute.
  • KEY=VALUE: um par de chave-valor associado ao EFFECT.

Consola

Crie um cluster com restrições de nós:

  1. Na Google Cloud consola, aceda à página Criar um cluster do Kubernetes.

    Aceda a Crie um cluster do Kubernetes

  2. Configure o cluster conforme pretendido.

  3. No painel de navegação, em Node Pools, expanda o conjunto de nós que quer modificar e, de seguida, clique em Metadata.

  4. Na secção Node taints, clique em Adicionar taint.

  5. Na lista pendente Efeito, selecione o efeito pretendido.

  6. Introduza o par de chave-valor pretendido nos campos Chave e Valor.

  7. Clique em Criar.

API

Quando usa a API para criar um cluster, inclua o campo nodeTaints em `nodeConfig`:

POST https://container.googleapis.com/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/clusters

{
  'cluster': {
    'name': 'example-cluster',
    'nodeConfig': {
      'nodeTaints': [
        {
          'key': 'special',
          'Value': 'gpu',
          'effect': 'PreferNoSchedule'
        }
      ]
      ...
    }
    ...
  }
}

Remova todas as restrições de um conjunto de nós

Para remover todas as restrições de um conjunto de nós, execute o seguinte comando:

gcloud beta container node-pools update POOL_NAME \
    --node-taints="" \
    --cluster=CLUSTER_NAME

Substitua o seguinte:

  • POOL_NAME: o nome do node pool a alterar.
  • CLUSTER_NAME: o nome do cluster do node pool.

O que se segue?