Actualiza un entorno de GKE de varios clústeres con Ingress para varios clústeres

Last reviewed 2022-12-15 UTC

Autopilot Standard

---

En este instructivo, se muestra cómo actualizar un entorno de varios clústeres de Google Kubernetes Engine (GKE) con Ingress de varios clústeres. Este instructivo es una continuación del documento acerca de la actualización de GKE de varios clústeres con Ingress de varios clústeres, en el que se explican el proceso, la arquitectura y los términos con más detalle. Te recomendamos que leas el documento conceptual antes de este instructivo.

Para obtener una comparación detallada entre Ingress de varios clústeres (MCI), la puerta de enlace de varios clústeres (MCG) y el balanceador de cargas con grupos de extremos de red independientes (LB y NEG independientes), consulta Elige tu API de balanceo de cargas de varios clústeres para GKE.

Este documento está dirigido a Google Cloud los administradores que se encargan de mantener las flotas de los clústeres de GKE.

Te recomendamos que actualices automáticamente los clústeres de GKE. Esta es una forma completamente administrada de actualizar de forma automática los clústeres (nodos y plano de control) en función de un programa de versiones determinado porGoogle Cloud. No se requiere intervención del operador. Sin embargo, si quieres tener más control para decidir cuándo y cómo deben actualizarse los clústeres, en este instructivo se explica un método de actualización de varios clústeres en el que las apps se ejecutan en cada uno de ellos. Luego, se usa Ingress de varios clústeres para vaciar un clúster a la vez antes de la actualización.

Arquitectura

En este instructivo, se usa la arquitectura siguiente. Hay un total de tres clústeres: dos (blue y green) actúan como clústeres idénticos con la misma app implementada y un tercero (ingress-config) que actúa como el clúster de plano de control que configura Ingress de varios clústeres. En este instructivo, implementarás una app de ejemplo en dos clústeres de app (el blue y green).

Objetivos

• Crear tres clústeres de GKE y registrarlos como una flota
• Configurar un clúster de GKE (ingress-config) como el clúster de configuración central
• Implementar una app de ejemplo en los otros clústeres de GKE
• Configurar Ingress de varios clústeres para enviar el tráfico del cliente a la app que se ejecuta en ambos clústeres de app
• Establecer un generador de cargas para la app y configurar la supervisión
• Quitar un clúster de app de Ingress de varios clústeres (vaciarlo) y actualizar el que se vació
• Devolver el tráfico al clúster actualizado por medio de Ingress de varios clústeres

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• GKE
• Networking
• Cloud Load Balancing

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Es posible que los usuarios Google Cloud nuevos cumplan con los requisitos para acceder una prueba gratuita.

Cuando termines las tareas descritas en este documento, puedes borrar los recursos que creaste para evitar que se siga facturando. Para obtener más información, consulta Realiza una limpieza.

Antes de empezar

1. Para este instructivo, debes configurar Ingress de varios clústeres con el objetivo de que se establezca lo siguiente:
   • Dos o más clústeres con las mismas apps, como espacios de nombres, implementaciones y servicios, que se ejecutan en todos los clústeres.
   • La actualización automática está desactivada para todos los clústeres.
   • Los clústeres son clústeres nativos de la VPC que usan rangos de direcciones IP de alias.
   • Habilita el balanceo de cargas de HTTP (habilitado de forma predeterminada).
   • gcloud --version debe ser 369 o superior. Los pasos para registrar los clústeres de GKE dependen de esta versión o una superior.

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

3. Make sure that billing is enabled for your Google Cloud project.

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

   Activate Cloud Shell

5. Configura el proyecto predeterminado:

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

6. Habilita las APIs de GKE, Hub y multiclusteringress:

   gcloud services enable container.googleapis.com \
                          gkehub.googleapis.com \
                          multiclusteringress.googleapis.com \
                          multiclusterservicediscovery.googleapis.com
   

Configura el entorno

1. En Cloud Shell, clona el repositorio para obtener los archivos de este instructivo:

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

2. Crea un directorio de WORKDIR:

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

Crea y registra los clústeres de GKE en Hub

En esta sección, crearás tres clústeres de GKE y los registrarás en GKE Enterprise Hub.

Crea clústeres de GKE

1. En Cloud Shell, crea tres clústeres de 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
   

   A los efectos de este instructivo, puedes crear los clústeres en una sola región, pero en tres zonas diferentes: us-west1-a, us-west1-b y us-west1-c. Para obtener más información sobre las regiones y las zonas, consulta Ubicación geográfica y regiones.

