Ilustração de evv no Shutterstock
O Istio Ambient Mesh foi lançado em setembro de 2022, mas, na época, eu não dei a devida atenção a ele. Ainda assim, para quem já usa ou pretende usar o Istio como service mesh, essa novidade busca resolver algumas das limitações do modelo tradicional com sidecar, que vamos abordar nas próximas seções deste blog.
Observação: o Istio Ambient Mesh ainda está em alpha e não deve ser usado em ambientes de produção até chegar ao General Availability (GA).
Antes de nos aprofundarmos, é preciso passar por alguns conceitos fundamentais — sem eles, o restante deste artigo pode soar como hieróglifo.
O que é um Service Mesh?
Boa parte das aplicações modernas é construída sobre uma base de microsserviços distribuídos, em que cada microsserviço cumpre uma função específica e, com frequência, conversa com os demais. Por falta de uma analogia melhor, pense neles como peças modulares de Lego que se encaixam para montar uma estátua, em vez de uma estátua monolítica esculpida em pedra.
Um service mesh é uma camada acrescentada sobre essas aplicações (ou microsserviços) que viabiliza recursos como gerenciamento de tráfego, observabilidade e segurança, sem que você precise alterar as aplicações em si.
Recursos do Istio Service Mesh
O Istio é um service mesh open-source que se acopla de forma transparente a aplicações distribuídas já existentes. O modo de comunicação padrão entre serviços dentro de um cluster é em texto puro, o que não é nada ideal do ponto de vista da segurança. O Istio service mesh protege esse tráfego criptografando essas comunicações com mTLS (mutual TLS). Ele também oferece outros recursos, incluindo, entre outros:
- Load balancing para HTTP, gRPC, WebSocket e TCP
- Controle de tráfego em nível granular
- Controles de acesso, rate limits e quotas
- Service discovery
- Observabilidade com visão de águia (métricas e dados de telemetria, logs e traces de todo o tráfego dentro de um cluster)
Agora que entendemos o que é um service mesh e os benefícios que ele traz, vamos comparar o modelo tradicional do Istio com sidecar e o novo modelo Ambient Mesh.
Arquitetura do Istio sem Ambient Mesh
O Istio tem 2 componentes fundamentais: um Control Plane e um Data Plane.
O Data Plane representa as comunicações entre os serviços no mesh. O service mesh utiliza um proxy Envoy implantado ao lado de cada serviço no mesh (como um sidecar), e todo o tráfego de entrada e saída dentro do mesh passa por esses proxies Envoy.
O Control Plane coleta dados desses proxies e define e controla a configuração deles, reconciliando o estado atual do ambiente com o estado desejado.
fonte: https://istio.io/latest/docs/ops/deployment/architecture/
Desvantagens desse modelo:
- Resiliência: aplicar mudanças, como atualizar os proxies via control plane, exige reiniciar cada container sidecar, o que pode causar interrupções.
- Alto consumo de recursos: os recursos para os sidecars precisam ser reservados pensando no pior cenário de uso, o que é ineficiente e tende a deixar o responsável pelo billing de cabelo em pé.
- Quebra de tráfego: principalmente ao lidar com aplicações que têm implementações HTTP fora do padrão.
O sidecar faz o processamento de tráfego tanto na Camada 4 quanto na Camada 7. Um problema importante é que o processamento na L7 é bem intensivo em computação, e esse recurso acaba sendo praticamente imposto aos serviços, mesmo quando eles só precisam de uma simples segurança de transporte. Além disso, a maior parte das Common Vulnerabilities and Exposures (CVEs) críticas no proxy Envoy ocorre na camada L7 — ou seja, há uma superfície de ataque maior quando o peso do filtro L7 recai sobre serviços que não precisam dele.
Arquitetura do Istio com Ambient Mesh
O Istio Ambient Mesh traz mudanças bem radicais para a arquitetura do Data Plane. Esse modelo separa as funcionalidades L4 e L7, que antes vinham num pacote fechado com os sidecars.
fonte: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
No lugar dos sidecars, agora temos uma overlay segura criada por ztunnels (zero-trust tunnels). Esses ztunnels funcionam como agentes compartilhados, implantados na forma de um DaemonSet — ou seja, um agente por nó no cluster Kubernetes.
O ztunnel usa um programa eBPF compilado no componente istio-cni para rotear o tráfego. Isso traz vários ganhos de performance e flexibilidade em comparação ao uso de iptables para roteamento.
Cada ztunnel é responsável por proteger o tráfego L4 dos workloads dentro do seu respectivo nó.
Para os recursos de L7, o ambient mesh permite implantar waypoint proxies baseados em Envoy, aplicados em nível de namespace, o que possibilita que os workloads daquele namespace aproveitem toda a gama de recursos do Istio.
fonte: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
Esses waypoint proxies escalam conforme a demanda real dos workloads no namespace em que atuam. Isso é bem mais eficiente e econômico do que reservar recursos para sidecars com base no pior cenário de uso dos workloads.
Por natureza, essa arquitetura permite um uso mais ergonômico e econômico do Istio service mesh, já que os proxies L7 são aplicados só onde fazem sentido, somando-se ao fato de que aproveitam os recursos com mais eficiência e podem escalar de forma mais dinâmica e independente.
Ela também permite interoperabilidade com o modelo tradicional de sidecar, dando a você liberdade de escolha.
Há 2 pontos de atenção sobre esse novo modelo de data plane que não vou tratar diretamente aqui:
- Performance (em razão dos saltos extras):
O Istio afirma que, sem o filtro L7 redundante de mão dupla do modelo sidecar, a perda de performance esperada no ambient mesh por conta do salto extra será mais do que compensada. Eles também devem publicar um post dedicado a performance, provavelmente em parceria com a Solo.io e o Google, com quem trabalharam nesse avanço. 2. Segurança (em razão do modelo de agente compartilhado):
Para quem se preocupa com as implicações de segurança de um Data Plane sem sidecar, recomendo a leitura do blog Ambient Mesh Security Deep Dive.
Estou bem animado para ver o Ambient Mesh rodando em produção, e ele promete entregar economia e eficiência consideráveis para quem adotá-lo.
Mesmo assim, no fim das contas, parece que o elefante na sala continua bem ali, sendo ignorado — o proxy Envoy.
Não acho que os sidecars vão sumir tão cedo, mas talvez um dia tenhamos um software de processamento L7 leve, seguro e ao mesmo tempo poderoso, que sirva como remédio universal para os males de todo usuário de service mesh. Até lá, sou grato por cada passo nessa direção — e você também deveria ser.