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

Questa pagina mostra come prenotare capacità di calcolo aggiuntiva i cluster Google Kubernetes Engine (GKE) per consentire rapidamente lo scale up dei tuoi carichi di lavoro durante eventi di traffico elevato senza attendere l'avvio di nuovi nodi. Puoi utilizzare queste istruzioni per riservare l'overhead di computing su un ambiente o prima di eventi specifici.

Perché il provisioning della capacità di riserva è utile

Cluster GKE Autopilot e Standard con il provisioning automatico dei nodi crea nuovi nodi quando non esistono nodi con la capacità di eseguire nuovi pod. Ogni nuovo nodo richiede da 80 a 120 secondi per l'avvio. GKE attende l'avvio del nodo prima di posizionando i pod in sospeso sul nuovo nodo, dopodiché possono avviarsi. Nel Cluster standard, in alternativa puoi creare un nuovo pool di nodi che abbia la capacità aggiuntiva necessaria per eseguire nuovi pod. Questa pagina si applica ai cluster che utilizzano di scalabilità automatica come Autopilot o il provisioning automatico dei nodi.

In alcuni casi, potresti volere che i pod si avviino più velocemente durante gli eventi di scale up. Ad esempio, se stai per lanciare una nuova espansione per il tuo popolare servizio live multiplayer, i tempi di avvio più rapidi per i pod del server di gioco potrebbero ridurre tempi in coda per i giocatori che eseguono l'accesso il giorno del lancio. Come ulteriore esempio, se esegui una piattaforma di e-commerce e stai pianificando un'offerta lampo per un periodo di tempo limitato, prevedi picchi di traffico per tutta la durata della vendita.

Il provisioning della capacità di riserva è compatibile con il bursting dei pod, che consente ai pod usare temporaneamente le risorse richieste da altri pod sul nodo, la capacità è disponibile e inutilizzata da altri pod. Per usare il bursting, imposta i limiti delle risorse su un valore superiore a quello delle richieste di risorse oppure non impostare limiti. Per maggiori dettagli, vedi Configura il bursting dei pod in GKE.

Come funziona il provisioning della capacità di riserva in GKE

Per eseguire il provisioning della capacità di riserva, puoi utilizzare PriorityClasses e pod segnaposto di Kubernetes. Un PriorityClass consente di indicare a GKE che alcuni carichi di lavoro sono rispetto ad altri carichi di lavoro. Puoi eseguire il deployment di pod segnaposto che utilizzano PriorityClass e richiedere la capacità di calcolo necessaria di riserva. 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 di pod segnaposto a priorità inferiore e pianifica le nuove repliche dei tuoi di produzione (che usano un valore PriorityClass con priorità più alta). Se se disponi di più pod a bassa priorità con diversi livelli di priorità, GKE rimuove prima i pod con priorità più bassa.

Metodi di provisioning della capacità

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

  • Provisioning coerente della capacità: utilizza un deployment per creare una specifica di pod segnaposto a bassa priorità che vengono eseguiti 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 per ricreare i pod rimossi a bassa priorità. Questo metodo fornisce un overhead di capacità coerente in più eventi di scale up e scale down, fino a quando non elimini il deployment.
  • Provisioning della capacità per uso singolo: utilizza un job per eseguire un numero specifico di segnaposto paralleli a bassa priorità per un periodo di tempo specifico. Quando è trascorso il tempo o quando GKE rimuove tutte le repliche del job, la capacità prenotata non è più disponibile. Questo metodo fornisce una definizione la quantità di capacità disponibile per un periodo specifico.

Prezzi

In GKE Autopilot, ti viene addebitato il costo della risorsa dei pod in esecuzione, inclusi i carichi di lavoro a bassa priorità deployment. Per maggiori dettagli, vedi Prezzi di Autopilot.

In GKE Standard, ti vengono addebitati i costi VM di Compute Engine sottoposte a provisioning da GKE, indipendentemente dal fatto che i pod usano questa capacità. Per maggiori dettagli, vedi Prezzi standard

Prima di iniziare

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

  • Attiva l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine .
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi initialize con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  • Assicurati di avere un cluster GKE Autopilot, o un Cluster GKE Standard con provisioning automatico dei nodi in un bucket con il controllo delle versioni attivo.
  • Leggi le considerazioni sul provisioning della capacità per assicurati di scegliere i 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:

  • Default PriorityClass: un valore PriorityClass predefinito globale assegnato a qualsiasi pod che non imposti esplicitamente un PriorityClass diverso nel pod la specifica del container. I pod con questo valore PriorityClass predefinito possono rimuovere i pod che utilizzano un PriorityClass inferiore.
  • Low PriorityClass: un PriorityClass non predefinito impostato sul valore più basso la priorità più alta possibile in GKE. I pod con questo PriorityClass possono essere rimosso per eseguire pod con PriorityClass più elevati.

  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 un oggetto PriorityClass possono o meno e rimuovere i pod con priorità inferiore. Il PriorityClass low-priority utilizza Never, e il PriorityClass default utilizza PreemptLowerPriority.

    • value: la priorità per i pod che utilizzano il valore PriorityClass. default PriorityClass utilizza 0. Il PriorityClass low-priority utilizza -10. Nel Autopilot, puoi impostarlo su qualsiasi valore inferiore a default Priorità PriorityClass.

      In Standard, se imposti questo valore su un valore inferiore a -10, i pod che questo PriorityClass non attiverà la creazione di nuovi nodi In attesa.

      Per informazioni su come decidere i valori appropriati per la priorità, consulta Scegli una priorità.

    • globalDefault: specifica se GKE assegna o meno la classe PriorityClass ai pod che non impostano esplicitamente un PriorityClass nel la specifica del pod. Il PriorityClass low-priority utilizza false, e il PriorityClass default utilizza true.

  2. Applica il manifest:

    kubectl apply -f priorityclasses.yaml

