Todos os produtos
Search
Central de documentação

Alibaba Cloud Service Mesh:Dimensione serviços automaticamente com base no tráfego

Última atualização: Jun 28, 2026

O Knative no ASM oferece o Knative Pod Autoscaler (KPA), um recurso pronto para uso que ajusta a escala dos serviços automaticamente conforme o tráfego de requisições. Caso seu serviço apresente instabilidade de desempenho ou desperdício de recursos devido a flutuações no tráfego, use o KPA para dimensioná-lo automaticamente. O KPA ajusta dinamicamente o número de instâncias do serviço ao monitorar e analisar dados de tráfego em tempo real. Isso garante a qualidade do serviço durante picos de demanda e economiza recursos em períodos de baixa atividade, aumentando a eficiência do sistema e reduzindo custos.

Pré-requisitos

Você já criou um Serviço Knative no Knative no ASM. Para mais informações, consulte Implantar uma aplicação serverless usando o Knative no ASM.

Nota

Este tópico usa o nome de domínio padrão example.com para fins de demonstração. Para usar um nome de domínio personalizado, consulte Usar um nome de domínio personalizado no Knative no ASM.

Funcionamento do dimensionamento automático

O Knative Serving injeta um contêiner Queue Proxy (queue-proxy) em cada pod. Esse contêiner reporta métricas de concorrência do contêiner da aplicação para o autoscaler. Em seguida, o autoscaler ajusta a quantidade de pods no Deployment com base no número de requisições simultâneas e no algoritmo de dimensionamento, habilitando o ajuste automático de escala.

扩缩容

Concorrência e QPS

Concorrência é a quantidade de requisições simultâneas que um pod processa. Já o QPS (consultas por segundo) indica quantas requisições um pod consegue processar por segundo, representando seu throughput máximo.

Sob carga elevada, uma alta concorrência pode sobrecarregar o sistema. Isso aumenta o consumo de CPU e memória, o que pode degradar o desempenho, elevar a latência de resposta e causar queda no QPS.

Algoritmo

O Knative Pod Autoscaler (KPA) dimensiona os pods com base na média de requisições concorrentes por pod. Por padrão, o Knative usa o dimensionamento baseado em concorrência, tendo como meta 100 requisições simultâneas por pod. O KPA também emprega uma porcentagem-alvo de utilização para decidir quando dimensionar.

No dimensionamento baseado em concorrência, o cálculo da quantidade de pods segue a fórmula: desired pods = Total Concurrent Requests / (Target Concurrency * Target Utilization)

Por exemplo, se a concorrência-alvo for 10 e a utilização-alvo for 0,7 (70%), uma entrada repentina de 100 requisições concorrentes fará o autoscaler dimensionar para 15 pods (100 / (10 * 0,7) ≈ 15).

O KPA opera em dois modos, Estável e Pânico, para responder adequadamente tanto a mudanças graduais quanto a picos repentinos de tráfego.

  • Modo Estável

    Neste modo, o KPA calcula a concorrência média em uma janela estável de 60 segundos e ajusta o número de pods de acordo.

  • Modo Pânico

    Este modo é ativado quando o tráfego aumenta subitamente. Ele calcula a concorrência média em uma janela de pânico muito mais curta, de 6 segundos por padrão. A janela de pânico é calculada como stable window * panic-window-percentage. A porcentagem padrão da janela de pânico é 10% (0,1). Quando o tráfego observado ultrapassa o limiar de pânico, o KPA aumenta rapidamente o número de pods para atender à demanda imediata.

O KPA decide entre o cálculo do Modo Estável ou do Modo Pânico com base no limiar de pânico. Esse limiar é calculado como panic-threshold-percentage / 100. O valor padrão de panic-threshold-percentage é 200, resultando em um limiar de pânico padrão de 2.

Se o número desejado de pods calculado no Modo Pânico for pelo menos o dobro da quantidade atual de pods prontos, o KPA aplicará o cálculo do Modo Pânico. Caso contrário, usará o cálculo do Modo Estável.

