Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O GKE na AWS permite que você execute cargas de trabalho Arm criadas para processadores AWS Graviton baseados em Arm.
Limitações
Pools de nós ARM executando versões do Kubernetes anteriores à 1.24.8-gke.1300 adicionam automaticamente uma contaminação durante a criação do pool de nós para impedir que cargas de trabalho do ARM sejam agendadas em nós que não sejam ARM. Pools de nós ARM em clusters na versão 1.24.8-gke.1300 ou superior não adicionam mais essa contaminação. Se você estiver atualizando de um cluster anterior à 1.24.8-gke.1300, deverá criar essa contaminação você mesmo ou levar isso em consideração ao atualizar.
Os pools de nós do ARM no GKE na AWS não são compatíveis com Cloud Service Mesh, Config Sync ou Policy Controller. Você precisa executar esses produtos em um pool de nós x86.
Clusters que executam o Kubernetes versão 1.24 precisam de um pool de nós x86 para executar o Connect Agent . Se o seu cluster executa o Kubernetes versão 1.25 ou posterior, você não precisa de um pool de nós x86.
Esta página explica como criar um pool de nós Arm, por que imagens multiarquitetura são a maneira recomendada de implantar cargas de trabalho Arm e como agendar cargas de trabalho Arm.
Antes de começar
Antes de criar pools de nós para suas cargas de trabalho do Arm, você precisa dos seguintes recursos:
Um cluster AWS existente para criar o pool de nós. Este cluster deve executar o Kubernetes versão 1.24 ou posterior.
NODE_POOL_NAME : o nome que você escolher para seu 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 alimentados por processadores AWS Graviton baseados em ARM. Você também precisa especificar o tamanho da instância desejada. Por exemplo, m6g.medium . Para obter uma lista completa, consulte Tipos de instância da AWS compatíveis .
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 do pool de nós
NODE_VERSION : a versão do Kubernetes a ser instalada em cada nó do pool de nós, que deve 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 de nós pode conter
MAX_NODES : o número máximo de nós que o pool de nós pode conter
MAX_PODS_PER_NODE : o número máximo de Pods que podem ser criados em qualquer nó do pool
GOOGLE_CLOUD_LOCATION : o nome do Google Cloud
local de onde este pool de nós será gerenciado
NODEPOOL_SUBNET : o ID da sub-rede na qual o pool de nós será executado. Se essa sub-rede estiver fora do bloco CIDR primário da VPC, você precisará executar etapas adicionais. Para obter 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 do recurso da Amazon (ARN) da chave AWS KMS que criptografa os dados do usuário
Entenda imagens multiarquitetônicas
As imagens de contêiner devem ser compatíveis com a arquitetura do nó onde você pretende executar as cargas de trabalho do Arm. Para garantir que sua imagem de contêiner seja compatível com o Arm, recomendamos o uso de imagens multiarquitetura ("multiarquitetura").
Uma imagem multiarquitetura é uma imagem que pode suportar múltiplas arquiteturas. Parece uma única imagem com uma única tag, mas contém um conjunto de imagens para execução em diferentes arquiteturas de máquina. Imagens multiarquitetura são compatíveis com o Esquema 2 do Docker Image Manifest V2 ou com as Especificações de Índice de Imagens OCI.
Ao implantar uma imagem multiarquitetura em um cluster, o tempo de execução do contêiner escolhe automaticamente a imagem compatível com a arquitetura do nó em que você está implantando. Depois de ter uma imagem multiarquitetura para uma carga de trabalho, você pode implantá-la em várias arquiteturas. Agendar uma imagem de arquitetura única em um nó incompatível causa um erro no momento do carregamento.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-06-12 UTC."],[],[],null,["# Run Arm workloads in GKE on AWS\n\nGKE on AWS lets you run Arm workloads built for Arm-based\n[AWS Graviton processors](https://aws.amazon.com/ec2/graviton/).\n\nLimitations\n-----------\n\n- Arm node pools running Kubernetes versions earlier than 1.24.8-gke.1300\n automatically add a taint during node pool creation to prevent Arm workloads\n from being scheduled on non-Arm nodes. Arm node pools in clusters at version\n 1.24.8-gke.1300 or higher no longer add this taint. If you're upgrading from a\n cluster earlier than 1.24.8-gke.1300, you must create this\n taint yourself or otherwise take this into account when upgrading.\n\n- Arm node pools on GKE on AWS don't support Cloud Service Mesh, Config Sync,\n or Policy Controller. You must run these products on an x86 node\n pool.\n\n- Clusters running Kubernetes version 1.24 need an x86 node pool to run the\n [Connect Agent](/anthos/fleet-management/docs/connect-agent).\n If your cluster runs Kubernetes version 1.25 or later, you don't need an\n x86 node pool.\n\nThis page explains how to create an Arm node pool, why\nmulti-architecture images are the recommended way to deploy Arm workloads, and\nhow to schedule Arm workloads.\n\n### Before you begin\n\nBefore you create node pools for your Arm workloads, you need the following\nresources:\n\n- An existing AWS cluster to create the node pool in. This cluster must run Kubernetes version 1.24 or later.\n- An [IAM instance profile](/kubernetes-engine/multi-cloud/docs/aws/how-to/create-aws-iam-roles#create_a_node_pool_iam_role) for the node pool VMs.\n- A [subnet](/kubernetes-engine/multi-cloud/docs/aws/how-to/create-aws-vpc#create_the_node_pool_subnets) where the node pool VMs will run.\n- If your cluster is running Kubernetes version 1.24, an x86 node pool to run\n the [Connect Agent](/anthos/fleet-management/docs/connect-agent).\n\n For details on how to create a node pool in GKE on AWS, see\n [Create a node pool](/kubernetes-engine/multi-cloud/docs/aws/how-to/create-node-pool).\n\n### Create an Arm node pool\n\nGKE on AWS supports node pools built on the Canonical Ubuntu\narm64 minimal node image and `containerd` runtime.\n\nTo create an Arm node pool and add it to an existing cluster, run the following\ncommand: \n\n gcloud container aws node-pools create \u003cvar translate=\"no\"\u003eNODE_POOL_NAME\u003c/var\u003e \\\n --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --instance-type \u003cvar translate=\"no\"\u003eINSTANCE_TYPE\u003c/var\u003e \\\n --root-volume-size \u003cvar translate=\"no\"\u003eROOT_VOLUME_SIZE\u003c/var\u003e \\\n --iam-instance-profile \u003cvar translate=\"no\"\u003eNODEPOOL_PROFILE\u003c/var\u003e \\\n --node-version \u003cvar translate=\"no\"\u003eNODE_VERSION\u003c/var\u003e \\\n --min-nodes \u003cvar translate=\"no\"\u003eMIN_NODES\u003c/var\u003e \\\n --max-nodes \u003cvar translate=\"no\"\u003eMAX_NODES\u003c/var\u003e \\\n --max-pods-per-node \u003cvar translate=\"no\"\u003eMAX_PODS_PER_NODE\u003c/var\u003e \\\n --location \u003cvar translate=\"no\"\u003eGOOGLE_CLOUD_LOCATION\u003c/var\u003e \\\n --subnet-id \u003cvar translate=\"no\"\u003eNODEPOOL_SUBNET\u003c/var\u003e \\\n --ssh-ec2-key-pair \u003cvar translate=\"no\"\u003eSSH_KEY_PAIR_NAME\u003c/var\u003e \\\n --config-encryption-kms-key-arn \u003cvar translate=\"no\"\u003eCONFIG_KMS_KEY_ARN\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eNODE_POOL_NAME\u003c/var\u003e: the name you choose for your node pool\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster to attach the node pool to\n- \u003cvar translate=\"no\"\u003eINSTANCE_TYPE\u003c/var\u003e: one of the following instance types:\n\n - `m6g`\n - `m6gd`\n - `t4g`\n - `r6g`\n - `r6gd`\n - `c6g`\n - `c6gd`\n - `c6gn`\n - `x2gd`\n - `c7g`\n - `im4gn`\n - `g5g`\n\n These instance types are powered by Arm-based AWS Graviton processors.\n You also need to specify the instance size that you want. For example,\n `m6g.medium`. For a complete list, see\n [Supported AWS instance types](/kubernetes-engine/multi-cloud/docs/aws/reference/supported-instance-types#supported_instance_types).\n- \u003cvar translate=\"no\"\u003eROOT_VOLUME_SIZE\u003c/var\u003e: the desired size for each node's root\n volume, in Gb\n\n- \u003cvar translate=\"no\"\u003eNODEPOOL_PROFILE\u003c/var\u003e: the IAM instance profile\n for node pool VMs\n\n- \u003cvar translate=\"no\"\u003eNODE_VERSION\u003c/var\u003e: the Kubernetes version to install on each\n node in the node pool, which must be version 1.24 or later. For example,\n `1.24.3-gke.200`.\n\n- \u003cvar translate=\"no\"\u003eMIN_NODES\u003c/var\u003e: the minimum number of nodes the node pool can\n contain\n\n- \u003cvar translate=\"no\"\u003eMAX_NODES\u003c/var\u003e: the maximum number of nodes the node pool can\n contain\n\n- \u003cvar translate=\"no\"\u003eMAX_PODS_PER_NODE\u003c/var\u003e: the maximum number of Pods that can be\n created on any single node in the pool\n\n- \u003cvar translate=\"no\"\u003eGOOGLE_CLOUD_LOCATION\u003c/var\u003e: the name of the Google Cloud\n\n location from which this node pool will be managed\n- \u003cvar translate=\"no\"\u003eNODEPOOL_SUBNET\u003c/var\u003e: the ID of the subnet the node pool will\n run on. If this subnet is outside of the VPC's primary CIDR block, you need\n to take additional steps. For more information, see\n [security groups](/kubernetes-engine/multi-cloud/docs/aws/reference/security-groups).\n\n- \u003cvar translate=\"no\"\u003eSSH_KEY_PAIR_NAME\u003c/var\u003e: the name of the AWS SSH key pair\n created for SSH access (optional)\n\n- \u003cvar translate=\"no\"\u003eCONFIG_KMS_KEY_ARN\u003c/var\u003e: the Amazon Resource Name (ARN) of the\n AWS KMS key that encrypts user data\n\nUnderstand multi-architecture images\n------------------------------------\n\nContainer images must be compatible with the architecture of the node where you\nintend to run the Arm workloads. To ensure that your container image is\nArm-compatible, we recommend that you use multi-architecture (\"multi-arch\")\nimages.\n\nA multi-arch image is an image that can support multiple architectures. It looks\nlike a single image with a single tag, but contains a set of images to run\non different machine architectures. Multi-arch images are\ncompatible with the Docker Image Manifest V2 Scheme 2 or OCI Image Index\nSpecifications.\n\nWhen you deploy a multi-arch image to a cluster, the container runtime\nautomatically chooses the image that is compatible with the architecture of the\nnode you're deploying to. Once you have a multi-arch image for a workload, you\ncan deploy this workload across multiple architectures. Scheduling a\nsingle-architecture image onto an incompatible node causes an error at load\ntime.\n\nTo learn more about how to use multi-arch images with Arm workloads, see\n[Build multi-architecture images for Arm workloads](/kubernetes-engine/docs/how-to/build-multi-arch-for-arm)\nin the Google Kubernetes Engine (GKE) documentation.\n\nWhat's next\n-----------\n\n- [Troubleshoot Arm workloads](/kubernetes-engine/multi-cloud/docs/aws/troubleshooting#troubleshoot-arm)."]]
