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:

  • Ative 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 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.
  • Revise os requisitos e limitações dos nós do Arm.
  • Para usar a autopilot-arm ComputeClass, verifique se o cluster está executando o GKE versão 1.35.3-gke.1389000 ou mais recente.
  • Verifique se você tem cota para os tipos de máquina C4A, N4A ou Tau T2A do Compute Engine.
  • Verifique se você tem um pod com uma imagem de contêiner criada para a arquitetura do Arm.

Como solicitar nós do Arm no Autopilot

Para instruir o Autopilot a executar seus pods em nós do Arm, use um dos métodos a seguir, dependendo dos seus requisitos. Você especifica isso usando uma regra de nodeSelector ou afinidade de nó:

  • Para cargas de trabalho de uso geral:solicite a plataforma Arm otimizada para contêineres especificando o seguinte:
    • cloud.google.com/compute-class: autopilot-arm
    • kubernetes.io/arch: arm64

  • Para cargas de trabalho com requisitos de hardware específicos:especifique uma das seguintes opções:

    • 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, N4A ou T2A. O GKE coloca pods na série especificada.

Por padrão, usar qualquer um dos rótulos, exceto Performance, 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 junto com os rótulos de arquitetura ou família de máquinas. 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 solicita um nó do Arm otimizado para contêineres do Autopilot:

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: autopilot-arm
        kubernetes.io/arch: arm64
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

Para solicitar hardware específico em vez de nós otimizados para contêineres do Autopilot, substitua autopilot-arm por Performance ou Scale-Out em nodeSelector.

nodeAffinity

Use a afinidade de nó para solicitar nós do Arm.

O exemplo de manifesto a seguir solicita um nó do Arm otimizado para contêineres do Autopilot:

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:
                - autopilot-arm
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64

Para solicitar um hardware específico em vez de nós otimizados para contêineres do Autopilot, substitua autopilot-arm por Performance ou Scale-Out nas regras nodeAffinity.

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 nas seguintes regiões: us-east1, us-west1, europe-west1, europe-west4 e us-central1.

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