Plano de controle gerenciado para clientes recorrentes

Este documento é para você se você for um cliente do Anthos Service Mesh que usa o plano de controle gerenciado ou no cluster. Este documento discute a implementação do plano de controle e a possível migração dele.

Se você já é cliente do Traffic Director ou é um novo cliente, não precisa ler este documento.

Visão geral do plano de controle

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

O Anthos Service Mesh oferecia dois planos de controle: um plano de controle gerenciado e um no cluster. Somente os proxies do Envoy são usados como plano de dados.

Novo plano de controle gerenciado

O novo plano de controle gerenciado é chamado de implementação do Traffic Director (TD). O que o novo plano de controle significa para você?

Uma das mudanças mais significativas do produto Anthos Service Mesh para o Cloud Service Mesh é a mudança para um plano de controle global multilocatário.

O plano de controle gerenciado usado no Anthos Service Mesh é dedicado a um único cluster. Embora as APIs (CRDs do Istio) usadas para o GKE sejam as mesmas e a configuração xDS enviada para os sidecars seja compatível sem diferenças comportamentais, as diferenças do plano de controle resultam em algumas características que são visíveis para você, o usuário final.

Tempo de resposta da mudança de configuração. As novas implantações de serviço ou mudanças nas políticas de serviço levam um pouco mais de tempo com o novo plano de controle.
- O pipeline de configuração executa um commit de configuração de duas etapas para fins de confiabilidade. A primeira passagem realiza validações para verificar se a configuração está bem formada. A fase seguinte propaga a configuração globalmente para as implantações de serviço. Para ativar o uso de serviços do Google Cloud, como balanceamento de carga global entre zonas ou regiões, verificação de integridade centralizada, escalonamento automático orientado por tráfego e limitação de taxa gerenciada, a configuração é propagada para esses sistemas e validada de forma independente para verificar a correção. A configuração também é armazenada internamente de uma forma que permite que a engenharia de confiabilidade do site do Google realize operações de produto de forma confiável e eficiente durante emergências de produção.
- Essas operações oferecem uma confiabilidade melhor, mas resultam em um push de configuração mais lento do que a latência observada pelos usuários atuais do Anthos Service Mesh.
- A latência para que qualquer novo pod busque a configuração atual é consideravelmente melhor com o novo plano de controle. O push de configuração lento é para a propagação inicial de qualquer serviço novo criado ou de qualquer política nova enviada para o serviço. As latências de propagação de endpoint são funcionalmente semelhantes.
Velocidade de eventos de escalonamento e outras mudanças nos endpoints. Elas são processadas pelo menos rapidamente com o novo plano de controle. Esses eventos incluem novos pods iniciados ou interrompidos devido ao escalonamento automático horizontal de pods e pods reiniciados com novos endereços IP porque foram movidos para um nó diferente no cluster.
Escalonar o número de endpoints. Com o novo plano de controle global, os endpoints da malha são enviados diretamente de cada cluster para o plano de controle de todos os clusters na malha. Essa é uma abordagem mais simples, rápida e escalonável do que a usada pelo plano de controle gerenciado anterior. Em modelos de planos de controle gerenciados mais antigos (planos de controle dedicados), cada Istiod precisa se comunicar com todos os outros clusters na malha para determinar os endpoints disponíveis em todos os outros clusters. Com o plano de controle global, os endpoints são propagados diretamente para ele. Isso resulta em melhor confiabilidade e desempenho em malhas com um grande número de endpoints e permite que as malhas sejam escalonadas para um número maior de endpoints.

Como o novo plano de controle afeta você?

O impacto do novo plano de controle depende das APIs e do plano de controle que você está usando.

Se você for um usuário do Traffic Director, seu plano de controle vai permanecer o mesmo. Você não precisa ler o restante deste guia. A documentação para sua implementação do Cloud Service Mesh está em Configurar com as APIs do Google Cloud.
Se você for um usuário do Anthos Service Mesh, as próximas etapas para o plano de controle na implantação atual dependem se você usa o plano de controle gerenciado ou o plano de controle no cluster.
- Se você usar o plano de controle gerenciado, com algumas exceções, suas frotas atuais serão migradas para o novo plano de controle, referido no Cloud Service Mesh como plano de controle gerenciado (implementação do Traffic Director ou TD). Leia a seção a seguir, Migração do plano de controle para malhas e frotas atuais. Se você estiver usando um recurso que não tem suporte da implementação do plano de controle do Traffic Director, permanecerá temporariamente no plano de controle anterior. Continue lendo este guia.
- Se você usar o plano de controle no cluster, ele vai permanecer o mesmo. Você não precisa ler o restante deste guia.
- Se você não tiver uma organização do Google Cloud e usar o plano de controle gerenciado em um projeto sem organização, vai receber o plano de controle de TD.
Se você é cliente do Anthos Service Mesh e está criando novas frotas, vai receber a implementação do plano de controle do Traffic Director. Continue a ler este guia.
- Você vai receber uma notificação sobre a data em que as novas frotas receberem o plano de controle do TD.

