Questa pagina è stata tradotta dall'API Cloud Translation.

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

Autopilot Standard

Questa pagina mostra come prenotare capacità di calcolo aggiuntiva nei tuoi cluster Google Kubernetes Engine (GKE) in modo che i tuoi carichi di lavoro possano scalare rapidamente durante gli 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. L'avvio di ogni nuovo nodo richiede da 80 a 120 secondi circa. GKE attende che il nodo sia avviato prima di collocare 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 voler avviare i pod più velocemente durante gli eventi di scalabilità. Ad esempio, se stai lanciando una nuova espansione per il tuo popolare gioco multiplayer con servizi dal vivo, i tempi di avvio più rapidi dei pod del server di gioco potrebbero ridurre i tempi di coda per i giocatori che eseguono l'accesso 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, prevedi picchi di traffico per tutta la durata della promozione.

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 utilizzare il bursting, imposta i limiti delle risorse più elevati rispetto alle richieste o non impostare i limiti delle risorse. Per maggiori dettagli, consulta Configurare l'esplosione 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 workload di produzione vengono scalati, GKE esegue l'espulsione dei pod segnaposto con priorità inferiore e pianifica al loro posto le nuove repliche dei pod di produzione (che utilizzano un PriorityClass di priorità più elevata). 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 una capacità aggiuntiva nei 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 esegue l'espulsione di questi pod per eseguire i tuoi carichi di lavoro di produzione, il controller dei deployment assicura che GKE provi più capacità per ricreare i pod a bassa priorità espulsi. Questo metodo fornisce un overhead di capacità coerente in più eventi di ridimensionamento fino all'eliminazione del deployment.
Provisioning della capacità per un solo utilizzo: utilizza un job per eseguire un numero specifico di pod segnaposto paralleli con priorità bassa per un periodo di tempo specifico. Quando questo tempo è trascorso o quando GKE esegue l'espulsione di 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 con priorità bassa 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, 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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. 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 provisioning automatico dei nodi abilitato.
Leggi le considerazioni per il provisioning della capacità per assicurarti di scegliere valori appropriati nelle richieste di capacità.

Crea una classe Priority

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

PriorityClass predefinito: un PriorityClass predefinito globale assegnato a qualsiasi pod che non imposta esplicitamente un PriorityClass diverso nella specifica del pod. I pod con questo PriorityClass predefinito possono espellere 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, 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à default 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 sapere come scegliere i 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 del pod. low-priority PriorityClass utilizza false e default PriorityClass utilizza true.
Applica il manifest:
```
kubectl apply -f priorityclasses.yaml
```

Esegui il provisioning di una 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 della capacità in modo 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 alle tue esigenze.
spec.resources.requests: modifica le richieste di CPU e memoria in base ai tuoi requisiti. Segui le indicazioni riportate 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

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à 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 da eseguire in parallelo per riservare la capacità.
- spec.backoffLimit: 0: impedisce al controller dei job di ricreare i job espulsi.
- template.spec.resources.requests: modifica le richieste di CPU e memoria per soddisfare i tuoi requisiti. Segui le indicazioni riportate nella sezione Considerazioni per scegliere i valori appropriati.
- template.spec.containers.command e template.spec.containers.args: chiedi 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
```
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:

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 il seguente 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 Pending a Running.

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 almeno la stessa capacità del tuo più grande carico di lavoro di produzione, in modo che questi workload possano rientrare nella capacità riservata dal tuo 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 la durata di conservazione dei job segnaposto fino al momento in cui hai bisogno di una capacità aggiuntiva. Ad esempio, se vuoi la capacità aggiuntiva per un giorno di lancio del gioco di 24 ore, imposta la durata 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 una domanda elevata 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.

Il provisioning della capacità viene eseguito solo per un singolo evento di scalabilità. Se esegui lo scale up e utilizzi la capacità, poi esegui fare lo scale down, la capacità non è più disponibile per un altro evento di scale up. Se prevedi più eventi di ridimensionamento, utilizza il metodo di prenotazione della capacità coerente e modifica le dimensioni della prenotazione in base alle esigenze. 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 PriorityClasses su un valore inferiore a 0.

Puoi definire più PriorityClass nel cluster da utilizzare con carichi di lavoro con requisiti diversi. Ad esempio, puoi creare un PriorityClass con una priorità -10 per il provisioning della capacità monouso e un 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 hai bisogno di una maggiore capacità per un evento speciale, puoi implementare nuovi job che utilizzano PriorityClass con priorità -10. GKE esegue l'espulsione prima dei workload con priorità più bassa.

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

Scegli 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 potrebbero aver bisogno i carichi di lavoro di produzione durante lo scale up.

La capacità totale di cui viene eseguito il provisioning si basa sul numero di pod segnaposto di cui viene eseguito il deployment 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 carichi di lavoro di produzione rimangono in Pending finché GKE non può eseguire il provisioning di più capacità.