Esegui il provisioning di capacità di calcolo aggiuntiva per una rapida scalabilità dei pod

Questa pagina mostra come prenotare capacità di calcolo extra nei tuoi cluster Google Kubernetes Engine (GKE) in modo che i carichi di lavoro possano fare lo scale up rapido durante eventi di traffico elevato senza attendere l'avvio di nuovi nodi. Puoi utilizzare queste istruzioni per prenotare l'overhead di computing in base alla disponibilità coerente o prima di eventi specifici.

Perché il provisioning della capacità di riserva è utile

I cluster GKE Autopilot e i cluster Standard con provisioning automatico dei nodi creano nuovi nodi quando non esistono nodi esistenti con la capacità di eseguire nuovi pod. L'avvio di ogni nuovo nodo richiede circa 80-120 secondi. GKE attende l'avvio del nodo prima di posizionare i pod in attesa sul nuovo nodo, dopodiché i pod possono avviarsi. Nei cluster standard, in alternativa, puoi creare manualmente un nuovo pool di nodi con la capacità aggiuntiva necessaria per eseguire nuovi pod. Questa pagina si applica ai cluster che utilizzano un meccanismo di scalabilità automatica dei nodi come Autopilot o il provisioning automatico dei nodi.

In alcuni casi, potresti volere che i tuoi pod si avviino più velocemente durante gli eventi di scale up. Ad esempio, se stai lanciando una nuova espansione per il tuo popolare gioco multiplayer sul servizio dal vivo, i tempi di avvio più rapidi per i pod dei tuoi server di gioco potrebbero ridurre i tempi di coda per i giocatori che accedono il giorno del lancio. Un altro esempio: se gestisci una piattaforma di e-commerce e stai pianificando un'offerta lampo per un periodo di tempo limitato, prevedi raffiche di traffico per tutta la durata della vendita.

Il provisioning della capacità di riserva è compatibile con il bursting dei pod, che consente ai pod di utilizzare temporaneamente le risorse richieste da altri pod sul nodo, nel caso in cui questa capacità sia disponibile e non utilizzata da altri pod. Per utilizzare il bursting, imposta un limite per le risorse superiore a quello richiesto oppure non impostare un limite per le risorse. Per maggiori dettagli, consulta Configurare il bursting dei pod in GKE.

Come funziona il provisioning della capacità di riserva in GKE

Per eseguire il provisioning di capacità di riserva, puoi utilizzare Kubernetes PriorityClasses e pod segnaposto. Un PriorityClass consente di indicare a GKE che alcuni carichi di lavoro hanno una priorità più bassa rispetto ad altri carichi di lavoro. Puoi eseguire il deployment di pod segnaposto che utilizzano un valore PriorityClass a bassa priorità e richiedere la capacità di calcolo necessaria per prenotare. GKE aggiunge capacità al cluster creando nuovi nodi per ospitare i pod segnaposto.

Quando i carichi di lavoro di produzione fanno lo scale up, GKE rimuove i pod segnaposto con priorità inferiore e pianifica al loro posto le nuove repliche dei tuoi pod di produzione (che utilizzano un valore PriorityClass con priorità più alta). Se hai più pod a bassa priorità con livelli di priorità diversi, GKE rimuove per primi i pod con priorità più bassa.

Metodi di provisioning della capacità

A seconda del caso d'uso, puoi eseguire il provisioning di capacità aggiuntiva nei tuoi cluster GKE in uno dei seguenti modi:

  • Provisioning coerente della capacità: utilizza un deployment per creare un numero specifico di pod segnaposto a bassa priorità in esecuzione costantemente nel cluster. Quando GKE rimuove questi pod per eseguire i carichi di lavoro di produzione, il controller Deployment garantisce che GKE esegua il provisioning di una maggiore capacità per ricreare i pod a bassa priorità eliminati. Questo metodo fornisce un overhead di capacità coerente per più eventi di scale up e scale down fino a quando non elimini il deployment.
  • Provisioning della capacità a uso singolo: utilizza un job per eseguire un numero specifico di pod segnaposto paralleli a bassa priorità per un periodo di tempo specifico. Una volta trascorso questo periodo o quando GKE rimuove tutte le repliche dei job, la capacità prenotata smette di essere disponibile. Questo metodo fornisce una quantità specifica di capacità disponibile per un periodo specifico.

Prezzi

