Provisiona una capacità di calcolo aggiuntiva per la scalabilità rapida dei pod

Questa pagina mostra come riservare capacità di calcolo aggiuntiva nei cluster Google Kubernetes Engine (GKE) in modo che i tuoi carichi di lavoro possano essere scalati rapidamente durante gli eventi di traffico elevato senza attendere l'avvio di nuovi nodi. Puoi utilizzare queste istruzioni per riservare l'overhead di calcolo in modo coerente o in anticipo rispetto a eventi specifici.

Perché il provisioning della capacità di riserva è utile

I cluster GKE Autopilot e i cluster Standard con il provisioning automatico dei nodi creano nuovi nodi quando non esistono nodi 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 inserire i pod in attesa sul nuovo nodo, dopodiché i pod possono essere avviati. Nei cluster Standard, puoi anche 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 voler che i pod si avviano più velocemente durante gli eventi di scalabilità. Ad esempio, se stai lanciando una nuova espansione per il tuo popolare gioco multiplayer live service, i tempi di avvio più rapidi per i pod del server di gioco potrebbero ridurre i tempi di attesa per i giocatori che accedono il giorno del lancio. Un altro esempio: se gestisci una piattaforma di e-commerce e stai pianificando una vendita lampo per un periodo di tempo limitato, ti aspetti picchi di traffico per 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, se questa capacità è disponibile e inutilizzata da altri pod. Per utilizzare il bursting, imposta i limiti delle risorse su un valore superiore alle richieste di risorse oppure non impostare limiti per le risorse. Per maggiori dettagli, vedi Configurare l'utilizzo di pod in GKE.

Come funziona il provisioning della capacità di riserva in GKE

Per eseguire il provisioning della capacità di riserva, puoi utilizzare le PriorityClassPriorityClasses e i pod segnaposto. Una PriorityClass consente di comunicare a GKE che alcuni carichi di lavoro hanno una priorità inferiore rispetto ad altri. Puoi eseguire il deployment di pod segnaposto che utilizzano una PriorityClass a bassa priorità e richiedere la capacità di calcolo da prenotare. GKE aggiunge capacità al cluster creando nuovi nodi per ospitare i pod segnaposto.

Quando i tuoi workload di produzione vengono scalati, GKE espelle i pod segnaposto a priorità inferiore e pianifica al loro posto le nuove repliche dei tuoi pod di produzione (che utilizzano una PriorityClass a priorità più elevata). Se hai più pod a bassa priorità con livelli di priorità diversi, GKE espelle prima i pod con la priorità più bassa.

Metodi di provisioning della capacità

A seconda del caso d'uso, puoi eseguire il provisioning di capacità aggiuntiva nei 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à che vengono eseguiti costantemente nel cluster. Quando GKE espelle questi pod per eseguire i carichi di lavoro di produzione, il controller Deployment garantisce che GKE fornisca più capacità per ricreare i pod a bassa priorità espulsi. Questo metodo fornisce un overhead di capacità coerente in più eventi di scalabilità verticale e orizzontale, fino all'eliminazione del deployment.
  • Provisioning della capacità monouso: utilizza un job per eseguire un numero specifico di pod segnaposto paralleli a bassa priorità per un periodo di tempo specifico. Quando questo periodo di tempo è trascorso o quando GKE espelle tutte le repliche del job, la capacità riservata non è più 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 pod in esecuzione, inclusi i carichi di lavoro a bassa priorità che implementi. Per i dettagli, consulta Prezzi di Autopilot.

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

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.
  • Assicurati di avere un cluster GKE Autopilot o un cluster GKE Standard con il provisioning automatico dei nodi abilitato.
  • Leggi le considerazioni sul provisioning della capacità per assicurarti di scegliere valori appropriati nelle richieste di capacità.

Creare un PriorityClass

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

  • PriorityClass predefinita: una PriorityClass predefinita globale assegnata a qualsiasi pod che non imposta esplicitamente una PriorityClass diversa nella specifica del pod. I pod con questa PriorityClass predefinita possono espellere i pod che utilizzano una PriorityClass inferiore.
  • Low PriorityClass: una PriorityClass non predefinita impostata sulla priorità più bassa possibile in GKE. I pod con questa 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."

    Questo manifest include i seguenti campi:

    • preemptionPolicy: specifica se i pod che utilizzano una PriorityClass possono espellere i pod con priorità inferiore. low-priority PriorityClass utilizza Never, mentre default PriorityClass utilizza PreemptLowerPriority.

    • value: La priorità per i pod che utilizzano PriorityClass. default PriorityClass utilizza 0. low-priority PriorityClass utilizza -10. In Autopilot, puoi impostare questo valore su qualsiasi valore inferiore alla priorità defaultPriorityClass.

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

      Per assistenza nella scelta dei valori appropriati per la priorità, consulta Scegliere una priorità.

    • globalDefault: specifica se GKE assegna o meno PriorityClass ai pod che non impostano esplicitamente un PriorityClass nella specifica del pod. low-priority PriorityClass utilizza false e default PriorityClass utilizza true.

  2. Applica il manifest:

    kubectl apply -f priorityclasses.yaml

