Introdução: Como uma importante tecnologia nativa da nuvem, a malha de serviço melhora os recursos de governança de serviços de microsserviços, como controle de fluxo, disjuntor e atualização, mas, ao mesmo tempo, a introdução de sidecar também leva a um aumento na latência. Netease Shufan, por meio da análise específica da introdução de atraso, tenta usar eBPF e tecnologia de pilha de protocolos de modo de usuário para otimizar o atraso e considerar a compatibilidade ao máximo, de modo a obter aceleração não intrusiva da rede de contêineres e aplicativos sidecar .
Análise de atraso
A introdução de sidecars na malha de serviço adiciona duas unidades de processamento de rede a todo o caminho da rede, o que inevitavelmente introduz atraso. Otimizar a latência otimizando a lógica do sidecar em si é um direcionamento da comunidade, como a otimização do mixer pela comunidade emissária. Outra direção é otimizar a camada inferior do link.
Se o link inteiro for aberto, o sidecar introduzirá mais links de Service para sidecar e de sidecar para sidecar, e o cliente e o servidor passarão pela pilha de protocolos do modo kernel mais quatro vezes no total. Analisamos o uso da CPU do aplicativo sidecar enviado por meio do gráfico de chama e descobrimos que a CPU da pilha de protocolos do modo kernel é responsável por quase 50%, portanto, o efeito de otimização para a pilha de protocolos do modo kernel deve teoricamente ser muito impressionante.
Além disso, você também pode otimizar a rede de contêineres, como usar a solução de rede de contêineres SRIOV, mas isso envolverá a transformação da solução de rede de contêineres existente, que é intrusiva.
eBPF Sockops otimiza a comunicação de serviço e sidecar
A comunicação entre os dois containers pertencentes ao mesmo nó entre o Service e o sidecar pode ser acelerada usando o componente Sockops.
O Sockops era originalmente um componente do Cillium de código aberto, que usa sockmap e tecnologia de redirecionamento sk para contornar a pilha de protocolos TCP/IP e enviar pacotes diretamente para o soquete peer, acelerando assim a comunicação entre soquetes no mesmo nó. Pegamos emprestado implementações relacionadas e desenvolvemos aprimoramentos para se adaptar a cenários secundários.
A aceleração Sockops é descrita em detalhes em "eBPF in NetEase Qingzhou Cloud Native Application Practice", consulte: https://www.infoq.cn/article/ovcvwqijzta7jlexgdoc .
A partir dos resultados finais do teste, usar Sockops para acelerar a comunicação entre o Service e o sidecar pode reduzir o atraso em cerca de 10%.
A pilha de protocolos do modo de usuário otimiza a comunicação de sidecar e sidecar
A comunicação entre o sidecar e o sidecar envolverá nós cruzados e não pode ser acelerada usando Sockops.Aqui usamos a pilha de protocolos do modo de usuário para substituir a implementação da pilha de protocolos do modo kernel. Comparada com a pilha de protocolos do modo kernel, a pilha de protocolos do modo usuário pode melhorar o desempenho em dois aspectos:
- Elimine a sobrecarga de alternar entre o modo kernel e o modo de usuário;
- Coloque o código de implementação da pilha de protocolos em um processo de modo de usuário separado e remova a sobrecarga da CPU da implementação da pilha de protocolos no sidecar;
A implementação relevante é descrita em detalhes abaixo.
A implantação separada de VPP+VCL economiza recursos de CPU
Para levar em conta o desempenho e a ocupação de recursos, escolhemos o VPP como a pilha de protocolos do modo de usuário. Como um processo independente, o VPP implementa a pilha de protocolos de modo de usuário e fornece uma biblioteca dinâmica VCL leve para integração de sidecar para implementar o seqüestro de interface de soquete.VPP e VCL se comunicam por meio de memória compartilhada.
dentro:
VCL - Implemente o seqüestro de interface de classe Socket e interação completa com o VPP de back-end
FIFO - é uma fila de mensagens baseada em encapsulamento de memória compartilhada para comunicação entre VCL e VPP
Sessão - mantém a correspondência entre a camada de transporte e as sessões de aplicação da camada superior
TCP/IP - a implementação da pilha de protocolos TCP/IP correspondente ao kernel
AF_XDP - realiza o descarregamento do envio e recebimento de pacotes da placa de rede para o modo usuário
Pode ser visto que o modo de implantação separada VPP+VCL separa a pilha de protocolos do lado do aplicativo. Como um processo independente que implementa a pilha de protocolos, o VPP pode servir todos os sidecars no nó, vinculando assim a relação de implantação 1:1 entre sidecars e a pilha de protocolos, tornando-se uma relação de implantação independente de N:1, que economiza o uso geral dos recursos da CPU. Ao mesmo tempo, o sidecar também usa mais recursos da CPU para processar sua própria lógica de negócios, o que melhora a utilização dos recursos da CPU e reduz o atraso de processamento dos nós sidecar.
O design não intrusivo melhora a facilidade de uso
O design não intrusivo é refletido nas direções norte e sul, o sul está conectado à rede de contêineres e o norte está conectado ao sidecar.
Quando o sidecar norte está conectado, a biblioteca dinâmica VCL é usada para integração do sidecar. A interface de soquete é automaticamente sequestrada na biblioteca dinâmica VCL, portanto, não há necessidade de sidecar para modificar o código. Além disso, a biblioteca dinâmica VCL suporta o método de carregamento LD_PRELOAD, só é necessário especificar esta variável de ambiente quando a aplicação sidecar iniciar a configuração do caminho da biblioteca dinâmica VCL.
Será mais problemático conectar a rede de contêineres ao sul. Existem muitos tipos de redes de contêineres, mas eventualmente uma porta de rede será inserida para uso do POD. Esta porta de rede é principalmente uma porta veth, e também pode ser uma porta VF. Como nem todo tráfego precisa passar pelo sidecar, por exemplo, a comunicação entre o serviço e o host só precisa passar pelo modo kernel, então como acelerar a pilha de protocolos do modo de usuário mantendo o canal de comunicação do kernel existente?
Usamos AF_XDP para desviar o tráfego. Ou seja, use o XDP para filtrar pacotes específicos primeiro e envie-os ao VPP se as condições forem atendidas, caso contrário, continue indo para o kernel.
Depois que os pacotes são distribuídos para o VPP, e depois enviados para o sidecar, o sidecar também precisa enviar os pacotes para o Service. Esse caminho só pode passar pelo kernel e pode ser acelerado por meio de Sockops.
Suporte para pilha dupla
O suporte a pilha dupla na verdade inclui dois aspectos.
Um é o desvio de pilha dupla baseado em AF_XDP baseado na porta eth0, que foi explicado na seção anterior.
O outro é o suporte de pilha dupla do sidecar, porque o sidecar também precisa se comunicar com o serviço por meio do modo kernel.
O suporte dual-stack do sidecar requer que a VCL diferencie os pacotes.Para os pacotes que precisam passar pelo modo kernel, a interface de soquete nativa é chamada novamente para permitir que os pacotes passem pela pilha de protocolos do modo kernel.
Efeito de otimização
Para diferentes testes de RPS de latência de ambos os sidecars, ua indica que a otimização da pilha de protocolos do modo de usuário está habilitada. Pode-se ver que o atraso da pilha de protocolos do modo de usuário é reduzido em cerca de 30%, o atraso do Sockops é reduzido em cerca de 10% e o atraso dos dois é reduzido em cerca de 35%.
escreva no final
AF_XDP + pilha de protocolos de modo de usuário + Sockops otimiza o uso de recursos de CPU da pilha de protocolos do kernel para o cenário de sidecar de malha de serviço, reduz a latência de ponta a ponta introduzida pelo sidecar e não modifica a rede de contêineres atual e os aplicativos sidecar. Sem aceleração intrusiva. O gerenciamento e controle da pilha de protocolos em modo usuário e Sockops são desenvolvidos com base no Kubernetes Operator, e a implantação, operação e manutenção também são muito simples, podendo ser implantados individualmente ou combinados conforme a necessidade. No futuro, também consideraremos open source esses kits de aceleração para service mesh.
Além disso, por meio da combinação flexível de componentes de aceleração, além da aceleração de sidecar, também lançamos a aceleração para gateways de API, e os componentes separados de aceleração de pilha de protocolos de modo de usuário também estão sendo estendidos para cenários de aceleração como Redis e Nginx.
Sobre o autor: Wang Hanlin, especialista em desenvolvimento de sistemas da NetEase Shufan, veterano de 17 anos em desenvolvimento de software. Ele trabalhou na H3C e Huawei, envolvido na pesquisa e desenvolvimento de segurança, vigilância por vídeo, big data, virtualização de rede e outros produtos de tecnologia. Atualmente, ele é responsável pela pré-pesquisa e implementação de produtos de tecnologia de rede de alto desempenho na equipe nativa da nuvem NetEase Shufan Qingzhou.