Esegui carichi di lavoro ARM in GKE su AWS

GKE su AWS consente di eseguire carichi di lavoro ARM creati per i processori AWS Graviton basati su Arm.

Limitazioni

  • I pool di nodi ARM che eseguono versioni di Kubernetes precedenti alla 1.24.8-gke.1300 aggiungono automaticamente un'incompatibilità durante la creazione del pool di nodi per impedire la pianificazione dei carichi di lavoro Arm su nodi non Arm. I pool di nodi ARM nei cluster con versione 1.24.8-gke.1300 o successive non aggiungono più questa incompatibilità. Se esegui l'upgrade da un cluster precedente alla versione 1.24.8-gke.1300, devi creare questa incompatibilità o tenerla in considerazione durante l'upgrade.

  • I pool di nodi ARM su GKE su AWS non supportano Anthos Service Mesh, Config Sync o Policy Controller. Devi eseguire questi prodotti su un pool di nodi x86.

  • I cluster che eseguono Kubernetes versione 1.24 richiedono un pool di nodi x86 per eseguire l'agente Connect. Se il tuo cluster esegue Kubernetes 1.25 o versioni successive, non hai bisogno di un pool di nodi x86.

Questa pagina spiega come creare un pool di nodi Arm, perché le immagini multi-architettura sono il metodo consigliato per eseguire il deployment dei carichi di lavoro Arm e come pianificare i carichi di lavoro ARM.

Prima di iniziare

Prima di creare pool di nodi per i carichi di lavoro ARM, hai bisogno delle seguenti risorse:

  • Un cluster AWS esistente in cui creare il pool di nodi. Questo cluster deve eseguire Kubernetes 1.24 o versioni successive.
  • Un profilo di istanza IAM per le VM del pool di nodi.
  • Una subnet in cui verranno eseguite le VM del pool di nodi.

  • Se nel cluster è in esecuzione Kubernetes versione 1.24, un pool di nodi x86 per eseguire l'agente Connect.

    Per maggiori dettagli su come creare un pool di nodi in GKE su AWS, consulta Creare un pool di nodi.

Crea un pool di nodi Arm

GKE su AWS supporta i pool di nodi creati sull'immagine minima dei nodi arm64 di Canonical Ubuntu e il runtime containerd.

Per creare un pool di nodi Arm e aggiungerlo a un cluster esistente, esegui questo 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

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome che scegli 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 istanza:

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

    • g5g

      Questi tipi di istanza sono basati su processori AWS Graviton basati su Arm. Devi anche specificare la dimensione dell'istanza che preferisci. Ad esempio, m6g.medium. Per un elenco completo, vedi Tipi di istanze AWS supportati.

  • ROOT_VOLUME_SIZE: la dimensione desiderata per il volume principale di ciascun nodo, in GB

  • NODEPOOL_PROFILE: il profilo dell'istanza IAM per le VM del pool di nodi

  • NODE_VERSION: la versione di Kubernetes da installare su ciascun nodo nel pool di nodi, che deve essere 1.24 o successiva. Ad esempio, 1.24.3-gke.200.

  • MIN_NODES: il numero minimo di nodi che il pool di nodi può contenere

  • MAX_NODES: il numero massimo di nodi che il pool di nodi può contenere

  • MAX_PODS_PER_NODE: il numero massimo di pod che possono essere creati su qualsiasi singolo nodo nel pool

  • GOOGLE_CLOUD_LOCATION: il nome di Google Cloud

    località 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 si trova all'esterno del blocco CIDR principale del VPC, devi eseguire alcuni passaggi aggiuntivi. Per maggiori informazioni, vedi gruppi di sicurezza.

  • SSH_KEY_PAIR_NAME: il nome della coppia di chiavi SSH di AWS creata per l'accesso SSH (facoltativo)

  • CONFIG_KMS_KEY_ARN: l'Amazon Resource Name (ARN) della chiave KMS AWS che cripta i dati utente

Comprendere le immagini con più architetture

Le immagini container devono essere compatibili con l'architettura del nodo in cui intendi eseguire i carichi di lavoro ARM. Per assicurarti che l'immagine container sia compatibile con Arm, ti consigliamo di utilizzare immagini con più architetture ("multi-arch").

Un'immagine multi-arco è un'immagine in grado di supportare più architetture. Sembra una singola immagine con un singolo tag, ma contiene un insieme di immagini da eseguire su diverse architetture di macchine. Le immagini multi-arch sono compatibili con le specifiche Docker Image Manifest V2 Scheme 2 o OCI Image Index.

Quando esegui il deployment di un'immagine multi-arch in un cluster, il runtime del container sceglie automaticamente l'immagine compatibile con l'architettura del nodo in cui stai eseguendo il deployment. Dopo aver ottenuto un'immagine multi-arch per un carico di lavoro, puoi eseguire il deployment del carico di lavoro in più architetture. La pianificazione di un'immagine con architettura singola su un nodo incompatibile causa un errore al momento del caricamento.

Per saperne di più su come utilizzare immagini multi-arch con i carichi di lavoro ARM, consulta Creare immagini con più architetture per i carichi di lavoro ARM nella documentazione di Google Kubernetes Engine (GKE).

Passaggi successivi