Como configurar a entrada de vários clusters

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 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, veja se você realizou as seguintes tarefas:

  • Veja se você ativou a API do Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Confirme se você instalou a Google Cloud CLI.
  • Defina as configurações padrão da Google Cloud CLI para o projeto usando um dos seguintes métodos:
    • Use gcloud init se quiser orientações para definir os padrões do projeto.
    • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

    gcloud init

    1. Execute gcloud init e siga as instruções:

      gcloud init

      Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

      gcloud init --console-only
    2. Siga as instruções para autorizar a CLI gcloud a usar a conta do Google Cloud.
    3. Crie uma nova configuração ou selecione uma atual.
    4. Escolha um projeto do Google Cloud.
    5. Escolha uma zona padrão do Compute Engine.
    6. Escolha uma região padrão do Compute Engine.
    .

    gcloud config

    1. Defina o ID do projeto padrão:
      gcloud config set project PROJECT_ID
    2. Defina a região padrão do Compute Engine (por exemplo, us-central1):
      gcloud config set compute/region COMPUTE_REGION
    3. Defina a zona padrão do Compute Engine (por exemplo, us-central1-c):
      gcloud config set compute/zone COMPUTE_ZONE
    4. Atualize gcloud para a versão mais recente:
      gcloud components update
    .

    Ao definir locais padrão, é possível evitar erros na gcloud CLI, 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.
  • 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 Identidade da carga de trabalho ativada.

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

  • Compatível apenas com um balanceador de carga HTTP(S) externo.
  • Só é possível implantar uma instância de entrada de vários clusters por projeto. Para implantar recursos MultiClusterIngress em subconjuntos específicos de clusters em um projeto, controle o escopo de clusters usando a seleção de cluster.
  • 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:

Topologia de cluster mostrando as relações entre regiões, frota e projeto.

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 Anthos que você está usando, recomendamos o uso de preços independentes. Se o projeto estiver usando outros componentes ou recursos do Anthos no Google Cloud, ative toda a plataforma do Anthos. Isso permite usar todos os recursos do Anthos 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 Anthos estiver ativada (anthos.googleapis.com), o projeto será faturado de acordo com o número de vCPUs de cluster e os preços do Anthos.
  • Se a API Anthos 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 do Ingress de vários clusters de independente para Anthos ou do Anthos para independente a qualquer momento sem afetar os recursos ou o tráfego de Ingress de vários clusters.

Preço do Anthos

Para ativar os preços do Anthos, siga estas etapas:

  1. Ative as APIs Anthos, entrada de vários clusters, Connect e GKE no seu projeto:

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

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

Preço da autorização binária

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

  1. Confirme se a API Anthos 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 Anthos será desativada no projeto e todos os recursos de entrada de vários clusters serão faturados usando preços independentes.

  2. Ative as APIs entrada de vários clusters, Connect e GKE no projeto:

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

Implantar clusters

Crie dois clusters do GKE chamados gke-us e gke-eu nas zonas europe-west1 e us-central1, com a Identidade da carga de trabalho ativada.

  1. Crie o cluster gke-us na zona us-central1-b:

    gcloud container clusters create gke-us \
        --zone=us-central1-b \
        --enable-ip-alias \
        --workload-pool=PROJECT_ID.svc.id.goog \
        --release-channel=stable \
        --project=PROJECT_ID
    
  2. Crie o cluster gke-eu na zona europe-west1-b:

    gcloud container clusters create gke-eu \
        --zone=europe-west1-b \
        --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 \
        --zone=us-central1-b \
        --project=PROJECT_ID
    
    gcloud container clusters get-credentials gke-eu \
        --zone=europe-west1-b \
        --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-b_gke-us gke-us
    kubectl config rename-context gke_PROJECT_ID_europe-west1-b_gke-eu gke-eu
    

Registrar clusters em uma frota

Registre seus clusters na frota do projeto da seguinte maneira.

  1. Registre seus clusters:

    gcloud container fleet memberships register gke-us \
        --gke-cluster us-central1-b/gke-us \
        --enable-workload-identity \
        --project=PROJECT_ID
    
    gcloud container fleet memberships register gke-eu \
        --gke-cluster europe-west1-b/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 que você registrar seus clusters, o GKE implantará os seguintes componentes no cluster: gke-mcs-importer, mcs-core-dns e mcs-core-dns-autoscaler.

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.

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

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

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.

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

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 da gcloud CLI nas versões 346.0.0 e 347.0.0 com a Entrada de 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