In GKE Autopilot ti vengono addebitate le richieste di risorse dei tuoi pod in esecuzione, inclusi i carichi di lavoro a bassa priorità di cui esegui il deployment. Per i dettagli, consulta la pagina relativa ai prezzi di Autopilot.

In GKE Standard, ti vengono addebitate le VM di Compute Engine sottostanti di cui GKE esegue il provisioning, indipendentemente dal fatto che i pod utilizzino o meno questa capacità. Per i dettagli, consulta i prezzi standard

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  • Assicurati di disporre di un cluster GKE Autopilot o di un cluster GKE Standard in cui è abilitato il provisioning automatico dei nodi.
  • Leggi le Considerazioni sul provisioning della capacità per assicurarti di scegliere i valori appropriati nelle richieste di capacità.

Creazione di un PriorityClass

Per utilizzare uno dei metodi descritti in Metodi di provisioning della capacità, devi prima creare le classi di priorità seguenti:

  • PriorityClass predefinita: un PriorityClass predefinito globale assegnato a qualsiasi pod che non imposta in modo esplicito un valore PriorityClass diverso nella specifica del pod. I pod con questo valore PriorityClass predefinito possono rimuovere i pod che utilizzano un valore PriorityClass inferiore.
  • Low PriorityClass: un PriorityClass non predefinito impostato sulla priorità più bassa possibile in GKE. I pod con questo valore PriorityClass possono essere rimossi per eseguire pod con PriorityClass più elevate.

  1. Salva il seguente manifest come priorityclasses.yaml:

    apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: -10
preemptionPolicy: Never
globalDefault: false
description: "Low priority workloads"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: default-priority
value: 0
preemptionPolicy: PreemptLowerPriority
globalDefault: true
description: "The global default priority."

    Il file manifest include i seguenti campi:

    • preemptionPolicy: specifica se i pod che utilizzano un oggetto PriorityClass possono eliminare o meno i pod con priorità inferiore. Il PriorityClass low-priority utilizza Never, mentre il PriorityClass di default utilizza PreemptLowerPriority.

    • value: la priorità per i pod che utilizzano l'attributo PriorityClass. Il default PriorityClass utilizza 0. Il PriorityClass low-priority utilizza -1. In Autopilot puoi impostarlo su qualsiasi valore inferiore alla priorità PriorityClass di default.

      In Standard, se imposti questo valore su un valore inferiore a -10, i pod che utilizzano questo valore PriorityClass non attiveranno la creazione di nuovi nodi e rimarranno nello stato In attesa.

      Per informazioni sui valori appropriati per la priorità, consulta Scegliere una priorità.

    • globalDefault: specifica se GKE assegna o meno il valore PriorityClass ai pod che non impostano esplicitamente un valore PriorityClass nella specifica dei pod. low-priority PriorityClass utilizza false, mentre default PriorityClass utilizza true.

  2. Applica il manifest:

    kubectl apply -f priorityclasses.yaml

Esegui il provisioning della capacità di calcolo aggiuntiva

Le sezioni seguenti mostrano un esempio in cui esegui il provisioning della capacità per un singolo evento o in modo coerente nel tempo.

Usare un oggetto Deployment per un provisioning della capacità coerente

  1. Salva il seguente manifest come capacity-res-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: capacity-res-deploy
spec:
  replicas: 10
  selector:
    matchLabels:
      app: reservation
  template:
    metadata:
      labels:
        app: reservation
    spec:
      priorityClassName: low-priority
      terminationGracePeriodSeconds: 0
      containers:
      - name: ubuntu
        image: ubuntu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 500m
            memory: 500Mi

    Il file manifest include i seguenti campi:

    • spec.replicas: modifica questo valore per soddisfare i requisiti.
    • spec.resources.requests: modifica le richieste di CPU e memoria in base ai tuoi requisiti. Segui le indicazioni riportate in Scegliere il dimensionamento della capacità per decidere i valori appropriati per le richieste.
    • spec.containers.command e spec.containers.args: comunica ai pod di rimanere attivi fino alla rimozione da parte di GKE.

  2. Applica il manifest:

    kubectl apply -f capacity-res-deployment.yaml

  3. Recupera lo stato del pod:

    kubectl get pods -l app=reservation

    Attendi finché tutte le repliche non avranno lo stato Running.

utilizza un job per il provisioning della capacità per singolo evento

  1. Salva il seguente manifest come capacity-res-job.yaml:

    apiVersion: batch/v1
kind: Job
metadata:
  name: capacity-res-job
