:Visão geral

Descrição do recurso

Instâncias do Service Mesh (ASM) com versão 1.18 ou posterior oferecem suporte ao modo Ambient Mesh. O Ambient Mesh introduz um plano de dados sem sidecar para simplificar a integração de aplicações com service meshes, permitir a adoção incremental dessa tecnologia e reduzir custos de infraestrutura para usuários do Istio.

O Ambient Mesh oferece suporte a planos de dados com ou sem sidecars. Utilize um ou ambos conforme as necessidades da sua aplicação. Em instâncias do ASM versão 1.18, os proxies sidecar suportam o HTTP-Based Overlay Network Environment (HBONE). Assim, esses proxies interoperam com aplicações sem sidecar por meio de túneis de confiança zero (ztunnels) ou proxies waypoint. Em alguns casos, ztunnels e proxies waypoint atuam em conjunto: os ztunnels fornecem a camada de sobreposição segura, enquanto os proxies waypoint oferecem capacidades de processamento na Camada 7.

Filosofia de design

O Ambient Mesh divide o plano de dados em duas camadas distintas: Camada 4 e Camada 7. O processamento fundamental ocorre na Camada 4, caracterizada por alta eficiência e menor consumo de recursos. Já os recursos avançados de gerenciamento de tráfego estão disponíveis na Camada 7, que exige mais recursos. Adote a tecnologia de service mesh de forma incremental, conforme os recursos necessários.

No modo Ambient Mesh, os proxies da Camada 4 (ztunnels) e os proxies da Camada 7 (proxies waypoint) são desacoplados. As capacidades de um proxy da Camada 4 são implementadas pelo plugin Container Network Interface (CNI). Esse proxy executa como DaemonSet em cada nó, funcionando como um componente compartilhado que atende todos os pods no mesmo nó.

O proxy da Camada 7 não é mais implantado como sidecar, mas sim como um pod por conta de serviço dedicado ao processamento na Camada 7.

Os componentes do plano de controle do ASM continuam a gerenciar as configurações dos proxies das Camadas 4 e 7. Esse desacoplamento permite separar ainda mais as aplicações do plano de dados do ASM.

A implementação do Ambient Mesh no Istio envolve três partes:

• Proxy waypoint:

  • Componente da Camada 7 separado das aplicações, o que aumenta a segurança.

  • Fornecimento de um proxy waypoint específico para cada identidade (conta de serviço no Kubernetes), evitando a complexidade e a instabilidade do modo multilocatário da Camada 7.

  • Ativação do proxy waypoint mediante configuração de um CustomResourceDefinition (CRD) de gateway do Kubernetes.

• Ztunnel: Implementa o processamento da Camada 4 usando o plugin CNI. O tráfego de uma carga de trabalho é redirecionado para o ztunnel correspondente, que identifica a carga e seleciona o certificado apropriado para processar o tráfego.

• Compatibilidade com sidecar: O plano de dados com proxies sidecar configurados ainda é o mais utilizado. Proxies waypoint podem se comunicar com cargas de trabalho que possuem proxies sidecar implantados.

No modo tradicional, é necessário injetar um proxy sidecar em cada aplicação. No modo Ambient Mesh, não é preciso reimplantar ou modificar a aplicação existente. Portanto, o Ambient Mesh é menos invasivo, o que reduz riscos de implementação e simplifica seu uso.

Por ser não invasivo, o Ambient Mesh permite adicionar uma aplicação ao service mesh apenas aplicando um rótulo específico ao namespace onde ela reside. Após a adição, o método de segurança da camada de transporte mútua (mTLS) e o recurso de observabilidade da Camada 4 ficam imediatamente disponíveis.

Roteamento no modo Ambient Mesh

No modo Ambient Mesh, as cargas de trabalho dividem-se em três categorias:

• Uncaptured: pod padrão sem nenhum recurso de mesh ativado.

• Captured: pod cujo tráfego é interceptado por um ztunnel. Para capturar pods, adicione o rótulo istio.io/dataplane-mode=ambient aos namespaces.

• Waypoint-enabled: pod cujo tráfego é interceptado por um ztunnel e possui um proxy waypoint implantado. Por padrão, todos os pods no mesmo namespace compartilham um proxy waypoint. Também é possível dedicar um proxy waypoint a uma conta de serviço específica adicionando a anotação istio.io/for-service-account no CRD de gateway do Kubernetes. Se houver configuração tanto para o namespace quanto para a conta de serviço, o proxy waypoint da conta de serviço terá precedência.

Roteamento do Ztunnel

