Implantar cargas de trabalho do Autopilot na arquitetura do Arm

Esta página mostra como configurar as implantações do Autopilot do Google Kubernetes Engine (GKE) para solicitar nós baseados na arquitetura do Arm.

Sobre a arquitetura do Arm no Autopilot

Os clusters do Autopilot oferecem classes de computação para cargas de trabalho que têm requisitos de hardware específicos. Algumas dessas classes de computação aceitam várias arquiteturas de CPU, como amd64 e arm64.

Casos de uso para nós do Arm

Nós com arquitetura do Arm oferecem desempenho mais econômico em comparação a nós x86 semelhantes. Selecione o Arm para as cargas de trabalho do Autopilot em situações como a seguinte:

  • Seu ambiente depende da arquitetura do Arm para criação e testes.
  • Você está desenvolvendo aplicativos para dispositivos Android que são executados em CPUs Arm.
  • Você usa imagens de várias arquiteturas e quer otimizar custos durante a execução das cargas de trabalho.

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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

Como solicitar nós do Arm no Autopilot

Para instruir o Autopilot a executar os pods em nós do Arm, especifique um dos rótulos a seguir em uma regra de nodeSelector ou afinidade de nó:

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

Por padrão, usar qualquer um dos rótulos permite que o GKE coloque outros pods no mesmo nó se houver capacidade disponível nele. Para solicitar um nó dedicado para cada pod, adicione o rótulo cloud.google.com/compute-class: Performance ao manifesto. Para mais detalhes, consulte Otimizar o desempenho do pod do Autopilot escolhendo uma série de máquinas.

Ou use os rótulos Scale-Out e arm64 para solicitar T2A. Também é possível solicitar a arquitetura do Arm para pods do Spot.

Quando você implanta sua carga de trabalho, o Autopilot faz o seguinte:

  1. Provisiona automaticamente os nós do Arm para executar seus pods.
  2. Impede automaticamente os novos nós para evitar que pods que não sejam do Arm sejam programados nesses nós.
  3. Adiciona automaticamente uma tolerância aos pods de grupo para permitir a programação nos novos nós.

Exemplo de solicitação de arquitetura do Arm

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

nodeSelector

O exemplo de manifesto a seguir mostra como solicitar nós do Arm em um 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

Use a afinidade de nó para solicitar nós do Arm. Também é possível especificar o tipo de afinidade de nó a ser usada:

  • requiredDuringSchedulingIgnoredDuringExecution: precisa usar a classe e a arquitetura de computação especificadas
  • preferredDuringSchedulingIgnoredDuringExecution: use a classe de computação e a arquitetura especificadas da melhor maneira possível. Por exemplo, se um nó x86 atual for alocável, o GKE colocará seu pod no nó x86 em vez de provisionar um novo nó Arm. O pod falhará a menos que você esteja usando um manifesto de imagem de várias arquiteturas. É altamente recomendável solicitar explicitamente a arquitetura específica que você quer.

O manifesto de exemplo a seguir requer a classe Performance e os nós do 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 de multiarquiteturas como parte do pipeline. As imagens de várias arquiteturas garantem que seus pods sejam executados mesmo que sejam colocados em nós x86.
  • Solicitar explicitamente a arquitetura e as classes de computação nos manifestos da carga de trabalho Se você não fizer isso, o Autopilot usará a arquitetura padrão da classe de computação selecionada, que pode não ser Arm.

Disponibilidade

É possível implantar cargas de trabalho do Autopilot na arquitetura do Arm em Google Cloud locais que oferecem suporte a essa arquitetura. Para mais detalhes, consulte Regiões e zonas disponíveis.

Solução de problemas

Para informações sobre erros comuns e solução de problemas, consulte Como solucionar problemas em cargas de trabalho do Arm.

A seguir