Best practice per ComputeClasses

Gli ingegneri della piattaforma possono utilizzare ComputeClasses personalizzate per configurare in modo dichiarativo le impostazioni dei nodi e le priorità di fallback che Google Kubernetes Engine (GKE) utilizza per creare i nodi durante la scalabilità automatica. Puoi creare ComputeClass in base a strategie specifiche e requisiti dei workload. Questo documento fornisce le best practice per la progettazione e l'implementazione di ComputeClass nei cluster. Dovresti già avere familiarità con le ComputeClass personalizzate. Per una panoramica consolidata di tutte le best practice di GKE, consulta Best practice per GKE.

Progettazione di ComputeClass

Le sezioni seguenti forniscono le best practice per la progettazione e l'implementazione di ComputeClass nei cluster in base a obiettivi come la massimizzazione dell'ottenibilità e delle prestazioni. Le ComputeClass funzionano sia con i node pool creati manualmente sia con quelli creati automaticamente.

Progettare ogni ComputeClass in base a una strategia

Progetta ogni ComputeClass in modo che soddisfi un obiettivo specifico per i tuoi workload, team o organizzazione. Utilizza il comportamento di fallback di ComputeClass e la possibilità di selezionare sia i node pool creati manualmente sia quelli creati automaticamente per dare la priorità a determinati risultati, ad esempio ridurre l'overhead manuale o migliorare le prestazioni di pianificazione. Le sezioni seguenti descrivono le strategie comuni.

Migliorare l'ottenibilità e ridurre l'overhead manuale

Per delegare la creazione di pool di nodi a GKE, utilizza solo i node pool creati automaticamente in ComputeClass. Il gestore della scalabilità automatica configura i nodi in base alla disponibilità dell'hardware, ai requisiti delle risorse dei pod e alla capacità di zona. Questa strategia elimina la necessità di creare e ottimizzare manualmente i node pool e può ridurre i costi associati alla capacità dei nodi inattiva e inutilizzata.

Migliorare le prestazioni di pianificazione e ottimizzare i nodi

Per ottimizzare i nodi con la priorità più alta e ridurre la latenza di pianificazione, utilizza un mix di node pool creati manualmente e creati automaticamente in ComputeClass. Questa strategia ibrida riduce la frequenza con cui i pod attendono la creazione di nuovi node pool da parte di GKE. Poiché i node pool con la priorità più alta vengono creati manualmente, puoi ottimizzare l'hardware per soddisfare i requisiti esatti dei pod.

La strategia ibrida prevede i seguenti tipi di node pool in ordine di priorità in ComputeClass:

  1. Node pool creati manualmente: questi node pool hanno le specifiche esatte su cui vuoi che vengano eseguiti la maggior parte dei pod. Configura questi node pool con etichette dei nodi, taints dei nodi, prenotazioni di capacità o configurazioni speciali come i parametri kubelet. Crea questi node pool con il numero di nodi che stimi che i pod avranno bisogno. In ComputeClass, assegna la priorità più alta a questi node pool.
  2. Node pool creati automaticamente: come misura di fallback, utilizza ComputeClass per richiedere node pool aggiuntivi che siano comunque ottimizzati per i pod. Assegna una priorità inferiore a questi node pool creati automaticamente rispetto ai node pool creati manualmente.

La seguente ComputeClass di esempio utilizza questa strategia ibrida:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

Quando esegui il deployment di un workload che utilizza questa ComputeClass, GKE inserisce i pod sui nodi disponibili in manual-pool1. GKE crea nuovi node pool solo quando il pool di nodi creato manualmente non ha capacità disponibile. La latenza di pianificazione diminuisce quando aumenta il numero di nodi esistenti nel pool di nodi creato manualmente, perché GKE non deve creare nuovi nodi con la stessa frequenza.

Definire esplicitamente il comportamento di scalabilità di ultima risorsa

Il campo whenUnsatisfiable controlla cosa succede se GKE non riesce a soddisfare i requisiti di nessuna delle regole di priorità in una ComputeClass. Per evitare comportamenti imprevisti dopo un upgrade della versione, specifica esplicitamente un valore per questo campo in ogni ComputeClass. L'impostazione di un valore aiuta gli utenti di ComputeClass a sapere cosa aspettarsi quando selezionano ComputeClass in un workload. Il valore consigliato per questo campo dipende dal tipo di workload, come segue:

  • Workload per uso generico: se i tuoi workload possono essere eseguiti su qualsiasi serie di macchine, specifica un valore di ScaleUpAnyway. Se i nodi che corrispondono a una regola di priorità in ComputeClass non sono disponibili, GKE esegue lo scale up dei nodi che utilizzano la serie di macchine predefinita del cluster.
  • Workload che richiedono hardware specializzato: per i workload di acceleratori o di computing ad alte prestazioni che dipendono da hardware specifico, come GPU o determinate serie di macchine Compute Engine, specifica un valore di DoNotScaleUp. Se i nodi che corrispondono a una regola di priorità in ComputeClass non sono disponibili, i pod rimangono nello stato Pending finché le risorse non diventano disponibili. Questo approccio impedisce l'esecuzione dei pod su hardware incompatibile.

