Escalonamento automático do pod vertical

Autopilot Standard

Nesta página, explicamos como analisar e otimizar a alocação de recursos para melhorar a eficiência da carga de trabalho no Google Kubernetes Engine (GKE) usando o escalonamento automático vertical de pods. Ao analisar o uso de recursos da carga de trabalho ao longo do tempo, é possível receber recomendações de otimização e ajustar automaticamente as solicitações de CPU e memória, além de limites para contêineres nos pods.

Nesta página, você vai aprender como o escalonamento automático vertical de pods funciona, os benefícios e as limitações dele, as práticas recomendadas para usá-lo e acessar as referências da API para o recurso personalizado VerticalPodAutoscaler e os tipos relacionados.

Esta página é destinada a operadores e desenvolvedores que provisionam e configuram recursos de nuvem, implantam cargas de trabalho e gerenciam o escalonamento de aplicativos. Para saber mais sobre papéis comuns, consulte Tarefas e papéis de usuário comuns do GKE.

Antes de ler esta página, você precisa ter familiaridade com as solicitações e os limites de recursos no Kubernetes.

Para necessidades de escalonamento rápido em resposta ao uso repentino de recursos, use o Autoescalonador Horizontal de Pods.

Para conhecer as práticas recomendadas de escalonamento automático, consulte Práticas recomendadas para executar aplicativos econômicos do Kubernetes no GKE.

Por que usar o escalonamento automático vertical de pods

O escalonamento automático vertical de pods oferece os seguintes benefícios:

• Definir as solicitações e os limites de recursos certos para suas cargas de trabalho melhora a estabilidade e a eficiência de custos. Se os tamanhos dos recursos do pod forem menores do que as cargas de trabalho, o aplicativo poderá ser limitado ou falhar devido a erros de falta de memória. Se os tamanhos dos recursos forem muito grandes, você terá resíduos e, portanto, contas maiores.
• Os nós de cluster são usados de forma eficiente, porque os pods usam exatamente o que precisam.
• Os pods são programados em nós que têm os recursos apropriados disponíveis.
• Você não precisa executar tarefas de benchmark demoradas para determinar os valores corretos de solicitações de CPU e memória.
• É possível reduzir o tempo de manutenção porque o escalonador automático pode ajustar as solicitações de CPU e memória ao longo do tempo sem nenhuma ação da sua parte.
• O escalonamento automático vertical de pods funciona melhor com cargas de trabalho homogêneas de longa duração.

O escalonamento automático vertical de pods do GKE oferece os seguintes benefícios em relação ao escalonador automático de código aberto do Kubernetes:

• Considera o tamanho máximo do nó e as cotas de recursos ao determinar a meta de recomendação.
• Notifica o escalonador automático de cluster para ajustar a capacidade do cluster.
• Usa dados históricos, incluindo métricas coletadas antes da ativação do VerticalPodAutoscaler.
• Executa os pods do VerticalPodAutoscaler como processos do plano de controle, em vez de implantações nos seus nós de trabalho.

Como funciona o escalonamento automático vertical de pods

O escalonamento automático vertical de pods permite analisar e definir recursos de CPU e memória exigidos pelos pods. Em vez de ter que configurar solicitações e limites de CPU atualizados e solicitações e limites de memória para os contêineres do seu pods, configure o escalonamento automático vertical de pods para fornecer valores recomendados para solicitações e limites de CPU e memória que podem ser usados para atualizar manualmente seus pods, ou configurar o escalonamento automático vertical de pods para atualizar automaticamente os valores. de dados.

O escalonamento automático vertical de pods é ativado por padrão nos clusters do Autopilot.

Relação com o VerticalPodAutoscaler de código aberto do Kubernetes

O escalonamento automático vertical de pods do GKE é baseado na API de código aberto do Kubernetes VerticalPodAutoscaler, mas é uma implementação separada e exclusiva do GKE. A implementação do GKE foi projetada para escalonamento com o próprio recomendador, mas mantém os mesmos tipos e campos da API VerticalPodAutoscaler definidos na versão de código aberto.

Para mais informações, consulte a documentação do Kubernetes sobre o escalonamento automático vertical de pods.

Modos de escalonamento automático vertical de pods

É possível configurar como o escalonamento automático vertical de pods aplica as mudanças de recursos usando diferentes modos de atualização.

Modo Auto (Recreate)

Observação: os modos Recreate e Auto usam o mesmo comportamento. O modo de atualização Auto é o padrão se o campo updateMode não for especificado no objeto VerticalPodAutoscaler.

