Migre para redes de vários clusters com o Autopilot do Google Kubernetes Engine (GKE) e clusters padrão

Last reviewed 2022-02-17 UTC

A rede de vários clusters é uma ferramenta valiosa que permite casos de uso como alta disponibilidade regional, proximidade global com usuários para menor latência e isolamento organizacional entre equipes. O Google Kubernetes Engine (GKE) oferece recursos integrados para redes de vários clusters que podem ser ativados e usados em escala em uma frota de clusters do GKE. Esse recurso também permite combinar ou migrar a infraestrutura implantada entre, o GKE Standard e o Autopilot para atender às necessidades arquitetônicas de cada aplicativo.

Neste documento, demonstramos esses recursos por meio de várias topologias de implantação. Você vai aprender a migrar um aplicativo implantado em um único cluster do GKE para uma implantação de vários clusters nos clusters do GKE Standard e do Autopilot. Use os serviços de vários clusters do GKE para tráfegos de leste a oeste e gateways de vários clusters para ativar redes norte-sul de vários clusters.

O documento é destinado a arquitetos de nuvem e equipes de operações que usam ou planejam usar o GKE para implantar serviços em vários clusters do Kubernetes. Para usar este documento, é necessário ter familiaridade com o Kubernetes.

GKE Standard e GKE Autopilot

O GKE fornece uma implantação totalmente gerenciada do Kubernetes com um conjunto completo de recursos, incluindo um plano de controle de alta disponibilidade. Os clusters do GKE podem ser iniciados rapidamente e escalonados para até 15.000 nós. Com os clusters do Autopilot do GKE, o Google gerencia a infraestrutura, incluindo o plano de controle e os nós. Se você quiser configurar e gerenciar os nós, o GKE fornece o Modo padrão.

Para mais informações sobre as diferenças entre os modos, consulte Escolher um modo de operação de cluster.

Serviços de vários clusters e gateways de vários clusters

O Kubernetes pode ser executado usando um único plano de controle em diferentes zonas de nuvem para fornecer resiliência e maior disponibilidade aos serviços. O GKE vai um passo à frente e fornece aos serviços de vários clusters (MCS, na sigla em inglês) do GKE um mecanismo de descoberta e invocação de serviços entre clusters. Os serviços que usam esse recurso são detectáveis e acessíveis em clusters com um IP virtual, que corresponde ao comportamento de um serviço ClusterIP acessível em um cluster. Essa abordagem permite os seguintes benefícios:

  • A carga dos serviços pode ser balanceada em vários clusters na mesma região ou em diferentes regiões (tráfego leste-oeste).
  • É possível alcançar opções de alta disponibilidade de serviços entre regiões.
  • As cargas de trabalho com estado e sem estado podem ser implantadas e gerenciadas em clusters separados.
  • Os serviços compartilhados estão disponíveis em clusters.

Para saber mais sobre como implantar o MCS, consulte Como configurar serviços de vários clusters.

O GKE fornece uma implementação da API Kubernetes Gateway que usa o controlador do Gateway GKE. O Gateway permite que o GKE implante balanceadores de carga do Google Cloud para fornecer roteamento de tráfego de entrada (norte-sul) para serviços implantados no GKE. O GKE também fornece gateways de vários clusters (MCG, na sigla em inglês), que estende o controlador do gateway do GKE para provisionar balanceadores de carga que encaminham o tráfego para serviços implantados em clusters diferentes do GKE.

O diagrama a seguir mostra como, ao combinar o MCS e o MCG, é possível gerenciar os aspectos complementares da implantação de serviço e do roteamento de tráfego de um único plano de controle:

Eles facilitam a comunicação entre serviços em um cluster, e o gateway de vários clusters implanta balanceadores de carga para rotear o tráfego entre os clusters.

Para mais informações, consulte Como implantar gateways de vários clusters.

Visão geral da migração

Os recursos de rede de vários clusters do GKE beneficiam cargas de trabalho de vários perfis. Por exemplo, é possível ter componentes sem estado com tráfego em burst que você quer migrar para o Autopilot devido ao modelo de custos mais eficiente.

Outra opção é colocar os front-ends do seu aplicativo mais próximos dos usuários. Essa abordagem fornece menor latência e armazenamento em cache, o que melhora o desempenho do aplicativo e a experiência do usuário. Ao mesmo tempo, você talvez tenha alguns componentes com estado em que o aplicativo depende e que só podem residir em um local. Essa configuração exige o balanceamento de carga de vários clusters norte-sul para enviar o tráfego do cliente ao cluster correto nesse local. Você também precisa do balanceamento de carga de vários clusters de leste a oeste para enviar tráfego entre clusters e alcançar os componentes com estado.

