Ajuste de escala automático vertical de Pods

En esta página, se explica cómo puedes analizar y optimizar la asignación de recursos para mejorar la eficiencia de tus cargas de trabajo en Google Kubernetes Engine (GKE) con el ajuste de escala automático vertical de Pods. Si analizas el uso de recursos de tu carga de trabajo a lo largo del tiempo, puedes obtener recomendaciones de optimización y ajustar automáticamente las solicitudes de CPU y memoria, así como los límites para los contenedores dentro de los Pods.

En esta página, aprenderás cómo funciona el ajuste de escala automático vertical de Pods, sus beneficios y limitaciones, las prácticas recomendadas para usarlo y acceder a las referencias de la API para el recurso personalizado VerticalPodAutoscaler y los tipos relacionados.

Esta página está dirigida a operadores y desarrolladores que aprovisionan y configuran recursos de la nube, implementan cargas de trabajo y administran el escalamiento de aplicaciones. Para obtener más información sobre los roles comunes, consulta Roles y tareas comunes del usuario de GKE.

Antes de leer esta página, asegúrate de estar familiarizado con las solicitudes y los límites de recursos en Kubernetes.

Para las necesidades de escalado rápido en respuesta al uso repentino de recursos, usa el Horizontal Pod Autoscaler.

Si deseas obtener prácticas recomendadas sobre el ajuste de escala automático, consulta Prácticas recomendadas para ejecutar aplicaciones de Kubernetes con optimización de costos en GKE.

Por qué usar el escalado automático vertical de Pods

El ajuste de escala automático vertical de Pods proporciona los siguientes beneficios:

  • Configurar las solicitudes y los límites de recursos correctos para las cargas de trabajo mejora la estabilidad y la rentabilidad. Si los tamaños de recursos de tu Pod son más pequeños de lo que requieren tus cargas de trabajo, tu aplicación puede verse limitada o puede fallar debido a errores por memoria insuficiente. Si los recursos son demasiado grandes, tendrás desperdicio y, por lo tanto, facturas más grandes.
  • Los nodos de clúster se usan de manera eficiente, porque los Pods usan exactamente los recursos que necesitan.
  • Los pods se programan en nodos que tienen los recursos adecuados disponibles.
  • No es necesario que ejecutes tareas comparativas que requieren mucho tiempo para determinar los valores correctos de requisitos de CPU y memoria.
  • Puedes reducir el tiempo de mantenimiento, ya que el escalador automático puede ajustar los requisitos de CPU y memoria con el tiempo sin que tengas que realizar ninguna acción.
  • El ajuste de escala automático vertical de Pods funciona mejor con cargas de trabajo homogéneas de larga duración.

El ajuste de escala automático vertical de Pods de GKE proporciona los siguientes beneficios en el escalador automático de código abierto de Kubernetes:

  • Ten en cuenta el tamaño máximo de los nodos y las cuotas de los recursos para determinar el objetivo de recomendación.
  • Notifica al escalador automático del clúster para ajustar su capacidad.
  • Usa datos históricos, incluidas las métricas recopiladas antes de habilitar el VerticalPodAutoscaler.
  • Ejecuta Pods de VerticalPodAutoscaler como procesos del plano de control, en lugar de como implementaciones en tus nodos trabajadores.

Cómo funciona el ajuste de escala automático vertical de Pods

El ajuste de escala automático vertical de Pods te permite analizar y configurar los recursos de CPU y memoria que requieren los Pods. En lugar de tener que configurar solicitudes y límites de CPU y solicitudes y límites de memoria actualizados para los contenedores de tu Pods, puedes configurar el ajuste de escala automático vertical de Pods a fin de proporcionar valores recomendados para las solicitudes de CPU y memoria, junto con límites que puedes usar a fin de actualizar de forma manual tus Pods. También puedes configurar el ajuste de escala automático vertical de Pods con el fin de actualizar los valores de forma automática.

