Nesta página, mostramos como escalonar suas implantações no Google Kubernetes Engine (GKE) ajustando automaticamente seus recursos usando métricas como alocação de recursos, tráfego do balanceador de carga, métricas personalizadas ou várias métricas simultaneamente. Esta página também fornece instruções detalhadas para configurar um perfil HorizontalPodAutoscaler (HPA), incluindo como visualizar, excluir, limpar e resolver problemas do objeto HPA. Uma implantação é um objeto da API Kubernetes que permite executar várias réplicas de pods distribuídos entre os nós de um cluster.
Esta página é destinada a desenvolvedores e operadores que gerenciam o escalonamento de aplicativos no GKE e querem entender como otimizar o desempenho de forma dinâmica e manter a eficiência de custos com o escalonamento automático horizontal de pods. Para saber mais sobre papéis comuns e exemplos de tarefas referenciados no conteúdo do Google Cloud, consulte Funções e tarefas comuns do usuário do GKE.
Antes de começar
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ative a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa, instale e inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando o comando
gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
- Verifique se você tem um cluster do Autopilot ou Standard. Se precisar de um, crie um cluster do Autopilot.
Versões de API para objetos de escalonador automático horizontal de pods
Quando você usa o console do Google Cloud , os objetos de HPA são criados usando a API autoscaling/v2. A API autoscaling/v1 ainda é compatível, mas não é mais recomendada e não oferece suporte a determinados recursos, como escalonamento para e de zero usando o HPA.
Crie a implantação de exemplo
Antes de criar um objeto HPA, crie a carga de trabalho que ele monitora. Os exemplos nesta página aplicam configurações diferentes do HPA à implantação nginx a seguir. Outros exemplos mostram um HPA com base na
utilização de recursos, em uma
métrica personalizada ou externa
e em métricas múltiplas.
Salve o seguinte em um arquivo chamado nginx.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
resources:
# You must specify requests for CPU to autoscale
# based on CPU utilization
requests:
cpu: "250m"
Este manifesto especifica um valor para solicitações de CPU. Se desejar fazer escalonamento automático com base na utilização de um recurso, como uma porcentagem, especifique solicitações para esse recurso. Se você não especificar solicitações, será possível fazer escalonamento automático com base apenas no valor absoluto da utilização do recurso, como milliCPUs para a utilização da CPU.
Para criar a implantação, aplique o manifesto nginx.yaml:
kubectl apply -f nginx.yaml
A implantação tem spec.replicas definido como 3, então três pods são implantados.
É possível verificar isso usando o comando kubectl get deployment nginx.
Cada um dos exemplos nesta página aplica um objeto HPA diferente a um exemplo de implantação nginx.
Escalonamento automático com base na utilização de recursos
Este exemplo cria um objeto HPA para escalonamento automático da
implantação nginx quando a utilização da CPU ultrapassar 50% e ajuda a garantir que sempre haja, no mínimo, uma réplica e, no máximo, dez réplicas.
É possível criar um HPA que segmente a CPU usando o console do Google Cloud , o
comando kubectl apply ou, somente para uma média da CPU, o comando kubectl autoscale.
Console
Acesse a página Cargas de trabalho no console Google Cloud .
Clique no nome da implantação
nginx.Clique em list Ações > Editar escalonamento automático.
Na seção Escalonamento automático horizontal de pods, clique em Selecionar e configurar.
Especifique os seguintes valores:
- Número mínimo de réplicas: 1
- Número máximo de réplicas: 10
- Métrica de escalonamento automático: CPU
- Destino: 50
- Unidade:CPUs
Clique em Enviar.
kubectl apply
Salve o seguinte manifesto YAML como um arquivo chamado nginx-hpa.yaml:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
# Set the minimum and maximum number of replicas the Deployment can scale to.
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
# The target average CPU utilization percentage across all Pods.
name: cpu
target:
type: Utilization
averageUtilization: 50
Se você criar um manifesto para corresponder a detalhes específicos no seu projeto, não inclua dados sensíveis nos campos do escalonador automático horizontal de pods.
Para criar o HPA, aplique o manifesto usando o seguinte comando:
kubectl apply -f nginx-hpa.yaml
kubectl autoscale
Para criar um objeto HPA que segmente somente a utilização média da CPU, é possível usar
o
comando kubectl autoscale.
kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10
Para receber uma lista de HPAs no cluster, use o seguinte comando:
kubectl get hpa
O resultado será o seguinte:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/50% 1 10 3 61s
Para detalhes sobre o HPA, use o console do Google Cloud ou o
comando kubectl.
Console
Acesse a página Cargas de trabalho no console Google Cloud .
Clique no nome da implantação
nginx.Clique na guia Escalonamento.
kubectl get
Para conferir detalhes sobre o HPA, use kubectl get hpa com a flag -o yaml. O campo status contém informações sobre o número atual de
réplicas e todos os eventos recentes de escalonamento automático.
kubectl get hpa nginx -o yaml
O resultado será o seguinte:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"metrics":[{"resource":{"name":"cpu","target":{"averageUtilization":50,"type":"Utilization"}},"type":"Resource"}],"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"}}}
creationTimestamp: "2025-10-30T19:42:43Z"
name: nginx
namespace: default
resourceVersion: "220050"
selfLink: /apis/autoscaling/v2/namespaces/default/horizontalpodautoscalers/nginx
uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
status:
conditions:
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: recent recommendations were higher than current one, applying the highest recent recommendation
reason: ScaleDownStabilized
status: "True"
type: AbleToScale
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
reason: ValidMetricFound
status: "True"
type: ScalingActive
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: the desired count is within the acceptable range
reason: DesiredWithinRange
status: "False"
type: ScalingLimited
currentMetrics:
- type: Resource
resource:
name: cpu
current:
averageUtilization: 0
averageValue: "0"
currentReplicas: 3
desiredReplicas: 3
Se você criar um manifesto para corresponder a detalhes específicos no seu projeto, não inclua dados sensíveis nos campos do escalonador automático horizontal de pods.
Antes de seguir os outros exemplos desta página, exclua o HPA:
kubectl delete hpa nginx
Quando você exclui um objeto de HPA, o número de réplicas da implantação permanece o mesmo. Uma implantação não reverte automaticamente para o estado anterior à aplicação do HPA.
Saiba mais sobre como excluir um HPA.
Como fazer escalonamento automático com base em uma métrica personalizada ou externa
Qualquer métrica emitida pela sua carga de trabalho ou que você pode consultar de uma fonte externa pode ser usada para escalonamento automático. O GKE tem suporte integrado para escalonamento automático com base em métricas personalizadas e externas em muitas situações, e o Kubernetes é compatível com outros adaptadores de métricas, como o KEDA e o Prometheus.
Como fazer escalonamento automático com base no tráfego do balanceador de carga
O escalonamento automático baseado em tráfego é um recurso do GKE que integra sinais de utilização de tráfego de balanceadores de carga para escalonar automaticamente os pods.
Usar o tráfego como um sinal de escalonamento automático pode ser útil, porque ele é um indicador principal de carga que é complementar à CPU e à memória. A integração incorporada no GKE ajuda a garantir que a configuração seja simples e que o escalonamento automático reaja rapidamente aos picos de tráfego para atender à demanda.
O escalonamento automático baseado em tráfego é ativado pelo controlador de gateway e seus recursos de gerenciamento de tráfego global. Para saber mais, consulte Escalonamento automático baseado em tráfego.
O escalonamento automático com base no tráfego do balanceador de carga está disponível apenas para cargas de trabalho do Gateway.
Requisitos
O escalonamento automático baseado em tráfego tem os seguintes requisitos:
- Compatível com as versões 1.31 e posteriores do GKE.
- API Gateway ativada no projeto.
- Compatível com tráfego que passa pelos balanceadores de carga implantados usando a API Gateway e um destes GatewayClasses:
gke-l7-global-external-managed,gke-l7-regional-external-managed,gke-l7-rilbougke-l7-gxlb.
Limitações
O escalonamento automático baseado em tráfego tem as seguintes limitações:
- Não é compatível com o GatewayClass de vários clusters (
gke-l7-global-external-managed-mc,gke-l7-regional-external-managed-mc,gke-l7-rilb-mcegke-l7-gxlb-mc). - Indisponível para tráfego usando os Serviços do tipo
LoadBalancer. - É preciso haver uma relação clara e isolada entre os componentes envolvidos no escalonamento automático com base no tráfego. Um objeto HPA precisa ser dedicado ao escalonamento de uma única implantação (ou qualquer recurso escalonável) exposta por um único serviço.
- Depois de configurar a capacidade do serviço usando o campo
maxRatePerEndpoint, aguarde tempo suficiente (geralmente um minuto, mas possivelmente até 15 minutos em clusters grandes) para que o balanceador de carga seja atualizado com essa mudança antes de configurar o HPA com métricas baseadas em tráfego. Essa abordagem ajuda a garantir que seu serviço não passe temporariamente por uma situação em que o cluster tente fazer o escalonamento automático com base em métricas emitidas por um balanceador de carga ainda em configuração. - Se o escalonamento automático baseado em tráfego for usado em um serviço atendido por vários balanceadores de carga (por exemplo, por um Entrada e um Gateway ou por dois Gateways), o HPA poderá considerar o maior valor de tráfego dos balanceadores de carga individuais para tomar decisões de escalonamento, em vez da soma dos valores de tráfego de todos os balanceadores de carga.
Implantar o escalonamento automático baseado em tráfego
O exercício a seguir usa o HPA para fazer o escalonamento automático da implantação store-autoscale com base no tráfego recebido. Um
gateway aceita o tráfego
de entrada da Internet para os pods. O escalonador automático compara sinais de tráfego
do gateway com a
capacidade de tráfego por pod
configurada no recurso de serviço store-autoscale. Ao gerar tráfego para o gateway, você influencia o número de pods implantados.
Veja no diagrama a seguir como o escalonamento automático baseado em tráfego funciona:
Para implantar o escalonamento automático baseado em tráfego, execute as seguintes etapas:
Para clusters padrão, confirme se as GatewayClasses estão instaladas no cluster. Para clusters do Autopilot, as GatewayClasses são instaladas por padrão.
kubectl get gatewayclassA saída confirma que os recursos do GatewayClass do GKE estão prontos para uso no cluster:
NAME CONTROLLER ACCEPTED AGE gke-l7-global-external-managed networking.gke.io/gateway True 16h gke-l7-regional-external-managed networking.gke.io/gateway True 16h gke-l7-gxlb networking.gke.io/gateway True 16h gke-l7-rilb networking.gke.io/gateway True 16hSe você não encontrar essa saída, ative a API Gateway no cluster do GKE.
Implante o aplicativo de amostra e o balanceador de carga de gateway no cluster:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yamlO aplicativo de amostra cria:
- Uma implantação com duas réplicas.
- Um serviço com uma configuração
GCPBackendPolicyassociadamaxRatePerEndpointdefinida como10. Para saber mais sobre os recursos de gateway, consulte Recursos de GatewayClass. - Um gateway externo para acessar o aplicativo na Internet. Para saber mais sobre como usar balanceadores de carga de gateway, consulte Como implantar gateways.
- Uma HTTPRoute que corresponde a todo o tráfego e a envia para o
serviço
store-autoscale.
A capacidade do serviço é um elemento essencial ao usar o escalonamento automático baseado em tráfego, porque determina a quantidade de tráfego por pod que aciona um evento de escalonamento automático. Ela é configurada usando um campo
maxRatePerEndpointem uma GCPBackendPolicy associada ao serviço, que define o tráfego máximo que um serviço precisa receber em solicitações por segundo, por pod. A capacidade do serviço é específica do seu aplicativo.Para mais informações, consulte Como determinar a capacidade do seu serviço.
Salve o seguinte manifesto como
hpa.yaml:apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: store-autoscale spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: store-autoscale # Set the minimum and maximum number of replicas the Deployment can scale to. minReplicas: 1 maxReplicas: 10 # This section defines that scaling should be based on the fullness of load balancer # capacity, using the following configuration. metrics: - type: Object object: describedObject: kind: Service name: store-autoscale metric: # The name of the custom metric which measures how "full" a backend is # relative to its configured capacity. name: "autoscaling.googleapis.com|gclb-capacity-fullness" target: # The target average value for the metric. The autoscaler adjusts the number # of replicas to maintain an average capacity fullness of 70% across all Pods. averageValue: 70 type: AverageValueEste manifesto descreve um objeto HPA com as seguintes propriedades:
minReplicasemaxReplicas: define os números mínimo e máximo de réplicas para esta implantação. Nesta configuração, o número de pods pode ser escalonado de1a10réplicas (ou de0réplicas se você configurar o escalonamento para e de zero usando o HPA).describedObject.name: store-autoscale: a referência ao serviçostore-autoscaleque define a capacidade do tráfego.scaleTargetRef.name: store-autoscale: a referência à implantaçãostore-autoscaleque define o recurso dimensionado pelo HPA.averageValue: 70: valor médio desejado de 70% de utilização da capacidade. Isso dá ao HPA uma margem de crescimento para que os pods em execução possam processar o tráfego excessivo enquanto novos pods estão sendo criados.
Se você criar um manifesto para corresponder a detalhes específicos no seu projeto, não inclua dados sensíveis nos campos do escalonador automático horizontal de pods.
O HPA resulta no seguinte comportamento de tráfego:
- O número de pods é ajustado entre 1 e 10 réplicas para alcançar
70% da taxa máxima por endpoint. Isso resulta em 7 RPS por pod quando
maxRatePerEndpoint=10. - Com mais de 7 RPS por pod, o escalonamento vertical dos pods é feito até atingir o máximo de 10 réplicas ou até que o tráfego médio seja de 7 RPS por pod.
- Se o tráfego for reduzido, os pods reduzir escala vertical a uma taxa razoável usando o algoritmo do HPA.
Também é possível implantar um gerador de tráfego para validar o comportamento de escalonamento automático baseado em tráfego.
Com 30 RPS, a implantação é escalonada para 5 réplicas para que cada réplica receba 6 RPS de tráfego, o que seria 60% de utilização por pod. Isso está abaixo da meta de utilização de 70%, portanto, os pods são dimensionados adequadamente. Dependendo das flutuações de tráfego, o número de réplicas com escalonamento automático também pode flutuar. Para uma descrição mais detalhada de como o número de réplicas é calculado, consulte Comportamento do escalonamento automático.
Como fazer escalonamento automático com base em várias métricas
Este exemplo cria um objeto HPA que faz o escalonamento automático com base na utilização da CPU e em uma
métrica personalizada chamada packets_per_second.
Se você seguiu o exemplo anterior e ainda tem um objeto HPA chamado nginx,
exclua-o antes de seguir este exemplo.
Este exemplo requer apiVersion: autoscaling/v2. Para mais informações sobre as APIs disponíveis, consulte Versões da API para objetos HPA.
Salve este manifesto YAML como um arquivo chamado nginx-multiple.yaml:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 10
metrics: # The metrics to base the autoscaling on.
- type: Resource
resource:
name: cpu # Scale based on CPU utilization.
target:
type: Utilization
averageUtilization: 50
# The HPA will scale the replicas to try and maintain an average
# CPU utilization of 50% across all Pods.
- type: Resource
resource:
name: memory # Scale based on memory usage.
target:
type: AverageValue
averageValue: 100Mi
# The HPA will scale the replicas to try and maintain an average
# memory usage of 100 Mebibytes (MiB) across all Pods.
# Uncomment these lines if you create the custom packets_per_second metric and
# configure your app to export the metric.
# - type: Pods
# pods:
# metric:
# name: packets_per_second
# target:
# type: AverageValue
# averageValue: 100
Se você criar um manifesto para corresponder a detalhes específicos no seu projeto, não inclua dados sensíveis nos campos do escalonador automático horizontal de pods.
Aplique o manifesto YAML:
kubectl apply -f nginx-multiple.yaml
Quando criado, o HPA monitora a implantação nginx para uso médio da CPU,
uso médio da memória e (se você remover a marca de comentário) a métrica personalizada
packets_per_second. O HPA faz o escalonamento automático da implantação com base na
métrica cujo valor criaria o maior evento de escalonamento automático.
Escalonar para e de zero
A partir da versão 1.37 do GKE, é possível configurar o HPA para reduzir uma implantação a zero (0) réplicas quando não houver demanda de carga de trabalho e escaloná-la automaticamente quando a demanda aumentar. Ao fazer o escalonamento vertical de zero, o GKE ignora as verificações padrão de tolerância de métricas para ativar os pods sem demora.
Para configurar o escalonamento para e de zero usando o HPA, faça o seguinte:
- Verifique se o cluster executa a versão 1.37 ou mais recente do GKE.
- Configure pelo menos uma métrica personalizada ou externa usando o recurso AutoscalingMetric.
- Defina o par campo-valor
minReplicas: 0em um manifesto do HPA que usa a APIautoscaling/v2.
Para instruções detalhadas, consulte Escalonar cargas de trabalho do GKE para e de zero usando o HPA.
Configurar o perfil de HPA de performance
O perfil de HPA de desempenho melhora o tempo de reação do escalonamento automático horizontal de pods, ajudando a melhorar a capacidade do HPA de lidar com um grande número de objetos (até 1.000 objetos nas versões secundárias 1.31-1.32 e 5.000 objetos na versão 1.33 ou posterior).
Esse perfil é ativado automaticamente em clusters do Autopilot qualificados com um plano de controle que executa o GKE versão 1.32 ou mais recente. Para clusters Standard, o perfil é ativado automaticamente em clusters qualificados com um plano de controle que executa o GKE versão 1.33 ou mais recente.
Um cluster Standard estará isento da ativação automática do perfil de HPA de desempenho se atender a todas as seguintes condições:
- O cluster está fazendo upgrade de uma versão anterior para a versão 1.33 ou mais recente.
- O cluster tem pelo menos um pool de nós com um dos seguintes tipos de máquina:
e2-micro,e2-custom-micro,g1-small,f1-micro. - O provisionamento automático de nós não está ativado.
Também é possível ativar o perfil de HPA de desempenho em clusters atuais se eles atenderem aos requisitos.
Requisitos
Para ativar o perfil de HPA de performance, verifique se os clusters do Autopilot e padrão atendem aos seguintes requisitos:
- O plano de controle está executando o GKE versão 1.31 ou posterior.
- Se o plano de controle estiver executando a versão 1.31 do GKE, ative a coleta de métricas do sistema.
- A API Autoscaling está ativada no seu projeto.
- Todas as
contas de serviço de nó
têm o papel
roles/autoscaling.metricsWriteratribuído. - Se você usa o VPC Service Controls, verifique se a API Autoscaling está incluída no perímetro de serviço.
Ativar o perfil de HPA de performance
Para ativar o perfil de HPA de desempenho no cluster, use o seguinte comando:
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--project=PROJECT_ID \
--hpa-profile=performance
Substitua:
CLUSTER_NAME: o nome do cluster.LOCATION: zona ou região de computação (por exemplo, us-central1-a ou us-central1) do cluster.PROJECT_ID: o ID do projeto do Google Cloud .
Desativar o perfil de HPA de desempenho
Para desativar o perfil de HPA de desempenho em um cluster, use o seguinte comando:
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--project=PROJECT_ID \
--hpa-profile=none
Substitua:
CLUSTER_NAME: o nome do cluster.LOCATION: zona ou região de computação (por exemplo, us-central1-a ou us-central1) do cluster.PROJECT_ID: o ID do projeto do Google Cloud .
Como visualizar detalhes de um HorizontalPodAutoscaler
Para ver a configuração e as estatísticas de um HPA, use o seguinte comando:
kubectl describe hpa HPA_NAME
Substitua HPA_NAME pelo nome do objeto HPA.
O status atual de cada objeto HPA é mostrado no campo Conditions, e os eventos de escalonamento automático são listados no campo Events.
O resultado será o seguinte:
Name: nginx
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"s...
CreationTimestamp: Tue, 05 May 2020 20:07:11 +0000
Reference: Deployment/nginx
Metrics: ( current / target )
resource memory on pods: 2220032 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Deployment pods: 1 current / 1 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale recommended size matches current size
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
Como excluir um HorizontalPodAutoscaler
É possível excluir um objeto HPA usando o console Google Cloud ou o comando kubectl delete.
Console
Para excluir o objeto HPA nginx:
Acesse a página Cargas de trabalho no console Google Cloud .
Clique no nome da implantação
nginx.Clique em list Ações > Escalonamento automático.
Clique em Excluir.
kubectl delete
Para excluir o objeto HPA nginx, use o seguinte comando:
kubectl delete hpa nginx
Quando você exclui um objeto HPA, a implantação (ou outro objeto de implantação) permanece
na escala atual e não volta ao número de réplicas no
manifesto original da implantação. Para escalonar manualmente a implantação para três pods um outra vez, é possível usar o comando kubectl scale:
kubectl scale deployment nginx --replicas=3
Limpar
Exclua o objeto HPA, se ainda não tiver feito isso:
kubectl delete hpa nginxExclua a implantação
nginx:kubectl delete deployment nginxOpcionalmente, exclua o cluster.
Solução de problemas
Para receber conselhos sobre solução de problemas, consulte Resolver problemas de escalonamento automático horizontal de pods.
A seguir
- Saiba mais sobre o escalonamento automático horizontal de pods.
- Saiba como ajustar o tamanho certo das cargas de trabalho do HPA com o VPA.
- Saiba mais sobre o Escalonamento automático vertical de pods.
- Saiba mais sobre a otimização de inicialização da CPU.