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étrica | Antes da recomendação de sidecar | Depois da recomendação de sidecar | Melhoria |
|---|---|---|---|
| Tamanho da configuração do sidecar | 1,2 MB | 105 KB | Redução de ~10x |
| Configurações de serviços não relacionados distribuídas | Sim (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:
Um cluster adicionado a uma instância do ASM
Coleta de logs de acesso do plano de dados ativada por meio do Simple Log Service
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
Crie um arquivo YAML chamado
httpbin-{i}.yamlcom base no modelo a seguir. Substitua{i}por um número único (de 0 a 199) para criar 200 aplicativos HTTPBin distintos.Aplique o arquivo YAML: Saída esperada:
kubectl apply -f httpbin-{i}.yamldeployment.apps/httpbin-{i} created
Implantar aplicativos sleep
Crie um arquivo YAML chamado
sleep-{i}.yamlcom base no modelo a seguir. Substitua{i}por um número único (de 0 a 19). O campoargscontém comandos curl para 10 serviços HTTPBin (httpbin-{i*10}ahttpbin-{i*10+9}), simulando dependências de chamada.NotaOs IDs do HTTPBin nos comandos curl não devem exceder o ID máximo do HTTPBin implantado. Caso contrário, as chamadas falharão.
Aplique o arquivo YAML: Saída esperada:
kubectl apply -f sleep-{i}.yamldeployment.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
Obtenha os nomes dos pods do aplicativo httpbin-0: Saída esperada:
kubectl get pod -n ns-in-mesh | grep httpbin-0NAME READY STATUS RESTARTS AGE httpbin-0-756995d867-jljgp 2/2 Running 0 9m15s httpbin-0-756995d867-whstr 2/2 Running 0 9m15sDespeje 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.jsonVerifique o tamanho do arquivo: Saída esperada:
du -sh config_dump.json1.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.
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: 5sVisualize os logs do plano de controle para observar o comportamento da distribuição.
Para o ASM versão 1.17.2.35 ou posterior:
Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
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.
Na página Log Center, clique na guia Control-Plane Logs.
Para versões do ASM anteriores à 1.17.2.35:
Faça login no console do ASM.
No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM.
Escolha ASM Instance > Base Information.
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.4kBPrincipais 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:09a10: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
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.jsonVerifique o tamanho do arquivo: Saída esperada:
du -sh config_dump.json105k 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
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: 5sVisualize 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.3kBPrincipais 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étrica | Antes da recomendação de sidecar | Depois da recomendação de sidecar |
|---|---|---|
| Tamanho da configuração do sidecar | 1,2 MB | 105 KB |
| Configurações de serviços não relacionados distribuídas | Sim | Nã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.