Configuração do KPA

A configuração global do KPA reside no ConfigMap config-autoscaler, localizado no namespace knative-serving. Execute o comando abaixo para visualizar a configuração padrão. Os principais parâmetros estão explicados a seguir.

kubectl -n knative-serving get cm config-autoscaler -o yaml

Saída esperada (comentários no código foram omitidos):

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  _example:
    container-concurrency-target-default: "100"
    container-concurrency-target-percentage: "0.7"
    enable-scale-to-zero: "true"
    max-scale-up-rate: "1000"
    max-scale-down-rate: "2"
    panic-window-percentage: "10"
    panic-threshold-percentage: "200"
    scale-to-zero-grace-period: "30s"
    scale-to-zero-pod-retention-period: "0s"
    stable-window: "60s"
    target-burst-capacity: "200"
    requests-per-second-target-default: "200"

Os parâmetros sob o campo _example exibem os valores padrão. Para alterar um parâmetro, copie-o do campo _example para o campo data e modifique seu valor.

Nota

Alterações no ConfigMap config-autoscaler afetam globalmente todos os Serviços Knative. Para configurar um Serviço Knative específico, use anotações. Para mais detalhes, visualize Caso de uso 1: Definir uma meta de concorrência para dimensionamento automático e Caso de uso 2: Definir limites de escala para dimensionamento automático.

Configure redução a zero

Parâmetro

Descrição

Valor de exemplo

scale-to-zero-grace-period

Tempo durante o qual uma Revision inativa permanece em execução antes de ser reduzida a zero. O valor mínimo é 30s.

30s

stable-window

No Modo Estável, o Autoscaler opera com base na concorrência média dentro desta janela. Além disso, é possível configurar a janela estável via anotação na Revision, por exemplo: autoscaling.knative.dev/window: 60s.

60s

enable-scale-to-zero

Defina este campo como true.

true

Configure a concorrência do autoscaler

Parâmetro

Descrição

Valor de exemplo

container-concurrency-target-default

Define o número desejado de requisições concorrentes (limite flexível). Esta é a configuração recomendada para o autoscaler no Knative. A meta de concorrência padrão no ConfigMap é 100.

Adicionalmente, é possível modificar esse valor com a anotação autoscaling.knative.dev/target na Revision, por exemplo: autoscaling.knative.dev/target: 50.

100

containerConcurrency

Limita o número de requisições concorrentes permitidas em um dado momento (limite rígido) para a Revision especificada.

  • 1: Garante que apenas uma requisição seja processada por vez por instância do contêiner.

  • 2-N: Restringe a concorrência para 2 ou mais requisições.

  • 0: Sem limite. O sistema determina a concorrência.

0

container-concurrency-target-percentage

A porcentagem de concorrência, também chamada de fator de concorrência, serve para calcular a meta efetiva de concorrência para o dimensionamento.Meta efetiva de concorrência = target (ou containerConcurrency) * container-concurrency-target-percentage. Por exemplo, se target ou containerConcurrency estiver definido como 100 e container-concurrency-target-percentage for 0.7, uma operação de scale-out será acionada quando a concorrência real atingir 70 (100 × 0,7).

0,7

Configure limites de escala

Use minScale e maxScale para definir o número mínimo e máximo de pods da sua aplicação. Essa configuração ajuda a controlar cold starts e custos computacionais.

Nota
  • Caso a anotação minScale não esteja definida, o serviço poderá reduzir a escala até zero pods.

  • Se a anotação maxScale não estiver configurada, não haverá limite superior para a criação de pods.

  • Ao definir enable-scale-to-zero como false no ConfigMap config-autoscaler, o serviço reduzirá a escala até um pod.

Configure minScale e maxScale no modelo da Revision conforme o exemplo:

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "2"
        autoscaling.knative.dev/maxScale: "10"

