Atualizar um ambiente do GKE com vários clusters com a entrada em vários clusters

Last reviewed 2022-12-15 UTC

Autopilot Padrão

---

Este tutorial mostra como atualizar um ambiente do Google Kubernetes Engine (GKE) com vários clusters usando a entrada com vários clusters. Este tutorial é uma continuação do documento de atualizações do GKE com vários clusters usando o Multi Cluster Ingress que explica o processo, a arquitetura e os termos mais detalhadamente. Recomendamos que leia o documento de conceitos antes deste tutorial.

Para uma comparação detalhada entre o Multi Cluster Ingress (MCI), o Multi-cluster Gateway (MCG) e o balanceador de carga com grupos de pontos finais de rede autónomos (LB e NEGs autónomos), consulte o artigo Escolha a sua API de balanceamento de carga de vários clusters para o GKE.

Este documento destina-se a Google Cloud administradores responsáveis pela manutenção de frotas para clusters do GKE.

Recomendamos que atualize automaticamente os seus clusters do GKE. A atualização automática é uma forma totalmente gerida de atualizar automaticamente os seus clusters (painel de controlo e nós) de acordo com um calendário de lançamentos determinado pelaGoogle Cloud. Isto não requer intervenção do operador. No entanto, se quiser ter mais controlo sobre como e quando os clusters são atualizados, este tutorial explica um método de atualização de vários clusters em que as suas apps são executadas em todos os clusters. Em seguida, usa a entrada em vários clusters para esvaziar um cluster de cada vez antes de fazer a atualização.

Arquitetura

Este tutorial usa a seguinte arquitetura. Existem um total de três clusters: dois clusters (blue e green) atuam como clusters idênticos com a mesma app implementada, e um cluster (ingress-config) atua como o cluster do plano de controlo que configura o Multi Cluster Ingress. Neste tutorial, implementa uma app de exemplo em dois clusters de apps (clusters blue e green).

Objetivos

• Crie três clusters do GKE e registe-os como uma frota.
• Configure um cluster do GKE (ingress-config) como o cluster de configuração central.
• Implemente uma app de exemplo nos outros clusters do GKE.
• Configure a entrada em vários clusters para enviar tráfego de clientes para a app que está a ser executada em ambos os clusters de apps.
• Configure um gerador de carga para a app e configure a monitorização.
• Remova (drene) um cluster de apps do Ingress de vários clusters e atualize o cluster drenado.
• Encaminhe o tráfego de volta para o cluster atualizado através da entrada em vários clusters.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

• GKE
• Networking
• Cloud Load Balancing

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

1. Este tutorial requer que configure a entrada em vários clusters para que o seguinte esteja configurado:
   • Dois ou mais clusters com as mesmas apps, como espaços de nomes, implementações e serviços, em execução em todos os clusters.
   • A atualização automática está desativada para todos os clusters.
   • Os clusters são clusters nativos de VPC que usam intervalos de endereços IP de alias
   • Ter o balanceamento de carga HTTP ativado (ativado por predefinição).
   • gcloud --version tem de ser 369 ou superior. Os passos de registo do cluster do GKE dependem desta versão ou 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 (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 o projeto predefinido:

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

6. Ative 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, clone o repositório para obter os ficheiros deste tutorial:

   cd ${HOME}
   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   

2. Crie um diretório WORKDIR:

   cd kubernetes-engine-samples/networking/gke-multicluster-upgrade-mci/
   export WORKDIR=`pwd`
   

Crie e registe clusters do GKE no Hub

Nesta secção, cria três clusters do GKE e regista-os no GKE Hub.

Crie clusters do GKE

1. No Cloud Shell, crie 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 efeitos deste tutorial, cria os clusters numa ú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 o artigo Geografia e regiões.

2. Aguarde alguns minutos até que todos os clusters sejam criados com êxito. Certifique-se de que os clusters estão em execução:

   gcloud container clusters list
   

   O resultado é semelhante ao seguinte:

   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. Crie um ficheiro kubeconfig e associe-o a todos os clusters para gerar entradas no ficheiro 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}
   

   Usa o ficheiro kubeconfig para criar autenticação para clusters criando um utilizador e um contexto para cada cluster. Depois de criar o ficheiro kubeconfig, pode alternar rapidamente o contexto entre clusters.

