Configurazione della scalabilità automatica del pod orizzontale

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 Horizontal Pod Autoscaler (HPA), incluso come visualizzare, eliminare, pulire e risolvere i problemi relativi all'oggetto HPA. Un deployment è un oggetto API Kubernetes che ti 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 viene fatto 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 Google 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.

Versioni API per gli oggetti HorizontalPodAutoscaler

Quando utilizzi la console Google Cloud , gli oggetti HorizontalPodAutoscaler vengono creati utilizzando l'API autoscaling/v2.

Quando utilizzi kubectl per creare o visualizzare informazioni su un Horizontal Pod Autoscaler, 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 utilizzare apiVersion: autoscaling/v2. L'esempio in Crea il deployment di esempio utilizza apiVersion: autoscaling/v1.

  • apiVersion: autoscaling/v2 è consigliato per creare nuovi oggetti HorizontalPodAutoscaler. Consente di scalare automaticamente in base a più metriche, incluse metriche personalizzate o esterne. Tutti gli altri esempi in questa pagina utilizzano apiVersion: 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 Horizontal Pod Autoscaler che utilizza apiVersion: autoscaling/v2.

Crea il deployment di esempio

Prima di poter creare un Horizontal Pod Autoscaler, devi creare il workload che monitora. Gli esempi in questa pagina applicano diverse configurazioni di Horizontal Pod Autoscaler al seguente deployment nginx. Esempi separati mostrano un Horizontal Pod Autoscaler 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 implementati tre pod. Puoi verificarlo utilizzando il comando kubectl get deployment nginx.

Ciascuno degli esempi in questa pagina applica un diverso Horizontal Pod Autoscaler a un esempio di deployment nginx.

Scalabilità automatica in base all'utilizzo delle risorse

Questo esempio crea l'oggetto HorizontalPodAutoscaler per scalare automaticamente il deployment nginx quando l'utilizzo della CPU supera il 50% e garantisce che ci sia sempre un minimo di 1 replica e un massimo di 10 repliche.

Puoi creare un Horizontal Pod Autoscaler 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

  1. Vai alla pagina Workload nella console Google Cloud .

    Vai a Carichi di lavoro

  2. Fai clic sul nome del deployment di nginx.

  3. Fai clic su Azioni > Scalabilità automatica.

  4. Specifica i seguenti valori:

    • Numero minimo di repliche:1
    • Numero massimo di repliche: 10
    • Metrica di scalabilità automatica: CPU
    • Target:50
    • Unità: %

  5. Fai clic su Fine.

  6. Fai clic su Scalabilità automatica.

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 l'HPA, applica il manifest utilizzando questo comando:

kubectl apply -f nginx-hpa.yaml

kubectl autoscale

Per creare un oggetto HorizontalPodAutoscaler 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 ottenere un elenco di Horizontal Pod Autoscaler 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 del Horizontal Pod Autoscaler, puoi utilizzare la console Google Cloud o il comando kubectl.

Console

  1. Vai alla pagina Workload nella console Google Cloud .

    Vai a Carichi di lavoro

  2. Fai clic sul nome del deployment di nginx.

  3. Visualizza la configurazione di Horizontal Pod Autoscaler nella sezione Gestore della scalabilità automatica.

  4. Visualizza ulteriori dettagli sugli eventi di scalabilità automatica nella scheda Eventi.

kubectl get

Per ottenere dettagli sul Horizontal Pod Autoscaler, 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 Horizontal Pod Autoscaler, il numero di repliche del deployment rimane invariato. Un deployment non viene automaticamente ripristinato allo stato precedente all'applicazione di Horizontal Pod Autoscaler.

Puoi scoprire di più su come eliminare un Horizontal Pod Autoscaler.

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 il traffico è un indicatore principale del carico complementare a CPU e memoria. L'integrazione integrata con GKE garantisce una configurazione semplice e la scalabilità automatica reagisce 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 cluster GKE.
  • 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-rilb o gke-l7-gxlb GatewayClass.

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-mc e gke-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 Horizontal Pod Autoscaler deve essere dedicato al ridimensionamento 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 il Horizontal Pod Autoscaler con metriche basate sul traffico. In questo modo, il servizio non subirà temporaneamente una situazione in cui il 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 Ingress che da un gateway o da due gateway), Horizontal Pod Autoscaler 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 HorizontalPodAutoscaler 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 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:

