Conheça o OpenShift Service Mesh 3.1

O Red Hat OpenShift Service Mesh 3.1 foi lançado e faz parte das soluções Red Hat OpenShift Container Platform e Red Hat OpenShift Platform Plus. Baseado nos projetos Istio, Envoy e Kiali, este lançamento atualiza o Istio para a versão 1.26 e o Kiali para 2.11, além de oferecer suporte ao OpenShift Container Platform 4.16 e versões posteriores.

Este é o primeiro lançamento secundário após o lançamento principal do Red Hat OpenShift Service Mesh 3.0, uma atualização importante para convergir o OpenShift Service Mesh com o projeto Istio da comunidade, com instalação e gerenciamento usando o operador Sail. Essa alteração ajuda a garantir que o OpenShift Service Mesh possa oferecer os recursos estáveis ​​mais recentes do Istio com o suporte da Red Hat.

Upgrade para o OpenShift Service Mesh 3.1

Se você estiver executando o OpenShift Service Mesh 2.6 ou versões anteriores, deverá atualizar para o OpenShift Service Mesh 3.0 antes de atualizar para 3.1. Recomendamos migrar para o OpenShift Service Mesh 3.0 imediatamente, pois a versão 2.6 chegará ao fim em 12/03/2026. A documentação do OpenShift Service Mesh 3.0, incluindo uma análise sobre as diferenças entre o OpenShift Service Mesh 2.6 e 3.0 fornece um guia de migração detalhado.  

Também publicamos recentemente um artigo que descreve como usar o console do Kiali para migrar entre o OpenShift Service Mesh 2.6 e 3.0.

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

Suporte à API Kubernetes Gateway no OCP 4.19 e versões posteriores

A API Kubernetes Gateway é a próxima geração das APIs de Ingress, balanceador de carga e service mesh do Kubernetes. O Istio planeja torná-la o conjunto padrão de APIs para criar e gerenciar tráfego usando uma service mesh, e o modo ambiente do Istio exige seu uso. Observe que não há planos para remover as APIs estáveis do Istio, como a VirtualService, DestinationRule e outras. Em alguns momentos, pode-se usar essas APIs para aproveitar recursos que ainda não foram adicionados à API Kubernetes Gateway.

Embora o OpenShift Service Mesh 3.0 já incluísse suporte à API Kubernetes Gateway, ele exigia que os usuários instalassem definições de recursos personalizados (CRD) sem suporte para usarem o recurso. Isso mudou a partir do OpenShift Container Platform 4.19 e versões posteriores, com as CRDs necessárias agora disponíveis de forma padrão no OpenShift. Você não precisa mais instalar essas CRDs separadamente. A Red Hat oferece suporte total às CRDs da API Gateway incluídas no OpenShift.

Como buscamos oferecer suporte otimizado para padrões de tráfego e cargas de trabalho de inteligência artificial (IA) generativa, incluímos suporte à Prévia de Tecnologia para a Gateway API Inference Extension ao fazer o backport desse recurso para o OpenShift Service Mesh 3.1.

Suporte de dual-stack geralmente disponível para clusters x86

Este lançamento disponibiliza o suporte a cargas de trabalho IPv4 e IPv6 de stack duplo com o OpenShift Service Mesh para clusters do OpenShift que rodam em hardware x86. Para habilitar o suporte a stack duplo no OpenShift Service Mesh, você precisa definir a flag ISTIO_DUAL_STACK como "true" no seu recurso de cliente do Istio. Isso é demonstrado na documentação upstream do sail-operator para stack duplo e na documentação de stack duplo do Istio da comunidade, com a documentação do OpenShift Service Mesh a seguir.

Migração para microcontainers UBI

Essa versão move a maioria dos containers, incluindo os containers key istiod e proxy (Enovy), para usar as imagens-base do (UBI) Micro. A UBI Micro é a menor imagem Universal Base Image (UBI) do Red Hat Enterprise Linux, obtida pela exclusão de um gerenciador de pacotes e todas as suas dependências, que normalmente são incluídas em uma imagem de container. A adoção da UBI Micro ajuda a minimizar a superfície de ataque das imagens de contêiner entregues como parte do OpenShift Service Mesh.

