Questa pagina è stata tradotta dall'API Cloud Translation.

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

Autopilota Standard

Questa pagina mostra come prenotare capacità di calcolo aggiuntiva i cluster Google Kubernetes Engine (GKE) per fare 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 prenotare il sovraccarico di calcolo su base coerente o in anticipo su 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 sono presenti 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. Nella 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 voler avviare i pod più velocemente durante gli eventi di scalabilità. Ad esempio, se stai lanciando una nuova espansione per il tuo popolare servizio live di giochi multiplayer, i tempi di avvio più rapidi dei pod del server di gioco potrebbero ridurre i tempi di attesa per i giocatori che accedono il giorno del lancio. Come ulteriore esempio, se esegui una piattaforma di e-commerce e stai pianificando una vendita 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 pod bursting, che consente ai pod di utilizzare temporaneamente le risorse richieste da altri pod sul nodo, se questa capacità è disponibile e non utilizzata 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 di Kubernetes e i pod segnaposto. Un 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 di bassa priorità e richiedere la capacità di calcolo necessaria da 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 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 hai più pod con priorità bassa con livelli di priorità diversi, GKE esegue prima l'espulsione dei 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 della capacità in modo coerente: utilizza un deployment per creare un numero specifico di pod segnaposto con priorità bassa 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 ridimensionamento fino all'eliminazione del 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 vengono addebitate le richieste di risorse dei pod in esecuzione, inclusi i carichi di lavoro a bassa priorità che esegui. Per i dettagli, consulta Prezzi di Autopilot.

In GKE Standard, ti vengono addebitate le VM Compute Engine di base di cui GKE esegue il provisioning, indipendentemente dal fatto che i pod utilizzino questa capacità. Per maggiori dettagli, vedi 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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Assicurati di avere un cluster GKE Autopilot o un cluster GKE Standard con il provisioning automatico dei nodi 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.
PriorityClass basso: un PriorityClass non predefinito impostato sulla priorità più bassa possibile in GKE. I pod con questo PriorityClass possono essere espulsi per eseguire pod con PriorityClass più elevati.

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 PriorityClass possono o meno rimuovere i pod con priorità inferiore. low-priority PriorityClass utilizza Never e default PriorityClass utilizza PreemptLowerPriority.
- value: la priorità per i pod che utilizzano il valore PriorityClass. default PriorityClass utilizza 0. low-priority PriorityClass utilizza -10. Nella 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 utilizzano PriorityClass non attiveranno la creazione di nuovi nodi e rimarranno in stato Pending.
  
  Per decidere i valori appropriati per la priorità, consulta Scegliere 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.
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.

Usa un deployment per il provisioning coerente della capacità

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 in base ai 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.

Applica il manifest:

kubectl apply -f capacity-res-deployment.yaml

Recupera 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

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 da eseguire in parallelo per riservare la capacità.
- spec.backoffLimit: 0: impedisci la creazione del controller Job lavori rimossi.
- template.spec.resources.requests: modifica le richieste di CPU e memoria in in base 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.
Applica il manifest:
```
kubectl apply -f capacity-res-job.yaml
```
Visualizza lo stato del job:
```
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:

Nel terminale, controlla 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
```

Apri una nuova finestra del terminale e svolgi i seguenti passaggi:

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 dei carichi di lavoro di provisioning della capacità per pianificare le nuove repliche, in modo 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 per il provisioning della capacità

Provisioning della capacità coerente

Valuta quante repliche di pod segnaposto sono necessarie e le dimensioni delle 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, ti consigliamo di impostare le richieste di risorse dei pod segnaposto su valori che prevedono una capacità sufficiente per eseguire più carichi di lavoro di produzione anziché uno solo.

Provisioning della capacità per uso singolo

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. In questo modo, la capacità di cui hai eseguito il provisioning non dura più del necessario.
Imposta un periodo di manutenzione per lo stesso periodo di tempo per cui stai prenotando la capacità. In questo modo, i job con priorità bassa non vengono espulsi 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, ti consigliamo di impostare le richieste di risorse dei job segnaposto su valori che prevedono una capacità sufficiente per eseguire più carichi di lavoro di produzione anziché uno solo.

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 di pod prima di un evento e ridurle o impostarle su zero dopo.

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 esegue prima l'espulsione dei carichi di lavoro con priorità più bassa.

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 il numero di repliche e le richieste di risorse del carico di lavoro segnaposto su un valore maggiore o uguale alla capacità di cui potrebbero aver bisogno 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 fino a quando GKE non può eseguire il provisioning e la capacità di archiviazione.