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 nodi durante la scalabilità automatica. Puoi creare ComputeClass in base a strategie e requisiti di workload specifici. 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 best practice per la progettazione e l'implementazione di ComputeClass nei cluster in base a obiettivi quali massimizzare la flessibilità, l'efficienza, la disponibilità e le prestazioni della capacità di calcolo. ComputeClasses funziona sia con i pool di nodi creati manualmente sia con quelli creati automaticamente.

Progetta 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 node pool creati manualmente e 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 la disponibilità delle risorse e ridurre l'overhead manuale

Per delegare la creazione pool di nodi a GKE, utilizza solo i node pool creati automaticamente nella tua ComputeClass. Il gestore della scalabilità automatica configura i nodi in base alla disponibilità dell'hardware, ai requisiti delle risorse dei pod e alla capacità zonale. Questa strategia elimina la necessità di creare e ottimizzare manualmente i pool di nodi 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 automaticamente in ComputeClass. Questa strategia ibrida riduce la frequenza con cui i pod attendono che GKE crei nuovi node pool. Poiché i pool di nodi con priorità più alta vengono creati manualmente, puoi ottimizzare l'hardware per soddisfare i requisiti esatti dei tuoi pod.

La strategia ibrida prevede i seguenti tipi di pool di nodi 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, taint dei nodi, prenotazioni di capacità o configurazioni speciali come i parametri kubelet. Crea questi node pool con tutti i nodi che stimi che i tuoi pod avranno bisogno. Nella tua ComputeClass, assegna la priorità più alta a questi pool di nodi.
  2. Pool di nodi creati automaticamente: come misura di fallback, utilizza ComputeClass per richiedere pool di nodi aggiuntivi ancora ottimizzati per i tuoi pod. Assegna una priorità inferiore a questi node pool creati automaticamente rispetto a quelli creati manualmente.

Il seguente esempio di ComputeClass 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 ilpool di nodil creato manualmente non ha capacità disponibile. La latenza di pianificazione diminuisce all'aumentare del numero di nodi esistenti nel pool di nodi creato manualmente, perché GKE non deve creare nuovi nodi con la stessa frequenza.

Definisci in modo esplicito il comportamento di scalabilità di ultima istanza

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 l'upgrade di una 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:

  • Carichi di lavoro per uso generico: se i tuoi carichi di lavoro 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 aumenta il numero di nodi che utilizzano la serie di macchine predefinita del cluster.
  • Carichi di lavoro che richiedono hardware specializzato: per acceleratori o carichi di lavoro di computing ad alte prestazioni che dipendono da hardware specifici, 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ù, vedi Definisci il comportamento di scalabilità quando non si applicano regole di priorità.

Imposta una ComputeClass predefinita a livello di cluster per la maggior parte dei carichi di lavoro

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 carichi di lavoro che non selezionano esplicitamente una ComputeClass. Se impostano una ComputeClass predefinita, gli operatori delle applicazioni non devono modificare i selettori dei nodi o richiedere manualmente node pool e hardware specifici nei singoli pod. Se imposti una ComputeClass predefinita a livello di cluster, non aggiungere etichette e taint dei nodi per altre ComputeClass ai pool di nodi esistenti nel cluster. Durante la pianificazione per la ComputeClass predefinita a livello di cluster, GKE ignora tutti i node pool con etichette o taint dei nodi per altre ComputeClass.

Imposta 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 carichi di lavoro eseguiti su hardware specializzato, allora configura 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.

Esegui carichi di lavoro a bassa interazione in modalità Autopilot

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

Workload stateful

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

Disattiva 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 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 carichi di lavoro che si basano su dati in uno spazio di 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 ComputeClass destinate ai carichi di lavoro stateful.

Migliora l'affidabilità della pianificazione utilizzando StorageClass

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

  • Crea volumi solo dopo la creazione del pod: se utilizzi il provisioning dinamico dei volumi, specifica un valore di WaitForFirstConsumer nel campo volumeBindingMode in una StorageClass. Questa modalità di binding del volume impedisce la creazione di un PersistentVolume finché GKE non crea un pod che utilizza l'oggetto PersistentVolumeClaim corrispondente. GKE esegue il provisioning di PersistentVolume nella stessa zona del nodo che esegue il pod.
  • Utilizza StorageClass compatibili con la 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 pianifica solo sui nodi che supportano i tipi di disco specificati. Puoi utilizzare l'oggetto StorageClass dynamic-rwo integrato o un oggetto StorageClass personalizzato. I tuoi carichi di lavoro stateful possono quindi essere eseguiti su più generazioni di istanze Compute Engine, perché lo strumento di scalabilità automatica del cluster sceglie dinamicamente un tipo di disco compatibile.

Progetta la tua infrastruttura per flessibilità, efficienza e disponibilità della capacità di calcolo

Le sezioni seguenti forniscono best practice per migliorare la flessibilità, l'efficienza e la disponibilità della capacità di calcolo in ComputeClasses, in modo che i tuoi pod trascorrano meno tempo nello stato Pending.

Richiedi 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 rigida da un tipo di macchina specifico, seleziona una serie di macchine utilizzando il campo machineFamily. Durante un'operazione di scalabilità, GKE può creare nodi che utilizzano qualsiasi tipo di macchina valido in quella serie di macchine, il che aumenta la probabilità che i tuoi pod vengano eseguiti nella configurazione dei nodi che preferisci.