Neste documento, usamos o aplicativo de demonstração de microsserviços em nuvem do Online Boutique para demonstrar um padrão de vários clusters que pode ser usado para aprimorar a implantação da demonstração de zona única. Comece com uma versão de zona única do aplicativo. Em seguida, adicione elementos de alta disponibilidade e resiliência usando serviços de vários clusters e gateways de vários clusters e reduza o trabalho operacional aproveitando o Autopilot.

Implantação inicial de cluster único

No diagrama a seguir, o aplicativo "Online Boutique" é implantado inicialmente em um único cluster do modo padrão do GKE chamado std-west. Ele é exposto usando um serviço LoadBalancer:

Um único cluster do modo padrão do GKE que executa todos os serviços expostos usando um serviço LoadBalancer externo HTTP normal.

Migrar para serviços de vários clusters

Na próxima etapa intermediária, você vai criar dois clusters adicionais, e os serviços sem estado serão implantados em outras regiões. Crie dois clusters do Autopilot do GKE chamados auto-east e auto-central em duas regiões diferentes do único cluster padrão do GKE std-west. Em seguida, registre os clusters na frota do Google Cloud.

Frotas são um conceito do Google Cloud para organizar logicamente clusters e outros recursos. Eles permitem que você use e gerencie recursos de vários clusters e aplique políticas consistentes nos sistemas.

Você exporta cartservice no cluster std-west no namespace onlineboutique para os novos clusters de frota usando ServiceExport de dados. Implante o serviço de front-end do Online Boutique em todos os três clusters e exponha-o usando um serviço ClusterIP. Depois, exporte o serviço para a frota usando o ServiceExports. Serviços como a camada de middleware da Online Boutique (como productcatalog ,shipping e adservice) também são implantados nos três clusters.

Um Pod executado em qualquer cluster na frota pode acessar um Service exportado enviando uma solicitação para o URI ClusterSet desse serviço. A solicitação é roteada para um endpoint que faz backup do serviço.

O serviço frontend pode consumir os serviços de middleware (como productcatalogservice ou currencyservice) localmente no mesmo cluster. Essa arquitetura ajuda a manter as solicitações recebidas locais nas regiões onde o front-end responde à solicitação e evita cobranças desnecessárias de tráfego de rede entre regiões.

O diagrama a seguir ilustra os dois serviços de vários clusters. O serviço sem front-end sem estado é implantado em três clusters e o back-end com estado cartservice é implantado em um cluster. O diagrama também mostra que, nessa etapa intermediária, o tráfego de entrada do serviço de front-end permanece roteado para o cluster original do GKE Standard no us-west1 usando um balanceador de carga de rede de passagem externo criado pelo serviço LoadBalancer externo de front-end:

Os serviços de vários clusters são executados em três clusters do GKE, mas o tráfego ainda é direcionado para um único cluster usando um serviço LoadBalancer externo HTTP normal.

Migrar para o gateway de vários clusters

Na etapa final, encaminhe o tráfego de entrada para o serviço frontend de solicitações de clientes externos para serviços em vários clusters na frota usando um gateway de vários clusters.

Um quarto cluster chamado config-central é adicionado à frota para hospedar e gerenciar a configuração do gateway e do HTTPRoute que são criados como parte dessa configuração. O recurso HTTPRoute mapeia o prefixo / para o do front-end ServiceImport. O tráfego para o front-end do Online Boutique é enviado para um endpoint em bom estado em uma das regiões disponíveis. Essa abordagem adiciona elementos de alta disponibilidade à arquitetura do aplicativo "Online Boutique".

No diagrama a seguir, o gateway de vários clusters implanta um balanceador de carga global do Cloud que encaminha o tráfego externo para o serviço frontend sem estado implantado em cada um dos três clusters de aplicativo na frota.

Os serviços de vários clusters são executados em três clusters do GKE, e o tráfego agora é distribuído entre os serviços de front-end em todos os clusters usando um gateway externo de vários clusters.

No estado final, esse padrão opinativo demonstra um acoplamento flexível entre os estados (cartservice e redis-cart) e partes sem estado do aplicativo (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice). Fora do escopo deste documento, essa abordagem oferece uma oportunidade futura de adicionar resiliência e alta disponibilidade à camada de serviços com estado.

Objetivos

  • Criar e configurar clusters do GKE Standard e do Autopilot.
  • Implantar o "Online Boutique" em um cluster zonal padrão do GKE.
  • Exporte os Services de vários clusters.
  • Implantar manifestos em clusters padrão e do Autopilot.
  • Ativar e configurar gateways de vários clusters.
  • Teste o comportamento do aplicativo multirregional.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Antes de começar

