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 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. 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 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 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 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 limiti di risorse superiori alle richieste di risorse oppure non impostare risorse 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
inizializzare
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 in cui è abilitato il controllo delle versioni.
- 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 e la specifica del prodotto. 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.
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 PriorityClasslow-priority
utilizzaNever
, e il PriorityClassdefault
utilizzaPreemptLowerPriority
.value
: la priorità per i pod che utilizzano il valore PriorityClass.default
PriorityClass utilizza0
. Il PriorityClasslow-priority
utilizza-10
. Nella Autopilot, puoi impostarlo su qualsiasi valore inferiore adefault
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 PriorityClasslow-priority
utilizzafalse
, e il PriorityClassdefault
utilizzatrue
.
Applica il manifest:
kubectl apply -f priorityclasses.yaml
Esegui il provisioning di capacità di calcolo aggiuntiva
Le sezioni seguenti 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à
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
espec.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
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
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 in base ai tuoi requisiti. Utilizza le indicazioni presenti in Considerazioni per aiutarti a decidere i valori appropriati.template.spec.containers.command
etemplate.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 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:
Nel terminale, osserva lo stato dei carichi di lavoro per il provisioning della capacità:
Per i deployment, esegui questo comando:
kubectl get pods --label=app=reservation -w
Per i job, esegui questo comando:
kubectl get Jobs -w
Apri una nuova finestra del terminale e procedi nel seguente modo:
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 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 a 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
fino a quando GKE non può eseguire il provisioning
e la capacità di archiviazione.
Passaggi successivi
- Scopri come separare i carichi di lavoro l'uno dall'altro
- Scopri come ottimizzare la scalabilità automatica dei carichi di lavoro in base alle metriche