2. Espera unos minutos hasta que todos los clústeres se creen de manera correcta. Asegúrate de que los clústeres estén en ejecución:

   gcloud container clusters list
   

   El resultado es similar a este:

   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. Crea un archivo kubeconfig y conéctate a todos los clústeres para generar entradas en el archivo kubeconfig de la siguiente manera:

   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 el archivo kubeconfig para crear la autenticación a los clústeres generando un usuario y un contexto para cada uno. Después de crear el archivo kubeconfig, puedes cambiar rápido el contexto entre clústeres.

4. Verifica que tengas tres clústeres en el archivo kubeconfig:

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

   Este es el resultado:

   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. Obtén el contexto de los tres clústeres para usarlo más adelante:

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

   Este es el resultado:

   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
   

Registra clústeres de GKE en una flota

Registrar clústeres en una flota permite usar los clústeres de Kubernetes en entornos híbridos. Los clústeres registrados en flotas pueden usar funciones de GKE avanzadas, como Ingress de varios clústeres. Para registrar un clúster de GKE en una flota, puedes usar directamente una cuenta de servicio de Google Cloudo el enfoque recomendado de Workload Identity Federation for GKE. Este permite que una cuenta de servicio de Kubernetes en tu clúster de GKE actúe como una cuenta de servicio de Identity and Access Management.

1. Registra los tres clústeres como una flota de la siguiente manera:

   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. Verifica que los clústeres estén registrados:

   gcloud container fleet memberships list
   

   El resultado es similar a este:

   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. Para configurar el clúster ingress-config como el clúster de configuración de Ingress de varios clústeres, habilita la función multiclusteringress a través de Hub de la siguiente manera:

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

   El comando anterior agrega las CDR (definiciones de recursos personalizados) MulticlusterIngress y MulticlusterService al clúster ingress-config. Este comando tardará unos minutos en completarse. Espera para poder continuar con el siguiente paso.

4. Verifica que el clúster ingress-cluster se haya configurado de forma correcta para Ingress de varios clústeres:

   watch gcloud container fleet ingress describe
   

   Espera hasta que el resultado sea similar al siguiente:

   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 función no se podrá usar hasta que el clúster de configuración tenga el estado OK. Si no ves code: OK después de unos minutos, ve a la sección de solución de problemas.

   Para salir del comando watch, presiona Control + C.

Implementa una aplicación de ejemplo en los clústeres azul y verde

1. En Cloud Shell, implementa la app de ejemplo whereami en los clústeres blue y green:

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

2. Espera unos minutos y asegúrate de que todos los Pods de los clústeres blue y green tengan el estado Running:

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

   El resultado es similar a este:

   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.
   

Configura Ingress de varios clústeres

En esta sección, crearás un Ingress de varios clústeres que envía el tráfico a la aplicación que se ejecuta en los clústeres blue y green. Debes usar Cloud Load Balancing para crear un balanceador de cargas que use la app whereami en los clústeres blue y green como backends. Para crear el balanceador de cargas, necesitarás dos recursos: MultiClusterIngress y uno o más MultiClusterServices. Los objetos MultiClusterIngress y MultiClusterService son equivalentes de varios clústeres para los recursos de Ingress y servicio de Kubernetes existentes que se usan en el contexto de clúster único.

1. En Cloud Shell, implementa el recurso MulticlusterIngress en el clúster ingress-config:

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

   Este es el resultado:

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

2. Implementa el recurso MulticlusterService en el clúster ingress-config:

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

   Este es el resultado:

   multiclusterservice.networking.gke.io/whereami-mcs created
   

3. Para comparar los dos recursos, haz lo siguiente:

   • Inspecciona el recurso MulticlusterIngress:

     kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusteringress -o yaml
     

     El resultado contiene lo siguiente:

     spec:
       template:
         spec:
           backend:
             serviceName: whereami-mcs
             servicePort: 8080
     

     El recurso MulticlusterIngress es similar al recurso Ingress de Kubernetes, excepto que la especificación serviceName apunta a un recurso MulticlusterService.

   • Inspecciona el recurso MulticlusterService:

     kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice -o yaml
     

     El resultado contiene lo siguiente:

     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
     

     El recurso MulticlusterService es similar a un recurso de servicio de Kubernetes, excepto que tiene una especificación clusters. El valor clusters es la lista de clústeres registrados en los que se crea el recurso MulticlusterService.

   • Verifica que el recurso MulticlusterIngress haya creado un balanceador de cargas con un servicio de backend que apunta al recurso MulticlusterService:

     watch kubectl --context ${INGRESS_CONFIG_CLUSTER} \
           get multiclusteringress -o jsonpath="{.items[].status.VIP}"
     

     Este proceso puede tardar hasta 10 minutos. Espera hasta que el resultado sea similar al siguiente:

     34.107.246.9
     

     Para salir del comando watch, presiona Control+C.

