Introdução
O escalonador precisa das solicitações de recursos para posicionar os Pods, o kubelet aplica os limites, e o HorizontalPodAutoscaler precisa de métricas e de uma referência de utilização significativa. Esses controles formam um único fluxo de gerenciamento de capacidade.
Você configurará solicitações e limites, inspecionará o uso atual, criará um HPA, gerará carga e observará as alterações no número de réplicas.
Essas configurações formam uma cadeia de dependências. A solicitação de CPU estabelece uma referência, o metrics-server informa o uso recente e o HPA compara os dois valores para decidir se o número de réplicas deve ser alterado. Sem a solicitação, a utilização percentual de CPU não teria uma base de comparação significativa.
Definir solicitações e limites
Nesta etapa, implante o exemplo de HPA do Kubernetes com recursos explícitos.
Uma solicitação é a quantidade usada pelo escalonador para posicionar o Pod e como denominador do escalonamento automático. Um limite é o máximo aplicado ao contêiner. A CPU usa cores ou millicores (100m corresponde a 0,1 core); a memória usa unidades de bytes, como Mi.
cd /home/labex/project/resource-autoscaling
kubectl create namespace practice-capacity
kubectl create deployment cpu-demo -n practice-capacity --image=registry.k8s.io/hpa-example:latest --replicas=1
Adicione o contrato de recursos ao Deployment gerado. kubectl set resources atualiza o modelo do Pod e, portanto, inicia uma nova implantação:
kubectl set resources deployment/cpu-demo -n practice-capacity --requests=cpu=100m,memory=32Mi --limits=cpu=200m,memory=64Mi
kubectl expose deployment cpu-demo -n practice-capacity --port=80 --target-port=80
kubectl rollout status deployment/cpu-demo -n practice-capacity --timeout=60s
kubectl get deployment cpu-demo -n practice-capacity -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'
100m representa um décimo de um core de CPU. As solicitações influenciam o agendamento e os cálculos de utilização; os limites restringem o consumo do contêiner.
A saída do JSONPath deve conter requests e limits. Declarar apenas um limite não forneceria o denominador de utilização necessário ao HPA.
deployment "cpu-demo" successfully rolled out
{"limits":{"cpu":"200m","memory":"64Mi"},"requests":{"cpu":"100m","memory":"32Mi"}}
O JSON pode exibir as chaves em uma ordem diferente. Verifique os quatro valores, não a posição deles na linha.
Inspecionar métricas de recursos
Nesta etapa, valide o pipeline de métricas preparado e inspecione o uso.
kubectl top exibe um instantâneo do uso recente, semelhante, em princípio, ao comando top dos sistemas operacionais. Ele não mostra as solicitações nem os limites configurados; esses valores continuam fazendo parte da especificação da carga de trabalho.
cd /home/labex/project/resource-autoscaling
kubectl get deployment metrics-server -n kube-system
for attempt in $(seq 1 18); do
if kubectl top nodes >/dev/null 2>&1 && kubectl top pods -n practice-capacity --containers >/dev/null 2>&1; then
break
fi
echo "Waiting for the first metrics sample (${attempt}/18)..."
sleep 5
done
kubectl top nodes
kubectl top pods -n practice-capacity --containers
kubectl top lê métricas recentes, não as solicitações de recursos. As métricas podem levar alguns instantes para aparecer; se um Pod novo ainda não tiver uma amostra, tente novamente após alguns segundos.
O laço realiza essa nova tentativa automaticamente. Ele verifica silenciosamente até 18 vezes, espera cinco segundos entre as tentativas e executa os dois comandos top visíveis assim que uma amostra estiver disponível. Nas verificações, >/dev/null descarta a saída normal e 2>&1 envia a saída de erro para o mesmo local; isso mantém no terminal as mensagens esperadas de que as métricas ainda não estão prontas. Essa demora é normal em um pipeline de uso recente e não significa que o Pod falhou.
Os valores do nó e do Pod variam, portanto concentre-se na presença das colunas de CPU e memória, e não nos números exatos. --containers separa o uso quando um Pod contém mais de um contêiner.
Por exemplo, o ambiente testado produziu uma tabela de nós e uma tabela por contêiner semelhantes a estas:
NAME CPU(cores) CPU(%) MEMORY(bytes) MEMORY(%)
labex-v135 182m 9% 1602Mi 44%
POD NAME CPU(cores) MEMORY(bytes)
cpu-demo-... hpa-example 1m 9Mi
É esperado que seus números sejam diferentes, pois eles são medições, não valores de configuração.
Criar um HorizontalPodAutoscaler
Nesta etapa, defina como meta uma utilização média de CPU de 30%, com uma a quatro réplicas.
Com uma solicitação de 100m, uma meta de 30% corresponde a aproximadamente 30m de uso médio de CPU por Pod. O HPA ajusta o número desejado de réplicas do Deployment, mas nunca fica abaixo de min=1 nem acima de max=4.
cd /home/labex/project/resource-autoscaling
kubectl autoscale deployment cpu-demo -n practice-capacity --cpu=30% --min=1 --max=4
kubectl get hpa cpu-demo -n practice-capacity
kubectl describe hpa cpu-demo -n practice-capacity
A utilização é medida em relação à solicitação de CPU de 100m. Sem essa solicitação, uma meta percentual de CPU não teria um denominador.
A sintaxe atual de kubectl autoscale especifica explicitamente a porcentagem com --cpu=30%. Ela substitui a opção antiga --cpu-percent, que o Kubernetes 1.35 informa como obsoleta.
Nos primeiros segundos, a coluna TARGETS pode exibir <unknown> enquanto uma nova amostra de métricas é coletada. describe hpa mostra as condições e os eventos que explicam se o controlador dispõe de métricas utilizáveis.
Por isso, uma tabela inicial pode ser semelhante a esta sem indicar um erro:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: <unknown>/30% 1 4 0
Após a próxima sincronização do controlador, <unknown> será substituído por uma porcentagem medida e REPLICAS refletirá o Deployment.
Gerar carga e observar o escalonamento
Nesta etapa, execute um cliente temporário que fará solicitações repetidas ao Service por até 60 segundos.
O comando timeout do BusyBox executa um laço interno de solicitações durante 60 segundos. O laço while chama repetidamente o endpoint da demonstração, que exige CPU, e >/dev/null descarta os corpos das respostas para manter o terminal legível. Ao atingir o limite de tempo, o comando normalmente retorna um status diferente de zero; por isso, || true trata essa parada planejada como uma conclusão normal.
cd /home/labex/project/resource-autoscaling
kubectl run load-generator -n practice-capacity --image=busybox:1.36 --image-pull-policy=IfNotPresent --restart=Never --rm -i -- sh -c 'timeout 60 sh -c "while true; do wget -qO- http://cpu-demo >/dev/null; done" || true'
kubectl get hpa cpu-demo -n practice-capacity
kubectl get deployment cpu-demo -n practice-capacity
O HPA reage de forma assíncrona, portanto as alterações no número de réplicas podem continuar depois que o cliente for encerrado. Inspecione as condições e os eventos do HPA em vez de esperar um escalonamento imediato.
Se o escalonamento ainda não aparecer na primeira tabela, execute kubectl get hpa cpu-demo -n practice-capacity -w por alguns instantes e pressione Ctrl+C depois de observar uma alteração. -w monitora as atualizações; ele não modifica o HPA. O tempo exato não faz parte da verificação, pois os ciclos de controle das métricas são assíncronos.
Na execução testada, o HPA observou um uso acima da meta e aumentou o Deployment para duas réplicas prontas:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: 55%/30% 1 4 2
NAME READY UP-TO-DATE AVAILABLE
cpu-demo 2/2 2 2
A utilização exata e o número de réplicas podem ser diferentes. O ponto principal é: o valor atual de 55% ultrapassou a meta de 30%, então a capacidade desejada aumentou, permanecendo dentro dos limites de 1 a 4 réplicas.
Resumo
Você conectou solicitações, limites, métricas atuais, metas de utilização e decisões do HPA. O gerenciamento de capacidade funciona como um ciclo de realimentação: declare uma referência, observe o uso, defina limites e inspecione as condições do controlador.
