Como configurar a entrada de vários clusters

Nesta página, mostramos como configurar a entrada de vários clusters para rotear o tráfego em vários clusters do Google Kubernetes Engine (GKE) em diferentes regiões.

A entrada de vários clusters é um controlador de entrada de vários clusters hospedado na nuvem para clusters do GKE compatíveis com a implantação de recursos de balanceamento de carga compartilhados entre clusters e regiões.

Para saber mais sobre a entrada de vários clusters, consulte entrada de vários clusters. Você também pode aprender sobre Como implantar o Ingress em clusters.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

  • Verifique se você ativou a API do Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Verifique se o SDK do Cloud está instalado.
  • Defina as configurações padrão da ferramenta de linha de comando gcloud do seu 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 ferramenta gcloud a usar sua 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 ferramenta gcloud como o seguinte: One of [--zone, --region] must be supplied: Please specify location.

Verifique se você atende aos requisitos para usar a Entrada de vários clusters.

Exercício de implantação

Neste exercício, você implanta componentes e prepara a infraestrutura necessária para usar a entrada de vários clusters. Essas etapas são necessárias para usar a entrada de vários clusters no seu ambiente. Essas etapas exigem privilégios elevados e devem ser executadas por um administrador do GKE.

Um resumo das etapas deste exercício inclui:

  1. Ative as APIs necessárias.
  2. Implante clusters do GKE para hospedar cargas de trabalho.
  3. Agrupe os clusters em uma frota.
  4. Defina as configurações administrativas da entrada de vários clusters.

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.

Ative as APIs

As APIs ativadas para entrada de vários clusters dependem dos preços da entrada de vários clusters usados.

Se a entrada de vários clusters é o único recurso do Anthos que você está usando, pode ser mais econômico usar o preço independente. A maneira como o projeto é faturado depende se a API Anthos (anthos.googleapis.com) está ativada ou desativada.

  • Se a API Anthos estiver ativada, 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.

Se o projeto estiver usando outros componentes ou recursos do Anthos no Google Cloud, use o licenciamento do Anthos.

É possível alterar o modelo de faturamento de entrada de vários clusters de autônomo para o Anthos ou vice-versa sem afetar os recursos ou o tráfego de Multi Cluster Ingress. Para alterar o modelo de faturamento, ative ou desative a API Anthos, como nas instruções a seguir.

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

Nesta seção, você criará dois clusters do GKE chamados gke-us e gke-eu nas zonas europe-west1 e us-central1.

Recomendamos que você crie seus clusters com a Identidade da carga de trabalho ativada, porque ela permite que as cargas de trabalho no cluster sejam autenticadas sem que você precise fazer o download, rotacionar ou gerenciar manualmente o serviço do Google Cloud chaves da conta. Se você criar os clusters sem a Identidade da carga de trabalho ativada, precisará registrar os clusters na frota manualmente usando chaves de conta de serviço.

Workload Identity

  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
    

Manual

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

    gcloud container clusters create gke-us \
        --zone=us-central1-b \
        --enable-ip-alias \
        --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 \
        --release-channel=stable \
        --project=PROJECT_ID
    

Configurar credenciais do cluster

Nesta seção, você configura as credenciais do cluster com nomes memoráveis. Isso facilita a alternância entre os clusters ao implantar recursos em vários clusters.

  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

É preciso registrar seus clusters em uma frota usando o Connect. É possível registrar clusters manualmente usando uma conta de serviço do Google Cloud ou por meio da identidade da carga de trabalho.

Workload Identity

  1. Se você tiver a identidade de carga de trabalho ativada para seus clusters, execute os seguintes comandos para registrar os clusters:

    gcloud container hub memberships register gke-us \
        --gke-cluster us-central1-b/gke-us \
        --enable-workload-identity \
        --project=PROJECT_ID
    
    gcloud container hub memberships register gke-eu \
        --gke-cluster europe-west1-b/gke-eu \
        --enable-workload-identity \
        --project=PROJECT_ID
    
  2. Confirme se os clusters foram registrados no Connect:

    gcloud container hub memberships list --project=PROJECT_ID
    

    A saída será assim:

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

Manual

