Gerador de Kubernetes HorizontalPodAutoscaler (HPA v2)

Gerador de Kubernetes HorizontalPodAutoscaler (HPA v2)

K8s 1.23+ GA

Crie manifestos YAML de HPA v2 com metas de utilização de CPU e memória, métricas personalizadas e políticas de estabilização de escala vertical e horizontal.

Presets:
Configuração do HPA
Limites de réplicasScale: 2 → 10 pods
minReplicas
maxReplicas
Nota de agendamento do Kubernetes: Quando o tráfego diminui, o HPA nunca escalará abaixo de minReplicas (2), e limitará a expansão rápida a maxReplicas (10).
Replicas: 2-10Metrics: 2
Target: api-service
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-service-hpa
  namespace: production
  labels:
    app.kubernetes.io/name: api-service
    app.kubernetes.io/managed-by: toolsaa-k8s-hpa-generator
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
        - type: Pods
          value: 4
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      selectPolicy: Min
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
Lines: 46Size: 1035 B
autoscaling/v2 syntax ready
Versão da API
autoscaling/v2 (K8s 1.23+)
Métricas Alvo
2 regras configuradas
Estabilização de Comportamento
300s s janela de resfriamento

Processamento no Cliente

Processamento de alto desempenho executado inteiramente na memória do navegador.

Privacidade Sem Upload para Servidor

Todas as cargas de dados permanecem estritamente locais, sem comunicação com servidores externos.

Exportação Pronta para Produção

Formatos de saída limpos e otimizados, prontos para implantação imediata via kubectl.

Referência técnica e guia de arquitetura

Guia do Desenvolvedor do Gerador de HorizontalPodAutoscaler (HPA v2) do Kubernetes — Guia de referência

Crie manifestos YAML de HPA v2 com metas de utilização de CPU e memória, métricas personalizadas e políticas de estabilização de escala vertical e horizontal.

Parâmetros principais e controles

scaleTargetRefobjeto (apiVersion, kind, name)

Especifica a carga de trabalho de destino para o autoscaling, normalmente um Deployment, StatefulSet ou ReplicaSet sob apps/v1.

Padrão: { apiVersion: "apps/v1", kind: "Deployment", name: "my-app" }
minReplicas / maxReplicasinteiro (positivo)

Define os limites inferior e superior absolutos para a contagem de réplicas de pods. O controlador nunca escalará fora desse intervalo sob nenhuma condição de tráfego.

Padrão: minReplicas: 2, maxReplicas: 10
metricsarray (Resource | ContainerResource | Pods | Object | External)

Lista de regras de métricas avaliadas pelo controlador. Suporta métricas de recursos (averageUtilization ou averageValue para CPU/memória), ContainerResource e consultas personalizadas/externas.

Padrão: [{ type: "Resource", resource: { name: "cpu", target: { type: "Utilization", averageUtilization: 70 } } }]
behavior.scaleDownobjeto (stabilizationWindowSeconds, policies, selectPolicy)

Janela de estabilização e políticas de limitação de taxa aplicadas durante a redução de escala para evitar oscilações bruscas (flapping/thrashing).

Padrão: { stabilizationWindowSeconds: 300, selectPolicy: "Min", policies: [{ type: "Percent", value: 10, periodSeconds: 60 }] }
behavior.scaleUpobjeto (stabilizationWindowSeconds, policies, selectPolicy)

Configura a agressividade de expansão de escala para picos de tráfego, com atrasos de estabilização e políticas de crescimento acelerado por rajadas.

Padrão: { stabilizationWindowSeconds: 0, selectPolicy: "Max", policies: [{ type: "Percent", value: 100, periodSeconds: 15 }, { type: "Pods", value: 4, periodSeconds: 15 }] }

Dicas profissionais e melhores práticas

O controlador HPA calcula as

O controlador HPA calcula as porcentagens de uso exclusivamente sobre as 'resources.requests' dos contêineres, nunca sobre 'limits'. Se as requests forem omitidas no Deployment, o HPA exibirá o status '<unknown>/target%' e não escalará.

Configure

Configure 'behavior.scaleUp.stabilizationWindowSeconds: 0' para responder prontamente a picos de tráfego, mas mantenha 'behavior.scaleDown.stabilizationWindowSeconds: 300' (5 minutos). Isso evita variações contínuas quando o tráfego oscila perto do limiar.

Se sua aplicação possuir um PDB

Se sua aplicação possuir um PDB restritivo (como minAvailable: 80%), evite políticas de redução excessivamente bruscas (como remover 50% dos pods a cada 15s). Use 'type: Percent, value: 10' ou passos fixos de 1-2 pods para evitar falhas de despejo.

Executar HPA e VPA simultaneamente

Executar HPA e VPA simultaneamente para métricas de CPU ou memória gera conflito entre os ciclos de controle. Se precisar de ambos, direcione o HPA para métricas de negócio (como requisições HTTP ou filas) e reserve o VPA para o dimensionamento de recursos.

Problemas comuns e solução de problemas

O status do HPA exibe 'TARGETS: <unknown>/70%' e nenhuma réplica é criada.