No modo Recreate, o escalonamento automático vertical de pods remove um pod se precisar alterar as solicitações de recurso dele. A remoção é necessária porque, devido às limitações do Kubernetes em versões anteriores à 1.33, a única maneira de modificar as solicitações de recursos de um pod em execução é recriá-lo.

Para limitar a quantidade de recriações de pods, use um orçamento de interrupção de pods . Para garantir que o cluster possa lidar com os novos tamanhos das cargas de trabalho, use o Escalonador automático de clusters e o Provisionamento automático de nós.

O escalonamento automático vertical de pods notifica o escalonador automático de cluster antes da atualização e fornece os recursos necessários para a carga de trabalho redimensionada antes de recriá-la para minimizar o tempo de interrupção.

Modo Initial

Com o Initial ativado, o escalonamento automático vertical de pods atribui solicitações de recursos apenas na criação do pod e nunca as altera posteriormente.

Modo InPlaceOrRecreate

Visualizar

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

O modo InPlaceOrRecreate visa reduzir a interrupção do serviço ao tentar atualizar os recursos do pod sem recriá-lo.

Para usar o modo InPlaceOrRecreate, defina o campo spec.updatePolicy.updateMode como "InPlaceOrRecreate" no objeto VerticalPodAutoscaler. Esse modo depende do campo resizePolicy definido no manifesto da carga de trabalho para determinar se uma mudança de recurso requer uma reinicialização. Se o campo resizePolicy não estiver definido, o padrão será NotRequired para CPU e memória, o que significa que as atualizações no local serão tentadas.

Se um contêiner for encerrado devido a um evento de OOM (memória insuficiente), o escalonamento automático vertical de pods no modo InPlaceOrRecreate vai agir de maneira semelhante ao modo Auto: ele vai aprender com a falha. Após a recriação do pod acionada pela falha, o escalonamento automático vertical de pods aplica uma recomendação que inclui um buffer de segurança (normalmente 20% de memória adicional ou 100 MB, o que for maior) para evitar a repetição imediata do erro de OOM.

O modo InPlaceOrRecreate está disponível com a versão 1.34.0-gke.2201000 e posteriores do Kubernetes.

Cenários de substituição para o modo InPlaceOrRecreate

Se o escalonamento automático vertical de pods determinar que uma atualização no local não é possível, ele vai voltar ao comportamento do modo Recreate, que remove e recria o pod para aplicar as mudanças. Alguns cenários comuns em que o escalonamento automático vertical de pods recorre à recriação incluem:

• Capacidade insuficiente do nó:a solicitação de recurso atualizada excede a capacidade alocável do nó atual, e a atualização não pode ser programada no local (estado "inviável" ou "adiado" por mais tempo do que um tempo limite).
• Mudança na classe de QoS:a atualização do recurso mudaria a classe de qualidade de serviço (QoS) do pod, por exemplo, de Burstable para Guaranteed.
• Política RestartContainer:o campo resizePolicy do pod é definido como RestartContainer para um recurso que o escalonamento automático vertical de pods está tentando mudar.
• Tempos limite:uma solicitação de atualização no local permanece em estado pendente por muito tempo.

Modo Off

No modo Off, o escalonamento automático vertical de pods não aplica automaticamente nenhuma alteração a um pod. Ainda é possível ver os valores recomendados para as solicitações e os limites de CPU e memória com base no uso histórico, mas essas recomendações não são aplicadas para você. Se necessário, é possível aplicar manualmente os valores recomendados aos pods.

Otimização da CPU de inicialização

A otimização de inicialização da CPU acelera a inicialização do aplicativo e melhora a eficiência de custos ao aumentar temporariamente as solicitações de CPU durante a inicialização e redimensioná-las de volta aos níveis de referência no local.

Para mais informações sobre como configurar a otimização de inicialização da CPU, consulte Acelerar a inicialização do aplicativo com a otimização de inicialização da CPU.

Como funciona a otimização de inicialização da CPU

A otimização de inicialização da CPU calcula um aumento temporário de recursos com base na solicitação de CPU de referência do contêiner. O pod retorna a esse nível de solicitação de referência após a fase de inicialização.

O aumento aumenta essa solicitação de referência por um multiplicador ou uma quantidade fixa. Essa solicitação elevada permanece ativa até que o pod esteja pronto. Depois disso, o GKE restaura a solicitação de CPU para o nível de referência.

Entender o ciclo de vida do boost