Scalabilità di un deployment di HorizontalPodAutoscaler in base al traffico.

Per eseguire il deployment della scalabilità automatica basata sul traffico, segui questi passaggi:

  1. Per i cluster Standard, verifica che le GatewayClasses siano installate nel cluster. Per i cluster Autopilot, le GatewayClass sono installate per impostazione predefinita.

    kubectl get gatewayclass

    L'output conferma che le risorse GKE GatewayClass sono pronte per l'uso nel tuo 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       16h

    Se non vedi questo output, abilita l'API Gateway nel tuo cluster GKE.

  2. Esegui il deployment dell'applicazione di esempio e del bilanciatore del carico del gateway nel cluster:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yaml

    L'applicazione di esempio crea:

    • Un deployment con 2 repliche.
    • Un servizio con l'impostazione GCPBackendPolicy associata maxRatePerEndpoint impostata su 10. Per scoprire 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 maxRatePerEndpoint in 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 ulteriori informazioni, consulta la sezione Determinare la capacità del servizio.

  3. 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: AverageValue

    Questo manifest descrive un HorizontalPodAutoscaler con le seguenti proprietà:

    • minReplicas e maxReplicas: 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 servizio store-autoscale che definisce la capacità di traffico.
    • scaleTargetRef.name: store-autoscale: il riferimento al deployment store-autoscale che definisce la risorsa scalata dal Horizontal Pod Autoscaler.
    • averageValue: 70: valore medio target del 70% di utilizzo della capacità. In questo modo, la Horizontal Pod Autoscaler ha un margine di crescita che consente ai pod in esecuzione di elaborare il traffico in eccesso durante la creazione di nuovi pod.

Horizontal Pod Autoscaler 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 orizzontalmente fino a raggiungere il massimo di 10 repliche o finché 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 di Horizontal Pod Autoscaler.

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%, quindi 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.

Scalabilità automatica in base a più metriche

Questo esempio crea un Horizontal Pod Autoscaler 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 Horizontal Pod Autoscaler denominato nginx, eliminalo prima di seguire questo esempio.

Questo esempio richiede apiVersion: autoscaling/v2. Per maggiori informazioni sulle API disponibili, consulta Versioni API per gli oggetti HorizontalPodAutoscaler.

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, Horizontal Pod Autoscaler 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. Horizontal Pod Autoscaler 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 il rendimento

Il profilo HPA per le prestazioni migliora il tempo di reazione di Horizontal Pod Autoscaler, consentendogli di ricalcolare rapidamente un numero elevato di oggetti HorizontalPodAutoscaler (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:

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: zona o regione di computing (ad es. us-central1-a o us-central1) per il cluster.
  • PROJECT_ID: il tuo 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: il tuo ID progetto Google Cloud .

Visualizzazione dei dettagli di un Horizontal Pod Autoscaler

Per visualizzare la configurazione e le statistiche di un Horizontal Pod Autoscaler, utilizza il seguente comando:

kubectl describe hpa HPA_NAME

Sostituisci HPA_NAME con il nome dell'oggetto HorizontalPodAutoscaler.

Se Horizontal Pod Autoscaler utilizza apiVersion: autoscaling/v2 e si basa su più metriche, il comando kubectl describe hpa mostra solo la metrica 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 HorizontalPodAutoscaler.

Lo stato attuale di ogni Horizontal Pod Autoscaler è 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 Horizontal Pod Autoscaler

Puoi eliminare un Horizontal Pod Autoscaler utilizzando la console Google Cloud o il comando kubectl delete.

Console

Per eliminare il Horizontal Pod Autoscaler nginx:

  1. Vai alla pagina Workload nella console Google Cloud .

    Vai a Carichi di lavoro

  2. Fai clic sul nome del deployment di nginx.

  3. Fai clic su Azioni > Scalabilità automatica.

  4. Fai clic su Elimina.

kubectl delete

Per eliminare nginx Horizontal Pod Autoscaler, utilizza questo comando:

kubectl delete hpa nginx

Quando elimini un Horizontal Pod Autoscaler, il deployment (o un altro oggetto di deployment) rimane alla sua scalabilità esistente e non torna al 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

  1. Elimina Horizontal Pod Autoscaler, se non l'hai ancora fatto:

    kubectl delete hpa nginx

  2. Elimina il deployment nginx:

    kubectl delete deployment nginx

  3. (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