Todos os produtos
Search

Este produto

    Alibaba Cloud Service Mesh:Efeitos da otimização de push de configuração após a aplicação de um recurso Sidecar

    Central de documentação

    Alibaba Cloud Service Mesh:Efeitos da otimização de push de configuração após a aplicação de um recurso Sidecar

    Última atualização: Aug 28, 2026

    Um recurso Sidecar limita a configuração que o plano de controle do Alibaba Cloud Service Mesh (ASM) envia para cada Sidecar do plano de dados. O recurso de recomendação de recursos Sidecar minimiza essa configuração. Um teste em um cluster com 420 pods analisa a eficiência do push de configuração antes e depois da aplicação de um recurso Sidecar recomendado.

    Pré-requisitos

    Ambiente de teste

    O teste implanta vários aplicativos sleep e httpbin em um único namespace gerenciado pela instância ASM. Um Sidecar é injetado em cada pod de teste, e o cluster contém muitos serviços com poucas dependências de chamada entre si. Este tópico usa o namespace default, referenciado pelos manifestos de exemplo, comandos e logs do plano de controle. Para mais informações sobre namespaces em uma instância ASM, consulte Manage global namespaces.

    • Aplicativos httpbin: Após a inicialização, o aplicativo httpbin expõe um service HTTP na porta 8000. Esse aplicativo simula a grande quantidade de serviços chamados dentro do cluster. O teste gera 200 deployments do aplicativo httpbin e implanta 400 pods desse aplicativo no cluster.

    • Aplicativos sleep: O aplicativo sleep contém um contêiner curl. Modifique o campo command do deployment do aplicativo para que ele chame os serviços fornecidos por vários contêineres httpbin antes de entrar em estado de espera. Esse aplicativo simula um service no cluster que depende de outros serviços. O teste atribui a cada aplicativo sleep uma dependência de 10 aplicativos httpbin. Portanto, são implantados 20 deployments e 20 pods do aplicativo sleep no total.

    • Escala do cluster: O cluster de teste executa um total de 420 pods.

    Implantar os aplicativos de teste no cluster

    1. Implante vários aplicativos httpbin no cluster.

      1. Use o conteúdo YAML a seguir para criar um arquivo yaml chamado httpbin-{i}.yaml.

        Nota

        Em httpbin-{i}, substitua {i} por um número específico para gerar múltiplos serviços httpbin numerados. Use este modelo para gerar qualquer quantidade de aplicativos httpbin. O número máximo de aplicativos depende do tamanho do seu cluster.

        O conteúdo YAML a seguir define o ServiceAccount, o Service e o Deployment de um aplicativo httpbin numerado:

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
  namespace: default
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
    service: httpbin-{i}
  name: httpbin-{i}
  namespace: default
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin-{i}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
  name: httpbin-{i}
  namespace: default
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. Execute o comando a seguir para criar o aplicativo httpbin-{i}.

        kubectl apply -f httpbin-{i}.yaml -n default

        Saída esperada:

        deployment.apps/httpbin-{i} created

    2. Implante os aplicativos sleep no cluster.

      1. Use o conteúdo YAML a seguir para criar um arquivo yaml chamado sleep-{i}.yaml.

        Nota

        Em sleep-{i}, substitua {i} por um número específico para gerar múltiplos serviços sleep numerados. Neste modelo, adicione o parâmetro de comando curl httpbin-{i*10}:8000 ao campo args do deployment do aplicativo sleep para simular chamadas a diferentes aplicativos httpbin. O número do service httpbin chamado não deve exceder a quantidade de serviços httpbin implantados anteriormente. Caso contrário, a chamada será inválida.

        O conteúdo YAML a seguir define o ServiceAccount, o Service e o Deployment de um aplicativo sleep numerado:

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
  namespace: default
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: sleep-{i}
    service: sleep-{i}
  name: sleep-{i}
  namespace: default
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}
  namespace: default
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. Execute o comando a seguir para criar o aplicativo sleep-{i}.

        kubectl apply -f sleep-{i}.yaml -n default

        Saída esperada:

        deployment.apps/sleep-{i} created

    Testar o push de configuração do plano de controle antes da aplicação de um recurso Sidecar

    Antes de aplicar um recurso Sidecar, meça dois valores de linha de base no cluster de teste: o tamanho da configuração do Sidecar em um único pod e o tempo necessário para o plano de controle do ASM concluir um push de configuração.

    Tamanho da configuração do Sidecar antes da aplicação de um recurso Sidecar

    1. Execute o comando a seguir para identificar o nome do pod do aplicativo httpbin-0.

      kubectl get pod -n default | grep httpbin-0

      Saída esperada:

      NAME                         READY   STATUS    RESTARTS   AGE
