A rede de vários clusters é uma ferramenta valiosa que permite exemplos de utilização como a elevada disponibilidade regional, a proximidade distribuída globalmente aos utilizadores para uma menor latência e o isolamento organizacional entre equipas. O Google Kubernetes Engine (GKE) oferece capacidades incorporadas para redes de vários clusters que pode ativar e usar em grande escala numa frota de clusters do GKE. Esta funcionalidade também lhe permite combinar ou migrar a infraestrutura implementada entre o GKE Standard e o Autopilot para satisfazer as necessidades de arquitetura de cada aplicação.
Com os clusters do GKE Autopilot, a Google gere a infraestrutura, incluindo o plano de controlo e os nós. Se quiser configurar e gerir os seus nós, o GKE oferece o modo Standard. Para mais informações sobre as diferenças entre os modos, consulte o artigo Escolha um modo de funcionamento do cluster.
Esta página demonstra estas funcionalidades através de várias topologias de implementação. Aprende a usar uma aplicação implementada num único cluster do GKE e a migrá-la para uma implementação de vários clusters nos clusters do GKE Standard e Autopilot. Usa os serviços em vários clusters do GKE para tráfego leste-oeste e os gateways em vários clusters para ativar a rede norte-sul em vários clusters.
Esta página destina-se a arquitetos de nuvem e equipas de operações que usam ou planeiam usar o GKE para implementar serviços em vários clusters do Kubernetes. Antes de ler esta página, certifique-se de que conhece o Kubernetes.
Serviços em vários clusters e gateways em vários clusters
O Kubernetes pode ser executado com um único plano de controlo em zonas da nuvem distintas para oferecer resiliência e maior disponibilidade aos seus serviços.
O GKE vai um passo mais longe e oferece
GKE
serviços multi-cluster
(MCS) que fornecem um mecanismo de invocação e descoberta de serviços entre clusters.
Os serviços que usam esta funcionalidade são detetáveis e acessíveis em todos os clusters com um IP virtual, o que corresponde ao comportamento de um ClusterIPserviço acessível num cluster. Esta abordagem permite as seguintes vantagens:
- Os serviços podem ser equilibrados em vários clusters na mesma região ou em regiões diferentes (tráfego leste-oeste).
- As opções de elevada disponibilidade do serviço em várias regiões são alcançáveis.
- As cargas de trabalho com estado e sem estado podem ser implementadas e geridas em clusters separados.
- Os serviços partilhados estão disponíveis em todos os clusters.
Para saber como implementar o MCS, consulte o artigo Configurar serviços multicluster.
O GKE fornece uma implementação da API Kubernetes Gateway que usa o GKE Gateway controller. A Gateway permite que o GKE implemente Google Cloud balanceadores de carga para fornecer encaminhamento de tráfego de entrada (norte-sul) para serviços implementados no GKE. O GKE também fornece Gateways de vários clusters (MCG) que expandem o GKE Gateway Controller para aprovisionar equilibradores de carga que encaminham o tráfego para serviços implementados em clusters do GKE distintos.
O diagrama seguinte mostra como, quando combina o MCS e o MCG, pode gerir os aspetos complementares da implementação de serviços e do encaminhamento de tráfego a partir de um único plano de controlo:
Para mais informações, consulte o artigo Implementar gateways de vários clusters.
Vista geral da migração
As capacidades de rede multicluster do GKE beneficiam as cargas de trabalho de vários perfis. Por exemplo, pode ter componentes sem estado com tráfego intermitente que quer mover para o Autopilot devido ao respetivo modelo de custo mais eficiente.
Em alternativa, pode querer colocar os frontends da sua aplicação mais perto dos utilizadores. Esta abordagem oferece uma latência mais baixa e uma colocação em cache que melhora o desempenho da aplicação e a experiência do utilizador. Ao mesmo tempo, pode ter alguns componentes com estado dos quais a sua aplicação depende e que só podem residir numa localização. Esta configuração requer o equilíbrio de carga de vários clusters norte-sul para enviar o tráfego de clientes para o cluster correto nessa localização. Também precisa do balanceamento de carga leste-oeste e de vários clusters para enviar tráfego entre clusters para alcançar os componentes com estado.
Esta página usa a aplicação de demonstração de microsserviços na nuvem Online Boutique para demonstrar um padrão de vários clusters que pode ser usado para melhorar a implementação da demonstração de zona única. Começa com uma versão de zona única da aplicação. Em seguida, adiciona elementos de alta disponibilidade e resiliência através da utilização de serviços de vários clusters e gateways de vários clusters, e reduz o esforço operacional tirando partido do Autopilot.
Implementação inicial de cluster único
No diagrama seguinte, a aplicação Online Boutique é inicialmente implementada num único cluster do modo padrão do GKE denominado std-west e é exposta através de um serviço LoadBalancer:
Migre para serviços em vários clusters
No passo intermédio seguinte, cria dois clusters adicionais e os serviços sem estado são implementados em regiões adicionais. Cria dois clusters do GKE Autopilot denominados auto-east e auto-central em duas regiões separadas distintas do cluster do GKE Standard único std-west e regista os clusters na Google Cloud frota.
As frotas são um Google Cloud conceito para organizar logicamente clusters e outros recursos, e permitem-lhe usar e gerir capacidades de vários clusters e aplicar políticas consistentes nos seus sistemas.
Exporta o cartservice no cluster std-west no espaço de nomes onlineboutique
para os novos clusters da frota através de
ServiceExport.
Implementa o serviço frontend da Online Boutique nos três clusters e expõe-o através de um serviço ClusterIP. Em seguida, exporta o serviço para a frota através de ServiceExports.
Os serviços, como a camada de middleware da Online Boutique (como productcatalog, shipping e adservice), também são implementados em todos os três clusters.
Um Pod que é executado em qualquer cluster na frota pode aceder a um Service exportado
enviando um pedido para o URI ClusterSet desse serviço. O pedido é encaminhado para um ponto final que suporta o serviço.
O serviço frontend pode consumir os serviços de middleware (como productcatalogservice ou currencyservice) localmente no mesmo cluster. Esta arquitetura ajuda a manter os pedidos recebidos locais para as regiões cujo front-end responde ao pedido e evita cobranças de tráfego de rede entre regiões desnecessárias.
O diagrama seguinte ilustra os dois serviços de vários clusters. O serviço de front-end sem estado é implementado em três clusters e o serviço de carrinho com estado é implementado num cluster. O diagrama também mostra que, neste passo intermédio, o tráfego de entrada para o serviço de front-end permanece encaminhado para o cluster padrão do GKE original em us-west1, usando um equilibrador de carga de rede de passagem externo criado pelo serviço LoadBalancer frontend-external:
Migre para o gateway de vários clusters
No passo final, encaminha o tráfego de entrada para o serviço de front-end a partir de pedidos de clientes externos para serviços em vários clusters na frota através de um gateway de vários clusters.
É adicionado um quarto cluster denominado config-central à frota para alojar e gerir os recursos
Gateway
e
HTTPRoute
criados como parte desta configuração. O recurso HTTPRoute
mapeia o prefixo / para o frontend
ServiceImport.
O tráfego para o frontend da Online Boutique é enviado para um ponto final
em bom estado numa das regiões disponíveis. Esta abordagem adiciona elementos de elevada disponibilidade à arquitetura da aplicação Online Boutique.
No diagrama seguinte, o gateway de vários clusters implementa um equilibrador de carga do Google Cloud global que encaminha o tráfego externo para o serviço frontend sem estado implementado em cada um dos três clusters de aplicações na frota.
No estado final, este padrão opinativo demonstra um acoplamento fraco entre as partes com estado (cartservice e redis-cart) e sem estado da aplicação (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice). Embora esteja fora do âmbito desta página, esta abordagem oferece-lhe uma oportunidade futura de adicionar resiliência e alta disponibilidade à camada de serviços com estado.
Objetivos
- Crie e configure clusters do GKE Standard e Autopilot.
- Implemente a Online Boutique num cluster padrão do GKE zonal.
- Exporte vários clusters
Services. - Implemente manifestos em clusters padrão e do Autopilot.
- Ative e configure gateways de vários clusters.
- Teste o comportamento da aplicação em várias regiões.
Custos
Neste documento, usa os seguintes componentes faturáveis do Google Cloud:
Para gerar uma estimativa de custos com base na sua utilização projetada,
use a calculadora de preços.
Antes de começar
As restrições de segurança definidas pela sua organização podem impedir a conclusão dos seguintes passos. Para informações de resolução de problemas, consulte o artigo Desenvolva aplicações num ambiente Google Cloud restrito.
Antes de começar, certifique-se de que cumpre os seguintes requisitos:
- Recomendamos que use um novo projeto para este guia, uma vez que a forma mais fácil de limpar é eliminar o projeto quando terminar.
- Este guia pressupõe que tem a função de IAM de proprietário para o seu Google Cloud projeto. Para definições de produção ou do mundo real, é uma boa prática restringir as autorizações ao mínimo privilégio. Para mais informações, consulte os artigos Usar o IAM de forma segura e Validar explicitamente todas as tentativas de acesso.
- Familiarize-se com a arquitetura da aplicação de demonstração de microsserviços da loja online.
Prepare o ambiente
Neste guia, vai usar a Cloud Shell para introduzir comandos. O Cloud Shell dá-lhe acesso à linha de comandos na Google Cloud consola e inclui o SDK Cloud da Google e outras ferramentas, como a CLI do Google Cloud. O Cloud Shell aparece como uma janela na parte inferior da Google Cloud consola. A inicialização pode demorar vários minutos, mas a janela aparece imediatamente.
In the Google Cloud console, activate Cloud Shell.
No Cloud Shell, defina as variáveis de ambiente usadas neste guia. Substitua PROJECT_ID pelo seu ID do projeto:
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}Ative os serviços necessários para os passos desta página:
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 enableOs serviços multicluster gerem Google Cloud componentes como o Cloud DNS, as regras de firewall e a Cloud Service Mesh, pelo que estas APIs também têm de ser ativadas. Para mais informações, consulte a vista geral da Cloud Service Mesh.
O resultado é semelhante ao seguinte exemplo:
Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad" finished successfully. Waiting for Feature Multi-cluster Services to be created...done.Verifique se os serviços de vários clusters mostram o estado ATIVO:
gcloud container fleet multi-cluster-services describeO resultado é semelhante ao seguinte exemplo:
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 os detalhes de resolução de problemas de serviços de vários clusters.
Crie clusters do GKE Standard e Autopilot:
gcloud container clusters create std-west \ --location 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 \ --location us-east1 \ --release-channel regular \ --async gcloud container clusters create-auto auto-central \ --location us-central1 \ --release-channel regular \ --async gcloud container clusters create config-central \ --location us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --asyncA Workload Identity Federation para o GKE está ativada por predefinição nos clusters do GKE Autopilot, pelo que não tem de usar a flag
--workload-poolquando cria esses clusters, como faz com os clusters do GKE Standard.Aguarde que o ESTADO dos clusters mude de PROVISIONING para RUNNING. Este processo pode demorar até 10 minutos. Pode monitorizar o progresso através de um ciclo de observação:
watch -n 20 --difference=permanent "gcloud container clusters list"O resultado é semelhante ao seguinte exemplo:
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: PROVISIONINGDepois de todos os clusters estarem no estado RUNNING, prima
CTRL-Cpara interromper o comando.Adicione uma associação de política de gestão de identidade e de acesso (IAM) que conceda à conta de serviço do MCS do projeto anfitrião da frota a função de utilizador da rede para o seu 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"Usa a Workload Identity Federation para o GKE para conceder ao serviço MCS acesso de leitura à configuração da rede VPC do seu projeto. Como resultado, a conta de serviço do GKE do importador do MCS do projeto anfitrião da frota precisa desta função.
O resultado é semelhante ao seguinte exemplo:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]Registe os clusters do GKE Standard e Autopilot na frota do seu projeto. Consulte o artigo Registar um cluster para ver mais detalhes. Este passo pode demorar até 5 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, o resultado é semelhante ao seguinte exemplo:
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.Estabeleça ligação aos clusters e gere entradas kubeconfig:
gcloud container clusters get-credentials std-west \ --location us-west1-a --project $PROJECT gcloud container clusters get-credentials auto-east \ --location us-east1 --project $PROJECT gcloud container clusters get-credentials auto-central \ --location us-central1 --project $PROJECT gcloud container clusters get-credentials config-central \ --location us-central1 --project $PROJECTPara cada comando, o resultado é semelhante ao seguinte exemplo:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.Mude o nome dos contextos dos clusters para que seja mais fácil trabalhar com eles no resto desta página:
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-centralNeste guia, os contextos são denominados com base na respetiva localização. Embora possa fornecer nomes alternativos, os restantes passos neste guia usam os nomes usados neste passo.
Crie o espaço de nomes onlineboutique em std-west:
kubectl create namespace onlineboutique --context std-westO resultado é semelhante ao seguinte exemplo:
namespace/onlineboutique createdClone o repositório do GitHub da 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`Implemente a Online Boutique em std-west. Este processo cria
DeploymentseServicespara todos os microsserviços da Online Boutique e inclui um serviço do tipo 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-westAguarde que o serviço
LoadBalancerobtenha um IP externo:watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"Inicialmente, o resultado é semelhante ao seguinte exemplo:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-external LoadBalancer 10.60.5.62 <pending> 80:30359/TCP 43sQuando o
Serviceestiver pronto, a coluna EXTERNAL-IP apresenta o endereço IP público do balanceador de carga.Quando o
Serviceestiver pronto, obtenha o endereço IP externo do balanceador de carga e use o curl para verificar se o front-end está pronto. Se este comando curl devolver um erro, aguarde alguns momentos antes de tentar 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 PodO resultado bem-sucedido do comando curl é semelhante ao seguinte exemplo:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-b7bddcc97-wdjskCrie o espaço de nomes onlineboutique nos restantes clusters:
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-centralPara cada comando, o resultado é semelhante ao seguinte exemplo:
namespace/onlineboutique createdExporte o cartservice do cluster std-west para todos os outros clusters no
ClusterSet. O objetoServiceExportregista o serviço cartservice com os serviços de vários clusters do GKE para exportação para todos os clusters na frota que tenham o espaço de nomes onlineboutique presente. Para mais detalhes, consulte o artigo sobre como registar 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- O primeiro manifesto é usado para o front-end
Deployment,ServiceeServiceExport. - O segundo manifesto é usado para implementar o middleware
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice) em todas as regiões que têm um frontend em execução. Ao manter um pedido local a uma região durante o maior tempo possível, evita custos desnecessários de tráfego de rede entre regiões. Defina uma variável de ambiente para o repositório do GitHub que contém os manifestos:
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migrationAplique os manifestos para implementar a camada de front-end em todos os 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-centralAplique os manifestos para implementar 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-centralConfirme se todos os clusters foram registados com êxito na frota:
gcloud container fleet memberships list --project=$PROJECTO seguinte resultado de exemplo mostra que todos os clusters estão registados com êxito:
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-612f14810012Instale a definição de recurso personalizado 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 -Este passo instala as definições de recursos personalizados da API Gateway, incluindo os recursos
GatewayClass,GatewayeHTTPRoute. As definições de recursos personalizados são mantidas pelo grupo de interesse especial de rede do Kubernetes. Após a instalação, pode usar o controlador do GKE Gateway.Ative o Multi Cluster Ingress para a sua frota, se ainda não o tiver feito. A ativação desta funcionalidade também ativa o controlador de gateway multicluster.
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECTO resultado é semelhante ao seguinte exemplo:
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 a secção Resolução de problemas e operações para o Multi Cluster Ingress.
Confirme se os
GatewayClassesestão disponíveis no cluster config-central:kubectl get gatewayclasses --context=config-centralO resultado é semelhante ao seguinte exemplo:
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 16sDiferentes recursos
GatewayClasstêm diferentes capacidades. Para mais informações sobre quando usar que tipo, consulte Capacidades de GatewayClass.Implemente o recurso de gateway
external-httpemconfig-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-centralConforme indicado pelo campo
gatewayClassName, este recurso é do tipoGatewayClassgke-l7-global-external-managed-mc, que gere o balanceamento de carga do Google Cloud externo de camada 7 e expõe a aplicação de vários clustersImplemente a
HTTPRoutedenominada 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-centralQuando implementa o recurso
HTTPRoute, cria um recurso de balanceamento de carga do Google Cloud de camada 7 externo e expõe o front-endServiceImportsuportado pelos serviços de front-end executados nos clusters std-west, auto-east e auto-central.O diagrama seguinte mostra como, após a implementação do gateway de vários clusters, o tráfego pode ser encaminhado para qualquer um dos serviços de vários clusters de front-end em qualquer um dos três clusters de aplicações:
Aguarde que o balanceador de carga esteja pronto com um endereço IP externo aprovisionado antes de avançar para o passo seguinte. Pode demorar até 10 minutos para o endereço IP ser atribuído. Pode monitorizar o progresso através de um ciclo 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"O resultado é semelhante ao seguinte exemplo:
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop REGION: IP_ADDRESS: 34.149.29.176 IP_PROTOCOL: TCP TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gopQuando 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 através da aplicação dos manifestos external-http-gateway.yaml e public-frontend-route.yaml:
export EXTERNAL_LB_IP=$(kubectl --context=config-central \ -n onlineboutique get gateway external-http \ -o=jsonpath='{.status.addresses[0].value}')Quando envia um pedido ao equilibrador de carga com os cabeçalhos adequados, este devolve o conteúdo HTML publicado pelo serviço de front-end. Por exemplo, uma vez que configurou o recurso
HTTPRoutepara mapear o nome do anfitriãostore.example.compara o front-endServiceImport, tem de fornecer o cabeçalhoHOSTquando fizer o pedido HTTP. Se o seguinte exemplo de curl devolver um erro, aguarde alguns minutos e tente novamente:curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodO resultado bem-sucedido do comando curl é semelhante ao seguinte exemplo:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-f<br/> <b>Pod: </b>frontend-7c7d596ddc-jdh8fCrie os pods de cliente:
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'Depois de os pods estarem em execução, use um comando curl para enviar um pedido para o ponto final do balanceador de carga a partir do cliente
Podno cluster std-west e reveja 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 PodO resultado bem-sucedido do comando curl é semelhante ao seguinte exemplo:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Execute o mesmo pedido curl a partir do cliente
Podno cluster auto-east e veja 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 PodO resultado bem-sucedido do comando curl é semelhante ao seguinte exemplo:
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsComo se trata de um cluster do Autopilot, o cluster pode ter de aprovisionar recursos adicionais para agendar o
Pod. Se vir um resultado semelhante ao exemplo seguinte, aguarde um momento e tente novamente:Error from server (BadRequest): pod client-east does not have a host assignedExecute o comando curl a partir do cliente
Podno 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 PodO resultado bem-sucedido do comando curl é semelhante ao seguinte exemplo:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4Estes resultados confirmam que o tráfego é encaminhado para os pods correspondentes nas localizações mais próximas da origem do pedido.
Execute o comando curl a partir do client-west
Podno cluster std-west e veja que o resultado é proveniente do front-end em 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 PodO resultado bem-sucedido do comando curl é semelhante ao seguinte exemplo:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Elimine o frontend
Deploymentno cluster std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-westO resultado é semelhante ao seguinte exemplo:
deployment.apps "frontend" deletedEnvie outro pedido a partir do client-west
Podno cluster std-west. Deve ver uma resposta de um dos frontends restantesDeploymentslocalizados 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 PodO resultado semelhante ao exemplo seguinte indica a localização do
Podsaudável que responde a este pedido:<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4ou
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsExecute o comando várias vezes para ver resultados alternados.
Crie e configure clusters do GKE
Para demonstrar o padrão de vários clusters neste guia, usa três clusters de aplicações em três regiões da nuvem separadas e um cluster para alojar a configuração dos recursos do Gateway. Regista todos os clusters na frota associada ao seu projeto. Um projeto só pode ter uma única frota associada. Google Cloud Este projeto é conhecido como o projeto de anfitrião da frota.
Implemente a Online Boutique no GKE Standard
No primeiro passo da implementação de demonstração, implementa o conjunto completo de serviços da aplicação Online Boutique no cluster padrão do GKE std-west em us-west1.
Agora, tem uma versão de zona única da Online Boutique em execução em us-west1-a.
Também pode usar um navegador de Internet para navegar para o IP externo atribuído ao serviço frontend-external LoadBalancer para aceder à aplicação e observar o respetivo comportamento. Esta implementação única inicial é apresentada no diagrama seguinte:
Exporte o cartservice como um serviço em vários clusters
Nesta secção, começa a adicionar elementos de elevada disponibilidade à aplicação. Exporta o cartservice de back-end como um serviço de vários clusters para os clusters do GKE Autopilot.
Aplique manifestos de aplicações para o padrão de vários clusters
Nesta secção, aplica dois manifestos organizados para implementar o padrão de vários clusters. Estes manifestos contêm partes selecionadas do ficheiro kubernetes-manifests.yaml que aplicou anteriormente ao cluster std-west:
Um Pod que é executado em qualquer cluster na frota pode aceder a um Service exportado enviando um pedido para o URI ClusterSet desse serviço no formato SERVICE_NAME.NAMESPACE.svc.clusterset.local. Por exemplo, o frontend
Deployments em todos os três clusters de exemplo consegue consumir o
cartservice, no espaço de nomes onlineboutique, fazendo um pedido para
cartservice.onlineboutique.svc.clusterset.local.
Por este motivo, em cada manifesto, o nome de anfitrião do cartservice foi atualizado para o respetivo URI ClusterSet. Este passo é fundamental. Se o nome do anfitrião deste serviço não for atualizado, o serviço de front-end pede ao kube-dns cartservice em vez de cartservice.onlineboutique.svc.clusterset.local. Este comportamento
resultaria em erros HTTP Status 500 em clusters onde não está disponível uma versão local do
cartservice e faria com que os pods frontend ficassem em mau estado.
Agora, tem o front-end Deployment, Service e ServiceExport ativos nos clusters std-west, auto-east e auto-central. Também tem serviços de middleware da Online Boutique em execução local em cada cluster. No entanto, o tráfego externo continua a ser encaminhado apenas para o Service que é executado no cluster inicial em us-west1, conforme mostrado no diagrama seguinte:
Ative e configure gateways de vários clusters
Nesta secção, encaminha o tráfego para e equilibra a carga do tráfego externo em todos os front-ends nos três clusters. Para alcançar esta configuração, usa gateways de vários clusters (MCG). Estes passos para configurar o MCG seguem as orientações descritas mais detalhadamente no artigo Ativar gateways de vários clusters.
Nestes passos, usa o cluster config-central para alojar a configuração para recursos do gateway.
Teste o comportamento de encaminhamento multirregião da aplicação
Uma das funcionalidades poderosas obtidas através da utilização de serviços em vários clusters e gateways em vários clusters é que os pedidos externos são encaminhados para o cluster geograficamente mais próximo.
Para testar o comportamento multirregional da aplicação, gere tráfego proveniente das várias regiões onde tem clusters implementados. Crie três pequenos pods, um em cada um dos clusters de publicação (std-west, auto-east e auto-central), que pode usar para enviar pedidos HTTP para o ponto final do balanceador de carga. Os resultados permitem-lhe ver qual o front-end Pod que responde.
Teste a resiliência multirregião da aplicação
Além do encaminhamento de tráfego eficiente, a execução dos seus serviços em várias regiões oferece resiliência no caso raro, mas ainda possível, de falha de infraestrutura.
Teste o comportamento eliminando o frontend Deployments em clusters específicos
e, em seguida, tente novamente o comando curl do cliente Pod nessas regiões. Observe
que a aplicação ainda está disponível e veja a localização do Pod
que responde ao pedido.
Com esta implementação de demonstração, adicionou elementos de resiliência e distribuição geográfica à aplicação Online Boutique através de serviços multicluster e gateways multicluster. Os pedidos são encaminhados para a região geográfica mais próxima e, mesmo que os serviços de front-end ou middleware numa região tenham problemas, o utilizador final continua a poder usar a aplicação com êxito.
Limpar
Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
O que se segue?
- Leia mais sobre a Google Cloud gestão de frotas e vários clusters.
- Saiba como registar um cluster, incluindo clusters do GKE, numa Google Cloud frota.
- Explore mais sobre a API Kubernetes Gateway e o GKE Gateway.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.