Esta página se ha traducido con Cloud Translation API.

Solucionar problemas con el autoescalado de pods horizontal

Autopilot Standard

Si el autoescalado horizontal de pods no funciona como esperas en Google Kubernetes Engine (GKE), es posible que tus cargas de trabajo no se escalen correctamente. Este problema puede impedir que las aplicaciones gestionen la carga, lo que puede provocar problemas de rendimiento o interrupciones. Es posible que veas que los pods no aumentan a pesar de que la CPU es alta, que los valores de las métricas se muestran como <unknown> en el estado de HorizontalPodAutoscaler o que no se producen operaciones de escalado.

Usa esta página para diagnosticar y resolver problemas habituales con el autoescalado horizontal de pods, desde errores de configuración inicial en tus objetos HorizontalPodAutoscaler hasta fallos más complejos en la canalización de métricas. Si sigues estos pasos para solucionar problemas, podrás asegurarte de que tus aplicaciones se escalen de forma eficiente y fiable en función de la demanda, lo que te permitirá usar de forma eficaz el recurso de escalado automático horizontal de pods.

Esta información es importante para los desarrolladores de aplicaciones que configuran objetos HorizontalPodAutoscaler y necesitan asegurarse de que sus aplicaciones se escalan correctamente. También ayuda a los administradores y operadores de la plataforma a solucionar problemas con la canalización de métricas o la configuración del clúster que afectan a todas las cargas de trabajo con escalado automático. Para obtener más información sobre los roles habituales y las tareas de ejemplo a los que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas habituales de los usuarios de GKE.

Si ya has experimentado síntomas o has visto un mensaje de error, consulta la siguiente tabla para obtener las instrucciones adecuadas:

Síntoma	Posible solución
No hay escalado, pero las condiciones de HorizontalPodAutoscaler son `True`	Solucionar problemas con un HorizontalPodAutoscaler que está en buen estado, pero no responde
Aparece un mensaje de error específico en los eventos de HorizontalPodAutoscaler	Solucionar errores comunes de la herramienta de adaptación dinámica de pods horizontales
Métrica `<unknown>`	Solucionar problemas con métricas personalizadas y externas
No se reduce verticalmente	Solucionar problemas de la herramienta de adaptación dinámica de pods horizontales que no puede reducir la escala

Antes de empezar