• Saída

  Quando uma aplicação em um pod capturado inicia uma solicitação de saída, o ztunnel do nó redireciona a solicitação transparentemente. Em seguida, o ztunnel seleciona o método de encaminhamento e o destino. Geralmente, o comportamento segue o roteamento padrão do Kubernetes: solicitações para um Service são enviadas a um endpoint desse Service, enquanto solicitações para um IP de pod vão diretamente a esse endereço. O roteamento varia conforme as capacidades do destino. Se o destino também for capturado ou possuir capacidades de proxy Istio (como sidecar ou gateway Istio), a solicitação será roteada por um túnel HBONE criptografado. Caso o destino tenha um proxy waypoint, a solicitação será roteada via túnel HBONE e encaminhada a esse proxy.

  Ao solicitar um Service, o ztunnel do pod de origem verifica se há um proxy waypoint configurado para o pod selecionado. Se houver, as solicitações serão enviadas ao proxy waypoint, que as encaminhará ao destino, permitindo a aplicação de políticas orientadas a serviços. Se os proxies waypoint estiverem ativados apenas para alguns pods de um Service, parte das solicitações passará pelos proxies waypoint, enquanto outras não.

• Entrada

  Quando um pod capturado recebe uma solicitação de entrada, o ztunnel do pod a direciona transparentemente. O ztunnel aplica as políticas de autorização e encaminha a solicitação apenas se ela estiver em conformidade. Os pods podem receber tráfego compatível com HBONE ou texto simples; por padrão, os ztunnels aceitam ambos. Como solicitações em texto simples não possuem identidade de par na avaliação das políticas, configure uma política que exija identidade (qualquer uma ou específica) para bloquear todo o tráfego em texto simples.

  Se um proxy waypoint estiver ativado para o destino, todas as solicitações deverão passar por ele para execução das políticas, e o ztunnel correspondente garantirá isso. Existe, contudo, um caso extremo: clientes HBONE adequados (como outro ztunnel ou sidecar Istio) sabem que devem enviar solicitações ao proxy waypoint, mas clientes externos ao mesh desconhecem o proxy e enviam solicitações diretamente ao pod de destino. Nessas chamadas diretas, o ztunnel enviará as solicitações recebidas ao seu próprio proxy waypoint para garantir a execução correta das políticas.

Roteamento do Waypoint

Um proxy waypoint recebe apenas solicitações HBONE. Ao receber uma solicitação, ele verifica se o destino é um pod gerenciado por ele ou um Service que contém tal pod.

Para qualquer tipo de solicitação, o proxy waypoint aplica políticas (como AuthorizationPolicy, WasmPlugin e Telemetry) antes de encaminhar a requisição.

Solicitações diretas a um pod são simplesmente encaminhadas após a aplicação das políticas.

Para solicitações destinadas a um Service, o proxy waypoint também aplica roteamento e balanceamento de carga. Por padrão, um Service roteia o tráfego para si mesmo e realiza o balanceamento entre seus endpoints. Substitua esse comportamento padrão configurando uma rota para o Service.

Diferenças em relação à arquitetura sidecar

• No modo Ambient Mesh, as capacidades de processamento das Camadas 4 e 7 são desacopladas. Os ztunnels baseados em Rust realizam o processamento da Camada 4, funcionando como proxies de rede de alto desempenho e baixo consumo de recursos.

• Os proxies waypoint são orientados ao destino. A configuração precisa conter apenas informações sobre clusters dinâmicos limitados, endpoints e rotas de conexão, em vez de detalhes de todos os Services no cluster. Isso elimina a necessidade de recursos de sidecar de suporte, removendo a obrigatoriedade de configuração manual desses recursos.

Benefícios do Ambient Mesh

• Os proxies do mesh operam independentemente das aplicações. Atualizações ou reinicializações dos proxies não exigem reinicialização das aplicações.

• Amplia o suporte a aplicações, incluindo Jobs do Kubernetes.

• Elimina requisitos impostos às aplicações na arquitetura sidecar, incluindo limitações para protocolos server-first.

• Permite a adoção incremental de tecnologias de mesh. Utilize, por exemplo, a camada de sobreposição segura na fase inicial para implementar mTLS, políticas simples de autorização da Camada 4 e recursos de observabilidade.

• Sem a necessidade de processamento da Camada 7, a camada de sobreposição segura reduz significativamente a superfície de ataque e a frequência de atualizações do plano de dados para correções de vulnerabilidades e exposições comuns (CVEs) e outros patches.

• Possibilita dimensionar o plano de dados independentemente da carga de trabalho, reduzindo custos de infraestrutura.