Per saperne di più, consulta Definire il comportamento di scalabilità quando non si applicano regole di priorità apply.

Impostare una ComputeClass predefinita a livello di cluster per la maggior parte dei workload

Se la maggior parte dei tuoi workload ha gli stessi requisiti hardware, configura una ComputeClass predefinita per il cluster. GKE applica la ComputeClass predefinita a tutti i workload che non selezionano esplicitamente una ComputeClass. Impostando una ComputeClass predefinita, gli operatori delle applicazioni non devono modificare i selettori di nodi o richiedere manualmente hardware e node pool specifici nei singoli pod. Se imposti una ComputeClass predefinita a livello di cluster, non aggiungere etichette e taints dei nodi per altre ComputeClass ai node pool esistenti nel cluster. Durante la pianificazione per la ComputeClass predefinita a livello di cluster, GKE ignora tutti i node pool che hanno etichette o taints dei nodi per altre ComputeClass.

Impostare ComputeClass predefinite per gli spazi dei nomi per separare i tenant

Oltre a una ComputeClass predefinita a livello di cluster, puoi impostare una ComputeClass predefinita per spazi dei nomi specifici. Se hai ambienti multi-tenant o vuoi separare i workload eseguiti su hardware specializzato, configura le ComputeClass predefinite per questi spazi dei nomi. Per impedire l'esecuzione dei pod di sistema su hardware specializzato come i nodi GPU, aggiungi una ComputeClass per uso generico come ComputeClass predefinita per gli spazi dei nomi di sistema.

Eseguire workload a bassa interazione in modalità Autopilot

Se hai workload che non richiedono interazione o gestione manuale, esegui questi workload in modalità Autopilot utilizzando ComputeClass. Puoi attivare la modalità Autopilot in qualsiasi ComputeClass, anche se hai un cluster Standard. GKE esegue i workload che selezionano una ComputeClass Autopilot su nodi completamente gestiti che implementano le funzionalità di sicurezza, scalabilità e fatturazione di GKE Autopilot. Per saperne di più, consulta Informazioni sulla modalità Autopilot workload in GKE Standard.

Workload stateful

Le sezioni seguenti forniscono le best practice per ridurre le interruzioni o i comportamenti imprevisti nei workload stateful che si basano su dati permanenti.

Disabilitare la migrazione attiva

La migrazione attiva sposta automaticamente i pod su nuovi nodi con una priorità più alta in ComputeClass o con la capacità di eseguire i pod DaemonSet non pianificati. Durante la migrazione attiva, GKE termina i pod sui nodi esistenti e crea nuovi pod sui nodi con priorità più alta. Se hai workload che si basano sui dati nell'archiviazione permanente locale, lo spostamento dei pod su nuovi nodi potrebbe causare interruzioni perché i pod perdono l'accesso ai dati permanenti. Per evitare questo problema, disattiva la migrazione attiva per le ComputeClass destinate ai workload stateful.

Migliorare l'affidabilità della pianificazione utilizzando StorageClass

Utilizza StorageClass per migliorare l'affidabilità della pianificazione per i workload stateful nei seguenti modi:

  • Creare volumi solo dopo la creazione dei pod: se utilizzi il provisioning dinamico dei volumi, specifica un valore di WaitForFirstConsumer nel volumeBindingMode campo in una StorageClass. Questa modalità di binding dei volumi impedisce la creazione di un PersistentVolume fino a quando GKE non crea un pod che utilizza il PersistentVolumeClaim corrispondente. GKE esegue il provisioning di PersistentVolume nella stessa zona del nodo che esegue il pod.
  • Utilizzare StorageClass con riconoscimento della topologia:se ComputeClass si estende su più generazioni di una serie di macchine (ad esempio, C4 e C3), utilizza una StorageClass con la selezione automatica del tipo di disco abilitata e che esegue la pianificazione solo sui nodi che supportano i tipi di disco specificati. Puoi utilizzare la StorageClass dynamic-rwo integrata o una StorageClass personalizzata. I workload stateful possono essere eseguiti su più generazioni di istanze Compute Engine, perché il gestore della scalabilità automatica dei cluster sceglie dinamicamente un tipo di disco compatibile.

