Plano de controlo gerido para clientes contínuos

Este documento destina-se a si se for um cliente do Anthos Service Mesh que usa o plano de controlo gerido ou o plano de controlo no cluster. Este documento aborda a implementação do plano de controlo e a possível migração do plano de controlo.

Se for um cliente do Traffic Director existente ou um novo cliente, não precisa de ler este documento.

Vista geral do plano de controlo

Nas malhas de serviço, o plano de controlo fornece gestão de tráfego, gestão de proxy quando o proxy Envoy está em utilização e outras capacidades de rede.

O Anthos Service Mesh oferecia dois painéis de controlo: um painel de controlo gerido e um painel de controlo no cluster. Apenas os proxies Envoy são usados como o plano de dados.

Novo plano de controlo gerido

O novo plano de controlo gerido chama-se implementação do Traffic Director (TD). O que significa o novo plano de controlo para si?

Uma das alterações mais significativas do produto Anthos Service Mesh para o Cloud Service Mesh é a mudança para um plano de controlo global multiinquilino.

O plano de controlo gerido 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 controlo resultam em algumas caraterísticas visíveis para si, o utilizador final.

Tempo de resposta à alteração da configuração. As implementações de novos serviços ou as alterações às políticas de serviço demoram um pouco mais com o novo plano de controlo.
- O pipeline de configuração executa uma confirmação de configuração de duas passagens para fins de fiabilidade. A primeira passagem faz validações para verificar se a configuração tem um formato correto. A fase subsequente propaga a configuração globalmente para as implementações do seu serviço. Para ativar a utilização de Google Cloud serviços, como o equilíbrio de carga global entre zonas ou regiões, a verificação de estado centralizada, a escala automática baseada no tráfego e a limitação de taxa gerida, a configuração é propagada a estes sistemas e validada de forma independente quanto à correção. A configuração também é armazenada internamente de uma forma que permite à engenharia de fiabilidade do site da Google realizar operações de produtos de forma fiável e eficiente durante emergências de produção.
- Estas operações oferecem uma melhor fiabilidade, mas resultam num envio de configuração mais lento do que a latência observada pelos utilizadores atuais do Anthos Service Mesh.
- A latência de qualquer novo pod para obter a configuração existente é ligeiramente melhor com o novo plano de controlo. O envio lento da configuração destina-se à propagação pela primeira vez de qualquer novo serviço criado ou de quaisquer novas políticas enviadas para o serviço. As latências de propagação dos pontos finais são funcionalmente semelhantes.
Velocidade dos eventos de escalabilidade e outras alterações aos pontos finais. Estas são processadas, pelo menos, tão rapidamente com o novo plano de controlo. Estes eventos incluem o início ou a paragem de novos pods devido à escala automática de pods horizontal e o reinício de pods com novos endereços IP porque foram movidos para um nó diferente no cluster.
Dimensionar o número de pontos finais. Com o novo plano de controlo global, os pontos finais da malha são enviados diretamente de cada cluster para o plano de controlo de todos os clusters na malha. Esta é uma abordagem mais simples, rápida e escalável do que a usada pelo plano de controlo gerido anterior. No modelo de plano de controlo gerido mais antigo (plano de controlo dedicado), cada Istiod tem de comunicar com todos os outros clusters na malha para determinar os pontos finais disponíveis em todos os outros clusters. Com o plano de controlo global, os pontos finais são propagados diretamente para o plano de controlo global. Isto resulta numa melhor fiabilidade e desempenho em malhas com um grande número de pontos finais e permite que as malhas sejam dimensionadas para um maior número de pontos finais.

Qual é o impacto do novo plano de controlo para si?

A forma como o novo plano de controlo lhe afeta depende das APIs e do plano de controlo que está a usar.