Caso de uso 1: Definir meta de concorrência

Este cenário demonstra como implantar a aplicação autoscale-go em um cluster e usar o KPA para dimensioná-la automaticamente definindo uma meta de concorrência.

Nota

Para mais detalhes sobre a criação de um Serviço Knative, consulte Implantar uma aplicação serverless usando o Knative no ASM.

  1. Crie o arquivo autoscale-go.yaml e defina a meta de concorrência como 10, ou seja, configure o valor de autoscaling.knative.dev/target para 10.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: autoscale-go
      namespace: default
    spec:
      template:
        metadata:
          labels:
            app: autoscale-go
          annotations:
            autoscaling.knative.dev/target: "10"
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
  2. Conecte-se ao seu cluster com kubectl e execute o comando abaixo para implantar a aplicação autoscale-go.

    kubectl apply -f autoscale-go.yaml
  3. Faça login no console do ASM. No painel de navegação à esquerda, clique em no nome da instância desejada. Escolha ASM Gateways > Ingress Gateway e obtenha o endereço IP na seção Service address.

  4. Use a ferramenta de teste de carga Hey para enviar tráfego com 50 requisições concorrentes durante 30 segundos.

    Para saber como instale e usar a ferramenta Hey, consulte o repositório oficial do Hey.

    Nota

    Substitua xxx.xxx.xxx.xxx pelo endereço real do seu gateway de acesso. Para mais informações, visualize Obter o endereço do gateway de acesso.

    hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://xxx.xxx.xxx.xxx?sleep=100&prime=10000&bloat=5"
    (base) xxx .kube % kubectl get deploy -w
    NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
    autoscale-go-00001-deployment     0/0     0            0           7m5s
    autoscale-go-00001-deployment     0/1     0            0           7m17s
    autoscale-go-00001-deployment     0/1     0            0           7m17s
    autoscale-go-00001-deployment     0/1     0            0           7m17s
    autoscale-go-00001-deployment     0/1     1            0           7m17s
    autoscale-go-00001-deployment     0/7     1            0           7m18s
    autoscale-go-00001-deployment     0/7     1            0           7m18s
    autoscale-go-00001-deployment     0/7     1            0           7m18s
    autoscale-go-00001-deployment     0/7     7            0           7m18s
    autoscale-go-00001-deployment     1/7     7            1           7m19s
    autoscale-go-00001-deployment     2/7     7            2           7m20s
    autoscale-go-00001-deployment     3/7     7            3           7m20s
    autoscale-go-00001-deployment     4/7     7            4           7m21s
    autoscale-go-00001-deployment     5/7     7            5           7m23s
    autoscale-go-00001-deployment     6/7     7            6           7m23s
    autoscale-go-00001-deployment     7/7     7            7           7m23s
    autoscale-go-00001-deployment     7/3     7            7           8m20s
    autoscale-go-00001-deployment     7/3     7            7           8m20s
    autoscale-go-00001-deployment     7/3     7            7           8m20s
    autoscale-go-00001-deployment     3/3     3            3           8m20s
    autoscale-go-00001-deployment     3/2     3            3           8m26s
    autoscale-go-00001-deployment     3/2     3            3           8m26s
    autoscale-go-00001-deployment     2/2     2            2           8m26s
    autoscale-go-00001-deployment     2/1     2            2           8m36s
    autoscale-go-00001-deployment     2/1     2            2           8m36s
    autoscale-go-00001-deployment     1/1     1            1           8m36s
    autoscale-go-00001-deployment     1/0     1            1           9m48s
    autoscale-go-00001-deployment     1/0     1            1           9m48s
    autoscale-go-00001-deployment     0/0     0            0           9m48s

    A saída mostra que o serviço escalou horizontalmente para 7 pods. Isso ocorre porque o Knative cria proativamente mais pods quando a concorrência dos contêineres excede uma certa porcentagem da meta (70% por padrão). Essa medida evita que a meta seja violada caso a concorrência continue aumentando.