Verifique se todos os contêineres do Deployment de destino definem 'resources.requests.cpu' (ou memória). Em seguida, garanta que o Kubernetes Metrics Server esteja operando corretamente executando 'kubectl top pods' e 'kubectl get apiservice v1beta1.metrics.k8s.io'.

A carga de trabalho sofre de oscilação contínua (sobe e desce réplicas repetidamente).

Aumente 'behavior.scaleDown.stabilizationWindowSeconds' para 300 a 600 segundos. Adicione políticas de redução com 'selectPolicy: Min' para que o encerramento de pods ocorra de forma gradual ao longo de vários minutos.

Métricas customizadas ou externas falham com 'unable to fetch metrics: metric not found'.

Verifique se o adaptador de métricas (por exemplo Prometheus Adapter, KEDA ou Datadog Cluster Agent) está implantado e registrado em 'kubectl get apiservices'. Certifique-se de que o nome da métrica e os seletores correspondam exatamente ao catálogo exposto.

Perguntas frequentes (FAQ)

Qual é a diferença fundamental entre autoscaling/v1 e autoscaling/v2?▼

A versão legada 'autoscaling/v1' permitia apenas dimensionar Deployments com base no percentual de uso de CPU. A versão 'autoscaling/v2' (padrão a partir do Kubernetes 1.23+) introduziu suporte simultâneo a múltiplas métricas (CPU, memória, métricas personalizadas e serviços externos), métricas por contêiner específico e políticas detalhadas de 'behavior' para estabilização.

Qual é o cálculo matemático utilizado pelo HPA para determinar réplicas?▼

O HPA utiliza a fórmula: réplicasDesejadas = ceil[réplicasAtuais * (valorMétricaAtual / valorMétricaAlvo)]. Por exemplo, se há 4 réplicas rodando a 80% de CPU com meta de 50%, o cálculo é ceil[4 * (80 / 50)] = ceil[6.4] = 7 réplicas. Se a razão estiver dentro de uma tolerância de 10% (0.9 a 1.1), nenhuma alteração de escala é aplicada.

Por que o autoscaling baseado em memória é considerado desafiador?▼

Diferente da CPU, cujo consumo cai instantaneamente no momento em que a carga cessa, linguagens e runtimes como Java (JVM), Go e Node.js tendem a reter a memória alocada ou postergar a coleta de lixo (GC). Isso faz com que a utilização de memória permaneça alta mesmo sem requisições ativas, bloqueando a redução de réplicas pelo HPA.

Como funcionam selectPolicy: Min e Max nas configurações de comportamento do HPA?▼

Ao configurar múltiplas políticas dentro de scaleUp ou scaleDown, o 'selectPolicy' define o critério de escolha: 'Min' seleciona a regra que resulta na menor alteração no número de réplicas (mais conservadora), enquanto 'Max' escolhe a de maior impacto (mais rápida). O scaleUp usa 'Max' como padrão para responder rapidamente a surtos de tráfego.

O HPA do Kubernetes oferece suporte a redução para zero réplicas (scale to zero)?▼

O HPA v2 nativo suporta 'minReplicas: 0' a partir do Kubernetes 1.23 (habilitado por padrão a partir do 1.28), porém estritamente para métricas customizadas ou externas (já que zero pods não produzem métricas de CPU/memória). Para arquiteturas orientadas a eventos com escala total a zero, recomenda-se o uso de KEDA ou Knative.

Ferramentas e utilitários relacionados

Todas as ferramentas →
Gerador e Otimizador de Configuração de Produção Redis (redis.conf)Desenvolvimento

Gere arquivos redis.conf ajustados para produção com políticas maxmemory, persistência RDB/AOF, vinculação de rede restrita e autenticação ACL robusta.

Abrir ferramenta→
Guia do Desenvolvedor: Otimizador e Gerador de Hardware para PostgreSQL (postgresql.conf)Desenvolvimento

Calcule e gere configurações otimizadas do postgresql.conf com base no hardware disponível (shared_buffers, work_mem, effective_cache_size, max_connections).

Abrir ferramenta→
Backup diário de banco de dadosDesenvolvimento

Crie e estruture unidades de temporizador systemd e serviços complementares prontos para produção com agendamento OnCalendar, intervalos OnBootSec, execução Persistent e atrasos aleatórios.

Abrir ferramenta→
Guia do Desenvolvedor do Gerador de Configuração TypeScript (tsconfig.json)Desenvolvimento

Gere configurações tsconfig.json modernas e robustas para Next.js, Node.js, Vite ou bibliotecas com modo estrito, aliases de caminho e resolução de módulos.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de DDL CREATE TABLE de JSON para ClickHouseDesenvolvimento

Converta documentos JSON de amostra em DDL SQL do ClickHouse com engine MergeTree, tipos UInt/Int/Float/String/DateTime e mapeamento de colunas Array/Nested.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de Esquema de Tabela Google BigQuery a partir de JSONDesenvolvimento

Infira e converta objetos JSON em esquemas de tabela JSON para o Google Cloud BigQuery com suporte a RECORD, STRING, INTEGER, NUMERIC e TIMESTAMP.

Abrir ferramenta→