Todos os produtos
Search

Este produto

    Alibaba Cloud Service Mesh:Use o recurso de aquecimento do ASM

    Central de documentação

    Alibaba Cloud Service Mesh:Use o recurso de aquecimento do ASM

    Última atualização: Jun 28, 2026

    Use o recurso de aquecimento do ASM ao escalar horizontalmente sua aplicação, implantar uma nova versão ou prever um pico de tráfego. Esse recurso aumenta gradualmente o tráfego de requisições para novas instâncias dentro de uma janela de tempo personalizada. O processo garante uma transição suave e reduz o risco de interrupções de serviço, tempos limite de requisição e perda de dados causados por aumentos repentinos de tráfego. Além disso, ajuda a manter o desempenho estável e a alta disponibilidade durante o dimensionamento e as atualizações da aplicação.

    Pré-requisitos

    Informações de fundo

    Sem o recurso de aquecimento, novos pods recebem imediatamente sua parcela total de tráfego, sem aumento gradual. Isso pode ser problemático para serviços que exigem um período de aquecimento para atingir o desempenho ideal, como aplicações baseadas em JVM que precisam realizar compilação Just-In-Time (JIT) ou preencher caches grandes. Essa carga repentina pode causar tempos limite de requisição, perda de dados e degradação da experiência do usuário. O recurso de aquecimento resolve esse problema introduzindo tráfego gradualmente nas novas instâncias, permitindo que elas se preparem para atender requisições com capacidade total.

    Recurso de aquecimento

    O recurso de aquecimento, também conhecido como início lento ou aumento progressivo de tráfego, permite configurar um período de tempo para um serviço. Quando uma instância de serviço é iniciada, o cliente envia uma fração da carga de requisições para essa instância e aumenta gradualmente a taxa de requisições durante a duração configurada. Ao final do período de aquecimento, a instância passa a receber sua parcela total de tráfego.

    No modo de início lento, novos pods são protegidos contra sobrecarga por picos repentinos de requisições. Isso permite que as novas instâncias realizem o aquecimento durante um período de rampa antes de receberem sua cota integral de tráfego.

    Esse recurso é útil para aplicações que dependem de cache e necessitam de um período de preparação para responder às requisições com desempenho otimizado. No ASM, basta configurar a seção trafficPolicy/loadBalancer da DestinationRule correspondente ao serviço. Observe os seguintes parâmetros:

    • loadBalancer: especifica as configurações do balanceador de carga. Este recurso suporta apenas os balanceadores ROUND_ROBIN e LEAST_REQUEST.

    • warmupDurationSecs: define a duração do aquecimento para o serviço. Se configurado, um endpoint de serviço recém-criado permanece no modo de aquecimento por essa duração, contada a partir do momento de sua criação. Durante essa janela, o Istio aumenta gradualmente o tráfego para o endpoint, em vez de enviar imediatamente uma parcela proporcional de tráfego.

    Nota

    O recurso de aquecimento exige que o número de réplicas da aplicação na zona de disponibilidade atual não seja zero. Por exemplo:

    • Se o cluster do plano de dados tiver apenas uma zona de disponibilidade, Zona A, e houver atualmente uma réplica nessa zona, o recurso de aquecimento entrará em vigor quando uma segunda réplica for iniciada.

    • Caso o cluster do plano de dados possua duas zonas de disponibilidade, Zona A e Zona B, e a única réplica existente esteja na Zona A, iniciar uma segunda réplica na Zona B não acionará o recurso de aquecimento. Isso pode ocorrer porque alguns agendadores distribuem réplicas entre zonas de disponibilidade por padrão. Nesse cenário, o recurso de aquecimento entrará em vigor quando uma terceira réplica for iniciada.

    A seguir, um exemplo de DestinationRule no formato YAML:

    apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: mocka
spec:
  host: mocka
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 100s

    Etapa 1: Configurar roteamento e acessar o gateway

    Para demonstração, escale as réplicas do Deployment reviews-v3 para 0.

    1. Defina os recursos de entrada.

      1. Crie um arquivo chamado bookinfo-gateway.yaml com o seguinte conteúdo.

        bookinfo-gateway.yaml

        apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: bookinfo