O processo de otimização de inicialização consiste em três fases:

1. Fase de admissão: durante a admissão do pod, o webhook de admissão do VPA intercepta a solicitação e injeta os valores de CPU otimizados antes que o GKE programe o pod.
2. Fase de inicialização: o aplicativo é inicializado usando a alocação de CPU temporariamente elevada para evitar a limitação de inicialização.
3. Fase de redução: depois que o pod atinge o status Ready e o período durationSeconds passa, o VPA reduz a solicitação de CPU no local para o valor base.

Observação: o atualizador do VPA verifica o status do pod em um ciclo regular de um minuto para lidar com a remoção do aumento. Devido a essa avaliação periódica, o GKE mede o período durationSeconds em intervalos de um minuto, o que significa que um aumento pode persistir por até um minuto a mais do que o configurado.

Escolher um modo de atualização para cargas de trabalho otimizadas

É possível configurar a otimização de inicialização da CPU com ou sem o gerenciamento contínuo de recursos do VPA. O gerenciamento contínuo de recursos do VPA ajusta automaticamente as solicitações de recursos do pod após o término da fase de inicialização. Para escolher sua preferência, defina o campo updateMode no objeto VPA. Para mais informações sobre os modos de atualização do VPA, consulte Modos de escalonamento automático vertical de pods.

• updateMode: "Off": o VPA gerencia apenas o aumento inicial durante a admissão do pod (uma fase na criação do pod) e a redução subsequente após a inicialização. Ele não modifica as solicitações de recursos de estado estável do contêiner.
• updateMode: "Auto", "Recreate" ou "InPlaceOrRecreate": o VPA gerencia a otimização de inicialização e continua ajustando as solicitações de recursos do pod automaticamente com base no uso contínuo.

Como a alocação de recursos da otimização de CPU é calculada

O GKE calcula a solicitação de CPU temporariamente otimizada da seguinte maneira:

1. Determine a CPU de base: a solicitação de CPU de base depende do campo updateMode do VPA:

   • Auto, Recreate ou InPlaceOrRecreate: a solicitação de CPU de referência é a recomendação do VPA. Se não houver recomendação, o GKE vai usar a solicitação de CPU definida na especificação do pod.
   • Off: a solicitação de CPU de referência é o valor da solicitação da especificação do pod.

2. Calcular a CPU otimizada: o cálculo depende do método especificado no campo type da configuração de otimização:

   • Factor: aplica um multiplicador à solicitação de CPU base:

     CPU otimizada  =  CPU base  ×  factor

   • Quantity: adiciona uma quantidade absoluta de CPU à solicitação de CPU base:

     CPU otimizada  =  CPU base  +  quantity

A solicitação final de CPU depende do modo do cluster:

• Clusters padrão: a solicitação final de CPU é o valor de CPU otimizado.
• Clusters do Autopilot: a solicitação final de CPU é o valor de CPU otimizado, limitado pela CPU máxima permitida para a memória do pod alocada.

Entender o comportamento do limite de CPU durante uma otimização

A maneira como o GKE lida com os limites de CPU depende da configuração controlledValues no containerResourcePolicy:

• RequestsAndLimits (padrão): o GKE aumenta a solicitação e o limite de CPU, mantendo a proporção original para preservar a classe de qualidade de serviço (QoS) do contêiner.
• RequestsOnly: o GKE aumenta apenas a solicitação de CPU. O GKE limita a solicitação otimizada logo abaixo de qualquer limite de CPU definido para preservar a QoS.

Considerações sobre clusters do Autopilot

Como o GKE Autopilot impõe intervalos específicos de proporção de CPU para memória e tamanhos mínimos de pod, o GKE avalia os aumentos durante a admissão do pod para garantir a conformidade. Uma otimização pode ser modificada ou ignorada nos seguintes cenários:

• Mínimos do Autopilot: se a solicitação otimizada estiver abaixo dos requisitos mínimos de CPU para cargas de trabalho do Autopilot (por exemplo, 50m para pods de uso geral), o GKE não aplicará a otimização e aplicará os mínimos padrão.
• Limite de proporção (otimizações parciais ou ignoradas): se a solicitação de CPU otimizada exceder o intervalo de proporção de CPU para memória necessário, o GKE vai limitar a otimização ao valor mais alto que respeita a memória alocada. Se a solicitação original do pod já usar a proporção máxima permitida de CPU para memória, o GKE vai pular o aumento para evitar o redimensionamento da memória.
• ComputeClass de escalonamento horizontal: a ComputeClass de escalonamento horizontal impõe uma proporção estrita de 1:4 (CPU:memória). Se você tentar aumentar a CPU em um pod de escalonamento horizontal sem aumentar a memória, o GKE pode ignorar o aumento.

