Implemente cargas de trabalho do Autopilot na arquitetura Arm

Esta página mostra como configurar as implementações do Autopilot do Google Kubernetes Engine (GKE) para pedir nós suportados pela arquitetura Arm.

Acerca da arquitetura ARM no Autopilot

Os clusters do Autopilot oferecem classes de computação para cargas de trabalho com requisitos de hardware específicos. Algumas destas classes de computação suportam várias arquiteturas de CPU, como amd64 e arm64.

Exemplos de utilização dos nós Arm

Os nós com arquitetura Arm oferecem um desempenho mais rentável do que os nós x86 semelhantes. Deve selecionar a arquitetura Arm para as suas cargas de trabalho do Autopilot em situações como as seguintes:

  • O seu ambiente depende da arquitetura Arm para a criação e os testes.
  • Está a desenvolver aplicações para dispositivos Android que são executadas em CPUs Arm.
  • Usa imagens multi-arquitetura e quer otimizar os custos enquanto executa as suas cargas de trabalho.

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.

Como pedir nós ARM no Autopilot

Para indicar ao Autopilot que execute os seus pods em nós Arm, especifique uma das seguintes etiquetas numa regra de nodeSelector ou nodeAffinity:

  • kubernetes.io/arch: arm64. Por predefinição, o GKE coloca pods em tipos de máquinas C4A para clusters que executam a versão 1.31.3-gke.1056000 e posteriores. Se o cluster estiver a executar uma versão anterior, o GKE coloca os pods em tipos de máquinas T2A.
  • cloud.google.com/machine-family: ARM_MACHINE_SERIES. Substitua ARM_MACHINE_SERIES por uma máquina da série Arm, como C4A ou T2A. O GKE coloca os pods na série especificada.

Por predefinição, a utilização de qualquer uma das etiquetas permite que o GKE coloque outros pods no mesmo nó se houver capacidade disponível nesse nó. Para pedir um nó dedicado para cada Pod, adicione a etiqueta cloud.google.com/compute-class: Performance ao manifesto. Para mais detalhes, consulte o artigo Otimize o desempenho do agrupamento do Autopilot escolhendo uma série de máquinas.

Em alternativa, pode usar a etiqueta Scale-Out com a etiqueta arm64 para pedir T2A. Também pode pedir a arquitetura Arm para pods de instâncias Spot.

Quando implementa a sua carga de trabalho, o Autopilot faz o seguinte:

  1. Aprovisiona automaticamente nós Arm para executar os seus pods.
  2. Marca automaticamente os novos nós para impedir que os pods não baseados em ARM sejam agendados nesses nós.
  3. Adiciona automaticamente uma tolerância aos seus pods Arm para permitir o agendamento nos novos nós.

Exemplo de pedido para arquitetura Arm

As especificações de exemplo seguintes mostram como usar um seletor de nós ou uma regra de afinidade de nós para pedir a arquitetura Arm no Autopilot.

nodeSelector

O manifesto de exemplo seguinte mostra como pedir nós Arm num nodeSelector:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      nodeSelector:
        cloud.google.com/compute-class: Performance
        kubernetes.io/arch: arm64
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

nodeAffinity

Pode usar a afinidade de nós para pedir nós Arm. Também pode especificar o tipo de afinidade de nós a usar:

  • requiredDuringSchedulingIgnoredDuringExecution: tem de usar a classe de computação e a arquitetura especificadas.
  • preferredDuringSchedulingIgnoredDuringExecution: use a classe de computação e a arquitetura especificadas com base no melhor esforço. Por exemplo, se um nó x86 existente for alocável, o GKE coloca o seu pod no nó x86 em vez de aprovisionar um novo nó Arm. A menos que esteja a usar um manifesto de imagem multi-arquitetura, o seu pod vai falhar. Recomendamos vivamente que peça explicitamente a arquitetura específica que quer.

O exemplo de manifesto seguinte requer a classe Performance e os nós Arm:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      terminationGracePeriodSeconds: 25
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi
            ephemeral-storage: 1Gi
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/compute-class
                operator: In
                values:
                - Performance
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64

Recomendações

  • Crie e use imagens multi-arquitetura como parte do seu pipeline. As imagens multi-arquitetura garantem que os seus pods são executados, mesmo que sejam colocados em nós x86.
  • Peça explicitamente classes de arquitetura e computação nos manifestos da sua carga de trabalho. Caso contrário, o Autopilot usa a arquitetura predefinida da classe de computação selecionada, que pode não ser Arm.

Disponibilidade

Pode implementar cargas de trabalho do Autopilot na arquitetura Arm em Google Cloud localizações que suportam a arquitetura Arm. Para ver detalhes, consulte o artigo Regiões e zonas disponíveis.

Resolução de problemas

Para ver informações de resolução de problemas e erros comuns, consulte o artigo Resolva problemas de cargas de trabalho do Arm.

O que se segue?