Esegui il provisioning di capacità di calcolo aggiuntiva

Le seguenti sezioni mostrano un esempio in cui esegui il provisioning della capacità per un per un singolo evento o costantemente 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 per soddisfare i requisiti.
    • spec.resources.requests: modifica le richieste di CPU e memoria da soddisfare i tuoi requisiti. Utilizza le indicazioni in Scegliere il dimensionamento della capacità per aiutarti a decidere i valori appropriati per le richieste.
    • spec.containers.command e spec.containers.args: chiedi ai pod di e rimangono attive finché non vengono rimosse da GKE.

  2. Applica il manifest:

    kubectl apply -f capacity-res-deployment.yaml

  3. Ottieni lo stato del pod:

    kubectl get pods -l app=reservation

    Attendi che tutte le repliche abbiano lo stato Running.

Utilizza un job per il provisioning della capacità di evento singolo

  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 in cui vuoi eseguire in parallelo alla capacità di riserva.
    • spec.backoffLimit: 0: impedisci la creazione del controller Job lavori rimossi.
    • template.spec.resources.requests: modifica le richieste di CPU e memoria in ai tuoi requisiti. Utilizza le indicazioni presenti in Considerazioni per aiutarti a 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 necessaria la capacità aggiuntiva.

  2. Applica il manifest:

    kubectl apply -f capacity-res-job.yaml

  3. Visualizza lo stato del job:

    kubectl get jobs

    Attendi fino a quando lo stato di tutti i job è Running.

Testare il provisioning e l'eliminazione della capacità

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

  1. Nel terminale, osserva 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 originale del terminale, nota che GKE termina dei carichi di lavoro con provisioning della capacità per pianificare le nuove repliche, simile all'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

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

Considerazioni sul provisioning della capacità

Provisioning coerente della capacità

  • Valuta quante repliche di pod segnaposto ti servono e le dimensioni richieste in ogni replica. Le repliche a bassa priorità devono richiedere alle ore almeno la stessa capacità del carico di lavoro di produzione più grande, in modo che carichi di lavoro possono 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, prendi in considerazione impostando le richieste di risorse dei pod segnaposto su valori che eseguire il provisioning di una capacità sufficiente per eseguire più carichi di lavoro di produzione solo uno.

Provisioning della capacità monouso

  • Imposta il periodo di tempo durante il quale i job segnaposto vengono mantenuti fino all'ora durante le quali hai bisogno di capacità aggiuntiva. Ad esempio, se vuoi che il capacità aggiuntiva per un giorno di lancio di 24 ore, imposta il periodo su 86.400 secondi. Ciò garantisce che la capacità sottoposta a provisioning non duri più a lungo del necessario.
  • Imposta un periodo di manutenzione per lo stesso periodo di tempo che prenoti la capacità. Questo impedisce che i job a bassa priorità vengano rimossi durante un upgrade del nodo. Impostare un periodo di manutenzione è una buona prassi anche quando prevedi un'elevata domanda per il tuo carico di lavoro.
  • Se gestisci un numero elevato di carichi di lavoro di produzione su larga scala, prendi in considerazione impostando le richieste di risorse dei job segnaposto su valori che eseguire il provisioning di una capacità sufficiente per eseguire più carichi di lavoro di produzione solo uno.

Viene eseguito il provisioning della capacità solo per un singolo evento di scalabilità. Se fai lo scale up e usi per poi fare lo scale down, questa capacità non è più disponibile di scale up. Se prevedi più eventi di scale up e scale down, utilizza il metodo coerente di prenotazione della capacità se necessario. Ad esempio, aumentare le richieste dei pod prima di e in basso o a zero in seguito.

Scegli una priorità

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

Puoi definire più PriorityClass nel cluster da utilizzare con i carichi di lavoro con requisiti diversi. Ad esempio, puoi creare un oggetto PriorityClass con una priorità pari a -10 per il provisioning della capacità monouso e un valore PriorityClass con priorità -9 per un provisioning coerente della capacità. Poi potresti eseguire il provisioning di una capacità coerente utilizzando la classe PriorityClass con priorità -9 e, quando Se vuoi più capacità per un evento speciale, potresti eseguire il deployment di nuovi job che utilizzano il PriorityClass con priorità -10. GKE rimuove il livello più basso carichi di lavoro prioritari.

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

Scegli il dimensionamento della capacità

Imposta i conteggi delle repliche e le richieste di risorse del carico di lavoro segnaposto su maggiore o uguale alla capacità 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 di cui esegui il deployment e le richieste di risorse per ogni replica. Se lo scale up richiede di più capacità rispetto a GKE di cui è stato eseguito il provisioning per i pod segnaposto, parte della tua produzione rimangono in Pending finché GKE non può eseguire il provisioning e la capacità di archiviazione.

Passaggi successivi