Prática recomendada:para cargas de trabalho do Autopilot, aloque memória de base suficiente na especificação do pod para dar suporte à proporção de CPU aumentada. Se você depende da otimização de inicialização, evite usar a ComputeClass de escalonamento horizontal.

Políticas do recurso

Use ContainerResourcePolicy para personalizar como o escalonamento automático vertical de pods gera recomendações para contêineres específicos. Essa política permite definir restrições e controlar quais recursos são escalonados.

Limites mínimo e máximo

É possível especificar os valores mínimo (minAllowed) e máximo (maxAllowed) de recursos para um contêiner.

• minAllowed: o escalonamento automático vertical de pods não vai recomendar um valor menor que esse limite. Esse limite é útil porque ajuda a garantir um nível de desempenho referencial ou a atender a requisitos específicos do aplicativo.
• maxAllowed: o escalonamento automático vertical de pods não vai recomendar um valor maior que esse limite. Esse limite é útil para controlar custos ou impedir que um único contêiner consuma muitos recursos de nó.

Recursos controlados

Por padrão, o escalonamento automático vertical de pods calcula recomendações para CPU e memória. Use o campo controlledResources para especificar quais recursos serão escalonados automaticamente. Por exemplo, é possível configurar o escalonador automático para fornecer recomendações apenas para memória, deixando as solicitações de CPU inalteradas.

Limitações

• Para usar o escalonamento automático vertical de pods com o escalonamento automático horizontal de pods na CPU, use o dimensionamento correto do HPA com o VPA (pré-lançamento) ou o escalonamento automático multidimensional de pods. Também é possível usar o escalonamento automático vertical de pods com escalonamento automático horizontal de pods em métricas personalizadas e externas.
• O escalonamento automático vertical de pods ainda não está pronto para uso com cargas de trabalho baseadas em JVM devido à visibilidade limitada do uso real da memória da carga de trabalho.
• No GKE versão 1.35.1 e anteriores, o escalonamento automático vertical de pods tem uma configuração padrão de duas réplicas mínimas para implantações para substituir pods por valores de recursos revisados. Na versão 1.35.2 e mais recentes, o padrão é uma réplica mínima. Na versão 1.22 e mais recentes, é possível substituir essa configuração especificando um valor para o campo minReplicas no campo PodUpdatePolicy.
• Se você usar o modo de atualização InPlaceOrRecreate do escalonamento automático vertical de pods e uma atualização no local não for possível (por exemplo, ao escalonar o pod além da capacidade do nó), o escalonamento automático vertical de pods vai remover e recriar o pod para aplicar a recomendação. A remoção e a recriação ocorrem mesmo para pods que têm um campo resizePolicy definido na especificação para evitar recriações. Esse comportamento ocorre para solicitações de redimensionamento do Autopilot, inclusive ao aplicar recursos mínimos e restrições de proporção de CPU:memória.
• O escalonamento automático vertical de pods requer um objeto de carga de trabalho que gerencie os pods, como uma implantação, um StatefulSet, um ReplicaSet ou ReplicationControllers. Não é possível usar o escalonamento automático vertical de pods com pods independentes porque um controlador de carga de trabalho é necessário para gerenciar o processo de recriação de pods.
• O escalonamento automático vertical de pods gera recomendações e aplica atualizações apenas em solicitações de recursos e limites no nível do contêiner (spec.containers[].resources). O escalonamento automático vertical de pods não é compatível com especificações de recursos no nível do pod (spec.resources).

Práticas recomendadas

• Limitar o número de objetos VerticalPodAutoscaler. Para evitar interrupções na atualização do cluster, mantenha o número de objetos VerticalPodAutoscaler por cluster abaixo de 1.000.
• O escalonamento automático vertical de pods funciona melhor com cargas de trabalho homogêneas de longa duração.
  • Longa duração:cargas de trabalho que são executadas por pelo menos 24 horas. O escalonamento automático vertical de pods requer uma quantidade significativa de dados históricos para gerar recomendações de alta confiança. No modo Auto ou Recreate, as atualizações geralmente acontecem depois que um pod tem pelo menos 24 horas, o que ajuda a evitar reinicializações frequentes e rotatividade de pods.
  • Homogêneos:os pods segmentados por um único objeto VerticalPodAutoscaler (como todas as réplicas em uma implantação) precisam exibir padrões de consumo de recursos semelhantes. O Autoescalonador de Pods Vertical gera recomendações agregando dados de uso de todos os pods segmentados. Se as réplicas tiverem uso heterogêneo, por exemplo, alguns pods estiverem inativos e outros estiverem muito carregados, o Autoescalonador de Pods Vertical poderá fornecer uma recomendação que provisione em excesso os pods inativos ou provisione de forma insuficiente os ocupados.
