Red Hat OpenShift Service Mesh 3: atualização da prévia para desenvolvedores

No início deste ano, anunciamos um novo operador para Istio no Red Hat OpenShift disponível na versão de prévia para Desenvolvedores para a próxima geração do OpenShift Service Mesh, versão 3. Este post tem informações importantes sobre as mudanças no OpenShift Service Mesh em 2024. Desde então, continuamos desenvolvendo o Sail Operator enquanto oferecemos suporte aos clientes no OpenShift Service Mesh 2 e recebemos feedback sobre os planos do Service Mesh 3. Enquanto o novo operador ainda está na versão de prévia para desenvolvedores, este post traz uma atualização, discute planos para o futuro e oferece orientações iniciais sobre como os usuários do OpenShift Service Mesh podem se preparar para o OpenShift Service Mesh 3.

Atualizações ao Service Mesh 3.0

O operador Kubernetes do Service Mesh 3 está sendo desenvolvido como o "Sail Operator" e está disponível como um operador Kubernetes da comunidade no Operator Hub do OpenShift. O Sail Kubernetes Operator é atualizado todas as noites, então ele continua em desenvolvimento e sujeito alterações. Durante sua evolução, ele pode ficar diferente das descrições neste post, então utilize-o apenas para testes no momento. Consulte este arquivo README para obter as informações mais recentes sobre o operador Kubernetes.

Planejamos migrar esse operador Kubernetes da comunidade para a organização upstream istio-ecosystem, aumentando a colaboração e contribuindo com melhorias para o projeto principal do Istio para que ele se torne mais compatível com o OpenShift. Os artefatos da solução downstream do OpenShift Service Mesh 3 ficarão na organização openshift-service-mesh recém-criada, enquanto a organização maistra continuará a ser usada para o Service Mesh 2.

Um operador Kubernetes apenas para o Istio

Como falamos no post anterior, o OpenShift Service Mesh 3 será baseado em um novo operador Kubernetes para o Istio. Ao contrário do operador Kubernetes atual do OpenShift Service Mesh 2, o novo operador Kubernetes gerenciará apenas recursos do Istio e não tentará configurar as integrações do Istio como o Kiali. Componentes complementares, como Kiali, métricas, rastreamento e outros, serão gerenciados por operadores Kubernetes de solução com suporte independente.

Quando o Sail Operator foi lançado pela primeira vez, o recurso personalizado para instalar o control plane do Istio era chamado de IstioHelmInstall. Esse recurso foi renomeado como "Istio" para indicar que ele é responsável por criar e gerenciar uma única instância do Istio (um control plane e um plano de dados).

Ao contrário do recurso personalizado ServiceMeshControlPlane usado no OpenShift Service Mesh 2, o recurso Istio usa valores upstream do Helm do Istio para definir a configuração do Istio. Para os usuários, isso facilita a tradução de exemplos de configuração da comunidade para o OpenShift Service Mesh 3. Também ajuda a garantir que nossos esforços futuros para melhorar a configuração sejam feitos em colaboração com a comunidade do Istio. Não descartamos uma convergência futura com a API do operador Istio da comunidade, usada com o processo de instalação do istioctl e a instalação do operador Istioupstream não recomendada.

Nossos próximos esforços incluirão o refinamento da organização da configuração e melhorias para oferecer um suporte aprimorado a funcionalidades como revisões do Istio, upgrades no estilo canárioe multitenancy. Consulte o arquivo README do operador Kubernetes para ver as informações mais atualizadas.

Como selecionar a versão

Quando lançamos o Sail Operator, ele implantava a versão mais recente do Istio, efetivamente a ramificação principal do Istio em desenvolvimento. Apesar de ser útil para experimentar as novidades da comunidade do Istio, na maioria dos casos, os usuários precisavam usar uma versão oficial do Istio para garantir estabilidade e compatibilidade com o istioctl e integrações como Kiali.

Agora, o padrão é a versão mais recente do Istio, 1.20 atualmente. Faça essa configuração no campo version na CRD do Istio. Ao criar uma nova instância com o console do OpenShift, use o menu suspenso para selecionar na lista uma das versões disponíveis do Istio. Elas são definidas no arquivo versions.yaml, que será atualizado para cada nova versão disponibilizada.

Menu suspenso do seletor de versões do Istio