spec:
  gateways:
    - bookinfo-gateway
  hosts:
    - '*'
  http:
    - match:
      - uri:
          exact: /productpage
      - uri:
          prefix: /static
      - uri:
          exact: /login
      - uri:
          exact: /logout
      - uri:
          prefix: /api/v1/products
      route:
        - destination:
            host: productpage
            port:
              number: 9080
    - match:
      - uri:
          prefix: /reviews
      route:
        - destination:
            host: reviews
            port:
              number: 9080

      2. Execute o comando a seguir para implantar o gateway e o serviço virtual.

        kubectl apply -f bookinfo-gateway.yaml

    2. Crie a DestinationRule para o serviço Reviews.

      1. Crie um arquivo chamado reviews.yaml com o seguinte conteúdo.

        reviews.yaml

        apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

      2. Execute o comando a seguir para implantar a DestinationRule.

        kubectl apply -f reviews.yaml

    3. Ative a topologia de malha e acesse continuamente o endereço do gateway de entrada.

      Este tópico utiliza o comando hey para enviar requisições de teste de carga por 10s. Para obter informações sobre como baixar e instalar o hey, consulte hey. Para mais detalhes sobre como ativar e visualizar a topologia de malha, veja Visualizar a topologia de malha de uma aplicação.

      hey -z 10s -q 100 -c 4 http://${INGRESS_GATEWAY_ADDRESS}/reviews/0

      A figura a seguir mostra um exemplo de topologia de chamadas:image

    Etapa 2: Observar a inicialização do pod

    1. Faça login no console do ASM.

    2. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

    3. Na página Mesh Management, localize a instância do ASM que deseja configurar. Clique no nome da instância do ASM ou clique em Manage na coluna Actions.

    4. No painel de navegação à esquerda, escolha Observability Management Center > Monitoring metrics.

      • Para instâncias do ASM anteriores à versão 1.17.2.35: Na página Monitoring metrics, clique na aba Monitoring instrument, depois clique na aba Cloud ASM Istio Service e selecione o serviço Reviews.

      • Para instâncias do ASM da versão 1.17.2.35 e posteriores: Na página Monitoring metrics, clique na aba Cloud ASM Istio Work load, selecione o workload reviews-v3 e defina Reporter como source.

    5. Envie requisições de teste de carga e observe os dados de monitoramento.

      1. Com o recurso de aquecimento desativado, escale as réplicas do Deployment reviews-v3 de 0 para 1.

      2. Execute o comando a seguir para enviar requisições de teste de carga ao gateway de entrada.

        Este exemplo envia requisições de teste de carga por 120s.

        hey -z 120s -q 100 -c 4 http://${INGRESS_GATEWAY_ADDRESS}/reviews/0

      3. Observe os dados no painel de monitoramento do Prometheus.

        Leva cerca de 45 segundos para que o pod reviews-v3 receba uma parcela equilibrada de requisições. O tempo real pode variar dependendo do seu ambiente de teste de carga.image

    6. Escale as réplicas do Deployment reviews-v3 de volta para 0.

    Etapa 3: Ativar o recurso de aquecimento

    1. Atualize o arquivo reviews.yaml com o seguinte conteúdo.

      Adicione o campo warmupDurationSecs e defina-o como 120s, o que estabelece a duração do aquecimento em 120 segundos.

      apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 120s

    2. Execute o comando a seguir para aplicar a atualização.

      kubectl apply -f reviews.yaml

    Etapa 4: Verificar o efeito do aquecimento

    1. Após ativar o recurso de aquecimento, escale as réplicas do Deployment reviews-v3 de 0 para 1.

    2. Execute o comando a seguir para enviar requisições de teste de carga ao gateway de entrada.

      Este exemplo envia requisições de teste de carga por 150s.

      hey -z 150s -q 100 -c 4 http://${INGRESS_GATEWAY_ADDRESS}/reviews/0

    3. Na aba Cloud ASM Istio Service, observe os dados no painel de monitoramento do Prometheus.

      Leva cerca de 120 segundos para que o pod reviews-v3 receba uma parcela equilibrada de requisições. O tempo real pode variar dependendo do seu ambiente de teste de carga.image A curva pode parecer escalonada porque as métricas são coletadas em intervalos. Na realidade, o tráfego para o pod reviews-v3 aumenta suavemente. Se você ativar a coleta de logs do sidecar, poderá pesquisar os logs desse sidecar no Simple Log Service (SLS) para visualizar o volume de logs nos últimos 5 minutos.image Conforme esperado com o recurso de aquecimento, uma nova instância recebe inicialmente uma fração do tráfego, que então aumenta suavemente durante a duração configurada até atingir sua parcela total.

      Depois que o recurso de aquecimento é ativado, leva cerca de 2 minutos e 30 segundos para que o tráfego seja distribuído uniformemente entre as versões v1, v2 e v3. Na visualização Service Graph do Kiali, o istio-ingressgateway distribui o tráfego quase igualmente entre as versões v1, v2 e v3 do serviço Reviews, com 33,3%, 33,3% e 33,4%, respectivamente. As versões v2 e v3 então chamam o serviço ratings v1, o que indica que o tráfego está equilibrado após a conclusão do aquecimento.

    Documentos relacionados