4. En Cloud Shell, obtén la VIP de Cloud Load Balancing:

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

   El resultado es similar a este:

   34.107.246.9
   

5. Usa curl para acceder al balanceador de cargas y a la aplicación implementada:

   curl ${GCLB_VIP}
   

   El resultado es similar a este:

   {
     "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. Ejecuta el comando curl varias veces. Ten en cuenta que las cargas de las solicitudes se balancean entre la aplicación whereami que se implementa en dos clústeres, blue y green.

Configura el generador de cargas

En esta sección, configurarás un servicio loadgenerator que genera tráfico de cliente a la VIP de Cloud Load Balancing. Primero, el tráfico se envía a los clústeres blue y green porque el recurso MulticlusterService está configurado para enviar tráfico a ambos clústeres. Más adelante, deberás configurar el recurso MulticlusterService para enviar tráfico a un único clúster.

1. Configura el manifiesto loadgenerator para enviar tráfico de cliente a Cloud Load Balancing:

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

2. Implementa loadgenerator en el clúster ingress-config:

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

3. Verifica que los pods loadgenerator en el clúster ingress-config tengan el estado Running:

   kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods
   

   El resultado es similar a este:

   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
   

   Si alguno de los Pods no tiene un estado Running, espera unos minutos y vuelve a ejecutar el comando.

Supervisa el tráfico

En esta sección, supervisarás el tráfico que se dirige a la app whereami con la consolaGoogle Cloud .

En la sección anterior, configuraste una implementación de loadgenerator que simula el tráfico de cliente accediendo a la app whereami con la VIP de Cloud Load Balancing. Estas métricas se pueden supervisar en la consolaGoogle Cloud . Primero, debes configurar la supervisión con el objetivo de poder llevarla a cabo mientras vacías los clústeres para las actualizaciones (se describe en la sección siguiente).

1. Crea un panel para mostrar el tráfico que llega a Ingress de varios clústeres:

   export DASH_ID=$(gcloud monitoring dashboards create \
       --config-from-file=dashboards/cloud-ops-dashboard.json \
       --format=json | jq  -r ".name" | awk -F '/' '{print $4}')
   

   El resultado es similar a este:

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

2. Las métricas de Cloud Load Balancing están disponibles en la consolaGoogle Cloud . Genera la URL:

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

   El resultado es similar a este:

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

3. En un navegador, accede a la URL que se generó con el comando anterior.

   El tráfico que se dirige a la aplicación de ejemplo va del generador de cargas a los clústeres blue y green (como lo indican las dos zonas en las que se encuentran los clústeres). En el gráfico de métricas a lo largo del tiempo, se muestra el tráfico que se dirige a ambos backends. Los valores k8s1- que aparecen cuando se coloca el cursor por encima indican que los grupos de extremos de red (NEG) para los dos MulticlusterServices de frontend se ejecutan en los clústeres blue y green.

   Nota: Es posible que los colores del gráfico no correspondan a los clústeres blue y green. El tráfico puede tardar varios minutos en aparecer en el gráfico.

   

Vacía y actualiza el clúster blue

En esta sección, vaciarás el clúster blue. Vaciar un clúster significa que lo quitas del grupo de balanceo de cargas. Después de que vacíes el clúster blue, todo el tráfico de cliente que se dirija a la aplicación se dirigirá al clúster green. Este proceso se puede supervisar tal como se describe en la sección anterior. Una vez que el clúster se desvía, puedes actualizarlo. Después de la actualización, puedes volver a colocarlo en el grupo de balanceo de cargas. Repite estos pasos para actualizar el otro clúster (no se muestra en este instructivo).

Para vaciar el clúster blue, debes actualizar el recurso MulticlusterService del clúster ingress-cluster y quitar el clúster blue de la especificación clusters.

Vacía el clúster azul

1. En Cloud Shell, actualiza el recurso MulticlusterService en el clúster ingress-config:

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

2. Verifica que solo tengas el clúster green en la especificación clusters:

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

   Este es el resultado:

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

   Solo el clúster green aparece en la especificación clusters, por lo que solo el clúster green está en el grupo de balanceo de cargas.

3. Puedes ver las métricas de Cloud Load Balancing en la consolaGoogle Cloud . Genera la URL:

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

4. En un navegador, accede a la URL generada con el comando anterior.

   En el gráfico, se muestra que solo el clúster green recibe tráfico.

   

Actualiza el clúster blue

Ahora que el clúster blue ya no recibe tráfico de clientes, puedes actualizarlo (nodos y plano de control).

1. En Cloud Shell, obtén la versión actual de los clústeres:

   gcloud container clusters list
   

   El resultado es similar a este:

   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
   

   Tus versiones de clúster pueden ser diferentes según cuándo completes este instructivo.

2. Obtén la lista de las versiones MasterVersions disponibles en la zona:

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

   El resultado es similar a este:

   [
     "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. Obtén una lista de las versiones NodeVersions disponibles en la zona:

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

   El resultado es similar a este:

   [
     "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. Configura una variable de entorno para una versión MasterVersion y NodeVersion que esté en las listas MasterVersions y NodeVersions y que sea posterior a la versión actual del clúster blue, por ejemplo:

   export UPGRADE_VERSION="1.22.10-gke.600"
   

   En este instructivo, se usa la versión 1.22.10-gke.600. Las versiones de tu clúster pueden ser diferentes según las versiones que estén disponibles cuando completes este instructivo. Para conocer más sobre la actualización, consulta Actualiza clústeres y grupos de nodos.

   Nota: Te recomendamos no omitir versiones secundarias de clústeres para evitar posibles problemas de incompatibilidad del plano de control o los nodos. Para obtener más información, consulta ¿Puedo omitir varias versiones de GKE durante una actualización del clúster?

5. Actualiza el nodo control plane del clúster blue:

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

   Para confirmar la actualización, presiona Y.

   Este proceso tarda unos minutos en completarse. Espera hasta que se complete la actualización antes de continuar.

   Una vez que se completa la actualización, el resultado es el siguiente:

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

6. Actualiza los nodos en el clúster blue:

   gcloud container clusters upgrade blue \
       --location=us-west1-b --node-pool=default-pool \
       --cluster-version ${UPGRADE_VERSION}
   

   Para confirmar la actualización, presiona Y.

   Este proceso tarda unos minutos en completarse. Espera hasta que se complete la actualización del nodo antes de continuar.

   Una vez que se completa la actualización, el resultado es el siguiente:

   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. Verifica que el clúster blue esté actualizado:

   gcloud container clusters list
   

   El resultado es similar a este:

   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
   

Vuelve a agregar el clúster blue al grupo de balanceo de cargas

En esta sección, volverás a agregar el clúster blue al grupo de balanceo de cargas.

1. En Cloud Shell, verifica que la implementación de la aplicación se ejecute en el clúster blue antes de agregarla de vuelta al grupo de balanceo de cargas:

   kubectl --context ${BLUE_CLUSTER} get pods
   

   El resultado es similar a este:

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

2. Actualiza el recurso MutliclusterService para volver a agregar el clúster blue al grupo de balanceo de cargas:

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

3. Verifica que tengas los clústeres blue y green en la especificación de clústeres:

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

   Este es el resultado:

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

   Los clústeres blue y green ahora están en la especificación clusters.

4. Las métricas de Cloud Load Balancing están disponibles en la consolaGoogle Cloud . Genera la URL:

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

5. En un navegador, accede a la URL generada con el comando anterior.

   En el gráfico, se muestra que los clústeres azul y verde reciben tráfico del generador de cargas por medio del balanceador de cargas.

   Nota: El tráfico puede tardar varios minutos en volver a equilibrarse.

   

   Felicitaciones. Actualizaste con éxito un clúster de GKE en una arquitectura de varios clústeres con Ingress de varios clústeres.

6. Si quieres actualizar el clúster green, repite el proceso para vaciar y actualizar el clúster azul reemplazando blue por green.

Realiza una limpieza

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

La manera más sencilla de eliminar la facturación es borrar el proyecto Google Cloud que creaste para el instructivo. Como alternativa, puedes borrar los recursos individuales.

Borra los clústeres

1. En Cloud Shell, cancela el registro de los clústeres blue y green y bórralos:

   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. Borra el recurso MuticlusterIngress del clúster ingress-config:

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

   Con este comando, se borran los recursos de Cloud Load Balancing del proyecto.

3. Cancela el registro del clúster ingress-config y bórralo:

   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. Verifica que se borren todos los clústeres:

   gcloud container clusters list
   

   Este es el resultado:

   *<null>*
   

5. Restablece el archivo kubeconfig:

   unset KUBECONFIG
   

6. Quita la carpeta WORKDIR:

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

Borra el proyecto

Precaución: Borrar un proyecto tiene las siguientes consecuencias:
• Se borra todo lo que incluye el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los IDs personalizados del proyecto. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto, en lugar de borrar el proyecto completo.
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.

¿Qué sigue?

• Obtén más información sobre Ingress de varios clústeres.
• Obtén más información para implementar Ingress de varios clústeres en los clústeres.
• Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta el Cloud Architecture Center.