El ajuste de escala automático vertical de Pods está habilitado de forma predeterminada en clústeres de Autopilot.

Relación con el VerticalPodAutoscaler de código abierto de Kubernetes

El escalado automático vertical de Pods de GKE se basa en la API de código abierto de Kubernetes VerticalPodAutoscaler, pero es una implementación independiente que es exclusiva de GKE. La implementación de GKE está diseñada para escalar con su propio recomendador, pero mantiene los mismos tipos y campos de la API de VerticalPodAutoscaler que se definen en la versión de código abierto.

Para obtener más información, consulta la documentación de Kubernetes sobre el ajuste de escala automático vertical de Pods.

Modos de ajuste de escala automático vertical de Pods

Puedes configurar cómo el escalador automático vertical de Pods aplica los cambios de recursos con diferentes modos de actualización.

Modo Auto (Recreate)

En el modo Recreate, el ajuste de escala automático vertical de Pods expulsa un Pod si necesita cambiar sus solicitudes de recursos. La expulsión es necesaria porque, debido a las limitaciones de Kubernetes en las versiones anteriores a la 1.33, la única forma de modificar las solicitudes de recursos de un Pod en ejecución es volver a crearlo.

Para limitar la cantidad de recreaciones de Pods, usa un presupuesto de interrupción de Pods . Para asegurarte de que tu clúster pueda controlar los tamaños nuevos de las cargas de trabajo, usa el escalador automático de clústeres y el aprovisionamiento automático de nodos.

El ajuste de escala automático vertical del Pod notifica al escalador automático de clústeres antes de la actualización y proporciona los recursos necesarios para el nuevo tamaño de la carga de trabajo antes de volver a crearla, a fin de minimizar el tiempo de interrupción.

Modo Initial

Con Initial habilitado, el ajuste de escala automático vertical de Pods solo asigna solicitudes de recursos en la creación del Pod y nunca las cambia más adelante.

Modo InPlaceOrRecreate

El modo InPlaceOrRecreate tiene como objetivo reducir la interrupción del servicio, ya que intenta actualizar los recursos de Pods sin volver a crearlos.

Para usar el modo InPlaceOrRecreate, establece el campo spec.updatePolicy.updateMode en "InPlaceOrRecreate" en tu objeto VerticalPodAutoscaler. Este modo se basa en el campo resizePolicy definido en el manifiesto de tu carga de trabajo para determinar si un cambio de recurso requiere un reinicio. Si no se define el campo resizePolicy, se establece de forma predeterminada en NotRequired para la CPU y la memoria, lo que significa que se intentan realizar actualizaciones in situ.

Si un contenedor finaliza debido a un evento de OOM (memoria insuficiente), el ajuste de escala automático vertical de Pods en el modo InPlaceOrRecreate actúa de manera similar al modo Auto: aprende de la falla. Cuando se vuelve a crear el Pod después de la falla, el ajuste de escala automático vertical de Pods aplica una recomendación que incluye un búfer de seguridad (por lo general, un 20% de memoria adicional o 100 MB, lo que sea mayor) para evitar que se repita de inmediato el error de OOM.

El modo InPlaceOrRecreate está disponible con la versión 1.34.0-gke.2201000 y posteriores de Kubernetes.

Situaciones de resguardo para el modo InPlaceOrRecreate

Si el escalador automático vertical de Pods determina que no es posible realizar una actualización in situ, recurre al comportamiento del modo Recreate, que expulsa y vuelve a crear el Pod para aplicar los cambios. Algunas situaciones comunes en las que el ajuste de escala automático vertical de Pods recurre a la recreación son las siguientes:

  • Capacidad de nodo insuficiente: La solicitud de recursos actualizada supera la capacidad asignable del nodo actual, y la actualización no se puede programar in situ (estado "no viable" o "aplazado" durante más de un tiempo de espera).
  • Cambio de clase de QoS: La actualización de recursos cambiaría la clase de calidad de servicio (QoS) del Pod, por ejemplo, de Burstable a Guaranteed.
  • Política RestartContainer: El campo resizePolicy del Pod se establece en RestartContainer para un recurso que el ajuste de escala automático vertical de Pods intenta cambiar.
  • Tiempos de espera: Una solicitud de actualización in situ permanece en estado pendiente durante demasiado tiempo.