Em direção a uma service mesh sem sidecar: o modo ambiente do Istio

O OpenShift Service Mesh 3.1 baseia-se no Istio 1.26 e inclui principalmente atualizações incrementais em comparação com o OpenShift Service Mesh 3.0, que se baseava no Istio 1.24. Isso ocorre porque a comunidade do Istio e a Red Hat estão muito focadas na próxima geração de plano de dados de service mesh: o modo ambiente do Istio.

Observamos um crescimento constante no uso de service mesh nos últimos anos, mas a necessidade de proxies sidecar costuma ser um impedimento para a adoção devido aos recursos extras (memória e CPU, principalmente) necessários para executar containers sidecar ao lado de cada container de aplicação. Isso complica a adoção do service mesh, porque é preciso adicionar e atualizar os proxies sidecar como parte do ciclo de vida do pod. Ou seja, as aplicações precisam ser reiniciadas para introduzir uma atualização do service mesh.

O modo ambiente do Istio solucionará essas preocupações, removendo a necessidade de proxies sidecar e dividindo o plano de dados do Istio em duas camadas separadas. Isso permite a adoção incremental de recursos de service mesh com menos complexidade para os proprietários de aplicações.

Essa arquitetura dividida resulta em uma quantidade reduzida de proxies implantados para habilitar a service mesh, diminuindo consideravelmente os recursos necessários para executar uma service mesh. Como o modo ambiente do Istio não exige proxies sidecar, é possível adicionar e remover aplicações do mesh sem a necessidade de modificar ou reiniciar os pods da aplicação.

As duas camadas separadas do modo de ambiente do Istio são:

• Ztunnel: um proxy leve de camada 4 no nível do nó (executado como um Daemonset no Kubernetes), que cria um soquete de escuta dentro do namespace da rede do pod da aplicação para fazer upgrade transparente do tráfego no nível do pod com criptografia mTLS. O Ztunnel também cuida do gerenciamento de certificados e identidades para pods no nó (e somente os pods no nó). Com o Ztunnel sozinho, você pode obter criptografia mTLS automática, telemetria de camada 4 e gerenciamento de políticas.
• Waypoint: um proxy opcional do Envoy, semelhante a um gateway, implantado para um conjunto de aplicações (com escopo de namespace por padrão) para fornecer recursos de malha de camada 7, como segurança no nível da aplicação e políticas de tráfego, recursos de telemetria no nível da aplicação e resiliência de malha. Ao contrário dos sidecars, é possível adicionar e dimensionar os proxies de ponto de referência conforme necessário, independentemente dos contêineres da aplicação.

Para mais detalhes sobre a arquitetura do modo de ambiente do Istio e suas vantagens e desvantagens, leia Experimente o modo de ambiente do Istio no Red Hat OpenShift.

O OpenShift Service Mesh 3.1 atualiza o status do modo ambiente do Istio para Prévia da Tecnologia, com um proxy Ztunnel, que a Red Hat oferece suporte total e que usa OpenSSL para criptografia para garantir sua conformidade com FIPS. O OpenShift Service Mesh 3.1 inclui documentação para introdução ao modo ambiente do Istio no OpenShift como parte do guia de instalação. Desenvolveremos isso nos próximos meses, à medida que avançamos para a disponibilidade geral da solução.

Observe que o modo ambiente do Istio exige a API Kubernetes Gateway, portanto, use-o no OpenShift Container Platform 4.19 ou versão posterior, que inclui CRDs de API de gateway compatíveis, que o OpenShift instala por padrão. Se você quiser experimentar o modo ambiente do Istio em versões anteriores do OpenShift, deverá instalar CRDs da API Kubernetes Gateway sem suporte, conforme a documentação da comunidade do Istio descreve. Observe que o upgrade para as CRDs da API Kubernetes Gateway compatíveis no OCP 4.19 pode resultar em tempo de inatividade.

