Preparati a eseguire il deployment di un workload Arm in un cluster standard

Questa pagina spiega come preparare un workload per la pianificazione sui nodi Arm in un cluster GKE Standard. Per saperne di più sulla pianificazione dei workload Arm con Autopilot, consulta Deployment dei workload Autopilot sull'architettura Arm.

Per pianificare correttamente un workload su un nodo Arm, devi disporre di quanto segue:

Panoramica

Per impostazione predefinita, GKE pianifica i workload solo su nodi basati su x86, ovvero serie di macchine Compute Engine con processori Intel o AMD, inserendo un taint (kubernetes.io/arch=arm64:NoSchedule) su tutti i nodi Arm. Questa incompatibilità impedisce la pianificazione involontaria di workload compatibili con x86 sui nodi Arm. Se vuoi che i workload compatibili con x86 vengano pianificati sui nodi Arm senza richiedere la tolleranza corrispondente, puoi rimuovere questo taint predefinito. Per saperne di più, consulta Configura il taint dell'architettura Arm predefinita.

Se vuoi eseguire il deployment di un workload su un nodo Arm con il taint predefinito, utilizza i campi descritti in questo documento per indicare allo scheduler di inviare il workload al tipo di nodo richiesto.

Utilizza uno dei seguenti campi:

Quando utilizzi un selettore di nodi o una regola di affinità dei nodi, GKE pianifica solo i carichi di lavoro compatibili con Arm quando hai dichiarato che l'immagine container del carico di lavoro può essere eseguita sull'architettura del nodo.

Se pianifichi un workload compatibile con Arm con un selettore di nodi o con una regola di affinità dei nodi come descritto nelle sezioni seguenti, GKE aggiunge automaticamente una tolleranza alla configurazione del workload in modo che i pod possano essere eseguiti sui nodi Arm.

Questa tolleranza aggiunta al workload corrisponde all'incompatibilità (kubernetes.io/arch=arm64:NoSchedule) aggiunta a tutti i nodi Arm, per impostazione predefinita, per consentire la pianificazione del workload sui nodi Arm.

In alcune situazioni, ad esempio quando hai immagini multi-architettura che possono essere eseguite su qualsiasi nodo, potresti voler aggiungere manualmente questa tolleranza alla configurazione del workload. Per istruzioni, consulta Utilizzare la tolleranza per la pianificazione di workload multi-architettura su qualsiasi architettura.

Utilizza un selettore di nodi per pianificare un workload Arm

Aggiungi il seguente selettore di nodi alla specifica:

nodeSelector:
    kubernetes.io/arch: arm64

Il selettore dei nodi specifica che questo workload deve essere pianificato solo per nodi con l'etichetta arm64, che hanno tutti i nodi Arm sui cluster GKE.

Quando questo selettore di nodi è incluso nella configurazione del workload, GKE aggiunge la tolleranza per corrispondere all'incompatibilità e consentire la pianificazione del workload sui nodi Arm.

Utilizza una regola di affinità dei nodi per pianificare un workload Arm

Puoi anche utilizzare l'affinità dei nodi per pianificare il carico di lavoro.

Pianifica il carico di lavoro per una singola architettura

Aggiungi la seguente affinità dei nodi alla specifica:

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64

La regola di affinità dei nodi specifica che il workload deve essere pianificato solo per i nodi con l'etichetta arm64, che hanno tutti i nodi Arm sui cluster GKE.

Quando questa regola di affinità nodo è inclusa nella configurazione del workload, GKE aggiunge la tolleranza per corrispondere all'incompatibilità e consentire la pianificazione del workload sui nodi Arm.

Pianificare il workload per le architetture x86 e Arm

Se vuoi pianificare un workload su architetture x86 (processori Intel e AMD) e Arm e i tuoi pool di nodi Arm utilizzano il comportamento di taint predefinito, puoi specificarlo in diversi modi. Le seguenti istruzioni presuppongono che i tuoi node pool Arm utilizzino il taint predefinito.