Modo Off

En el modo Off, el ajuste de escala automático vertical de Pods no aplica automáticamente ningún cambio a un Pod. Aún puedes ver los valores recomendados para las solicitudes y los límites de CPU y memoria según el uso histórico, pero estas recomendaciones no se aplican por ti. Puedes aplicar de forma manual los valores recomendados a tus Pods, si es necesario.

Aumento de CPU en el inicio

El aumento de CPU de inicio acelera el inicio de las aplicaciones y mejora la rentabilidad, ya que aumenta temporalmente las solicitudes de CPU durante la inicialización y las vuelve a ajustar a los niveles de referencia in situ.

Para obtener más información sobre cómo configurar el aumento de CPU en el inicio, consulta Acelera el inicio de la aplicación con el aumento de CPU en el inicio.

Cómo funciona el aumento de CPU de inicio

El aumento de CPU de inicio calcula un aumento temporal de recursos en función de la solicitud de CPU de referencia de tu contenedor. El Pod vuelve a este nivel de solicitud de referencia después de la fase de inicio.

La mejora aumenta esta solicitud de referencia con un multiplicador o una cantidad fija. Esta solicitud elevada permanece activa hasta que el Pod está listo, después de lo cual GKE restablece la solicitud de CPU a su nivel de referencia.

Comprende el ciclo de vida de la potenciación

El proceso de mejora del inicio consta de tres fases:

  1. Fase de admisión: Durante la admisión del Pod, el webhook de admisión del VPA intercepta la solicitud y, luego, inserta los valores de CPU aumentados antes de que GKE programe el Pod.
  2. Fase de inicio: La aplicación se inicializa con la asignación de CPU elevada de forma temporal para evitar la limitación de inicialización.
  3. Fase de reducción de potencia: Después de que el Pod alcanza el estado Ready y transcurre el período de durationSeconds, el VPA reduce la solicitud de CPU in situ al valor base.

Elige un modo de actualización para las cargas de trabajo con aumento

Puedes configurar el aumento de CPU de inicio con o sin la administración continua de recursos del VPA. La administración continua de recursos del VPA ajusta automáticamente las solicitudes de recursos de tus Pods después de que finaliza la fase de inicio. Para elegir tu preferencia, configura el campo updateMode en el objeto de VPA. Para obtener más información sobre los modos de actualización del VPA, consulta Modos de escalado automático vertical de Pods.

  • updateMode: "Off": El VPA administra solo el aumento inicial durante la admisión del Pod (una fase en la creación del Pod) y la reducción de escala posterior después del inicio. No modifica las solicitudes de recursos de estado estable de tu contenedor.
  • updateMode: "Auto", "Recreate" o "InPlaceOrRecreate": El VPA administra el aumento de inicio y sigue ajustando las solicitudes de recursos del Pod de forma automática según su uso continuo.

Cómo se calcula la asignación de recursos de la mejora de CPU

GKE calcula la solicitud de CPU con aumento temporal de la siguiente manera:

  1. Determina la CPU base: La solicitud de CPU de referencia depende del campo updateMode del VPA:

    • Auto, Recreate o InPlaceOrRecreate: la solicitud de CPU de referencia es la recomendación del VPA. Si no existe ninguna recomendación, GKE recurre a la solicitud de CPU definida en la especificación del Pod.
    • Off: La solicitud de CPU de referencia es el valor de la solicitud de la especificación del Pod.
  2. Calcula la CPU potenciada: El cálculo depende del método de cálculo que especifiques en el campo type de la configuración de potenciación:

    • Factor: Aplica un multiplicador a la solicitud de CPU base:

      CPU aumentada  =  CPU base × factor

    • Quantity: Agrega una cantidad absoluta de CPU a la solicitud de CPU base:

      CPU aumentada  =  CPU base + quantity