Asegúrate de usar objetos HorizontalPodAutoscaler con cargas de trabajo escalables, como Deployments y StatefulSets. No puedes usar el autoescalado de pods horizontal con cargas de trabajo que no se puedan escalar, como los DaemonSets.
Para obtener los permisos que necesitas para solucionar problemas de autoescalado horizontal de pods en GKE, lo que incluye inspeccionar objetos HorizontalPodAutoscaler y ver los registros del clúster, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos en tu proyecto:
- Inspecciona los recursos de GKE: Lector de GKE (roles/container.viewer)
- Para ver los registros del clúster, haz lo siguiente: Visualizador de registros (roles/logging.viewer)
Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.
Configura la herramienta de línea de comandos kubectl para que se comunique con tu clúster de GKE:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID
```
Haz los cambios siguientes:
- CLUSTER_NAME: el nombre de tu clúster.
- LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
- PROJECT_ID: tu ID de proyecto Google Cloud .

Verificar el estado y la configuración de la herramienta de adaptación dinámica horizontal de pods

Para empezar a solucionar el problema, inspecciona el estado y la configuración del objeto HorizontalPodAutoscaler. Esta comprobación inicial te ayuda a identificar y resolver errores de configuración básicos, que son una causa habitual de los problemas de escalado.

Describe el objeto HorizontalPodAutoscaler

Para ver los cálculos en tiempo real y las decisiones de escalado recientes de HorizontalPodAutoscaler, usa el comando kubectl describe hpa. Este comando proporciona un resumen del objeto HorizontalPodAutoscaler y un registro Events que resulta útil para diagnosticar problemas:

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

Haz los cambios siguientes:

HPA_NAME: el nombre de tu objeto HorizontalPodAutoscaler.
NAMESPACE_NAME: el espacio de nombres de tu objeto HorizontalPodAutoscaler.

El resultado debería ser similar al siguiente:

Name:                                                  php-apache-hpa
Reference:                                             Deployment/php-apache
Metrics: ( current / target )
  resource cpu on pods (as a percentage of request):   1% (1m) / 50%
Min replicas:                                          1
Max replicas:                                          10
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HorizontalPodAutoscaler was able to successfully calculate a replica count
Events:
  Type     Reason              Age   From                       Message
  ----     ------              ----  ----                       -------
  Normal   SuccessfulRescale   39m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization...
  Normal   SuccessfulRescale   26m   horizontal-pod-autoscaler  New size: 1; reason: cpu resource utilization...

En el resultado, las tres secciones siguientes te ayudan a diagnosticar el problema:

Metrics: en esta sección se muestran los valores actuales de las métricas en comparación con sus objetivos. Comprueba aquí si HorizontalPodAutoscaler está recibiendo datos. Un valor de métrica <unknown> indica que HorizontalPodAutoscaler no ha obtenido la métrica o que la canalización de métricas no funciona.
Conditions: esta comprobación de estado de alto nivel muestra si HorizontalPodAutoscaler puede obtener métricas (AbleToScale) y realizar cálculos de escalado (ScalingActive). El estado False en cualquiera de estas condiciones indica un error.
Events: en esta sección se registran las acciones de escalado, las advertencias y los errores recientes del controlador HorizontalPodAutoscaler. A menudo, es el primer lugar en el que se pueden encontrar mensajes de error o motivos específicos, como FailedGetScale o FailedGetResourceMetric, que te ayudan a descubrir el origen del problema.

Comprobar el estado de HorizontalPodAutoscaler en Despliegues

Para comprobar el estado de los objetos HorizontalPodAutoscaler que se usan con tus Deployments, usa la Google Cloud consola:

En la Google Cloud consola, ve a la página Cargas de trabajo.

Ir a Cargas de trabajo
Haz clic en el nombre de la implementación.
Ve a la pestaña Detalles y busca la sección Escalado automático.
Revisa el valor de la fila Estado:
- Una marca de verificación verde significa que HorizontalPodAutoscaler está configurado y puede leer sus métricas.
- Un triángulo de color ámbar significa que el HorizontalPodAutoscaler está configurado, pero tiene problemas para leer sus métricas. Este es un problema habitual con las métricas personalizadas o externas. Para solucionar este problema, diagnostique por qué no están disponibles las métricas. Para obtener más información, consulta la sección Solucionar problemas con métricas personalizadas y externas.

Para otros tipos de cargas de trabajo, como StatefulSets, o para obtener más información, consulta el manifiesto del objeto HorizontalPodAutoscaler.

Comprueba el manifiesto de HorizontalPodAutoscaler

El manifiesto YAML de tu objeto HorizontalPodAutoscaler te permite ver información sobre su configuración y su estado actual.

Para ver el manifiesto YAML, selecciona una de las siguientes opciones:

Consola

En la Google Cloud consola, ve a la página Explorador de objetos.

Ir al navegador de objetos
En la lista Tipos de objeto, selecciona la casilla HorizontalPodAutoscaler y haz clic en Aceptar.
Ve al grupo de APIs autoscaling y, a continuación, haz clic en la flecha del desplegable de HorizontalPodAutoscaler.
Haga clic en el nombre del objeto HorizontalPodAutoscaler que quiera inspeccionar.
Consulta la sección YAML, donde se muestra la configuración completa del objeto HorizontalPodAutoscaler.

kubectl

Ejecuta el siguiente comando:

kubectl get hpa HPA_NAME -n NAMESPACE_NAME -o yaml

Haz los cambios siguientes:

HPA_NAME: el nombre de tu objeto HorizontalPodAutoscaler.
NAMESPACE_NAME: el espacio de nombres de tu objeto HorizontalPodAutoscaler.

Una vez que hayas obtenido el manifiesto, busca estas secciones clave:

spec (tu configuración):
- scaleTargetRef: la carga de trabajo (como un Deployment) que debe escalar HorizontalPodAutoscaler.
- minReplicas y maxReplicas: los ajustes de réplica mínimos y máximos.
- metrics: las métricas que has configurado para el escalado (por ejemplo, el uso de la CPU o las métricas personalizadas).
status (el estado activo de HorizontalPodAutoscaler):
- currentMetrics: los valores de métricas más recientes que ha observado HorizontalPodAutoscaler.
- currentReplicas y desiredReplicas: el número actual de pods y el número al que HorizontalPodAutoscaler quiere escalar.
- conditions: la sección más valiosa para solucionar problemas. En esta sección se muestra el estado de HorizontalPodAutoscaler:
  - AbleToScale: indica si HorizontalPodAutoscaler puede encontrar su objetivo y sus métricas.
  - ScalingActive: muestra si HorizontalPodAutoscaler tiene permiso para calcular y realizar el escalado.
  - ScalingLimited: muestra si HorizontalPodAutoscaler quiere escalar, pero está limitado por los ajustes de minReplicas o maxReplicas.

Usar funciones de registro avanzadas

Para obtener información más detallada sobre tu objeto HorizontalPodAutoscaler, usa los siguientes tipos de registros:

Ver eventos de la herramienta de adaptación dinámica horizontal de pods en Cloud Logging: usa un filtro de registro para encontrar todos los eventos de la herramienta de adaptación dinámica horizontal de pods de un clúster específico. Por ejemplo:
1. En la Google Cloud consola, ve a la página Explorador de registros.
  
  Ir a Explorador de registros
2. En el panel de consultas, introduce la siguiente consulta:
```
resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
logName="projects/PROJECT_ID/logs/events"
jsonPayload.involvedObject.kind="HorizontalPodAutoscaler"`
```
  Haz los cambios siguientes:
  - CLUSTER_NAME: el nombre del clúster al que pertenece HorizontalPodAutoscaler.
  - LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
  - PROJECT_ID: tu ID de proyecto.
3. Haz clic en Ejecutar consulta y revisa el resultado.
Ver eventos de la herramienta de adaptación dinámica horizontal de pods: estos registros proporcionan registros estructurados y legibles que explican cómo calcula la herramienta de adaptación dinámica horizontal de pods una recomendación, lo que ofrece información detallada sobre su proceso de toma de decisiones.

Solucionar problemas de un HorizontalPodAutoscaler en buen estado, pero que no responde

En esta sección se explica por qué es posible que tu HorizontalPodAutoscaler no esté activando ninguna acción de escalado, aunque parezca que funciona correctamente y no informe de ningún error en su estado o eventos.

Síntomas:

El HorizontalPodAutoscaler parece correcto, sus condiciones indican True y no muestra ningún error en sus eventos. Sin embargo, no realiza ninguna acción de escalado.

Causa:

Este comportamiento esperado puede deberse a varios factores:

