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:
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:
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:
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.
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
Servicesde 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.
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.
No Console do Google Cloud, ative o Cloud Shell.
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}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 enableOs 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.Verifique se os serviços de vários clusters mostram o estado ACTIVE:
gcloud container fleet multi-cluster-services describeA 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 state, 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.
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 \ --asyncA 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-poolao criar esses clusters como faz com os clusters padrão do GKE.Aguarde até que o STATUS dos clusters seja alterado de PROVISIONING para RUNNING. 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: PROVISIONINGDepois que todos os clusters estiverem no estado RUNNING, pressione
CTRL-Cpara interromper o comando.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 [...]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.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 $PROJECTPara cada comando, a saída é semelhante ao exemplo a seguir:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.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-centralNeste 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 us-west1.
Crie o namespace onlineboutique em std-west:
kubectl create namespace onlineboutique --context std-westA resposta será semelhante a:
namespace/onlineboutique createdClone 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`Implante o Online Boutique em std-west. Esse processo cria
DeploymentseServicespara 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-westAguarde o serviço
LoadBalancerreceber 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 43sQuando o
Serviceestiver pronto, a coluna EXTERNAL-IP vai exibir o endereço IP público do balanceador de carga.Depois que o
Serviceestiver 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 PodA 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:
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.
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-centralPara cada comando, a saída é semelhante ao exemplo a seguir:
namespace/onlineboutique createdExporte cartservice do cluster std-west para todos os outros clusters no
ClusterSet. O objetoServiceExportregistra 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,ServiceeServiceExport. - O segundo manifesto é usado para implantar o middleware
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice) a todas as regiões que tem um front-end 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.
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-migrationAplique 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-centralAplique 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:
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.
Confirme se todos os clusters foram registrados na frota:
gcloud container fleet memberships list --project=$PROJECTO 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-612f14810012Instale 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,GatewayeHTTPRoute. 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.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=$PROJECTA 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 state, consulte Solução de problemas e operações para a entrada Multicluster.
Confirme se
GatewayClassesestá disponível no cluster config-central:kubectl get gatewayclasses --context=config-centralA 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 16sDiferentes recursos do
GatewayClasstêm recursos distintos. Para mais informações sobre quando usar qual tipo, consulte Recursos da GatewayClass.Implante o recurso 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, esse recurso é deGatewayClassgke-l7-global-external-managed-mc, que gerencia o Cloud Load Balancing da camada 7 e expõe o aplicativo de vários clustersImplante o
HTTPRoutedenominado 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 você implanta o
HTTPRoute, é criado um recurso externo de camada 7 do Cloud Load Balancing e é exposto o front-endServiceImportcom suporte dos serviços de front-end que são executados nos clusters std-west, auto-east e auto-central.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:
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-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 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}')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
HTTPRoutepara mapear o nome do hoststore.example.comno front-endServiceImport, forneça oHOSTao 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 PodA 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, auto-east e
auto-central), 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.
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'Quando os pods estiverem em execução, use um comando curl para enviar uma solicitação ao endpoint do balanceador de carga do cliente
Podno 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 PodA 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-trzc4Execute a mesma solicitação curl do
Poddo 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 PodA 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-scdwsComo 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 assignedExecute o curl no
Poddo 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 PodA 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-x2fv4Esses 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.
Execute o comando curl no client-west
Podno 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 PodA 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-trzc4Exclua o frontend
Deploymentno cluster std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-westA resposta será semelhante a:
deployment.apps "frontend" deletedEnvie outra solicitação da client-west
Podno cluster std-west. Você vai ver uma resposta de um dosDeploymentsdo 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 PodUma saída semelhante ao seguinte exemplo indica a localização da
Podem 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-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.
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.
- No Console do Google Cloud, acesse a página Gerenciar recursos.
- Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
- Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.
A seguir
- Leia mais sobre o gerenciamento de frotas e vários clusters do Google Cloud.
- Saiba como registrar um cluster, incluindo clusters do GKE Enterprise, em uma frota do Google Cloud.
- Saiba mais sobre a API Kubernetes Gateway e o gateway do GKE.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.