Como fazer upgrade de um ambiente do GKE de vários clusters com a entrada de vários clusters (MCI, na sigla em inglês)

Autopilot Standard

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ê vai usar os seguintes componentes faturáveis do Google Cloud:

• GKE
• Networking
• Cloud Load Balancing

Para gerar uma estimativa de custo baseada na sua projeção de uso, utilize a calculadora de preços.

Novos usuários do Google Cloud podem estar qualificados para um teste sem custo financeiro.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Para mais informações, consulte Limpeza.

Antes de começar

1. 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.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Verify that billing is enabled for your Google Cloud project.

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

   Activate Cloud Shell

5. Defina seu projeto padrão:

   export PROJECT=$(gcloud info --format='value(config.project)')
   gcloud config set project ${PROJECT}
   

6. 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

1. 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
   

2. 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 Hub.

Criar clusters do GKE

1. No Cloud Shell, para criar três clusters do GKE:

   gcloud container clusters create ingress-config --location 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 --location 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 --location 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 e us-west1-c. Para mais informações sobre regiões e zonas, consulte Geografia e regiões.

2. 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
   

3. Criar um arquivo kubeconfig (em inglês) e conectar a todos os clusters para gerar entradas no arquivo kubeconfig:

   touch gke-upgrade-kubeconfig
   export KUBECONFIG=gke-upgrade-kubeconfig
   gcloud container clusters get-credentials ingress-config \
       --location us-west1-a --project ${PROJECT}
   gcloud container clusters get-credentials blue --location us-west1-b \
       --project ${PROJECT}
   gcloud container clusters get-credentials green --location 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 arquivo kubeconfig, é possível alternar rapidamente o contexto entre os clusters.

4. 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
   

5. 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 recomendada de Federação de identidade da carga de trabalho para GKE 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.

1. 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
   

2. 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
   

3. Configurar o cluster ingress-config como o cluster de configuração do Ingress em vários clusters ativando o recurso multiclusteringress por meio do Hub:

   gcloud container fleet ingress enable --config-membership=ingress-config
   

   O comando anterior adiciona MulticlusterIngress e MulticlusterService CRDs (definições de recursos personalizados) ao cluster ingress-config. Esse comando leva alguns minutos para ser concluído. Aguarde antes de prosseguir para a próxima etapa.

4. 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'
   

   Observação: esse recurso não estará pronto para uso até que o cluster de configuração tenha um status OK. Se code: OK não aparecer depois de alguns minutos, acesse a seção de solução de problemas.

   Para sair do comando watch, pressione Control+C.

Implantar um aplicativo de amostra nos clusters azul e verde

1. No Cloud Shell, implante o app de amostra whereami nos clusters blue e green:

   kubectl --context ${BLUE_CLUSTER} apply -f ${WORKDIR}/application-manifests
   kubectl --context ${GREEN_CLUSTER} apply -f ${WORKDIR}/application-manifests
   

2. Aguarde alguns minutos e verifique se todos os pods nos clusters blue e green têm um status Running:

   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.

1. No Cloud Shell, implante o recurso MulticlusterIngress no cluster ingress-config:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mci.yaml
   

   A saída é esta:

   multiclusteringress.networking.gke.io/whereami-mci created
   

2. Implante o recurso MulticlusterService no cluster ingress-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
   

3. 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ção serviceName apontar para um recurso MulticlusterService.

   • 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ção clusters. O valor clusters é a lista de clusters registrados em que o recurso MulticlusterService foi criado.

   • Verifique se o recurso MulticlusterIngress criou um balanceador de carga com um serviço de back-end que aponta para o recurso MulticlusterService:

     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, pressione Control+C.

4. 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
   

5. 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"
   }
   

6. Execute o comando curl repetidamente. Observe que as solicitações têm a carga balanceada entre o aplicativo whereami, que está implantado em dois clusters, blue e green.

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.

1. Configure o manifesto loadgenerator para enviar o tráfego de cliente ao Cloud Load Balancing:

   TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}
   

2. Implantar o loadgenerator no cluster ingress-config:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/loadgen-manifests
   