Caso de uso 2: Definir limites de escala

Os limites de escala estabelecem o número mínimo e máximo de pods para uma aplicação. Este exemplo ilustra como implantar a aplicação autoscale-go e dimensioná-la automaticamente por meio desses limites.

Nota

Para mais informações sobre como crie um Serviço Knative, consulte Implantar uma aplicação serverless usando o Knative no ASM.

  1. Crie um arquivo chamado autoscale-go.yaml. Configure a meta de concorrência para 10, o mínimo de instâncias (minScale) para 1 e o máximo de instâncias (maxScale) para 3.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: autoscale-go
      namespace: default
    spec:
      template:
        metadata:
          labels:
            app: autoscale-go
          annotations:
            autoscaling.knative.dev/target: "10"
            autoscaling.knative.dev/minScale: "1"
            autoscaling.knative.dev/maxScale: "3"
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
  2. Conecte-se ao seu cluster com kubectl e execute o seguinte comando para implantar a aplicação autoscale-go.

    kubectl apply -f autoscale-go.yaml
  3. Acesse o console do ASM. No painel de navegação à esquerda, clique em no nome da instância alvo. Selecione ASM Gateways > Ingress Gateway e obtenha o endereço IP na seção Service address.

  4. Use a ferramenta de teste de carga Hey para gerar tráfego com 50 requisições simultâneas por 30 segundos.

    Para instruções sobre instalação e uso da ferramenta Hey, visite o repositório oficial do Hey.

    Nota

    Troque xxx.xxx.xxx.xxx pelo endereço real do seu gateway de acesso. Consulte Obter o endereço do gateway de acesso para mais detalhes.

    hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://xxx.xxx.xxx.xxx?sleep=100&prime=10000&bloat=5"
    kubectl get deploy -w
    
    Expected output:
    text
    NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
    autoscale-go-00001-deployment     1/1     1            1           115s
    autoscale-go-00001-deployment     1/2     1            1           2m4s
    autoscale-go-00001-deployment     1/2     1            1           2m4s
    autoscale-go-00001-deployment     1/2     1            1           2m4s
    autoscale-go-00001-deployment     1/2     2            1           2m4s
    autoscale-go-00001-deployment     2/2     2            2           2m6s
    autoscale-go-00001-deployment     2/3     2            2           2m6s
    autoscale-go-00001-deployment     2/3     2            2           2m6s
    autoscale-go-00001-deployment     2/3     2            2           2m6s
    autoscale-go-00001-deployment     2/3     3            2           2m6s
    autoscale-go-00001-deployment     3/3     3            3           2m8s
    autoscale-go-00001-deployment     3/1     3            3           3m34s
    autoscale-go-00001-deployment     3/1     3            3           3m34s
    autoscale-go-00001-deployment     1/1     1            1           3m34s

    A saída indica que o serviço escalou horizontalmente até o máximo de 3 pods. Na ausência de tráfego de requisições, o serviço reduziu a escala para o mínimo de 1 pod. Isso confirma que o dimensionamento automático está funcionando conforme o esperado.

Documentação relacionada

  • Para acessar e gerencie microsserviços construídos com Knative de forma segura, use um gateway do ASM para ative o acesso HTTPS. Criptografar o tráfego para os endpoints do serviço protege a comunicação e melhora a segurança e confiabilidade da sua arquitetura. Para mais informações, consulte Acessar um Serviço Knative via HTTPS usando um gateway do ASM.

  • Ao enfrentar desafios de compatibilidade e estabilidade durante atualizações de aplicações, realize uma canary release para seu Serviço Knative no Knative no ASM. Visualize mais em Realizar uma canary release para um Serviço Knative no Knative no ASM.

  • É possível defina um limiar de métrica de CPU para um Serviço Knative, permitindo que os recursos sejam dimensionados automaticamente em resposta a picos repentinos de carga. Saiba mais em Usar HPA no Knative.