As restrições de segurança definidas pela sua organização podem impedir que você conclua as etapas a seguir. Para informações sobre solução de problemas, consulte Desenvolver aplicativos em um ambiente restrito do Google Cloud.

Antes de começar, verifique se você atende aos seguintes requisitos:

  • É recomendável usar um novo projeto para este guia, porque a maneira mais fácil de fazer a limpeza é excluí-lo após a conclusão.
  • Neste guia, pressupomos que você tenha o papel de proprietário do IAM do projeto do Google Cloud. Para configurações de produção ou do mundo real, a prática recomendada é definir permissões com escopo com privilégio mínimo. Para mais informações, consulte Como usar o IAM com segurança e Gerenciar identidade e acesso.
  • Conheça a arquitetura do aplicativo de demonstração de microsserviços Online Boutique.

prepare o ambiente

Neste guia, você usa o Cloud Shell para inserir comandos. O Cloud Shell fornece acesso à linha de comando no Console do Google Cloud e inclui o SDK do Google Cloud e outras ferramentas, como a Google Cloud CLI. O Cloud Shell aparece como uma janela na parte inferior do Console do Google Cloud. A inicialização leva alguns minutos, mas a janela aparece imediatamente.

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  2. No Cloud Shell, defina as variáveis de ambiente usadas neste guia. Substitua PROJECT_ID pelo ID do projeto:

    export PROJECT=PROJECT_ID
    gcloud config set project ${PROJECT}
    
  3. Ative os serviços necessários para este documento:

    gcloud services enable \
        gkehub.googleapis.com \
        multiclusteringress.googleapis.com \
        dns.googleapis.com \
        trafficdirector.googleapis.com \
        cloudresourcemanager.googleapis.com \
        multiclusterservicediscovery.googleapis.com \
        container.googleapis.com
    
    gcloud container fleet multi-cluster-services enable
    

    Os serviços de vários clusters gerenciam componentes do Google Cloud, como Cloud DNS, regras de firewall e Cloud Service Mesh, portanto, essas APIs também devem ser ativadas. Para mais informações, consulte Visão geral do Cloud Service Mesh.

    A resposta será semelhante a:

    Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad"
    finished successfully.
    
    Waiting for Feature Multi-cluster Services to be created...done.
    
  4. Verifique se os serviços de vários clusters mostram o estado ACTIVE:

    gcloud container fleet multi-cluster-services describe
    

    A resposta será semelhante a:

    createTime: '2021-11-30T21:59:25.245190894Z'
    name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery
    resourceState:
      state: ACTIVE
    spec: {}
    updateTime: '2021-11-30T21:59:27.459063070Z'
    

    Se o valor de state não for ACTIVE, consulte a seção de solução de problemas da documentação do MCS.

Criar e configurar clusters do GKE