3. Verificar se todos os pods loadgenerator no cluster ingress-config têm o status Running:

   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 doGoogle 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 doGoogle Cloud . Primeiro, configure o monitoramento para poder monitorar os clusters à medida que drena-os para upgrades (descrito na próxima seção).

1. 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]
   

2. As métricas do Cloud Load Balancing estão disponíveis no Google Cloud console. 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"
   

3. 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 e green (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 mouseover k8s1- indicam que o grupo de endpoints de rede (NEGs) dos dois front-ends MulticlusterServices estão em execução nos clusters blue e green.

   Observação: as cores do gráfico podem não corresponder aos clusters blue e green. Pode levar alguns minutos para o tráfego ficar visível no gráfico.

   

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

1. No Cloud Shell, para atualizar o recurso MulticlusterService no cluster ingress-config:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} \
             apply -f ${WORKDIR}/multicluster-manifests/mcs-green.yaml
   

2. Verificar se você tem apenas o cluster green na especificação clusters:

   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ção clusters. Portanto, apenas o cluster green está no pool de balanceamento de carga.

3. É possível ver as métricas do Cloud Load Balancing no Google Cloud console. Gerar o URL:

   echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
   

4. 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).

1. 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.

2. Ver a lista de versões de MasterVersions disponíveis na zona:

   gcloud container get-server-config --location 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"
   ]
   

3. Ver uma lista de versões de NodeVersions disponíveis na zona:

   gcloud container get-server-config --location 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"
   ]
   

4. Defina uma variável de ambiente para uma versão MasterVersion eNodeVersion que está nas listas MasterVersions e NodeVersions e é superior à versão atual do cluster blue, 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.

   Observação: é recomendável não pular versões secundárias do cluster para evitar possíveis problemas de incompatibilidade do plano de controle ou do nó. Para mais informações, consulte Posso pular várias versões do GKE durante um upgrade de cluster?.

5. Fazer upgrade do nó control plane para o cluster blue:

   gcloud container clusters upgrade blue \
       --location 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].
   

6. Fazer upgrade dos nós no cluster blue:

   gcloud container clusters upgrade blue \
       --location=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].
   

7. 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.

1. 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
   

2. Atualizar o recurso MutliclusterService para adicionar o cluster blue novamente ao pool de balanceamento de carga:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} apply \
           -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml
   

3. Verificar se você tem os clusters blue e green 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 e green agora estão na especificação clusters.

4. As métricas do Cloud Load Balancing estão disponíveis no consoleGoogle Cloud . Gerar o URL:

   echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
   

5. 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.

   Observação: pode levar vários minutos para que o tráfego se reequilibre.

   

   Parabéns! Você fez upgrade de um cluster do GKE em uma arquitetura de vários clusters usando a entrada de vários clusters.

6. Para fazer upgrade do cluster green, repita o processo para drenar e atualizar o cluster azul, substituindo blue por green.

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 evitar cobranças é excluir o projeto Google Cloud que você criou para o tutorial. A outra opção é excluir os recursos individuais.

Excluir os clusters

1. No Cloud Shell, cancele o registro e exclua os clusters blue e green:

   gcloud container fleet memberships unregister blue --gke-cluster=us-west1-b/blue
   gcloud container clusters delete blue --location us-west1-b --quiet
   
   gcloud container fleet memberships unregister green --gke-cluster=us-west1-c/green
   gcloud container clusters delete green --location us-west1-c --quiet
   

2. Exclua o recurso MuticlusterIngress do cluster ingress-config:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} delete -f ${WORKDIR}/multicluster-manifests/mci.yaml
   

   Esse comando exclui os recursos do Cloud Load Balancing do projeto.

3. 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 --location us-west1-a --quiet
   

4. Verificar se todos os clusters foram excluídos:

   gcloud container clusters list
   

   A saída é esta:

   *<null>*
   

5. Redefinir o arquivo kubeconfig:

   unset KUBECONFIG
   

6. Remover a pasta WORKDIR:

   cd ${HOME}
   rm -rf ${WORKDIR}
   

Excluir o projeto

Cuidado: a exclusão de um projeto tem os seguintes efeitos:
• Tudo no projeto é excluído. Se você tiver usado um projeto atual para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos nele.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um ID do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

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

A seguir

• 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.