Migração do plano de controle para malhas e frotas atuais

A partir de 22 de julho de 2024, o Google vai atualizar gradualmente os clusters atuais para usar o plano de controle gerenciado com a implementação de TD. Você vai receber uma notificação antes de atualizar as malhas.

Confira os recursos dos planos de controle do Istiod e do Traffic Director na página que descreve os recursos compatíveis com as APIs do Istio (plano de controle gerenciado).

Você vai receber uma notificação de que um cluster está programado para ser atualizado pelo menos duas semanas antes da atualização. As notificações estão disponíveis nas condições de estado do recurso no nível do cluster.

Use o comando da Google Cloud CLI a seguir para verificar a notificação:

gcloud container hub mesh describe --project=[PROJECT_ID]

Você verá resultados parecidos com o seguinte:

membershipStates:
  projects/656460026795/locations/us-central1/memberships/cluster:
    servicemesh:
      conditions:
      - code: MODERNIZATION_SCHEDULED
        details: This cluster has been scheduled for modernization on or after (date ~ at least 2 weeks).
        documentationLink: 
        severity: INFO

Todos os clusters de plano de controle gerenciados legados que foram integrados usando a API meshconfig.googleapis.com são registrados automaticamente na frota no projeto do cluster com a API gkehub.googleapis.com Membership. Se você tiver alguma automação que descadastre um cluster, remova-a antes da migração, ou ela terá problemas. Para que o produto gerenciado funcione, ele precisa estar registrado em uma frota com o recurso de malha ativado.

Entre em contato com o suporte se precisar personalizar a migração ou tiver dúvidas sobre o uso de recursos sem suporte.

Durante a migração, de forma segura e controlada, as seguintes mudanças acontecem:

Para ativar a verificação de integridade, o daemonset snk é criado no namespace kube-system do cluster e uma regra de firewall por cluster é criada.
Para ativar a ingestão de grupos de endpoints de rede (NEGs), a anotação cloud.google.com/neg é adicionada a todos os serviços do Kubernetes.
Novos recursos do Google Cloud, como Mesh, Routes, serviços de back-end e verificações de saúde, são criados no cluster.
Os pods gerenciados por implantações do Kubernetes são reiniciados para se reconectar ao plano de controle do Traffic Director.

Alguns dos novos recursos são limitados por cota. É possível ver as cotas e solicitar mais, se necessário.

Verificar a compatibilidade do plano de controle

Analise as diferenças nos recursos compatíveis entre as implementações do plano de controle gerenciado para determinar se o uso atual do Cloud Service Mesh vai exigir mudanças.

Plano de controle para novas malhas

A partir de 1º de julho de 2024, a maioria dos usuários da implementação do plano de controle istiod gerenciado vai começar a receber o plano de controle gerenciado atualizado com a implementação disponível globalmente do Google, o plano de controle do Traffic Director (TD), em novas frotas.

Os usuários cujo uso atual do Cloud Service Mesh gerenciado com a implementação do plano de controle istiod não é compatível com a implementação do Traffic Director sem alterações vão continuar recebendo a implementação istiod até 8 de setembro de 2024. Se isso se aplica à sua organização, você recebeu um aviso de serviço.

Se você integrar uma nova frota ao Cloud Service Mesh gerenciado e ela não estiver em uma organização do Google Cloud ou estiver em uma nova organização do Google Cloud, você vai receber o novo plano de controle gerenciado com a implementação de TD a partir da data de lançamento do Cloud Service Mesh.

A seguir

Se você for um cliente do Anthos Service Mesh, sua documentação estará na tabela de conteúdos à esquerda em Configurar a malha de serviço com as APIs do Istio.
Se você for um cliente do Traffic Director, a documentação está em Configurar a malha de serviços com as APIs do Google Cloud.