Ottenibilità

Le sezioni seguenti forniscono le best practice per migliorare l'ottenibilità in ComputeClass, in modo che i pod trascorrano meno tempo nello stato Pending.

Richiedere serie di macchine anziché tipi di macchine

Puoi richiedere una serie di macchine Compute Engine o tipi di macchine specifici nelle regole di priorità di ComputeClass. A meno che tu non abbia una dipendenza rigorosa da un tipo di macchina specifico, seleziona una serie di macchine utilizzando il machineFamily campo. Durante un'operazione di scalabilità, GKE può creare nodi che utilizzano qualsiasi tipo di macchina praticabile in quella serie di macchine, il che migliora la probabilità che i pod vengano eseguiti sulla configurazione dei nodi preferita.

Utilizzare le prenotazioni di capacità per l'hardware su richiesta

Se i tuoi workload si basano su hardware su richiesta, come TPU o GPU ad alte prestazioni, crea prenotazioni di capacità di Compute Engine per l'hardware e utilizza queste prenotazioni in ComputeClass. Le prenotazioni di capacità migliorano la probabilità che l'hardware sia disponibile nella tua regione o zona, il che ti aiuta ad aumentare l'ottenibilità delle risorse. Per utilizzare una prenotazione in ComputeClass senza influire sul comportamento di fallback, utilizza l'affinità di prenotazione Specific o AnyThenFail. Se utilizzi l'affinità AnyBestEffort o Automatic e non è disponibile capacità riservata, Compute Engine potrebbe ignorare le regole di priorità di ComputeClass e eseguire il fallback all'hardware on demand. Per saperne di più, consulta Utilizzare le risorse di zona riservate.

Non utilizzare le nuove prenotazioni per almeno un'ora

Il gestore della scalabilità automatica dei cluster archivia le informazioni sulle prenotazioni di capacità in una cache. Quando crei una nuova prenotazione di capacità, il gestore della scalabilità automatica potrebbe impiegare fino a un'ora per rilevarla. Dopo aver creato una prenotazione, attendi almeno un'ora prima di utilizzarla in un workload. Se esegui il deployment di un workload che utilizza la prenotazione prima che il gestore della scalabilità automatica la memorizzi nella cache, l'operazione di scalabilità automatica potrebbe non riuscire.

Sicurezza

Le sezioni seguenti forniscono le best practice per migliorare la sicurezza di ComputeClass nei cluster. Queste misure sono importanti perché ComputeClass può essere utilizzata per creare e configurare nodi che utilizzano hardware costoso o con disponibilità limitata. L'uso improprio intenzionale o accidentale potrebbe causare interruzioni dei workload, addebiti imprevisti per l'utilizzo delle risorse e esaurimento della quota.

Limitare l'accesso API alle configurazioni di ComputeClass

I workload possono utilizzare ComputeClass per creare nodi che eseguono hardware specializzato, tra cui GPU e TPU. Limita l'accesso alla creazione, alla modifica e all'eliminazione di ComputeClass agli stessi principali che possono creare, modificare ed eliminare i nodi nei cluster. Per controllare l'accesso a ComputeClass, utilizza le policy RBAC.

Limitare la disponibilità di ComputeClass per spazio dei nomi

I clienti di GKE spesso separano team o tipi di workload diversi per spazio dei nomi Kubernetes. ComputeClass è una risorsa con ambito cluster, il che significa che per impostazione predefinita qualsiasi workload in qualsiasi spazio dei nomi può selezionare qualsiasi ComputeClass. Per evitare un uso improprio intenzionale o accidentale, utilizza ValidatingAdmissionPolicy per controllare l'insieme di ComputeClass che i workload in ogni spazio dei nomi possono selezionare. Ad esempio, potresti impedire ai pod nello spazio dei nomi del frontend web di selezionare ComputeClass che creano acceleratori. Verifica che ValidatingAdmissionPolicy controlli le seguenti configurazioni comuni:

  • Controllare tutti i campi di selezione:un workload può selezionare una ComputeClass utilizzando il campo nodeSelector, nodeAffinity o tolerations nella specifica del pod. Per evitare la selezione involontaria di ComputeClass, controlla tutti questi campi nelle espressioni ValidatingAdmissionPolicy.
  • Verificare i bypass di tolleranza con caratteri jolly:blocca o convalida esplicitamente le tolleranze con caratteri jolly (ad esempio, la tolleranza operator: Exists senza chiave). Questi selettori con caratteri jolly possono comprendere la maggior parte dei taints dei nodi, inclusi i taints di ComputeClass.
  • Controllare tutti i controller dei workload: configura matchConstraints della policy in modo che copra tutte le risorse del controller dei workload (ad esempio Deployment, StatefulSet, DaemonSet, Job e CronJob). Non limitare i controlli solo alle risorse Pod.

