Questa pagina spiega come preparare un workload per la pianificazione su nodi Arm in un cluster GKE Standard. Per scoprire di più sulla pianificazione dei workload Arm con Autopilot, consulta Esegui il deployment dei workload Autopilot sull'architettura Arm.
Per pianificare correttamente un workload su un nodo Arm, devi disporre di quanto segue:
- Un'immagine container compatibile con Arm. Per indicazioni su come verificare questo aspetto, consulta Il mio workload è pronto per Arm?
- Nodi Arm in cui è possibile pianificare i workload compatibili con Arm. Per creare le risorse necessarie, consulta Crea cluster e node pool con nodi Arm.
- Un cluster in una regione o zona Google Cloud con macchine virtuali (VM) Arm disponibili. Per una tabella filtrabile dei tipi di macchina e delle piattaforme, consulta Regioni e zone disponibili.
Panoramica
Per impostazione predefinita, GKE pianifica i workload solo su nodi basati su x86 (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, puoi rimuovere questa contaminazione predefinita per consentire la pianificazione dei workload compatibili con x86 sui nodi Arm senza la tolleranza corrispondente. Per saperne di più, consulta Configura il taint predefinito dell'architettura Arm.
Se vuoi eseguire il deployment di un workload in un nodo Arm con la contaminazione predefinita, utilizza i campi descritti in questo documento per guidare lo scheduler nell'invio del workload al tipo di nodo richiesto.
Utilizza uno dei seguenti campi:
- Un selettore di nodi.
- Una regola di affinità dei nodi.
Quando utilizzi un selettore di nodi o una regola di affinità dei nodi, GKE pianifica i workload compatibili con Arm solo se hai dichiarato che l'immagine container del workload 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 alla tolleranza (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 Utilizza la tolleranza per pianificare i 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 di nodi specifica che questo workload deve essere pianificato solo su 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 in modo che corrisponda alla contaminazione per 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 workload.
Pianifica il workload su 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à nodo specifica che il workload deve essere pianificato solo su 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 in modo che corrisponda alla contaminazione per consentire la pianificazione del workload sui nodi Arm.
Pianifica il workload su architetture x86 e Arm
Se vuoi pianificare un workload su architetture x86 (processori Intel e AMD) e Arm e i tuoi node pool Arm utilizzano il comportamento di taint predefinito, puoi specificarlo in modi diversi. Le seguenti istruzioni presuppongono che i tuoi node pool Arm utilizzino la contaminazione predefinita.
Utilizza la tolleranza per la pianificazione di workload multi-architettura su qualsiasi architettura
Se hai un'immagine multi-arch 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é la pianificazione del workload può essere eseguita su tutti i tipi di architettura.
Aggiungi la tolleranza:
tolerations:
- key: kubernetes.io/arch
operator: Equal
value: arm64
effect: NoSchedule
Utilizzando questa tolleranza, GKE potrebbe pianificare un workload su 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 multi-arch e la tolleranza arm64 nella configurazione del workload, GKE potrebbe pianificare il workload in tutti i node pool.
Utilizza la regola di affinità dei nodi per pianificare i workload multi-architettura su qualsiasi architettura
Se vuoi che un workload venga pianificato su nodi di diversi tipi di architettura, tra cui x86 e Arm, puoi anche utilizzare una regola di affinità dei nodi. Con le regole di affinità dei nodi, puoi specificare esattamente su quali tipi di architettura vuoi pianificare il workload. Questo approccio è consigliato per la pianificazione dei workload sui cluster Autopilot. Per scoprire di più, consulta Esegui il deployment dei workload Autopilot sull'architettura Arm.
Con i workload 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 su nodi basati su x86, non è necessario utilizzare questi campi.
Per pianificare i workload su qualsiasi tipo di architettura, elenca sia arm64 che amd64 nella sezione values del campo di affinità dei nodi. amd64 include tutti i nodi
che utilizzano processori x86.
L'esempio seguente specifica che questo workload potrebbe 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:
arm64per i nodi che utilizzano processori Arm (ad esempio, C4A).amd64per i nodi che utilizzano processori AMD (ad esempio Tau T2D) o i nodi che utilizzano processori Intel (ad esempio C2).
Ad esempio, se hai un cluster con i seguenti node pool e la regola di affinità dei nodi specificata:
- 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-arch 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 node pool.
Configura il taint predefinito dell'architettura Arm
Per impostazione predefinita, GKE applica un taint a tutti i nodi Arm con il taint kubernetes.io/arch=arm64:NoSchedule. 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 disabilitare questa incompatibilità per consentire a GKE di pianificare questi workload sui nodi Arm senza bisogno di una tolleranza corrispondente all'incompatibilità.
Puoi aggiornare il comportamento predefinito solo nei node pool Standard nei cluster GKE in cui il control plane esegue la versione 1.35.0-gke.2141000 o successive o con i nodi creati per le ComputeClass personalizzate. Per saperne di più, consulta Configura il taint predefinito dell'architettura Arm. L'aggiornamento del comportamento dei 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 con i pool di nodi Standard:
- 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 la contaminazione predefinita, perché i workload incompatibili potrebbero essere pianificati sui nodi Arm non contaminati.
Per configurare il taint dei nodi 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=BEHAVIORCrea 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=BEHAVIORAggiorna 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 località di Compute Engine del control plane del tuo cluster. Specifica una regione per i cluster regionali o una zona per i cluster di zona.POOL_NAME: il nome del pool di nodi.BEHAVIOR: una delle seguenti impostazioni:none: GKE omette il taint predefinito dikubernetes.io/arch=arm64:NoSchedule.arm: imposta esplicitamente il comportamento predefinito, che aggiunge i taintkubernetes.io/arch=arm64:NoScheduleper tutti i nodi nel pool di nodi Arm.
Quando modifichi il comportamento del 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 del taint dell'architettura:
taint_config {
architecture_taint_behavior = "BEHAVIOR"
}
Sostituisci BEHAVIOR con una delle seguenti impostazioni:
NONE: GKE omette il taint predefinito dikubernetes.io/arch=arm64:NoSchedule.ARM: imposta esplicitamente il comportamento predefinito, che aggiunge le contaminazionikubernetes.io/arch=arm64:NoScheduleper 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 località del control plane del cluster.
Esegui il deployment del workload
Ora che hai specificato dove devono essere pianificati i workload compatibili con Arm, puoi eseguirne il deployment.
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 per qualsiasi altro workload, a condizione che tu abbia completato i passaggi dei prerequisiti. Per vedere esempi di deployment dei workload, consulta le seguenti pagine:
- Deployment di un'applicazione Linux stateless.
- Deployment di un'applicazione stateful.
- Esecuzione di un job.
Risoluzione dei problemi
Per informazioni sugli errori comuni e sulla risoluzione dei problemi, consulta Risoluzione dei problemi relativi ai workload Arm.