Neste tutorial, mostramos como fazer upgrade de um ambiente do Google Kubernetes Engine (GKE) de vários clusters usando o Ingress de vários clusters. Este tutorial é uma continuação do documento sobre upgrades do GKE de vários clusters usando o Ingress de vários clusters, que explica melhor o processo, a arquitetura e os termos. Recomendamos que você leia o documento conceitual antes deste tutorial.
Para uma comparação detalhada entre Ingress de vários clusters (MCI), Gateway de vários clusters (MCG) e balanceador de carga com grupos de endpoints de rede independentes (LB e NEGs independentes), consulte Escolher sua API de balanceamento de carga de vários clusters para o GKE.
Este documento é destinado a administradores do Google Cloud responsáveis pela manutenção de frotas para clusters do GKE.
Recomendamos o upgrade automático dos clusters do GKE. O upgrade automático é uma maneira totalmente gerenciada de fazer com que os clusters (plano de controle e nós) sejam atualizados automaticamente em uma programação de lançamento determinada pelo Google Cloud. Isso não requer intervenção do operador. No entanto, se você quiser ter mais controle sobre como e quando fazer upgrade dos clusters, veja as orientações neste tutorial sobre o método de fazer upgrade de vários clusters que executam aplicativos em todos os clusters. Em seguida, ele usa a Entrada multicluster para drenar um cluster por vez antes do upgrade.
Arquitetura
Neste tutorial, usamos a arquitetura a seguir. Há um total de três
clusters: dois clusters (blue
e green
) atuam como clusters idênticos com o
mesmo app implantado e um cluster (ingress-config
) atua como o cluster de plano de
controle que configura o Ingress. Neste tutorial, você implantará um
app de exemplo em dois clusters de apps (blue
e green
).
Objetivos
- Criar três clusters do GKE e registrá-los como uma frota
- Configurar um cluster do GKE (
ingress-config
) como o cluster de configuração central. - Implantar um aplicativo de amostra nos outros clusters do GKE.
- Configurar o Ingress de vários clusters para enviar o tráfego do cliente ao app executado em ambos os clusters do aplicativo.
- Configure um gerador de carga para o app e configure o monitoramento.
- Remover (drenar) um cluster de app do Ingress de vários clusters e fazer upgrade do cluster drenado.
- Enviar o tráfego de volta ao cluster atualizado usando a Entrada de vários clusters.
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.
Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.
Antes de começar
- Este tutorial requer a
configuração do Ingress de vários clusters
para que o seguinte seja configurado:
- Dois ou mais clusters com os mesmos apps, como namespaces, implantações e serviços, executados em todos os clusters.
- A desabilitação do upgrade automático de todos os clusters.
- Os clusters nativos de VPC que usam intervalos de endereços IP de alias.
- Ativação do balanceamento de carga HTTP (o padrão é ativado).
gcloud --version
precisa ser 369 ou superior. As etapas de registro de cluster do GKE dependem dessa versão ou de uma superior.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
Defina seu projeto padrão:
export PROJECT=$(gcloud info --format='value(config.project)') gcloud config set project ${PROJECT}
Ativar as APIs GKE, Hub e
multiclusteringress
:gcloud services enable container.googleapis.com \ gkehub.googleapis.com \ multiclusteringress.googleapis.com \ multiclusterservicediscovery.googleapis.com
Configure o ambiente
No Cloud Shell, para clonar o repositório para conseguir os arquivos deste tutorial:
cd ${HOME} git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Criar um diretório
WORKDIR
:cd kubernetes-engine-samples/networking/gke-multicluster-upgrade-mci/ export WORKDIR=`pwd`
Criar e registrar clusters do GKE no Hub
Nesta seção, você cria três clusters do GKE e os registra no GKE Enterprise Hub.
Criar clusters do GKE
No Cloud Shell, para criar três clusters do GKE:
gcloud container clusters create ingress-config --zone us-west1-a \ --release-channel=None --no-enable-autoupgrade --num-nodes=4 \ --enable-ip-alias --workload-pool=${PROJECT}.svc.id.goog --quiet --async gcloud container clusters create blue --zone us-west1-b --num-nodes=3 \ --release-channel=None --no-enable-autoupgrade --enable-ip-alias \ --workload-pool=${PROJECT}.svc.id.goog --quiet --async gcloud container clusters create green --zone us-west1-c --num-nodes=3 \ --release-channel=None --no-enable-autoupgrade --enable-ip-alias \ --workload-pool=${PROJECT}.svc.id.goog --quiet
Para os fins deste tutorial, crie os clusters em uma única região, em três zonas diferentes:
us-west1-a
,us-west1-b
eus-west1-c
. Para mais informações sobre regiões e zonas, consulte Geografia e regiões.Aguarde alguns minutos até que todos os clusters sejam criados. Para verificar se eles estão sendo executados:
gcloud container clusters list
O resultado será assim:
NAME: ingress-config LOCATION: us-west1-a MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 35.233.186.135 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 4 STATUS: RUNNING NAME: blue LOCATION: us-west1-b MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 34.82.35.222 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 3 STATUS: RUNNING NAME: green LOCATION: us-west1-c MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 35.185.204.26 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 3 STATUS: RUNNING
Criar um arquivo
kubeconfig
(em inglês) e conectar a todos os clusters para gerar entradas no arquivokubeconfig
:touch gke-upgrade-kubeconfig export KUBECONFIG=gke-upgrade-kubeconfig gcloud container clusters get-credentials ingress-config \ --zone us-west1-a --project ${PROJECT} gcloud container clusters get-credentials blue --zone us-west1-b \ --project ${PROJECT} gcloud container clusters get-credentials green --zone us-west1-c \ --project ${PROJECT}
Use o arquivo
kubeconfig
para criar a autenticação dos clusters com um usuário e um contexto para cada cluster. Depois de criar o arquivokubeconfig
, é possível alternar rapidamente o contexto entre os clusters.Verificar se você tem três clusters no arquivo
kubeconfig
:kubectl config view -ojson | jq -r '.clusters[].name'
A saída é esta:
gke_gke-multicluster-upgrades_us-west1-a_ingress-config gke_gke-multicluster-upgrades_us-west1-b_blue gke_gke-multicluster-upgrades_us-west1-c_green
Receber contexto para os três clusters para uso posterior:
export INGRESS_CONFIG_CLUSTER=$(kubectl config view -ojson | jq \ -r '.clusters[].name' | grep ingress-config) export BLUE_CLUSTER=$(kubectl config view -ojson | jq \ -r '.clusters[].name' | grep blue) export GREEN_CLUSTER=$(kubectl config view -ojson | jq \ -r '.clusters[].name' | grep green) echo -e "${INGRESS_CONFIG_CLUSTER}\n${BLUE_CLUSTER}\n${GREEN_CLUSTER}"
A saída é esta:
gke_gke-multicluster-upgrades_us-west1-a_ingress-config gke_gke-multicluster-upgrades_us-west1-b_blue gke_gke-multicluster-upgrades_us-west1-c_green
Registrar clusters do GKE em uma frota
O registro dos clusters em uma frota permite operar os clusters do Kubernetes em ambientes híbridos. Os clusters registrados nas frotas podem usar recursos avançados do GKE, como a Entrada em vários clusters. Para registrar um cluster do GKE em uma frota, use uma conta de serviço do Google Cloud diretamente ou use a abordagem Federação de identidade da carga de trabalho para GKE recomendada, que permite que uma conta de serviço do Kubernetes no cluster do GKE atue como uma conta de serviço do Identity and Access Management.
Registre os três clusters como uma frota:
gcloud container fleet memberships register ingress-config \ --gke-cluster=us-west1-a/ingress-config \ --enable-workload-identity gcloud container fleet memberships register blue \ --gke-cluster=us-west1-b/blue \ --enable-workload-identity gcloud container fleet memberships register green \ --gke-cluster=us-west1-c/green \ --enable-workload-identity
Verificar se os clusters estão registrados:
gcloud container fleet memberships list
O resultado será assim:
NAME: blue EXTERNAL_ID: 401b4f08-8246-4f97-a6d8-cf1b78c2a91d NAME: green EXTERNAL_ID: 8041c36a-9d42-40c8-a67f-54fcfd84956e NAME: ingress-config EXTERNAL_ID: 65ac48fe-5043-42db-8b1e-944754a0d725
Configurar o cluster
ingress-config
como o cluster de configuração do Ingress em vários clusters ativando o recursomulticlusteringress
por meio do Hub:gcloud container fleet ingress enable --config-membership=ingress-config
O comando anterior adiciona
MulticlusterIngress
eMulticlusterService
CRDs (definições de recursos personalizados) ao clusteringress-config
. Esse comando leva alguns minutos para ser concluído. Aguarde antes de prosseguir para a próxima etapa.Verifique se o cluster
ingress-cluster
foi configurado com êxito para a Entrada em vários clusters:watch gcloud container fleet ingress describe
Aguarde até que a saída seja semelhante a esta:
createTime: '2022-07-05T10:21:40.383536315Z' membershipStates: projects/662189189487/locations/global/memberships/blue: state: code: OK updateTime: '2022-07-08T10:59:44.230329189Z' projects/662189189487/locations/global/memberships/green: state: code: OK updateTime: '2022-07-08T10:59:44.230329950Z' projects/662189189487/locations/global/memberships/ingress-config: state: code: OK updateTime: '2022-07-08T10:59:44.230328520Z' name: projects/gke-multicluster-upgrades/locations/global/features/multiclusteringress resourceState: state: ACTIVE spec: multiclusteringress: configMembership: projects/gke-multicluster-upgrades/locations/global/memberships/ingress-config state: state: code: OK description: Ready to use updateTime: '2022-07-08T10:57:33.303543609Z' updateTime: '2022-07-08T10:59:45.247576318Z'
Para sair do comando
watch
, pressione Control+C.
Implantar um aplicativo de amostra nos clusters azul e verde
No Cloud Shell, implante o app de amostra
whereami
nos clustersblue
egreen
:kubectl --context ${BLUE_CLUSTER} apply -f ${WORKDIR}/application-manifests kubectl --context ${GREEN_CLUSTER} apply -f ${WORKDIR}/application-manifests
Aguarde alguns minutos e verifique se todos os pods nos clusters
blue
egreen
têm um statusRunning
:kubectl --context ${BLUE_CLUSTER} get pods kubectl --context ${GREEN_CLUSTER} get pods
O resultado será assim:
NAME READY STATUS RESTARTS AGE whereami-deployment-756c7dc74c-zsmr6 1/1 Running 0 74s NAME READY STATUS RESTARTS AGE whereami-deployment-756c7dc74c-sndz7 1/1 Running 0 68s.
Configurar o Ingress de vários clusters
Nesta seção, você cria uma Entrada em vários clusters que envia tráfego para o aplicativo em execução nos clusters blue
e green
. Use o
Cloud Load Balancing
para criar um balanceador de carga que usa o app whereami
nos clusters blue
e
green
como back-ends. Para criar o balanceador de carga, você precisa de dois
recursos: um MultiClusterIngress
e um ou mais MultiClusterServices
.
Os objetos MultiClusterIngress
e MultiClusterService
são análogos de vários clusters
dos recursos Ingress e Service do Kubernetes usados no
contexto de cluster único.
No Cloud Shell, implante o recurso
MulticlusterIngress
no clusteringress-config
:kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mci.yaml
A saída é esta:
multiclusteringress.networking.gke.io/whereami-mci created
Implante o recurso
MulticlusterService
no clusteringress-config
:kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml
A saída é esta:
multiclusterservice.networking.gke.io/whereami-mcs created
Para comparar os dois recursos, faça o seguinte:
Inspecione o recurso
MulticlusterIngress
:kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusteringress -o yaml
A saída contém o seguinte:
spec: template: spec: backend: serviceName: whereami-mcs servicePort: 8080
O recurso
MulticlusterIngress
é semelhante ao recurso Ingress do Kubernetes, exceto pelo fato de a especificaçãoserviceName
apontar para um recursoMulticlusterService
.Inspecione o recurso
MulticlusterService
:kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice -o yaml
A saída contém o seguinte:
spec: clusters: - link: us-west1-b/blue - link: us-west1-c/green template: spec: ports: - name: web port: 8080 protocol: TCP targetPort: 8080 selector: app: whereami
O recurso
MulticlusterService
é semelhante a um recurso Service do Kubernetes, mas tem uma especificaçãoclusters
. O valorclusters
é a lista de clusters registrados em que o recursoMulticlusterService
foi criado.Verifique se o recurso
MulticlusterIngress
criou um balanceador de carga com um serviço de back-end que aponta para o recursoMulticlusterService
:watch kubectl --context ${INGRESS_CONFIG_CLUSTER} \ get multiclusteringress -o jsonpath="{.items[].status.VIP}"
Isso pode levar até 10 minutos. Aguarde até que a saída seja semelhante a esta:
34.107.246.9
Para sair do comando
watch
, pressioneControl+C
.
Para ver o endereço IP virtual do Cloud Load Balancing no Cloud Shell:
export GCLB_VIP=$(kubectl --context ${INGRESS_CONFIG_CLUSTER} \ get multiclusteringress -o json | jq -r '.items[].status.VIP') \ && echo ${GCLB_VIP}
O resultado será assim:
34.107.246.9
Use
curl
para acessar o balanceador de carga e o aplicativo implantado:curl ${GCLB_VIP}
O resultado será assim:
{ "cluster_name": "green", "host_header": "34.107.246.9", "pod_name": "whereami-deployment-756c7dc74c-sndz7", "pod_name_emoji": "😇", "project_id": "gke-multicluster-upgrades", "timestamp": "2022-07-08T14:26:07", "zone": "us-west1-c" }
Execute o comando
curl
repetidamente. Observe que as solicitações têm a carga balanceada entre o aplicativowhereami
, que está implantado em dois clusters,blue
egreen
.
Configurar o gerador de carga
Nesta seção, você configurará um serviço loadgenerator
que gerará o tráfego de
cliente ao endereço IP virtual do Cloud Load Balancing. Primeiro, o tráfego será enviado aos clusters
blue
e green
porque o recurso MulticlusterService
está configurado
para enviar tráfego aos dois clusters. Mais tarde, configure o recurso MulticlusterService
para enviar tráfego a um único cluster.
Configure o manifesto
loadgenerator
para enviar o tráfego de cliente ao Cloud Load Balancing:TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}
Implantar o
loadgenerator
no clusteringress-config
:kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/loadgen-manifests
Verificar se todos os pods
loadgenerator
no clusteringress-config
têm o statusRunning
:kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods
O resultado será assim:
NAME READY STATUS RESTARTS AGE loadgenerator-5498cbcb86-hqscp 1/1 Running 0 53s loadgenerator-5498cbcb86-m2z2z 1/1 Running 0 53s loadgenerator-5498cbcb86-p56qb 1/1 Running 0 53s
Se algum dos pods não tiver o status
Running
, aguarde alguns minutos e execute o comando novamente.
Monitorar tráfego
Nesta seção, você monitora o tráfego para o app whereami
usando o
console do Google Cloud.
Na seção anterior, você configurou uma implantação loadgenerator
que simula
o tráfego do cliente acessando o app whereami
pelo
VIP do Cloud Load Balancing. É possível monitorar essas métricas no
Console do Google Cloud. Primeiro, configure o monitoramento para poder monitorar os clusters à medida que
drena-os para upgrades (descrito na próxima seção).
Crie um painel para mostrar o tráfego alcançando a Entrada em vários clusters:
export DASH_ID=$(gcloud monitoring dashboards create \ --config-from-file=dashboards/cloud-ops-dashboard.json \ --format=json | jq -r ".name" | awk -F '/' '{print $4}')
O resultado será assim:
Created [721b6c83-8f9b-409b-a009-9fdf3afb82f8]
As métricas do Cloud Load Balancing estão disponíveis no console do Google Cloud. Gerar o URL:
echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
O resultado será assim:
https://console.cloud.google.com/monitoring/dashboards/builder/721b6c83-8f9b-409b-a009-9fdf3afb82f8/?project=gke-multicluster-upgrades&timeDomain=1h"
Em um navegador, acesse o URL gerado pelo comando anterior.
O tráfego para o aplicativo de amostra vai do gerador de carga aos clusters
blue
egreen
(indicados pelas duas zonas em que os clusters estão). O gráfico de métricas da linha do tempo mostra o tráfego indo para ambos os back-ends. Os valores de mouseoverk8s1-
indicam que o grupo de endpoints de rede (NEGs) dos dois front-endsMulticlusterServices
estão em execução nos clustersblue
egreen
.
Drenar e fazer upgrade do cluster blue
Nesta seção, você drenará o cluster blue
. Drenar um cluster significa que você
o remove do pool de balanceamento de carga. Depois de drenar o cluster blue
, todo o tráfego de cliente destinado ao aplicativo vai para o cluster green
.
É possível monitorar esse processo conforme descrito na seção anterior. Após a
drenagem do cluster, é possível fazer upgrade dele. Após o upgrade,
é possível colocá-lo novamente no pool de balanceamento de carga. Repita essas etapas para fazer upgrade
do outro cluster (não mostrado neste tutorial).
Para drenar o cluster blue
, atualize o recurso MulticlusterService
no cluster ingress-cluster
e remova o cluster blue
da especificação
clusters
.
Drenar o cluster azul
No Cloud Shell, para atualizar o recurso
MulticlusterService
no clusteringress-config
:kubectl --context ${INGRESS_CONFIG_CLUSTER} \ apply -f ${WORKDIR}/multicluster-manifests/mcs-green.yaml
Verificar se você tem apenas o cluster
green
na especificaçãoclusters
:kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \ -o json | jq '.items[].spec.clusters'
A saída é esta:
[ { "link": "us-west1-c/green" } ]
Somente o cluster
green
está listado na especificaçãoclusters
. Portanto, apenas o clustergreen
está no pool de balanceamento de carga.É possível ver as métricas do Cloud Load Balancing no Console do Google Cloud. Gerar o URL:
echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
Em um navegador, acesse o URL gerado pelo comando anterior.
O gráfico mostra que apenas o cluster
green
está recebendo tráfego.
Fazer upgrade do cluster blue
Agora que o cluster blue
não está mais recebendo tráfego do cliente,
é possível fazer upgrade dele (plano de controle e nós).
No Cloud Shell, para conseguir a versão atual dos clusters:
gcloud container clusters list
O resultado será assim:
NAME: ingress-config LOCATION: us-west1-a MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 35.233.186.135 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 4 STATUS: RUNNING NAME: blue LOCATION: us-west1-b MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 34.82.35.222 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 3 STATUS: RUNNING NAME: green LOCATION: us-west1-c MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 35.185.204.26 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 3 STATUS: RUNNING
As versões do cluster podem ser diferentes dependendo de quando você concluir este tutorial.
Ver a lista de versões de
MasterVersions
disponíveis na zona:gcloud container get-server-config --zone us-west1-b --format=json | jq \ '.validMasterVersions[0:20]'
O resultado será assim:
[ "1.24.1-gke.1400", "1.23.7-gke.1400", "1.23.6-gke.2200", "1.23.6-gke.1700", "1.23.6-gke.1501", "1.23.6-gke.1500", "1.23.5-gke.2400", "1.23.5-gke.1503", "1.23.5-gke.1501", "1.22.10-gke.600", "1.22.9-gke.2000", "1.22.9-gke.1500", "1.22.9-gke.1300", "1.22.8-gke.2200", "1.22.8-gke.202", "1.22.8-gke.201", "1.22.8-gke.200", "1.21.13-gke.900", "1.21.12-gke.2200", "1.21.12-gke.1700" ]
Ver uma lista de versões de
NodeVersions
disponíveis na zona:gcloud container get-server-config --zone us-west1-b --format=json | jq \ '.validNodeVersions[0:20]'
O resultado será assim:
[ "1.24.1-gke.1400", "1.23.7-gke.1400", "1.23.6-gke.2200", "1.23.6-gke.1700", "1.23.6-gke.1501", "1.23.6-gke.1500", "1.23.5-gke.2400", "1.23.5-gke.1503", "1.23.5-gke.1501", "1.22.10-gke.600", "1.22.9-gke.2000", "1.22.9-gke.1500", "1.22.9-gke.1300", "1.22.8-gke.2200", "1.22.8-gke.202", "1.22.8-gke.201", "1.22.8-gke.200", "1.22.7-gke.1500", "1.22.7-gke.1300", "1.22.7-gke.900" ]
Defina uma variável de ambiente para uma versão
MasterVersion
eNodeVersion
que está nas listasMasterVersions
eNodeVersions
e é superior à versão atual do clusterblue
, por exemplo:export UPGRADE_VERSION="1.22.10-gke.600"
Este tutorial usa a versão
1.22.10-gke.600
. As versões do cluster podem ser diferentes, dependendo das versões disponíveis quando você concluir este tutorial. Para mais informações sobre o upgrade, consulte Como fazer upgrade de clusters e de pools de nós.Fazer upgrade do nó
control plane
para o clusterblue
:gcloud container clusters upgrade blue \ --zone us-west1-b --master --cluster-version ${UPGRADE_VERSION}
Para confirmar o upgrade, pressione
Y
.Esse processo leva alguns minutos para ser concluído. Aguarde a conclusão do upgrade para continuar.
Após a conclusão da atualização, a saída será a seguinte:
Updated [https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
Fazer upgrade dos nós no cluster
blue
:gcloud container clusters upgrade blue \ --zone=us-west1-b --node-pool=default-pool \ --cluster-version ${UPGRADE_VERSION}
Para confirmar a atualização, pressione
Y
.Esse processo leva alguns minutos para ser concluído. Aguarde o término do upgrade do nó para continuar.
Após a conclusão do upgrade, a saída será a seguinte:
Upgrading blue... Done with 3 out of 3 nodes (100.0%): 3 succeeded...done. Updated [https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
Verificar se o upgrade do cluster
blue
foi feito:gcloud container clusters list
O resultado será assim:
NAME: ingress-config LOCATION: us-west1-a MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 35.233.186.135 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 4 STATUS: RUNNING NAME: blue LOCATION: us-west1-b MASTER_VERSION: 1.22.10-gke.600 MASTER_IP: 34.82.35.222 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.10-gke.600 NUM_NODES: 3 STATUS: RUNNING NAME: green LOCATION: us-west1-c MASTER_VERSION: 1.22.8-gke.202 MASTER_IP: 35.185.204.26 MACHINE_TYPE: e2-medium NODE_VERSION: 1.22.8-gke.202 NUM_NODES: 3 STATUS: RUNNING
Adicionar o cluster blue
ao pool de balanceamento de carga
Nesta seção, você adicionará o cluster blue
novamente ao pool de balanceamento de carga.
No Cloud Shell, verifique se a implantação do aplicativo está em execução no cluster
blue
antes de adicioná-la novamente ao pool de balanceamento de carga:kubectl --context ${BLUE_CLUSTER} get pods
O resultado será assim:
NAME READY STATUS RESTARTS AGE whereami-deployment-756c7dc74c-xdnb6 1/1 Running 0 17m
Atualizar o recurso
MutliclusterService
para adicionar o clusterblue
novamente ao pool de balanceamento de carga:kubectl --context ${INGRESS_CONFIG_CLUSTER} apply \ -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml
Verificar se você tem os clusters
blue
egreen
na especificação dos clusters:kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \ -o json | jq '.items[].spec.clusters'
A saída é esta:
[ { "link": "us-west1-b/blue" }, { "link": "us-west1-c/green" } ]
Os clusters
blue
egreen
agora estão na especificaçãoclusters
.As métricas no Cloud Load Balancing estão disponíveis no Console do Google Cloud. Gerar o URL:
echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
Em um navegador, acesse o URL gerado pelo comando anterior.
O gráfico mostra que os clusters em azul e verde estão recebendo tráfego do gerador de carga pelo balanceador de carga.
Parabéns! Você fez upgrade de um cluster do GKE em uma arquitetura de vários clusters usando a entrada de vários clusters.
Para fazer upgrade do cluster
green
, repita o processo para drenar e atualizar o cluster azul, substituindoblue
porgreen
.
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.
A maneira mais fácil de eliminar o faturamento é excluir o projeto do Google Cloud que você criou para o tutorial. A outra opção é excluir os recursos individuais.
Excluir os clusters
No Cloud Shell, cancele o registro e exclua os clusters
blue
egreen
:gcloud container fleet memberships unregister blue --gke-cluster=us-west1-b/blue gcloud container clusters delete blue --zone us-west1-b --quiet gcloud container fleet memberships unregister green --gke-cluster=us-west1-c/green gcloud container clusters delete green --zone us-west1-c --quiet
Exclua o recurso
MuticlusterIngress
do clusteringress-config
:kubectl --context ${INGRESS_CONFIG_CLUSTER} delete -f ${WORKDIR}/multicluster-manifests/mci.yaml
Esse comando exclui os recursos do Cloud Load Balancing do projeto.
Cancelar o registro e excluir o cluster
ingress-config
:gcloud container fleet memberships unregister ingress-config --gke-cluster=us-west1-a/ingress-config gcloud container clusters delete ingress-config --zone us-west1-a --quiet
Verificar se todos os clusters foram excluídos:
gcloud container clusters list
A saída é esta:
*<null>*
Redefinir o arquivo
kubeconfig
:unset KUBECONFIG
Remover a pasta
WORKDIR
:cd ${HOME} rm -rf ${WORKDIR}
Exclua o projeto
- 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.
A seguir
- Saiba mais sobre a entrada de vários clusters.
- Saiba como implantar a entrada de vários clusters nos clusters.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.