Per saperne di più, consulta Limitare l'accesso alla modifica e alla selezione di ComputeClass.

Affidabilità

Le sezioni seguenti forniscono le best practice per migliorare l'affidabilità della scalabilità automatica e della migrazione dei pod per ComputeClass, riducendo il rischio di interruzioni o pod bloccati.

Impedire l'utilizzo di selettori di nodi in conflitto

I selettori di nodi nei pod influiscono sulla posizione in cui GKE inserisce questi pod e, in modalità Autopilot o con la creazione automatica di pool di nodi, potrebbero attivare la creazione di nuovi node pool nel cluster. Se hai pod che selezionano una ComputeClass e utilizzano i selettori di nodi per richiedere nodi in conflitto con la configurazione di ComputeClass, GKE potrebbe non pianificare affatto i pod.

Ad esempio, considera una ComputeClass che richiede solo istanze on demand. Se un pod seleziona ComputeClass e seleziona le VM spot in un selettore di nodi, GKE non può pianificare il pod perché ComputeClass e il selettore di nodi sono in conflitto tra loro. Per evitare questo problema, utilizza metodi come ValidatingAdmissionPolicy per impedire ai pod che selezionano ComputeClass di selezionare anche le etichette dei nodi di sistema. Per saperne di più, consulta Selettori di nodi per le etichette dei nodi di sistema.

Testare tutte le modifiche alle impostazioni di migrazione attiva e scalabilità automatica

Le impostazioni di migrazione attiva e scalabilità automatica in ComputeClass influiscono direttamente sulla frequenza con cui GKE termina i pod per eseguire attività come lo spostamento dei pod su hardware preferito e il consolidamento dei nodi sottoutilizzati. Le modifiche a queste impostazioni in una ComputeClass esistente potrebbero causare interruzioni impreviste dei workload. Prima di applicare modifiche a queste impostazioni in ComputeClass esistenti, testa le modifiche in un ambiente di gestione temporanea. Puoi anche utilizzare le annotazioni per proteggere i workload critici dall'eliminazione durante la scalabilità.

Testare gli aggiornamenti di ComputeClass CRD prima degli upgrade del cluster

GKE aggiorna regolarmente la definizione di risorsa personalizzata (CRD) ComputeClass per aggiungere campi, modificare il comportamento dei campi e correggere i problemi. In genere, le aggiunte e le modifiche ai campi diventano effettive in versioni specifiche di GKE. Prima di eseguire l'upgrade dei cluster di produzione alle nuove versioni secondarie o patch, verifica se le modifiche alla CRD causano problemi ai workload utilizzando le seguenti linee guida:

Utilizzare PodDisruptionBudget per migliorare la disponibilità dei workload

Le operazioni di ComputeClass che causano l'eliminazione dei pod, come la migrazione attiva, rispettano tutti i PodDisruptionBudgets configurati. Ad esempio, puoi configurare un deployment di inferenza in modo che abbia un PodDisruptionBudget che richieda la disponibilità di oltre il 70% dei pod. Durante la migrazione attiva, se l'eliminazione di un pod viola il budget, GKE non elimina il pod. Specifica PodDisruptionBudget per workload come i seguenti:

  • Workload stateless, come i deployment di inferenza.
  • Workload stateful replicati, come le applicazioni di database ad alta disponibilità.

Non fare affidamento su PodDisruptionBudget per proteggere i workload che devono essere eseguiti fino al completamento, che hanno una sola istanza o che si basano su dati permanenti locali. Specifica un budget che bilanci la disponibilità dei workload e consenta il completamento di funzioni come gli upgrade.

Proteggere i workload critici dall'eliminazione

Se hai workload in cui ogni pod deve essere eseguito fino al completamento prima di essere terminato, aggiungi l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict: "false" alla specifica del pod. Questa annotazione impedisce a GKE di eliminare i pod durante le operazioni di scalabilità automatica. Utilizza questa annotazione per proteggere i pod che non possono tollerare interruzioni, come i workload stateful a istanza singola e i job batch a lunga esecuzione.

Riepilogo delle best practice

Questo documento contiene le seguenti best practice per ComputeClass:

Passaggi successivi