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

Last reviewed 2022-12-15 UTC

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

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

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

    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.

    Gráfico de métricas a lo largo del tiempo, en el que se muestra el tráfico que fluye a ambos backends.

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.

    Tráfico que fluye solo al clúster “verde”.

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.

  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.

    Ambos clústeres recibiendo tráfico.

    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.