Configurar el autoescalado de pods horizontal

En esta página se explica cómo escalar tus implementaciones en Google Kubernetes Engine (GKE) ajustando automáticamente tus recursos mediante métricas como la asignación de recursos, el tráfico del balanceador de carga, las métricas personalizadas o varias métricas simultáneamente. En esta página también se proporcionan instrucciones detalladas para configurar un perfil de autoescalador de pods horizontal (HPA), así como para ver, eliminar, limpiar y solucionar problemas relacionados con el objeto HPA. Un Deployment es un objeto de la API de Kubernetes que te permite ejecutar varias réplicas de pods distribuidas entre los nodos de un clúster.

Esta página está dirigida a operadores y desarrolladores que gestionan el escalado de aplicaciones en GKE y quieren saber cómo optimizar el rendimiento de forma dinámica y mantener la eficiencia de los costes mediante el escalado automático horizontal de pods. Para obtener más información sobre los roles habituales y las tareas de ejemplo que se mencionan en el contenido, consulta Roles y tareas de usuario habituales de GKE. Google Cloud

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la CLI de gcloud, obtén la versión más reciente ejecutando el comando gcloud components update. Es posible que las versiones anteriores de la interfaz de línea de comandos de gcloud no admitan la ejecución de los comandos de este documento.

Versiones de la API para objetos HorizontalPodAutoscaler

Cuando usas la consola, los objetos HorizontalPodAutoscaler se crean con la API autoscaling/v2. Google Cloud

Cuando usas kubectl para crear o ver información sobre un escalado automático horizontal de pods, puedes especificar la API autoscaling/v1 o la API autoscaling/v2.

  • apiVersion: autoscaling/v1 es el valor predeterminado y te permite autoescalar en función del uso de la CPU. Para autoescalar en función de otras métricas, se recomienda usar apiVersion: autoscaling/v2. En el ejemplo de Crear el ejemplo de Deployment se usa apiVersion: autoscaling/v1.

  • apiVersion: autoscaling/v2 se recomienda para crear objetos HorizontalPodAutoscaler nuevos. Te permite autoescalar en función de varias métricas, incluidas las métricas personalizadas o externas. En el resto de los ejemplos de esta página se usa apiVersion: autoscaling/v2.

Para comprobar qué versiones de la API son compatibles, usa el comando kubectl api-versions.

Puedes especificar qué API quieres usar cuando consultes los detalles de un autoescalador horizontal de pods que use apiVersion: autoscaling/v2.

Crear el Deployment de ejemplo

Antes de crear un autoescalador horizontal de pods, debes crear la carga de trabajo que monitoriza. En los ejemplos de esta página se aplican diferentes configuraciones de Horizontal Pod Autoscaler a la siguiente implementación de nginx. En ejemplos independientes se muestra un autoescalador horizontal de pods basado en el uso de recursos, en una métrica personalizada o externa y en varias métricas.

Guarda lo siguiente en un archivo llamado 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"

Este manifiesto especifica un valor para las solicitudes de CPU. Si quieres autoescalar en función del uso de un recurso como porcentaje, debes especificar solicitudes para ese recurso. Si no especificas ninguna solicitud, puedes autoescalar en función únicamente del valor absoluto del uso de los recursos, como los miliCPUs del uso de la CPU.

Para crear el Deployment, aplica el manifiesto nginx.yaml:

kubectl apply -f nginx.yaml

El Deployment tiene el valor spec.replicas definido en 3, por lo que se desplegarán tres pods. Puedes verificarlo con el comando kubectl get deployment nginx.

En cada uno de los ejemplos de esta página se aplica una herramienta de escalado automático horizontal de pods diferente a un ejemplo de implementación de nginx.

Autoescalado basado en el uso de recursos

En este ejemplo se crea un objeto HorizontalPodAutoscaler para autoescalar el nginxdespliegue cuando la utilización de la CPU supere el 50 % y se asegura de que siempre haya un mínimo de 1 réplica y un máximo de 10 réplicas.

