OpenShift Service Mesh 3.2 com modo ambiente do Istio

Temos o prazer de anunciar a disponibilidade geral do Red Hat OpenShift Service Mesh 3.2. Essa versão inclui a disponibilidade geral do modo ambiente do Istio, uma nova maneira de implantar service mesh sem sidecars que reduz significativamente os custos de recursos do uso da service mesh. Isso oferece uma solução de baixa sobrecarga para redes de confiança zero com criptografia mTLS lightweight pod a pod e políticas de autorização baseadas em identidades de carga de trabalho, com a capacidade de adicionar recursos mais avançados conforme necessário.

Com base nos projetos Istio, Envoy e Kiali, esta versão atualiza a versão do Istio para 1.27 e do Kiali para 2.17. Além disso, ela é compatível com o Red Hat OpenShift 4.18 e versões posteriores. 

Upgrade para o OpenShift Service Mesh 3.2

Se você estiver executando o OpenShift Service Mesh 2.6 ou versões anteriores, deverá realizar upgrade para o OpenShift Service Mesh 3.0, 3.1 e, em seguida, 3.2. Recomendamos migrar para o OpenShift Service Mesh 3.0 imediatamente, pois a versão 2.6 chegará ao fim da vida útil (EOL) em 30 de junho de 2026 (recentemente estendida de 12 de março de 2026). Um guia detalhado de migração é fornecido na documentação do OpenShift Service Mesh 3.0, incluindo uma análise das diferenças entre o OpenShift Service Mesh 2.6 e 3.0. Este post descreve como usar o console do Kiali para migrar entre o OpenShift Service Mesh 2.6 e o 3.0.

Para ver um exemplo do OpenShift Service Mesh 3 em ação, com métricas totalmente configuradas e o console do Kiali, consulte este padrão de solução.

Service mesh sem sidecar: modo ambiente do Istio

Esta versão traz compatibilidade de disponibilidade geral para o modo ambiente do Istio no OpenShift Service Mesh. O modo ambiente do Istio é uma novidade significativa que habilita funcionalidades de service mesh em cargas de trabalho sem a necessidade de proxies sidecar.

Com a arquitetura de plano de dados tradicional do Istio, conhecida como "modo sidecar", cada pod de aplicação exige um container proxy sidecar para habilitar os recursos da service mesh. Isso torna a arquitetura simples, mas gera custos indiretos adicionais ao executar uma service mesh, já que um container proxy é necessário para cada container de carga de trabalho da aplicação. Isso também complica a adoção da service mesh, porque os proxies sidecar devem ser adicionados e atualizados como parte do aplicativo e do ciclo de vida da service mesh. Ou seja, as aplicações devem ser reiniciadas quando a service mesh for introduzida e atualizada.

Com a arquitetura de modo ambiente do Istio, o data plane é dividido em dois níveis de proxy: ztunnels e waypoints, que cumprem funções diferentes. 

Proxy do Ztunnel

O Ztunnel é um proxy lightweight e compartilhado no nível do nó que intercepta o tráfego na camada 4, fornecendo segurança (o "Z" significa "confiança zero") na forma de criptografia de segurança mútua da camada de transporte (mTLS), autenticação, telemetria e autorização L4 simples baseada em identidades de aplicações. Ele também fornece logs e métricas no nível da camada 4 básica (por exemplo, TCP) que, como todas as métricas da service mesh, podem ser visualizadas usando o console do Kiali.

O fato de o ztunnel ser escrito em Rust para essa finalidade específica permite que ele alcance um proxy de alto desempenho com o mínimo de sobrecarga adicional. 

Embora o ztunnel seja executado como um proxy no nível do nó, um DaemonSet do Kubernetes, ele implementa o redirecionamento de tráfego dentro do namespace de rede de cada pod. Isso significa que, do ponto de vista do isolamento de rede, o redirecionamento e a criptografia do tráfego realmente ocorrem dentro do pod e, assim, o isolamento e a criptografia do tráfego pod para pod são mantidos. Isso é discutido em mais detalhes, juntamente com como o agente CNI do Istio configura esse redirecionamento de tráfego, na documentação do Istio sobre redirecionamento de tráfego do ZTunnel.

Com o modo ambiente do Istio, se você só precisa dos recursos fornecidos pelo ztunnel, ele é o único proxy que você precisa executar, resultando em uma service mesh com muita eficiência de recursos.

Proxy de waypoint

Se os usuários quiserem funcionalidades de service mesh no nível da aplicação (camada 7), como telemetria relacionada a HTTP ou gRPC, gerenciamento de tráfego e políticas de autorização, eles poderão introduzir proxies adicionais chamados "waypoints". Normalmente, eles são implantados por namespace, com um grupo de cargas de trabalho de aplicações estreitamente relacionadas. 