httpbin-0-756995d867-jljgp   2/2     Running   0          9m15s
httpbin-0-756995d867-whstr   2/2     Running   0          9m15s

    2. Execute o comando a seguir para baixar a configuração do Sidecar do pod que executa o aplicativo httpbin-0 para sua máquina local. Substitua httpbin-0-756995d867-jljgp pelo nome de um pod retornado na etapa anterior.

      kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n default -- curl -s localhost:15000/config_dump > config_dump.json

    3. Execute o comando a seguir para visualizar o tamanho do arquivo de configuração do Sidecar.

      du -sh config_dump.json

      Saída esperada:

      1.2M    config_dump.json

    A saída esperada mostra que a configuração do Sidecar tem cerca de 1,2 MB no cenário de teste com 420 pods implantados no cluster. Se um Sidecar for implantado para cada pod no cluster, o grande volume de configurações aumentará a carga de push no plano de controle.

    Eficiência de push do plano de controle antes da aplicação de um recurso Sidecar

    Aplique uma nova regra de service virtual ao service httpbin-0 no ASM para acionar um push de configuração do plano de controle para os Sidecars no plano de dados. O conteúdo dos logs do plano de controle indica a eficiência com que ele conclui um único push. A coleta de logs do plano de controle já deve estar ativada, conforme descrito em Prerequisites.

    1. Use o conteúdo YAML a seguir para criar um service virtual no ASM que aplique tratamento de timeout ao service httpbin-0. Para mais informações sobre como criar um service virtual, consulte Manage virtual services.

      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 gerados pelo plano de controle. O caminho de navegação no console depende da versão da sua instância ASM.

      Versão da instância ASM 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 em o nome da instância ASM. No painel de navegação à esquerda, escolha Observability Management Center > Log Center.

      3. Na página Log Center, clique em a aba Control-Plane Logs para visualizar os logs.

      Versão da instância ASM anterior a 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 em o nome da instância de destino.

      4. Na página de detalhes do mesh, escolha Instance Information > Base Information.

      5. Na página Basic Information, clique em View log à direita de Control-plane log collection.

      O trecho a seguir mostra exemplos de logs:

      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

    No ambiente de teste com 420 pods implantados, adicionar um service virtual faz com que o plano de controle envie a alteração para todos os Sidecars no plano de dados. Isso gera uma grande quantidade de logs de push, e cada push transfere um volume significativo de dados. Aplicar uma regra de service virtual no ASM exige que o plano de controle realize pushes por até cerca de 4 segundos, o que indica baixa eficiência de push no plano de controle.

    Testar o push de configuração do plano de controle após a aplicação de um recurso Sidecar

    Aplique um recurso Sidecar recomendado no mesmo cluster de teste e repita as duas medições para comparar os resultados com os valores de linha de base.

    1. Use o recurso que recomenda automaticamente recursos Sidecar com base na análise de logs de acesso para recomendar e aplicar um recurso Sidecar para cada workload no cluster de teste. Para mais informações, consulte Use automatically recommended Sidecar resources based on access log analysis.

    Tamanho da configuração do Sidecar após a aplicação de um recurso Sidecar

    1. Execute o comando a seguir para baixar a configuração do Sidecar do pod que executa o aplicativo httpbin-0 para sua máquina local. Substitua httpbin-0-756995d867-jljgp pelo nome de um pod que esteja executando atualmente o aplicativo httpbin-0.

      kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n default -- curl -s localhost:15000/config_dump > config_dump.json

    2. Execute o comando a seguir para visualizar o tamanho do arquivo de configuração do Sidecar.

      du -sh config_dump.json

      Saída esperada:

      105k    config_dump.json

    A saída esperada demonstra que, no cenário com 420 pods implantados no cluster, o recurso de recomendação automática de recursos Sidecar baseada em análise de logs de acesso reduz a configuração do Sidecar em mais de 10 vezes, para 105 KB. Isso melhora significativamente a eficiência dos pushes de configuração do plano de controle para os Sidecars no plano de dados.

    Eficiência de push do plano de controle após a aplicação de um recurso Sidecar

    Aplique novamente uma nova regra de service virtual ao service httpbin-0 no ASM para acionar um push de configuração do plano de controle para os Sidecars no plano de dados.

    1. Exclua o service virtual httpbin-0-timeout criado anteriormente no ASM antes da otimização. Em seguida, crie o service virtual novamente usando o mesmo conteúdo YAML de Control plane push efficiency before a Sidecar resource is applied, para que o plano de controle realize mais um push de configuração para o service httpbin-0. Para mais informações sobre como criar um service virtual, consulte Manage virtual services.

    2. Visualize os logs gerados pelo plano de controle. O caminho de navegação no console depende da versão da sua instância ASM.

      Versão da instância ASM 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 em o nome da instância ASM. No painel de navegação à esquerda, escolha Observability Management Center > Log Center.

      3. Na página Log Center, clique em a aba Control-Plane Logs para visualizar os logs.

      Versão da instância ASM anterior a 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 em o nome da instância de destino.

      4. Na página de detalhes do mesh, escolha Instance Information > Base Information.

      5. Na página Basic Information, clique em View log à direita de Control-plane log collection.

      O trecho a seguir mostra exemplos de logs:

      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

    Após a aplicação do recurso Sidecar recomendado pelo ASM, cada workload no plano de dados deixa de receber alterações relacionadas a serviços dos quais não depende. Quando uma regra de service virtual é aplicada ao service httpbin-0, o plano de controle envia a alteração de configuração apenas para o Sidecar no pod do aplicativo sleep-0, pois somente esse aplicativo depende do service httpbin-0. O push de configuração acionado pela regra de service virtual dura apenas cerca de 0,01 segundos, aproximadamente 400 vezes mais rápido do que antes da otimização. O volume de dados da alteração também é reduzido em cerca de 10 vezes. Isso aumenta substancialmente a eficiência dos pushes de configuração do plano de controle para o plano de dados.

    Resumo da comparação

    A tabela a seguir compara os valores medidos neste ambiente de teste antes e depois da aplicação de um recurso Sidecar recomendado.

    Métrica

    Sem otimização de recurso Sidecar

    Com otimização de recurso Sidecar

    Tamanho da configuração do Sidecar

    1,2 MB

    105 KB

    Pushes para serviços sem dependências

    Sim

    Não

    Duração do push de configuração do plano de controle

    Cerca de 4 segundos

    Cerca de 0,01 segundos