Esegui workload Arm in GKE su AWS

GKE su AWS consente di eseguire workload 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 sui nodi non Arm. I node pool 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 questo taint 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 node pool 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 nodi x86.

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

Prima di iniziare

Prima di creare node pool per i workload 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, consulta Creare un node pool.

Creare un pool di nodi Arm

GKE su AWS supporta i node pool basati sull'immagine del nodo minimale arm64 di Canonical Ubuntu e sul runtime containerd.

Per creare un pool di nodi Arm e aggiungerlo a un cluster esistente, esegui il comando seguente:

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 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 istanza sono basati sui processori AWS Graviton basati su Arm. Devi anche specificare le dimensioni dell'istanza che vuoi utilizzare. 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 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 della 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 si trova al di fuori del blocco CIDR principale del VPC, devi eseguire 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 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 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 di cui stai eseguendo il deployment. Una volta che hai un'immagine multi-arch 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 saperne di più su come utilizzare le immagini multi-arch con i workload Arm, consulta Creare immagini multi-architettura per i workload Arm nella documentazione di Google Kubernetes Engine (GKE).

Passaggi successivi