Plano de controle gerenciado para clientes contínuos

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

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

Visão geral do plano de controle

Nas malhas de serviço, o plano de controle fornece gerenciamento de tráfego, gerenciamento quando o proxy Envoy estiver 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 proxies Envoy são usados como o 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 Anthos Service Mesh para O Cloud Service Mesh é a migração para um plano de controle global e 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 o xDS configuração enviada para os arquivos secundários é compatível sem diferenças comportamentais, as diferenças do plano de controle resultam em algumas características visíveis para você, o usuário final.

  • Tempo de resposta da mudança de configuração. Novas implantações de serviço ou alterações políticas de serviço, demoram um pouco mais com o novo plano de controle.
    • O pipeline de configuração executa uma confirmação de configuração em duas etapas para fins de confiabilidade. A primeira passagem realiza validações para verificar se a configuração está bem formada. A fase subsequente propaga a configuração globalmente para as implantações de serviço. Para permitir o uso dos serviços do Google Cloud, como carga global entre zonas ou entre regiões de rede, verificação de integridade centralizada, escalonamento automático orientado por tráfego e com limitação de taxa gerenciada, a configuração é propagada para esses sistemas e validados de maneira independente quanto à correção. A configuração também é armazenadas internamente de modo a garantir a confiabilidade do site do Google. de engenharia para executar operações de produtos de maneira confiável e eficiente durante qualquer emergência de produção.
    • Essas operações proporcionam melhor confiabilidade, mas resultam em uma configuração push que é mais lento do que a latência observada pelos usuários atuais do Anthos Malha de serviço.
    • 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 escalonamento de eventos e outras alterações nos endpoints. São ser tratados pelo menos tão 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. Esta é uma forma mais simples, rápida e mais escalonável do que o plano de controle gerenciado usado. Em modelo mais antigo de plano de controle gerenciado (plano de controle dedicado), cada Istiod precisa se comunicam 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 o plano de controle global. Isso resulta para melhorar a confiabilidade e o desempenho de 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ê?

A forma como o novo plano de controle afeta você depende das APIs e do plano de controle que que você está usando.

  • Se você for um usuário do Traffic Director, o plano de controle vai continuar o mesmo. Você não precisa ler o restante deste guia. A documentação da sua A implementação do Cloud Service Mesh está em Configurar com 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 continuará sendo 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, você receberá plano de controle do 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. Você deve continuar lendo 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 para usar o plano de controle gerenciado com a implementação do 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 no nível do cluster e as condições de estado do recurso.

Use o seguinte comando da Google Cloud CLI 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 descadastra um cluster, remova-a antes da migração, ou ela terá problemas. Para o produto gerenciado para funcionar, ele precisa ser 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 maneira segura e controlada, as seguintes mudanças ocorrem lugar:

  • 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.
  • Ativar o grupo de endpoints de rede (NEG) ingestão, a anotação cloud.google.com/neg é adicionada a todos os componentes serviços.
  • Os novos recursos do Google Cloud, como Mesh, Routes, back-end serviços e saúde e verificações são criadas 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 o plano de controle gerenciado implementações 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.

Usuários que já usam o Cloud Service Mesh gerenciado com istiod A implementação do plano de controle não é compatível com o Traffic Director A implementação sem mudanças vai continuar recebendo a implementação de 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.