Utilizza la tolleranza per pianificare i workload multi-architettura in qualsiasi architettura

Se hai un'immagine multi-architettura che vuoi pianificare per qualsiasi tipo di architettura disponibile in un cluster Standard, devi solo aggiungere la tolleranza alla specifica del workload. Non hai bisogno del selettore di nodi o delle regole di affinità dei nodi descritte in questa pagina, poiché il workload può essere pianificato per tutti i tipi di architettura.

Aggiungi la tolleranza:

  tolerations:
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

Utilizzando questa tolleranza, GKE potrebbe programmare un workload per i nodi con qualsiasi tipo di architettura.

Ad esempio, se hai un cluster con i seguenti pool di nodi:

  • my-c4a-node-pool, utilizzando VM c4a-standard-16 (arm64).
  • my-c2-node-pool, utilizzando VM c2-standard-8 (amd64).
  • my-t2d-node-pool, utilizzando VM t2-standard-48 (amd64).

Se esegui il deployment in questo cluster di un workload che utilizza un'immagine multiazione e la tolleranza arm64 nella configurazione del workload, GKE potrebbe pianificare il workload in tutti i pool di nodi.

Utilizza la regola di affinità dei nodi per pianificare i workload multarchitettura su qualsiasi architettura

Se vuoi che un workload venga pianificato sui nodi in base ai tipi di architettura, inclusi x86 e Arm, puoi anche utilizzare una regola di affinità dei nodi. Con le regole di affinità dei nodi, puoi specificare esattamente i tipi di architettura su cui vuoi pianificare il workload. Questo approccio è consigliato per la pianificazione dei workload sui cluster Autopilot. Per saperne di più, consulta Deployment di workload Autopilot su architettura Arm.

Con i carichi di lavoro basati su x86, non hai bisogno di questi selettori di nodi, regole di affinità dei nodi o tolleranze per la pianificazione del workload. Se hai un'immagine che vuoi pianificare solo per i nodi basati su x86, non devi utilizzare questi campi.

Per pianificare i workload per qualsiasi tipo di architettura, elenca sia arm64 sia amd64 nella sezione values del campo di affinità dei nodi. amd64 include tutti i nodi che utilizzano processori x86.

Il seguente esempio specifica che questo workload può essere pianificato su nodi con processori Arm o x86:

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
            - amd64

Le etichette per ogni tipo di architettura sono:

Ad esempio, se hai un cluster con i seguenti pool di nodi e la seguente regola di affinità dei nodi:

  • my-c4a-node-pool, utilizzando VM c4a-standard-16 (arm64).
  • my-c2-node-pool, utilizzando VM c2-standard-8 (amd64).
  • my-t2d-node-pool, utilizzando VM t2-standard-48 (amd64).

Se esegui il deployment in questo cluster di un workload che utilizza un'immagine multi-architettura e l'affinità dei nodi con arm64 inclusa nell'elenco values, GKE aggiunge la tolleranza nella configurazione del workload e potrebbe pianificare il workload in tutti i pool di nodi.

Configura la taint dell'architettura Arm predefinita

Per impostazione predefinita, GKE applica il taint kubernetes.io/arch=arm64:NoSchedule a tutti i nodi Arm. Questa incompatibilità impedisce la pianificazione dei workload compatibili solo con l'architettura x86, ma non con l'architettura Arm, sui nodi Arm. Se hai workload compatibili sia con x86 che con Arm, puoi disattivare questo taint per consentire a GKE di pianificare questi workload sui nodi Arm senza bisogno di una tolleranza corrispondente al taint.

Puoi aggiornare il comportamento di taint predefinito solo nei node pool standard. L'aggiornamento del comportamento di taint non si applica al deployment dei workload Arm con Autopilot. Per saperne di più, consulta Esegui il deployment dei workload Autopilot sull'architettura Arm.

