Todos os produtos
Search
Central de documentação

Alibaba Cloud Service Mesh:Como a recomendação de sidecar otimiza a distribuição de configuração

Última atualização: Jun 28, 2026

Por padrão, o plano de controle do Alibaba Cloud Service Mesh (ASM) distribui a configuração de todos os serviços para cada proxy sidecar, independentemente de um workload se comunicar com esses serviços. Em clusters pequenos, o impacto é negligenciável. Em grande escala -- centenas de serviços, milhares de pods -- a distribuição de configuração em malha completa causa dois problemas:

  • Configurações de sidecar volumosas. Cada proxy mantém dados de roteamento, cluster e listener para todos os serviços da malha, consumindo memória e CPU.

  • Distribuição de configuração lenta. Quando a configuração de qualquer serviço muda, o plano de controle precisa enviar atualizações para cada sidecar, aumentando a latência e a carga do plano de controle.

O recurso de recomendação de sidecar resolve isso analisando os logs de acesso para determinar as dependências reais de cada workload e, em seguida, gerando um recurso Sidecar que restringe a configuração do proxy apenas aos serviços de que o workload precisa.

O teste a seguir usa um cluster com 420 pods para quantificar o impacto no tamanho da configuração e no desempenho da distribuição.

Resultados em resumo

MétricaAntes da recomendação de sidecarDepois da recomendação de sidecarMelhoria
Tamanho da configuração do sidecar1,2 MB105 KBRedução de ~10x
Configurações de serviços não relacionados distribuídasSim (todos os 420 pods)Não (apenas pods dependentes)Restrito às dependências
Tempo de distribuição de configuração~4 segundos~0,01 segundos~400x mais rápido

Pré-requisitos

Antes de começar, verifique se você tem:

Etapa 1: Implantar aplicativos de teste

Implante vários aplicativos HTTPBin e sleep no namespace ns-in-mesh para simular um cluster grande com dependências de serviço esparsas. Para obter mais informações sobre como criar um namespace, consulte Gerenciar namespaces globais.

  • Os aplicativos HTTPBin expõem um serviço HTTP na porta 8000, simulando os vários serviços de um cluster de produção.

  • Os aplicativos Sleep contêm um contêiner curl que chama um subconjunto de serviços HTTPBin antes de entrar em repouso, simulando workloads com dependências de chamada específicas.

O cluster de teste totaliza 420 pods: 200 aplicativos HTTPBin (2 réplicas cada = 400 pods) e 20 aplicativos sleep (1 réplica cada = 20 pods). Cada aplicativo sleep depende de 10 serviços HTTPBin.

Implantar aplicativos HTTPBin

  1. Crie um arquivo YAML chamado httpbin-{i}.yaml com base no modelo a seguir. Substitua {i} por um número único (de 0 a 199) para criar 200 aplicativos HTTPBin distintos.

    Modelo YAML do aplicativo HTTPBin

       apiVersion: v1
       kind: ServiceAccount
       metadata:
         name: httpbin
       ---
       apiVersion: v1
       kind: Service
       metadata:
         creationTimestamp: null
         labels:
           app: httpbin-{i}
           service: httpbin-{i}
         name: httpbin-{i}
       spec:
         ports:
         - name: http
           port: 8000
           targetPort: 80
         selector:
           app: httpbin-0
       ---
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         creationTimestamp: null
         labels:
           app: httpbin-{i}
         name: httpbin-{i}
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: httpbin-{i}
             version: v1
         template:
           metadata:
             creationTimestamp: null
             labels:
               app: httpbin-{i}
               version: v1
           spec:
             containers:
             - image: docker.io/kennethreitz/httpbin
               imagePullPolicy: IfNotPresent
               name: httpbin
               ports:
               - containerPort: 80
             serviceAccountName: httpbin
  2. Aplique o arquivo YAML: Saída esperada:

       kubectl apply -f httpbin-{i}.yaml
       deployment.apps/httpbin-{i} created

