Resumo: Em setembro deste ano, a comunidade Istio anunciou o código aberto do Ambient Mesh, que gerou discussões acaloradas entre muitos desenvolvedores no país e no exterior.
Este artigo é compartilhado da Comunidade HUAWEI CLOUD " Análise Profunda! Ambient Mesh, um novo modo de proxy compartilhado do Istio , pela equipe nativa do HUAWEI CLOUD Cloud.
Em setembro deste ano, a comunidade Istio anunciou o código aberto do Ambient Mesh, que gerou discussões acaloradas entre muitos desenvolvedores em casa e no exterior. De fato, através da comunicação com o membro do Istio TOC linsun ( https://github.com/linsun ) , soubemos que já em 2021, http://Solo.io começou a compartilhar a pesquisa e o design do agente, também in Em 2021, o Google também está explorando o modelo de proxy compartilhado internamente. Portanto, as duas empresas se deram bem e começaram a acelerar o desenvolvimento do modelo de agência compartilhada por meio do desenvolvimento colaborativo de abril a maio deste ano.
Atualmente, o Ambient Mesh lançou uma versão prévia, e os leitores interessados podem experimentá-lo sob demanda. Devido a limitações de espaço, este artigo realiza principalmente uma análise aprofundada da arquitetura Ambient Mesh e do processo de gerenciamento de tráfego de quatro camadas. Para obter uma explicação detalhada do gerenciamento de tráfego de sete camadas, preste atenção aos artigos de acompanhamento.
1. O que é Malha Ambiente
Simplificando, o Ambient Mesh é um novo modo de proxy compartilhado para o service mesh do Istio . É um novo esquema de plano de dados desenvolvido em conjunto pelo Google e http://Solo.io para simplificar as operações, melhorar a compatibilidade de aplicativos e reduzir os custos de infraestrutura. O modo ambiente mantém os principais recursos do Istio de segurança de confiança zero, gerenciamento de tráfego e telemetria, sem a introdução do Sidecar.
2. Análise da Arquitetura de Malha Ambiente
Antes de iniciar a arquitetura do Ambient, vamos revisar brevemente a arquitetura do Istio. Ele consiste principalmente de duas partes, a saber, o plano de controle e o plano de dados. O plano de controle Istiod executa a geração e o push de configuração básica e gerencia todos os planos de dados; o proxy sidecar é introduzido no plano de dados para assumir o tráfego de entrada e saída do aplicativo.
Figura 1 Arquitetura do Istio
Comparado ao Sidecar, o Ambient Mesh oferece uma opção menos intrusiva com gerenciamento de atualização mais simples. Ambient divide a funcionalidade do Istio em duas camadas distintas, uma sobreposição de segurança (quatro camadas de governança) e uma camada de processamento de sete camadas (sete camadas de governança):
Figura 2 A malha ambiente é dividida em uma camada
• Camada de sobreposição de segurança: roteamento TCP de processo, indicadores de monitoramento, logs de acesso, túnel mTLS, autorização simples • Camada de processamento de sete camadas: Além das funções da camada de sobreposição de segurança, fornece roteamento de protocolo HTTP, monitoramento, logs de acesso, chamadas chain, load Funções de gerenciamento de tráfego, como balanceamento, fusão, limitação de corrente e repetição, bem como políticas de autorização de sete camadas ricas
As cargas no Ambient Mesh podem interoperar perfeitamente com as cargas no modo Sidecar, permitindo que os usuários misturem e combinem os dois modos de acordo com suas necessidades.
• Arquitetura de governança de quatro camadas: no modo Sidecar, o Istio implementa a interceptação de tráfego por meio do InitContainer ou do Istio-CNI. O Istio-CNI é um componente obrigatório no Ambient Mesh. A figura a seguir mostra a estrutura básica de governança de quatro camadas do Ambient Mesh:
Figura 3 Arquitetura de governança de quatro camadas de malha ambiente
No Istio-CNI, um novo módulo de processamento para Ambient é adicionado , que monitora as alterações no Namespace e no Pod e define regras de roteamento e iptables para aplicativos no nó:
• Roteamento: Configure a tabela de roteamento para rotear o tráfego enviado pela aplicação deste nó para o ztunnel e o tráfego recebido por este nó para o ztunnel.
• iptables: Defina as regras do iptables no contêiner ztunnel para interceptar de forma transparente o tráfego para a porta correspondente ao ztunnel.
ztunnel é um componente recém-introduzido do Ambient, que é implantado em cada nó na forma de Daemonset. O ztunnel fornece mTLS, telemetria, autenticação e autorização L4 para comunicação de aplicativos na malha e não executa nenhum processamento relacionado ao protocolo da camada 7. O plano de controle só emitirá um certificado de carga de trabalho para um ztunnel se estiver sendo executado em um nó com a mesma carga de trabalho. Portanto, quando o ztunnel é atacado, apenas o certificado da carga em execução no nó pode ser roubado e o risco de segurança é relativamente controlável, o que é semelhante a outra infraestrutura de compartilhamento de nó bem implementada.
• Arquitetura de governança de tráfego de sete camadas: atualmente, o Ambient Mesh precisa habilitar explicitamente o processamento de sete camadas para um serviço definindo um recurso de API de gateway. A figura a seguir mostra a arquitetura da governança de sete camadas do Ambient:
Figura 4 Arquitetura de governança de sete camadas de malha ambiente
Comparado com a governança de quatro camadas do Ambient, um componente de waypoint foi adicionado à arquitetura de governança de sete camadas. Um novo módulo de processamento de waypoint é adicionado ao Pilot , que monitora as alterações dos objetos ServiceAccount, Deployment e Gateway API e, em seguida, coordena os objetos de waypoint relacionados:
• Quando a ServiceAccount muda, o Pilot tentará atualizar todos os waypoints no namespace atual.
• Quando o Deployment muda, ele aciona a manutenção do waypoint através do objeto Gateway associado à sua OwnerReference.
• Quando o Gateway muda, o waypoint associado proxy é atualizado.
Atualmente, o Ambient precisa contar com recursos da API Gateway, como os seguintes, para criar um proxy de waypoint:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: productpage
annotations:
istio.io/service-account: bookinfo-productpage
spec:
gatewayClassName: istio-meshO valor gatewayClassName deve ser definido como istio-mesh, caso contrário, poderá ser ignorado. Cada ServiceAccount tem seu próprio proxy de waypoint dedicado, muito parecido com o modelo Sidecar. Recomenda-se que cada serviço use sua própria identidade separada para evitar riscos de segurança adicionais.
O Pilot atualizará as regras de tráfego da Camada 7 e da Camada 7 para o proxy de waypoint por meio do xDS para implementar os recursos de governança de tráfego relacionados à Camada 7. Não é necessariamente garantido que o proxy de waypoint esteja no mesmo nó que a carga de trabalho que está atendendo, o que parece apresentar alguns problemas de desempenho. Mas para o Istio, o atraso é mais do processamento complexo de sete camadas, e espera-se que o atraso de governança de sete camadas do modo Ambient final seja próximo ao do modo Sidecar. O agente de waypoint é implantado por meio de uma implantação separada, para que possa ser configurado individualmente com a CPU e a memória necessárias, definir a estratégia de dimensionamento elástico HPA relevante, não mais acoplado ao aplicativo, fornecer escalabilidade mais flexível e melhorar o uso de recursos para uma certa medida Taxa.
3. Gerenciamento de tráfego de quatro camadas Ambient Mesh
Sabemos que o ztunnel só pode executar gerenciamento de tráfego de quatro camadas, balanceamento de carga de quatro camadas, criptografia de tráfego TLS, autenticação e autenticação básicas etc., mas não pode executar roteamento e autenticação de sete camadas mais avançados. Aqui usamos o exemplo de acesso ao bookinfo por meio do aplicativo sleep para obter uma compreensão profunda de como o tráfego de quatro camadas do Ambient Mesh é roteado. O plano de fundo real do ambiente deste exemplo é o seguinte: Os aplicativos sleep e productpage estão sendo executados em dois nós diferentes.
Figura 5 Processo de proxy de tráfego de quatro camadas de malha ambiente
• Para acessar o serviço productpage no contêiner sleep, a solicitação é primeiro interceptada no ztunnel do mesmo nó, e o ztunnel executa balanceamento de carga básico de quatro camadas e criptografia e descriptografia TLS e, finalmente, seleciona uma instância de destino (o IP do o contêiner productpage) para encaminhar a solicitação.
• Quando essa solicitação entra no nó onde o container productpage está localizado, ela é primeiro interceptada pelo ztunnel, que é responsável por descriptografar o tráfego TLS, depois executa a política de autenticação especificada pelo usuário e, finalmente, envia a solicitação para o container productpage.
O acima é um processo básico de encaminhamento de tráfego de malha ambiente. Vamos entender profundamente o processo de comunicação completo em combinação com a configuração xDS específica.
3.1 Processamento de tráfego no lado de envio do sono
(1) O tráfego do sleep para acessar a página do produto é interceptado e encaminhado ao ztunnel (monitoramento 127.0.0.1:15001) pelo túnel do mesmo nó no modo TPROXY (proxy transparente). A vantagem de usar o TPROXY é manter o destino original endereço, e ztunnel deve confiar nele para encaminhamento. Endereço de destino original.
-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff(2) ztunnel escuta na porta 15001 através do listener "ztunnel_outbound". O listener ztunnel_outbound é completamente diferente do listener no modo sidecar do Istio, ele contém uma cadeia de filtros de todos os serviços neste nó para outros serviços em toda a malha.
Figura 6 ouvinte ztunnel_outbound
Pode-se ver que nenhuma condição de correspondência é definida para todas as cadeias de filtro (todas correspondentes por padrão), então como o ztunnel seleciona a cadeia de filtro de destino de acordo com as características do tráfego? Acontece que também há uma maneira de definir as condições de correspondência de filtro na raiz do ouvinte. Por meio da correspondência a seguir, o endereço de origem é 10.244.1.4, o endereço de destino é 10.96.179.71 e a porta de destino é 9080. O tráfego é entregue ao processamento do filtro "spiffe://cluster.local/ns/default/sa/sleep_to_http_productpage.default.svc.cluster.local_outbound_internal",
Figura 7 correspondência da cadeia de filtros ztunnel_outbound
(3) O filtro "spiffe://cluster.local/ns/default/sa/sleep_to_http_productpage.default.svc.cluster.local_outbound_internal" está associado ao cluster de mesmo nome. O Cluster contém um total de duas instâncias de Endpoint. Um Endpoint é selecionado de acordo com o algoritmo de balanceamento de carga, e o mais importante é passar os metadados (destino e endereço do túnel) para o nome "outbound_tunnel_lis_spiffe://cluster.local /ns/default/sa" Manipulação de ouvinte para /bookinfo-productpage".
Figura 8 configuração de cluster interno outbound_internal
Figura 9 endpoint de cluster interno outbound_internal
(4) O listener "outbound_tunnel_lis_spiffe://cluster.local/ns/default/sa/sleep" usa o filtro "set_dst_address" para definir o endereço de destino dos dados de acordo com os metadados do endpoint selecionado na etapa anterior. Se o cluster outbound_internal anterior selecionou o endpoint 10.244.2.8:9080, o ouvinte de túnel aqui definirá 10.244.2.8:15008 como o endereço de destino. Além disso, o listener possui apenas um TcpProxy, que está associado ao Cluster chamado "outbound_tunnel_clus_spiffe://cluster.local/ns/default/sa/sleep", então o tráfego é naturalmente entregue ao Cluster. Um túnel HTTP Connect (transportando tráfego enviado para 10.244.2.8:9080) também é definido no filtro TCP para uso pelo ztunnel do nó onde a página do produto está localizada. O encapsulamento HTTP é o protocolo do portador para comunicação segura entre os componentes do Ambient Mesh.
Figura 10 configuração do listener outbound_tunnel
O tipo de cluster outbound_tunnel é "ORIGINAL_DST", e está configurado com UpstreamTlsContext, portanto, é responsável pela criptografia TLS do tráfego e, em seguida, enviado diretamente para o endereço de destino, que é 10.244.2.8:15008.
Figura 11 configuração do cluster outbound_tunnel
3.2 Página do produto recebendo processamento de tráfego lateral
(1) O tráfego de sono acessando productpage (endereço de destino é "10.244.2.8:15008") chega ao nó onde productpage está localizado, e é interceptado por TPROXY (proxy transparente) para ztunnel (monitoramento 127.0.0.1:15008), o benefícios de usar TPROXY Ele mantém o endereço de destino original e o ztunnel deve confiar no endereço de destino original ao encaminhar.
10.244.2.8 via 192.168.126.2 dev istioin table 100 src 10.244.2.1
-A PREROUTING -i pistioin -p tcp -m tcp --dport 15008 -j TPROXY --on-port 15008 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff(2) O ouvinte "ztunnel_inbound" no ztunnel escuta na porta 15008, portanto, o tráfego é processado primeiro pelo ouvinte ztunnel_inbound. O TLS é definido no ouvinte ztunnel_inbound e o handshake TLS é executado com o downstream de acordo com sua configuração, para que todos os ztunnels se comuniquem com base na criptografia TLS mútua. Além disso, como você pode ver na configuração abaixo, a atualização do CONNECT foi definida, portanto, o Envoy fará proxy de solicitações HTTP Connect. Além disso, o connectMatcher é definido em RouteMatch, o que significa que a solicitação HTTP Connect é entregue ao cluster "virtual_inbound" para processamento.
Figura 12 configuração do ouvinte ztunnel_inbound
(3) O tipo de cluster virtual_inbound é ORIGINAL_DST, e o cabeçalho HTTP x-envoy-original-dst-host é definido para reescrever o endereço de destino original, e esse cabeçalho é definido exatamente pelo lado de envio "outbound_tunnel_lis_spiffe://cluster.local /ns/default/sa/sleep" com um valor de 10.244.2.8:9080. Portanto, essa solicitação é finalmente enviada com sucesso ao contêiner da página do produto por meio de virtual_inbound.
Figura 13 configuração do cluster virtual_inbound
3.3 Resumo do gerenciamento de tráfego de quatro camadas do Ambient Mesh
Figura 14 Proxy de quatro camadas de acesso ao serviço completo
Na instância do sono acessando a página do produto, embora usemos o protocolo HTTP, na perspectiva de todos os componentes Ambient, o proxy é o tráfego TCP. Anteriormente, analisamos profundamente o princípio de funcionamento de cada ouvinte e de cada Cluster no ztunnel, o que pode parecer complicado. Portanto, aqui está um breve resumo através da Figura 14. Verificamos que no processo de comunicação, não há muitos módulos que realmente participam do trabalho:
- Roteamento e iptables no lado de envio: intercepte o tráfego para a porta 15001 do ztunnel
- Enviando ztunnel lateral: dois ouvintes e dois clusters correspondentes
- Roteamento e iptables no lado receptor: intercepte o tráfego para a porta 15008 do ztunnel
- Receber ztunnel: ouvinte virtual_inbound e cluster associado
4. Perspectivas Futuras
O Sidecar é um recurso do Istio. Usando o Sidecar, você pode aproveitar os benefícios do service mesh e reduzir a carga de operação e manutenção fazendo pequenas modificações no aplicativo. No entanto, o modo Sidecar também tem algumas limitações:
- Intrusivo: O container sidecar é injetado na forma de Admission Webhook e pertence ao mesmo Pod que o container do aplicativo, portanto, a atualização do sidecar deve ser acompanhada pela reconstrução do container de negócios. Pode atrapalhar a carga do aplicativo (por exemplo, atualizações contínuas podem causar surtos em cenários de conexão longa).
- Baixa utilização de recursos: Sidecars correspondem a aplicativos um para um, e CPU e memória suficientes devem ser reservadas, o que pode levar à baixa utilização de recursos de todo o cluster; o dimensionamento elástico só pode ser executado para toda a carga de trabalho e não pode ser executado apenas em sidecars.
- Interrupção de tráfego: a captura de tráfego e o processamento HTTP são feitos pelo Sidecar, que é caro e pode quebrar algumas implementações HTTP incompatíveis.
Atualmente, o Ambient Mesh resolveu bem o problema de dependência de implantação de aplicativos e sidecars no modo sidecar, e não precisa mais injetar sidecars; os recursos do service mesh são fornecidos por meio de ztunnel e waypoint proxy, e a implantação e atualização de aplicativos e mesh componentes não é fácil, interdependente novamente.
Além disso, o modo de compartilhamento Ambient pode reduzir bastante a sobrecarga de recursos do próprio componente de grade, o que é um grande benefício para usuários sensíveis a recursos.
O ambiente ainda está em pré-visualização, muitos recursos ainda estão em desenvolvimento e muitas restrições foram listadas na documentação oficial . Além disso, os usuários da comunidade também têm novas descobertas durante o uso:
• Não suporta IPV6
• Não compatível com Calico CNI, pois iptables criados por Ambient entram em conflito com Calico.
Ao mesmo tempo, o ztunnel baseado em envoy atual pode ter problemas de desempenho em eficiência xDS, multilocação e telemetria. No futuro, um ztunnel mais leve e de alto desempenho pode ser reescrito com base em ferrugem.
A longo prazo, o modelo Sidecar continuará sendo o modelo principal do Istio. O modelo de compartilhamento Ambient trouxe bastante estímulo para a comunidade Istio ou a indústria de malha de serviços. Acredita-se que com base nos esforços conjuntos de todos os desenvolvedores da comunidade, o modelo de compartilhamento Ambient se tornará a segunda escolha do Istio.
Clique em Seguir para conhecer as novas tecnologias da HUAWEI CLOUD pela primeira vez~