Como configurar o Ingress de vários clusters

Autopilot Standard

---

Nesta página, mostramos como rotear o tráfego em vários clusters do Google Kubernetes Engine (GKE) em diferentes regiões usando a Entrada em vários clusters, com um exemplo usando dois clusters.

Para uma comparação detalhada entre Ingress de vários clusters (MCI), Gateway de vários clusters (MCG) e balanceador de carga com grupos de endpoints de rede independentes (LB e NEGs independentes), consulte Escolher sua API de balanceamento de carga de vários clusters para o GKE.

Para saber mais sobre a implantação da Entrada em vários clusters, consulte Como implantar a Entrada em clusters.

Essas etapas exigem permissões elevadas e devem ser executadas por um administrador do GKE.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
  Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Requisitos e limitações

A entrada de vários clusters tem os seguintes requisitos:

• Google Cloud CLI versão 290.0.0 e posterior.

Se você usa clusters no modo Standard, verifique se atende aos requisitos a seguir. Os clusters do Autopilot já atendem a esses requisitos.

• Os clusters precisam ter o complemento HttpLoadBalancing ativado. Esse complemento é ativado por padrão. Não o desative.
• Os clusters precisam ser nativos de VPC.
• Os clusters precisam ter a federação de identidade da carga de trabalho do GKE ativada.

Ingress de vários clusters tem as seguintes limitações:

• Compatível apenas com um balanceador de carga de aplicativo externo.
• Não crie balanceadores de carga do Compute Engine no mesmo projeto com o prefixo mci- que não são gerenciados pela Entrada de vários clusters. Caso contrário, eles serão excluídos. O Google Cloud usa o prefixo mci-[6 char hash] para gerenciar os recursos do Compute Engine que a Entrada de vários clusters implanta.
• A configuração de HTTPS requer um endereço IP estático pré-alocado. O HTTPS não é compatível com endereços IP temporários.

Visão geral

Neste exercício, você realizará as seguintes etapas:

1. Selecione o preço que você quer usar.
2. Implantar clusters.
3. Configurar credenciais do cluster
4. Registrar os clusters em uma frota.
5. Especificar um cluster de configuração. Esse cluster pode ser um plano de controle dedicado ou executar outras cargas de trabalho.

O diagrama a seguir mostra como será o ambiente depois que você concluir o exercício:

No diagrama, há dois clusters do GKE chamados gke-us e gke-eu nas zonas europe-west1 e us-central1. Os clusters são agrupados em uma frota para que o controlador da entrada de vários clusters possa reconhecê-los. Com ele, é possível agrupar e normalizar logicamente os clusters do GKE, facilitando a administração da infraestrutura e o uso de recursos como o de vários clusters. Saiba mais sobre os benefícios dos frotas e como criá-los na documentação de gerenciamento de frota.

Selecione os preços

Se o Ingress de vários clusters for o único recurso do GKE Enterprise que você está usando, recomendamos o uso de preços independentes. Se o projeto estiver usando outros componentes ou recursos do GKE Enterprise nos componentes ou recursos do Google Cloud, ative toda a plataforma GKE Enterprise. Isso permite que você use todos os recursos do GKE Enterprise para uma única cobrança por vCPU.

As APIs que você precisa ativar dependem dos preços de Entrada de vários clusters usados.

• Se a API GKE Enterprise (anthos.googleapis.com) estiver ativada, seu projeto será faturado de acordo com o número de vCPUs de cluster e os preços do GKE Enterprise.
• Se a API GKE Enterprise estiver desativada, o projeto será faturado de acordo com o número de pods da entrada de vários clusters de back-end no projeto.

É possível alterar o modelo de faturamento de Entrada em vários clusters de independente para GKE Enterprise ou de GKE Enterprise para autônomo a qualquer momento sem afetar os recursos ou o tráfego da Entrada em vários clusters.

Aviso: não desative a API GKE Enterprise se houver outros componentes ativos do GKE Enterprise em uso no projeto ou se os componentes ativos sofrerem uma interrupção.

Preço da autorização binária

Para ativar os preços independentes, siga estas etapas:

1. Confirme se a API GKE Enterprise está desativada no seu projeto:

   gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com
   

   Substitua PROJECT_ID pelo ID do projeto em que os clusters do GKE estiverem em execução.

   Se a saída for uma resposta vazia, a API GKE Enterprise será desativada no projeto e todos os recursos de entrada de vários clusters serão faturados usando preços independentes.