Além dos recursos já fornecidos pelo ztunnel, um waypoint proxy adiciona recursos como:

• Roteamento HTTP e balanceamento de carga, novas tentativas, tempos-limite, quebra de circuitos, limitação de taxa e injeção de falhas
• Políticas de autorização avançadas baseadas em L7 primitivos, como tipo de solicitação ou cabeçalho HTTP
• Métricas HTTP, registro em log de acesso e rastreamento

Os proxies de waypoint são gerenciados de maneira semelhante aos gateways de entrada, como proxies Envoy autônomos e, da mesma forma, provavelmente passam pelo ciclo de vida com as cargas de trabalho da sua aplicação, em vez de com o control plane da service mesh ou o ztunnel por nó.

O modo ambiente do Istio é a opção certa para você? Quais são os benefícios, vantagens e desvantagens? 

O modo ambiente do Istio ainda está em evolução na comunidade do Istio e, no momento, é ideal para novas instalações de service mesh, já que há algumas limitações ao migrar ou combinar com o modo sidecar (mais sobre esse tópico abaixo).  

O OpenShift 4.19 ou posterior deve ser usado para as definições de recursos personalizados (CRDs) da API de gateway do Kubernetes, recomendadas para configurar gateways de entrada e são necessárias para configurar proxies de waypoint do ambiente. O OpenShift Service Mesh 4.18 e versões anteriores não incluem ou oferecem suporte para essas CRDs.

Alguns dos benefícios e compensações de adotar o modo ambiente incluem:

Custos de recursos significativamente reduzidos

Como os sidecars não são mais necessários, o modo ambiente do Istio reduz significativamente a área de ocupação de recursos, tanto na memória quanto na CPU, necessários para adotar recursos de service mesh, como criptografia mTLS. Vimos reduções de uso de memória de mais de 90% e de CPU de mais de 50% em comparação com o modo sidecar. Uma redução ainda maior no uso de recursos é vista quando apenas o ztunnel é usado. 

Rede leve de confiança zero

Acreditamos que a maior motivação para o modo ambiente do Istio é a criptografia mTLS lightweight entre pods. À medida que a rede de confiança zero se torna uma prioridade mais alta, mais clientes exigem service mesh para aplicar a criptografia mTLS em um grande número de aplicações. O modo ambiente do Istio com ztunnel sozinho oferece isso, incluindo gerenciamento de identidade e certificado, enquanto minimiza a sobrecarga de recursos e o impacto nas cargas de trabalho em execução. À medida que os requisitos aumentam, é possível adicionar waypoints para introduzir políticas e telemetria no nível da aplicação, como aquelas baseadas em tipos de solicitação HTTP (por exemplo, /GET) ou cabeçalhos. 

Escalabilidade aprimorada 

Com menos proxies para gerenciar e uma área de ocupação significativamente menor, o potencial de escalabilidade do modo ambiente do Istio é significativamente maior do que o modo sidecar tradicional. Temos visto clientes escalando meshes para dar suporte a milhares de cargas de trabalho usando as funcionalidades de escala e escopo do Istio. No entanto, a arquitetura do modo ambiente oferece o potencial para escalar dezenas ou até mesmo centenas de milhares de cargas de trabalho com menos otimizações necessárias. 

Possíveis características de desempenho

Embora as primeiras medidas de desempenho na comunidade do Istio tenham sido promissoras, ainda estamos avaliando o desempenho do modo ambiente do Istio em uma configuração empresarial comparável à dos nossos clientes. Até o momento, vimos um desempenho comparável ao do modo sidecar, com potencial de melhoria em versões futuras. As características de desempenho serão diferentes com o ztunnel sozinho em comparação com o ztunnel e um waypoint, com um waypoint adicionando maior sobrecarga dependendo da configuração. Também encontramos um gargalo conhecido de desempenho que limitava a escalabilidade vertical do ztunnel, e levará algum tempo para ser resolvido. Acreditamos que a arquitetura ambiente do Istio mostra potencial para melhorias de desempenho em versões futuras.

Adoção facilitada

O modo ambiente do Istio também facilita a adoção da service mesh, eliminando a necessidade de modificar as cargas de trabalho para adicionar containers sidecar. Na verdade, eles nem precisam ser reiniciados para serem adicionados à mesh ou quando esta é atualizada. A arquitetura de dois níveis também permite que as funcionalidades do Istio sejam adotadas incrementalmente, sem incorrer nos custos de recursos do proxy da camada 7 quando não é necessário. 

Níveis de suporte a funcionalidades