4. Confirme que tem três clusters no ficheiro kubeconfig:

   kubectl config view -ojson | jq -r '.clusters[].name'
   

   O resultado é o seguinte:

   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. Obtenha o contexto dos três clusters para utilização 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}"
   

   O resultado é o seguinte:

   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
   

Registe clusters do GKE numa frota

O registo dos seus clusters numa frota permite-lhe operar os seus clusters do Kubernetes em ambientes híbridos. Os clusters registados em frotas podem usar funcionalidades avançadas do GKE, como o Multi Cluster Ingress. Para registar um cluster do GKE numa frota, pode usar uma conta de serviço diretamente ou usar a abordagem recomendada da federação de identidades da carga de trabalho para o GKE, que permite que uma conta de serviço do Kubernetes no seu cluster do GKE atue como uma conta de serviço de gestão de identidades e acessos. Google Cloud

1. Registe 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. Verifique se os clusters estão registados:

   gcloud container fleet memberships list
   

   O resultado é semelhante ao seguinte:

   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. Configure o cluster ingress-config como o cluster de configuração para o Multi Cluster Ingress ativando a funcionalidade multiclusteringress através do Hub:

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

   O comando anterior adiciona os MulticlusterIngress e os MulticlusterService CRDs (Custom Resource Definitions) ao cluster ingress-config. Este comando demora alguns minutos a ser concluído. Aguarde antes de avançar para o passo seguinte.

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 o resultado seja semelhante ao seguinte:

   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'
   

   Nota: esta funcionalidade não está pronta para utilização até que o cluster de configuração tenha o estado OK. Se não vir code: OK após alguns minutos, aceda à secção de resolução de problemas.

   Para sair do comando watch, prima Control+C.

Implemente uma aplicação de exemplo nos clusters azul e verde

1. No Cloud Shell, implemente a app de exemplo 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 certifique-se de que todos os pods nos clusters blue e green têm o estado Running:

   kubectl --context ${BLUE_CLUSTER} get pods
   kubectl --context ${GREEN_CLUSTER} get pods
   

   O resultado é semelhante ao seguinte:

   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.
   

Configure a entrada em vários clusters

Nesta secção, cria um Ingress de vários clusters que envia tráfego para a aplicação em execução nos clusters blue e green. Usa o Cloud Load Balancing para criar um equilibrador de carga que usa a app whereami nos clusters blue e green como back-ends. Para criar o balanceador de carga, precisa de dois recursos: um MultiClusterIngress e um ou mais MultiClusterServices. Os objetos MultiClusterIngress e MultiClusterService são análogos de vários clusters para os recursos Kubernetes Ingress e Service existentes usados no contexto de cluster único.

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

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

   O resultado é o seguinte:

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

2. Implemente o recurso MulticlusterService no cluster ingress-config:

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

   O resultado é o seguinte:

   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 de entrada do Kubernetes, exceto que a especificação serviceName aponta 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 de serviço do Kubernetes, exceto que tem uma especificação clusters. O valor clusters é a lista de clusters registados onde o recurso MulticlusterService é 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}"
     

     Esta ação pode demorar até 10 minutos. Aguarde até que o resultado seja semelhante ao seguinte:

     34.107.246.9
     

     Para sair do comando watch, prima Control+C.

4. No Cloud Shell, obtenha o VIP do Cloud Load Balancing:

   export GCLB_VIP=$(kubectl --context ${INGRESS_CONFIG_CLUSTER} \
          get multiclusteringress -o json | jq -r '.items[].status.VIP') \
          && echo ${GCLB_VIP}
   

   O resultado é semelhante ao seguinte:

   34.107.246.9
   

