Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Autopilot Standard

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

Perché è utile il provisioning della capacità di riserva

I cluster GKE Autopilot e i cluster Standard con 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 avviare i pod più velocemente durante gli eventi di scale up. 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 un'offerta lampo per un periodo di tempo limitato, prevedi 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 non viene utilizzata da altri pod. Per utilizzare il bursting, imposta i limiti delle risorse su un valore superiore alle richieste di risorse o non impostare limiti delle 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 della capacità di riserva, puoi utilizzare Kubernetes PriorityClasses e i pod segnaposto. Una PriorityClass ti consente di indicare 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 che devi prenotare. GKE aggiunge capacità al cluster creando nuovi nodi per ospitare i pod segnaposto.

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

Quando un pod segnaposto viene espulso, torna allo stato In attesa. Se utilizzi un deployment per il provisioning coerente, il controller del deployment tenta immediatamente di ricreare il pod. Se un pod segnaposto ha una priorità di -10, attiverà la scalabilità automatica del cluster per creare un nuovo nodo (se necessario) per sostituire la capacità prenotata appena utilizzata. Questo ciclo contribuisce a garantire che il cluster mantenga sempre la quantità specificata di capacità di riserva.

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 della capacità coerente: 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 del deployment contribuisce a garantire che GKE esegua il provisioning di una maggiore capacità per ricreare i pod a bassa priorità espulsi. Questo metodo fornisce un overhead di capacità coerente in più eventi di scale up e scale down, finché non elimini il deployment.
Provisioning della capacità a utilizzo singolo: utilizza un job per eseguire un numero specifico di pod segnaposto paralleli a bassa priorità per un periodo di tempo specifico. Al termine del periodo di tempo o quando GKE espelle tutte le repliche del job, la capacità prenotata non è più disponibile. Questo metodo fornisce una quantità specifica di capacità disponibile per un periodo specifico.

Prezzi

In GKE Autopilot, ti vengono addebitati i costi per le richieste di risorse dei pod in esecuzione, inclusi i carichi di lavoro a bassa priorità di cui esegui il deployment. Per maggiori dettagli, consulta Prezzi di Autopilot.

In GKE Standard, ti vengono addebitati i costi per le VM Compute Engine sottostanti di cui GKE esegue il provisioning, indipendentemente dal fatto che i pod utilizzino o meno questa capacità. Per maggiori dettagli, consulta Prezzi di 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à, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Nota: per le installazioni esistenti di gcloud CLI assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Assicurati di avere un cluster GKE Autopilot, o un cluster GKE Standard con il provisioning automatico dei nodi abilitato.
Leggi le Considerazioni per il provisioning della capacità per assicurarti di scegliere valori appropriati nelle richieste di capacità.

Creare una 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.
PriorityClass a bassa priorità: una PriorityClass non predefinita impostata sulla priorità più bassa possibile in GKE. I pod con questa PriorityClass possono essere espulsi per eseguire pod con PriorityClass più elevate.

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 o meno i pod a priorità inferiore. La PriorityClass low-priority utilizza Never e la PriorityClass default utilizza PreemptLowerPriority.
- value: la priorità per i pod che utilizzano la PriorityClass. Nei cluster GKE, la scalabilità automatica del cluster utilizza un limite di priorità eliminabile predefinito di -10. Con una priorità di -10 o superiore, i pod possono attivare la creazione di nuovi nodi se non è disponibile capacità. Con una priorità inferiore a -10, i pod non attivano la scalabilità automatica del cluster e pertanto non viene eseguito il provisioning di nuovi nodi. Se non esiste capacità, i pod rimangono nello stato In attesa.
  
  Per scegliere i valori di priorità appropriati, consulta Scegliere una priorità.
- globalDefault: specifica se GKE assegna o meno la PriorityClass ai pod che non impostano esplicitamente una PriorityClass nella specifica del pod. La PriorityClass low-priority utilizza false e la PriorityClass default utilizza true.
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.

Utilizzare un deployment per il provisioning della capacità coerente

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 ai tuoi requisiti.
spec.resources.requests: modifica le richieste di CPU e memoria in base ai tuoi requisiti. Utilizza le indicazioni in Scegliere le dimensioni 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 espulsi da GKE.

Applica il manifest:

kubectl apply -f capacity-res-deployment.yaml

Ottieni 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à per un singolo evento

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: impedisce al controller del job di ricreare i job espulsi.
- template.spec.resources.requests: modifica le richieste di CPU e memoria in base ai tuoi requisiti. Utilizza le indications in 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.
Applica il manifest:
```
kubectl apply -f capacity-res-job.yaml
```
Ottieni lo stato del job:
```
kubectl get jobs
```
Attendi che tutti i job abbiano lo stato Running.

Testare il provisioning della capacità e l'espulsione

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

Nel terminale, monitora lo stato dei carichi di lavoro di 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
```

Apri una nuova finestra del terminale ed esegui le seguenti operazioni:

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

Applica il manifest:
```
kubectl apply -f test-deployment.yaml
```

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

Questo output mostra che il nuovo deployment ha impiegato cinque secondi per passare dallo stato In attesa allo stato In esecuzione.

Considerazioni per il provisioning della capacità

Le sezioni seguenti forniscono suggerimenti che potrebbero aiutarti a migliorare l'affidabilità della capacità di cui esegui il provisioning.

Provisioning della capacità coerente

Valuta il numero di repliche dei 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 carico di lavoro di produzione più grande, in modo che questi carichi di lavoro 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 eseguono il provisioning di una capacità sufficiente per eseguire più carichi di lavoro di produzione anziché uno solo.

Provisioning della capacità a utilizzo singolo

Imposta la durata di persistenza dei job segnaposto sul periodo di tempo durante il quale hai bisogno di capacità aggiuntiva. Ad esempio, se vuoi la capacità aggiuntiva per un giorno di lancio del gioco di 24 ore, imposta la durata su 86400 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 espulsi durante l'upgrade di un nodo. L'impostazione di un periodo di manutenzione è anche una buona pratica 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 eseguono il provisioning di 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 esegui lo scale up e utilizzi la capacità, quindi esegui fare lo scale down, tale 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, aumentando le richieste di pod prima di un evento e riducendole o azzerandole dopo.

Scegliere una priorità

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à di -10 per il provisioning della capacità a utilizzo singolo e una PriorityClass con una priorità di -9 per il provisioning della capacità coerente. Puoi quindi eseguire il provisioning della capacità coerente utilizzando la PriorityClass con priorità -9 e, quando vuoi più capacità per un evento speciale, puoi eseguire il deployment di nuovi job che utilizzano la PriorityClass con priorità -10. GKE espelle prima i carichi di lavoro con la priorità più bassa.

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

Scegliere le dimensioni della capacità

Imposta il numero di repliche e le richieste di risorse del carico di lavoro segnaposto su un valore maggiore o uguale alla capacità di cui i carichi di lavoro di produzione potrebbero aver bisogno 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 una capacità maggiore di quella di cui GKE ha eseguito il provisioning per i pod segnaposto, alcuni carichi di lavoro di produzione rimangono nello stato Pending finché GKE non può eseguire il provisioning di una maggiore capacità.