2. Ativar as APIs necessárias no projeto:

   gcloud services enable \
       multiclusteringress.googleapis.com \
       gkehub.googleapis.com \
       container.googleapis.com \
       multiclusterservicediscovery.googleapis.com \
       --project=PROJECT_ID
   

Preços do GKE Enterprise

Para ativar os preços do GKE Enterprise, ative as APIs necessárias no projeto:

gcloud services enable \
    anthos.googleapis.com \
    multiclusteringress.googleapis.com \
    gkehub.googleapis.com \
    container.googleapis.com \
    multiclusterservicediscovery.googleapis.com \
    --project=PROJECT_ID

Depois que anthos.googleapis.com for ativado no projeto, todos os clusters registrados no Connect serão faturados de acordo com os preços do GKE Enterprise.

Implantar clusters

Crie dois clusters do GKE chamados gke-us e gke-eu nas zonas europe-west1 e us-central1.

Piloto automático

1. Crie o cluster gke-us na região us-central1:

   gcloud container clusters create-auto gke-us \
       --region=us-central1 \
       --release-channel=stable \
       --project=PROJECT_ID
   

   Substitua o PROJECT_ID pelo ID do projeto do Google Cloud.

2. Crie o cluster gke-eu na região europe-west1:

   gcloud container clusters create-auto gke-eu \
       --region=europe-west1 \
       --release-channel=stable \
       --project=PROJECT_ID
   

Padrão

Crie os dois clusters com a federação de identidade da carga de trabalho do GKE ativada.

1. Crie o cluster gke-us na região us-central1:

   gcloud container clusters create gke-us \
       --region=us-central1 \
       --enable-ip-alias \
       --workload-pool=PROJECT_ID.svc.id.goog \
       --release-channel=stable \
       --project=PROJECT_ID
   

   Substitua o PROJECT_ID pelo ID do projeto do Google Cloud.

2. Crie o cluster gke-eu na região europe-west1:

   gcloud container clusters create gke-eu \
       --region=europe-west1 \
       --enable-ip-alias \
       --workload-pool=PROJECT_ID.svc.id.goog \
       --release-channel=stable \
       --project=PROJECT_ID
   

Configurar credenciais do cluster

Configure credenciais para os clusters e renomeie os contextos do cluster para facilitar a alternância entre clusters ao implantar recursos.

1. Recupere as credenciais dos clusters:

   gcloud container clusters get-credentials gke-us \
       --region=us-central1 \
       --project=PROJECT_ID
   
   gcloud container clusters get-credentials gke-eu \
       --region=europe-west1 \
       --project=PROJECT_ID
   

   As credenciais são armazenadas localmente para que você possa usar o cliente kubectl para acessar os servidores da API do cluster. Por padrão, um nome gerado automaticamente é criado para as credenciais.

2. Renomeie os contextos do cluster:

   kubectl config rename-context gke_PROJECT_ID_us-central1_gke-us gke-us
   kubectl config rename-context gke_PROJECT_ID_europe-west1_gke-eu gke-eu
   

Registrar clusters em uma frota

Registre seus clusters na frota do projeto da seguinte maneira.

Observação :se você escolheu ativar toda a plataforma do GKE Enterprise, também pode registrar os clusters nas páginas do GKE Enterprise no console do Google Cloud. Saiba mais em Registrar um cluster do GKE na sua frota.

1. Registre seus clusters:

   gcloud container fleet memberships register gke-us \
       --gke-cluster us-central1/gke-us \
       --enable-workload-identity \
       --project=PROJECT_ID
   
   gcloud container fleet memberships register gke-eu \
       --gke-cluster europe-west1/gke-eu \
       --enable-workload-identity \
       --project=PROJECT_ID
   

2. Confirme se os clusters foram registrados na frota:

   gcloud container fleet memberships list --project=PROJECT_ID
   

   O resultado será assim:

   NAME                                  EXTERNAL_ID
   gke-us                                0375c958-38af-11ea-abe9-42010a800191
   gke-eu                                d3278b78-38ad-11ea-a846-42010a840114
   

Depois de registrar seus clusters, o GKE implanta o pod gke-mcs-importer no cluster.

Saiba mais sobre como registrar clusters em Registrar um cluster do GKE na frota.

Especificar um cluster de configuração

O cluster de configuração é um cluster do GKE que você escolhe como o ponto central de controle do Ingress entre os clusters de membros. Esse cluster já precisa estar registrado na frota. Para mais informações, consulte Design do cluster de configuração.

Observação: mesmo que você tenha clusters zonais do GKE, o controlador do Ingress de vários clusters só está disponível em uma região. Para ativar o Ingress de vários clusters, é necessário especificar a região no lugar da zona ao usar o parâmetro --location.

