Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
GKE su AWS ti consente di eseguire carichi di lavoro Arm creati per i
processori AWS Graviton basati su Arm.
Limitazioni
I node pool Arm che eseguono versioni di Kubernetes precedenti alla 1.24.8-gke.1300
aggiungono automaticamente un taint durante la creazione pool di nodi per impedire la pianificazione dei workload Arm
su nodi non Arm. I pool di nodi Arm nei cluster con versione
1.24.8-gke.1300 o successive non aggiungono più questo taint. Se esegui l'upgrade da un cluster precedente alla versione 1.24.8-gke.1300, devi creare autonomamente questo stato di contaminazione o tenerlo in considerazione durante l'upgrade.
I pool di nodi Arm su GKE su AWS non supportano Cloud Service Mesh, Config Sync o Policy Controller. Devi eseguire questi prodotti in un pool di nodi x86.
I cluster che eseguono la versione 1.24 di Kubernetes richiedono un pool di nodi x86 per eseguire Connect Agent.
Se il tuo cluster esegue Kubernetes versione 1.25 o successive, non è necessario un
pool di nodi x86.
Questa pagina spiega come creare un pool di nodi Arm, perché
le immagini multipiattaforma sono il modo consigliato per eseguire il deployment dei workload Arm e
come pianificare i workload Arm.
Prima di iniziare
Prima di creare pool di nodi per i tuoi carichi di lavoro Arm, devi disporre delle seguenti risorse:
Un cluster AWS esistente in cui creare il pool di nodi. Questo cluster deve eseguire Kubernetes 1.24 o versioni successive.
NODE_POOL_NAME: il nome scelto per il pool di nodi
CLUSTER_NAME: il nome del cluster a cui collegare il pool di nodi
INSTANCE_TYPE: uno dei seguenti tipi di istanze:
m6g
m6gd
t4g
r6g
r6gd
c6g
c6gd
c6gn
x2gd
c7g
im4gn
g5g
Questi tipi di istanze sono basati su processori AWS Graviton basati su Arm.
Devi anche specificare le dimensioni dell'istanza che preferisci. Ad esempio,
m6g.medium. Per un elenco completo, consulta
Tipi di istanze AWS supportati.
ROOT_VOLUME_SIZE: la dimensione desiderata per il volume radice di ogni nodo, in GB
NODEPOOL_PROFILE: il profilo istanza IAM per le VM del pool di nodi
NODE_VERSION: la versione di Kubernetes da installare su ogni
nodo del pool di nodi, che deve essere la versione 1.24 o successiva. Ad esempio,
1.24.3-gke.200.
MIN_NODES: il numero minimo di nodi che può contenere il pool di nodi
MAX_NODES: il numero massimo di nodi che può contenere il pool di nodi
MAX_PODS_PER_NODE: il numero massimo di pod che possono essere
creati su un singolo nodo del pool
GOOGLE_CLOUD_LOCATION: il nome del Google Cloud
posizione da cui verrà gestito questo pool di nodi
NODEPOOL_SUBNET: l'ID della subnet su cui verrà eseguito il pool di nodi. Se questa subnet non rientra nel blocco CIDR principale del VPC, devi eseguire alcuni passaggi aggiuntivi. Per ulteriori informazioni, consulta
gruppi di sicurezza.
SSH_KEY_PAIR_NAME: il nome della coppia di chiavi SSH AWS creata per l'accesso SSH (facoltativo)
CONFIG_KMS_KEY_ARN: l'Amazon Resource Name (ARN) della chiave KMS di AWS che cripta i dati utente
Informazioni sulle immagini con più architetture
Le immagini dei container devono essere compatibili con l'architettura del nodo in cui intendi eseguire i workload ARM. Per assicurarti che l'immagine del contenitore sia compatibile con Arm, ti consigliamo di utilizzare immagini multi-architettura ("multi-arch").
Un'immagine multi-arch è un'immagine che può supportare più architetture. Sembra
una singola immagine con un singolo tag, ma contiene un insieme di immagini da eseguire
su architetture di macchine diverse. Le immagini multi-architettura sono compatibili con le specifiche dello schema 2 del manifest dell'immagine Docker o dell'indice delle immagini OCI.
Quando esegui il deployment di un'immagine multi-architettura in un cluster, il runtime del contenitore sceglie automaticamente l'immagine compatibile con l'architettura del nodo in cui esegui il deployment. Una volta creata un'immagine multi-architettura per un carico di lavoro, puoi eseguire il deployment di questo carico di lavoro su più architetture. La pianificazione di un'immagine con un'architettura singola su un nodo incompatibile causa un errore al momento del caricamento.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 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)."]]
