Questa pagina mostra come configurare i deployment GKE Autopilot per richiedere nodi basati sull'architettura Arm.
Informazioni sull'architettura Arm in Autopilot
I cluster Autopilot offrono
classi di calcolo
per i carichi di lavoro che hanno requisiti hardware specifici. Alcune di queste classi di calcolo supportano più architetture CPU, come amd64
e arm64
.
Casi d'uso per i nodi Arm
I nodi con architettura Arm offrono prestazioni più convenienti rispetto a nodi x86 simili. Devi selezionare Arm per i tuoi carichi di lavoro Autopilot in situazioni come le seguenti:
- Il tuo ambiente si basa sull'architettura Arm per la creazione e il test.
- Stai sviluppando applicazioni per dispositivi Android che vengono eseguite su CPU Arm.
- Utilizzi immagini multi-architettura e vuoi ottimizzare i costi durante l'esecuzione dei tuoi workload.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
installala e poi
inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo
gcloud components update
.
- Esamina i requisiti e le limitazioni per i nodi Arm.
- Assicurati di avere una quota per i tipi di macchine di Compute Engine C4A o Tau T2A.
- Assicurati di avere un pod con un'immagine container creata per l'architettura Arm.
Come richiedere nodi Arm in Autopilot
Per indicare ad Autopilot di eseguire i pod sui nodi Arm, specifica una delle seguenti etichette in una regola nodeSelector o node affinity:
kubernetes.io/arch: arm64
. GKE posiziona i pod sui tipi di macchineC4A
per impostazione predefinita per i cluster che eseguono la versione 1.31.3-gke.1056000 e successive. Se il cluster esegue una versione precedente, GKE posiziona i pod sui tipi di macchinaT2A
.cloud.google.com/machine-family: ARM_MACHINE_SERIES
. SostituisciARM_MACHINE_SERIES
con una serie di macchine Arm comeC4A
oT2A
. GKE posiziona i pod nella serie specificata.
Per impostazione predefinita, l'utilizzo di una delle etichette consente a GKE di posizionare altri pod
sullo stesso nodo se è disponibile capacità su quel nodo. Per richiedere un
nodo dedicato per ogni pod, aggiungi l'etichetta cloud.google.com/compute-class:
Performance
al manifest. Per maggiori dettagli, vedi Ottimizzare le prestazioni del pod Autopilot scegliendo una serie di macchine.
In alternativa, puoi utilizzare l'etichetta Scale-Out
con l'etichetta arm64
per richiedere T2A
.
Puoi anche richiedere l'architettura Arm per i pod spot.
Quando esegui il deployment del workload, Autopilot esegue le seguenti operazioni:
- Esegue automaticamente il provisioning dei nodi Arm per eseguire i pod.
- Contrassegna automaticamente i nuovi nodi per impedire la pianificazione di pod non Arm su questi nodi.
- Aggiunge automaticamente una tolleranza ai pod Arm per consentire la pianificazione sui nuovi nodi.
Esempio di richiesta per l'architettura Arm
Le seguenti specifiche di esempio mostrano come utilizzare un selettore di nodi o una regola di affinità dei nodi per richiedere l'architettura Arm in Autopilot.
nodeSelector
Il seguente manifest di esempio mostra come richiedere nodi Arm in un nodeSelector:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-arm
spec:
replicas: 3
selector:
matchLabels:
app: nginx-arm
template:
metadata:
labels:
app: nginx-arm
spec:
nodeSelector:
cloud.google.com/compute-class: Performance
kubernetes.io/arch: arm64
containers:
- name: nginx-arm
image: nginx
resources:
requests:
cpu: 2000m
memory: 2Gi
nodeAffinity
Puoi utilizzare l'affinità dei nodi per richiedere nodi Arm. Puoi anche specificare il tipo di affinità dei nodi da utilizzare:
requiredDuringSchedulingIgnoredDuringExecution
: Deve utilizzare la classe di computing e l'architettura specificate.preferredDuringSchedulingIgnoredDuringExecution
: utilizza la classe di computing e l'architettura specificate in base al massimo impegno. Ad esempio, se un nodo x86 esistente è allocabile, GKE inserisce il pod sul nodo x86 anziché eseguire il provisioning di un nuovo nodo Arm. A meno che tu non utilizzi un manifest di immagini multi-architettura, il pod si arresterà in modo anomalo. Ti consigliamo vivamente di richiedere esplicitamente l'architettura specifica che ti interessa.
Il seguente file manifest di esempio richiede la classe Performance
e i nodi Arm:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-arm
spec:
replicas: 3
selector:
matchLabels:
app: nginx-arm
template:
metadata:
labels:
app: nginx-arm
spec:
terminationGracePeriodSeconds: 25
containers:
- name: nginx-arm
image: nginx
resources:
requests:
cpu: 2000m
memory: 2Gi
ephemeral-storage: 1Gi
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/compute-class
operator: In
values:
- Performance
- key: kubernetes.io/arch
operator: In
values:
- arm64
Consigli
- Crea e utilizza immagini multi-arch come parte della tua pipeline. Le immagini multi-architettura assicurano che i pod vengano eseguiti anche se sono posizionati su nodi x86.
- Richiedi esplicitamente le classi di architettura e di calcolo nei manifest dei carichi di lavoro. In caso contrario, Autopilot utilizza l'architettura predefinita della classe di computing selezionata, che potrebbe non essere Arm.
Disponibilità
Puoi eseguire il deployment dei carichi di lavoro Autopilot sull'architettura Arm nelle Google Cloud posizioni che supportano l'architettura Arm. Per maggiori dettagli, consulta Regioni e zone disponibili.
Risoluzione dei problemi
Per informazioni sugli errori comuni e sulla risoluzione dei problemi, consulta Risoluzione dei problemi dei carichi di lavoro Arm.
Passaggi successivi
- Scopri di più sull'architettura dei cluster Autopilot.
- Scopri di più sul ciclo di vita dei pod.
- Scopri di più sulle classi di computing Autopilot disponibili.
- Scopri di più sulle richieste di risorse predefinite, minime e massime per ogni piattaforma.