5. Use curl para aceder ao balanceador de carga e à aplicação implementada:

   curl ${GCLB_VIP}
   

   O resultado é semelhante ao seguinte:

   {
     "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. Repare que os pedidos estão a ser equilibrados entre a aplicação whereami implementada em dois clusters, blue e green.

Configure o gerador de carga

Nesta secção, configura um serviço loadgenerator que gera tráfego de cliente para o VIP do Cloud Load Balancing. Primeiro, o tráfego é enviado para os clusters blue e green porque o recurso MulticlusterService está configurado para enviar tráfego para ambos os clusters. Posteriormente, configura o recurso MulticlusterService para enviar tráfego para um único cluster.

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

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

2. Implemente o loadgenerator no cluster ingress-config:

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

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

   kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods
   

   O resultado é semelhante ao seguinte:

   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 estado Running, aguarde alguns minutos e, em seguida, execute o comando novamente.

Monitorizar o tráfego

Nesta secção, monitoriza o tráfego para a app whereami através da consolaGoogle Cloud .

Na secção anterior, configurou uma implementação loadgenerator que simula o tráfego de clientes acedendo à app whereami através do VIP do Cloud Load Balancing. Pode monitorizar estas métricas através da Google Cloud consola. Primeiro, configura a monitorização para poder monitorizar à medida que esvazia os clusters para atualizações (descrito na secção seguinte).

1. Crie um painel de controlo para mostrar o tráfego que chega à 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 é semelhante ao seguinte:

   Created [721b6c83-8f9b-409b-a009-9fdf3afb82f8]
   

2. As métricas do Cloud Load Balancing estão disponíveis na Google Cloud consola. Gere o URL:

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

   O resultado é semelhante ao seguinte:

   https://console.cloud.google.com/monitoring/dashboards/builder/721b6c83-8f9b-409b-a009-9fdf3afb82f8/?project=gke-multicluster-upgrades&timeDomain=1h"
   

3. Num navegador, aceda ao URL gerado pelo comando anterior.

   O tráfego para a aplicação de exemplo está a ir do gerador de carga para os clusters blue e green (indicado pelas duas zonas em que os clusters se encontram). O gráfico de métricas da cronologia mostra o tráfego que se dirige a ambos os back-ends.Os valores k8s1- ao passar o cursor do rato indicam que o grupo de pontos finais da rede (NEG) para os dois front-ends MulticlusterServices está a ser executado nos clusters blue e green.

   Nota: as cores do gráfico podem não corresponder aos clusters blue e green. O tráfego pode demorar vários minutos a ficar visível no gráfico.

   

Esvazie e atualize o cluster blue

Nesta secção, esvazia o cluster blue. Esvaziar um cluster significa que o remove do conjunto de balanceamento de carga. Depois de esgotar o cluster blue, todo o tráfego de clientes destinado à aplicação é encaminhado para o cluster green. Pode monitorizar este processo conforme descrito na secção anterior. Depois de esvaziar o cluster, pode atualizá-lo. Após a atualização, pode voltar a colocá-lo no conjunto de balanceamento de carga. Repete estes passos para atualizar o outro cluster (não apresentado neste tutorial).

Para esgotar o cluster blue, atualize o recurso MulticlusterService no cluster ingress-cluster e remova o cluster blue da especificação clusters.

Esvazie o conjunto azul

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

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

2. Verifique se tem apenas o cluster green na clustersespecificação:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
           -o json | jq '.items[].spec.clusters'
   

   O resultado é o seguinte:

   [
     {
       "link": "us-west1-c/green"
     }
   ]
   

   Apenas o cluster green está listado na especificação clusters, pelo que apenas o cluster green está no conjunto de equilíbrio de carga.

3. Pode ver as métricas do Cloud Load Balancing na Google Cloud consola. Gere o URL:

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

4. Num navegador, aceda ao URL gerado a partir do comando anterior.

   O gráfico mostra que apenas o cluster green está a receber tráfego.

   

Atualize o cluster blue

Agora que o cluster blue já não está a receber tráfego de clientes, pode atualizar o cluster (painel de controlo e nós).

1. No Cloud Shell, obtenha a versão atual dos clusters:

   gcloud container clusters list
   

   O resultado é semelhante ao seguinte:

   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 consoante a data em que concluir este tutorial.

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

   gcloud container get-server-config --location us-west1-b --format=json | jq \
   '.validMasterVersions[0:20]'
   

   O resultado é semelhante ao seguinte:

   [
     "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. Obtenha uma lista das versões NodeVersions disponíveis na zona:

   gcloud container get-server-config --location us-west1-b --format=json | jq \
   '.validNodeVersions[0:20]'
   

   O resultado é semelhante ao seguinte:

   [
     "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 e NodeVersion que esteja nas listas MasterVersions e NodeVersions e seja 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 consoante as versões disponíveis quando concluir este tutorial. Para mais informações sobre a atualização, consulte o artigo Atualizar clusters e conjuntos de nós.

   Nota: recomendamos que não ignore versões secundárias do cluster para evitar potenciais problemas de incompatibilidade do plano de controlo ou do nó. Para mais informações, consulte o artigo Posso ignorar várias versões do GKE durante uma atualização do cluster?.

5. Atualize o nó control plane para o cluster blue:

   gcloud container clusters upgrade blue \
       --location us-west1-b --master --cluster-version ${UPGRADE_VERSION}
   

   Para confirmar a atualização, prima Y.

   Este processo demora alguns minutos a ser concluído. Aguarde até que a atualização esteja concluída antes de continuar.

   Após a conclusão da atualização, a saída é a seguinte:

   Updated
   [https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
   

6. Atualize os 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, prima Y.

   Este processo demora alguns minutos a ser concluído. Aguarde até que a atualização do nó esteja concluída antes de continuar.

   Após a conclusão da atualização, a saída é 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. Confirme se o cluster blue foi atualizado:

   gcloud container clusters list
   

   O resultado é semelhante ao seguinte:

   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
   

Adicione novamente o cluster blue ao conjunto de balanceamento de carga

Nesta secção, adiciona novamente o cluster blue ao conjunto de balanceamento de carga.

1. No Cloud Shell, verifique se a implementação da aplicação está a ser executada no cluster blue antes de a adicionar novamente ao conjunto de balanceamento de carga:

   kubectl --context ${BLUE_CLUSTER} get pods
   

   O resultado é semelhante ao seguinte:

   NAME                                   READY   STATUS    RESTARTS   AGE
   whereami-deployment-756c7dc74c-xdnb6   1/1     Running   0          17m
   

2. Atualize o recurso MutliclusterService para adicionar o cluster blue novamente ao conjunto de balanceamento de carga:

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

3. Verifique se tem os clusters blue e green na especificação de clusters:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
           -o json | jq '.items[].spec.clusters'
   

   O resultado é o seguinte:

   [
     {
       "link": "us-west1-b/blue"
     },
     {
       "link": "us-west1-c/green"
     }
   ]
   

   Os clusters blue e green estão agora na especificação clusters.

4. As métricas do Cloud Load Balancing estão disponíveis na Google Cloud consola. Gere o URL:

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

5. Num navegador, aceda ao URL gerado pelo comando anterior.

   O gráfico mostra que os clusters azuis e verdes estão a receber tráfego do gerador de carga através do equilibrador de carga.

   Nota: o reequilíbrio do tráfego pode demorar vários minutos.

   

   Parabéns. Atualizou com êxito um cluster do GKE numa arquitetura de vários clusters através da entrada em vários clusters.

6. Para atualizar o cluster green, repita o processo para esvaziar e atualizar o cluster azul, substituindo blue por green em todo o processo.

Limpar

Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.

A forma mais fácil de eliminar a faturação é eliminar o Google Cloud projeto que criou para o tutorial. Em alternativa, pode eliminar os recursos individuais.

Elimine os clusters

1. No Cloud Shell, anule o registo e elimine 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. Elimine o recurso MuticlusterIngress do cluster ingress-config:

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

   Este comando elimina os recursos do Cloud Load Balancing do projeto.

3. Anule o registo e elimine 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. Verifique se todos os clusters foram eliminados:

   gcloud container clusters list
   

   O resultado é o seguinte:

   *<null>*
   

5. Reponha o ficheiro kubeconfig:

   unset KUBECONFIG
   

6. Remova a pasta WORKDIR:

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

Elimine o projeto

Atenção: a eliminação de um projeto tem os seguintes efeitos:
• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar 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.

O que se segue?

• Saiba mais sobre o Multi Cluster Ingress.
• Saiba como implementar o Multi Cluster Ingress em vários clusters.
• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.