O futuro operador Kubernetes da solução OpenShift Service Mesh 3, que será baseado no Sail Operator, gerenciará as versões do OpenShift Service Mesh de maneira semelhante. O campo version é parecido com o campo version do recurso ServiceMeshControlPlane no Service Mesh 2.x. Porém, uma diferença importante é que os usuários podem especificar uma versão até o nível de versão do "patch" Z (por exemplo, 3.1.1). Nosso suporte é apenas para versões de patch mais recentes do OpenShift Service Mesh. No entanto, com esse recurso, os usuários poderão fixar ou reverter uma versão de patch "z" específica, o que oferece maior controle e flexibilidade para gerenciar atualizações de patch.

Validação da configuração

O campo values é o principal para configurar o Istio com a nova CRD. Nesse campo avançado, os usuários conseguem fazer referência direta aos valores de configuração do Helm do Istio. Incluímos a validação nesse campo para detectar valores de configuração inexistentes e outros erros de configuração com base nas validações de protobufdo do Istio upstream.

Essas validações também permitem o gerenciamento do campo values da seguinte maneira:

$ oc explain istio.spec.values 
KIND:     Istio 
VERSION:  operator.istio.io/v1alpha1 
RESOURCE: values <Object> 
DESCRIPTION: 
    Values defines the values to be passed to the Helm chart when installing 
    Istio. 
FIELDS: 
  base <Object> 
  cni <Object> 
  defaultRevision <string> 
  global <Object> 
  istio_cni <Object> 
  istiodRemote <Object> 
  meshConfig <> 
  ownerName <string> 
  pilot <Object> 
  revision <string> 
  revisionTags <[]string> 
  sidecarInjectorWebhook <Object> 
  telemetry <Object> 
  ztunnel <>

Às vezes, é preciso substituir essas validações, por exemplo, para acessar uma configuração experimental que ainda não faz parte do esquema protobuf do Istio. Por isso, também incluímos um campo rawValues, que é idêntico ao values, mas não é validado.

Observe que os campos resource, values e rawValues do Istio ainda são experimentais e estão sujeitos a alterações. Consulte o projeto README para ver as informações mais recentes.

Status e configuração do Istio

Após aplicar a configuração do Istio, é preciso validar o status do control plane. Para fazer isso, use o seguinte comando:

$ kubectl get istioundefinedundefinedundefined

NAME         READY  STATUS VERSION AGE

istio-sample True  Healthy v1.20.0 62sundefinedundefined

Ou use o campo de status:

Definição de recurso personalizado do Istio

Quando expandido, o campo status.appliedValues pode ser usado para validar se a configuração foi aplicada conforme o esperado usando o campo spec.values.

Istio no OpenShift

Como parte da nossa iniciativa para convergir com o Istio da comunidade, continuamos contribuindo com o Istio upstream para melhorar a compatibilidade dele no OpenShift. Fazemos isso em benefício próprio (para simplificar nosso trabalho de desenvolvimento do Istio como solução) e para a comunidade, clientes e parceiros. Nossas contribuições facilitam a execução do Istio da comunidade no OpenShift e oferecem um caminho de integração fluido para o nosso OpenShift Service Mesh compatível.

Um exemplo desse esforço foi a remoção da necessidade de conceder o privilégio anyuid da restrição de contexto de segurança (SCC) aos componentes do control plane e do plano de dados do Istio, como destacado recentemente no Istio 1.20. Faremos contribuições semelhantes de maneira contínua, e a mais significativa delas será um esforço para que o Ambient mesh do Istio funcione no OpenShift.

Práticas recomendadas para o gateway

Quando esse operador Kubernetes foi anunciado, ele instalou gateways automaticamente, semelhante ao perfil de configuração de instalação padrão do Istio. Isso é consistente com o OpenShift Service Mesh 2.x, que cria um gateway padrão de entrada e saída chamado istio-ingressgateway e istio-egressgateway, respectivamente.

Esses gateways criados automaticamente são úteis para começar, mas não fornecem a capacidade de configuração necessária para ambientes de produção. Também acreditamos que os gateways são mais bem criados e gerenciados com as aplicações no plano de dados, e não no control plane. Gateways criados e gerenciados com as próprias aplicações são mais seguros, limitando a abrangência a menos aplicações e permitindo que ele adote o ciclo de vida das próprias aplicações, e não do control plane.

