Questa pagina mostra come scalare i deployment in Google Kubernetes Engine (GKE) regolando automaticamente le risorse utilizzando metriche come l'allocazione delle risorse, il traffico del bilanciatore del carico, le metriche personalizzate o più metriche contemporaneamente. Questa pagina fornisce anche istruzioni passo passo per configurare un profilo HorizontalPodAutoscaler (HPA), tra cui come visualizzare, eliminare, pulire e risolvere i problemi dell'oggetto HPA. Un deployment è un oggetto API Kubernetes che consente di eseguire più repliche di pod distribuite tra i nodi di un cluster.
Questa pagina è rivolta agli sviluppatori e agli operatori che gestiscono la scalabilità delle applicazioni in GKE e vogliono capire come ottimizzare dinamicamente le prestazioni e mantenere l'efficienza dei costi tramite la scalabilità automatica orizzontale dei pod. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui viene fatto riferimento nei contenuti di Google Cloud consulta Ruoli utente e attività comuni di GKE.
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
- Per 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 comando
gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
- Assicurati di avere un cluster Autopilot o Standard esistente. Se non ne hai uno, crea un cluster Autopilot.
Versioni API per gli oggetti HorizontalPodAutoscaler
Quando utilizzi la console Google Cloud , gli oggetti HPA vengono creati utilizzando l'API autoscaling/v2. L'API autoscaling/v1 è ancora supportata, ma non è più consigliata e non supporta alcune funzionalità, come lo scale up e lo scale down da e verso zero utilizzando l'HPA.
Crea il deployment di esempio
Prima di poter creare un oggetto HPA, devi creare il workload che monitora. Gli esempi in questa pagina applicano diverse configurazioni HPA al seguente deployment nginx. Esempi separati mostrano un HPA basato sull'utilizzo delle risorse, basato su una metrica personalizzata o esterna e basato su più metriche.
Salva quanto segue in un file denominato nginx.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
resources:
# You must specify requests for CPU to autoscale
# based on CPU utilization
requests:
cpu: "250m"
Questo manifest specifica un valore per le richieste di CPU. Se vuoi scalare automaticamente in base all'utilizzo di una risorsa in percentuale, devi specificare le richieste per quella risorsa. Se non specifichi le richieste, puoi eseguire la scalabilità automatica solo in base al valore assoluto dell'utilizzo della risorsa, ad esempio milliCPU per l'utilizzo della CPU.
Per creare il deployment, applica il manifest nginx.yaml:
kubectl apply -f nginx.yaml
Il deployment ha spec.replicas impostato su 3, quindi vengono eseguiti il deployment di tre pod.
Puoi verificarlo utilizzando il comando kubectl get deployment nginx.
Ciascuno degli esempi in questa pagina applica un oggetto HPA diverso a un esempio di deployment nginx.
Scalabilità automatica in base all'utilizzo delle risorse
Questo esempio crea un oggetto HPA per la scalabilità automatica del
deployment nginx quando l'utilizzo della CPU
supera il 50% e contribuisce a garantire che ci sia sempre un minimo di 1 replica e
un massimo di 10 repliche.
Puoi creare un HPA che ha come target la CPU utilizzando la console Google Cloud , il comando
kubectl apply o, solo per la CPU media, il comando kubectl autoscale.
Console
Vai alla pagina Workload nella console Google Cloud .
Fai clic sul nome del deployment
nginx.Fai clic su list Azioni > Modifica scalabilità automatica.
Nella sezione Scalabilità automatica orizzontale dei pod, fai clic su Seleziona e configura.
Specifica i seguenti valori:
- Numero minimo di repliche:1
- Numero massimo di repliche:10
- Metrica di scalabilità automatica: CPU
- Target:50
- Unità: CPU
Fai clic su Invia.
kubectl apply
Salva il seguente manifest YAML in un file denominato nginx-hpa.yaml:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
# Set the minimum and maximum number of replicas the Deployment can scale to.
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
# The target average CPU utilization percentage across all Pods.
name: cpu
target:
type: Utilization
averageUtilization: 50
Se crei un manifest per corrispondere a dettagli specifici del tuo progetto, assicurati di non includere dati sensibili nei campi dell'Horizontal Pod Autoscaler.
Per creare l'HPA, applica il manifest utilizzando questo comando:
kubectl apply -f nginx-hpa.yaml
kubectl autoscale
Per creare un oggetto HPA che ha come target solo l'utilizzo medio della CPU, puoi utilizzare il comando kubectl autoscale:
kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10
Per visualizzare un elenco di HPA nel cluster, utilizza questo comando:
kubectl get hpa
L'output è simile al seguente:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/50% 1 10 3 61s
Per visualizzare i dettagli sull'HPA, puoi utilizzare la console Google Cloud o il comando kubectl.
Console
Vai alla pagina Workload nella console Google Cloud .
Fai clic sul nome del deployment
nginx.Fai clic sulla scheda Scalabilità.
kubectl get
Per ottenere dettagli sull'HPA, puoi utilizzare kubectl get hpa con il flag -o yaml. Il campo status contiene informazioni sul numero attuale di repliche e su eventuali eventi di scalabilità automatica recenti.
kubectl get hpa nginx -o yaml
L'output è simile al seguente:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"metrics":[{"resource":{"name":"cpu","target":{"averageUtilization":50,"type":"Utilization"}},"type":"Resource"}],"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"}}}
creationTimestamp: "2025-10-30T19:42:43Z"
name: nginx
namespace: default
resourceVersion: "220050"
selfLink: /apis/autoscaling/v2/namespaces/default/horizontalpodautoscalers/nginx
uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
status:
conditions:
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: recent recommendations were higher than current one, applying the highest recent recommendation
reason: ScaleDownStabilized
status: "True"
type: AbleToScale
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
reason: ValidMetricFound
status: "True"
type: ScalingActive
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: the desired count is within the acceptable range
reason: DesiredWithinRange
status: "False"
type: ScalingLimited
currentMetrics:
- type: Resource
resource:
name: cpu
current:
averageUtilization: 0
averageValue: "0"
currentReplicas: 3
desiredReplicas: 3
Se crei un manifest per corrispondere a dettagli specifici del tuo progetto, assicurati di non includere dati sensibili nei campi dell'Horizontal Pod Autoscaler.
Prima di seguire gli esempi rimanenti in questa pagina, elimina HPA:
kubectl delete hpa nginx
Quando elimini un oggetto HPA, il numero di repliche del deployment rimane invariato. Un deployment non torna automaticamente allo stato precedente all'applicazione dell'HPA.
Scopri di più sull'eliminazione di un HPA.
Scalabilità automatica in base a una metrica personalizzata o esterna
Qualsiasi metrica emessa dal tuo workload o che puoi interrogare da una fonte esterna può essere utilizzata per la scalabilità automatica. GKE supporta la scalabilità automatica basata su metriche personalizzate e metriche esterne in molte situazioni e Kubernetes supporta adattatori di metriche aggiuntivi come KEDA e l'adattatore Prometheus.
Scalabilità automatica in base al traffico del bilanciatore del carico
La scalabilità automatica basata sul traffico è una funzionalità di GKE che integra gli indicatori di utilizzo del traffico dei bilanciatori del carico per scalare automaticamente i pod.
L'utilizzo del traffico come indicatore di scalabilità automatica potrebbe essere utile in quanto è un indicatore principale del carico complementare a CPU e memoria. L'integrazione integrata con GKE contribuisce a garantire che la configurazione sia semplice e che lo scalabilità automatica reagisca rapidamente ai picchi di traffico per soddisfare la domanda.
La scalabilità automatica basata sul traffico è abilitata dal controller Gateway e dalle sue funzionalità di gestione del traffico globale. Per saperne di più, consulta Scalabilità automatica basata sul traffico.
La scalabilità automatica basata sul traffico del bilanciatore del carico è disponibile solo per i carichi di lavoro del gateway.
Requisiti
La scalabilità automatica basata sul traffico presenta i seguenti requisiti:
- Supportato su GKE 1.31 e versioni successive.
- API Gateway abilitata nel tuo progetto.
- Supportato per il traffico che passa attraverso i bilanciatori del carico di cui è stato eseguito il deployment utilizzando l'API Gateway e
gke-l7-global-external-managed,gke-l7-regional-external-managed,gke-l7-rilbogke-l7-gxlbGatewayClass.
Limitazioni
La scalabilità automatica basata sul traffico presenta le seguenti limitazioni:
- Non supportato dalle GatewayClass multi-cluster
(
gke-l7-global-external-managed-mc,gke-l7-regional-external-managed-mc,gke-l7-rilb-mcegke-l7-gxlb-mc). - Non supportato per il traffico che utilizza servizi di tipo
LoadBalancer. - Deve esistere una relazione chiara e isolata tra i componenti coinvolti nello scaling automatico basato sul traffico. Un oggetto HPA deve essere dedicato alla scalabilità di un singolo deployment (o di qualsiasi risorsa scalabile) esposto da un singolo servizio.
- Dopo aver configurato la capacità del servizio utilizzando il campo
maxRatePerEndpoint, lascia trascorrere un tempo sufficiente (in genere un minuto, ma potenzialmente fino a 15 minuti nei cluster di grandi dimensioni) prima che il bilanciatore del carico venga aggiornato con questa modifica, prima di configurare HPA con metriche basate sul traffico. Questo approccio aiuta a garantire che il servizio non si trovi temporaneamente in una situazione in cui il cluster tenta di eseguire la scalabilità automatica in base alle metriche emesse da un bilanciatore del carico ancora in fase di configurazione. - Se la scalabilità automatica basata sul traffico viene utilizzata su un servizio gestito da più bilanciatori del carico (ad esempio, sia da un ingresso che da un gateway o da due gateway), HPA potrebbe considerare il valore di traffico più alto dei singoli bilanciatori del carico per prendere decisioni di scalabilità, anziché la somma dei valori di traffico di tutti i bilanciatori del carico.
Esegui il deployment della scalabilità automatica basata sul traffico
L'esercizio seguente utilizza l'HPA per scalare automaticamente il deployment store-autoscale in base al traffico che riceve. Un
gateway accetta il traffico
in entrata da internet per i pod. Il gestore della scalabilità automatica confronta gli indicatori di traffico del gateway con la capacità di traffico per pod configurata nella risorsa del servizio store-autoscale. Generando
traffico verso il gateway, influisci sul numero di pod di cui viene eseguito il deployment.
Il seguente diagramma mostra come funziona la scalabilità automatica basata sul traffico:
Per eseguire il deployment della scalabilità automatica basata sul traffico, segui questi passaggi:
Per i cluster Standard, verifica che le GatewayClasses siano installate nel cluster. Per i cluster Autopilot, le GatewayClass vengono installate per impostazione predefinita.
kubectl get gatewayclassL'output conferma che le risorse GKE GatewayClass sono pronte per l'uso nel cluster:
NAME CONTROLLER ACCEPTED AGE gke-l7-global-external-managed networking.gke.io/gateway True 16h gke-l7-regional-external-managed networking.gke.io/gateway True 16h gke-l7-gxlb networking.gke.io/gateway True 16h gke-l7-rilb networking.gke.io/gateway True 16hSe non vedi questo output, attiva l'API Gateway nel tuo cluster GKE.
Esegui il deployment dell'applicazione di esempio e del bilanciatore del carico del gateway nel tuo cluster:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yamlL'applicazione di esempio crea:
- Un deployment con 2 repliche.
- Un servizio con un'impostazione
GCPBackendPolicyassociatamaxRatePerEndpointimpostata su10. Per scoprire di più sulle funzionalità del gateway, consulta Funzionalità di GatewayClass. - Un gateway esterno per accedere all'applicazione su internet. Per saperne di più su come utilizzare i bilanciatori del carico del gateway, consulta Deployment dei gateway.
- Un HTTPRoute che corrisponde a tutto il traffico e lo invia al servizio
store-autoscale.
La capacità del servizio è un elemento fondamentale quando si utilizza la scalabilità automatica basata sul traffico, perché determina la quantità di traffico per pod che attiva un evento di scalabilità automatica. Viene configurato utilizzando un campo
maxRatePerEndpointin un GCPBackendPolicy associato al servizio, che definisce il traffico massimo che un servizio deve ricevere in richieste al secondo per pod. La capacità del servizio è specifica per la tua applicazione.Per saperne di più, consulta Determinare la capacità del servizio.
Salva il seguente manifest come
hpa.yaml:apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: store-autoscale spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: store-autoscale # Set the minimum and maximum number of replicas the Deployment can scale to. minReplicas: 1 maxReplicas: 10 # This section defines that scaling should be based on the fullness of load balancer # capacity, using the following configuration. metrics: - type: Object object: describedObject: kind: Service name: store-autoscale metric: # The name of the custom metric which measures how "full" a backend is # relative to its configured capacity. name: "autoscaling.googleapis.com|gclb-capacity-fullness" target: # The target average value for the metric. The autoscaler adjusts the number # of replicas to maintain an average capacity fullness of 70% across all Pods. averageValue: 70 type: AverageValueQuesto manifest descrive un oggetto HPA con le seguenti proprietà:
minReplicasemaxReplicas: imposta il numero minimo e massimo di repliche per questo deployment. In questa configurazione, il numero di pod può scalare da1a10repliche (o da0repliche se configuri lo scaling da e verso zero utilizzando HPA).describedObject.name: store-autoscale: il riferimento al serviziostore-autoscaleche definisce la capacità di traffico.scaleTargetRef.name: store-autoscale: il riferimento alstore-autoscaleDeployment che definisce la risorsa scalata da HPA.averageValue: 70: valore medio target del 70% di utilizzo della capacità. In questo modo, l'HPA ha un margine di crescita che consente ai pod in esecuzione di elaborare il traffico in eccesso durante la creazione di nuovi pod.
Se crei un manifest per corrispondere a dettagli specifici del tuo progetto, assicurati di non includere dati sensibili nei campi dell'Horizontal Pod Autoscaler.
HPA genera il seguente comportamento del traffico:
- Il numero di pod viene modificato tra 1 e 10 repliche per raggiungere
il 70% della velocità massima per endpoint. In questo modo, si ottengono 7 RPS per pod quando
maxRatePerEndpoint=10. - Con più di 7 RPS per pod, i pod vengono scalati verticalmente fino a raggiungere il numero massimo di 10 repliche o fino a quando il traffico medio è di 7 RPS per pod.
- Se il traffico viene ridotto, i pod fare lo scale down a una velocità ragionevole utilizzando l'algoritmo HPA.
Puoi anche eseguire il deployment di un generatore di traffico per convalidare il comportamento di scalabilità automatica basata sul traffico.
A 30 RPS, il deployment viene scalato a 5 repliche in modo che ogni replica riceva idealmente 6 RPS di traffico, il che corrisponderebbe a un utilizzo del 60% per pod. Questo valore è inferiore all'utilizzo target del 70%, pertanto i pod vengono scalati in modo appropriato. A seconda delle fluttuazioni del traffico, anche il numero di repliche con scalabilità automatica potrebbe variare. Per una descrizione più dettagliata di come viene calcolato il numero di repliche, consulta Comportamento della scalabilità automatica.
Scalabilità automatica in base a più metriche
Questo esempio crea un oggetto HPA che esegue la scalabilità automatica in base all'utilizzo della CPU e a una
metrica personalizzata denominata packets_per_second.
Se hai seguito l'esempio precedente e hai ancora un oggetto HPA denominato nginx,
eliminalo prima di seguire questo esempio.
Questo esempio richiede apiVersion: autoscaling/v2. Per saperne di più
sulle API disponibili, consulta Versioni API per gli oggetti HPA.
Salva questo manifest YAML come file denominato nginx-multiple.yaml:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 10
metrics: # The metrics to base the autoscaling on.
- type: Resource
resource:
name: cpu # Scale based on CPU utilization.
target:
type: Utilization
averageUtilization: 50
# The HPA will scale the replicas to try and maintain an average
# CPU utilization of 50% across all Pods.
- type: Resource
resource:
name: memory # Scale based on memory usage.
target:
type: AverageValue
averageValue: 100Mi
# The HPA will scale the replicas to try and maintain an average
# memory usage of 100 Mebibytes (MiB) across all Pods.
# Uncomment these lines if you create the custom packets_per_second metric and
# configure your app to export the metric.
# - type: Pods
# pods:
# metric:
# name: packets_per_second
# target:
# type: AverageValue
# averageValue: 100
Se crei un manifest in modo che corrisponda a dettagli specifici del tuo progetto, assicurati di non includere dati sensibili nei campi del gestore della scalabilità automatica orizzontale dei pod.
Applica il manifest YAML:
kubectl apply -f nginx-multiple.yaml
Una volta creato, HPA monitora il deployment nginx per l'utilizzo medio della CPU, l'utilizzo medio della memoria e (se hai rimosso il commento) la metrica personalizzata packets_per_second. L'HPA scala automaticamente il deployment in base alla metrica il cui valore creerebbe l'evento di scalabilità automatica più grande.
Scale up e scale down da zero
A partire dalla versione 1.37 di GKE, puoi configurare l'HPA in modo da fare lo scale down di un deployment fino a zero (0) repliche quando non c'è domanda di workload e fare lo scale up automatico quando la domanda aumenta. Quando esegui lo scale up da zero, GKE ignora i controlli standard di tolleranza delle metriche per attivare i pod senza ritardi.
Per configurare lo scale up e lo scale down da zero utilizzando HPA, devi:
- Assicurati che il cluster esegua GKE versione 1.37 o successive.
- Configura almeno una metrica personalizzata o esterna utilizzando la risorsa AutoscalingMetric.
- Imposta la coppia campo-valore
minReplicas: 0in un manifest HPA che utilizza l'APIautoscaling/v2.
Per istruzioni passo passo, vedi Scalare i carichi di lavoro GKE a zero e da zero utilizzando HPA.
Configura il profilo HPA per il rendimento
Il profilo HPA per le prestazioni migliora il tempo di reazione della scalabilità automatica orizzontale dei pod, contribuendo a migliorare la capacità dell'HPA di gestire un numero elevato di oggetti (fino a 1000 oggetti nelle versioni secondarie 1.31-1.32 e 5000 oggetti nella versione 1.33 o successive).
Questo profilo viene attivato automaticamente sui cluster Autopilot idonei con un control plane che esegue GKE 1.32 o versioni successive. Per i cluster standard, il profilo viene abilitato automaticamente sui cluster idonei con un control plane che esegue GKE versione 1.33 o successive.
Un cluster Standard è esente dall'attivazione automatica del profilo HPA Performance se soddisfa tutte le seguenti condizioni:
- Il cluster sta eseguendo l'upgrade da una versione precedente alla versione 1.33 o successiva.
- Il cluster ha almeno un pool di nodi con uno dei seguenti tipi di macchina:
e2-micro,e2-custom-micro,g1-small,f1-micro. - Il provisioning automatico dei nodi non è abilitato.
Puoi anche abilitare il profilo HPA per il rendimento sui cluster esistenti se soddisfano i requisiti.
Requisiti
Per abilitare il profilo HPA per il rendimento, verifica che i cluster Autopilot e standard soddisfino i seguenti requisiti:
- Il control plane esegue GKE versione 1.31 o successive.
- Se il control plane esegue GKE versione 1.31, abilita la raccolta delle metriche di sistema.
- L'API Autoscaling è abilitata nel tuo progetto.
- Tutti gli
account di servizio dei nodi
hanno il ruolo
roles/autoscaling.metricsWriterassegnato. - Se utilizzi i Controlli di servizio VPC, verifica che l'API Autoscaling sia inclusa nel perimetro di servizio.
Attiva il profilo HPA per il rendimento
Per attivare il profilo HPA per il rendimento nel cluster, utilizza questo comando:
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--project=PROJECT_ID \
--hpa-profile=performance
Sostituisci:
CLUSTER_NAME: il nome del cluster.LOCATION: zona o regione di computing (ad es. us-central1-a o us-central1) per il cluster.PROJECT_ID: l'ID progetto Google Cloud .
Disattiva il profilo HPA per le prestazioni
Per disattivare il profilo HPA per il rendimento in un cluster, utilizza il seguente comando:
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--project=PROJECT_ID \
--hpa-profile=none
Sostituisci:
CLUSTER_NAME: il nome del cluster.LOCATION: zona o regione di computing (ad es. us-central1-a o us-central1) per il cluster.PROJECT_ID: l'ID progetto Google Cloud .
Visualizzazione dei dettagli di un HorizontalPodAutoscaler
Per visualizzare la configurazione e le statistiche di un HPA, utilizza il seguente comando:
kubectl describe hpa HPA_NAME
Sostituisci HPA_NAME con il nome dell'oggetto HPA.
Lo stato attuale di ogni oggetto HPA è mostrato nel campo Conditions e gli eventi di scalabilità automatica sono elencati nel campo Events.
L'output è simile al seguente:
Name: nginx
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"s...
CreationTimestamp: Tue, 05 May 2020 20:07:11 +0000
Reference: Deployment/nginx
Metrics: ( current / target )
resource memory on pods: 2220032 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Deployment pods: 1 current / 1 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale recommended size matches current size
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
Eliminazione di un HorizontalPodAutoscaler
Puoi eliminare un oggetto HPA utilizzando la console Google Cloud o il comando kubectl delete.
Console
Per eliminare l'oggetto HPA nginx:
Vai alla pagina Workload nella console Google Cloud .
Fai clic sul nome del
nginxdeployment.Fai clic su list Azioni > Scala automaticamente.
Fai clic su Elimina.
kubectl delete
Per eliminare l'oggetto HPA nginx, utilizza il seguente comando:
kubectl delete hpa nginx
Quando elimini un oggetto HPA, il deployment (o un altro oggetto di deployment) rimane
alla sua scala esistente e non viene ripristinato il numero di repliche nel
manifest originale del deployment. Per scalare manualmente il deployment di nuovo a tre pod, puoi utilizzare il comando kubectl scale:
kubectl scale deployment nginx --replicas=3
Pulizia
Elimina l'oggetto HPA, se non l'hai ancora fatto:
kubectl delete hpa nginxElimina il deployment
nginx:kubectl delete deployment nginxFacoltativamente, elimina il cluster.
Risoluzione dei problemi
Per suggerimenti sulla risoluzione dei problemi, vedi Risolvere i problemi relativi alla scalabilità automatica orizzontale dei pod.
Passaggi successivi
- Scopri di più sulla scalabilità automatica orizzontale dei pod.
- Scopri come ridimensionare in modo ottimale i workload HPA con VPA.
- Scopri di più sulla scalabilità automatica verticale dei pod.
- Scopri di più sul CPU startup boost.