Puedes crear un autoescalador horizontal de pods que se centre en la CPU mediante la Google Cloud consola, el comando kubectl apply o, solo para la CPU media, el comando kubectl autoscale.

Consola

  1. Ve a la página Cargas de trabajo de la Google Cloud consola.

    Ir a Cargas de trabajo

  2. Haz clic en el nombre de la nginximplementación.

  3. Haga clic en Acciones > Escalado automático.

  4. Especifique los siguientes valores:

    • Número mínimo de réplicas: 1
    • Número máximo de réplicas: 10
    • Métrica de autoescalado: CPU
    • Objetivo: 50
    • Unidad: %

  5. Haz clic en Listo.

  6. Haz clic en Autoescalar.

kubectl apply

Guarda el siguiente manifiesto YAML en un archivo llamado 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

Para crear el HPA, aplica el manifiesto con el siguiente comando:

kubectl apply -f nginx-hpa.yaml

kubectl autoscale

Para crear un objeto HorizontalPodAutoscaler que solo se centre en el uso medio de la CPU, puedes usar el comando kubectl autoscale:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Para obtener una lista de las herramientas de adaptación dinámica horizontal de pods del clúster, usa el siguiente comando:

kubectl get hpa

El resultado debería ser similar al siguiente:

NAME    REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
nginx   Deployment/nginx   0%/50%    1         10        3          61s

Para obtener información sobre la herramienta de adaptación dinámica de pods horizontal, puedes usar la consola Google Cloud o el comando kubectl.

Consola

  1. Ve a la página Cargas de trabajo de la Google Cloud consola.

    Ir a Cargas de trabajo

  2. Haz clic en el nombre de la nginximplementación.

  3. Consulta la configuración de la herramienta de adaptación dinámica horizontal de pods en la sección Adaptación dinámica.

  4. Para ver más detalles sobre los eventos de escalado automático, vaya a la pestaña Eventos.

kubectl get

Para obtener información sobre la herramienta de adaptación dinámica horizontal de pods, puedes usar kubectl get hpa con la marca -o yaml. El campo status contiene información sobre el número actual de réplicas y los eventos de escalado automático recientes.

kubectl get hpa nginx -o yaml

El resultado debería ser similar al siguiente:

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

Antes de seguir con los ejemplos que quedan en esta página, elimina el HPA:

kubectl delete hpa nginx

Cuando eliminas un Horizontal Pod Autoscaler, el número de réplicas del Deployment sigue siendo el mismo. Un Deployment no vuelve automáticamente al estado que tenía antes de que se aplicara el autoescalado de pods horizontal.

Puedes consultar más información sobre cómo eliminar un autoescalador de pods horizontal.

Autoescalado basado en el tráfico del balanceador de carga

El autoescalado basado en el tráfico es una función de GKE que integra señales de uso del tráfico de los balanceadores de carga para autoescalar los pods.

Usar el tráfico como señal de autoescalado puede ser útil, ya que el tráfico es un indicador adelantado de la carga que complementa la CPU y la memoria. La integración con GKE asegura que la configuración sea sencilla y que el ajuste de escala automático reaccione rápidamente a los picos de tráfico para satisfacer la demanda.

El ajuste de escala automático basado en el tráfico se habilita mediante el controlador de Gateway y sus funciones de gestión del tráfico global. Para obtener más información, consulta Autoescalado basado en el tráfico.

El autoescalado basado en el tráfico del balanceador de carga solo está disponible para las cargas de trabajo de Gateway.

Requisitos

El autoescalado basado en el tráfico tiene los siguientes requisitos:

  • Compatible con GKE 1.31 y versiones posteriores.
  • API Gateway habilitada en tu clúster de GKE.
  • Se admite el tráfico que pasa por balanceadores de carga implementados con la API Gateway y con gke-l7-global-external-managed, gke-l7-regional-external-managed, gke-l7-rilb o gke-l7-gxlb GatewayClass.

Limitaciones