Se você não tiver a identidade de carga de trabalho ativada para seus clusters, execute as seguintes etapas para registrar os clusters:

  1. Verifique se você concluiu os Pré-requisitos para registrar um cluster.

  2. Crie uma conta de serviço e faça o download do arquivo JSON da chave privada da conta de serviço.

  3. Registre seus clusters na frota usando o arquivo JSON da chave privada que você baixou:

    gcloud container hub memberships register gke-us \
         --gke-cluster us-central1-b/gke-us \
         --service-account-key-file=SERVICE_ACCOUNT_KEY_PATH \
         --project=PROJECT_ID
    
    gcloud container hub memberships register gke-eu \
        --gke-cluster europe-west1-b/gke-eu \
        --service-account-key-file=SERVICE_ACCOUNT_KEY_PATH \
        --project=PROJECT_ID
    

    Substitua:

    • SERVICE_ACCOUNT_KEY_PATH: o caminho do arquivo local para o arquivo JSON da chave privada da conta de serviço que você salvou nos pré-requisitos de registro. Esta chave de conta de serviço é armazenada como um secret chamado creds-gcp no namespace gke-connect.
  4. Confirme se os clusters foram registrados no Connect:

    gcloud container hub memberships list --project=PROJECT_ID
    

    A saída será assim:

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

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. Ao contrário do Ingress do GKE, o controlador do Multi Cluster Ingress não fica em um único cluster, mas é um serviço gerenciado pelo Google que monitora recursos no cluster de configuração. Esse cluster do GKE é usado como um servidor de API de vários clusters para armazenar recursos como MultiClusterIngress e MultiClusterService. Qualquer cluster membro pode se tornar um cluster de configuração, mas só pode haver um cluster de configuração por vez.

Para mais informações sobre clusters de configuração, consulte Projeto do cluster de configuração.

Se o cluster de configuração estiver inativo ou inacessível, os objetos MultiClusterIngress e MultiClusterService não poderão ser atualizados nos clusters de membros. Os balanceadores de carga e o tráfego podem continuar funcionando independentemente do cluster de configuração em caso de interrupção.

A ativação da entrada de vários clusters e a seleção do cluster de configuração ocorrem na mesma etapa. O cluster do GKE escolhido como o cluster de configuração já precisa estar registrado em uma frota.

  1. Identifique o URI do cluster que você quer especificar como o cluster de configuração:

    gcloud container hub memberships list
    

    A saída será assim:

    NAME                                  EXTERNAL_ID
    gke-us                                0375c958-38af-11ea-abe9-42010a800191
    gke-eu                                d3278b78-38ad-11ea-a846-42010a840114
    
  2. Ative a Entrada de vários clusters e selecione gke-us como o cluster de configuração:

    gcloud beta container hub ingress enable \
      --config-membership=gke-us
    

    Esse processo pode levar alguns minutos durante a execução do controlador. Se for bem-sucedido, a saída será semelhante a esta:

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

    Se falhar, o comando atingirá o tempo limite conforme abaixo:

    Waiting for controller to start...failed.
    ERROR: (gcloud.alpha.container.hub.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. Ele precisa indicar exatamente o que deu errado:

    gcloud beta container hub ingress describe
    

    A saída será assim:

    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 essas mensagens de erro, consulte Solução de problemas e operações.

Implantação de VPC compartilhada

A entrada de vários clusters pode ser implantada para clusters em uma rede VPC compartilhada, mas todos os clusters participantes 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 Cloud Load Balancing para cargas de trabalho de contêineres.

Em uma rede VPC compartilhada, o Ingress for Anthos não é capaz de gerenciar essas regras de firewall porque o firewall é gerenciado pelo projeto host, a que os administradores do projeto de serviço não têm acesso. O modelo de segurança centralizado das redes VPC compartilhadas centraliza intencionalmente o controle de rede. Em redes VPC compartilhadas, um administrador de projeto de host precisa criar manualmente as regras de firewall necessárias para o tráfego do Cloud Load Balancing em nome da entrada de vários clusters.

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 que o Cloud Load Balancing usa para enviar tráfego para back-ends no Google Cloud. Essa regra precisa existir durante o ciclo de vida operacional da entrada de vários clusters e só poderá ser removida se a entrada ou o Cloud Load Balancing para o balanceamento de carga do GKE não forem mais usados.

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.
  • 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 ferramenta de linha de comando gcloud 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 ferramenta gcloud versão 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