Alibaba Cloud afirma que as malhas de serviço K8s podem exigir mais recursos do que os aplicativos que executam
SIGCOMM 2024 O Alibaba Cloud afirmou que seu service mesh desenvolvido internamente para Kubernetes – Canal Mesh – supera significativamente o Istio do Google e outras ferramentas rivais.
O líder chinês em nuvem revelou a existência do Canal Mesh na conferência da Association for Computing Machinery SIGCOMM da semana passada em Sydney, Austrália, em um apresentação e papel [PDF]. O presidente abriu com uma explicação de como os microsserviços dependem de malhas de serviço para conectar pods do Kubernetes, como essas malhas dependem de um proxy “sidecar” para manipular e mediar a comunicação de rede entre microsserviços e para coletar telemetria no tráfego, para que os aplicativos não precisem de seu próprio encanamento de rede.
Mas, na estimativa da Alibaba Cloud, os sidecars “causam vários problemas, incluindo intrusão no pod do usuário, ocupação excessiva de recursos, sobrecarga significativa no gerenciamento de muitos sidecars e degradação do desempenho causada pela passagem de tráfego pelo sidecar”.
A nuvem chinesa considerou o impacto do Istio em um cliente que executava um cluster Kubernetes composto por 500 nós e 15.000 pods e descobriu que ele consumia 1.500 núcleos e 5.000 gigabytes de memória – dez por cento dos recursos de hardware.
Em outros cenários, o Alibaba Cloud afirmou que os requisitos de CPU e memória do sidecar “crescem ainda mais que os do aplicativo”.
Isso é uma loucura e claramente insustentável. E em 2022 o Google fez algo a respeito Apresentando Ambient Mesh – um modo de plano de dados do Istio que oferecia aos usuários do Istio a chance de estacionar sidecars.
O artigo da Alibaba Cloud observa que o Ambient Mesh melhorou o desempenho e reduziu as demandas de recursos, mas ainda exigiu que alguns proxies residissem no cluster de usuários.
A nuvem chinesa sentiu que o desacoplamento completo da malha de serviços dos clusters de usuários seria mais eficaz – e criou o Canal Mesh para provar isso.
O artigo afirma que o Alibaba Cloud teve um sucesso considerável e produziu os seguintes resultados:
- Taxa de transferência 12,3x e 2,3x maior que Istio e Ambient, com latência 1,7x e 1,3x menor;
- Consumo de CPU 12x~19x e 4,6x~7,2x menor que Istio e Ambient;
- Tempo de conclusão da configuração para criar centenas de pods 1,5x~2,1x e 1,2x~1,5x menores que o Istio e o Ambient;
- A ocupação de largura de banda no sentido sul é 9,8x e 4,6x menor que a do Istio e Ambient.
O Alibaba Cloud atingiu esses números com uma arquitetura que vê os proxies movidos para fora do cluster de usuários — embora com um proxy mínimo no nó retido para lidar com algumas tarefas de segurança e observabilidade.
O bypass de kernel baseado em eBPF e a aceleração remota de mTLS também são empregados. O artigo descreve como o Alibaba Cloud usa sua inteligência de hiperescala para colocar proxies em seus pools de recursos.
O artigo e a apresentação afirmam que o Canal Mesh foi executado no Alibaba Cloud por um ano – sem confirmar que ele está em produção. Ambos também omitem um link ou mesmo menção de código para você ler ou implementar – mas a apresentação inclui contatos no Alibaba Cloud para aqueles que têm perguntas.
Se a Alibaba Cloud pretende manter o Canal Mesh para si, ela pode operar de forma mais eficiente do que seus rivais. A nuvem chinesa compete com empresas como AWS, Google e Azure em alguns mercados, mas O Registro entende que a maioria dos clientes do Alibaba fora da China tem raízes ou conexões no Reino do Meio, o que os faz se sentir mais confortáveis com a roupa do que os compradores baseados em outros países. ®