Implantar aplicativos sleep

  1. Crie um arquivo YAML chamado sleep-{i}.yaml com base no modelo a seguir. Substitua {i} por um número único (de 0 a 19). O campo args contém comandos curl para 10 serviços HTTPBin (httpbin-{i*10} a httpbin-{i*10+9}), simulando dependências de chamada.

    Nota

    Os IDs do HTTPBin nos comandos curl não devem exceder o ID máximo do HTTPBin implantado. Caso contrário, as chamadas falharão.

    Modelo YAML do aplicativo sleep

       apiVersion: v1
       kind: ServiceAccount
       metadata:
         name: sleep
       ---
       apiVersion: v1
       kind: Service
       metadata:
         creationTimestamp: null
         labels:
           app: sleep-{i}
           service: sleep-{i}
         name: sleep-{i}
       spec:
         ports:
         - name: http
           port: 80
           targetPort: 0
         selector:
           app: sleep-{i}
       ---
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         creationTimestamp: null
         labels:
           app: sleep-{i}
         name: sleep-{i}
       spec:
         replicas: 1
         selector:
           matchLabels:
             app: sleep-{i}
         template:
           metadata:
             creationTimestamp: null
             labels:
               app: sleep-{i}
           spec:
             containers:
             - args:
               - curl httpbin-{i*10}:8000; curl httpbin-{i*10+1}:8000; curl httpbin-{i*10+2}:8000; curl httpbin-{i*10+3}:8000;
                 curl httpbin-{i*10+4}:8000; curl httpbin-{i*10+5}:8000; curl httpbin-{i*10+6}:8000; curl httpbin-{i*10+7}:8000;
                 curl httpbin-{i*10+8}:8000; curl httpbin-{i*10+9}:8000; sleep 3650d
               command:
               - /bin/sh
               - -c
               image: curlimages/curl
               imagePullPolicy: IfNotPresent
               name: sleep
               volumeMounts:
               - mountPath: /etc/sleep/tls
                 name: secret-volume
             serviceAccountName: sleep
             terminationGracePeriodSeconds: 0
             volumes:
             - name: secret-volume
               secret:
                 optional: true
                 secretName: sleep-secret
  2. Aplique o arquivo YAML: Saída esperada:

       kubectl apply -f sleep-{i}.yaml
       deployment.apps/sleep-{i} created

Etapa 2: Medir o desempenho inicial (antes da recomendação de sidecar)

Com 420 pods em execução e sem recomendação de sidecar, meça o tamanho da configuração e o desempenho da distribuição.

Medir o tamanho da configuração do sidecar

  1. Obtenha os nomes dos pods do aplicativo httpbin-0: Saída esperada:

       kubectl get pod -n ns-in-mesh | grep httpbin-0
       NAME                         READY   STATUS    RESTARTS   AGE
       httpbin-0-756995d867-jljgp   2/2     Running   0          9m15s
       httpbin-0-756995d867-whstr   2/2     Running   0          9m15s
  2. Despeje a configuração do sidecar em um arquivo local:

       kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n ns-in-mesh -- curl -s localhost:15000/config_dump > config_dump.json
  3. Verifique o tamanho do arquivo: Saída esperada:

       du -sh config_dump.json
       1.2M    config_dump.json

Cada sidecar contém 1,2 MB de configuração -- dados de roteamento, cluster e listener para todos os 420 pods. Em todos os proxies da malha, isso gera sobrecarga significativa de memória e aumenta a carga de distribuição do plano de controle.

Medir o desempenho da distribuição de configuração

Acione uma distribuição de configuração criando um serviço virtual e observe os logs do plano de controle para medir a duração e o escopo da distribuição.

  1. Crie um serviço virtual para o aplicativo httpbin-0. Para obter mais informações, consulte Gerenciar serviços virtuais.

       apiVersion: networking.istio.io/v1beta1
       kind: VirtualService
       metadata:
         name: httpbin-0-timeout
         namespace: default
       spec:
         hosts:
           - httpbin-0.default.svc.cluster.local
         http:
           - route:
               - destination:
                   host: httpbin-0.default.svc.cluster.local
             timeout: 5s
  2. Visualize os logs do plano de controle para observar o comportamento da distribuição.

    Para o ASM versão 1.17.2.35 ou posterior:

    1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

    2. Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha Observability Management Center > Log Center.

    3. Na página Log Center, clique na guia Control-Plane Logs.

    Para versões do ASM anteriores à 1.17.2.35:

    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, clique no nome da instância do ASM.

    4. Escolha ASM Instance > Base Information.

    5. Clique em View log ao lado de Control-plane log collection.

    Para obter mais informações, consulte Ativar a coleta de logs do plano de controle e alertas baseados em log em uma instância do ASM anterior à versão 1.17.2.35.

    Logs de amostra:

       2021-12-01T10:20:09.708673Z info  ads CDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:227 size:169.3kB
       2021-12-01T10:20:09.710469Z info  ads CDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:227 size:169.3kB
       2021-12-01T10:20:09.713567Z info  ads CDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:227 size:169.3kB
       2021-12-01T10:20:09.714514Z info  ads LDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:16 size:70.7kB
       2021-12-01T10:20:09.792732Z info  ads LDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:16 size:70.7kB
       2021-12-01T10:20:09.792982Z info  ads LDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:16 size:70.7kB
       2021-12-01T10:20:09.796430Z info  ads RDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:8 size:137.4kB
       ...
       2021-12-01T10:20:13.405850Z info  ads RDS: PUSH for node:httpbin-156-68b85b4f79-2znmp.default resources:8 size:137.4kB
       2021-12-01T10:20:13.406154Z info  ads RDS: PUSH for node:httpbin-121-7c4cff97b9-sn5g4.default resources:8 size:137.4kB
       2021-12-01T10:20:13.406420Z info  ads CDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:227 size:169.3kB
       2021-12-01T10:20:13.407230Z info  ads LDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:16 size:70.7kB
       2021-12-01T10:20:13.410147Z info  ads RDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:8 size:137.4kB
       2021-12-01T10:20:13.494840Z info  ads RDS: PUSH for node:httpbin-57-69b756f779-db7vv.default resources:8 size:137.4kB

    Principais observações:

    • O plano de controle distribui a alteração do serviço virtual httpbin-0 para cada sidecar -- incluindo pods sem dependência do httpbin-0.

    • Cada distribuição carrega 227 recursos do Cluster Discovery Service (CDS) (169,3 KB), 16 recursos do Listener Discovery Service (LDS) (70,7 KB) e 8 recursos do Route Discovery Service (RDS) (137,4 KB).

    • O ciclo completo de distribuição vai de 10:20:09 a 10:20:13 -- aproximadamente 4 segundos para propagar uma única alteração de serviço virtual para 420 pods.