El escalado automático basado en el tráfico tiene las siguientes limitaciones:

  • No es compatible con las GatewayClasses de varios clústeres (gke-l7-global-external-managed-mc, gke-l7-regional-external-managed-mc, gke-l7-rilb-mc y gke-l7-gxlb-mc).
  • No se admite el tráfico que usa servicios de tipo LoadBalancer.
  • Debe haber una relación clara y aislada entre los componentes implicados en el escalado automático basado en el tráfico. Una herramienta de adaptación dinámica horizontal de pods debe dedicarse a escalar una sola implementación (o cualquier recurso escalable) expuesta por un solo servicio.
  • Después de configurar la capacidad de tu servicio mediante el campo maxRatePerEndpoint , espera el tiempo suficiente (normalmente un minuto, pero puede ser hasta 15 minutos en clústeres grandes) para que el balanceador de carga se actualice con este cambio antes de configurar el autoescalador horizontal de pods con métricas basadas en el tráfico. De esta forma, tu servicio no experimentará temporalmente una situación en la que tu clúster intente autoescalarse en función de las métricas emitidas por un balanceador de carga que aún esté en proceso de configuración.
  • Si se usa el autoescalado basado en el tráfico en un servicio proporcionado por varios balanceadores de carga (por ejemplo, por un Ingress y una Gateway, o por dos Gateways), el autoescalador horizontal de pods puede tener en cuenta el valor de tráfico más alto de los balanceadores de carga individuales para tomar decisiones de escalado, en lugar de la suma de los valores de tráfico de todos los balanceadores de carga.

Desplegar el autoescalado basado en el tráfico

En el siguiente ejercicio se usa HorizontalPodAutoscaler para escalar automáticamente la store-autoscale Deployment en función del tráfico que recibe. Un gateway acepta el tráfico de entrada de Internet para los pods. El autoescalador compara las señales de tráfico de la puerta de enlace con la capacidad de tráfico por pod configurada en el recurso store-autoscale Service. Al generar tráfico a la pasarela, influyes en el número de pods implementados.

En el siguiente diagrama se muestra cómo funciona el escalado automático basado en el tráfico:

HorizontalPodAutoscaler escala un Deployment en función del tráfico.

Para implementar el ajuste de escala automático basado en el tráfico, siga estos pasos:

  1. En los clústeres estándar, confirma que las GatewayClasses están instaladas en tu clúster. En los clústeres de Autopilot, las GatewayClasses se instalan de forma predeterminada.

    kubectl get gatewayclass

    El resultado confirma que los recursos de GKE GatewayClass están listos para usarse en tu clúster:

    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

    Si no ves este resultado, habilita la API Gateway en tu clúster de GKE.

  2. Despliega la aplicación de muestra y el balanceador de carga de Gateway en tu clúster:

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

    La aplicación de ejemplo crea lo siguiente:

    • Un Deployment con 2 réplicas.
    • Un servicio con un ajuste GCPBackendPolicy asociado maxRatePerEndpoint definido como 10. Para obtener más información sobre las funciones de Gateway, consulta Funciones de GatewayClass.
    • Una pasarela externa para acceder a la aplicación en Internet. Para obtener más información sobre cómo usar los balanceadores de carga de Gateway, consulta Implementar Gateways.
    • Un HTTPRoute que coincide con todo el tráfico y lo envía al servicio store-autoscale.

    La capacidad de servicio es un elemento fundamental cuando se usa el autoescalado basado en el tráfico, ya que determina la cantidad de tráfico por pod que activa un evento de autoescalado. Se configura mediante un campo maxRatePerEndpoint en un GCPBackendPolicy asociado al servicio, que define el tráfico máximo que debe recibir un servicio en solicitudes por segundo y por pod. La capacidad del servicio es específica de tu aplicación.

    Para obtener más información, consulta Determinar la capacidad de tu Servicio.

  3. Guarda el siguiente archivo de manifiesto como 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

    Este manifiesto describe un HorizontalPodAutoscaler con las siguientes propiedades:

    • minReplicas y maxReplicas: definen el número mínimo y máximo de réplicas de esta implementación. En esta configuración, el número de pods puede escalar de 1 a 10 réplicas.
    • describedObject.name: store-autoscale: la referencia al servicio store-autoscale que define la capacidad de tráfico.
    • scaleTargetRef.name: store-autoscale: la referencia a la store-autoscale implementación que define el recurso que escala la herramienta de adaptación dinámica horizontal de pods.
    • averageValue: 70: valor medio objetivo del 70% de la utilización de la capacidad. De esta forma, la herramienta de adaptación dinámica horizontal de pods tiene un margen de crecimiento para que los pods en ejecución puedan procesar el exceso de tráfico mientras se crean nuevos pods.