Ative a Entrada de vários clusters e selecione gke-us como o cluster de configuração:

gcloud container fleet ingress enable \
    --config-membership=gke-us \
    --location=us-central1 \
    --project=PROJECT_ID

O registro do cluster de configuração leva até 15 minutos. A saída será assim:

Waiting for Feature to be created...done.
Waiting for controller to start...done.

A saída malsucedida é semelhante a esta:

Waiting for controller to start...failed.
ERROR: (gcloud.container.fleet.ingress.enable) Controller did not start in 2 minutes. Please use the `describe` command to check Feature state for debugging information.

Se ocorreu uma falha na etapa anterior, verifique o estado do recurso:

gcloud container fleet ingress describe \
    --project=PROJECT_ID

A saída bem-sucedida é semelhante a esta:

createTime: '2021-02-04T14:10:25.102919191Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
 state:
   code: ERROR
   description: '...is not a VPC-native GKE Cluster.'
   updateTime: '2021-08-10T13:58:50.298191306Z'
 projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
 state:
   code: OK
   updateTime: '2021-08-10T13:58:08.499505813Z'

Para saber mais sobre como solucionar problemas de erros com a Entrada de vários clusters, consulte Solução de problemas e operações.

Impacto nos clusters ativos

É possível ativar a Entrada de vários clusters com segurança usando gcloud container fleet ingress enable em um cluster ativo, porque isso não resulta em inatividade nem afeta o tráfego no cluster.

VPC compartilhada

É possível implantar um recurso MultiClusterIngress para clusters em uma rede VPC compartilhada, mas todos os clusters do GKE de back-end precisam estar no mesmo projeto. Não há suporte para clusters do GKE em projetos diferentes que usam o mesmo VIP do Cloud Load Balancing.

Em redes VPC não compartilhadas, o controlador da entrada de vários clusters gerencia regras de firewall para permitir que as verificações de integridade passem do balanceador de carga para cargas de trabalho de contêineres.

Em uma rede VPC compartilhada, um administrador de projeto host precisa criar manualmente as regras de firewall para o tráfego do balanceador de carga em nome do controlador de entrada Multi Cluster.

O comando a seguir mostra a regra de firewall que você precisa criar se os clusters estiverem em uma rede VPC compartilhada. Os intervalos de origem são aqueles usados pelo balanceador de carga para enviar tráfego aos back-ends. Essa regra precisa existir para a vida útil operacional de um recurso MultiClusterIngress.

Se os clusters estiverem em uma rede VPC compartilhada, crie a regra de firewall:

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --project=HOST_PROJECT \
    --network=SHARED_VPC \
    --direction=INGRESS \
    --allow=tcp:0-65535 \
    --source-ranges=130.211.0.0/22,35.191.0.0/16

Substitua:

• FIREWALL_RULE_NAME: o nome da nova regra de firewall escolhida.
• HOST_PROJECT: o ID do projeto host da VPC compartilhada.
• SHARED_VPC: o nome da rede VPC compartilhada.

Problemas conhecidos

Nesta seção, descrevemos os problemas conhecidos do Ingress de vários clusters

InvalidValueError para o campo config_membership

Um problema conhecido impede que a Google Cloud CLI interaja com a Entrada de vários clusters. Esse problema foi introduzido na versão 346.0.0 e corrigido na versão 348.0.0. Não recomendamos o uso das versões 346.0.0 e 347.0.0 da CLI gcloud com a Entrada em vários clusters.

Valor inválido para o campo "recurso"

O Google Cloud Armor não pode se comunicar com os clusters de configuração da entrada de vários clusters executados nas seguintes versões do GKE:

• 1.18.19-gke.1400 e superior
• 1.19.10-gke.700 e superior
• 1.20.6-gke.700 e superior

Quando você configura uma política de segurança do Google Cloud Armor, a seguinte mensagem é exibida:

Invalid value for field 'resource': '{"securityPolicy": "global/securityPolicies/"}': The given policy does not exist

Para evitar esse problema, faça upgrade do cluster de configuração para a versão 1.21 ou posterior ou use o seguinte comando para atualizar o BackendConfig CustomResourceDefinition:

kubectl patch crd backendconfigs.cloud.google.com --type='json' -p='[{"op": "replace", "path": "/spec/versions/1/schema/openAPIV3Schema/properties/spec/properties/securityPolicy", "value":{"properties": {"name": {"type": "string"}}, "required": ["name" ],"type": "object"}}]'

A seguir

• Como implantar o Ingress em vários clusters.