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 sua carga de trabalho ao longo do tempo, você pode receber recomendações de otimização e ajustar automaticamente as solicitações e os limites de CPU e memória para contêineres nos pods.
Nesta página, você vai aprender como funciona o escalonamento automático vertical de pods, os benefícios e limitações, as práticas recomendadas para uso e acessar as referências da API para o recurso personalizado VerticalPodAutoscaler e 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 funções de usuário comuns do GKE.
Antes de ler esta página, confira se você conhece os pedidos e limites de recursos no Kubernetes.
Para necessidades de escalonamento rápido em resposta ao uso repentino de recursos, use o escalonador automático 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 ajusta as solicitações de CPU e memória ao longo do tempo sem qualquer 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 um recomendador próprio, 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 mudanças de recursos usando diferentes modos de atualização.
Modo Auto (Recreate)
No modo Recreate, o escalonamento automático vertical de pods
remove um pod se precisar mudar as solicitações de recursos 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 depois.
Modo InPlaceOrRecreate
O modo InPlaceOrRecreate visa reduzir a interrupção do serviço tentando
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 exige 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 OOM (falta de memória), 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 subsequente 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 falta de memória.
O modo InPlaceOrRecreate está disponível com a versão 1.34.0-gke.2201000 e mais recente 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
reverte para a 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
BurstableparaGuaranteed. - Política
RestartContainer:o camporesizePolicydo pod é definido comoRestartContainerpara 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 mudanças automaticamente a um pod.
Você ainda pode conferir 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 automaticamente. Se necessário, é possível aplicar manualmente os valores recomendados aos seus pods.
Políticas do recurso
Você pode usar ContainerResourcePolicy para personalizar como o escalonamento automático vertical de pods gera recomendações para contêineres específicos. Com ela, é possível definir restrições e controlar quais recursos são escalonados.
Limites mínimos e máximos
É 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 recomenda um valor menor que esse limite. Esse limite é útil para garantir um nível básico de desempenho ou atender a requisitos específicos do aplicativo.maxAllowed: o escalonamento automático vertical de pods não recomenda um valor maior que esse limite. Esse limite é útil para controlar custos ou impedir que um único contêiner consuma recursos demais do 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, use 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 do pod vertical 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.
- 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. No GKE versão 1.22 e posterior, é possível substituir essa configuração especificando um valor para o campo
minReplicasno campo PodUpdatePolicy. - Se você usar o modo de atualização
InPlaceOrRecreatedo escalonamento automático vertical de pods e uma atualização no local não for possível (por exemplo, ao aumentar a escala do 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 camporesizePolicydefinido na especificação para evitar recriações. Esse comportamento ocorre em solicitações de redimensionamento do Autopilot, inclusive ao aplicar restrições de recursos mínimos e proporção de CPU:memória. - O escalonamento automático vertical de pods exige um objeto de carga de trabalho que gerencie os pods, como um Deployment, StatefulSet, ReplicaSet ou ReplicationController. 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.
Práticas recomendadas
- Limite o número de objetos
VerticalPodAutoscaler. Para evitar interrupções na atualização do cluster, recomendamos que você mantenha o número de objetosVerticalPodAutoscalerpor cluster abaixo de 1.000. - O escalonamento automático vertical de pods funciona melhor com cargas de trabalho homogêneas de longa duração.
- De longa duração:cargas de trabalho que são executadas por pelo menos 24 horas. O escalonamento automático vertical de pods exige uma quantidade significativa de dados históricos para gerar recomendações de alta confiança. No modo
AutoouRecreate, as atualizações geralmente acontecem depois que um pod tem pelo menos 24 horas, o que ajuda a evitar reinicializações e rotatividade frequentes de pods. - Homogêneos:os pods segmentados por um único objeto
VerticalPodAutoscaler(como todas as réplicas em uma implantação) precisam apresentar padrões semelhantes de consumo de recursos. O escalonador automático vertical de pods gera recomendações agregando dados de uso em todos os pods de destino. Se as réplicas tiverem uso heterogêneo, por exemplo, alguns pods estiverem ociosos e outros muito carregados, o escalonador automático de pod vertical poderá fornecer uma recomendação que provisione demais os pods ociosos ou provisione de menos os ocupados.
- De longa duração:cargas de trabalho que são executadas por pelo menos 24 horas. O escalonamento automático vertical de pods exige uma quantidade significativa de dados históricos para gerar recomendações de alta confiança. No modo
- 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 dimensionamento adequado de 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 por CPU ou memória, use o escalonador automático horizontal de pods.
- Use a proteção contra OOM. Embora o escalonador automático vertical de pods 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 escalonador automático vertical de pods 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 falta de memória, consulte Resolver problemas de eventos de falta de memória.
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 | |
|---|---|
|
Grupo, versão e tipo de API. |
metadata |
Metadados de objeto padrão. |
spec |
O comportamento do |
status |
O status mais recentemente observado do |
VerticalPodAutoscalerSpec v1 autoscaling.k8s.io
| Campos | |
|---|---|
targetRef |
Referência do controlador que gerencia o conjunto de pods para administração do autoescalador. Por exemplo, uma implantação ou um StatefulSet.
É possível apontar um |
updatePolicy |
Especifica se as atualizações recomendadas são aplicadas quando um pod é iniciado e durante a vida útil dele. |
resourcePolicy |
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 |
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 | |
|---|---|
|
Grupo, versão e tipo de API. |
metadata |
Metadados de objeto padrão (em inglês). |
items |
Uma lista de objetos |
PodUpdatePolicy v1 autoscaling.k8s.io
| Campos | |
|---|---|
updateMode |
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:
|
minReplicas |
O número mínimo de réplicas que precisam estar ativas para
tentar a remoção do pod (pendente de outras verificações, como o orçamento de interrupção do pod).
Somente valores positivos são permitidos. O valor padrão é |
PodResourcePolicy v1 autoscaling.k8s.io
| Campos | |
|---|---|
containerPolicies |
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 |
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 |
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 |
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 |
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 |
Especifica o tipo de recomendações que serão calculadas (e
possivelmente aplicadas) pelo |
VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io
| Campos | |
|---|---|
name |
Nome do recomendador responsável por gerar recomendação para esse objeto. |
VerticalPodAutoscalerStatus v1 autoscaling.k8s.io
| Campos | |
|---|---|
recommendation |
As solicitações de CPU e memória recomendadas mais recentemente. |
conditions |
Descreve o estado atual do |
RecommendedPodResources v1 autoscaling.k8s.io
| Campos | |
|---|---|
containerRecommendation |
Uma matriz de recomendações de recursos para contêineres individuais. |
RecommendedContainerResources v1 autoscaling.k8s.io
| Campos | |
|---|---|
containerName |
O nome do contêiner ao qual a recomendação se aplica. |
target |
A solicitação de CPU e a solicitação de memória recomendadas para o contêiner. |
lowerBound |
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 |
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 |
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 do recurso fizer com que o destino viole o 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 |
O tipo de condição que está sendo descrita. Os valores possíveis são "RecommendationProvided", "LowConfidence", "NoPodsMatched" e "FetchingHistory". |
status |
O status da condição. Os valores possíveis são "True", "False" e "Unknown". |
lastTransitionTime |
A última vez que a condição fez uma transição de um status para outro. |
reason |
O motivo da última transição de um status para outro. |
message |
Uma string legível com detalhes sobre a última transição de um status para outro. |
A seguir
- Saiba como configurar o escalonamento automático vertical de pods.
- Saiba mais sobre o escalonamento automático horizontal de pods.
- Saiba mais sobre o escalonador automático de clusters.
- Saiba como configurar o escalonamento automático horizontal de pods.
- Saiba como otimizar o escalonamento automático de pods com base em métricas.