• Use o escalonamento automático horizontal de pods para cargas de trabalho com picos repentinos de demanda. O escalonamento automático vertical de pods foi projetado para o dimensionamento correto em estado estável e não é uma solução para picos de recursos repentinos e de curta duração. Para cargas de trabalho com flutuações rápidas no tráfego ou na demanda de CPU ou memória, use o Autoescalonador Horizontal de Pods.
• Aproveite a proteção contra OOM. Embora o Autoescalonador de Pods Vertical seja reativo, ele inclui proteção automatizada contra eventos de falta de memória (OOM, na sigla em inglês). Se um pod estiver OOMKilled, o Autoescalonador de Pods Vertical vai observar imediatamente o evento e aumentar a recomendação de memória em aproximadamente 20% (ou 100 MB, o que for maior) para melhorar a estabilidade quando o pod for recriado. Para mais informações sobre eventos de OOM, consulte Resolver problemas de eventos de OOM.

Referência da API

Esta é a referência da API v1. É altamente recomendável usar essa versão da API.

VerticalPodAutoscaler v1 autoscaling.k8s.io

Campos
	TypeMeta Grupo, versão e tipo de API.
metadata	ObjectMeta Metadados de objeto padrão.
spec	VerticalPodAutoscalerSpec O comportamento do VerticalPodAutoscaler.
status	VerticalPodAutoscalerStatus O status mais recentemente observado do VerticalPodAutoscaler.

VerticalPodAutoscalerSpec v1 autoscaling.k8s.io

Campos
targetRef	CrossVersionObjectReference Referência do controlador que gerencia o conjunto de pods para administração do escalonador automático. Por exemplo, uma implantação ou um StatefulSet. É possível apontar um VerticalPodAutoscaler em qualquer controlador que tenha um sub-recurso Escala. Normalmente, o VerticalPodAutoscaler recupera o conjunto de pods do ScaleStatus do controlador. Em alguns controladores conhecidos como o DaemonSet, o VerticalPodAutoscaler recupera o conjunto de pods da especificação do controlador.
updatePolicy	PodUpdatePolicy Especifica se as atualizações recomendadas são aplicadas quando um pod é iniciado e durante a vida útil dele.
resourcePolicy	PodResourcePolicy Especifica as políticas de como as solicitações de CPU e memória são ajustadas em contêineres individuais. A política de recursos pode ser usada para definir restrições nas recomendações para contêineres individuais. Se não for especificado, o escalonador automático calculará os recursos recomendados para todos os contêineres no pod, sem restrições adicionais.
recommenders	VerticalPodAutoscalerRecommenderSelector array O recomendador responsável por gerar recomendações para esse objeto VPA. Deixe em branco para usar o recomendador padrão fornecido pelo GKE. Caso contrário, a lista pode conter exatamente uma entrada para um recomendador alternativo fornecido pelo usuário. Compatível desde o GKE 1.22.

VerticalPodAutoscalerList v1 autoscaling.k8s.io

Campos
	TypeMeta Grupo, versão e tipo de API.
metadata	ObjectMeta Metadados de objeto padrão (em inglês).
items	VerticalPodAutoscaler array Uma lista de objetos VerticalPodAutoscaler.

PodUpdatePolicy v1 autoscaling.k8s.io

Campos
updateMode	string Especifica se as atualizações recomendadas são aplicadas quando um pod é iniciado e durante a vida útil dele. Os valores possíveis são: "Off": as atualizações recomendadas são geradas, mas não são aplicadas automaticamente ao pod. "Initial": as atualizações recomendadas são aplicadas apenas quando um pod é iniciado pela primeira vez. As atualizações que ocorrem enquanto o pod já está em execução não são aplicadas automaticamente. "Recreate": as atualizações recomendadas são aplicadas recriando o pod. O pod atual é encerrado, e um novo pod com a configuração atualizada é criado. "Auto": o valor padrão que basicamente aplica o modo "Recreate". "InPlaceOrRecreate": as atualizações recomendadas são aplicadas sem recriar o pod, se possível.
minReplicas	int32 O número mínimo de réplicas que precisam estar ativas para tentar a remoção de pods (pendente de outras verificações, como o orçamento de interrupção de pods). Somente valores positivos são permitidos. O padrão é 1 no GKE versão 1.35.2 e mais recentes, e 2 na versão 1.35.1 e anteriores. Compatível desde o GKE 1.22.

