Informazioni sulle classi di computing bilanciate e di scalabilità orizzontale nei cluster Autopilot

Puoi utilizzare Balanced e Scale-Out ComputeClasses nei cluster Google Kubernetes Engine (GKE) Autopilot per eseguire carichi di lavoro che richiedono capacità di calcolo aggiuntiva o configurazioni CPU specializzate. Questa pagina è destinata agli amministratori dei cluster che vogliono opzioni di calcolo più flessibili rispetto a quelle fornite dalla configurazione predefinita del cluster Autopilot.

Panoramica delle ComputeClass bilanciate e di scalabilità orizzontale

Per impostazione predefinita, i pod nei cluster GKE Autopilot vengono eseguiti su una piattaforma di calcolo ottimizzata per i container. Questa piattaforma è ideale per carichi di lavoro per uso generico come server web e job batch di media intensità. La piattaforma di calcolo ottimizzata per container fornisce una configurazione hardware affidabile, scalabile e ottimizzata per i costi in grado di gestire i requisiti della maggior parte dei workload.

Se hai carichi di lavoro con requisiti hardware unici (ad esempio l'esecuzione di attività di machine learning o AI, l'esecuzione di database ad alto traffico in tempo reale o la necessità di piattaforme e architetture CPU specifiche), puoi utilizzare ComputeClasses per eseguire il provisioning di questo hardware.

Solo nei cluster Autopilot, GKE fornisce le seguenti ComputeClass curate che ti consentono di eseguire pod che richiedono maggiore flessibilità rispetto alla piattaforma di calcolo ottimizzata per container predefinita:

  • Balanced: offre una capacità massima di CPU e memoria superiore rispetto alla piattaforma di calcolo ottimizzata per i container.
  • Scale-Out: disabilita il multi-threading simultaneo (SMT) ed è ottimizzato per lo scale out.

Queste ComputeClass sono disponibili solo nei cluster Autopilot. Analogamente alla piattaforma di computing ottimizzata per i container predefinita, Autopilot gestisce il dimensionamento dei nodi e l'allocazione delle risorse in base ai pod in esecuzione.

ComputeClass personalizzate per una maggiore flessibilità

Se le ComputeClass bilanciate o di scalabilità orizzontale nei cluster Autopilot non soddisfano i requisiti del tuo workload, puoi configurare le tue ComputeClass. Esegui il deployment delle risorse personalizzate Kubernetes ComputeClass nei tuoi cluster con set di attributi dei nodi che GKE utilizza per configurare nuovi nodi nel cluster. Queste ComputeClass personalizzate possono, ad esempio, consentirti di eseguire il deployment dei workload sullo stesso hardware delle ComputeClass Balanced o Scale-Out in qualsiasi cluster GKE Autopilot o Standard. Per saperne di più, consulta Informazioni sui carichi di lavoro in modalità Autopilot in GKE Standard.

Prezzi

I pod che utilizzano le ComputeClass Balanced o Scale-Out vengono fatturati in base ai seguenti SKU:

Per saperne di più, consulta la sezione Prezzi di GKE.

Dettagli tecnici di Balanced e Scale-Out

Questa sezione descrive i tipi di macchine e i casi d'uso per le classi Balanced e Scale-Out. Se non richiedi una ComputeClass nei tuoi pod, Autopilot li posiziona per impostazione predefinita sulla piattaforma di calcolo ottimizzata per i container. La piattaforma di calcolo ottimizzata per i container utilizza una qualsiasi delle serie di macchine della famiglia di macchine per uso generico di Compute Engine, con una preferenza per i tipi di macchine ridimensionabili. Poiché la serie di macchine sottostante non è fissa, le prestazioni per CPU variano a seconda della serie di macchine su cui GKE pianifica il pod.

Inoltre, la pianificazione dei pod con spazio di archiviazione permanente collegato dipende dalla compatibilità del tipo di disco:

  • Persistent Disk legacy: i pod con Persistent Disk legacy collegati (ad esempio pd-standard) vengono eseguiti solo sulle serie di macchine che li supportano, ad esempio E2.
  • Hyperdisk: i pod con archiviazione di nuova generazione collegata (ad esempio hyperdisk-balanced) vengono eseguiti su serie di macchine più recenti, come C3.
  • Stato In attesa: se configuri esplicitamente un pod per l'esecuzione su una serie di macchine più recente (ad esempio, utilizzando i selettori di nodi per richiedere nodi C3 o configurando una ComputeClass personalizzata), ma colleghi un Persistent Disk legacy, il pod rimane nello stato Pending a tempo indeterminato. Ciò si verifica perché GKE non riesce a trovare un nodo che soddisfi sia i vincoli di compatibilità del tipo di macchina che del disco. Quando selezioni esplicitamente una serie di macchine, sei responsabile di garantire la compatibilità di PersistentVolume e del disco.

La tabella seguente fornisce una panoramica tecnica delle classi di calcolo Balanced e Scale-Out.

ComputeClass bilanciate e di scale out
Balanced

Fornisce più capacità di CPU e memoria rispetto ai valori massimi della piattaforma di calcolo ottimizzata per i container. Fornisce piattaforme CPU aggiuntive e la possibilità di impostare piattaforme CPU minime per i pod, come Intel Ice Lake o versioni successive.

  • CPU disponibili: AMD EPYC Milan, Intel Ice Lake, Intel Cascade Lake
  • Architettura disponibile: amd64
  • Serie di macchine: N2 (CPU Intel) o serie di macchine N2D (CPU AMD).

Utilizza la classe Balanced per applicazioni come le seguenti:

  • Server web
  • Database medio-grandi
  • Memorizzazione nella cache
  • Streaming e distribuzione di contenuti multimediali
  • Archiviazione Hyperdisk Throughput ed Extreme