La solicitud de CPU final depende del modo de clúster:

  • Clústeres de Standard: la solicitud de CPU final es el valor de CPU potenciado.
  • Clústeres de Autopilot: La solicitud de CPU final es el valor de CPU mejorado, limitado por la CPU máxima permitida para la memoria del Pod asignada.

Comprende el comportamiento del límite de CPU durante un aumento

La forma en que GKE controla los límites de CPU depende de la configuración de controlledValues en tu containerResourcePolicy:

  • RequestsAndLimits (predeterminado): GKE aumenta la solicitud y el límite de CPU, y mantiene su proporción original para preservar la clase de calidad de servicio (QoS) del contenedor.
  • RequestsOnly: GKE solo aumenta la solicitud de CPU. GKE limita la solicitud de aumento justo por debajo de cualquier límite de CPU definido para preservar la QoS.

Consideraciones para los clústeres de Autopilot

Debido a que GKE Autopilot aplica rangos específicos de proporción de CPU a memoria y tamaños mínimos de Pods, GKE evalúa los aumentos durante la admisión de Pods para garantizar el cumplimiento. Un aumento se puede modificar o ignorar en las siguientes situaciones:

  • Mínimos de Autopilot: Si la solicitud de aumento es inferior a los requisitos mínimos de CPU para las cargas de trabajo de Autopilot (por ejemplo, 50m para los Pods de uso general), GKE no aplica el aumento y aplica los mínimos estándar.
  • Limitación de la proporción (mejoras parciales o omitidas): Si la solicitud de CPU mejorada supera el rango de proporción de CPU a memoria requerido, GKE limita la mejora al valor más alto que respete la memoria asignada. Si la solicitud original del Pod ya usa la proporción máxima permitida de CPU a memoria, GKE omite el aumento para evitar el cambio de tamaño de la memoria.
  • ComputeClass de escalamiento horizontal: la ComputeClass de escalamiento horizontal aplica una proporción estricta de 1:4 (CPU:memoria). Si intentas aumentar la CPU en un Pod de escalamiento horizontal sin aumentar su memoria, es posible que GKE ignore el aumento.

Políticas de recursos

Puedes usar ContainerResourcePolicy para personalizar la forma en que el ajuste de escala automático vertical de Pods genera recomendaciones para contenedores específicos. Esta política te permite establecer restricciones y controlar qué recursos se escalan.

Límites mínimos y máximos

Puedes especificar los valores de recursos mínimos (minAllowed) y máximos (maxAllowed) para un contenedor.

  • minAllowed: El ajuste de escala automático vertical de Pods no recomendará un valor inferior a este límite. Este límite es útil porque ayuda a garantizar un nivel de rendimiento de referencia o a cumplir con los requisitos específicos de la aplicación.
  • maxAllowed: El escalador automático vertical de Pods no recomendará un valor superior a este límite. Este límite es útil para controlar los costos o evitar que un solo contenedor consuma demasiados recursos del nodo.

Recursos controlados

De forma predeterminada, el ajuste de escala automático vertical de Pods calcula las recomendaciones para la CPU y la memoria. Puedes usar el campo controlledResources para especificar qué recursos se deben escalar automáticamente. Por ejemplo, puedes configurar el escalador automático para que proporcione recomendaciones solo para la memoria, sin modificar las solicitudes de CPU.

