Abstract: Ambient Mesh aparece em uma forma mais alinhada com os requisitos de implementação em larga escala e supera os defeitos inerentes da maioria dos modelos sidecar, de modo que os usuários não precisam mais perceber os componentes relacionados à grade e realmente afundar a grade em infraestrutura.
Este artigo é compartilhado pela Huawei Cloud Community " Huawei Cloud Cloud Native Team: Istio Data Plane New Model Ambient Mesh Technology Analysis ", autor: The future of cloud containers.
Se for dito qual padrão de design é o mais clássico no mundo cloud-native construído com base no Kubernetes, o padrão Sidecar é sem dúvida o concorrente mais poderoso entre eles. Quando é necessário fornecer uma aplicação com funções auxiliares que nada têm a ver com sua própria lógica, o sidecar que injeta as funções correspondentes no Pod da aplicação é obviamente a forma mais nativa do Kubernetes, e o Istio é o representante deste modo.
A visão do projeto Istio é resolver os problemas de conexão, segurança e observabilidade entre serviços no cenário de microsserviços da forma mais transparente possível. O principal método de implementação é implantar um proxy próximo ao aplicativo e, no cenário do Kubernetes, injetar o Sidecar no pod do aplicativo para interceptar o tráfego do aplicativo para o Sidecar. O Sidecar processa o tráfego do aplicativo com base na configuração do usuário obtida do plano de controle do Istio e implementa a governança de serviço de uma maneira quase não invasiva ao código do aplicativo.
Embora o Istio não se limite apenas a oferecer suporte à plataforma Kubernetes, o conceito de design do Istio tem uma afinidade natural com o modelo sidecar do Kubernetes. Com base no modelo Sidecar, o Istio pode realizar rápido desenvolvimento, implantação e verificação na plataforma Kubernetes. Ao mesmo tempo, no nível funcional, Isito retira a função de governança do serviço do código do aplicativo e o transfere para o Sidecar como uma infraestrutura, abstraindo a camada de rede do aplicativo nativo da nuvem real, o que reduz bastante a carga mental dos desenvolvedores de aplicativos. é exatamente o que faltava no ecossistema do Kubernetes. Com base no complemento perfeito do Istio para o ecossistema do Kubernetes, com a popularização em larga escala do Kubernetes, o Istio também alcançou uma rápida conquista das mentes e mercados dos usuários.
Embora a implantação do plano de dados do Istio no modo Sidecar pareça ser uma escolha natural que as pessoas não podem recusar, é preciso enfatizar que a implementação das funções completas do Istio não está fortemente vinculada ao modo Sidecar e temos várias outras opções. s Escolha. Além disso, à medida que o uso do Istio continua a se aprofundar e a escala de implementação continua a se expandir, pode-se descobrir que há muitos desafios na implantação de dados do Istio no modo Sidecar:
1. Intrusão: o Istio basicamente atinge zero intrusão no código do aplicativo, mas como a injeção do Sidecar precisa alterar a especificação do pod e redirecionar o tráfego do aplicativo, o pod precisa ser reiniciado quando o aplicativo acessa a grade e o contêiner do aplicativo e o contêiner Sidecar Os conflitos causados pela sequência de inicialização incerta de , também podem causar a interrupção do aplicativo;
2. Ligação do ciclo de vida: O Sidecar é essencialmente uma infraestrutura, e seu ciclo de vida geralmente é inconsistente com o do aplicativo. Portanto, ao atualizar o Sidecar, também é necessário reiniciar o Pod do aplicativo, o que também pode causar a interrupção do aplicativo. Para aplicativos de trabalho , a existência de Sidecar fará com que o Pod não seja limpo a tempo;
3. Baixa utilização de recursos: o Sidecar é exclusivo para um único pod de aplicativo e o tráfego do aplicativo tem picos e quedas. Em geral, o uso de memória do Sidecar está fortemente relacionado ao tamanho do cluster (número de serviços, número de pods). os recursos precisam ser reservados em casos extremos, levando a uma baixa utilização de recursos do cluster como um todo. Ao mesmo tempo, como o Sidecar precisa ser injetado em cada pod, conforme a escala do cluster continua a se expandir, a quantidade total de recursos ocupados pelo Sidecar também aumentará linearmente.
Para resolver as deficiências do modelo de implantação Sidecar, o Google e a Solo.io lançaram em conjunto um novo modelo de implantação sem Sidecar --- Ambient Mesh.
Arquitetura Introdução
A arquitetura Ambient Mesh é mostrada na figura acima. Do ponto de vista do design, ela possui principalmente as duas características a seguir:
1. Sem Sidecar: Para evitar os defeitos do modelo Sidecar mencionado acima, o Ambient Mesh não injeta mais o Sidecar em nenhum Pod e afunda ainda mais a implementação da função mesh nos próprios componentes do Istio.
2. Camadas de processamento L4/L7: Ambient Mesh apresenta dois componentes, ztunnel e waypoint, para substituir o Sidecar original para implementar funções relacionadas. Ao contrário do Sidecar, que pode lidar com o tráfego L4 e L7, o Ambient Mesh suporta ambos. o processamento do tráfego L4, enquanto o tráfego L7 é entregue aos waypoints para processamento conforme necessário.
Comparado com o Istio no modo Sidecar original, o plano de controle do Ambient Mesh é basicamente inalterado. A composição do componente do plano de dados e as funções de cada componente são as seguintes:
1. istio-cni: Componente necessário, implantado na forma de DaemonSet. Na verdade, istio-cni não é um novo componente do Ambient Mesh. Ele já existia no modo sidecar original. Naquela época, era usado principalmente para substituir istio-init, o Init Container, para configurar regras de interceptação de tráfego e para evitar problemas de segurança causados por istio-init. O Ambient Mesh o expande e o implanta como um componente obrigatório, sendo responsável por configurar as regras de encaminhamento de tráfego, sequestrando o tráfego de aplicação dos Pods que aderiram ao Ambient Mesh neste nó e encaminhando-o para o ztunnel deste nó;
2. ztunnel: Componente necessário, implantado na forma de DaemonSet. O ztunnel atua como um proxy para o tráfego de Pods no nó onde está localizado, sendo o principal responsável pelo processamento do tráfego L4, telemetria L4 e gerenciamento mTLS (autenticação bidirecional) entre os serviços. Originalmente, o ztunnel foi implementado com base no Envoy, mas considerando as restrições intencionais nas funções do ztunnel e os requisitos de segurança e ocupação de recursos, a comunidade usou ferrugem para construir esse componente do zero;
3. waypoint: configurado sob demanda, implantado na forma de Deployment. waypoint é responsável por lidar com HTTP, injeção de falhas e outras funções L7. Implante na granularidade da carga ou Namespace. No Kubernetes, uma conta de serviço ou um Namespace corresponde a uma implantação de waypoint, que é usada para processar o tráfego da camada 7 enviado para a carga correspondente. Ao mesmo tempo, o número de instâncias de waypoint pode ser dimensionado dinamicamente de acordo com o tráfego.
O seguinte usa o processo de processamento real do plano de dados Ambient Mesh para mostrar as funções específicas desempenhadas pelos componentes acima:
1. Semelhante ao modo Sidecar, o Ambient Mesh também pode adicionar serviços à grade na granularidade da grade, Namespace e Pod. A diferença é que o Pod recém-adicionado não precisa ser reiniciado, nem precisa injetar Sidecar ;
2. istio-cni monitora a adição e exclusão de Pods no nó e a entrada e saída da grade, e ajusta dinamicamente as regras de encaminhamento. O tráfego enviado pelos Pods na grade será encaminhado de forma transparente para o ztunnel do nó , ignorando diretamente o processamento de kube-proxy ;
3. O ztunnel também precisa monitorar a adição e exclusão de Pods no nó local e a entrada e saída da grade, além de obter e gerenciar os certificados dos Pods localizados no nó local e assumidos pela grade do plano de controle ;
4. O ztunnel na ponta da origem processa o tráfego interceptado, encontra o certificado correspondente ao Pod de acordo com o IP de origem do tráfego e estabelece mTLS com a ponta do par;
5. Se o serviço de destino a ser acessado não estiver configurado com um waypoint ou política de processamento relacionada a L7, o ztunnel de origem estabelecerá uma conexão direta com o ztunnel de destino (conforme marcado pela linha amarela na figura acima) e o peer O ztunnel encerrará o mTLS e implementará a política de segurança L4. Encaminhar o tráfego para o pod de destino;
6. Se o serviço de destino estiver configurado com um ponto de referência (usando um objeto Gateway especialmente configurado) e uma estratégia de processamento L7, o ztunnel de origem estabelecerá mTLS com o ponto de referência correspondente. Depois que o ponto de referência encerrar o mTLS, ele executará o processamento lógico L7 e em seguida, comunique-se com o Pod de destino O ztunnel do nó onde está localizado estabelece mTLS e, finalmente, o ztunnel da extremidade de destino também encerra o mTLS e envia o tráfego para o Pod de destino.
Análise de valor
Embora, do ponto de vista da implementação subjacente, haja uma grande diferença entre o Ambient Mesh e o modo Sidecar original, mas, do ponto de vista do usuário, os efeitos de uso e implementação da API principal do Istio (VirtualService, DestinationRules etc.) consistente, o que pode garantir basicamente a mesma experiência do usuário. Ambient Mesh é o segundo modo de plano de dados compatível com a comunidade Istio além do modo Sidecar, portanto, a própria tecnologia de grade pode agregar valor aos usuários. Ambient Mesh não é diferente do modo Sidecar anterior. Portanto, apenas o valor de Ambient Mesh relativo ao modo Sidecar nativo é analisado aqui, e o valor da própria grade não será repetido.
O Ambient Mesh é ajustado principalmente para a arquitetura do plano de dados do Istio para superar as deficiências do modelo Sidecar existente, portanto, seu valor deve ser baseado em seus recursos de arquitetura. Conforme mencionado anteriormente, os recursos arquitetônicos do Ambient Mesh incluem principalmente "sem sidecar" e "camadas de processamento L4/L7". A análise de valor é baseada nestes dois pontos:
1. As vantagens do Sidecar-less podem, na verdade, ser vistas como o oposto dos defeitos do modelo Sidecar:
- Transparência: A função de grade é reduzida para a infraestrutura, que não apenas tem intrusão zero no código do aplicativo, mas também desacopla completamente o ciclo de vida do aplicativo, de modo que seja verdadeiramente transparente para o aplicativo e permita que o aplicativo e a grade se evoluir de forma independente;
- Otimize a ocupação de recursos: CPU, memória e outros recursos ocupados pelo plano de dados não aumentam mais linearmente com o número de instâncias. À medida que o número de instâncias no plano de dados diminui, o número de conexões com o plano de controle também diminui proporcionalmente, o que reduz consideravelmente reduz os recursos e o processamento do plano de controle.
2. Quanto ao motivo pelo qual L4/L7 deve ser estratificado, antes de mais nada, é necessário distinguir a diferença entre os dois. Em comparação com L4, o processamento de L7 é mais complicado e requer mais recursos como CPU/memória, e também há uma grande diferença na ocupação de recursos entre diferentes tipos de operações; ao mesmo tempo, quanto mais complexa a operação, maior superfície de ataque exposta. Além disso, o Envoy atualmente não suporta forte isolamento do tráfego de diferentes inquilinos, e o problema de "vizinho barulhento" é inevitável. Portanto, as vantagens da arquitetura de processamento em camadas do Ambient Mesh são as seguintes:
- Alta utilização de recursos: o ztunnel é responsável apenas pelo processamento L4, o processamento L4 é relativamente simples e a ocupação de recursos é relativamente fixa, portanto, é mais fácil planejar recursos para ztunnel, sem reserva excessiva de recursos e mais recursos de nó podem ser usados pelos usuários; ponto de passagem também pode expansão dinâmica e contração de acordo com a carga L7, fazendo pleno uso dos fragmentos de recursos no cluster;
- Isolamento do inquilino: o processamento L7 com processamento complexo e altos riscos de segurança é tratado pelos waypoints de cada inquilino (Conta de Serviço), o que não apenas evita a preempção de recursos entre os inquilinos, mas também limita o raio de explosão de problemas de segurança;
- Aterrissagem suave: Permite que os usuários acessem gradualmente a grade. Quando apenas a capacidade de processamento L4 da grade é necessária, não há necessidade de considerar a ocupação de recursos de L7 e o potencial impacto negativo que pode ser causado (por exemplo: devido a erros configuração, o aplicativo entra em processamento L7 e atende totalmente ao protocolo L7, resultando em interrupção do serviço) e, em seguida, habilita as funções relevantes sob demanda no momento apropriado.
É claro que o Ambient Mesh, como uma nova arquitetura de plano de dados do Istio, ainda existe como um recurso experimental na comunidade e ainda há muitos problemas a serem resolvidos, como:
1. Desempenho: Especialmente para o processamento L7, o Ambient Mesh precisa passar por dois ztunnels e um waypoint, e um salto adicional é visível a olho nu, então o processamento L7 completo precisa passar por três saltos adicionais. Embora a comunidade afirme que isso tem pouco impacto no desempenho, ainda são necessárias mais observações e comparações após a estabilização de suas características;
2. Adaptação da rede do contêiner: Embora o Ambient Mesh e o aplicativo sejam basicamente completamente desacoplados, ele também aumenta o acoplamento entre a grade e a infraestrutura subjacente. O modo Sidecar precisa apenas implementar a interceptação de tráfego nas redes do Pod, mas o Ambient A malha intercepta o tráfego na rede do host, obviamente, mais consideração precisa ser dada à adaptação à rede de contêiner subjacente;
3. Configuração complexa: a configuração complexa do Envoy foi amplamente criticada, mas o Ambient Mesh precisa implementar um ztunnel como um proxy para todos os pods no nó. A complexidade da configuração aumentou em uma ordem de magnitude. Ao mesmo tempo, configuração complexa significa um aumento no fluxo de processamento, afetando também a depuração do plano de dados e o desempenho geral;
4. Outros: Alta disponibilidade do ztunnel? Na verdade, o waypoint altera o processamento L7 original de duas extremidades para um único. Como isso afeta a exatidão dos indicadores de monitoramento L7? …
perspectiva futura
Do ponto de vista do lançamento, desde seu lançamento em setembro de 2022, o Ambient Mesh está em um ramo independente como um recurso experimental. Portanto, o próximo plano para o Ambient Mesh é fundir-se com o ramo principal (que foi implementado em fevereiro de 2023) e lançá-lo como um recurso Alpha e, finalmente, atingir o Stable no final de 2023, tornando-o disponível para produção.
Do ponto de vista da API, o ideal é compartilhar o mesmo conjunto de APIs nas duas arquiteturas. Claro, isso não é realista, porque algumas das APIs Istio existentes são projetadas com base na implantação do modo sidecar. O mais comum é o sidecar CRD, que é usado para personalizar a configuração entregue a diferentes sidecars, reduzindo assim a ocupação desnecessária de recursos dos sidecars. Essas APIs somente de sidecar obviamente não fazem sentido no Ambient Mesh. Ao mesmo tempo, o próprio Ambient Mesh apresenta dois componentes exclusivos, ztunnel e waypoint, portanto, o Ambient Mesh também precisa criar uma nova API para gerenciar esses componentes exclusivos e implementar algumas funções do Ambient Mesh Only. No final, o Ambient Mesh implementará as principais APIs do Istio existentes (VirtualService, DestinationRules etc.) e criará algumas APIs exclusivas. É importante unificar os três tipos de APIs (modo Sidecar exclusivo, Ambient Mesh exclusivo e ambos). e interação.
Então, o Ambient Mesh cobriu totalmente os cenários de uso do modo Sidecar, de modo que o modo Sidecar foi completamente retirado do palco da história? A resposta é naturalmente não. Semelhante às disputas entre vários modelos exclusivos e compartilhados da indústria, o modelo Sidecar é essencialmente o uso exclusivo de Proxy pelo Pod de aplicação. Muitas vezes, um Proxy dedicado pode garantir melhor disponibilidade de recursos, evitar ao máximo o impacto de outros aplicativos e garantir o funcionamento normal de aplicativos de alta prioridade. É previsível que na implantação mista final dos dois modos, o aplicativo selecione o modo proxy sob demanda é uma maneira mais ideal. Portanto, construir um modo de implantação híbrido para garantir uma boa compatibilidade e uma experiência unificada entre os dois modos nesse modo também será o foco do trabalho de acompanhamento.
Resumir
O modo sidecar é como uma verificação de protótipo para o Istio. Ele demonstra rapidamente o valor da tecnologia de grade da maneira mais nativa do Kubernetes e captura a consciência do usuário e o mercado. Porém, à medida que a implementação do Istio entra gradativamente na área de águas profundas e começa a ser implantada em larga escala no ambiente de produção, o modelo Sidecar parece não conseguir fazer o que deseja. Neste momento, o Ambient Mesh aparece em uma forma mais alinhada com os requisitos de implementação em larga escala, superando os defeitos inerentes à maioria dos modelos sidecar, para que os usuários não precisem mais perceber os componentes relacionados à grade e realmente afundar o rede em infraestrutura.
Mas está claro que o Ambient Mesh não é o fim da evolução da arquitetura de superfície de dados em grade. Atualmente, não há nenhuma solução de superfície de dados em grade que possa ser perfeita em termos de intrusão, desempenho e uso de recursos. O Ambient Mesh basicamente atinge zero intrusão no aplicativo, mas os problemas de desempenho causados pelo processamento de três saltos do L7 e a ocupação de recursos de processos residentes, como o ztunnel, não podem ser ignorados; bibliotecas RPC, como gRPC, implementam xDS por meio de built-in, diretamente conectado para o plano de controle do Istio, misturar a grade no SDK pode realmente alcançar bom desempenho e desempenho de ocupação de recursos, mas é inevitável pagar o preço inerente de forte acoplamento com o aplicativo e alta complexidade do suporte multilíngue; com base em eBPF, o conjunto completo de funções de superfície de dados de grade pode ser diretamente Afundar a pilha de protocolo TCP/IP para o kernel parece ser uma solução final ideal, mas considerando a complexidade da segurança do kernel e interação com o kernel, o ambiente de execução do eBPF é realmente muito limitado. Por exemplo, programas eBPF devem passar por Para verificação do verificador, o caminho de execução deve ser completamente conhecido e loops arbitrários não podem ser executados. Portanto, para processamento L7 complexo, como HTTP/2 e gRPC, será difícil desenvolver e manter com base no eBPF.
Considerando os requisitos extremos de infraestrutura em desempenho e consumo de recursos e a evolução de tecnologias relacionadas no passado, por exemplo, para a rede básica, a maioria dos aplicativos pode compartilhar a pilha de protocolo do kernel e alguns aplicativos especiais usam DPDK, RDMA e outras tecnologias dedicadas acelerar. Da mesma forma, para a superfície de dados da grade, pode ser mais viável combinar várias tecnologias para otimizar as soluções para os cenários correspondentes. Pode-se prever que este tipo de solução basicamente leva o agente de nível de nó como o Ambient Mesh como o corpo principal. Com o desenvolvimento da grade e da tecnologia eBPF, o maior número possível de funções do plano de dados da grade será rebaixado para eBPF (Fast Path). para realização; menos Algumas funções avançadas são implementadas pelo Proxy (Slow Path) no modo de usuário; para aplicativos que têm altos requisitos de desempenho e isolamento, Sidecars dedicados são implantados para eles. Dessa forma, pode atender aos requisitos de várias dimensões, como intrusividade, desempenho e ocupação de recursos na maioria dos cenários.
Resumindo, no final das contas, um conjunto de soluções de plano de dados dominará o mundo, ou uma implantação mista de várias soluções, dependendo dos diretores de cada empresa, ainda é necessário continuar explorando e evoluindo tecnologias relacionadas e depois use testes práticos e, finalmente, deixe o tempo nos dizer a resposta.
referências
[1] Istio Ambient Mesh explicado: https://lp.solo.io/istio-ambient-mesh-explained
[2] O que esperar do ambiente mesh em 2023: https://www.solo.io/blog/ambient-mesh-2023
[3] Apresentando o Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh
[4] Comece a usar o Istio Ambient Mesh: https://istio.io/latest/blog/2022/get-started-ambient
Clique para seguir e aprender sobre as novas tecnologias da Huawei Cloud pela primeira vez~