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 plano de controle.

Se você for 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 gerenciado e um plano de controle 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 Traffic Director (TD). implementação. 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 de duas etapas para para fins de confiabilidade. A primeira aprovação 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 de qualquer pod novo para buscar a configuração atual é agora será um pouco melhor com o novo plano de controle. A lentidão o push de configuração serve para a primeira propagação de qualquer novo serviço criadas ou novas políticas enviadas para o serviço. Propagação de endpoint latências 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 incluir novos pods iniciados ou interrompidos devido ao escalonamento automático horizontal de pods e pods reiniciando com novos endereços IP porque eles foram movidos para outro nó no cluster.
• Escalonar o número de endpoints. Com o novo plano de controle global, endpoints da malha são enviados diretamente de cada cluster para o de todos os clusters da malha. Esta é uma forma mais simples, rápida e mais escalonável do que o atual plano de controle gerenciado. 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. No plano de controle global, 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 do plano de controle na implantação atual dependem do uso da ferramenta de controle de controle ou no plano de controle no cluster.
  • Se você usa o plano de controle gerenciado, com algumas exceções, os frotas serão migradas para o novo plano de controle, mencionado no Cloud Service Mesh como plano de controle gerenciado (Traffic Director, ou TD). Leia a próxima seção, Plano de controle migração de malhas e frotas atuais. Se você está usando um recurso sem suporte do Traffic Director da implementação do plano de controle, você permanece temporariamente na plano de controle. 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ê for um cliente do Anthos Service Mesh e estiver criando novas frotas, você 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 novas frotas recebem 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 uso o plano de controle gerenciado com a implementação do TD. Você será notificado antes que atualizar suas malhas.

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

Você deve receber a notificação de que um cluster está programado para ser atualizado pelo menos dois 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 legados do plano de controle gerenciado que foram integrados usando o A API meshconfig.googleapis.com será registrada automaticamente na frota no projeto do cluster com a API Membership gkehub.googleapis.com. Se se houver uma automação que cancele o registro de um cluster, será preciso removê-lo antes ou a migração 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 durante a migração ou se tiver dúvidas sobre o uso de atributos de machine learning.

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 kube-system do cluster e uma por cluster em que uma regra de firewall é criados.
• 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 health 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 têm cotas limitadas. Você pode ver 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 1o de julho de 2024, a maioria dos usuários do controle istiod gerenciado a implementação do plano vai começar a receber o plano de controle gerenciado atualizado com a implementação do Google disponível globalmente: o Traffic Director (TD) plano de controle em frotas novas.

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 essa frota não for em uma organização do Google Cloud ou em uma nova. você vai receber o novo plano de controle gerenciado com a implementação do TD, a data de lançamento do Cloud Service Mesh.

A seguir

• Se você for um cliente contínuo do Anthos Service Mesh, sua documentação estará no sumário à esquerda, em Configurar a malha de serviço com as APIs do Istio
• Se você é um cliente contínuo do Traffic Director, sua documentação está em Configurar malha de serviço com as APIs do Google Cloud