Limitaciones

  • Para usar el escalado automático vertical de Pods con el escalado automático horizontal de Pods en la CPU, usa el ajuste de tamaño de HPA con VPA (versión preliminar) o el escalado automático multidimensional de Pods. También puedes usar el escalado automático vertical de Pods con el escalado automático horizontal de Pods en métricas personalizadas y externas.
  • El ajuste de escala automático vertical de Pods aún no está listo para usarse con cargas de trabajo basadas en JVM debido a la visibilidad limitada del uso de memoria real de la carga de trabajo.
  • En la versión 1.35.1 y anteriores de GKE, el Ajuste de escala automático vertical de Pods tiene una configuración predeterminada de dos réplicas mínimas para que los Deployments reemplacen a los Pods con valores de recursos revisados. En la versión 1.35.2 y posteriores, el valor predeterminado es una réplica mínima. En la versión 1.22 y las posteriores, puedes anular esta configuración si especificas un valor para el campo minReplicas en el campo PodUpdatePolicy.
  • Si usas el modo de actualización InPlaceOrRecreate del ajuste de escala automático vertical de Pods y no es posible realizar una actualización in situ (por ejemplo, cuando se escala verticalmente el Pod más allá de la capacidad del nodo), el ajuste de escala automático vertical de Pods desaloja y vuelve a crear el Pod para aplicar la recomendación. La expulsión y la recreación se producen incluso para los Pods que tienen un campo resizePolicy establecido en su especificación para evitar recreaciones. Este comportamiento se produce para las solicitudes de cambio de tamaño de Autopilot, incluso cuando se aplican restricciones de recursos mínimos y de proporción de CPU:memoria.
  • El Ajuste de escala automático vertical de Pods requiere un objeto de carga de trabajo que administre los Pods, como un Deployment, un StatefulSet, un ReplicaSet o un ReplicationController. No puedes usar el ajuste de escala automático vertical de Pods con Pods independientes, ya que se requiere un controlador de cargas de trabajo para administrar el proceso de recreación de Pods.
  • El Ajuste de escala automático vertical de Pods genera recomendaciones y aplica actualizaciones solo en las solicitudes y los límites de recursos a nivel de contenedor (spec.containers[].resources). El Ajuste de escala automático vertical de Pods no admite las especificaciones de recursos a nivel de Pod (spec.resources).

Prácticas recomendadas

  • Limita la cantidad de objetos VerticalPodAutoscaler. Para evitar interrupciones de la actualización del clúster, debes mantener la cantidad de objetos VerticalPodAutoscaler por clúster por debajo de 1,000.
  • El ajuste de escala automático vertical de Pods funciona mejor con cargas de trabajo homogéneas de larga duración.
    • De larga duración: Son cargas de trabajo que se ejecutan durante, al menos, 24 horas. El escalado automático vertical de Pods requiere una cantidad significativa de datos históricos para generar recomendaciones de alta confianza. En el modo Auto o Recreate, las actualizaciones suelen ocurrir después de que un Pod tiene al menos 24 horas de antigüedad, lo que ayuda a evitar reinicios frecuentes y deserción de Pods.
    • Homogéneos: Los Pods a los que se orienta un solo objeto VerticalPodAutoscaler (como todas las réplicas de un Deployment) deben mostrar patrones de consumo de recursos similares. El Vertical Pod Autoscaler genera recomendaciones agregando datos de uso de todos los Pods de destino. Si tus réplicas tienen un uso heterogéneo, por ejemplo, algunos Pods están inactivos y otros tienen una carga pesada, el Vertical Pod Autoscaler puede proporcionar una recomendación que aprovisione en exceso los Pods inactivos o que aprovisione de forma insuficiente los que están ocupados.
  • Usa el escalado automático horizontal de Pods para cargas de trabajo con aumentos repentinos de la demanda. El ajuste de escala automático vertical de Pods está diseñado para ajustar el tamaño de estado estable y no es una solución para los aumentos repentinos y de corta duración de los recursos. En el caso de las cargas de trabajo con fluctuaciones rápidas en el tráfico o la demanda de CPU o memoria, usa el escalador automático horizontal de Pods en su lugar.
  • Aprovecha la protección contra OOM. Aunque el Vertical Pod Autoscaler es reactivo, incluye protección automatizada contra eventos de falta de memoria (OOM). Si un Pod tiene el estado OOMKilled, el Vertical Pod Autoscaler observa el evento de inmediato y aumenta la recomendación de memoria en un 20% aproximadamente (o 100 MB, lo que sea mayor) para mejorar la estabilidad cuando se vuelve a crear el Pod. Para obtener más información sobre los eventos de OOM, consulta Soluciona problemas relacionados con eventos de OOM.

