Preparar a implantação de uma carga de trabalho do Arm em um cluster padrão

Nesta página, explicamos como preparar uma carga de trabalho a ser programada em nós do Arm em um cluster do GKE Standard. Para saber mais sobre como programar cargas de trabalho do Arm com o Autopilot, consulte Implantar cargas de trabalho do Autopilot na arquitetura do Arm.

Para programar uma carga de trabalho para um nó Arm, você precisa ter o seguinte:

Visão geral

Por padrão, o GKE programa cargas de trabalho apenas para nós baseados em x86, séries de máquinas do Compute Engine com processadores Intel ou AMD, colocando um taint (kubernetes.io/arch=arm64:NoSchedule) em todos os nós do Arm. Esse taint impede que cargas de trabalho compatíveis com x86 sejam programadas inadvertidamente para seus nós do Arm. Você pode remover esse taint padrão se quiser que cargas de trabalho compatíveis com x86 sejam programadas em nós do Arm sem precisar da tolerância correspondente. Para mais informações, consulte Configurar a restrição de arquitetura Arm padrão.

Se você quiser implantar uma carga de trabalho em um nó do Arm com a restrição padrão, use os campos descritos neste documento para orientar o programador a enviar a carga de trabalho para o tipo de nó solicitado.

Use um dos seguintes campos:

Ao usar um seletor de nó ou uma regra de afinidade de nó, o GKE só programará suas cargas de trabalho compatíveis com o Arm quando você declarar que a imagem do contêiner da carga de trabalho pode ser executada na arquitetura do nó.

Se você programar uma carga de trabalho compatível com o Armcom um seletor de nó oucom uma regra de afinidade de nó conforme descrito nas seções a seguir, o GKE adiciona automaticamente uma tolerância à configuração da carga de trabalho para que os pods possam ser executados nos nós do Arm.

Essa tolerância adicionada à carga de trabalho corresponde ao taint (kubernetes.io/arch=arm64:NoSchedule) adicionado a todos os nós do Arm, por padrão, para permitir que sua carga de trabalho seja programada em nós do Arm.

Em algumas situações, como quando você tem imagens de multiarquitetura que podem ser executadas em qualquer nó, convém adicionar manualmente essa tolerância à configuração da carga de trabalho. Para mais instruções, consulte Usar a tolerância para programar cargas de trabalho de vários arcos em qualquer arquitetura.

Usar um seletor de nós para programar uma carga de trabalho do Arm

Adicione o seletor de nós a seguir à especificação:

nodeSelector:
    kubernetes.io/arch: arm64

O seletor de nós especifica que essa carga de trabalho precisa ser programada apenas para nós com o rótulo arm64, que todos os nós do Arm têm em clusters do GKE.

Quando esse seletor de nó é incluído na configuração da carga de trabalho, o GKE adiciona a tolerância para corresponder ao taint a fim de permitir que a carga de trabalho seja programada em nós do Arm.

Usar uma regra de afinidade de nó para programar uma carga de trabalho do Arm

Também é possível usar a afinidade de nó para programar a carga de trabalho.

Programar carga de trabalho para uma única arquitetura

Adicione a seguinte afinidade de nó à especificação:

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64

A regra de afinidade do nó especifica que a carga de trabalho seja programada apenas para nós com o identificador arm64, que todos os nós do Arm usam nos clusters do GKE.

Quando essa regra de afinidade de nó é incluída na configuração da carga de trabalho, o GKE adiciona a tolerância para corresponder ao taint a fim de permitir que a carga de trabalho seja programada em nós do Arm.

Programar carga de trabalho para arquiteturas x86 e Arm

Se quiser programar uma carga de trabalho em arquiteturas x86 (processadores Intel e AMD) e Arm, e seus pools de nós do Arm usarem o comportamento de taint padrão, é possível especificar isso de diferentes maneiras. As instruções a seguir pressupõem que seus pools de nós do Arm usam a restrição padrão.

Usar a tolerância para programar cargas de trabalho de várias arquiteturas em qualquer arquitetura

Se você tiver uma imagem de vários arcos que quiser ser programada para qualquer tipo de arquitetura disponível em um cluster padrão, basta adicionar a tolerância à especificação da carga de trabalho. Não são necessários o seletor de nós ou as regras de afinidade de nó descritas nesta página, porque a carga de trabalho pode ser programada para todos os tipos de arquitetura.

Adicione a tolerância:

  tolerations:
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

Usando essa tolerância, o GKE pode programar uma carga de trabalho para nós com qualquer tipo de arquitetura.

Por exemplo, se você tiver um cluster com os seguintes pools de nós:

  • my-c4a-node-pool, usando VMs c4a-standard-16 (arm64).
  • my-c2-node-pool, usando VMs c2-standard-8 (amd64).
  • my-t2d-node-pool, usando VMs t2-standard-48 (amd64).

Se você implantar neste cluster uma carga de trabalho que use uma imagem de vários arcos e a tolerância arm64 na configuração de carga de trabalho, o GKE poderá programá-la em todos os pools de nós.

Usar a regra de afinidade do nó para programar cargas de trabalho de multiarquitetura em qualquer arquitetura

Caso queira que uma carga de trabalho seja programada em nós em todos os tipos de arquitetura que incluem x86 e Arm, também é possível usar uma regra de afinidade de nó. Com as regras de afinidade de nó, é possível especificar exatamente em quais tipos de arquitetura você quer programar a carga de trabalho. Essa abordagem é recomendada para programar cargas de trabalho em clusters do Autopilot. Para saber mais, consulte Implantar cargas de trabalho do Autopilot na arquitetura do Arm.

