Execute cargas de trabalho Arm no GKE no AWS

O GKE no AWS permite-lhe executar cargas de trabalho Arm criadas para processadores AWS Graviton baseados em Arm.

Limitações

  • Os node pools Arm que executam versões do Kubernetes anteriores a 1.24.8-gke.1300 adicionam automaticamente uma restrição durante a criação do node pool para impedir que as cargas de trabalho Arm sejam agendadas em nós não Arm. Os pools de nós ARM em clusters na versão 1.24.8-gke.1300 ou superior já não adicionam esta restrição. Se estiver a atualizar a partir de um cluster anterior a 1.24.8-gke.1300, tem de criar esta restrição manualmente ou, caso contrário, ter isto em conta ao fazer a atualização.

  • Os pools de nós Arm no GKE no AWS não suportam o Cloud Service Mesh, o Config Sync nem o Policy Controller. Tem de executar estes produtos num conjunto de nós x86.

  • Os clusters que executam a versão 1.24 do Kubernetes precisam de um conjunto de nós x86 para executar o agente Connect. Se o seu cluster executar a versão 1.25 ou posterior do Kubernetes, não precisa de um node pool x86.

Esta página explica como criar um conjunto de nós Arm, por que motivo as imagens de várias arquiteturas são a forma recomendada de implementar cargas de trabalho Arm e como agendar cargas de trabalho Arm.

Antes de começar

Antes de criar pools de nós para as suas cargas de trabalho Arm, precisa dos seguintes recursos:

  • Um cluster da AWS existente no qual criar o node pool. Este cluster tem de executar a versão 1.24 ou posterior do Kubernetes.
  • Um perfil de instância do IAM para as VMs do node pool.
  • Uma sub-rede onde as VMs do node pool são executadas.

  • Se o cluster estiver a executar a versão 1.24 do Kubernetes, um node pool x86 para executar o agente Connect.

    Para ver detalhes sobre como criar um node pool no GKE no AWS, consulte o artigo Crie um node pool.

Crie um node pool Arm

O GKE no AWS suporta pools de nós criados na imagem de nó mínima do Canonical Ubuntu arm64 e no tempo de execução containerd.

Para criar um conjunto de nós Arm e adicioná-lo a um cluster existente, 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 o seguinte:

  • NODE_POOL_NAME: o nome que escolher para o seu node pool
  • CLUSTER_NAME: o nome do cluster ao qual anexar o grupo de nós

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

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

    • g5g

      Estes tipos de instâncias são alimentados por processadores AWS Graviton baseados em ARM. Também tem de especificar o tamanho da instância pretendido. Por exemplo, m6g.medium. Para ver uma lista completa, consulte o artigo Tipos de instâncias da AWS suportados.

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

  • NODEPOOL_PROFILE: o perfil da instância do IAM para VMs do node pool

  • NODE_VERSION: a versão do Kubernetes a instalar em cada nó no node pool, que tem de 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 node pool pode conter

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

  • MAX_PODS_PER_NODE: o número máximo de agrupamentos que podem ser criados em qualquer nó único no conjunto

  • GOOGLE_CLOUD_LOCATION: o nome do Google Cloud

    Localização a partir da qual este node pool vai ser gerido

  • NODEPOOL_SUBNET: o ID da sub-rede na qual o conjunto de nós vai ser executado. Se esta sub-rede estiver fora do bloco CIDR principal da VPC, tem de tomar medidas adicionais. Para mais informações, consulte os 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 do AWS KMS que encripta os dados do utilizador

Compreenda as imagens de várias arquiteturas

As imagens de contentores têm de ser compatíveis com a arquitetura do nó onde pretende executar as cargas de trabalho do Arm. Para garantir que a sua imagem do contentor é compatível com Arm, recomendamos que use imagens de várias arquiteturas ("multi-arch").

Uma imagem multi-arquitetura é uma imagem que pode suportar várias arquiteturas. Parece uma única imagem com uma única etiqueta, mas contém um conjunto de imagens para execução em diferentes arquiteturas de máquinas. As imagens multi-arquitetura são compatíveis com as especificações do esquema 2 do manifesto de imagem do Docker ou do índice de imagens da OCI.

Quando implementa uma imagem de várias arquiteturas num cluster, o tempo de execução do contentor escolhe automaticamente a imagem compatível com a arquitetura do nó para o qual está a fazer a implementação. Depois de ter uma imagem de várias arquiteturas para uma carga de trabalho, pode implementar esta carga de trabalho em várias arquiteturas. Agendar uma imagem de arquitetura única num nó incompatível causa um erro no momento do carregamento.

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

O que se segue?