Referencia de la API

Esta es la referencia de la API de v1. Recomendamos enfáticamente usar esta versión de la API.

VerticalPodAutoscaler v1 autoscaling.k8s.io

Campos

TypeMeta

Grupo de API, versión y tipo

metadata

ObjectMeta

Metadatos de objeto estándar

spec

VerticalPodAutoscalerSpec

Es el comportamiento de VerticalPodAutoscaler.

status

VerticalPodAutoscalerStatus

El estado más reciente del VerticalPodAutoscaler.

VerticalPodAutoscalerSpec v1 autoscaling.k8s.io

Campos
targetRef

CrossVersionObjectReference

Referencia al controlador que administra el conjunto de Pods que el escalador automático debe controlar, por ejemplo, un objeto Deployment o StatefulSet. Puedes apuntar un VerticalPodAutoscaler a cualquier controlador que tenga un subrecurso Scale. Por lo general, el VerticalPodAutoscaler recupera el conjunto de pods desde el ScaleStatus del controlador. En algunos controladores conocidos, como DaemonSet, el VerticalPodAutoscaler recupera el conjunto de pods desde las especificaciones del controlador.

updatePolicy

PodUpdatePolicy

Especifica si se aplican las actualizaciones recomendadas cuando se inicia un pod, y si las actualizaciones recomendadas se aplican durante la vida útil del pod.

resourcePolicy

PodResourcePolicy

Especifica las políticas sobre cómo se ajustan los requisitos de CPU y memoria para los contenedores individuales. La política de recursos se puede usar para establecer restricciones en las recomendaciones de contenedores individuales. Si no se especifica, el escalador automático procesa los recursos recomendados para todos los contenedores en el Pod, sin restricciones adicionales.

recommenders

VerticalPodAutoscalerRecommenderSelector array

Es el recomendador responsable de generar recomendaciones para este objeto del VPA. Deja el campo en blanco para usar el recomendador predeterminado que proporciona GKE. De lo contrario, la lista puede contener exactamente una entrada para un recomendador alternativo proporcionado por el usuario. Compatible desde GKE 1.22.

VerticalPodAutoscalerList v1 autoscaling.k8s.io

Campos

TypeMeta

Grupo de API, versión y tipo

metadata

ObjectMeta

Metadatos de objeto estándar

items

VerticalPodAutoscaler array

Una lista de objetos VerticalPodAutoscaler.

PodUpdatePolicy v1 autoscaling.k8s.io

Campos
updateMode

string

Especifica si se aplican las actualizaciones recomendadas cuando se inicia un pod, y si las actualizaciones recomendadas se aplican durante la vida útil del pod. Los valores posibles son los siguientes:

  • "Off": Se generan actualizaciones recomendadas, pero no se aplican automáticamente al Pod.
  • "Initial": Las actualizaciones recomendadas se aplican solo cuando se inicia un Pod por primera vez. Las actualizaciones que se producen mientras el Pod ya se está ejecutando no se aplican automáticamente.
  • "Recreate": Las actualizaciones recomendadas se aplican volviendo a crear el Pod. Se finaliza el Pod existente y se crea uno nuevo con la configuración actualizada.
  • "Auto": Es el valor predeterminado que, en esencia, aplica el modo "Recreate".
  • "InPlaceOrRecreate": Las actualizaciones recomendadas se aplican sin volver a crear el Pod, si es posible.
minReplicas

int32

Es la cantidad mínima de réplicas que deben estar activas para intentar la expulsión del Pod (pendientes de otras verificaciones, como el presupuesto de interrupción del Pod). Solo se permiten valores positivos. El valor predeterminado es 1 en la versión 1.35.2 y posteriores de GKE, y 2 en la versión 1.35.1 y anteriores. Compatible desde GKE 1.22.

