Executar cargas de trabalho Arm no GKE na AWS

O GKE na AWS permite executar cargas de trabalho do Arm criadas para processadores AWS Graviton baseados em ARM.

Limitações

  • Os pools de nós do ARM que executam versões do Kubernetes anteriores à 1.24.8-gke.1300 adicionam automaticamente um taint durante a criação do pool de nós para evitar que cargas de trabalho do ARM sejam programadas em nós que não sejam do ARM. Os pools de nós do ARM em clusters na versão 1.24.8-gke.1300 ou mais recente não adicionam mais esse taint. Se você estiver fazendo upgrade de um cluster anterior a 1.24.8-gke.1300, crie esse taint por conta própria ou leve isso em consideração ao fazer upgrade.

  • Os pools de nós do Arm no GKE na AWS não são compatíveis com o Anthos Service Mesh, o Config Sync ou o Controlador de Políticas. Execute esses produtos em um pool de nós x86.

  • Os clusters que executam a versão 1.24 do Kubernetes precisam de um pool de nós x86 para executar o agente do Connect. Se o cluster executar o Kubernetes versão 1.25 ou mais recente, você não precisará de um pool de nós x86.

Nesta página, explicamos como criar um pool de nós do Arm, por que as imagens de várias arquiteturas são a maneira recomendada de implantar cargas de trabalho do Arm e como programar cargas de trabalho do Arm.

Antes de começar

Antes de criar pools de nós para as cargas de trabalho do Arm, você precisa dos recursos a seguir:

  • Um cluster da AWS em que o pool de nós será criado. Este cluster precisa executar o Kubernetes versão 1.24 ou mais recente.
  • Um perfil de instância do IAM para VMs de pool de nós.
  • Uma sub-rede em que as VMs do pool de nós serão executadas.

  • Se o cluster estiver executando o Kubernetes versão 1.24, um pool de nós x86 para executar o agente do Connect.

    Para detalhes sobre como criar um pool de nós no GKE na AWS, consulte Criar um pool de nós.

Criar um pool de nós do Arm

O GKE na AWS dá suporte a pools de nós criados na imagem de nó arm64 mínima do Canonical Ubuntu e no ambiente de execução containerd.

Para criar um pool de nós do Arm e adicioná-lo a um cluster atual, execute o seguinte comando:

gcloud container aws node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --instance-type INSTANCE_TYPE \
    --root-volume-size ROOT_VOLUME_SIZE \
    --iam-instance-profile NODEPOOL_PROFILE \
    --node-version NODE_VERSION \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --max-pods-per-node MAX_PODS_PER_NODE \
    --location GOOGLE_CLOUD_LOCATION \
    --subnet-id NODEPOOL_SUBNET \
    --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
    --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN

Substitua:

  • NODE_POOL_NAME: o nome escolhido para o pool de nós
  • CLUSTER_NAME: o nome do cluster ao qual o pool de nós será anexado

  • INSTANCE_TYPE: um dos seguintes tipos de instância:

    • m6g
    • m6gd
    • t4g
    • r6g
    • r6gd
    • c6g
    • c6gd
    • c6gn
    • x2gd
    • c7g
    • im4gn

    • g5g

      Esses tipos de instância são apoiados por processadores da AWS Graviton baseados em ARM. Também é preciso especificar o tamanho da instância que você quer. Por exemplo, m6g.medium. Para ver uma lista completa, consulte Tipos de instâncias compatíveis da AWS.

  • ROOT_VOLUME_SIZE: o tamanho desejado para o volume raiz de cada nó, em GB

  • NODEPOOL_PROFILE: o perfil de instância do IAM para VMs de pool de nós

  • NODE_VERSION: a versão do Kubernetes a ser instalada em cada nó no pool de nós, que precisa ser a versão 1.24 ou posterior. Por exemplo, 1.24.3-gke.200.

  • MIN_NODES: o número mínimo de nós que o pool pode conter

  • MAX_NODES: o número máximo de nós que o pool pode conter

  • MAX_PODS_PER_NODE: o número máximo de pods que podem ser criados em qualquer nó no pool

  • GOOGLE_CLOUD_LOCATION: o nome do Google Cloud

    local em que este pool de nós será gerenciado

  • NODEPOOL_SUBNET: o ID da sub-rede em que o pool de nós será executado. Se essa sub-rede estiver fora do bloco CIDR principal da VPC, será necessário tomar medidas adicionais. Para mais informações, consulte grupos de segurança.

  • SSH_KEY_PAIR_NAME: o nome do par de chaves SSH da AWS criado para acesso SSH (opcional)

  • CONFIG_KMS_KEY_ARN: o nome de recurso da Amazon (ARN) da chave de KMS da AWS que criptografa os dados do usuário;

Entender imagens de várias arquiteturas

As imagens de contêiner precisam ser compatíveis com a arquitetura do nó em que você pretende executar as cargas de trabalho do Arm. Para garantir que a imagem do contêiner seja compatível com o Arm, recomendamos o uso de imagens de várias arquiteturas ("multi-arch").

Uma imagem "multi-arch" é uma imagem compatível com várias arquiteturas. Ela se parece com uma imagem única com uma única tag, mas contém um conjunto de imagens para ser executado em diferentes arquiteturas de máquina. As imagens de várias arquiteturas são compatíveis com o Esquema 2 do manifesto de imagem do Docker V2 ou com as Especificações do índice de imagens OCI.

Quando você implanta uma imagem de vários arquiteturas em um cluster, o ambiente de execução do contêiner escolhe automaticamente a imagem compatível com a arquitetura do nó que está sendo implantado. Depois que você tiver uma imagem de várias arquiteturas para uma carga de trabalho, será possível implantá-la em várias arquiteturas. Programar uma imagem de arquitetura única em um nó incompatível causa um erro no tempo de carregamento.

Para saber mais sobre como usar imagens de várias arquiteturas com cargas de trabalho do Arm, consulte Como criar imagens de multiarquitetura para cargas de trabalho do Arm na documentação do Google Kubernetes Engine (GKE).

A seguir