Instalação de vários projetos no GKE

Neste guia, explicamos como instalar o Anthos Service Mesh para uma malha contendo vários clusters do Google Kubernetes Engine (GKE) que estão em diferentes projetos do Google Cloud.

Use o guia para estes casos de uso:

  • Novas instalações do Anthos Service Mesh 1.9.8.

  • Como fazer upgrade de 1.8 or a 1.9 patch release para o Anthos Service Mesh 1.9.8. Upgrades de versões anteriores não são compatíveis.

  • Como migrar do Istio 1.8 or 1.9 de código aberto para o Anthos Service Mesh 1.9.8. Se você tiver uma versão anterior do Istio, será necessário fazer o upgrade antes de migrar para o Anthos Service Mesh. Se você precisar fazer upgrade, acesse a página Fazer upgrade do Istio na versão aplicável do Istio. O upgrade em mais de uma versão secundária (por exemplo, 1.6.x a 1.8.x) em uma etapa não está oficialmente testado nem é recomendado. Não se esqueça de reler Como se preparar para migrar do Istio para planejar sua migração.

Nem todos os recursos estão disponíveis para uma malha de serviço com clusters em projetos diferentes. Especificamente, os painéis do Anthos Service Mesh no Console do Google Cloud não estão disponíveis no momento. No entanto, ainda é possível ver registros no Cloud Logging e métricas no Cloud Monitoring de cada projeto.

Antes de começar

Veja o que é necessário para seguir este guia:

Se você estiver migrando do Istio, leia o artigo Como se preparar para migrar do Istio.

Diferenças entre o Anthos e o Anthos Service Mesh

O Anthos Service Mesh está disponível no GKE Enterprise ou como um serviço independente. As APIs do Google são usadas para determinar como você é cobrado. Para usar o Anthos Service Mesh como um serviço independente, não ative a API Enterprise GKE no seu projeto. Para mais informações sobre preços do Anthos Service Mesh, consulte Preços.

  • Os assinantes do GKE Enterprise precisam ativar a API GKE Enterprise.

    Ativar a API

  • Mesmo que você não seja um assinante do GKE Enterprise, ainda é possível instalar o Anthos Service Mesh, mas alguns elementos e recursos da IU no console do Google Cloud estão disponíveis apenas para assinantes do GKE Enterprise. Para informações sobre o que está disponível para assinantes e não assinantes, consulte Diferenças na interface do GKE Enterprise e Anthos Service Mesh.

  • Se você ativou a API GKE Enterprise, mas quer usar o Anthos Service Mesh como um serviço independente, desative a API GKE Enterprise.

Requisitos

Como escolher uma autoridade de certificação

Para novas instalações e migrações, é possível usar a autoridade de certificação do Anthos Service Mesh (Mesh CA) ou a ICA do Istio (anteriormente conhecida como Citadel) como autoridade de certificação (CA) para emitir certificados TLS mútuos (mTLS, na sigla em inglês).

Recomendamos que você use a Mesh CA pelos seguintes motivos:

  • A Mesh CA é um serviço altamente confiável e escalonável, otimizado para cargas de trabalho escalonadas dinamicamente no Google Cloud.
  • Com ela, o Google gerencia a segurança e a disponibilidade do back-end da CA.
  • Esta autoridade de certificação possibilita confiar em uma única raiz de confiança entre os clusters.

No entanto, há casos em que convém considerar o uso da CA do Istio. Veja abaixo alguns exemplos:

  • Se você tiver uma CA personalizada.
  • Se você estiver migrando do Istio.

    Caso você escolha o Ca do Istio, o tempo de inatividade será breve porque o tráfego mTLS não será interrompido durante a migração. Se você escolher o Mesh CA, será necessário agendar o tempo de inatividade para a migração, porque a raiz da confiança é alterada de CA do Istio para Mesh CA. Para concluir a migração para a raiz de confiança da Mesh CA, é necessário reiniciar todos os pods em todos os namespaces. Durante esse processo, os pods antigos não podem estabelecer conexões mTLS com os novos pods.

Os certificados do Mesh CA incluem os seguintes dados sobre os serviços do aplicativo:

  • O ID do projeto do Google Cloud
  • O namespace do GKE
  • O nome da conta de serviço do GKE

Como registrar o cluster

Embora não seja obrigatório no momento, recomendamos que você registre o cluster na frota (anteriormente conhecida como ambiente) do projeto. Uma frota permite organizar clusters para facilitar o gerenciamento de vários deles. Ao registrar os clusters em uma frota, é possível agrupar serviços e outras infraestruturas conforme necessário para aplicar políticas consistentes. Se você tiver clusters em projetos diferentes, será necessário registrar os clusters com o projeto host da frota e não com o projeto em que o cluster foi criado. Para saber detalhes sobre como registrar o cluster, consulte Como registrar clusters na frota.

O conceito de um projeto host de frota é importante ao configurar o cluster para ativar as opções exigidas pelo Anthos Service Mesh. A malha de serviço do cluster é identificada com um valor baseado em um número de projeto. Ao configurar clusters em diferentes projetos, você precisa usar o número do projeto host da frota.