spec:
  parallelism: 4
  backoffLimit: 0
  template:
    spec:
      priorityClassName: low-priority
      terminationGracePeriodSeconds: 0
      containers:
      - name: ubuntu-container
        image: ubuntu
        command: ["sleep"]
        args: ["36000"]
        resources:
          requests:
            cpu: "16"
      restartPolicy: Never

    Il file manifest include i seguenti campi:

    • spec.parallelism: modifica al numero di job da eseguire in parallelo per prenotare capacità.
    • spec.backoffLimit: 0: impedisci al controller Job di ricreare job rimossi.
    • template.spec.resources.requests: modifica le richieste di CPU e memoria in base ai tuoi requisiti. Segui le indicazioni contenute nella sezione Considerazioni per scegliere i valori appropriati.
    • template.spec.containers.command e template.spec.containers.args: comunica ai job di rimanere attivi per il periodo di tempo, in secondi, durante il quale è necessaria la capacità extra.

  2. Applica il manifest:

    kubectl apply -f capacity-res-job.yaml

  3. Recupera lo stato del lavoro:

    kubectl get jobs

    Attendi che tutti i job abbiano lo stato Running.

Testare il provisioning e l'eliminazione della capacità

Per verificare che il provisioning della capacità funzioni come previsto:

  1. Nel terminale, controlla lo stato dei carichi di lavoro per il provisioning della capacità:

    1. Per i deployment, esegui questo comando:

      kubectl get pods --label=app=reservation -w

    2. Per i job, esegui questo comando:

      kubectl get Jobs -w

  2. Apri una nuova finestra del terminale e procedi nel seguente modo:

    1. Salva il seguente manifest come test-deployment.yaml:

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  replicas: 5
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 400m
            memory: 400Mi

    2. Applica il manifest:

      kubectl apply -f test-deployment.yaml

  3. Nella finestra del terminale originale, tieni presente che GKE termina alcuni carichi di lavoro di provisioning della capacità per pianificare le nuove repliche, come nell'esempio seguente:

    NAME                                         READY   STATUS    RESTARTS   AGE
capacity-res-deploy-6bd9b54ffc-5p6wc         1/1     Running   0          7m25s
capacity-res-deploy-6bd9b54ffc-9tjbt         1/1     Running   0          7m26s
capacity-res-deploy-6bd9b54ffc-kvqr8         1/1     Running   0          2m32s
capacity-res-deploy-6bd9b54ffc-n7zn4         1/1     Running   0          2m33s
capacity-res-deploy-6bd9b54ffc-pgw2n         1/1     Running   0          2m32s
capacity-res-deploy-6bd9b54ffc-t5t57         1/1     Running   0          2m32s
capacity-res-deploy-6bd9b54ffc-v4f5f         1/1     Running   0          7m24s
helloweb-85df88c986-zmk4f                    0/1     Pending   0          0s
helloweb-85df88c986-lllbd                    0/1     Pending   0          0s
helloweb-85df88c986-bw7x4                    0/1     Pending   0          0s
helloweb-85df88c986-gh8q8                    0/1     Pending   0          0s
helloweb-85df88c986-74jrl                    0/1     Pending   0          0s
capacity-res-deploy-6bd9b54ffc-v6dtk   1/1     Terminating   0          2m47s
capacity-res-deploy-6bd9b54ffc-kvqr8   1/1     Terminating   0          2m47s
capacity-res-deploy-6bd9b54ffc-pgw2n   1/1     Terminating   0          2m47s
capacity-res-deploy-6bd9b54ffc-n7zn4   1/1     Terminating   0          2m48s
capacity-res-deploy-6bd9b54ffc-2f8kx   1/1     Terminating   0          2m48s
...
helloweb-85df88c986-lllbd              0/1     Pending       0          1s
helloweb-85df88c986-gh8q8              0/1     Pending       0          1s
helloweb-85df88c986-74jrl              0/1     Pending       0          1s
helloweb-85df88c986-zmk4f              0/1     Pending       0          1s
helloweb-85df88c986-bw7x4              0/1     Pending       0          1s
helloweb-85df88c986-gh8q8              0/1     ContainerCreating   0          1s
helloweb-85df88c986-zmk4f              0/1     ContainerCreating   0          1s
helloweb-85df88c986-bw7x4              0/1     ContainerCreating   0          1s
helloweb-85df88c986-lllbd              0/1     ContainerCreating   0          1s
helloweb-85df88c986-74jrl              0/1     ContainerCreating   0          1s
helloweb-85df88c986-zmk4f              1/1     Running             0          4s
helloweb-85df88c986-lllbd              1/1     Running             0          4s
helloweb-85df88c986-74jrl              1/1     Running             0          5s
helloweb-85df88c986-gh8q8              1/1     Running             0          5s
helloweb-85df88c986-bw7x4              1/1     Running             0          5s

    L'output mostra che il passaggio da In attesa a In esecuzione del nuovo deployment ha richiesto cinque secondi.