Também recomendamos experimentar o modo ambiente do Istio em clusters que ainda não têm o OpenShift Service Mesh instalado para reduzir a probabilidade de interferir nas implantações de service mesh existentes. No futuro, forneceremos documentação sobre a execução de um plano de dados no modo ambiente com um plano de dados no modo sidecar, além de orientações sobre como migrar aplicações do modo sidecar para o modo ambiente.

Observe que, a partir do Istio 1.26, nem todos os recursos do modo sidecar têm suporte para o modo ambiente, e alguns recursos permanecem na versão "Alpha" no Istio upstream. O modo ambiente pode não ser apropriado para todos os casos de uso para a service mesh. As principais lacunas são as múltiplas configurações de clusters de rede e a interoperabilidade entre os planos de dados dos modos ambiente e sidecar. Essas e outras funcionalidades estão em desenvolvimento na comunidade do Istio.

Atualizações do Kiali

O Kiali é o console do Istio service mesh incluído no OpenShift Service Mesh. Essa versão o atualiza para 2.11 e inclui muitas atualizações e aprimoramentos (como o modo ambiente do Istio).

Atualizações da página do mesh

A página mesh continua a receber aprimoramentos como o painel principal para monitorar o status da infraestrutura do Istio, abrangendo o plano de controle do Istio em si, os componentes do plano de dados e os complementos de observabilidade, como Prometheus e Tempo. Esta versão inclui várias atualizações, incluindo gateways do Istio e os componentes de plano de dados do modo ambiente: Ztunnel e Waypoint. Da página mesh, você pode examinar os componentes para revelar informações de status importantes, como métricas e dumps de configurações relevantes a cada um dos componentes.

Desempenho e escalabilidade com meshes de grande porte

Uma preocupação comum com o Kiali é o desempenho à medida que o número de cargas de trabalho na service mesh aumenta. No passado, o Kiali tinha dificuldades para permanecer responsivo com service meshes de grande porte. As Perguntas Frequentes (FAQ) do projeto Kiali agora incluem uma nova seção sobre desempenho que fornece orientações para usar o Kiali com implantações de mesh de grande porte. Esta versão inclui atualizações para aprimorar o desempenho, como atualizações para gerenciar meshes de grande porte de maneira aprimorada.

Por exemplo, por padrão, o Kiali tenta renderizar uma página imediatamente e atualiza automaticamente a maioria das páginas com base na configuração do menu suspenso Refresh Interval. Para meshes de grande porte, até mesmo a renderização inicial pode ser lenta, atrasando sua capacidade de usar o console. O Kiali agora oferece uma configuração de atualização Manual que atualiza uma página somente quando o botão Refresh for clicado manualmente. É possível definir isso com o spec.kiali_feature_flags.ui_defaults.refresh_interval: manual na definição de recurso personalizado (CRD) do Kiali. 

Você também pode desabilitar validações para aprimorar o desempenho e a capacidade de resposta com meshes de grande porte. Para fazer isso, defina a configuração do operador Kiali spec.external_services.istio.validation_reconcile_interval para 0.

Comece a usar o OpenShift Service Mesh

Se você é novo no OpenShift Service Mesh, comece lendo a introdução ao OpenShift Service Mesh e nossas instruções de instalação do Dia 1. Para um exemplo de funcionamento completo, confira o conteúdo Otimizando o tráfego e a observabilidade com o OpenShift Service Mesh 3.

Se você vem da versão OpenShift Service Mesh 3.0, revise a documentação de upgrade para diferentes abordagens para atualizar o operador do OpenShift Service Mesh 3, planos de controle do Istio, recurso CNI do Istio e os proxies que compõem o plano de dados.

Se você vem da versão OpenShift Service Mesh 2.6 ou anterior, revise as diferenças entre o OpenShift Service Mesh 2 e 3 e nossa extensa documentação de migração. Há também um blog post que descreve o procedimento usando o Kiali.