Observe que o nível de suporte para os recursos do Istio com o modo ambiente pode ser diferente do modo sidecar tradicional. Para ver a lista de recursos compatíveis, consulte a tabela de suporte a recursos do Service Mesh. Funcionalidades avançadas, como multicluster e multimesh, ainda estão em desenvolvimento, enquanto a mistura de cargas de trabalho com sidecar e modo ambiente tem limitações, principalmente para usar waypoint proxies com sidecars. Para ver a perspectiva da comunidade do Istio sobre a relação ambiente versus sidecar, consulte esta página. 

Considerações sobre upgrade

O modo ambiente do Istio oferece o benefício de que o plano de dados do Istio pode ser atualizado sem reiniciar os pods de carga de trabalho, o que é necessário com proxies sidecar. A desvantagem é que os ztunnels são agentes compartilhados no nível do nó que fazem parte do caminho de dados para vários aplicativos. Portanto, o ztunnel deve ser atualizado com cuidado. Recomendamos realizar o upgrade durante uma janela de manutenção ou um período de tráfego baixo, o que resultará na redefinição de conexões TCP de longa duração nesse nó. Os upgrades baseados em revisão (canário) também não são compatíveis com esta versão. Essa será uma área de desenvolvimento em versões futuras.

Introdução ao modo ambiente do Istio

Para começar a usar o modo ambiente do Istio, o OpenShift Service Mesh fornece o recurso "Ztunnel" para instalar e gerenciar o ztunnel como um daemonset. Ele é instalado com os recursos "Istio" e "IstioCNI", que devem ser configurados com o perfil "ambiente", mesmo que algumas cargas de trabalho tenham sidecars. 

Assim como no modo sidecar tradicional, também é importante configurar os "seletores de descoberta" do Istio para garantir que o control plane do Istio possa monitorar os namespaces que devem fazer parte da mesh e nada mais. Para o modo ambiente, o rótulo "istio.io/dataplane-mode=ambient" é usado para indicar que um namespace ou carga de trabalho deve ser incluído na mesh. Para mais informações sobre como adicionar cargas de trabalho, consulte a documentação da comunidade Istio.

Quando uma nova carga de trabalho é adicionada à mesh, o agente CNI do Istio trabalha com o proxy ztunnel node-local para configurar o redirecionamento de tráfego, de modo que todo o tráfego seja interceptado e atualizado para usar o mTLS usando o protocolo de tunelamento HBONE do Istio. O Ztunnel também lida com a busca e o gerenciamento de certificados para todos os pods no mesmo nó.

Se quiser um proxy de waypoint, ele pode ser adicionado da mesma forma que um gateway de entrada ou saída seria adicionado usando o recurso "Gateway" do Kubernetes da API Gateway do Kubernetes, incluída no OpenShift 4.19+. Mais informações sobre a instalação de waypoints aqui e como usar waypoints para funcionalidades L7 aqui.

Para ver um procedimento detalhado de introdução ao modo ambiente do Istio, consulte a documentação do o OpenShift Service Mesh.

Posso migrar para o modo ambiente se já estiver usando a service mesh?

Embora o modo ambiente seja ideal para novos usuários de service mesh, ele também pode ser introduzido em implantações de service mesh existentes e combinado com cargas de trabalho no modo sidecar, com certas ressalvas. Também prevemos que o modo sidecar continuará sendo o caso de uso preferido quando o conjunto completo de recursos de um proxy dedicado do Envoy por pod for necessário. 

Para introduzir o modo ambiente em uma mesh existente, a mesh (Istio e Istio CNI) deve ser atualizada com o perfil "ambiente". Além disso, todas as cargas de trabalho com sidecars devem ser reiniciadas para poderem se comunicar com os ztunnels usando o protocolo de tunelamento HBONE. 

Uma limitação atual dessa coexistência é que o tráfego entre proxies sidecar e cargas de trabalho de ambiente geralmente ignora proxies de waypoint; portanto, as políticas da camada 7 não serão aplicadas à carga de trabalho de ambiente.

Dadas essas limitações, recomendamos que os namespaces e grupos de aplicações usem o modo ambiente ou o modo sidecar, e não misturem modos em cargas de trabalho de aplicações fortemente acopladas. Também é importante evitar misturar os rótulos de pod do sidecar e do modo ambiente.

Kiali com ambiente do Istio

Kiali, o console do Istio incluído no OpenShift Service Mesh, oferece muitos recursos para configurar, visualizar e validar o modo ambiente do Istio. Com cargas de trabalho operando em diversos estados — como ztunnel, waypoints ou sidecars — o Kiali é essencial para visualizar o mesh e diagnosticar comportamentos inesperados em aplicações distribuídas.