Utilizzare le prenotazioni di capacità per l'hardware richiesto

Se i tuoi carichi di lavoro si basano su hardware richiesto, come TPU o GPU ad alte prestazioni, crea prenotazioni di capacità di Compute Engine per l'hardware e utilizza queste prenotazioni nelle tue ComputeClass. Le prenotazioni di capacità aumentano la probabilità che l'hardware sia disponibile nella tua regione o zona, il che ti aiuta ad aumentare la flessibilità, l'efficienza e la disponibilità della capacità di calcolo. Per utilizzare una prenotazione in una 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 ripiegare sull'hardware on demand. Per saperne di più, consulta Utilizzo delle risorse di zona prenotate.

Non utilizzare nuove prenotazioni per almeno un'ora

Il gestore della scalabilità automatica dei cluster memorizza le informazioni sulle prenotazioni di capacità in una cache. Quando crei una nuova prenotazione di capacità, lo strumento di 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 deploy un carico di lavoro 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 best practice per migliorare la sicurezza delle ComputeClass nei tuoi cluster. Queste misure sono importanti perché ComputeClasses può essere utilizzato per creare e configurare nodi che utilizzano hardware costoso o con disponibilità limitata. L'uso improprio intenzionale o accidentale potrebbe causare interruzioni del workload, addebiti per l'utilizzo non pianificato 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 per creare, modificare ed eliminare ComputeClasses agli stessi principal che possono creare, modificare ed eliminare nodi nei tuoi cluster. Per controllare l'accesso a ComputeClass, utilizza le policy RBAC.

Limitare la disponibilità di ComputeClass per spazio dei nomi

I clienti GKE spesso separano team o tipi di workload diversi in base allo spazio dei nomi Kubernetes. Le ComputeClass sono una risorsa con ambito cluster, il che significa che qualsiasi carico di lavoro in qualsiasi spazio dei nomi può selezionare qualsiasi ComputeClass per impostazione predefinita. Per evitare un uso improprio intenzionale o accidentale, utilizza ValidatingAdmissionPolicies 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 le tue ValidatingAdmissionPolicies controllino le seguenti configurazioni comuni:

  • Controlla 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.
  • Verifica la presenza di bypass della tolleranza dei caratteri jolly: blocca o convalida esplicitamente le tolleranze dei caratteri jolly (ad esempio, la tolleranza operator: Exists senza chiave). Questi selettori con caratteri jolly possono includere la maggior parte dei taint dei nodi, inclusi i taint ComputeClass.
  • Controlla tutti i controller del workload:configura l'matchConstraints del criterio in modo che copra tutte le risorse del controller del workload (ad esempio Deployment, StatefulSet, DaemonSet, Job e CronJob). Non limitare i controlli solo alle risorse Pod.

Per maggiori informazioni, consulta Limitare l'accesso per modificare e selezionare ComputeClass.

Affidabilità

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

Impedisci l'utilizzo di selettori di nodi in conflitto

I selettori di nodi nei pod influiscono sul posizionamento dei pod da parte di GKE 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 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 ValidatingAdmissionPolicies per impedire ai pod che selezionano ComputeClasses di selezionare anche le etichette dei nodi di sistema. Per saperne di più, vedi Selettori di nodi per le etichette dei nodi di sistema.

Testa tutte le modifiche alle impostazioni di migrazione e scalabilità automatica attive

Le impostazioni di migrazione e scalabilità automatica attive in una ComputeClass influiscono direttamente sulla frequenza con cui GKE termina i pod per eseguire attività come lo spostamento dei pod su hardware più preferito e il consolidamento dei nodi sottoutilizzati. Le modifiche a queste impostazioni in un ComputeClass esistente potrebbero comportare interruzioni impreviste del workload. Prima di applicare modifiche a queste impostazioni nelle ComputeClass esistenti, testa le modifiche in un ambiente di staging. Puoi anche utilizzare le annotazioni per proteggere i carichi di lavoro critici dall'espulsione durante lo scaling.

Testare gli aggiornamenti di ComputeClass CRD prima degli upgrade del cluster

GKE aggiorna regolarmente la CustomResourceDefinition (CRD) ComputeClass per aggiungere campi, modificare il comportamento dei campi e risolvere i problemi. Le aggiunte e le modifiche ai campi diventano in genere effettive in versioni specifiche di GKE. Prima di eseguire l'upgrade dei cluster di produzione a nuove versioni secondarie o patch, verifica se le modifiche al CRD causano problemi di carico di lavoro utilizzando le seguenti linee guida:

Utilizza PodDisruptionBudget per migliorare la disponibilità del workload

Le operazioni ComputeClass che causano l'eliminazione dei pod, come la migrazione attiva, rispettano i PodDisruptionBudgets configurati. Ad esempio, puoi configurare un deployment di inferenza in modo che abbia un PodDisruptionBudget che richiede 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 i PodDisruptionBudget per i workload come i seguenti:

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

Non fare affidamento sui budget di interruzione dei pod per proteggere i carichi di lavoro 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à del carico di lavoro e consenta il completamento di funzioni come gli upgrade.

Proteggi i workload critici dall'espulsione

Se hai carichi di lavoro 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 singola istanza e i job batch a esecuzione prolungata.

Riepilogo delle best practice

Questo documento include le seguenti best practice per ComputeClasses:

Passaggi successivi