Il meglio dei due mondi: workloads in modalità Autopilot dentro GKE Standard

Ecco alcune delle criticità che le aziende incontrano con cluster puramente Standard o puramente Autopilot, e perché nessuna delle due modalità da sola basta sempre.

• Carico operativo nei cluster Standard: ha il pieno controllo, ma si fa carico anche di scaling, manutenzione e sicurezza, un impegno che può pesare sui team più piccoli.
• Perdita di flessibilità nei cluster Autopilot: Autopilot offre operazioni più gestite, ma impone anche dei vincoli: richieste minime di risorse, immagini del sistema operativo specifiche, minor controllo sulla configurazione dei nodi e così via.
• Costi e fatturazione: in un cluster Standard paga le macchine virtuali (VM) che compongono i node pool, a prescindere dal fatto che i suoi workloads stiano sfruttando o meno tutte le risorse disponibili. Senza una gestione attenta, si rischiano overprovisioning e sprechi di costo.

Per questi motivi, molte aziende si sono trovate a dover scegliere tra Standard a tutto tondo (flessibile, ma con più manutenzione) o Autopilot a tutto tondo (meno manutenzione, ma minor controllo e più vincoli). Nessuna delle due opzioni è ideale in molti scenari con workloads misti.

Il meccanismo "Autopilot ComputeClasses nei cluster Standard" di GKE sfrutta le ComputeClasses (una risorsa Kubernetes personalizzata che definisce un elenco di configurazioni dei nodi, come tipi di macchina o impostazioni delle funzionalità) per abilitare questo modello ibrido, offrendo un nuovo livello di flessibilità e diversi vantaggi chiave.

La modalità Autopilot in Standard poggia su una nuova piattaforma di calcolo container-optimised, progettata per garantire latenza minima e prestazioni massime. Il nuovo calcolo container-optimised offre tempi di scheduling dei pod fino a 7 volte più rapidi, migliorando in modo significativo i tempi di risposta delle applicazioni per i workloads configurati per usare le Autopilot ComputeClasses.

Tra i vantaggi chiave figurano inoltre:

• Eseguire workloads specifici in modalità Autopilot, completamente gestiti da Google.
• Mantenere il controllo manuale su workloads e infrastrutture che non utilizzano la modalità Autopilot, come i node pool creati manualmente.
• Impostare una Autopilot ComputeClass come predefinita per il cluster o per il namespace, in modo che i workloads ereditino i vantaggi di Autopilot salvo diversa indicazione.

Requisiti e limitazioni

L'idea le sembra interessante? Esamini requisiti e limitazioni prima di abilitare i workloads Autopilot all'interno di un cluster Standard.

• I nodi Autopilot applicano regole rigorose in materia di funzionalità e sicurezza. I workloads standard possono essere rifiutati se non rispettano questi requisiti: verifichi quindi le impostazioni dei nodi per garantire la compatibilità.
• Il cluster deve essere registrato sul canale di rilascio Rapid ed eseguire la versione 1.33.1-gke.1107000 o successiva.
• Il canale Rapid introduce funzionalità e nuove versioni di Kubernetes più rapidamente, ma può anche includere modifiche non retrocompatibili. Esamini e risolva eventuali modifiche alle API o di altra natura prima di aggiornare il cluster.
• Almeno un node pool del cluster non deve avere node taint, così da poter eseguire i pod di sistema standard.
• Il cluster deve essere VPC-native, con Shielded GKE Nodes abilitato per impostazione predefinita.

Autopilot ComputeClasses integrate

GKE configura automaticamente le risorse personalizzate ComputeClasses autopilot e autopilot-spot non appena il cluster viene aggiornato a una versione supportata.

Esempio di autopilot computeclasses

Per selezionare una Autopilot ComputeClass in un workload, utilizzi un node selector sull'etichetta cloud.google.com/compute-class.

#Sample workload that uses built-in autopilot ComputeClass
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Replace COMPUTE_CLASS with the name of the compute class to use.
        cloud.google.com/compute-class: COMPUTE_CLASS
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "4Gi"

Le risorse del container vengono adeguate automaticamente per soddisfare i requisiti di Autopilot e vengono pianificate su nodi della piattaforma di calcolo container-optimized.

ComputeClasses personalizzate

Se le ComputeClasses integrate non bastano, può creare Autopilot ComputeClasses personalizzate, calibrate su workloads specifici. È un'opzione particolarmente utile per workloads che richiedono GPU o determinate famiglie di macchine.

Se sta già utilizzando una ComputeClass personalizzata, per portare in modalità Autopilot le risorse ComputeClass già presenti nel cluster, deve ricrearle con una specifica aggiornata. Per maggiori informazioni, consulti Abilitare Autopilot per una ComputeClass personalizzata esistente.

#sample custom ComputeClass with autopilot mode enabled
---
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: autopilot-n2-class
spec:
  autopilot:
    enabled: true
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false
  activeMigration:
    optimizeRulePriority: true
  whenUnsatisfiable: DoNotScaleUp

Non può utilizzare la regola di priorità podFamily nelle sue ComputeClasses. Questa regola è disponibile solo nelle Autopilot ComputeClasses integrate.

Può utilizzare le ComputeClasses personalizzate con la modalità Autopilot abilitata per impostare una compute class predefinita a livello di cluster GKE o di namespace. La classe predefinita configurata si applica a qualsiasi Pod del cluster o del namespace che non specifichi una compute class diversa. Quando distribuisce un Pod che non specifica una compute class, GKE applica le compute class predefinite in questo ordine:

1. Se il namespace ha una compute class predefinita, GKE modifica la specifica del Pod per selezionare quella compute class.
2. In caso contrario, si applica l'impostazione predefinita del cluster, se configurata, e GKE non modifica il Pod.

Per maggiori dettagli, consulti il link.