Puoi configurare questo comportamento nelle seguenti situazioni:

  • Durante la creazione del cluster, per il pool di nodi Standard predefinito
  • Quando crei o aggiorni un pool di nodi Standard

Se nel cluster sono in esecuzione workload non compatibili con Arm, non rimuovere il taint predefinito, perché i workload incompatibili potrebbero essere pianificati per i nodi Arm senza taint.

Per configurare il taint del nodo predefinito per i nodi Arm, seleziona una delle seguenti opzioni:

gcloud CLI

Per impostare il comportamento di taint con gcloud CLI, utilizza il flag --node-architecture-taint-behavior quando esegui una delle seguenti operazioni:

  • Crea un cluster Standard con un comportamento di taint specifico per il pool di nodi predefinito utilizzando il comando gcloud container cluster create:

    gcloud container cluster create CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Crea un pool di nodi Standard utilizzando il comando gcloud container node-pools create:

    gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Aggiorna un pool di nodi Standard utilizzando il comando gcloud container node-pools update:

    gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

Per questi comandi, sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.
  • POOL_NAME: il nome del tuo pool di nodi.

  • BEHAVIOR: una delle seguenti impostazioni:

    • none: GKE omette il taint predefinito di kubernetes.io/arch=arm64:NoSchedule.
    • arm: imposta esplicitamente il comportamento predefinito, che aggiunge i taint kubernetes.io/arch=arm64:NoSchedule per tutti i nodi nel pool di nodi Arm.

Quando modifichi il comportamento di taint dell'architettura dei nodi per un pool di nodi Standard, GKE aggiorna immediatamente i taint senza dover ricreare i nodi.

Terraform

Aggiungi il seguente blocco taint_config in node_config per configurare il comportamento di taint dell'architettura:

taint_config {
  architecture_taint_behavior = "BEHAVIOR"
}

Sostituisci BEHAVIOR con una delle seguenti impostazioni:

  • NONE: GKE omette il taint predefinito di kubernetes.io/arch=arm64:NoSchedule.
  • ARM: imposta esplicitamente il comportamento predefinito, che aggiunge le incompatibilità kubernetes.io/arch=arm64:NoSchedule per tutti i nodi nel pool di nodi Arm.

Un node_config completo per un pool di nodi Standard che include questo blocco ha il seguente aspetto:

resource "google_container_node_pool" "primary_preemptible_nodes" {
  name       = "NODE_POOL_NAME"
  location   = "NODE_POOL_LOCATION"
  cluster    = google_container_cluster.primary.name
  node_count = 1

  node_config {
    preemptible  = true
    machine_type = "ARM_MACHINE_TYPE"

    # Google recommends custom service accounts that have cloud-platform scope and permissions granted via IAM Roles.
    service_account = google_service_account.default.email
    oauth_scopes    = [
      "https://www.googleapis.com/auth/cloud-platform"
    ]
    taint_config {
      architecture_taint_behavior = "BEHAVIOR"
    }
  }
}

In questo esempio, NODE_POOL_NAME rappresenta il nome del pool di nodi e NODE_POOL_LOCATION rappresenta la posizione del control plane del cluster.

Esegui il deployment del workload

Ora che hai specificato dove devono essere pianificati i workload compatibili con Arm, puoi eseguire il deployment del workload.

Quando esegui il deployment di un workload in un cluster GKE, le istruzioni sono le stesse per tutti i tipi di architettura. Puoi eseguire il deployment di un workload compatibile con Arm come faresti con qualsiasi altro workload, a condizione che tu abbia completato i passaggi preliminari. Per visualizzare esempi di deployment di workload, consulta le seguenti pagine:

Risoluzione dei problemi

Per informazioni su errori comuni e risoluzione dei problemi, consulta la sezione Risoluzione dei problemi dei carichi di lavoro Arm.

Passaggi successivi