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 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.

Requisitos

  • Para usar a ComputeClass autopilot-arm, verifique se o cluster está executando a versão 1.35.3-gke.1389000 ou mais recente do GKE.
  • Para usar recursos como a definição padrão inteligente (especificando apenas o kubernetes.io/arch: arm64 rótulo), a autopilot-arm-spot ComputeClass, ou a autopilot-arm ComputeClass em clusters GKE Standard que usam ComputeClasses do Autopilot, o cluster precisa executar a versão 1.36.0-gke.3302001 ou mais recente.
  • Verifique se você tem cota para os C4A, N4A, ou Tau T2A tipos de máquina 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, especifique um dos seletores a seguir (dependendo do tipo e da versão do GKE) usando um nodeSelector ou regra de afinidade de nó:

  • Em clusters do Autopilot (definição padrão inteligente) : especifique apenas o tipo de arquitetura:

    • kubernetes.io/arch: arm64

    Se a carga de trabalho for executada em um cluster do Autopilot, isso selecionará a plataforma Arm de uso geral.

  • Em clusters do Autopilot ou clusters padrão que usam ComputeClasses do Autopilot (somente ComputeClass) : especifique a ComputeClass:

    • cloud.google.com/compute-class: autopilot-arm (ou autopilot-arm-spot)

    A seleção dessa classe programa a carga de trabalho na plataforma Arm otimizada para contêineres (ou na variante de VMs spot) e adiciona automaticamente o seletor kubernetes.io/arch: arm64 necessário ao pod durante a admissão.

  • Seleção explícita (versões mais antigas do GKE) : em clusters do Autopilot que executam a versão 1.35.3-gke.1389000 ou mais recente, mas anterior à 1.36.0-gke.3302001, especifique o seletor a seguir para selecionar a plataforma Arm de uso geral. Essa combinação também é compatível com versões mais recentes do GKE para oferecer compatibilidade com versões anteriores:

    • 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 em um cluster padrão. O GKE coloca os pods nos tipos de máquina C4A por padrão.
    • 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, o uso de qualquer um dos rótulos, exceto Performance, permite que o GKE coloque outros pods no mesmo nó se houver capacidade disponível. 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, você pode usar o rótulo Scale-Out com o rótulo 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 manifesto de exemplo a seguir solicita um nó do Arm otimizado para contêineres do Autopilot usando a definição padrão inteligente:

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

Como alternativa, é possível solicitar a plataforma Arm otimizada para contêineres especificando explicitamente a autopilot-arm (ou autopilot-arm-spot para VMs spot) ComputeClass:

...
    spec:
      nodeSelector:
        cloud.google.com/compute-class: autopilot-arm
...

Para solicitar hardware específico em vez de nós otimizados para contêineres do Autopilot, substitua as ComputeClasses ou adicione cloud.google.com/machine-family: C4A ao seletor.

nodeAffinity

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

O manifesto de exemplo a seguir solicita um nó do Arm otimizado para contêineres do Autopilot usando a definição padrão inteligente:

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

Para solicitar hardware específico em vez de nós otimizados para contêineres do Autopilot, substitua kubernetes.io/arch por regras de afinidade de família de máquinas específicas ou classes de solicitação como Performance ou Scale-Out.

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-west2, europe-west4, asia-southeast1 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