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

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.

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'

    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.

    Gráfico de métricas da linha do tempo mostrando o tráfego indo aos dois back-ends.

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.

    Tráfego que flui apenas para o cluster &quot;verde&quot;.

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.

  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 Google Cloud console. 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.

    Ambos os clusters estão recebendo tráfego.

    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.