Límites de réplicas: el número actual de réplicas ya ha alcanzado el límite establecido por el campo minReplicas o maxReplicas en la configuración de HorizontalPodAutoscaler.
Ventana de tolerancia: Kubernetes usa una ventana de tolerancia predeterminada del 10% para evitar el escalado en fluctuaciones menores de las métricas. El escalado solo se produce si la relación entre la métrica actual y la métrica objetivo está fuera del intervalo de 0,9 a 1,1. Por ejemplo, si el objetivo es el 85% de CPU y el uso actual es del 93%, la proporción es de aproximadamente 1,094 (93/85 ≈ 1,094). Como este valor es inferior a 1,1, el autoescalador de pods horizontal no aumenta la escala.
Pods no preparados: el autoescalador horizontal de pods solo incluye en sus cálculos de escalado los pods con el estado Ready. Los pods que se quedan bloqueados con el estado Pending o que no pasan al estado Ready (porque no superan las comprobaciones de estado o por problemas con los recursos) se ignoran y pueden impedir el escalado.
Retraso del periodo de sincronización: el controlador HorizontalPodAutoscaler comprueba las métricas periódicamente. Es normal que haya un retraso de entre 15 y 30 segundos entre el momento en que una métrica supera el umbral y el momento en que se inicia una acción de escalado.
Latencia de métricas nuevas: cuando un HorizontalPodAutoscaler usa una nueva métrica personalizada por primera vez, puede que se produzca una latencia única de varios minutos. Este retraso se produce porque el sistema de monitorización (como Cloud Monitoring) debe crear la nueva serie temporal cuando se escribe el primer punto de datos.
Cálculo de varias métricas: cuando configuras varias métricas, el autoescalador horizontal de pods calcula el número de réplicas necesario para cada métrica de forma independiente y, a continuación, elige el valor calculado más alto como número final de réplicas. Debido a este comportamiento, tu carga de trabajo se escala para satisfacer las demandas de la métrica con las necesidades más altas. Por ejemplo, si las métricas de CPU calculan que se necesitan 9 réplicas, pero una métrica de solicitudes por segundo calcula que se necesitan 15, el escalador automático horizontal de pods escala la implementación a 15 réplicas.

Resolución:

Prueba las siguientes soluciones:

Límites de réplicas: comprueba los valores minReplicas y maxReplicas en el manifiesto de HorizontalPodAutoscaler o en el resultado del comando kubectl describe. Ajusta estos límites si impiden el escalado necesario.
Ventana de tolerancia: si se requiere un ajuste de escala dentro de la tolerancia predeterminada, configure un valor de tolerancia diferente. De lo contrario, espera a que la métrica salga del intervalo de 0,9 a 1,1.
Pods no preparados: investiga por qué los pods están Pending o no Ready y resuelve los problemas subyacentes (por ejemplo, las restricciones de recursos o los errores en las sondas de disponibilidad). Para obtener consejos sobre cómo solucionar problemas, consulta el artículo Depurar pods de la documentación de Kubernetes.
Retraso del periodo de sincronización y latencia de las métricas nuevas: estas latencias son normales. Espere a que finalice el periodo de sincronización o a que se cree la nueva serie temporal de la métrica personalizada.
Cálculo de varias métricas: este es el comportamiento previsto. Si el escalado vertical se produce en función de una métrica (como las solicitudes por segundo), se anula correctamente el cálculo inferior de otra métrica (como la CPU).

Solucionar errores habituales de la herramienta de adaptación dinámica horizontal de pods

En las siguientes secciones se ofrecen soluciones para mensajes de error y motivos de eventos específicos que pueden aparecer al inspeccionar el estado de HorizontalPodAutoscaler. Normalmente, estos mensajes se encuentran en la sección Events de la salida del comando kubectl describe hpa.

Solucionar errores de configuración de la herramienta de adaptación dinámica horizontal de pods

Los errores de esta sección se deben a un error de configuración en el manifiesto de HorizontalPodAutoscaler, como un campo mal escrito o configuraciones conflictivas.

Error: métricas no válidas

Es posible que veas este error cuando la configuración de una métrica de un HorizontalPodAutoscaler sea sintácticamente incorrecta o incoherente.

Síntomas:

Si HorizontalPodAutoscaler no puede calcular las réplicas necesarias debido a un problema de configuración, su sección Events muestra el motivo FailedComputeMetricsReplicas con un mensaje similar al siguiente:

invalid metrics (1 invalid out of 1)

Causa:

Este error suele significar que hay una discrepancia entre la métrica type y el target que has definido en el manifiesto de HorizontalPodAutoscaler. Por ejemplo, puede que haya especificado un type de Utilization, pero haya proporcionado un valor objetivo de averageValue en lugar de averageUtilization.

Resolución:

Corrige el manifiesto de HorizontalPodAutoscaler para que el valor del campo target coincida con la métrica type:

Si type es Utilization, el valor del campo target debe ser averageUtilization.
Si type es AverageValue, el valor del campo target debe ser averageValue.

Error: varios servicios seleccionan el mismo destino

Puede que veas este error al usar el escalado automático basado en el tráfico que tiene una configuración de servicio incorrecta para tu HorizontalPodAutoscaler.

Síntomas:

Aparece el siguiente error:

multiple services selecting the same target of HPA_NAME: SERVICE_NAME

Esta salida incluye los siguientes valores:

HPA_NAME: nombre de HorizontalPodAutoscaler.
SERVICE_NAME: el nombre de un servicio.

Causa:

El autoescalado basado en el tráfico está configurado, pero más de un servicio de Kubernetes tiene como destino el campo scaleTargetRef de HorizontalPodAutoscaler. El escalado automático basado en el tráfico solo admite una relación individual entre el servicio y la carga de trabajo escalada automáticamente.

Resolución:

Para solucionar este problema, asegúrate de que solo un selector de etiquetas de Service coincida con los pods de tu carga de trabajo:

Busca las etiquetas de los pods de tu carga de trabajo:
```
kubectl get deployment HPA_TARGET_DEPLOYMENT \
    -n NAMESPACE \
    -o jsonpath='{.spec.template.metadata.labels}'
```
Haz los cambios siguientes:
- HPA_TARGET_DEPLOYMENT: el nombre del Deployment al que se dirige HorizontalPodAutoscaler.
- NAMESPACE: el espacio de nombres de la implementación.
El resultado debería ser similar al siguiente:
```
{"app":"my-app", "env":"prod"}
```
Para encontrar todos los servicios que coincidan con esas etiquetas, revisa el campo spec.selector de todos los servicios del espacio de nombres.
```
kubectl get services -n NAMESPACE -o yaml
```
Identifica todos los servicios cuyo selector coincida con las etiquetas del paso anterior. Por ejemplo, tanto {"app": "my-app"} como {"app": "my-app", "env": "prod"} coincidirían con las etiquetas de Pod de ejemplo.
Resuelve el conflicto eligiendo una de las siguientes opciones:
- Asigna un selector único al servicio añadiendo una etiqueta nueva y única al campo spec.template.metadata.labels de tu implementación. A continuación, actualiza el campo spec.selector del servicio correspondiente para incluir esta nueva etiqueta.
- Haz que otros selectores de servicios sean más restrictivos cambiando el campo spec.selector de todos los otros servicios en conflicto para que sean más restrictivos y ya no coincidan con los pods de tu carga de trabajo.
Aplica los cambios:
```
kubectl apply -f MANIFEST_NAME
```
Sustituye MANIFEST_NAME por el nombre del archivo YAML que contiene el manifiesto de servicio o de implementación actualizado.

Error: no se permite la etiqueta

Síntomas:

Aparece el siguiente error:

unable to fetch metrics from external metrics API: googleapi: Error 400: Metric label: 'LABEL_NAME' is not allowed

En este resultado, LABEL_NAME es el nombre de la etiqueta incorrecta.

Causa:

El manifiesto de HorizontalPodAutoscaler especifica una clave de etiqueta no válida en la sección metric.selector.matchLabels y Cloud Monitoring no reconoce ni permite esta clave para la métrica.

Resolución:

Para solucionar este problema, sigue estos pasos:

Identifica el nombre de la etiqueta no permitida en el mensaje de error.
Retire o corrija esta clave de etiqueta en la sección metric.selector.matchLabels del manifiesto de HorizontalPodAutoscaler.
Para encontrar una clave de etiqueta válida que se pueda filtrar, consulta la documentación de Cloud Monitoring sobre esa métrica.

Problema: varios HorizontalPodAutoscalers se dirigen a la misma carga de trabajo

Configurar varios objetos HorizontalPodAutoscaler para gestionar la misma carga de trabajo provoca un comportamiento de escalado conflictivo e impredecible.

Síntomas:

No hay ningún Condition ni Reason específico en el estado de un HorizontalPodAutoscaler que indique directamente este conflicto. En su lugar, puede que observes los siguientes síntomas:

El recuento de réplicas de la carga de trabajo puede fluctuar de forma inesperada.
Es posible que las decisiones de escalado no se correspondan con las métricas definidas en ningún objeto HorizontalPodAutoscaler.
Cuando veas eventos, es posible que veas eventos alternativos o contradictorios SuccessfulRescale de diferentes objetos HorizontalPodAutoscaler.

Causa:

Este problema se produce porque más de un objeto HorizontalPodAutoscaler del mismo espacio de nombres especifica la misma carga de trabajo en el campo spec.scaleTargetRef. Cada HorizontalPodAutoscaler calcula de forma independiente el número de réplicas e intenta escalar la carga de trabajo en función de su propio conjunto de métricas y objetivos. Kubernetes no bloquea esta configuración, pero provoca ajustes de escalado erráticos porque los HorizontalPodAutoscalers compiten entre sí.

Resolución:

Para evitar conflictos, define todas las métricas de escalado en un solo objeto HorizontalPodAutoscaler. Cada HorizontalPodAutoscaler calcula las necesidades de escalado a partir de su propio campo spec.metrics, por lo que, al combinarlo, el objeto HorizontalPodAutoscaler elegido puede tener en cuenta todos los factores, como la CPU y las solicitudes por segundo, a la vez:

Para identificar qué HorizontalPodAutoscalers se dirigen a la misma carga de trabajo, obtén el manifiesto YAML de cada objeto HorizontalPodAutoscaler. Presta mucha atención al campo spec.scaleTargetRef del resultado.
```
kubectl get hpa -n NAMESPACE_NAME -o yaml
```
Sustituye NAMESPACE_NAME por el espacio de nombres de tu objeto HorizontalPodAutoscaler.

Busca las instancias en las que diferentes recursos de HorizontalPodAutoscaler tengan los mismos valores para apiVersion, kind y name en su campo scaleTargetRef.
Consolida las métricas en un único objeto HorizontalPodAutoscaler:
1. Elige un objeto HorizontalPodAutoscaler que quieras conservar. Este HorizontalPodAutoscaler será el que modifiques.
2. Examina la sección spec.metrics del manifiesto de cada uno de los otros objetos HorizontalPodAutoscaler que tengan como destino la misma carga de trabajo.
3. Copia las definiciones de métricas que quieras conservar de las secciones spec.metrics de los objetos HorizontalPodAutoscaler duplicados.
4. Pega estas definiciones de métricas copiadas en la matriz spec.metrics del HorizontalPodAutoscaler que hayas decidido conservar.
Aplica los cambios:
```
kubectl apply -f MANIFEST_NAME
```
Sustituye MANIFEST_NAME por el nombre del manifiesto de HorizontalPodAutoscaler que hayas decidido conservar.
Elimina los demás objetos HorizontalPodAutoscaler que se dirigían a la misma carga de trabajo:
```
kubectl delete hpa DUPLICATE_MANIFEST_NAME -n NAMESPACE_NAME
```
Sustituye DUPLICATE_MANIFEST_NAME por el nombre del objeto HorizontalPodAutoscaler redundante que quieras eliminar.

Solucionar problemas de carga de trabajo y de destino