Por isso, optamos por remover esses gateways do control plane para orientar os usuários a criar gateways com as próprias aplicações, usando a injeção de gateway ou a API Gateway Kubernetes. Conforme especificado no ServiceMeshControlPlane do OpenShift Service Mesh 2.x, oistio-ingressgateway e o istio-egressgateway não serão incluídos no Service Mesh 3.0. Em vez disso, forneceremos exemplos de configurações de gateways para a aplicação Bookinfo usando a injeção de gateway e a API Gateway do Kubernetes.

Com a injeção de gateway, os gateways são criados e gerenciados como qualquer outra carga de trabalho no Kubernetes ou no OpenShift, usando um recurso de implantação injetado com um proxy do Envoy. Essa abordagem dá controle total do gateway ao proprietário da aplicação. Essa é a maneira recomendada de criar e gerenciar gateways no OpenShift Service Mesh 2.3 e posteriores.

Com a API Gateway, na apresentação prévia de tecnologia do OpenShift Service Mesh 2.4, uma instância de "implantação" de gateway é criada e configurada com cada instância de gateway.

Essas opções permitem que os gateways sejam criados e gerenciados com aplicações, idealmente como parte de um fluxo de trabalho do GitOps.

API Gateway do Kubernetes

A API Gateway do Kubernetes representa a próxima geração de APIs para modelagem de rede no Kubernetes. Em comparação com a API Ingress do Kubernetes atual, ela oferece muito mais flexibilidade e extensibilidade para gerenciar redes em uma organização de grande porte. A princípio, o intuito dela era gerenciar o tráfego norte/sul de clientes fora do cluster, mas ela cresceu e incorporou o tráfego leste/oeste, incluindo o Service Mesh. A iniciativa GAMMA foi criada para definir como a API Gateway pode abranger casos de uso de service mesh. Agora, o Istio inclui exemplos de configuração da API Gateway para a maioria das tarefas documentadas, como Gerenciamento de tráfego.

API Gateway ainda é uma funcionalidade de apresentação prévia de tecnologia no OpenShift Service Mesh 2.4 e precisa ser ativada com um sinalizador de funcionalidade, mas agora tem disponibilidade geral na comunidade. A versão 1.0 da API está disponível no Istio 1.20, que será incluído no OpenShift Service Mesh 2.6 e posteriores. A intenção do Istio é usar a API Gateway como padrão para todo o gerenciamento de tráfego, mantendo a compatibilidade com as APIs do Istio (Gateway, VirtualService, DestinationRule, etc.).

O projeto da API Gateway tem o potencial de oferecer um padrão comum para redes Kubernetes, e nossa empolgação vai muito além do service mesh.

Estamos desenvolvendo uma implementação baseada na API Gateway do OpenShift Ingress que os usuários podem implantar sem service mesh por meio do operador Ingress da API Gateway. Para obter mais informações sobre esse projeto e a API Gateway, consulte este post e a atualização mais recente.

Enquanto isso, a equipe que criou o 3Scale API Management está trabalhando no projeto Kuadrant.io. Ele usará a API Gateway para lidar com casos de uso relacionados a como o tráfego externo entra em um gateway de entrada, como conectividade de vários clusters, balanceamento de carga global, limitação de taxa, autorização e muito mais. Confira as informações sobre esse projeto no próximo post.

Introdução aos complementos do Istio, como o Kiali

Uma mudança importante no OpenShift Service Mesh 3.0 é que o operador Kubernetes gerenciará apenas o Istio. Integrações como Kiali, rastreamento distribuído e métricas serão instalados e gerenciados de modo independente. Isso gera mais etapas para a experiência inicial, mas acreditamos ser uma boa troca para ter mais modularidade e flexibilidade na configuração desses componentes.

Para ajudar os usuários nesse primeiro momento, incluímos algumas instruções no README do operador Kubernetes para configurar o Istio com Istioctl, gateways de amostra, Prometheus, Jaeger e Kiali. Assim, o usuário tem um ambiente de demonstração/desenvolvimento parecido com o do OpenShift Service Mesh 2.x atualmente. Ele também fornece uma prévia do fluxo de trabalho de instalação que planejamos oferecer no OpenShift Service Mesh 3, com instalação automática do Istio e independente dos complementos. É claro que o Service Mesh 3.0 usará operadores Kubernetes de solução compatíveis para cada um dos complementos do Istio com uma distribuição compatível do Istioctl. Essas configurações de complemento do Istio da comunidade são apenas para fins de demonstração/desenvolvimento e não devem ser usadas para ambientes de produção.