Para demonstrar o padrão de vários clusters neste guia, você usa três clusters de aplicativo em três regiões de nuvem separadas e um cluster para hospedar a configuração para Recursos de gateway. Você registra todos os clusters com a frota associada ao seu projeto. Um projeto do Google Cloud só pode ter uma frota associada a ele. Esse projeto é conhecido como o projeto host da frota.

  1. Crie clusters padrão e do Autopilot do GKE:

    gcloud container clusters create std-west \
        --zone us-west1-a \
        --num-nodes=6 \
        --enable-ip-alias \
        --release-channel regular \
        --workload-pool=${PROJECT}.svc.id.goog \
        --async
    
    gcloud container clusters create-auto auto-east \
        --region us-east1 \
        --release-channel regular \
        --async
    
    gcloud container clusters create-auto auto-central \
        --region us-central1 \
        --release-channel regular \
        --async
    
    gcloud container clusters create config-central \
        --region us-central1 \
        --num-nodes=1 \
        --enable-ip-alias \
        --release-channel regular \
        --workload-pool=${PROJECT}.svc.id.goog \
        --async
    

    A federação da identidade da carga de trabalho do GKE é ativada por padrão nos clusters do Autopilot do GKE para que você não precise usar a sinalização --workload-pool ao criar esses clusters como faz com os clusters padrão do GKE.

  2. Aguarde até que o STATUS dos clusters seja alterado de STATUS para STATUS. Esse processo pode levar até 10 minutos. É possível monitorar o progresso usando um loop de observação enquanto você toma uma xícara de café ou faz alguns exercícios de alongamento antes de continuar com o restante do documento.

    watch -n 20 --difference=permanent "gcloud container clusters list"
    

    A resposta será semelhante a:

    NAME: auto-central
    LOCATION: us-central1
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP: 107.178.213.138
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 3
    STATUS: PROVISIONING
    
    NAME: config-central
    LOCATION: us-central1
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP:
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 9
    STATUS: PROVISIONING
    
    NAME: auto-east
    LOCATION: us-east1
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP: 35.229.88.209
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 3
    STATUS: PROVISIONING
    
    NAME: std-west
    LOCATION: us-west1-a
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP: 35.197.93.113
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 6
    STATUS: PROVISIONING
    
  3. Depois que todos os clusters estiverem no estado RUNNING, pressione CTRL-C para interromper o comando.

  4. Adicione uma vinculação de política do Identity and Access Management (IAM) concedendo à conta de serviço MCS do projeto host da frota o papel de usuário de rede para o próprio projeto:

    gcloud projects add-iam-policy-binding ${PROJECT} \
        --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \
        --role "roles/compute.networkViewer"
    

    Use a federação de identidade da carga de trabalho do GKE para conceder ao serviço MCS acesso de leitura à configuração de rede VPC do projeto. Como resultado, a conta de serviço do Importer GKE do projeto host da frota precisa desse papel.

    A resposta será semelhante a:

    - members:
      - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]
      role: roles/compute.networkViewer
    [...]
    
  5. Registre os clusters do GKE Standard e do Autopilot na frota do projeto. Consulte Como registrar um cluster para mais detalhes. Isso pode levar até cinco minutos:

    gcloud container fleet memberships register std-west \
        --gke-cluster us-west1-a/std-west \
        --enable-workload-identity \
        --project=${PROJECT}
    
    gcloud container fleet memberships register auto-east \
        --gke-cluster us-east1/auto-east \
        --enable-workload-identity \
        --project=${PROJECT}
    
    gcloud container fleet memberships register auto-central \
        --gke-cluster us-central1/auto-central \
        --enable-workload-identity \
        --project=${PROJECT}
    
    gcloud container fleet memberships register config-central \
        --gke-cluster us-central1/config-central \
        --enable-workload-identity \
        --project=${PROJECT}
    

    Para cada comando, a saída é semelhante ao exemplo a seguir:

    Waiting for membership to be created...done.
    Created a new membership [projects/PROJECT_ID/locations/global/memberships/std-west] for the cluster [std-west]
    Generating the Connect Agent manifest...
    Deploying the Connect Agent on cluster [std-west] in namespace [gke-connect]...
    Deployed the Connect Agent on cluster [std-west] in namespace [gke-connect].
    Finished registering the cluster [std-west] with the Hub.
    
  6. Conecte-se aos clusters e gere entradas kubeconfig:

    gcloud container clusters get-credentials std-west \
        --zone us-west1-a --project $PROJECT
    
    gcloud container clusters get-credentials auto-east \
        --region us-east1 --project $PROJECT
    
    gcloud container clusters get-credentials auto-central \
        --region us-central1 --project $PROJECT
    
    gcloud container clusters get-credentials config-central \
        --region us-central1 --project $PROJECT
    

    Para cada comando, a saída é semelhante ao exemplo a seguir:

    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for std-west.
    
  7. Renomeie os contextos de clusters para facilitar o trabalho no restante deste documento:

    kubectl config rename-context \
        gke_${PROJECT}_us-west1-a_std-west \
        std-west
    
    kubectl config rename-context \
        gke_${PROJECT}_us-east1_auto-east \
        auto-east
    
    kubectl config rename-context \
        gke_${PROJECT}_us-central1_auto-central \
        auto-central
    
    kubectl config rename-context \
        gke_${PROJECT}_us-central1_config-central \
        config-central
    

    Neste guia, os contextos são nomeados com base na localização deles. É possível fornecer nomes alternativos, mas as etapas restantes deste guia usam os nomes usados nesta etapa.

Implantar o Online Boutique no GKE Standard