Eseguire il provisioning di 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.

Utilizza un deployment per il provisioning coerente della capacità

  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

    Questo manifest include i seguenti campi:

    • spec.replicas: modifica questo valore in base alle tue esigenze.
    • spec.resources.requests: modifica le richieste di CPU e memoria in base ai tuoi requisiti. Utilizza le indicazioni riportate in Scegliere il dimensionamento della capacità per decidere i valori di richiesta appropriati.
    • spec.containers.command e spec.containers.args: indica ai pod di rimanere attivi finché non vengono eliminati da 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 che tutte le repliche abbiano lo stato Running.

Utilizzare un job per il provisioning della capacità di un 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

    Questo manifest include i seguenti campi:

    • spec.parallelism: Modifica il numero di job che vuoi eseguire in parallelo per prenotare la capacità.
    • spec.backoffLimit: 0: impedisci al controller dei job di ricreare i job eliminati.
    • template.spec.resources.requests: modifica le richieste di CPU e memoria in modo che soddisfino i tuoi requisiti. Utilizza le indicazioni riportate nella sezione Considerazioni per decidere i valori appropriati.
    • template.spec.containers.command e template.spec.containers.args: Indica ai job di rimanere attivi per il periodo di tempo, in secondi, durante il quale hai bisogno della capacità aggiuntiva.

  2. Applica il manifest:

    kubectl apply -f capacity-res-job.yaml

  3. Recupera lo stato del job:

    kubectl get jobs

    Attendi che tutti i job abbiano lo stato Running.

Testare il provisioning e l'espulsione della capacità

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

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

    1. Per i deployment, esegui il comando seguente:

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

    2. Per i job, esegui questo comando:

      kubectl get Jobs -w

  2. Apri una finestra del terminale nuova 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, nota che GKE termina alcuni dei workload di provisioning della capacità per pianificare le nuove repliche, in modo simile al seguente esempio:

    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

    Questo output mostra che il nuovo deployment ha impiegato cinque secondi per passare da In attesa a In esecuzione.

Considerazioni per il provisioning della capacità

Provisioning della capacità coerente

  • Valuta il numero di repliche di pod segnaposto di cui hai bisogno e le dimensioni delle richieste in ogni replica. Le repliche a bassa priorità devono richiedere almeno la stessa capacità del tuo workload di produzione più grande, in modo che questi workload possano rientrare nella capacità riservata dal tuo workload 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 anziché uno solo.

Provisioning della capacità per un singolo utilizzo

  • Imposta il periodo di tempo per cui i job segnaposto devono rimanere attivi fino al momento in cui hai bisogno di capacità aggiuntiva. Ad esempio, se vuoi la capacità aggiuntiva per il giorno del lancio di un gioco di 24 ore, imposta la durata su 86.400 secondi. In questo modo, la capacità di cui è stato eseguito il provisioning non dura più del necessario.
  • Imposta un periodo di manutenzione per lo stesso periodo di tempo in cui prenoti la capacità. In questo modo, i job a bassa priorità non vengono eliminati durante un upgrade del nodo. L'impostazione di un periodo di manutenzione è anche una buona pratica quando prevedi una domanda elevata per il tuo workload.
  • 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 anziché uno solo.

La capacità viene sottoposta a provisioning solo per un singolo evento di scalabilità. Se aumenti lo scale up e utilizzi la capacità, quindi fare lo scale down, questa capacità non è più disponibile per un altro evento di scale up. Se prevedi più eventi di scalabilità verticale e orizzontale, utilizza il metodo di prenotazione della capacità coerente e regola le dimensioni della prenotazione in base alle esigenze. Ad esempio, aumentare le richieste di pod prima di un evento e diminuirle o azzerarle dopo.

Scegliere una priorità

Imposta la priorità in PriorityClasses su un valore inferiore a 0.

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

Puoi anche utilizzare altre PriorityClass per eseguire workload non di produzione a bassa priorità che eseguono attività effettive, come i workload batch a tolleranza di errore, con una priorità inferiore rispetto ai workload di produzione, ma superiore rispetto ai pod segnaposto. Ad esempio, -5.

Scegliere il dimensionamento della capacità

Imposta il numero di repliche e le richieste di risorse del tuo workload segnaposto in modo che siano maggiori o uguali alla capacità di cui potrebbero aver bisogno i tuoi workload di produzione durante lo scale up.

La capacità totale di cui è stato eseguito il provisioning si basa sul numero di pod segnaposto che deploy e sulle richieste di risorse di ogni replica. Se lo scale up richiede più capacità di quella di cui GKE ha eseguito il provisioning per i pod segnaposto, alcuni dei tuoi carichi di lavoro di produzione rimangono in Pending finché GKE non può eseguire il provisioning di più capacità.

Passaggi successivi