PodResourcePolicy v1 autoscaling.k8s.io

Campos
containerPolicies

ContainerResourcePolicy array

Un arreglo de políticas de recursos para contenedores individuales Puede haber, como máximo, una entrada para cada contenedor con nombre y, opcionalmente, una entrada de comodín única con “containerName = "*"”, que maneje todos los contenedores que no tienen políticas individuales.

ContainerResourcePolicy v1 autoscaling.k8s.io

Campos
containerName

string

El nombre del contenedor al cual se aplica la política. Si no se especifica, la política se usa como política predeterminada.

mode

ContainerScalingMode

Especifica si se aplican las actualizaciones recomendadas cuando se inicia un contenedor, y si las actualizaciones recomendadas se aplican durante la vida útil del contenedor. Los valores posibles son “Apagado” o “Auto”. El valor predeterminado es "Auto" si no especificas un valor.

minAllowed

ResourceList

Especifica los requisitos de CPU y memoria mínimos que se permiten para el contenedor. De forma predeterminada, no hay un valor mínimo aplicado.

maxAllowed

ResourceList

Especifica los requisitos de CPU y memoria máximos permitidos para el contenedor. De forma predeterminada, no hay un valor máximo aplicado.

controlledResources

[]ResourceName

Especifica el tipo de recomendaciones que procesará (y que probablemente aplicará) el VerticalPodAutoscaler. Si está vacío, se usa el valor predeterminado [ResourceCPU, ResourceMemory].

VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io

Campos
name

string

Nombre del recomendador responsable de generar recomendaciones para este objeto.

VerticalPodAutoscalerStatus v1 autoscaling.k8s.io

Campos
recommendation

RecommendedPodResources

Los requisitos de CPU y memoria recomendados más recientes

conditions

VerticalPodAutoscalerCondition array

Describe el estado actual del VerticalPodAutoscaler.

RecommendedPodResources v1 autoscaling.k8s.io

Campos
containerRecommendations

RecommendedContainerResources array

Un arreglo de recomendaciones de recursos para contenedores individuales

RecommendedContainerResources v1 autoscaling.k8s.io

Campos
containerName

string

El nombre del contenedor al cual se aplica la recomendación.

target

ResourceList

Los requisitos de CPU y memoria recomendados para el contenedor.

lowerBound

ResourceList

Los requisitos de CPU y memoria mínimos recomendados para el contenedor. No se garantiza que esta cantidad sea suficiente para que la aplicación permanezca estable. Es probable que la ejecución con menos requisitos de CPU y memoria tenga un impacto considerable en el rendimiento o la disponibilidad.

upperBound

ResourceList

Los requisitos de CPU y memoria máximos recomendados para el contenedor. Es probable que los requisitos de CPU y memoria que superen estos valores se desperdicien.

uncappedTarget

ResourceList

La recomendación de recursos más reciente que procesó el escalador automático, en función del uso real de recursos y sin tener en cuenta la ContainerResourcePolicy. Si el uso real de recursos hace que el objetivo incumpla la ContainerResourcePolicy, este valor podría ser diferente de la recomendación limitada. Este campo no afecta la asignación real de recursos. Solo se usa como indicador de estado.

VerticalPodAutoscalerCondition v1 autoscaling.k8s.io

Campos
type

VerticalPodAutoscalerConditionType

El tipo de condición que se describe. Los valores posibles son “RecommendationProvided”, “LowConfidence”, “NoPodsMatched” y “FetchingHistory”.

status

ConditionStatus

El estado de la condición. Los posibles valores son Verdadero, Falso y Desconocido.

lastTransitionTime

Time

La última vez que la condición hizo una transición de un estado a otro.

reason

string

La razón por la cual se realizó la última transición de un estado a otro.

message

string

Es una cadena legible por humanos que proporciona detalles sobre la última transición de un estado a otro.

¿Qué sigue?