Ajuste de escala automático vertical de Pods

Autopilot estándar

En esta página, se explica cómo puedes analizar y optimizar la asignación de recursos para mejorar la eficiencia de tu carga 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 y los límites de CPU y memoria 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ás 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 ajuste de escala de las 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 necesidades de ajuste de escala rápido en respuesta a un uso repentino de recursos, usa el escalador automático de Pods horizontal.

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 ajuste de escala automático vertical de Pods

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

• Configurar los requisitos y 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 las solicitudes 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 que habilitaras 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 ajuste de escala automático vertical de Pods de GKE se basa en la API de VerticalPodAutoscaler de Kubernetes de código abierto, 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 del ajuste de escala automático vertical de Pods

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

Modo Auto (Recreate)

Nota: Los modos Recreate y Auto usan el mismo comportamiento. El modo de actualización Auto es el modo predeterminado si no se especifica el campo updateMode en el objeto VerticalPodAutoscaler.

En el modo Recreate, el ajuste de escala automático vertical de Pods expulsa un Pod si necesita cambiar sus solicitudes de recursos. El desalojo es necesario porque, debido a las limitaciones de Kubernetes en 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

Vista previa

Esta función está sujeta a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles “sin modificaciones” y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

El modo InPlaceOrRecreate tiene como objetivo reducir las interrupciones del servicio intentando actualizar los recursos del Pod sin volver a crearlo.

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 la carga de trabajo para determinar si un cambio de recurso requiere un reinicio. Si no se define el campo resizePolicy, el valor predeterminado es NotRequired para la CPU y la memoria, lo que significa que se intentarán actualizaciones in situ.

Si un contenedor finaliza debido a un evento de OOM (falta de memoria), el ajuste de escala automático vertical de Pods en el modo InPlaceOrRecreate actúa de manera similar al modo Auto: aprende del error. 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 la repetición inmediata del error de OOM.

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

Situaciones de resguardo para el modo InPlaceOrRecreate

Si el ajuste de escala 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. Algunos casos comunes en los que el ajuste de escala automático vertical de Pods recurre a la recreación incluyen los 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 en el lugar (estado "infeasible" o "diferido" durante más de un tiempo de espera).
• Cambio de clase de QoS: La actualización del recurso cambiaría la clase de Calidad de servicio (QoS) del Pod, por ejemplo, de Burstable a Guaranteed.
• Política de 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 agotados: 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 ningún cambio a un Pod de forma automática. Aún puedes ver los valores recomendados para las solicitudes y los límites de la CPU y la memoria según el uso histórico, pero estas recomendaciones no se aplican automáticamente. Si es necesario, puedes aplicar manualmente los valores recomendados a tus Pods.

Aumento de CPU en el inicio

El aumento de CPU de inicio acelera el inicio de la aplicación y mejora la eficiencia en los costos, ya que aumenta temporalmente las solicitudes de CPU durante la inicialización y las vuelve a ajustar a los niveles de referencia de forma local.

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

Cómo funciona el aumento de la CPU de inicio

El aumento de inicio de CPU calcula un incremento 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.

El aumento incrementa 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 del aumento

El proceso de aceleración de 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 temporalmente para evitar la limitación de la inicialización.
3. Fase de reducción: Después de que el Pod alcanza el estado Ready y transcurre el período durationSeconds, el VPA reduce la solicitud de CPU en el lugar al valor base.

Nota: El actualizador de VPA verifica el estado del Pod en un ciclo regular de un minuto para controlar la eliminación del aumento. Debido a esta evaluación periódica, GKE mide el período de durationSeconds en intervalos de un minuto, lo que significa que un aumento podría persistir hasta un minuto más de lo configurado.

Elige un modo de actualización para las cargas de trabajo potenciadas

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 tu Pod después de que finaliza la fase de inicio. Para elegir tu preferencia, configura el campo updateMode en el objeto VPA. Para obtener más información sobre los modos de actualización del VPA, consulta Modos del ajuste de escala automático vertical de Pods.

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

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

GKE calcula la solicitud de CPU temporal mejorada 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 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 final de CPU depende del modo del clúster:

• Clústeres estándar: La solicitud final de CPU es el valor de CPU aumentado.
• Clústeres de Autopilot: La solicitud final de CPU es el valor de CPU aumentado, limitado por la CPU máxima permitida para la memoria del Pod asignado.

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

La forma en que GKE controla los límites de CPU depende del parámetro de configuración 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 amplificada justo por debajo de cualquier límite de CPU definido para preservar la QoS.

Consideraciones para los clústeres de Autopilot

Dado que GKE Autopilot aplica rangos específicos de relación entre CPU y memoria, y tamaños mínimos de Pod, GKE evalúa los aumentos durante la admisión de Pods para garantizar el cumplimiento. Es posible que se modifique o ignore un refuerzo en las siguientes situaciones:

