Plano de controle gerenciado

<0x0

Este documento explica as diferenças arquitetônicas entre a implementação descontinuada do plano de controle ISTIOD e a implementação moderna do plano de controle TRAFFIC_DIRECTOR do Google. Ele também descreve as próximas etapas se os clusters ainda usarem um plano de controle descontinuado.

Visão geral do plano de controle

Em malhas de serviço, o plano de controle oferece gerenciamento de tráfego, gerenciamento de proxy quando o proxy Envoy está em uso e outros recursos de rede.

O Cloud Service Mesh usando APIs do Istio em clusters do GKE oferece uma implementação totalmente compatível das APIs do Istio. As APIs são implementadas e compatíveis com o plano de controle TRAFFIC_DIRECTOR totalmente gerenciado e integrado ao Cloud Networking. Antes, havia suporte para duas implementações adicionais de plano de controle:

  • A implementação ISTIOD gerenciada descontinuada, que executa um plano de controle dedicado de cluster único.
  • A implementação ISTIODno cluster descontinuada, que executa componentes do plano de controle gerenciados pelo cliente dentro do cluster.

Características operacionais do plano de controle TRAFFIC_DIRECTOR

O Cloud Service Mesh com o plano de controle TRAFFIC_DIRECTOR usa a infraestrutura de rede gerenciada do Google Cloudem vez de instâncias de plano de controle por cluster.

As APIs do Istio (CRDs) e a configuração xDS enviada aos sidecars do Envoy permanecem compatíveis, mas você pode esperar as seguintes características operacionais:

  • Propagação de políticas e configurações de serviço:ao criar novos serviços ou atualizar políticas de roteamento e segurança, a configuração é validada e propagada em sistemas Google Cloud antes de entrar em vigor nos sidecars. Como resultado, a propagação inicial de políticas e serviços leva mais tempo do que com planos de controle no cluster ou ISTIOD. Para orientações sobre como otimizar fluxos de trabalho de implantação, consulte Propagação de configuração.
  • Escalonamento de pods e atualizações de endpoints:as mudanças nos endpoints de carga de trabalho, como novos pods criados pelo escalonamento automático horizontal de pods ou pods reiniciados com novos endereços IP, são propagadas diretamente pelo plano de controle sem a latência associada às atualizações de política. Os pods atuais que buscam a configuração existente são iniciados sem demora.
  • Descoberta de endpoints de vários clusters:em malhas de vários clusters, os clusters compartilham os endpoints diretamente por Google Cloud em vez de sincronizá-los ponto a ponto entre cada combinação de clusters. Isso garante que o estado do endpoint entre clusters convirja mais rapidamente e de forma consistente à medida que a malha é escalonada.

Como isso afeta você?

As próximas etapas dependem de qual implementação do plano de controle do Cloud Service Mesh seus clusters usam:

Modernização do plano de controle para o Cloud Service Mesh gerenciado com a implementação do ISTIOD

Todas as frotas gerenciadas que executam a implementação ISTIOD descontinuada precisam concluir a modernização para a implementação TRAFFIC_DIRECTOR antes do prazo de fim de suporte especificado no aviso de descontinuação. É possível modernizar sua frota usando a modernização acionada pelo cliente (recomendada para controle por cluster e migração de tráfego em etapas) ou a modernização orientada pelo Google (implantações automatizadas para frotas qualificadas).

Para instruções detalhadas, consulte Modernização do plano de controle gerenciado.

Verificar a compatibilidade do plano de controle

Para avaliar sua frota em relação aos recursos compatíveis e identificar bloqueadores de configuração antes da modernização, consulte:

Apêndice: cronograma de lançamento e descontinuação do plano de controle

A transição dos planos de controle ISTIOD para a implementação do plano de controle gerenciado TRAFFIC_DIRECTOR seguiu esta linha do tempo:

  • 23 de maio de 2024: o Anthos Service Mesh e o Traffic Director foram unificados no Cloud Service Mesh, apresentando a implementação do plano de controle TRAFFIC_DIRECTOR para APIs do Istio.
  • 1º de julho de 2024: as novas frotas integradas ao Cloud Service Mesh gerenciado começaram a receber a implementação do TRAFFIC_DIRECTOR por padrão.
  • 8 de setembro de 2024:o provisionamento da implementação do ISTIOD para novas frotas foi encerrado para disponibilidade geral (com exceções temporárias para organizações específicas em uma lista de permissões).
  • 28 de setembro de 2026: anúncio formal da descontinuação da implementação do plano de controle ISTIOD gerenciado e do plano de controle no cluster no GKE.