Na primeira etapa da implantação de demonstração, implante o conjunto completo de serviços do aplicativo Online Boutique no único cluster GKE Standard std-west no std-west.

  1. Crie o namespace onlineboutique em std-west:

    kubectl create namespace onlineboutique --context std-west
    

    A resposta será semelhante a:

    namespace/onlineboutique created
    
  2. Clone o repositório do GitHub do Online Boutique e configure uma variável WORKDIR:

    cd ~
    
    git clone --branch release/v0.4.1 \
        https://github.com/GoogleCloudPlatform/microservices-demo.git
    
    cd microservices-demo/release && export WORKDIR=`pwd`
    
  3. Implante o Online Boutique em std-west. Esse processo cria Deployments e Services para todos os microsserviços do Online Boutique e inclui um serviço LoadBalancer que expõe externamente o serviço de front-end da Online Boutique:

    cd $WORKDIR
    
    kubectl apply -f kubernetes-manifests.yaml \
        -n onlineboutique --context=std-west
    
  4. Aguarde o serviço LoadBalancer receber um IP externo:

    watch -n 20 --difference=permanent \
         "kubectl get svc frontend-external -n onlineboutique --context=std-west"
    

    Inicialmente, resposta vai ser semelhante a esta:

    NAME                TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
    frontend-external   LoadBalancer   10.60.5.62   <pending>     80:30359/TCP   43s
    

    Quando o Service estiver pronto, a coluna EXTERNAL-IP vai exibir o endereço IP público do balanceador de carga.

  5. Depois que o Service estiver pronto, consiga o endereço IP externo do balanceador de carga e use curl para verificar se o front-end está pronto. Se este comando curl retornar um erro, aguarde alguns instantes e tente novamente:

      curl $(kubectl get svc frontend-external \
          -n onlineboutique --context=std-west \
          -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \
            grep -e Cluster -e Zone -e Pod
    

    A saída bem-sucedida do comando curl é semelhante ao exemplo a seguir:

    <b>Cluster: </b>std-west<br/>
    <b>Zone: </b>us-west1-a<br/>
    <b>Pod: </b>frontend-b7bddcc97-wdjsk
    

Agora você tem uma versão de zona única do Online Boutique em execução em us-west1-a. Também é possível usar um navegador da Web para acessar o IP externo atribuído ao serviço LoadBalancer frontend-external para acessar o aplicativo e observar o comportamento dele. Essa implantação única inicial é mostrada no seguinte diagrama:

Um único cluster do modo padrão do GKE que executa todos os serviços expostos por meio de um serviço LoadBalancer externo HTTP normal.

Exportar o serviço de carrinho como um serviço de vários clusters

Nesta seção, você começa a adicionar elementos de alta disponibilidade ao aplicativo. Exporte o cartservice de back-end como um serviço de vários clusters para os clusters do GKE Autopilot.

  1. Crie o namespace onlineboutique nos clusters restantes:

    kubectl create namespace onlineboutique --context auto-east
    
    kubectl create namespace onlineboutique --context auto-central
    
    kubectl create namespace onlineboutique --context config-central
    

    Para cada comando, a saída é semelhante ao exemplo a seguir:

    namespace/onlineboutique created
    
  2. Exporte cartservice do cluster std-west para todos os outros clusters no ClusterSet. O objeto ServiceExport registra o serviço cartservice, com os serviços de vários clusters do GKE, para exportação para todos os clusters na frota que têm o namespace onlineboutique presente. Para mais detalhes, consulte Como registrar um serviço para exportação.

    cat <<EOF>> $WORKDIR/cartservice-export.yaml
    kind: ServiceExport
    apiVersion: net.gke.io/v1
    metadata:
     namespace: onlineboutique
     name: cartservice
    
    EOF
    
    kubectl apply -f $WORKDIR/cartservice-export.yaml \
        -n onlineboutique --context=std-west
    

Aplicar manifestos de aplicativo para o padrão de vários clusters

Nesta seção, você aplicará dois manifestos selecionados para implantar o padrão de vários clusters. Esses manifestos contêm partes selecionadas do kubernetes-manifests.yaml que você aplicou anteriormente ao cluster kubernetes-manifests.yaml:

  • O primeiro manifesto é usado para o front-end Deployment, Service e ServiceExport.
  • O segundo manifesto é usado para implantar o middleware Services (emailservice, emailservice, emailservice, emailservice, emailservice, emailservice, emailservice e emailservice) a todas as regiões que tem um emailservice em execução. Ao manter uma solicitação local por uma região pelo maior tempo possível, você evita cobranças desnecessárias de tráfego de rede entre regiões.

Um Pod executado em qualquer cluster na frota pode acessar um Service exportado enviando uma solicitação para o URI ClusterSet desse serviço no formato SERVICE_NAME.NAMESPACE.svc.clusterset.local. Por exemplo, o frontend Deployments nos três clusters de exemplo pode consumir o cartservice, no namespace onlineboutique, ao fazer uma solicitação para cartservice.onlineboutique.svc.clusterset.local.

Por esse motivo, em cada manifesto, o nome do host do cartservice foi atualizado para o URI ClusterSet. Portanto, esta etapa é essencial. Se esse nome de host de serviço não for atualizado, o serviço frontend vai solicitar que kube-dns receba cartservice em vez de cartservice.onlineboutique.svc.clusterset.local. Esse comportamento resultaria em erros HTTP Status 500 em clusters em que uma versão local do cartservice não está disponível e fazer com que os pods frontend não estejam íntegros de dados.

  1. Defina um ambiente variável para o repositório do GitHub que contenha os manifestos:

    export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migration
    
  2. Aplique os manifestos para implantar a camada de front-end nos três clusters de carga de trabalho:

    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
        -n onlineboutique --context=std-west
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
        -n onlineboutique --context=auto-east
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
        -n onlineboutique --context=auto-central
    
  3. Aplique os manifestos para implantar a camada de middleware em todos os três clusters de carga de trabalho:

    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
        -n onlineboutique --context=std-west
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
        -n onlineboutique --context=auto-east
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
        -n onlineboutique --context=auto-central
    

Agora você tem o front-end Deployment, Service e ServiceExport ativos nos clusters std-west, auto-east e auto-central. Também há serviços locais de middleware do Online Boutique em cada cluster. No entanto, o tráfego externo ainda é roteado apenas para o Service executado no cluster inicial em us-west1, conforme mostrado no diagrama a seguir:

Os serviços de vários clusters são executados em três clusters do GKE, mas o tráfego ainda é direcionado para um único cluster usando um serviço LoadBalancer externo HTTP normal.

Ativar e configurar gateways de vários clusters

Nesta seção, você roteia o tráfego e equilibra a carga do tráfego externo entre front-ends nos três clusters. Para conseguir essa configuração, use gateways de vários clusters (MCG). Este documento segue as instruções para configurar o MCG conforme descrito em Como ativar gateways de vários clusters.

Neste guia, use o cluster config-central para hospedar a configuração dos recursos de gateway.

  1. Confirme se todos os clusters foram registrados na frota:

    gcloud container fleet memberships list --project=$PROJECT
    

    O exemplo de saída a seguir mostra que todos os clusters foram registrados com sucesso:

    NAME: auto-central
    EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f
    
    NAME: config-central
    EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98
    
    NAME: std-west
    EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3
    
    NAME: auto-east
    EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012
    
  2. Instale a definição de recurso personalizada da API Gateway no cluster config-central:

    kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \
        | kubectl apply -f -
    

    Esta etapa instala as definições de recursos personalizados da API Gateway, incluindo os recursos GatewayClass, Gateway e HTTPRoute. As definições de recursos personalizados são mantidas pelo Grupo de interesse especial da rede do Kubernetes. Depois de instalado, é possível usar o controlador de gateway do GKE.

  3. Ative a entrada em vários clusters para sua frota, caso ainda não tenha feito isso. A ativação desse recurso também ativa o controlador de gateway de vários clusters.

    gcloud container fleet ingress enable \
        --config-membership=config-central \
        --project=$PROJECT
    
    gcloud container fleet ingress describe --project=$PROJECT
    

    A resposta será semelhante a:

    createTime: '2021-12-08T23:10:52.505888854Z'
    name: projects/PROJECT_ID/locations/global/features/multiclusteringress
    resourceState:
      state: ACTIVE
    spec:
      multiclusteringress:
        configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central
    state:
      state:
        code: OK
        description: Ready to use
        updateTime: '2021-12-08T23:11:37.994971649Z'
    updateTime: '2021-12-08T23:11:38.098244178Z'
    

    Se o valor de state não for ACTIVE, consulte Solução de problemas e operações para a entrada Multicluster.

  4. Confirme se GatewayClasses está disponível no cluster config-central:

    kubectl get gatewayclasses --context=config-central
    

    A resposta será semelhante a:

    NAME                                  CONTROLLER                  AGE
    gke-l7-global-external-managed        networking.gke.io/gateway   18s
    gke-l7-global-external-managed-mc     networking.gke.io/gateway   19s
    gke-l7-regional-external-managed      networking.gke.io/gateway   18s
    gke-l7-regional-external-managed-mc   networking.gke.io/gateway   19s
    gke-l7-gxlb                           networking.gke.io/gateway   74s
    gke-l7-gxlb-mc                        networking.gke.io/gateway   16s
    gke-l7-rilb                           networking.gke.io/gateway   74s
    gke-l7-rilb-mc                        networking.gke.io/gateway   16s
    

    Diferentes recursos do GatewayClass têm recursos distintos. Para mais informações sobre quando usar qual tipo, consulte Recursos da GatewayClass.

  5. Implante o recurso Gateway external-http em config-central:

    cat <<EOF>> $WORKDIR/external-http-gateway.yaml
    kind: Gateway
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: external-http
      namespace: onlineboutique
    spec:
      gatewayClassName: gke-l7-global-external-managed-mc
      listeners:
      - protocol: HTTP
        port: 80
        name: http
    EOF
    
    kubectl apply -f external-http-gateway.yaml \
        -n onlineboutique --context=config-central
    

    Conforme indicado pelo campo gatewayClassName, esse recurso é de GatewayClass gke-l7-global-external-managed-mc, que gerencia o Cloud Load Balancing da camada 7 e expõe o aplicativo de vários clusters

  6. Implante o HTTPRoute denominado public-frontend-route em config-central:

    cat <<EOF>> $WORKDIR/public-frontend-route.yaml
    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: public-frontend-route
      namespace: onlineboutique
    spec:
      parentRefs:
      - name: "external-http"
      hostnames:
      - "store.example.com"
      rules:
      - matches:
        - path:
            type: PathPrefix
            value: /
        backendRefs:
        - name: frontend
          group: net.gke.io
          kind: ServiceImport
          port: 80
    EOF
    
    kubectl apply -f public-frontend-route.yaml \
        -n onlineboutique --context=config-central
    

    Quando você implanta o HTTPRoute, é criado um recurso externo de camada 7 do Cloud Load Balancing e é exposto o front-endServiceImport com suporte dos serviços de front-end que são executados nos clusters std-west, std-west e std-west.

    O diagrama a seguir mostra como, após a implantação do gateway de vários clusters, o tráfego pode ser roteado para qualquer um dos serviços de vários clusters de front-end em qualquer um dos três clusters de aplicativo:

    Os serviços de vários clusters são executados em três clusters do GKE, e o tráfego agora é distribuído entre os serviços de front-end em todos os clusters usando um gateway externo de vários clusters.

  7. Aguarde o balanceador de carga estar pronto com um endereço IP externo provisionado antes de prosseguir para a próxima etapa. Pode levar até 10 minutos para que o endereço IP seja atribuído. É possível monitorar o progresso usando um loop de observação. O balanceador de carga tem um nome no padrão como gkemcg-onlineboutique-external-http-k09mfhk74gop:

    watch -n 20 --difference=permanent \
        "gcloud compute forwarding-rules list \
            | grep -A 5 NAME..*external-http"
    

    A resposta será semelhante a:

    NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop
    REGION:
    IP_ADDRESS: 34.149.29.176
    IP_PROTOCOL: TCP
    TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gop
    
  8. Quando o balanceador de carga estiver pronto, execute o seguinte comando no Cloud Shell para exportar o endereço IP externo do balanceador de carga criado pelo aplicativo external-http-gateway.yaml e external-http-gateway.yaml manifests:

    export EXTERNAL_LB_IP=$(kubectl --context=config-central \
                                -n onlineboutique get gateway external-http \
                                -o=jsonpath='{.status.addresses[0].value}')
    
  9. Quando você envia uma solicitação ao balanceador de carga com os cabeçalhos apropriados, ela retorna o conteúdo HTML exibido pelo serviço de front-end. Por exemplo, como você configurou o recurso HTTPRoute para mapear o nome do host store.example.com no front-end ServiceImport, forneça o HOST ao fazer a solicitação HTTP. Se o exemplo de curl a seguir retornar um erro, aguarde alguns minutos e tente novamente:

    curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
        grep -e Cluster -e Zone -e Pod
    

    A saída bem-sucedida do comando curl é semelhante ao exemplo a seguir:

    <b>Cluster: </b>auto-central<br/>
    <b>Zone: </b>us-central1-f<br/>
    <b>Pod: </b>frontend-7c7d596ddc-jdh8f
    

Testar o comportamento de roteamento multirregional do aplicativo

Um dos recursos avançados obtidos usando serviços de vários clusters e gateways de vários clusters é que as solicitações externas são roteadas para o cluster geograficamente mais próximo.

Para testar o comportamento multirregional do aplicativo, gere tráfego proveniente das várias regiões em que você tem clusters implantados. Crie três pods pequenos, um em cada um dos clusters de exibição (std-west, std-west e std-west), que podem ser usados para enviar solicitações HTTP ao endpoint do balanceador de carga. Os resultados permitem que você veja qual front-end Pod responde.

  1. Crie os pods clientes:

    kubectl run --context=std-west \
                --image=radial/busyboxplus:curl client-west \
                -- sh -c 'while sleep 3600; do :; done'
    
    kubectl run --context=auto-east \
                --image=radial/busyboxplus:curl client-east \
                -- sh -c 'while sleep 3600; do :; done'
    
    kubectl run --context=auto-central \
                --image=radial/busyboxplus:curl client-central \
                -- sh -c 'while sleep 3600; do :; done'
    
  2. Quando os pods estiverem em execução, use um comando curl para enviar uma solicitação ao endpoint do balanceador de carga do cliente Pod no cluster std-west e analisar a resposta:

    kubectl exec -it --context=std-west client-west \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
               grep -e Cluster -e Zone -e Pod
    

    A saída bem-sucedida do comando curl é semelhante ao exemplo a seguir:

    <b>Cluster: </b>std-west<br/>
    <b>Zone: </b>us-west1-a<br/>
    <b>Pod: </b>frontend-7cf48b79cf-trzc4
    
  3. Execute a mesma solicitação curl do Pod do cliente no cluster auto-east e observe a resposta:

    kubectl exec -it --context=auto-east client-east \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
               grep -e Cluster -e Zone -e Pod
    

    A saída bem-sucedida do comando curl é semelhante ao exemplo a seguir:

    <b>Cluster: </b>auto-east<br/>
    <b>Zone: </b>us-east1-d<br/>
    <b>Pod: </b>frontend-6784b6df98-scdws
    

    Como este é um cluster do Autopilot, o cluster pode precisar provisionar recursos adicionais para programar o Pod. Se você vir uma saída semelhante ao exemplo a seguir, aguarde um momento e tente novamente:

     Error from server (BadRequest): pod client-east does not have a host assigned
    
  4. Execute o curl no Pod do cliente no cluster auto-central e verifique a resposta:

    kubectl exec -it --context=auto-central client-central \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
            grep -e Cluster -e Zone -e Pod
    

    A saída bem-sucedida do comando curl é semelhante ao exemplo a seguir:

    <b>Cluster: </b>auto-central<br/>
    <b>Zone: </b>us-central1-b<br/>
    <b>Pod: </b>frontend-6784b6df98-x2fv4
    

    Esses resultados confirmam que o tráfego é roteado para os pods correspondentes nos locais mais próximos da origem da solicitação.

Testar a resiliência multirregional do aplicativo

Além do roteamento de tráfego eficiente, a execução dos serviços em várias regiões fornece resiliência no caso raro, mas ainda possível, de falha de infraestrutura.

Exclua o front-end Deployments em clusters específicos para testar o comportamento. Em seguida, tente executar novamente o comando curl do Pod do cliente nessas regiões. O aplicativo ainda está disponível. Veja o local do Pod que responde à solicitação.

  1. Execute o comando curl no client-west Pod no cluster std-west e veja se o resultado vem do front-end no us-west1:

    kubectl exec -it --context=std-west client-west \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP  | \
               grep -e Cluster -e Zone -e Pod
    

    A saída bem-sucedida do comando curl é semelhante ao exemplo a seguir:

    <b>Cluster: </b>std-west<br/>
    <b>Zone: </b>us-west1-a<br/>
    <b>Pod: </b>frontend-7cf48b79cf-trzc4
    
  2. Exclua o frontend Deployment no cluster std-west:

    kubectl delete deploy frontend \
        -n onlineboutique --context=std-west
    

    A resposta será semelhante a:

    deployment.apps "frontend" deleted
    
  3. Envie outra solicitação da client-west Pod no cluster std-west. Você vai ver uma resposta de um dos Deployments do front-end restante localizado nos clusters auto-east ou auto-central.

    kubectl exec -it --context=std-west client-west \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
               grep -e Cluster -e Zone -e Pod
    

    Uma saída semelhante ao seguinte exemplo indica a localização da Pod em bom estado que responde a essa solicitação:

    <b>Cluster: </b>auto-central<br/>
    <b>Zone: </b>us-central1-b<br/>
    <b>Pod: </b>frontend-6784b6df98-x2fv4
    

    ou

    <b>Cluster: </b>auto-east<br/>
    <b>Zone: </b>us-east1-d<br/>
    <b>Pod: </b>frontend-6784b6df98-scdws
    

    Execute o comando várias vezes para ver resultados alternados.

Com essa implantação de demonstração, você adicionou elementos de resiliência e distribuição geográfica ao aplicativo "Online Boutique" usando gateways e clusters de vários clusters. As solicitações são encaminhadas para a região geográfica mais próxima e, mesmo que os serviços de front-end ou middleware em uma região tenham problemas, o usuário final ainda pode usar o aplicativo.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

A seguir