Esegui workload 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 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 alla versione 1.24.8-gke.1300 o successive non aggiungono più questa contaminazione. Se esegui l'upgrade da un cluster precedente alla versione 1.24.8-gke.1300, devi creare questa taint autonomamente o tenerne conto durante l'upgrade.

  • I node pool Arm su GKE su AWS non supportano Cloud 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 cluster esegue Kubernetes versione 1.25 o successive, non hai bisogno di un pool di nodil x86.

Questa pagina spiega come creare un pool di nodi Arm, perché le immagini multarchitettura sono il modo consigliato per eseguire il deployment dei workload Arm e come pianificare i workload Arm.

Prima di iniziare

Prima di creare i node pool per i 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 versione 1.24 o successive.
  • Un profilo istanza IAM per le VM del pool di nodi.
  • Una subnet in cui verranno eseguite le VM del pool di nodi.

  • Se il cluster esegue Kubernetes versione 1.24, un pool di nodi x86 per eseguire l'agente Connect.

    Per informazioni dettagliate su come creare un pool di nodi in GKE su AWS, vedi Creare un node pool.

Crea un pool di nodi Arm

GKE su AWS supporta i node pool basati sull'immagine del nodo minimale Canonical Ubuntu arm64 e sul 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 tuo pool di nodi
  • CLUSTER_NAME: il nome del cluster a cui collegare il node pool

  • INSTANCE_TYPE: uno dei seguenti tipi di istanza:

    • 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: le dimensioni desiderate per il volume di root di ogni 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 ogni nodo del pool di nodi, che deve essere la versione 1.24 o successive. 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 un singolo nodo del pool

  • GOOGLE_CLOUD_LOCATION: il nome di Google Cloud

    la 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 al di fuori del blocco CIDR principale del VPC, devi eseguire passaggi aggiuntivi. Per ulteriori informazioni, vedi 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 AWS KMS che cripta i dati utente

Informazioni sulle immagini multi-architettura

Le immagini container devono essere compatibili con l'architettura del nodo in cui intendi eseguire i workload Arm. Per assicurarti che l'immagine container 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 un'unica immagine con un unico tag, ma contiene un insieme di immagini da eseguire su diverse architetture di macchine. Le immagini multi-architettura sono compatibili con le specifiche Docker Image Manifest V2 Scheme 2 o OCI Image Index.

Quando esegui il deployment di un'immagine multi-architettura in un cluster, il runtime del container sceglie automaticamente l'immagine compatibile con l'architettura del nodo di cui stai eseguendo il deployment. Una volta che hai un'immagine multi-architettura per un workload, puoi eseguire il deployment di questo workload su più architetture. La pianificazione di un'immagine a singola architettura su un nodo incompatibile causa un errore in fase di caricamento.

Per scoprire di più su come utilizzare immagini multi-architettura con i workload Arm, consulta Creare immagini multi-architettura per i workload Arm nella documentazione di Google Kubernetes Engine (GKE).

Passaggi successivi