En esta página, se muestra cómo escalar tus implementaciones en Google Kubernetes Engine (GKE) ajustando automáticamente tus recursos con métricas como la asignación de recursos, el tráfico del balanceador de cargas, las métricas personalizadas o varias métricas de forma simultánea. En esta página, también se proporcionan instrucciones paso a paso para configurar un perfil de HorizontalPodAutoscaler (HPA), lo que incluye cómo ver, borrar, limpiar y solucionar problemas de tu objeto HPA. Un Deployment es un objeto de la API de Kubernetes que te permite ejecutar varias réplicas de Pods que se distribuyen entre los nodos de un clúster.
Esta página está dirigida a los desarrolladores y operadores que administran el ajuste de escala de aplicaciones en GKE y desean comprender cómo optimizar el rendimiento de forma dinámica y mantener la eficiencia en los costos a través del ajuste de escala automático horizontal de Pods. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que se hace referencia en el contenido de Google Cloud, consulta Roles y tareas comunes del usuario de GKE.
Antes de comenzar
Antes de comenzar, asegúrate de haber realizado las siguientes tareas:
- Habilita la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste la gcloud CLI, ejecuta el comando
gcloud components updatepara obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se indican en este documento.
- Asegúrate de tener un clúster de Autopilot o Standard existente. Si necesitas uno, crea un clúster de Autopilot.
Versiones de API para objetos HorizontalPodAutoscaler
Cuando usas la consola de Google Cloud , los objetos HPA se crean con la API deautoscaling/v2. La API de autoscaling/v1 aún se admite, pero ya no se recomienda y no admite ciertas funciones, como el ajuste de escala a cero y desde cero con el HPA.
Crea la implementación de ejemplo
Antes de crear un objeto de HPA, debes crear la carga de trabajo que supervisa. En los ejemplos de este tema, se aplican diferentes configuraciones de HPA a la siguiente Deployment nginx. Ejemplos separados muestran un HPA 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 deseas ajustar la escala automática según el uso de un recurso como un porcentaje, debes especificar solicitudes para ese recurso. Si no especificas solicitudes, solo puedes escalar automáticamente según el valor absoluto del uso del recurso, como milicorazones para el uso de CPU.
Para crear el Deployment, aplica el manifiesto nginx.yaml:
kubectl apply -f nginx.yaml
El Deployment tiene spec.replicas establecido en 3, por lo que se implementan tres Pods.
Puedes verificar esto con el comando kubectl get deployment nginx.
En cada uno de los ejemplos de esta página, se aplica un objeto de HPA diferente a un ejemplo de Deployment de nginx.
Ajuste de escala automático según el uso de recursos
En este ejemplo, se crea un objeto HPA para ajustar automáticamente la escala de la implementación nginx cuando el uso de CPU supera el 50% y ayuda a garantizar que siempre haya un mínimo de 1 réplica y un máximo de 10 réplicas.
Puedes crear un HPA orientado a la CPU con la consola de Google Cloud , el comando kubectl apply o el comando kubectl autoscale solo para la CPU promedio.
Console
Accede a la página Cargas de trabajo de la consola de Google Cloud .
Haz clic en el nombre de la Deployment
nginx.Haz clic en list Acciones > Editar ajuste de escala automático.
En la sección Escalado automático horizontal de Pods, haz clic en Seleccionar y configurar.
Especifica los siguientes valores:
- Cantidad mínima de réplicas: 1
- Cantidad máxima de réplicas: 10
- Métrica de ajuste de escala automático: CPU
- Objetivo: 50
- Unidad: CPU
Haz clic en Enviar.
kubectl apply
Guarda el siguiente manifiesto YAML como un archivo llamado 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
Si creas un manifiesto para que coincida con detalles específicos de tu propio proyecto, asegúrate de no incluir datos sensibles en los campos del escalador automático horizontal de Pods.
Para crear el HPA, aplica el manifiesto con el siguiente comando:
kubectl apply -f nginx-hpa.yaml
kubectl autoscale
Para crear un objeto HPA que solo apunte al uso promedio de CPU, puedes usar el comando kubectl autoscale.
kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10
Para obtener una lista de los HPA en el clúster, usa el siguiente comando:
kubectl get hpa
El resultado es similar a lo siguiente:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/50% 1 10 3 61s
Para obtener detalles sobre el HPA, puedes usar la Google Cloud consola o el comandokubectl.
Console
Accede a la página Cargas de trabajo de la consola de Google Cloud .
Haz clic en el nombre de la Deployment
nginx.Haz clic en la pestaña Ajuste.
kubectl get
Para obtener detalles sobre el HPA, puedes usar kubectl get hpa con la marca -o yaml. El campo status contiene información sobre la cantidad actual de réplicas y los eventos de ajuste de escala automático recientes.
kubectl get hpa nginx -o yaml
El resultado es similar a lo siguiente:
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
Si creas un manifiesto para que coincida con detalles específicos de tu propio proyecto, asegúrate de no incluir datos sensibles en los campos del escalador automático horizontal de Pods.
Antes de seguir los ejemplos restantes en esta página, borra el HPA:
kubectl delete hpa nginx
Cuando borras un objeto HPA, la cantidad de réplicas de la Deployment sigue igual. Una Deployment no vuelve automáticamente a su estado anterior a la aplicación del HPA.
Puedes obtener más información sobre cómo borrar un HPA.
Ajuste de escala automático en función de una métrica personalizada o externa
Cualquier métrica que emita tu carga de trabajo o que puedas consultar desde una fuente externa se puede usar para el ajuste de escala automático. GKE tiene compatibilidad integrada con el ajuste de escala automático basado en métricas personalizadas y externas en muchas situaciones, y Kubernetes admite adaptadores de métricas adicionales, como KEDA y el adaptador de Prometheus.
Ajuste de escala automático basado en el tráfico del balanceador de cargas
El ajuste de escala automático basado en el tráfico es una función de GKE que integra señales de uso de tráfico de los balanceadores de cargas para ajustar automáticamente la escala de los Pods.
El uso del tráfico como una señal para el ajuste de escala automático puede ser útil porque es un indicador principal de carga que se complementa con la CPU y la memoria. La integración incorporada en GKE ayuda a garantizar que la configuración sea sencilla y que el ajuste de escala automático reaccione rápidamente a los aumentos repentinos de tráfico para satisfacer la demanda.
El controlador de Gateway y sus funciones de administración del tráfico global habilitan el ajuste de escala automático basado en el tráfico. Para obtener más información, consulta Ajuste de escala automático basado en el tráfico.
El ajuste de escala automático basado en el tráfico del balanceador de cargas solo está disponible para las cargas de trabajo de Gateway.
Requisitos
El ajuste de escala automático basado en el tráfico tiene los siguientes requisitos:
- Es compatible con las versiones 1.31 y posteriores de GKE.
- La API de Gateway debe estar habilitada en tu proyecto.
- Compatible con el tráfico que pasa por los balanceadores de cargas implementados mediante la API de Gateway y la GatewayClass
gke-l7-global-external-managed,gke-l7-regional-external-managed,gke-l7-rilbogke-l7-gxlb.
Limitaciones
El ajuste de escala 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-mcygke-l7-gxlb-mc). - No admitido para el tráfico que usa Services de tipo
LoadBalancer. - Debe haber una relación clara y aislada entre los componentes involucrados en el ajuste de escala automático basado en el tráfico. Un objeto HPA debe dedicarse a escalar una sola Deployment (o cualquier recurso escalable) expuesta por un solo servicio.
- Después de configurar la capacidad de tu servicio con el campo
maxRatePerEndpoint, espera el tiempo suficiente (por lo general, un minuto, pero potencialmente hasta 15 minutos en clústeres grandes) para que el balanceador de cargas se actualice con este cambio antes de configurar el HPA con métricas basadas en el tráfico. Este enfoque ayuda a garantizar que tu servicio no experimente temporalmente una situación en la que tu clúster intente escalar automáticamente según las métricas que emite un balanceador de cargas que aún se está configurando. - Si se usa el ajuste de escala automático basado en el tráfico en un Service que se entrega a través de varios balanceadores de cargas (por ejemplo, a través de un Ingress y una puerta de enlace, o a través de dos puertas de enlace), es posible que el HPA considere el valor de tráfico más alto de los balanceadores de cargas individuales para tomar decisiones de escalamiento, en lugar de la suma de los valores de tráfico de todos los balanceadores de cargas.
Implementa el ajuste de escala automático basado en el tráfico
En el siguiente ejercicio, se usa el HPA para escalar automáticamente el
objeto Deployment store-autoscale en función del tráfico que recibe. Una Gateway acepta el tráfico de entrada de Internet para los Pods. El escalador automático compara las señales de tráfico de la puerta de enlace con la capacidad de tráfico por Pod configurada en el recurso de Service store-autoscale. Cuando generas tráfico a la Gateway, influyes en la cantidad de Pods implementados.
En el siguiente diagrama, se muestra cómo funciona el ajuste de escala automático basado en el tráfico:
Para implementar el ajuste de escala automático basado en el tráfico, sigue estos pasos:
Para 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 gatewayclassEl resultado confirma que los recursos GatewayClass de GKE 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 16hSi no ves este resultado, habilita la API de Gateway en tu clúster de GKE.
Implementa la aplicación de muestra y el balanceador de cargas de Gateway en tu clúster:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yamlLa aplicación de muestra crea lo siguiente:
- Una Deployment con 2 réplicas.
- Un servicio con un parámetro de configuración
GCPBackendPolicyasociadomaxRatePerEndpointestablecido en10. Para obtener más información sobre las capacidades de la puerta de enlace, consulta Funciones de GatewayClass. - Una Gateway externa para acceder a la aplicación en Internet. Para obtener más información sobre cómo usar los balanceadores de cargas de Gateway, consulta Implementa puertas de enlace.
- Una HTTPRoute que hace coincidir todo el tráfico y lo envía al Service
store-autoscale.
La capacidad del Service es un elemento fundamental cuando se usa el ajuste de escala automático basado en el tráfico, ya que determina la cantidad de tráfico por Pod que activa un evento de ajuste de escala automático. Se configura con un campo
maxRatePerEndpointen un objeto GCPBackendPolicy asociado al servicio, que define el tráfico máximo que un servicio debe recibir en solicitudes por segundo, por Pod. La capacidad del Service es específica de tu aplicación.Para obtener más información, consulta Determina la capacidad de tu Service.
Guarda el siguiente 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: AverageValueEn este manifiesto, se describe un objeto HPA con las siguientes propiedades:
minReplicasymaxReplicas: Establecen la cantidad mínima y máxima de réplicas para esta Deployment. En esta configuración, la cantidad de Pods puede escalar de1a10réplicas (o de0réplicas si configuras el escalamiento desde y hacia cero con HPA).describedObject.name: store-autoscale: Es la referencia al Servicestore-autoscaleque define la capacidad de tráfico.scaleTargetRef.name: store-autoscale: Es la referencia a la Deploymentstore-autoscaleque define el recurso escalado por el HPA.averageValue: 70: Es el valor objetivo promedio del 70% del uso de capacidad. Esto le da al HPA un margen de crecimiento para que los Pods en ejecución puedan procesar el tráfico excesivo mientras se crean Pods nuevos.
Si creas un manifiesto para que coincida con detalles específicos de tu propio proyecto, asegúrate de no incluir datos sensibles en los campos del escalador automático horizontal de Pods.
El HPA tiene como resultado el siguiente comportamiento de tráfico:
- La cantidad de Pods se ajusta entre 1 y 10 réplicas para alcanzar el 70% de la tasa máxima por extremo. Esto da como resultado 7 RPS por Pod cuando se configura
maxRatePerEndpoint=10. - A más de 7 RPS por Pod, los Pods se escalan verticalmente hasta alcanzar su máximo de 10 réplicas o hasta que el tráfico promedio sea de 7 RPS por Pod.
- Si se reduce el tráfico, se reduce verticalmente la escala de los Pods a una tasa razonable con el algoritmo del HPA.
También puedes implementar un generador de tráfico para validar el comportamiento del ajuste de escala automático basado en el tráfico.
A 30 RPS, la Deployment se escala a 5 réplicas para que cada réplica reciba, de manera ideal, 6 RPS de tráfico, que sería un 60% de uso por Pod. Esto está por debajo del uso objetivo del 70%, por lo que los Pods se escalan de manera adecuada. Según las fluctuaciones del tráfico, la cantidad de réplicas con ajuste de escala automático también puede fluctuar. Para obtener una descripción más detallada de cómo se calcula la cantidad de réplicas, consulta Comportamiento del ajuste de escala automático.
Ajuste de escala automático en función de varias métricas
En este ejemplo, se crea un objeto HPA que se ajusta automáticamente según el uso de CPU y una métrica personalizada llamada packets_per_second.
Si seguiste el ejemplo anterior y aún tienes un objeto de HPA llamado nginx,
bórralo antes de seguir este ejemplo.
En este ejemplo, se necesita apiVersion: autoscaling/v2. A fin de obtener más información sobre las API disponibles, consulta las versiones de la API para objetos HPA.
Guarda este manifiesto YAML como 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
Si creas un manifiesto para que coincida con detalles específicos de tu propio proyecto, asegúrate de no incluir datos sensibles en los campos del escalador automático horizontal de Pods.
Aplica el manifiesto YAML:
kubectl apply -f nginx-multiple.yaml
Cuando se crea, el HPA supervisa el Deployment de nginx para el uso promedio de la CPU, el uso promedio de la memoria y (si quitaste el comentario) la métrica personalizada de packets_per_second. El HPA ajusta automáticamente la escala del Deployment en función de la métrica cuyo valor crearía el evento de ajuste de escala automático más grande.
Escala desde y hacia cero
A partir de la versión 1.37 de GKE, puedes configurar el HPA para que reduzca la escala de un Deployment a cero (0) réplicas cuando no haya demanda de carga de trabajo y vuelva a aumentarla con escalado automático cuando aumente la demanda. Cuando se realiza un ajuste de escala vertical desde cero, GKE omite las verificaciones de tolerancia de métricas estándar para activar los Pods sin demora.
Para configurar el ajuste de escala a cero y desde cero con HPA, debes hacer lo siguiente:
- Asegúrate de que tu clúster ejecute la versión 1.37 de GKE o una posterior.
- Configura al menos una métrica personalizada o externa con el recurso AutoscalingMetric.
- Establece el par campo-valor
minReplicas: 0en un manifiesto de HPA que use la API deautoscaling/v2.
Para obtener instrucciones paso a paso, consulta Cómo escalar cargas de trabajo de GKE a cero y desde cero con HPA.
Configura el perfil de HPA de rendimiento
El perfil de HPA de rendimiento mejora el tiempo de reacción del escalado automático horizontal de Pods, lo que ayuda a mejorar la capacidad del HPA para controlar una gran cantidad de objetos (hasta 1,000 objetos en las versiones secundarias 1.31-1.32 y 5,000 objetos en la versión 1.33 o posterior).
Este perfil se habilita automáticamente en los clústeres de Autopilot aptos con un plano de control que ejecuta la versión 1.32 de GKE o una posterior. En el caso de los clústeres de Standard, el perfil se habilita automáticamente en los clústeres aptos con un plano de control que ejecuta la versión 1.33 de GKE o una posterior.
Un clúster de Standard está exento de la habilitación automática del perfil de HPA de rendimiento si cumple con todas las siguientes condiciones:
- El clúster se está actualizando de una versión anterior a la 1.33 o posterior.
- El clúster tiene, al menos, un grupo de nodos con cualquiera de los siguientes tipos de máquina:
e2-micro,e2-custom-micro,g1-small,f1-micro. - El aprovisionamiento automático de nodos no está habilitado.
También puedes habilitar el perfil de HPA de rendimiento en clústeres existentes si cumplen con los requisitos.
Requisitos
Para habilitar el perfil de HPA de rendimiento, verifica que tus clústeres de Autopilot y Standard cumplan con los siguientes requisitos:
- Tu plano de control ejecuta la versión 1.31 de GKE o una posterior.
- Si tu plano de control ejecuta la versión 1.31 de GKE, habilita la recopilación de métricas del sistema.
- La API de Autoscaling está habilitada en tu proyecto.
- Todas las
cuentas de servicio de nodo
tienen asignado el rol
roles/autoscaling.metricsWriter. - Si usas los Controles del servicio de VPC, verifica que la API de ajuste de escala automático esté incluida en tu perímetro de servicio.
Habilita 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
Reemplaza lo siguiente:
CLUSTER_NAME: Es el nombre del clúster.LOCATION: Es la zona o región de procesamiento (p.ej., us-central1-a o us-central1) del clúster.PROJECT_ID: Es el ID del proyecto de Google Cloud .
Inhabilita 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
Reemplaza lo siguiente:
CLUSTER_NAME: Es el nombre del clúster.LOCATION: Es la zona o región de procesamiento (p.ej., us-central1-a o us-central1) del clúster.PROJECT_ID: Es el ID del proyecto de Google Cloud .
Visualiza detalles sobre un HorizontalPodAutoscaler
Para ver la configuración y las estadísticas de un HPA, usa el siguiente comando:
kubectl describe hpa HPA_NAME
Reemplaza HPA_NAME por el nombre de tu objeto HPA.
El estado actual de cada objeto de HPA se muestra en el campo Conditions, y los eventos de ajuste automático se enumeran en el campo Events.
El resultado es similar a lo 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>
Borra un HorizontalPodAutoscaler
Puedes borrar un objeto HPA con la consola de Google Cloud o el comando kubectl delete.
Console
Para borrar el objeto nginx de HPA, haz lo siguiente:
Accede a la página Cargas de trabajo de la consola de Google Cloud .
Haz clic en el nombre de la Deployment
nginx.Haz clic en list Acciones > Ajuste de escala automático.
Haz clic en Borrar.
kubectl delete
Para borrar el objeto nginx del HPA, usa el siguiente comando:
kubectl delete hpa nginx
Cuando borras un objeto de HPA, el Deployment (u otro objeto de implementación) permanece
en su escala existente y no vuelve a la cantidad de réplicas en
el manifiesto original del Deployment. Para ajustar manualmente la escala de la Deployment a tres Pods, puedes usar el comando kubectl scale:
kubectl scale deployment nginx --replicas=3
Realiza una limpieza
Borra el objeto HPA, si aún no lo hiciste:
kubectl delete hpa nginxBorra la Deployment de
nginx:kubectl delete deployment nginxSi lo deseas, borra el clúster.
Soluciona problemas
Para obtener asesoramiento sobre la solución de problemas, consulta Soluciona problemas del ajuste de escala automático horizontal de Pods.
¿Qué sigue?
- Obtén más información sobre el escalado automático horizontal de Pods.
- Obtén más información para ajustar el tamaño correcto de las cargas de trabajo de HPA con VPA.
- Obtén más información sobre el Ajuste de escala automático vertical de Pods
- Obtén más información sobre el aumento de CPU en el inicio.