O Kiali fornece confirmações claras em todos os níveis de que o modo ambiente foi configurado com êxito. Isso começa com o control plane do Istio em execução com o perfil de ambiente habilitado e que os namespaces e as cargas de trabalho foram rotulados, para que o tráfego da carga de trabalho seja capturado pelo ztunnel e/ou waypoint conforme o esperado. Por fim, no nível do pod, você pode verificar se o tráfego está sendo protegido usando o protocolo HBONE do Istio, em vez de TCP não criptografado.

O Kiali também fornece logs correlacionados entre o ztunnel e o waypoint, para que você possa entender e solucionar problemas de como o tráfego se move da carga de trabalho por cada proxy.

Embora os proxies de waypoint sejam semelhantes a outros proxies, o Kiali tem uma guia específica para mostrar quais serviços e cargas de trabalho foram registrados. 

Por fim, os gráficos de topologia do modo ambiente diferem em comparação com o modo sidecar. Como agora há dois níveis de proxy, pode haver dois conjuntos independentes de telemetria relatados por carga de trabalho: métricas L4 (TCP) exibidas com bordas azuis dos ztunnels e métricas L7 (HTTP) exibidas com bordas verdes onde um waypoint foi configurado. O Kiali oferece a capacidade de selecionar o tipo de tráfego exibido.

Como é provável que os proxies de waypoint representem grupos de cargas de trabalho fortemente acopladas (talvez formando uma aplicação distribuída comum), a visualização de waypoint oferecerá uma visão geral de alto nível da sua mesh no que poderia ser uma mesh muito grande.

Para obter mais informações sobre todos os recursos do Kiali para o modo ambiente, consulte a documentação da comunidade Kiali.

Atualizações do Istio 1.27

Esta versão inclui todas as atualizações mencionadas nas notas de alteração do Istio 1.27. Estes são alguns dos destaques.

Extensões de inferência de API do gateway (GIE)

Esta versão inclui suporte para Gateway API Inference Extensions. Para oferecer um suporte aprimorado aos clientes no Red Hat OpenShift AI 3, realizamos o backporting da implementação de disponibilidade geral (versão 1.0) da API para esta versão. Essa funcionalidade é compatível apenas com o Red Hat OpenShift AI 3 sendo considerada uma apresentação prévia de tecnologia do OpenShift Service Mesh 3.2. 

Multicluster com modo ambiente

Esta versão introduz o suporte inicial para o modo ambiente do Istio em uma topologia multiprimária e multicluster. Como essa funcionalidade ainda está em desenvolvimento upstream, ela foi designada como "apresentação prévia para desenvolvedores" do OpenShift Service Mesh 3.2. 

Suporte nativo ao nftables no modo sidecar

Em preparação para o Red Hat Enterprise Linux (RHEL) 10, a Red Hat contribuiu com suporte ao nftables para o projeto Istio, com suporte para o modo sidecar introduzido no Istio 1.27. O nftable framework é o sucessor moderno do iptables, o recurso do Linux usado pelo Istio para configurar regras de redirecionamento de rede. Ele tem como objetivo oferecer melhor desempenho, capacidade de manutenção e gerenciamento de regras mais flexível para redirecionamento de tráfego de e para o sidecar do Envoy. A partir do RHEL 10, o nftables será a ferramenta padrão para gerenciar regras de rede. O suporte para o RHEL 10 virá em uma versão futura do OpenShift.

O Cert-manager Istio-CSR já está disponível

O operador cert-manager é compatível para uso com o OpenShift Service Mesh, embora o agente istio-csr seja necessário para que o cert-manager assine, entregue e renove certificados para cargas de trabalho. Com o lançamento do operador cert-manager, versão 1.18, esse agente agora está disponível para o público geral e pode ser usado com todas as versões compatíveis do OpenShift Service Mesh. Para mais informações sobre como o cert-manager e o OpenShift Service Mesh funcionam juntos para viabilizar a confiança zero, leia este post. Para o procedimento que descreve como usar o cert-manager com o OpenShift Service Mesh, consulte a documentação.

Introdução ao OpenShift Service Mesh

Para saber mais sobre o Red Hat OpenShift Service Mesh, leia este post e a continuação da service mesh multicluster. 

Para começar a usar a service mesh, você precisa primeiro instalar o Red Hat OpenShift Service Mesh 3 Operator. Se você ainda não conhece a service mesh, considere o modo ambiente do Istio. Ele oferecerá uma arquitetura de service mesh com recursos muito mais eficientes do que o modo sidecar tradicional. Para começar a usar o modo ambiente do Istio, leia a documentação aqui. 

Para ver um exemplo completo do uso do OpenShift Service Mesh com monitoramento de cargas de trabalho do usuário do OpenShift, rastreamento distribuído e Kiali, consulte este padrão de solução.