Se for um utilizador do Traffic Director, o seu plano de controlo permanece inalterado. Não tem de ler o resto deste guia. A documentação para a sua implementação do Cloud Service Mesh encontra-se em Configure com Google Cloud APIs.
Se for um utilizador do Anthos Service Mesh, os passos seguintes para o plano de controlo na sua implementação existente dependem de usar o plano de controlo gerido ou o plano de controlo no cluster.
- Se usar o plano de controlo gerido, com algumas exceções, as suas frotas existentes são migradas para o novo plano de controlo, referido no Cloud Service Mesh como plano de controlo gerido (implementação do Traffic Director ou TD). Leia a secção seguinte, Migração do plano de controlo para malhas e frotas existentes. Se estiver a usar uma funcionalidade não suportada pela implementação do plano de controlo do Traffic Director, permanece temporariamente no plano de controlo anterior. Deve continuar a ler este guia.
- Se usar o plano de controlo no cluster, o plano de controlo permanece o mesmo. Não precisa de ler o resto deste guia.
- Se não tiver uma Google Cloud organização e usar o plano de controlo gerido num projeto sem organização, recebe o plano de controlo de TD.
Se for cliente do Anthos Service Mesh e estiver a criar novas frotas, recebe a implementação do plano de controlo do Traffic Director. Deve continuar a ler este guia.
- Recebe uma notificação sobre a data em que as novas frotas recebem o plano de controlo de TD.

Migração do plano de controlo para malhas e frotas existentes

A partir de 22 de julho de 2024, a Google vai atualizar gradualmente os clusters existentes para usar o plano de controlo gerido com a implementação de TD. Vai receber uma notificação antes de atualizarmos as suas malhas.

Pode rever as capacidades dos planos de controlo do Istiod e do Traffic Director na página que descreve as funcionalidades suportadas através das APIs Istio (plano de controlo gerido).

Deve receber uma notificação a informar que um cluster vai ser atualizado, pelo menos, duas semanas antes da atualização. As notificações estão disponíveis nas condições de estado das funcionalidades ao nível do cluster.

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

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

Vê resultados semelhantes aos seguintes:

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 do plano de controlo geridos antigos que foram incorporados através da API meshconfig.googleapis.com são automaticamente registados na frota no projeto do cluster com a API gkehub.googleapis.com Membership. Se tiver alguma automatização que anule o registo de um cluster, tem de a remover antes da migração, caso contrário, a migração terá problemas. Para que o produto gerido funcione com êxito, tem de estar registado numa frota com a funcionalidade de rede de malha ativada.

Contacte o apoio técnico se precisar de personalizar a migração ou se tiver dúvidas sobre se está a usar funcionalidades não suportadas.

Durante a migração, as seguintes alterações ocorrem de forma segura e controlada:

Para ativar a verificação de funcionamento, o conjunto de daemon snk é criado no espaço de nomes kube-system do cluster e é criada uma regra de firewall por cluster.
Para ativar a carregamento de grupos de pontos finais da rede (NEGs), a anotação cloud.google.com/neg é adicionada a todos os serviços do Kubernetes.
São criados novos Google Cloud recursos, como Mesh, Routes, serviços de back-end e verificações de estado no cluster.
Os pods geridos por implementações do Kubernetes são reiniciados para estabelecer novamente ligação ao plano de controlo do Traffic Director.

Alguns dos novos recursos têm um limite de quota. Pode ver as quotas e pedir mais, se necessário.

Verifique a compatibilidade do plano de controlo

Reveja as diferenças nas funcionalidades suportadas entre as implementações do plano de controlo gerido para determinar se a sua utilização atual do Cloud Service Mesh vai exigir alterações.

Plano de controlo para novas malhas

A partir de 1 de julho de 2024, a maioria dos utilizadores existentes da implementação do plano de controlo gerido vai começar a receber o plano de controlo gerido atualizado com a implementação disponível globalmente da Google, o plano de controlo do Traffic Director (TD), em frotas novas.istiod

Os utilizadores cuja utilização existente da malha de serviços na nuvem gerida com a implementação do plano de controlo não for compatível com a implementação do Traffic Director sem alterações vão continuar a receber a implementação até 8 de setembro de 2024.istiodistiod Se isto se aplicar à sua organização, recebeu um anúncio de serviço.

Se integrar uma nova frota no Cloud Service Mesh gerido e esta frota não estiver numa Google Cloud organização ou estiver numa nova Google Cloud organização, recebe o novo plano de controlo gerido com a implementação de TD a partir da data de lançamento do Cloud Service Mesh.

O que se segue?

Se for um cliente do Anthos Service Mesh, a sua documentação encontra-se no índice do lado esquerdo em Configure a malha de serviços com APIs Istio.
Se for um cliente do Traffic Director, a sua documentação encontra-se em Configure a malha de serviços com Google Cloud APIs.