Considerazioni sul provisioning della capacità

Provisioning coerente della capacità

  • Valuta il numero di repliche di pod segnaposto di cui hai bisogno e la dimensione delle richieste in ogni replica. Le repliche a bassa priorità devono richiedere almeno la stessa capacità del carico di lavoro di produzione più grande, in modo che possano rientrare nella capacità prenotata dal carico di lavoro a bassa priorità.
  • Se gestisci un numero elevato di carichi di lavoro di produzione su larga scala, valuta la possibilità di impostare le richieste di risorse dei pod segnaposto su valori che forniscono una capacità sufficiente per eseguire più carichi di lavoro di produzione invece di uno solo.

Provisioning della capacità monouso

  • Imposta il tempo di permanenza dei job segnaposto sull'intervallo di tempo durante il quale hai bisogno di capacità aggiuntiva. Ad esempio, se vuoi che la capacità aggiuntiva per un giorno di lancio di un gioco di 24 ore, imposta la durata su 86.400 secondi. Ciò garantisce che la capacità di cui è stato eseguito il provisioning non duri più a lungo di quanto ti serva.
  • Imposta un periodo di manutenzione per lo stesso periodo di tempo in cui stai prenotando la capacità. Questo impedisce che i job a bassa priorità vengano rimossi durante l'upgrade di un nodo. Impostare un periodo di manutenzione è utile anche quando prevedi una domanda elevata per il tuo carico di lavoro.
  • Se gestisci un numero elevato di carichi di lavoro di produzione su larga scala, valuta la possibilità di impostare le richieste di risorse dei job segnaposto su valori che forniscono una capacità sufficiente per eseguire più carichi di lavoro di produzione invece di uno solo.

Viene eseguito il provisioning della capacità solo per un singolo evento di scalabilità. Se fai lo scale up e utilizzi la capacità e poi fare lo scale down, la capacità non è più disponibile per un altro evento di scale up. Se prevedi più eventi di scale up e scale down, utilizza il metodo di prenotazione della capacità coerente e modifica le dimensioni della prenotazione in base alle esigenze. Ad esempio, le richieste di pod diventano più grandi prima di un evento e più basse o zero dopo.

Scegli una priorità

Impostare la priorità in PriorityClasses in modo che sia inferiore a 0.

Puoi definire più PriorityClass nel cluster da utilizzare con carichi di lavoro che presentano requisiti diversi. Ad esempio, puoi creare un elemento PriorityClass con priorità -10 per il provisioning della capacità monouso e un elemento PriorityClass con priorità -9 per il provisioning coerente della capacità. Puoi quindi eseguire il provisioning di capacità coerente utilizzando il PriorityClass con priorità -9 e, se vuoi più capacità per un evento speciale, puoi eseguire il deployment di nuovi job che utilizzano il PriorityClass con priorità -10. GKE rimuove prima i carichi di lavoro a priorità più bassa.

Puoi anche utilizzare altre classi di priorità per eseguire carichi di lavoro non di produzione a bassa priorità che eseguono attività effettive, ad esempio carichi di lavoro batch a tolleranza di errore, con una priorità inferiore ai carichi di lavoro di produzione, ma superiore ai pod segnaposto. Ad esempio, -5.

Scegli il dimensionamento della capacità

Imposta il numero di repliche e le richieste di risorse del carico di lavoro segnaposto su un valore superiore o uguale alla capacità che potrebbe essere necessaria per i carichi di lavoro di produzione durante lo scale up.

La capacità totale di cui è stato eseguito il provisioning si basa sul numero di pod segnaposto di cui esegui il deployment e sulle richieste di risorse di ogni replica. Se lo scale up richiede più capacità rispetto a quella di cui è stato eseguito il provisioning di GKE per i pod segnaposto, parte dei carichi di lavoro di produzione rimangono in Pending finché GKE non esegue il provisioning di maggiore capacità.

Passaggi successivi