La herramienta de adaptación dinámica horizontal de pods da como resultado el siguiente comportamiento del tráfico:

  • El número de pods se ajusta entre 1 y 10 réplicas para alcanzar el 70% de la tasa máxima por endpoint. Esto da como resultado 7 RPS por pod cuando maxRatePerEndpoint=10.
  • Si se superan las 7 RPS por pod, los pods se escalan verticalmente hasta alcanzar un máximo de 10 réplicas o hasta que el tráfico medio sea de 7 RPS por pod.
  • Si se reduce el tráfico, los pods se reducen a una tasa razonable mediante el algoritmo de autoescalado horizontal de pods.

También puede desplegar un generador de tráfico para validar el comportamiento del autoescalado basado en el tráfico.

Con 30 RPS, el despliegue se escala a 5 réplicas para que cada réplica reciba idealmente 6 RPS de tráfico, lo que supondría una utilización del 60% por pod. Esto está por debajo del 70% de uso objetivo, por lo que los pods se escalan de forma adecuada. En función de las fluctuaciones del tráfico, el número de réplicas con escalado automático también puede fluctuar. Para obtener una descripción más detallada de cómo se calcula el número de réplicas, consulta Comportamiento del ajuste automático de escala.

Autoescalado basado en una métrica personalizada o externa

Para crear autoescaladores de pods horizontales para métricas personalizadas y métricas externas, consulta Optimizar el autoescalado de pods en función de las métricas.

Autoescalado basado en varias métricas

En este ejemplo se crea un autoescalador horizontal de pods que se autoescala en función del uso de la CPU y de una métrica personalizada llamada packets_per_second.

Si has seguido el ejemplo anterior y aún tienes una herramienta de escalado automático de pods horizontal llamada nginx, elimínala antes de seguir este ejemplo.

Este ejemplo requiere apiVersion: autoscaling/v2. Para obtener más información sobre las APIs disponibles, consulte Versiones de la API para objetos HorizontalPodAutoscaler.

Guarda este manifiesto YAML en un archivo llamado 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

Aplica el manifiesto YAML:

kubectl apply -f nginx-multiple.yaml

Cuando se crea, el autoescalador de pods horizontal monitoriza el nginxdespliegue para comprobar el uso medio de la CPU, el uso medio de la memoria y (si lo has descomentado) la métrica personalizadapackets_per_second. La herramienta de adaptación dinámica horizontal de pods adapta automáticamente la escala de la implementación en función de la métrica cuyo valor crearía el evento de adaptación automática de la escala más grande.

Configurar el perfil de HPA de rendimiento

El perfil de HPA de rendimiento mejora el tiempo de reacción del autoescalador de pods horizontal, lo que le permite recalcular rápidamente un gran número de objetos HorizontalPodAutoscaler (hasta 1000 objetos en las versiones secundarias 1.31 y 1.32, y 5000 objetos en la versión 1.33 o posterior).

Este perfil se habilita automáticamente en los clústeres de Autopilot que cumplen los requisitos y que tienen un plano de control que ejecuta la versión 1.32 de GKE o una posterior. En los clústeres estándar, el perfil se habilita automáticamente en los clústeres que cumplen los requisitos y cuyo plano de control ejecuta la versión 1.33 de GKE o una posterior.