PodResourcePolicy v1 autoscaling.k8s.io

Campos
containerPolicies	ContainerResourcePolicy array Uma matriz de políticas de recursos para contêineres individuais. Pode haver, no máximo, uma entrada para cada contêiner nomeado e, opcionalmente, uma única entrada de caractere curinga com "containerName = "*", que processa todos os contêineres sem políticas individuais.

ContainerResourcePolicy v1 autoscaling.k8s.io

Campos
containerName	string O nome do contêiner ao qual a política se aplica. Se não especificado, a política serve como política padrão.
mode	ContainerScalingMode Especifica se as atualizações recomendadas são aplicadas quando um contêiner é iniciado e durante a vida útil dele. Os valores possíveis são "Off" e "Auto". O padrão será "Auto" se você não especificar um valor.
minAllowed	ResourceList Especifica o pedido mínimo de CPU e a solicitação de memória permitida para o contêiner. Por padrão, não há uma solicitação mínima aplicada.
maxAllowed	ResourceList Especifica a solicitação máxima de CPU e a solicitação de memória permitida para o contêiner. Por padrão, não há uma solicitação máxima aplicada.
controlledResources	[]ResourceName Especifica o tipo de recomendações que serão calculadas (e possivelmente aplicadas) pelo VerticalPodAutoscaler. Se estiver vazio, o padrão do [ResourceCPU, ResourceMemory] será usado.

VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io

Campos
name	string Nome do recomendador responsável por gerar recomendação para esse objeto.

VerticalPodAutoscalerStatus v1 autoscaling.k8s.io

Campos
recommendation	RecommendedPodResources As solicitações de CPU e memória recomendadas mais recentemente.
conditions	VerticalPodAutoscalerCondition array Descreve o estado atual do VerticalPodAutoscaler.

RecommendedPodResources v1 autoscaling.k8s.io

Campos
containerRecommendations	RecommendedContainerResources array Uma matriz de recomendações de recursos para contêineres individuais.

RecommendedContainerResources v1 autoscaling.k8s.io

Campos
containerName	string O nome do contêiner ao qual a recomendação se aplica.
target	ResourceList A solicitação de CPU e a solicitação de memória recomendadas para o contêiner.
lowerBound	ResourceList A solicitação mínima de CPU e solicitação de memória para o contêiner. Não é garantido que esse valor seja suficiente para que o aplicativo seja estável. A execução com solicitações de CPU e memória menores provavelmente terá um impacto significativo no desempenho ou na disponibilidade.
upperBound	ResourceList A solicitação de CPU e a solicitação de memória máximas recomendadas para o contêiner. Solicitações de CPU e memória mais altas do que esses valores provavelmente serão desperdiçadas.
uncappedTarget	ResourceList A recomendação de recurso mais recente computada pelo escalonador automático, com base no uso real de recursos, não considerando o ContainerResourcePolicy. Se o uso real de recursos fizer com que o destino viole a ContainerResourcePolicy, esse valor poderá ser diferente da recomendação limitada. Este campo não afeta a atribuição real de recursos. Ele é usado apenas como uma indicação de status.

VerticalPodAutoscalerCondition v1 autoscaling.k8s.io

Campos
type	VerticalPodAutoscalerConditionType O tipo de condição que está sendo descrita. Os valores possíveis são "RecommendationProvided", "LowConfidence", "NoPodsMatched" e "FetchingHistory".
status	ConditionStatus O status da condição. Os valores possíveis são "True", "False" e "Unknown".
lastTransitionTime	Time A última vez que a condição fez uma transição de um status para outro.
reason	string O motivo da última transição de um status para outro.
message	string Uma string legível por humanos que fornece detalhes sobre a última transição de um status para outro.

A seguir

• Saiba como configurar o escalonamento automático vertical de pods.
• Saiba como dimensionar corretamente as cargas de trabalho do HPA com o VPA.
• Saiba como acelerar a inicialização de aplicativos usando a otimização de CPU de inicialização.
• Saiba mais sobre o escalonamento automático horizontal de pods.
• Saiba mais sobre o escalonador automático de clusters.