Com cargas de trabalho baseadas em x86, esses seletores de nós, regras de afinidade de nós ou tolerâncias não são necessários para programar a carga de trabalho. Se você tiver uma imagem que quer apenas programar para nós baseados em x86, não é necessário usar esses campos.

Para programar cargas de trabalho para qualquer tipo de arquitetura, liste arm64 e amd64 na seção values do campo de afinidade do nó. amd64 inclui qualquer nó que usa processadores x86.

O exemplo a seguir especifica que essa carga de trabalho pode ser programada em nós com processadores Arm ou processadores x86:

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
            - amd64

Estes são os rótulos para cada tipo de arquitetura:

Por exemplo, se você tiver um cluster com os seguintes pools e a regra de afinidade de nó especificada:

  • my-c4a-node-pool, usando VMs c4a-standard-16 (arm64).
  • my-c2-node-pool, usando VMs c2-standard-8 (amd64).
  • my-t2d-node-pool, usando VMs t2-standard-48 (amd64).

Se você implantar nesse cluster uma carga de trabalho que use uma imagem de vários arcos e a afinidade de nó com arm64 incluído na lista values, o GKE adicionará a tolerância na configuração da carga de trabalho e programá-la em todos os pools de nós.

Configurar a restrição de arquitetura Arm padrão

Por padrão, o GKE corrompe todos os nós do Arm com a corrupção kubernetes.io/arch=arm64:NoSchedule. Esse taint impede que cargas de trabalho compatíveis apenas com a arquitetura x86, mas não com a arquitetura Arm, sejam programadas para nós Arm. Se você tiver cargas de trabalho compatíveis com x86 e Arm, desative esse taint para permitir que o GKE programe essas cargas de trabalho em nós Arm sem precisar de uma tolerância correspondente ao taint.

É possível atualizar o comportamento padrão de taint apenas em pools de nós padrão. A atualização do comportamento de taint não se aplica à implantação de cargas de trabalho do Arm com o Autopilot. Para mais informações, consulte Implantar cargas de trabalho do Autopilot na arquitetura do Arm.

É possível configurar esse comportamento nas seguintes situações:

  • Durante a criação do cluster, para o pool de nós padrão
  • Ao criar ou atualizar um pool de nós padrão

Se você tiver cargas de trabalho em execução no cluster que não sejam compatíveis com Arm, não remova o taint padrão, porque cargas de trabalho incompatíveis podem ser programadas para os nós Arm sem taint.

Para configurar a restrição de nó padrão para nós do Arm, selecione uma das seguintes opções:

CLI da gcloud

Para definir o comportamento de restrição com a CLI gcloud, use a flag --node-architecture-taint-behavior ao realizar qualquer uma das seguintes operações:

  • Crie um cluster Standard com um comportamento de restrição específico para o pool de nós padrão usando o comando gcloud container cluster create:

    gcloud container cluster create CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Crie um pool de nós padrão usando o comando gcloud container node-pools create:

    gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Atualize um pool de nós padrão usando o comando gcloud container node-pools update:

    gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

Nesses comandos, substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster.
  • CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
  • POOL_NAME: o nome do pool de nós.

  • BEHAVIOR: uma das seguintes configurações:

    • none: o GKE omite o taint padrão de kubernetes.io/arch=arm64:NoSchedule.
    • arm: define explicitamente o comportamento padrão, que adiciona as restrições kubernetes.io/arch=arm64:NoSchedule a todos os nós no pool de nós do Arm.

Quando você modifica o comportamento de taint da arquitetura do nó para um pool de nós padrão, o GKE atualiza imediatamente os taints sem precisar recriar os nós.

Terraform

Adicione o seguinte bloco taint_config em node_config para configurar o comportamento de taint de arquitetura:

taint_config {
  architecture_taint_behavior = "BEHAVIOR"
}

Substitua BEHAVIOR por uma das seguintes configurações:

  • NONE: o GKE omite o taint padrão de kubernetes.io/arch=arm64:NoSchedule.
  • ARM: define explicitamente o comportamento padrão, que adiciona os taints kubernetes.io/arch=arm64:NoSchedule para todos os nós no pool de nós do Arm.

Um node_config completo para um pool de nós do Standard que inclui esse bloco tem esta aparência:

resource "google_container_node_pool" "primary_preemptible_nodes" {
  name       = "NODE_POOL_NAME"
  location   = "NODE_POOL_LOCATION"
  cluster    = google_container_cluster.primary.name
  node_count = 1

  node_config {
    preemptible  = true
    machine_type = "ARM_MACHINE_TYPE"

    # Google recommends custom service accounts that have cloud-platform scope and permissions granted via IAM Roles.
    service_account = google_service_account.default.email
    oauth_scopes    = [
      "https://www.googleapis.com/auth/cloud-platform"
    ]
    taint_config {
      architecture_taint_behavior = "BEHAVIOR"
    }
  }
}

Neste exemplo, NODE_POOL_NAME representa o nome do pool de nós, e NODE_POOL_LOCATION representa o local do plano de controle do cluster.

Implantar a carga de trabalho

Agora que você especificou onde suas cargas de trabalho compatíveis com o Arm precisam ser programadas, implante sua carga de trabalho.

Quando você implanta uma carga de trabalho em um cluster do GKE, as instruções são as mesmas nos tipos de arquitetura. É possível implantar uma carga de trabalho compatível com o Arm como qualquer outra carga de trabalho, desde que você tenha concluído as etapas obrigatórias. Para ver exemplos de implantação de cargas de trabalho, consulte as seguintes páginas:

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