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

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

Panoramica delle classi ComputeClass Balanced e Scale-Out

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

Se hai workload con requisiti hardware unici (ad esempio l'esecuzione di attività di machine learning o attività 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 dell'hardware.

Solo nei cluster Autopilot, GKE fornisce le seguenti classi di computing selezionate che ti consentono di eseguire pod che richiedono una maggiore flessibilità rispetto alla piattaforma di computing ottimizzata per i container predefinita:

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

Queste classi di computing 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 classi di computing Balanced o Scale-Out nei cluster Autopilot non soddisfano i requisiti del tuo workload, puoi configurare le tue classi di computing. Esegui il deployment delle risorse personalizzate Kubernetes ComputeClass nei tuoi cluster con insiemi di attributi dei nodi che GKE utilizza per configurare i 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 workload in modalità Autopilot in GKE Standard.

Prezzi

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

Per saperne di più, consulta i 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 classe di computing nei tuoi pod, Autopilot li posiziona sulla piattaforma di computing ottimizzata per i container per impostazione predefinita. La piattaforma di computing 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 archiviazione permanente collegata dipende dalla compatibilità del tipo di disco:

  • Persistent Disk legacy: i pod con Persistent Disk legacy collegati (come pd-standard) vengono eseguiti solo su serie di macchine che li supportano, come E2.
  • Hyperdisk: i pod con spazio di archiviazione di nuova generazione collegato (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. Questo accade perché GKE non riesce a trovare un nodo che soddisfi i vincoli di compatibilità sia del tipo di macchina sia 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 computing Balanced e Scale-Out.

ComputeClass Balanced e Scale-Out
Balanced

Fornisce una capacità di CPU e di memoria superiore rispetto ai valori massimi della piattaforma di computing ottimizzata per i container. Fornisce piattaforme CPU aggiuntive e la possibilità di impostare piattaforme CPU minime per i pod, ad esempio 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
  • Spazio di archiviazione Hyperdisk Throughput ed Extreme
Scale-Out

Fornisce computing single-thread per core 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:
    • L'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 dei dati
  • App Java su larga 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 di esempio seleziona una classe 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 classe ComputeClass, ad esempio Balanced o Scale-Out. Puoi selezionare un massimo di una classe 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 tuoi 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 della CPU, GKE aggiunge un taint separato univoco per quell'architettura.
  • Aggiunge automaticamente tolleranze corrispondenti alle incompatibilità applicate ai pod di cui è stato eseguito il deployment, consentendo a GKE di posizionare i pod sui nuovi nodi.

Ad esempio, se richiedi la classe di computing Scale-Out per un pod:

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

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

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

Se utilizzi ComputeClasses o richiedi serie di macchine specifiche, assicurati che i tuoi workload non utilizzino uno spazio di archiviazione incompatibile. Ad esempio, non utilizzare i tipi di volume Persistent Disk precedenti, come i volumi Standard Persistent Disk (pd-standard) o SSD Persistent Disk (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 non è possibile collegare o montare lo spazio di archiviazione, il pod rimane nello stato ContainerCreating. Per ulteriori informazioni sulla risoluzione dei problemi di compatibilità dello spazio di archiviazione, consulta Workload pianificato su serie di macchine precedenti o bloccato nello stato Pending a causa di incompatibilità dello spazio di archiviazione.

Come richiedere un'architettura della CPU

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

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 classe ComputeClass selezionata 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, pur offrendo miglioramenti delle prestazioni. Per istruzioni su come richiedere nodi Arm, consulta Esegui il deployment dei workload Autopilot sull'architettura Arm.

Assicurati di utilizzare le immagini corrette nei tuoi 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. Analogamente, se utilizzi accidentalmente immagini x86, ma richiedi nodi Arm per i pod, i pod si arresteranno in modo anomalo.

Richieste di risorse predefinite, minime e massime

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

Passaggi successivi