• Mínimos de Autopilot: Si la solicitud potenciada está por debajo de los requisitos mínimos de CPU para las cargas de trabajo de Autopilot (por ejemplo, 50 m para los Pods de uso general), GKE no aplica el aumento y aplica los mínimos estándar.
• Limitación de la proporción (aumentos parciales o omitidos): Si la solicitud de CPU aumentada supera el rango de proporción de CPU a memoria requerido, GKE limita el aumento al valor más alto que respeta 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.
• Clase de procesamiento de escalamiento horizontal: La clase de procesamiento de escalamiento horizontal aplica una proporción estricta de 1:4 (CPU:memoria). Si intentas aumentar la CPU en un pod de expansión sin aumentar su memoria, es posible que GKE ignore el aumento.

Práctica recomendada: Para las cargas de trabajo de Autopilot, asegúrate de asignar suficiente memoria base en la especificación del Pod para admitir la proporción de CPU aumentada. Si dependes del aumento de velocidad de inicio, evita usar la clase de procesamiento Scale-Out.

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 ajustan.

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 básico o el cumplimiento de los requisitos específicos de la aplicación.
• maxAllowed: El ajuste de escala 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 recomendaciones para la CPU y la memoria. Puedes usar el campo controlledResources para especificar qué recursos se deben ajustar automáticamente. Por ejemplo, puedes configurar el escalador automático para que proporcione recomendaciones solo para la memoria y deje sin cambios las solicitudes de CPU.

Limitaciones

• Para usar el ajuste de escala automático vertical de Pods con ajuste de escala automático horizontal de Pods, usa el Ajuste de escala automático multidimensional de Pods. También puedes usar el ajuste de escala automático vertical de Pods con ajuste de escala 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 objetos Deployment 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 en las posteriores, puedes anular este parámetro de 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 aumenta la escala del Pod más allá de la capacidad del nodo), el ajuste de escala automático vertical de Pods expulsa 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 la recreación. 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, StatefulSet, ReplicaSet o ReplicationController. No puedes usar el ajuste de escala automático vertical de Pods con Pods independientes porque se requiere un controlador de carga de trabajo para administrar el proceso de recreación de Pods.

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: Cargas de trabajo que se ejecutan durante al menos 24 horas. El ajuste de escala automático vertical de Pods requiere una cantidad significativa de datos históricos para generar recomendaciones con un alto nivel de confianza. En el modo Auto o Recreate, las actualizaciones suelen ocurrir después de que un Pod tiene al menos 24 horas, lo que ayuda a evitar los reinicios frecuentes de Pods y la rotación.
  • Homogéneos: Los Pods segmentados por un solo objeto VerticalPodAutoscaler (como todas las réplicas en una Deployment) deben mostrar patrones de consumo de recursos similares. El ajuste de escala automático vertical de Pods genera recomendaciones agregando datos de uso en todos los Pods objetivo. Si tus réplicas tienen un uso heterogéneo (por ejemplo, algunos Pods están inactivos y otros están muy cargados), el escalador automático vertical de Pods puede proporcionar una recomendación que aprovisione en exceso los Pods inactivos o que aprovisione de forma insuficiente los Pods ocupados.
• Usa el ajuste de escala automático horizontal de Pods para cargas de trabajo con aumentos repentinos en la demanda. El ajuste de escala automático vertical de Pods está diseñado para el ajuste de tamaño adecuado en estado estable y no es una solución para los picos repentinos y de corta duración en el uso de recursos. Para las cargas de trabajo con fluctuaciones rápidas en el tráfico o la demanda de CPU o memoria, usa el ajuste de escala automático horizontal de Pods.
• Aprovecha la protección contra errores de memoria. Si bien el escalador automático vertical de Pods es reactivo, incluye protección automática contra eventos de memoria insuficiente (OOM). Si un Pod es OOMKilled, el escalador automático vertical de Pods observa de inmediato el evento y aumenta la recomendación de memoria en aproximadamente un 20% (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 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 solo se aplican cuando se inicia un Pod por primera vez. Las actualizaciones que se producen mientras el Pod ya está en ejecución no se aplican automáticamente. "Recreate": Las actualizaciones recomendadas se aplican recreando el Pod. Se finaliza el Pod existente y se crea uno nuevo con la configuración actualizada. "Auto": Es el valor predeterminado que, básicamente, 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 (pendiente 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 los recursos hace que el objetivo viole 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 Una cadena legible que proporciona detalles sobre la última transición de un estado a otro.

¿Qué sigue?

• Obtén más información para configurar el ajuste de escala automático vertical de Pods.
• Obtén más información para acelerar el inicio de la aplicación con el aumento de la CPU de inicio.
• Obtén más información sobre el ajuste automático de escala horizontal de Pods.
• Obtén más información sobre el escalador automático de clústeres.