Un clúster Standard está exento de la habilitación automática del perfil de HPA de rendimiento si cumple todas las condiciones siguientes:

  • El clúster se está actualizando de una versión anterior a la 1.33 o a una posterior.
  • El clúster tiene al menos un grupo de nodos con alguno de los siguientes tipos de máquina: e2-micro, e2-custom-micro, g1-small o f1-micro.
  • El aprovisionamiento automático de nodos no está habilitado.

También puedes habilitar el perfil de HPA de rendimiento en clústeres disponibles si cumplen los requisitos.

Requisitos

Para habilitar el perfil de HPA de rendimiento, compruebe que sus clústeres de Autopilot y Standard cumplen los siguientes requisitos:

Habilitar el perfil de HPA de rendimiento

Para habilitar el perfil de HPA de rendimiento en tu clúster, usa el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --hpa-profile=performance

Sustituye:

  • CLUSTER_NAME: el nombre del clúster.
  • LOCATION: zona o región de Compute (por ejemplo, us-central1-a o us-central1) del clúster.
  • PROJECT_ID: tu ID de proyecto Google Cloud .

Inhabilitar el perfil de HPA de rendimiento

Para inhabilitar el perfil de HPA de rendimiento en un clúster, usa el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --hpa-profile=none

Sustituye:

  • CLUSTER_NAME: el nombre del clúster.
  • LOCATION: zona o región de Compute (por ejemplo, us-central1-a o us-central1) del clúster.
  • PROJECT_ID: tu ID de proyecto Google Cloud .

Ver los detalles de un autoescalador horizontal de pods

Para ver la configuración y las estadísticas de un autoescalador de pods horizontal, usa el siguiente comando:

kubectl describe hpa HPA_NAME

Sustituye HPA_NAME por el nombre de tu objeto HorizontalPodAutoscaler.

Si el autoescalador horizontal de pods usa apiVersion: autoscaling/v2 y se basa en varias métricas, el comando kubectl describe hpa solo muestra la métrica de CPU. Para ver todas las métricas, usa el siguiente comando:

kubectl describe hpa.v2.autoscaling HPA_NAME

Sustituye HPA_NAME por el nombre de tu objeto HorizontalPodAutoscaler.

El estado actual de cada Horizontal Pod Autoscaler se muestra en el campo Conditions y los eventos de autoescalado se indican en el campo Events.

El resultado debería ser similar al siguiente:

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>

Eliminar un autoescalador de pods horizontal

Puedes eliminar un Horizontal Pod Autoscaler mediante la consola Google Cloud o el comando kubectl delete.

Consola

Para eliminar el nginx Horizontal Pod Autoscaler, haz lo siguiente:

  1. Ve a la página Cargas de trabajo de la Google Cloud consola.

    Ir a Cargas de trabajo

  2. Haz clic en el nombre de la nginximplementación.

  3. Haga clic en Acciones > Escalado automático.

  4. Haz clic en Eliminar.

kubectl delete

Para eliminar el nginx Horizontal Pod Autoscaler, usa el siguiente comando:

kubectl delete hpa nginx

Cuando eliminas un autoescalador horizontal de pods, el Deployment (u otro objeto de implementación) mantiene su escala y no vuelve al número de réplicas del manifiesto original del Deployment. Para volver a escalar manualmente la implementación a tres pods, puedes usar el comando kubectl scale:

kubectl scale deployment nginx --replicas=3

Eliminar los recursos utilizados

  1. Elimina la herramienta de adaptación dinámica horizontal de pods, si aún no lo has hecho:

    kubectl delete hpa nginx

  2. Elimina el despliegue nginx:

    kubectl delete deployment nginx

  3. Opcionalmente, elimina el clúster.

Solución de problemas

Para obtener consejos sobre cómo solucionar problemas, consulta Solucionar problemas del autoescalado horizontal de pods.

Siguientes pasos