Como se preparar para o Service Mesh 3.0

Há várias medidas que os usuários do OpenShift Service Mesh 2 podem tomar para se preparar para a adoção do Service Mesh 3.0.

É importante lembrar que o OpenShift Service Mesh 3 continuará baseado no Istio, e não haverá alteração nas APIs estáveis do Istio que provavelmente serão utilizadas pelos usuários finais. As mudanças no OpenShift Service Mesh 3 que exigirão migração são os recursos de configuração do control plane, como ServiceMeshControlPlane, ServiceMeshMemberRolle ServiceMeshMemberRoll. Em geral, esses recursos são gerenciados por administradores ou equipes de plataforma, e não pelos proprietários das aplicações. Continuaremos explorando algumas formas que os administradores podem usar para migrar as configurações de control plane existentes para o Service Mesh 3.

Não haverá mudança na configuração específica da aplicação (recursos do Istio como VirtualServices, DestinationRulese até mesmo PeerAuthentication). Assim, os usuários se sentirão seguros para começar ou expandir o uso do OpenShift Service Mesh 2 sem precisar migrar configurações específicas de aplicações, ou serviços na transição para o OpenShift Service Mesh 3.

Há algumas coisas que os usuários podem fazer hoje para facilitar a migração para o OpenShift Service Mesh 3.0. Além de usar a versão mais recente do OpenShift Service Mesh (2.4 ou posterior), os usuários podem:

• Fazer a adoção ou migração para a injeção de gateway para criar e gerenciar gateways do Istio com as próprias aplicações, e não com o control plane do Istio (que é o padrão no Service Mesh 2.0). Conforme descrito acima, o control plane no 3.0 não criará gateways.
• Usar o modo em todo o cluster, se não forem necessários vários control planes. Com esse modo, o Istiod é executado como um recurso no nível do cluster. Esse será o padrão no Service Mesh 3.0, com a possibilidade de criar vários control planes usando a nova funcionalidade Multiple-Control Plane.
• Configurar o Service Mesh para usar o monitoramento de carga de trabalho do usuário do OpenShift ou a observabilidade do Red Hat Advanced Cluster Management para capturar métricas. Eles vão oferecer um stack de monitoramento de nível de produção com alerta muito mais configurável e extensível do que o stack de métricas instalado com o OpenShift Service Mesh 2.x (e que será removido no Service Mesh 3).
• Usar recursos do Kiali e Jaeger configurados externamente em vez de configurá-los diretamente no recurso ServiceMeshControlPlane. Além de oferecer mais flexibilidade para gerenciar o Kiali e o Jaeger, eles serão configurados de maneira independente no Service Mesh 3.

Publicaremos um post que abordará mais a fundo cada um desses tópicos.

Qual é o futuro do OpenShift Service Mesh?

Nosso próximo lançamento será o OpenShift Service Mesh 2.5 (baseado no Istio 1.18) no início de 2024. Também decidimos fazer uma versão 2.6 baseada no Istio 1.20 ou posterior em 2024 para garantir que os clientes tenham pelo menos um ano de suporte sobreposto para fazer upgrade do OpenShift Service Mesh 2 para o 3. A versão 2.6 também nos dará mais tempo para receber feedback sobre o OpenShift Service Mesh 3 durante o estado de apresentação prévia da tecnologia.

Para o OpenShift Service Mesh 3, continuamos a desenvolver o novo operador Kubernetes, incluindo ajustes nas definições de recursos personalizados para gerenciar melhor a configuração do Istio e adicionar funcionalidades para oferecer suporte aprimorado aos upgrades canário dos control planes do Istio. A apresentação prévia de tecnologia está prevista para o final do primeiro trimestre de 2024, com disponibilidade geral para o segundo semestre do mesmo ano. Naturalmente, essas metas estão sujeitas a alterações. Continuaremos oferecendo suporte aos clientes no OpenShift Service Mesh 2.x até termos um OpenShift Service Mesh 3 pronto para disponibilidade geral.

Acesse esta página para saber mais sobre o Red Hat OpenShift Service Mesh.