Los errores de esta sección se deben al escalado de Deployment, StatefulSet o Pods, no al objeto HorizontalPodAutoscaler en sí.

Error: no se puede obtener la escala actual del elemento de destino

Este error puede aparecer cuando HorizontalPodAutoscaler no puede localizar o acceder a la carga de trabajo que debería escalar.

Síntomas:

La sección Events tiene una condición FailedGetScale con un mensaje similar al siguiente:

the HorizontalPodAutoscaler controller was unable to get the target's current scale: WORKLOAD_TYPE.apps "TARGET_WORKLOAD" not found

Esta salida incluye los siguientes valores:

WORKLOAD_TYPE: el tipo de carga de trabajo, como Deployment o StatefulSet.
TARGET_WORKLOAD: el nombre de la carga de trabajo.

Causa:

El controlador HorizontalPodAutoscaler no puede encontrar la carga de trabajo (como un Deployment o un StatefulSet) que está configurado para gestionar. Este problema se debe a un error en el campo scaleTargetRef del manifiesto de HorizontalPodAutoscaler. Es posible que el recurso especificado no exista, se haya eliminado o tenga un error ortográfico.

Resolución:

Prueba las siguientes soluciones:

Verifica el campo scaleTargetRef del manifiesto de HorizontalPodAutoscaler: asegúrate de que los valores de name, kind y apiVersion del campo scaleTargetRef coincidan exactamente con los metadatos correspondientes de tu carga de trabajo de destino. Si el nombre de la carga de trabajo es incorrecto, actualiza el campo scaleTargetRef de HorizontalPodAutoscaler para que apunte al nombre correcto.
Confirma que la carga de trabajo existe: asegúrate de que la carga de trabajo de destino se encuentra en el mismo espacio de nombres que HorizontalPodAutoscaler. Puedes comprobarlo con un comando como kubectl get deployment DEPLOYMENT_NAME. Si has eliminado la carga de trabajo intencionadamente, elimina el objeto HorizontalPodAutoscaler correspondiente para limpiar el clúster. Si tienes que volver a crear la carga de trabajo, HorizontalPodAutoscaler la encontrará automáticamente cuando esté disponible y el error se resolverá.
Comprueba que HorizontalPodAutoscaler y la carga de trabajo estén en el mismo espacio de nombres: HorizontalPodAutoscaler y su carga de trabajo de destino deben estar en el mismo espacio de nombres. Si olvidas especificar un espacio de nombres al crear un objeto con comandos kubectl, Kubernetes colocará el objeto en el espacio de nombres default. Este comportamiento puede provocar un desajuste si tu HorizontalPodAutoscaler está en el espacio de nombres default mientras que tu carga de trabajo está en otro espacio de nombres, o viceversa. Comprueba el espacio de nombres de ambos objetos y asegúrate de que coincidan.

Una vez que HorizontalPodAutoscaler localiza correctamente su destino, la condición AbleToScale pasa a ser True y el mensaje cambia a the HorizontalPodAutoscaler controller was able to get the target's current scale.

Error: no se puede calcular el número de réplicas

Es posible que veas este error cuando HorizontalPodAutoscaler necesite calcular el escalado en función de la utilización de recursos, pero no tenga la información de referencia necesaria de los pods.

Síntomas:

La condición ScalingActive es False con un Reason de FailedGetResourceMetric. Normalmente, también verás un mensaje similar al siguiente:

the HorizontalPodAutoscaler was unable to compute the replica count

Causa:

El autoescalador horizontal de pods necesita calcular el uso de recursos como porcentaje para escalar la carga de trabajo, pero no puede realizar este cálculo porque falta una definición de resources.requests para el recurso correspondiente (cpu o memory) en al menos un contenedor de la especificación del pod.

Resolución:

Para solucionar este problema, actualice el manifiesto del pod en su Deployment, StatefulSet u otro controlador para incluir un campo resources.requests para el recurso (cpu o memory) que HorizontalPodAutoscaler está intentando escalar en todos los contenedores del pod. Por ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
...
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Error: no se pueden obtener las métricas de Pod para Pod

Este error puede aparecer cuando hay un problema al recuperar las métricas necesarias para que un HorizontalPodAutoscaler tome decisiones de escalado. A menudo, está relacionado con las definiciones de recursos de pods.

Síntomas:

Observas un mensaje persistente similar al siguiente:

unable to fetch pod metrics for pod

Es normal que este mensaje aparezca temporalmente cuando se inicia el servidor de métricas.

Causa:

Para escalar en función del porcentaje de utilización de recursos (como cpu o memory), todos los contenedores de los pods a los que se dirige el objeto HorizontalPodAutoscaler deben tener definido el campo resources.requests para ese recurso específico. De lo contrario, HorizontalPodAutoscaler no podrá realizar los cálculos que necesita y no tomará ninguna medida relacionada con esa métrica.

Resolución:

Si estos mensajes de error persisten y observas que los pods no se escalan para tu carga de trabajo, asegúrate de haber especificado solicitudes de recursos para cada contenedor de tu carga de trabajo.

Solucionar problemas de la API de métricas y de disponibilidad de datos

En las siguientes secciones se explica cómo resolver los errores que se producen cuando HorizontalPodAutoscaler intenta obtener datos de una API de métricas. Estos problemas pueden ir desde fallos de comunicación interna del clúster, en los que la API de métricas no está disponible, hasta consultas no válidas que rechaza el proveedor de métricas (a menudo se ven como errores HTTP de nivel 400).

Error: no se ha encontrado ninguna versión de métrica disponible

Síntomas:

Aparece el siguiente error:

unable to fetch metrics from custom metrics API: no known available metric versions found

Causa:

Este error indica que se ha producido un fallo en la comunicación del clúster, no un problema con la fuente de las métricas (como Cloud Monitoring). Entre las causas más frecuentes se incluyen las siguientes:

El servidor de la API de Kubernetes no está disponible temporalmente (por ejemplo, durante una actualización del clúster o una reparación del plano de control).
Los pods del adaptador de métricas (por ejemplo, custom-metrics-stackdriver-adapter) no están en buen estado, no se están ejecutando o no están registrados correctamente en el servidor de la API.

Resolución:

Este problema suele ser temporal. Si persiste, prueba las siguientes soluciones:

Comprueba el estado del plano de control de Kubernetes:
1. En la consola de Google Cloud , consulta el estado y el estado de tu clúster.
  1. Ve a la página Clústeres de Kubernetes.
    
    Ir a clústeres de Kubernetes
  2. Consulta las columnas Estado y Notificaciones de tu clúster.
  3. Haz clic en Notificaciones para buscar operaciones en curso, como actualizaciones o reparaciones. Es posible que el servidor de la API no esté disponible durante estos periodos.
2. Revisa los registros de auditoría de Cloud para detectar errores relacionados con los componentes del plano de control. Para obtener información sobre cómo ver estos registros, consulta Registros de auditoría de GKE.
Comprueba el estado y los registros de los pods del adaptador de métricas: asegúrate de que los pods del adaptador de métricas tengan el estado Running y no se hayan reiniciado recientemente:
```
kubectl get pods -n custom-metrics,kube-system -o wide
```
Si el estado de un pod es distinto de Running o tiene un recuento de reinicios alto, investiga el pod para encontrar la causa principal. Para obtener consejos sobre cómo solucionar problemas, consulta Depurar pods en la documentación de Kubernetes.

Verifica que las APIs de métricas estén registradas y disponibles:

kubectl get apiservice | grep metrics.k8s.io

Si las APIs de métricas están en buen estado, el resultado será similar al siguiente:

NAME                            SERVICE                                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.external.metrics.k8s.io custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.metrics.k8s.io          kube-system/metrics-server                          True        18d

Si la columna AVAILABLE tiene el valor False, la columna Message del manifiesto completo de APIService puede proporcionar más detalles.

Puedes ver el manifiesto completo con el siguiente comando:

kubectl get apiservice API_SERVICE_NAME -o yaml

Sustituye API_SERVICE_NAME por el nombre del objeto APIService, como v1beta1.custom.metrics.k8s.io.

Error: la consulta no devolverá ninguna serie temporal

Síntomas:

Aparece el siguiente error:

unable to fetch metrics from custom or external metrics API: googleapi: Error
400: The supplied filter [...] query will not return any time series

Causa:

La consulta enviada a Cloud Monitoring era válida, pero no ha devuelto ningún dato. Esto significa que no hay puntos de datos que coincidan con tu filtro (lo que es diferente de encontrar una métrica con el valor 0). Lo más probable es que la aplicación o la carga de trabajo responsables de generar la métrica personalizada no escribieran datos en Cloud Monitoring durante el periodo en el que se notificaron los errores.

Resolución:

Prueba las siguientes soluciones:

Verifica la configuración: asegúrate de que los nombres y las etiquetas de las métricas de tu objeto HorizontalPodAutoscaler coincidan exactamente con los que emite la aplicación.
Comprueba los permisos: confirma que la aplicación esté configurada correctamente con los permisos y los endpoints de API necesarios para publicar métricas en Cloud Monitoring.
Confirma la actividad de la aplicación: comprueba que la aplicación responsable de la métrica estuviera operativa e intentara enviar datos a Cloud Monitoring durante el periodo en el que se produjeron las advertencias de escalado automático horizontal de pods.
Busca errores: consulta los registros de la aplicación del mismo periodo para ver si hay errores explícitos relacionados con la emisión de métricas, como fallos de conexión, credenciales no válidas o problemas de formato.

Solucionar problemas con métricas personalizadas y externas

Cuando tu HorizontalPodAutoscaler se basa en métricas de fuentes distintas de la CPU o la memoria predeterminadas, pueden producirse problemas en la canalización de métricas personalizadas o externas. Esta canalización consta del controlador HorizontalPodAutoscaler, el servidor de la API de métricas de Kubernetes, el adaptador de métricas y la fuente de métricas (por ejemplo, Cloud Monitoring o Prometheus), tal como se muestra en el siguiente diagrama:

Métricas de HPA
pipeline que muestra los componentes: controlador de HPA, servidor de la API de Kubernetes, adaptador de métricas y fuente de métricas.

En esta sección se explica cómo depurar esta canalización, desde el adaptador de métricas hasta la fuente de métricas.

Síntomas:

Los síntomas más habituales de un problema en la canalización de métricas son los siguientes:

El valor de la métrica se muestra como <unknown>.
Los eventos de HorizontalPodAutoscaler muestran errores como FailedGetExternalMetric o FailedGetCustomMetric.

Causa:

Hay un problema en la canalización de métricas personalizadas o externas.

Resolución:

Sigue estos pasos para depurar la canalización:

Comprueba si el adaptador de métricas está registrado y disponible: el adaptador de métricas debe registrarse en el servidor de la API de Kubernetes principal para proporcionar métricas. Esta acción es la forma más directa de comprobar si el adaptador se está ejecutando y si el servidor de la API puede acceder a él:
```
kubectl get apiservice | grep -E 'NAME|metrics.k8s.io'
```
En el resultado, deberían aparecer las entradas v1beta1.custom.metrics.k8s.io o v1beta1.external.metrics.k8s.io y el valor True en la columna Available. Por ejemplo:
```
NAME                   SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io kube-system/metrics-server   True        18d
```
- Si el valor de la columna Available es False o falta, es probable que el adaptador se haya bloqueado o esté mal configurado. Consulta los registros de Pod del adaptador en el espacio de nombres kube-system o custom-metrics para ver si hay errores relacionados con los permisos, la conectividad de red a la fuente de métricas o mensajes que indiquen que no se ha encontrado la métrica.
- Si el valor es True, ve al paso siguiente.
Consultar la API de métricas directamente: si el adaptador está disponible, omite HorizontalPodAutoscaler y pide la métrica directamente a la API de Kubernetes. Este comando prueba toda la canalización, desde el servidor de la API hasta el adaptador de métricas y la fuente de datos.

