Actualizar un entorno de GKE con varios clústeres mediante la entrada de varios clústeres

En este tutorial se muestra cómo actualizar un entorno de Google Kubernetes Engine (GKE) con varios clústeres mediante Multi Cluster Ingress. Este tutorial es una continuación del documento sobre las actualizaciones de GKE multiclústeres con Multi Cluster Ingress, que explica el proceso, la arquitectura y los términos con más detalle. Te recomendamos que leas el documento de conceptos antes de este tutorial.

Para ver una comparación detallada entre Multi Cluster Ingress (MCI), Multi-cluster Gateway (MCG) y el balanceador de carga con grupos de endpoints de red independientes (LB y Standalone NEGs), consulta Elegir la API de balanceo de carga multiclúster para GKE.

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

Te recomendamos que actualices automáticamente tus clústeres de GKE. La actualización automática es una forma totalmente gestionada de actualizar automáticamente los clústeres (plano de control y nodos) según una programación de lanzamientos determinada porGoogle Cloud. No requiere ninguna intervención por parte del operador. Sin embargo, si quieres tener más control sobre cómo y cuándo se actualizan los clústeres, en este tutorial se explica un método para actualizar varios clústeres en los que se ejecutan tus aplicaciones. A continuación, usa Ingress de varios clústeres para vaciar un clúster a la vez antes de actualizarlo.

Arquitectura

En este tutorial se usa la siguiente arquitectura. Hay un total de tres clústeres: dos clústeres (blue y green) actúan como clústeres idénticos con la misma aplicación desplegada y un clúster (ingress-config) actúa como clúster de plano de control que configura Multi Cluster Ingress. En este tutorial, desplegarás una aplicación de ejemplo en dos clústeres de aplicaciones (clústeres blue y green).

Arquitectura de dos clústeres idénticos y un clúster de plano de control.

Configurar el entorno

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

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

  2. Crea un directorio WORKDIR:

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

Crear y registrar clústeres de GKE en Hub

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

Crear 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

    En este tutorial, crearás los clústeres en una sola región, 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 el artículo sobre geografía y regiones.

  2. Espera unos minutos hasta que se hayan creado todos los clústeres correctamente. Asegúrate de que los clústeres se estén ejecutando:

    gcloud container clusters list

    El resultado debería ser similar al siguiente:

    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éctalo a todos los clústeres para generar entradas en el archivo 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}

    El archivo kubeconfig se usa para crear la autenticación en los clústeres. Para ello, se crea un usuario y un contexto para cada clúster. Después de crear el archivo kubeconfig, puedes cambiar rápidamente de contexto entre clústeres.

  4. Comprueba que haya tres clústeres en el archivo kubeconfig:

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

    El resultado es el siguiente:

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

    El resultado es el siguiente:

    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 clústeres de GKE en una flota

Registrar tus clústeres en una flota te permite operar tus clústeres de Kubernetes en entornos híbridos. Los clústeres registrados en flotas pueden usar funciones avanzadas de GKE, como la entrada multi-clúster. Para registrar un clúster de GKE en una flota, puedes usar una Google Cloud cuenta de servicio directamente o usar el enfoque recomendado de federación de Workload Identity para GKE , que permite que una cuenta de servicio de Kubernetes de tu clúster de GKE actúe como cuenta de servicio de gestión de identidades y accesos.

  1. Registra los tres clústeres como una flota:

    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 debería ser similar al siguiente:

    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. Configura el clúster ingress-config como clúster de configuración de Ingress de varios clústeres habilitando la función multiclusteringress a través del Hub:

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

    El comando anterior añade los MulticlusterIngress y los MulticlusterService CRDs (Custom Resource Definitions) al clúster ingress-config. Este comando tarda unos minutos en completarse. Espera antes de continuar con el siguiente paso.

  4. Verifica que el clúster ingress-cluster se ha configurado correctamente para Ingress con 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'

    Para salir del comando watch, pulsa Control+C.

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

  1. En Cloud Shell, despliega la aplicación 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 comprueba 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 debería ser similar al siguiente:

    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 Ingress de varios clústeres

