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), incluso come visualizzare, eliminare, pulire e risolvere i problemi relativi all'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 è dedicata agli operatori e agli sviluppatori che gestiscono lo scaling 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 si fa riferimento nei contenuti di Google Cloud, consulta la pagina Ruoli utente e attività comuni di GKE.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API 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 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 ne hai bisogno, 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.
Quando utilizzi kubectl per creare o visualizzare informazioni su un oggetto HPA, puoi specificare l'API autoscaling/v1 o l'API autoscaling/v2.
apiVersion: autoscaling/v1è l'impostazione predefinita e consente di scalare automaticamente solo in base all'utilizzo della CPU. Per la scalabilità automatica in base ad altre metriche, è consigliabile utilizzareapiVersion: autoscaling/v2. L'esempio in Crea il deployment di esempio utilizzaapiVersion: autoscaling/v1.apiVersion: autoscaling/v2è consigliato per la creazione di nuovi oggetti HPA. Consente di scalare automaticamente in base a più metriche, incluse metriche personalizzate o esterne. Tutti gli altri esempi in questa pagina utilizzanoapiVersion: autoscaling/v2.
Per controllare quali versioni dell'API sono supportate, utilizza il comando kubectl api-versions.
Puoi specificare quale API utilizzare quando
visualizzi i dettagli di un HPA che utilizza apiVersion: autoscaling/v2.
Crea il deployment di esempio
Prima di poter creare un oggetto HPA, devi creare il carico di lavoro 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, su una metrica personalizzata o esterna e 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 utilizzare la scalabilità automatica solo in base al valore assoluto dell'utilizzo della risorsa, ad esempio i millicore 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
nginx deployment 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 di
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 come file denominato nginx-hpa.yaml:
apiVersion: autoscaling/v1
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
# The target average CPU utilization percentage across all Pods.
targetCPUUtilizationPercentage: 50
Per creare 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 ottenere dettagli su 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 di
nginx.Fai clic sulla scheda Scalabilità.
kubectl get
Per ottenere dettagli su 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/v1
kind: HorizontalPodAutoscaler
metadata:
annotations:
autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ScaleDownStabilized","message":"recent
recommendations were higher than current one, applying the highest recent recommendation"},{"type":"ScalingActive","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ValidMetricFound","message":"the
HPA was able to successfully calculate a replica count from cpu resource utilization
(percentage of request)"},{"type":"ScalingLimited","status":"False","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"DesiredWithinRange","message":"the
desired count is within the acceptable range"}]'
autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":"Resource","resource":{"name":"cpu","currentAverageUtilization":0,"currentAverageValue":"0"}}]'
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"},"targetCPUUtilizationPercentage":50}}
creationTimestamp: "2019-10-30T19:42:43Z"
name: nginx
namespace: default
resourceVersion: "220050"
selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/nginx
uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
targetCPUUtilizationPercentage: 50
status:
currentCPUUtilizationPercentage: 0
currentReplicas: 3
desiredReplicas: 3
Prima di seguire gli altri esempi in questa pagina, elimina l'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 di HPA.
Scopri di più sull'eliminazione di un HPA.
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 dai 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 la 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 globale del traffico. Per saperne di più, consulta Scalabilità automatica basata sul traffico.
La scalabilità automatica in base al 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 nella scalabilità automatica basata sul traffico. Un oggetto HPA deve essere dedicato allo scaling 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, attendi un tempo sufficiente (di solito 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 contribuisce a garantire che il tuo servizio non si trovi temporaneamente in una situazione in cui il tuo cluster tenta di scalare automaticamente 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
Il seguente esercizio utilizza HPA per scalare automaticamente il deployment
store-autoscale in base al traffico che riceve. Un
gateway accetta il traffico
di ingresso 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 di servizio store-autoscale. Generando
traffico verso il gateway, influenzi il 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 GatewayClasses siano installate nel cluster. Per i cluster Autopilot, le GatewayClass sono 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, abilita l'API Gateway nel tuo cluster GKE.
Esegui il deployment dell'applicazione di esempio e del bilanciatore del carico Gateway nel 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 l'impostazione
GCPBackendPolicyassociatamaxRatePerEndpointimpostata su10. Per saperne di più sulle funzionalità di Gateway, consulta Funzionalità di GatewayClass. - Un gateway esterno per accedere all'applicazione su internet. Per scoprire 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 da 1 a 10 repliche.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 di utilizzo della capacità del 70%. In questo modo, l'HPA ha un margine di crescita che consente ai pod in esecuzione di elaborare il traffico in eccesso mentre vengono creati nuovi pod.
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. Il risultato è di 7 RPS per pod quando
maxRatePerEndpoint=10. - Con più di 7 RPS per pod, i pod vengono scalati verticalmente fino a raggiungere il massimo di 10 repliche o fino a quando il traffico medio non è 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 implementare un generatore di traffico per convalidare il comportamento di scalabilità automatica basato 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 fluttuare. Per una descrizione più dettagliata di come viene calcolato il numero di repliche, consulta Comportamento della scalabilità automatica.
Scalabilità automatica in base a una metrica personalizzata o esterna
Per creare gestori della scalabilità automatica orizzontale dei pod per metriche personalizzate e metriche esterne, consulta Ottimizza la scalabilità automatica dei pod in base alle metriche.
In alternativa, puoi esporre metriche personalizzate (anteprima) e inviare le metriche da un pod o un workload direttamente al gestore 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
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. HPA esegue la scalabilità automatica del deployment in base alla metrica il cui valore creerebbe l'evento di scalabilità automatica più grande.
Configura il profilo HPA per le prestazioni
Il profilo HPA per il rendimento migliora il tempo di reazione della scalabilità automatica orizzontale dei pod, contribuendo a migliorare la capacità di 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 versione 1.32 o successive. Per i cluster standard, il profilo viene attivato 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 esegue l'upgrade da una versione precedente alla versione 1.33 o successive.
- 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 abilitare 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: la zona o la regione di computing (ad es. us-central1-a o us-central1) per il cluster.PROJECT_ID: l'ID progetto Google Cloud .
Disattivare 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: la zona o la 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.
Se HPA utilizza apiVersion: autoscaling/v2 e si basa su più metriche, il comando kubectl describe hpa mostra solo la metrica della CPU. Per visualizzare
tutte le metriche, utilizza invece il seguente comando:
kubectl describe hpa.v2.autoscaling HPA_NAME
Sostituisci HPA_NAME con il nome dell'oggetto HPA.
Lo stato attuale di ogni oggetto HPA viene visualizzato 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 nginx HPA:
Vai alla pagina Workload nella console Google Cloud .
Fai clic sul nome del deployment di
nginx.Fai clic su list Azioni > Scalabilità automatica.
Fai clic su Elimina.
kubectl delete
Per eliminare l'oggetto HPA nginx, utilizza questo 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 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 nginx(Facoltativo) Elimina il cluster.
Risoluzione dei problemi
Per suggerimenti sulla risoluzione dei problemi, vedi Risolvere i problemi di scalabilità automatica orizzontale dei pod.
Passaggi successivi
- Scopri di più sulla scalabilità automatica orizzontale dei pod.
- Scopri di più sulla scalabilità automatica verticale dei pod.
- Scopri come ottimizzare la scalabilità automatica dei pod in base alle metriche.
- Scopri di più sulla scalabilità automatica dei deployment con metriche personalizzate.
- Scopri come assegnare risorse CPU a container e pod.
- Scopri come assegnare risorse di memoria a container e pod.