Etapa 3: Ativar a recomendação de sidecar

Ative a recomendação de sidecar para gerar um recurso Sidecar para cada workload com base em suas dependências de chamada reais observadas nos logs de acesso. Para obter instruções detalhadas, consulte Usar os sidecars recomendados automaticamente com base na análise de logs de acesso.

Após ativar a recomendação de sidecar, cada proxy recebe configuração apenas para os serviços que realmente chama, em vez de todos os serviços da malha.

Etapa 4: Medir o desempenho otimizado (após a recomendação de sidecar)

Medir o tamanho da configuração do sidecar

  1. Despeje a configuração do sidecar novamente:

       kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n ns-in-mesh -- curl -s localhost:15000/config_dump > config_dump.json
  2. Verifique o tamanho do arquivo: Saída esperada:

       du -sh config_dump.json
       105k    config_dump.json

O tamanho da configuração caiu de 1,2 MB para 105 KB -- uma redução de mais de 10x, o que se traduz diretamente em menor consumo de memória por proxy.

Medir o desempenho da distribuição de configuração

  1. Exclua o serviço virtual criado anteriormente e, em seguida, recrie-o para acionar um novo ciclo de distribuição. Para obter mais informações, consulte Gerenciar serviços virtuais.

       apiVersion: networking.istio.io/v1beta1
       kind: VirtualService
       metadata:
         name: httpbin-0-timeout
         namespace: default
       spec:
         hosts:
           - httpbin-0.default.svc.cluster.local
         http:
           - route:
               - destination:
                   host: httpbin-0.default.svc.cluster.local
             timeout: 5s
  2. Visualize os logs do plano de controle usando o mesmo método descrito na Etapa 2.

    Logs de amostra:

       2021-12-01T12:12:43.498048Z info  ads Push debounce stable[750] 1: 100.03379ms since last change, 100.033692ms since last push, full=true
       2021-12-01T12:12:43.504270Z info  ads XDS: Pushing:2021-12-01T12:12:43Z/493 Services:230 ConnectedEndpoints:421  Version:2021-12-01T12:12:43Z/493
       2021-12-01T12:12:43.507451Z info  ads CDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:14 size:7.8kB
       2021-12-01T12:12:43.507739Z info  ads LDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:3 size:15.5kB
       2021-12-01T12:12:43.508029Z info  ads RDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:1 size:6.3kB

    Principais observações:

    • O plano de controle distribui a alteração apenas para sleep-0 -- o único workload com dependência do httpbin-0. Todos os outros pods não são afetados.

    • O payload da distribuição caiu drasticamente: 14 recursos CDS (7,8 KB), 3 recursos LDS (15,5 KB) e 1 recurso RDS (6,3 KB).

    • A distribuição completa leva aproximadamente 0,01 segundos, em comparação com 4 segundos antes da otimização -- uma melhoria de ~400x.

Resumo

Este teste simula um cluster de grande escala com dependências de serviço esparsas: 200 serviços HTTPBin (400 pods) e 20 aplicativos sleep (20 pods), cada um dependendo de apenas 10 dos 200 serviços.

MétricaAntes da recomendação de sidecarDepois da recomendação de sidecar
Tamanho da configuração do sidecar1,2 MB105 KB
Configurações de serviços não relacionados distribuídasSimNão
Tempo de distribuição de configuração~4 segundos~0,01 segundos

A recomendação de sidecar gera as melhorias mais significativas em clusters nos quais:

  • Um grande número de serviços está implantado em um único namespace

  • A maioria dos workloads depende de apenas um pequeno subconjunto dos serviços disponíveis

  • A latência da distribuição de configuração ou o consumo de recursos do plano de controle é uma preocupação

Para clusters que correspondem a essas características, ativar a recomendação de sidecar reduz o consumo de memória dos proxies e acelera a convergência da configuração.

Próximas etapas