Nota: Los siguientes comandos usan el procesador JSON jq para imprimir el resultado JSON. Si no tienes jq instalado, puedes quitar la sección | jq . de los comandos para ver la respuesta JSON sin formato.

Para consultar métricas externas, ejecuta el siguiente comando:
```
kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/METRIC_NAME" | jq .
```
Para consultar métricas de pods personalizadas, ejecuta el siguiente comando:
```
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/pods/*/METRIC_NAME" | jq .
```
Haz los cambios siguientes:
- NAMESPACE_NAME: el espacio de nombres en el que se ejecutan tus pods.
- METRIC_NAME: el nombre de la métrica personalizada o externa que quieres consultar. Por ejemplo, requests_per_second o queue_depth.
Analiza el resultado del comando: el resultado de los comandos anteriores te indica dónde está el problema. Elige el caso que coincida con tu resultado:
- Respuesta JSON correcta con un valor: la canalización de métricas funciona correctamente. Es probable que el problema se deba a un error de configuración en el manifiesto de HorizontalPodAutoscaler. Comprueba si hay errores ortográficos en el nombre de la métrica o si el matchLabels es incorrecto.
- Error: Error from server (Service Unavailable): este error suele indicar un problema de conectividad de red, que a menudo es un problema de firewall en clústeres que usan aislamiento de red.
  1. Identifica el servicio del adaptador de métricas. Normalmente, se encuentra en el espacio de nombres custom-metrics o kube-system:
```
kubectl get service -n custom-metrics,kube-system | grep -E 'adapter|metrics'
```
  2. Busca el puerto en el que está escuchando el adaptador:
```
kubectl get service ADAPTER_SERVICE -n ADAPTER_NAMESPACE -o yaml
```
    Haz los cambios siguientes:
    - ADAPTER_SERVICE: el nombre del servicio de Kubernetes asociado al adaptador de métricas que has desplegado. Este Service es el servicio que has encontrado en el paso anterior. Este servicio expone la funcionalidad del adaptador a otras partes del clúster, incluido el servidor de la API de Kubernetes.
    - ADAPTER_NAMESPACE: el espacio de nombres en el que reside el servicio del adaptador (por ejemplo, custom-metrics o kube-system).
  3. Busca las reglas de cortafuegos de entrada del plano de control de tu clúster:
```
gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master"
```
    Sustituye CLUSTER_NAME por el nombre de tu clúster.
  4. Añade el targetPort del adaptador a la regla:
    
    Precaución: El siguiente comando sustituye a los puertos permitidos. Para evitar que se interrumpa la funcionalidad del clúster, debes incluir los puertos que ya tengas (normalmente, tcp:443 para la API de Kubernetes y tcp:10250 para kubelet) más el ADAPTER_PORT.
    1. Describe la regla actual para ver los puertos permitidos:
      gcloud compute firewall-rules describe FIREWALL_RULE_NAME
      Sustituye FIREWALL_RULE_NAME por el nombre de la regla de cortafuegos que rige el tráfico de red hacia el plano de control de tu clúster de Kubernetes.
    2. Actualiza la regla para añadir el puerto del adaptador a la lista:
      gcloud compute firewall-rules update FIREWALL_RULE_NAME \ --allow tcp:443,tcp:10250,tcp:ADAPTER_PORT
      Sustituye ADAPTER_PORT por el puerto de red en el que está escuchando el adaptador de métricas.
  5. Asegúrate de que las políticas de red de Kubernetes no bloqueen el tráfico a los pods del adaptador de métricas:
```
kubectl get networkpolicy -n custom-metrics,kube-system
```
    Revisa las políticas para asegurarte de que permiten el tráfico de entrada desde el plano de control o el servidor de la API al ADAPTER_SERVICE en el ADAPTER_PORT.
- Una lista vacía []: esta salida significa que el adaptador se está ejecutando, pero no puede recuperar la métrica específica, lo que indica que hay un problema con la configuración del adaptador o con la propia fuente de la métrica.
  - Problemas con el pod del adaptador: inspecciona los registros del pod del adaptador de métricas o los pods para detectar errores relacionados con las llamadas a la API, la autenticación o la obtención de métricas. Para inspeccionar los registros, haz lo siguiente:
    1. Busca el nombre del adaptador Pod:
      kubectl get pods -n ADAPTER_NAMESPACE
    2. Ver sus registros:
      kubectl logs ADAPTER_POD_NAME \ -n ADAPTER_NAMESPACE
      Haz los cambios siguientes:
      - ADAPTER_POD_NAME: el nombre del pod del adaptador que has identificado en el paso anterior.
      - ADAPTER_NAMESPACE: el espacio de nombres en el que reside el pod del adaptador (por ejemplo, custom-metrics o kube-system).
  - No hay datos en la fuente: es posible que la métrica no exista en el sistema de origen. Usa una herramienta de monitorización, como el explorador de métricas, para confirmar que la métrica existe y que tiene el nombre y las etiquetas correctos.

Solucionar problemas de la herramienta de adaptación dinámica horizontal de pods que no puede reducir la escala

En esta sección se explica por qué es posible que un HorizontalPodAutoscaler no reduzca la escala de tu carga de trabajo como esperabas.

Síntomas:

HorizontalPodAutoscaler escala la carga de trabajo correctamente, pero no puede volver a reducirla aunque las métricas, como el uso de la CPU, sean bajas.

Causa:

Este comportamiento se ha diseñado para evitar que se escale verticalmente de forma rápida o que se reduzca verticalmente en función de información incompleta. Los dos motivos principales son los siguientes:

Usar varias métricas: la herramienta de adaptación dinámica horizontal de pods se escala en función de la métrica que requiera el mayor número de réplicas. Si tienes varias métricas, la carga de trabajo no se reducirá a menos que todas las métricas indiquen que se necesitan menos réplicas. Si una métrica requiere un número elevado de réplicas, no se podrá reducir la escala, aunque otras métricas tengan valores bajos.
Métricas no disponibles: si alguna métrica deja de estar disponible (a menudo se muestra como <unknown>), la herramienta de adaptación dinámica de pods horizontal se niega de forma conservadora a reducir la carga de trabajo. No puede determinar si falta la métrica porque el uso es realmente cero o porque la canalización de métricas no funciona. Este problema es habitual con las métricas personalizadas basadas en tasas (por ejemplo, messages_per_second), que pueden dejar de registrar datos cuando no hay actividad, lo que provoca que la herramienta de adaptación dinámica de pods horizontal considere que la métrica no está disponible y detenga las operaciones de reducción.
Retraso de reducción a partir de la política de escalado: el campo behavior de HorizontalPodAutoscaler te permite configurar políticas de escalado. La política predeterminada de reducción incluye un periodo de estabilización de 300 segundos (cinco minutos). Durante este periodo, HorizontalPodAutoscaler no reducirá el número de réplicas, aunque los valores de las métricas hayan caído por debajo del umbral objetivo. Esta ventana evita las fluctuaciones rápidas, pero puede hacer que la reducción de escala sea más lenta de lo esperado.

Resolución:

Prueba las siguientes soluciones:

Si hay varias métricas o métricas no disponibles, diagnostica la métrica que está causando problemas:
```
kubectl describe hpa HPA_NAME -n NAMESPACE_NAME
```
En la salida, busque en la sección Metrics cualquier métrica con el estado <unknown> y en la sección Events advertencias como FailedGetCustomMetric o FailedGetExternalMetric. Para depurar una canalización en detalle, consulta la sección Solucionar problemas de métricas personalizadas y externas.
Si una métrica no está disponible durante periodos de poco tráfico (algo habitual en las métricas basadas en porcentajes), pruebe una de las siguientes soluciones:
- Utiliza métricas basadas en indicadores en lugar de métricas basadas en tasas siempre que sea posible. Una métrica de tipo Gauge, como el número total de mensajes de una cola (por ejemplo, subscription o num_undelivered_messages), informa de un valor de forma constante, aunque ese valor sea 0, lo que permite que el escalado automático horizontal de pods tome decisiones de escalado de forma fiable.
- Asegúrate de que la fuente de la métrica registre valores cero. Si controlas la métrica personalizada, configúrala para que publique un 0 durante los periodos de inactividad en lugar de no enviar ningún dato.
En el caso de los retrasos en la reducción de la escala de la política de escalado, si el periodo de estabilización predeterminado de cinco minutos para las reducciones de escala es demasiado largo, personalízalo. Inspecciona la sección spec.behavior.scaleDown del manifiesto de HorizontalPodAutoscaler. Puedes reducir el stabilizationWindowSeconds para permitir que la herramienta de ajuste automático reduzca el tamaño más rápidamente después de que bajen las métricas. Para obtener más información sobre cómo configurar estas políticas, consulta Políticas de escalado en la documentación de Kubernetes.

Siguientes pasos

Si no encuentras una solución a tu problema en la documentación, consulta la sección Obtener asistencia para obtener más ayuda, incluidos consejos sobre los siguientes temas:
- Abrir un caso de asistencia poniéndose en contacto con el equipo de Atención al Cliente de Cloud.
- Obtener asistencia de la comunidad haciendo preguntas en Stack Overflow y usando la etiqueta google-kubernetes-engine para buscar problemas similares. También puedes unirte al #kubernetes-enginecanal de Slack para obtener más ayuda de la comunidad.
- Abrir errores o solicitudes de funciones mediante el seguimiento de problemas público.

Solucionar problemas con el autoescalado de pods horizontal Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Verificar el estado y la configuración de la herramienta de adaptación dinámica horizontal de pods

Describe el objeto HorizontalPodAutoscaler

Comprobar el estado de HorizontalPodAutoscaler en Despliegues

Comprueba el manifiesto de HorizontalPodAutoscaler

Consola

kubectl

Usar funciones de registro avanzadas

Solucionar problemas de un HorizontalPodAutoscaler en buen estado, pero que no responde

Solucionar errores habituales de la herramienta de adaptación dinámica horizontal de pods

Solucionar errores de configuración de la herramienta de adaptación dinámica horizontal de pods

Error: métricas no válidas

Error: varios servicios seleccionan el mismo destino

Error: no se permite la etiqueta

Problema: varios HorizontalPodAutoscalers se dirigen a la misma carga de trabajo

Solucionar problemas de carga de trabajo y de destino

Error: no se puede obtener la escala actual del elemento de destino

Error: no se puede calcular el número de réplicas

Error: no se pueden obtener las métricas de Pod para Pod

Solucionar problemas de la API de métricas y de disponibilidad de datos

Error: no se ha encontrado ninguna versión de métrica disponible

Error: la consulta no devolverá ninguna serie temporal

Solucionar problemas con métricas personalizadas y externas

Solucionar problemas de la herramienta de adaptación dinámica horizontal de pods que no puede reducir la escala

Siguientes pasos

Solucionar problemas con el autoescalado de pods horizontal