En esta sección, crearás un recurso Ingress multiclúster que envíe tráfico a la aplicación que se ejecuta en los clústeres blue y green. Usas Cloud Load Balancing para crear un balanceador de carga que utilice la aplicación whereami en los clústeres blue y green como back-ends. Para crear el balanceador de carga, necesitas dos recursos: un MultiClusterIngress y uno o varios MultiClusterServices. Los objetos MultiClusterIngress y MultiClusterService son análogos multiclúster de los recursos de Kubernetes Ingress y Service que se usan en el contexto de un solo clúster.

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

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

    El resultado es el siguiente:

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

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

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

    El resultado es el siguiente:

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

  3. Para comparar los dos recursos, sigue estos pasos:

    • Inspecciona el recurso MulticlusterIngress:

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

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

      La salida 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, pero tiene una especificación clusters. El valor de 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 carga con un servicio de backend que apunte al recurso MulticlusterService:

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

      Esta operación puede tardar hasta 10 minutos. Espera hasta que el resultado sea similar al siguiente:

      34.107.246.9

      Para salir del comando watch, pulsa Control+C.

  4. En Cloud Shell, obtén la dirección IP virtual 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 debería ser similar al siguiente:

    34.107.246.9

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

    curl ${GCLB_VIP}

    El resultado debería ser similar al siguiente:

    {
  "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 repetidamente. Observa que las solicitudes se están equilibrando entre la aplicación whereami, que se ha implementado en dos clústeres, blue y green.

Configurar el generador de carga

En esta sección, configurarás un loadgenerator servicio que genere tráfico de cliente a la dirección IP virtual 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, configurará el MulticlusterService recurso para que envíe tráfico a un solo clúster.

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

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

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

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

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

    kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods

    El resultado debería ser similar al siguiente:

    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 el estado Running, espera unos minutos y vuelve a ejecutar el comando.

Supervisar el tráfico

En esta sección, monitorizarás el tráfico de la aplicación whereami mediante la consolaGoogle Cloud .

En la sección anterior, has configurado una implementación de loadgenerator que simula el tráfico de clientes accediendo a la aplicación whereami a través de la dirección IP virtual de Cloud Load Balancing. Puedes monitorizar estas métricas a través de la consolaGoogle Cloud . Primero debes configurar la monitorización para poder monitorizar los clústeres mientras los vacías para realizar las actualizaciones (se describe en la siguiente sección).

  1. Crea un panel de control 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 debería ser similar al siguiente:

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

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

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

    El resultado debería ser similar al siguiente:

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

  3. En un navegador, ve a la URL generada por el comando anterior.

    El tráfico a la aplicación de ejemplo va del generador de carga a los clústeres blue y green (indicados por las dos zonas en las que se encuentran los clústeres). El gráfico de métricas de la cronología muestra el tráfico que va a ambos backends.Los valores al colocar el cursor sobre k8s1- indican que el grupo de puntos finales de red (NEG) de los dos frontend MulticlusterServices se está ejecutando en los clústeres blue y green.

    Gráfico de métricas cronológicas que muestra el tráfico que llega a ambos back-ends.

Drenar y actualizar el clúster blue

En esta sección, vaciarás el clúster blue. Drenar un clúster significa que lo eliminas del grupo de balanceo de carga. Una vez que hayas vaciado el clúster blue, todo el tráfico de clientes destinado a la aplicación se dirigirá al clúster green. Puedes monitorizar este proceso como se describe en la sección anterior. Una vez que se haya vaciado el clúster, puedes actualizarlo. Después de la actualización, puedes volver a añadirlo al grupo de balanceo de carga. Repite estos pasos para actualizar el otro clúster (no se muestra en este tutorial).

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

Drena el clúster azul

  1. En Cloud Shell, actualiza el recurso MulticlusterService del 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'

    El resultado es el siguiente:

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

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

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

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

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

    El gráfico muestra que solo el clúster green está recibiendo tráfico.

    Solo se dirige tráfico al clúster `green`.

Actualizar el clúster blue

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

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

    gcloud container clusters list

    El resultado debería ser similar al siguiente:

    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

    Las versiones de tu clúster pueden ser diferentes en función de cuándo completes este tutorial.

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

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

    El resultado debería ser similar al siguiente:

    [
  "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 de NodeVersions disponibles en la zona:

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

    El resultado debería ser similar al siguiente:

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

    export UPGRADE_VERSION="1.22.10-gke.600"

    En este tutorial se usa la versión 1.22.10-gke.600. Las versiones de tu clúster pueden ser diferentes en función de las versiones que estén disponibles cuando completes este tutorial. Para obtener más información sobre cómo actualizar, consulta Actualizar clústeres y grupos de nodos.

  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, pulsa Y.

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

    Una vez completada 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 del 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, pulsa Y.

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

    Una vez completada 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 se haya actualizado:

    gcloud container clusters list

    El resultado debería ser similar al siguiente:

    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

Añade el clúster blue de nuevo al pool de balanceo de carga

En esta sección, volverá a añadir el clúster blue al pool de balanceo de carga.

  1. En Cloud Shell, comprueba que el despliegue de la aplicación se esté ejecutando en el clúster blue antes de volver a añadirlo al pool de balanceo de carga:

    kubectl --context ${BLUE_CLUSTER} get pods

    El resultado debería ser similar al siguiente:

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

  2. Actualiza el recurso MutliclusterService para añadir el clúster blue de nuevo al grupo de balanceo de carga:

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

  3. Verifica que tienes 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'

    El resultado es el siguiente:

    [
  {
    "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 laGoogle Cloud consola. Genera la URL:

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

  5. En un navegador, ve a la URL generada por el comando anterior.

    El gráfico muestra que tanto los clústeres azules como los verdes reciben tráfico del generador de carga mediante el balanceador de carga.

    Ambos clústeres reciben tráfico.

    Enhorabuena. Has actualizado correctamente un clúster de GKE en una arquitectura de varios clústeres mediante Multi Cluster Ingress.

  6. Para actualizar el clúster green, repite el proceso para vaciar y actualizar el clúster azul, sustituyendo blue por green.