Scale-Out

Fornisce un singolo thread per core di calcolo e scalabilità orizzontale.

  • CPU disponibili: Ampere Altra Arm o AMD EPYC Milan
  • Architettura disponibile: arm64 o amd64
  • Serie di macchine: T2A (Arm) o T2D (x86).
  • Funzionalità aggiuntive:
    • SMT è disattivato, quindi una vCPU equivale a un core fisico.
    • Velocità di clock massima di 3,5 GHz.

Utilizza la classe Scale-Out per applicazioni come le seguenti:

  • Server web
  • Microservizi containerizzati
  • Elaborazione dei log di dati
  • App Java su vasta scala
  • Spazio di archiviazione Hyperdisk Throughput

Selezione di ComputeClass nei workload

Per utilizzare una ComputeClass per un workload GKE, seleziona la ComputeClass nel manifest del workload utilizzando un selettore di nodi per l'etichetta cloud.google.com/compute-class.

Il seguente manifest di Deployment seleziona una 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 with the name of a compute class
        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: "1Gi"

Sostituisci COMPUTE_CLASS con il nome di una ComputeClass, ad esempio Balanced o Scale-Out. Puoi selezionare un massimo di una ComputeClass in un workload.

Quando esegui il deployment del workload, GKE esegue le seguenti operazioni:

  • Esegue automaticamente il provisioning dei nodi supportati dalla configurazione specificata per eseguire i pod.
  • Aggiunge automaticamente etichette e taint ai nuovi nodi per impedire la pianificazione di altri pod su questi nodi. I taint sono univoci per ogni ComputeClass. Se selezioni anche un'architettura CPU, GKE aggiunge un taint separato univoco per quell'architettura.
  • Aggiunge automaticamente le tolleranze corrispondenti alle incompatibilità applicate ai pod di cui è stato eseguito il deployment, consentendo a GKE di posizionare questi pod sui nuovi nodi.

Ad esempio, se richiedi ComputeClass Scale-Out per un pod:

  1. Autopilot aggiunge un taint specifico per Scale-Out per questi nodi.
  2. Autopilot aggiunge una tolleranza per questa incompatibilità ai pod Scale-Out.

I pod che non richiedono Scale-Out non otterranno la tolleranza. Di conseguenza, GKE non pianificherà questi pod sui nodi Scale-Out.

Se non richiedi esplicitamente una ComputeClass nella specifica del workload, Autopilot pianifica i pod sui nodi che utilizzano la piattaforma di calcolo ottimizzata per i container predefinita. La maggior parte dei carichi di lavoro per uso generico può essere eseguita senza problemi su questa piattaforma.

Se utilizzi ComputeClasses o richiedi serie di macchine specifiche, assicurati che i tuoi carichi di lavoro non utilizzino spazio di archiviazione incompatibile. Ad esempio, non utilizzare tipi di volumi Persistent Disk precedenti, come i volumi Persistent Disk standard (pd-standard) o Persistent Disk SSD (pd-ssd), su serie di macchine che non li supportano. L'utilizzo di uno spazio di archiviazione incompatibile può far sì che i pod rimangano nello stato Pending se GKE non riesce a trovare o eseguire il provisioning di un nodo che soddisfi tutti i vincoli. Se un pod è pianificato, ma l'archiviazione non viene collegata o montata, il pod rimane nello stato ContainerCreating. Per ulteriori informazioni sulla risoluzione dei problemi di compatibilità dell'archiviazione, vedi Workload pianificato su serie di macchine precedenti o bloccato nello stato Pending a causa dell'incompatibilità dell'archiviazione.

Come richiedere un'architettura della CPU

In alcuni casi, i tuoi workload potrebbero essere creati per un'architettura specifica, ad esempio Arm. Scale-Out ComputeClass supporta più architetture CPU. Puoi richiedere un'architettura specifica insieme alla richiesta ComputeClass specificando un'etichetta nel selettore di nodi o nella regola di affinità dei nodi, come nel seguente esempio:

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: COMPUTE_CLASS
        kubernetes.io/arch: ARCHITECTURE
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

Sostituisci ARCHITECTURE con l'architettura della CPU che preferisci, ad esempio arm64 o amd64. Puoi selezionare un massimo di un'architettura nel tuo workload. La ComputeClass che selezioni deve supportare l'architettura specificata.

Se non richiedi esplicitamente un'architettura, Autopilot utilizza l'architettura predefinita di ComputeClass.

Architettura Arm su Autopilot

Autopilot supporta le richieste di nodi che utilizzano l'architettura della CPU Arm. I nodi Arm sono più convenienti rispetto a nodi x86 simili e offrono miglioramenti delle prestazioni. Per istruzioni su come richiedere nodi Arm, consulta Eseguire il deployment di workload Autopilot sull'architettura Arm.

Assicurati di utilizzare le immagini corrette nei deployment. Se i tuoi pod utilizzano immagini Arm e non richiedi nodi Arm, Autopilot pianifica i pod sui nodi x86 e i pod si arrestano in modo anomalo. Allo stesso modo, se utilizzi accidentalmente immagini x86, ma richiedi nodi Arm per i pod, questi ultimi si arresteranno in modo anomalo.

Richieste di risorse predefinite, minime e massime

Quando scegli una ComputeClass per i tuoi workload Autopilot, assicurati di specificare richieste di risorse che soddisfino le richieste minime e massime per quella ComputeClass. Per informazioni sulle richieste predefinite, nonché sulle richieste minime e massime per ogni ComputeClass, consulta Richieste e limiti delle risorse in GKE Autopilot.

Passaggi successivi