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)

Last reviewed 2022-12-15 UTC

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

Arquitetura de dois clusters idênticos e um cluster de plano de controle.

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. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

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.

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
Make sure that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

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 e us-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 arquivo kubeconfig:

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 arquivo kubeconfig, é 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 de Identidade da carga de trabalho recomendada, que permite uma conta de serviço do Kubernetes no cluster do GKE para atuar 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 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.

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 clusters blue e green:

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

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

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

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.

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

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 cluster ingress-config:

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

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

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

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.

É 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 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?.
Fazer upgrade do nó control plane para o cluster blue:
```
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 cluster blue 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 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.

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.

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.
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 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 e green:

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

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:
```
*&lt;null&gt;*
```
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.
Go to Manage resources
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.

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)

Arquitetura

Objetivos

Custos

Antes de começar

Configure o ambiente

Criar e registrar clusters do GKE no Hub

Criar clusters do GKE

Registrar clusters do GKE em uma frota

Implantar um aplicativo de amostra nos clusters azul e verde

Configurar o Ingress de vários clusters

Configurar o gerador de carga

Monitorar tráfego

Drenar e fazer upgrade do cluster blue

Drenar o cluster azul

Fazer upgrade do cluster blue

Adicionar o cluster blue ao pool de balanceamento de carga

Limpar

Excluir os clusters

Exclua o projeto

A seguir

Drenar e fazer upgrade do cluster `blue`

Fazer upgrade do cluster `blue`

Adicionar o cluster `blue` ao pool de balanceamento de carga