Configura una malla de varios clústeres en GKE

En esta guía, se explica cómo unir dos clústeres en una sola Cloud Service Mesh mediante la CA de Mesh o la CA de Istio, y habilitar el balanceo de cargas entre clústeres. Puedes ampliar con facilidad este proceso para incorporar cualquier cantidad de clústeres en la malla.

Una configuración de Cloud Service Mesh de varios clústeres puede resolver varias tareas fundamentales como la escala, la ubicación y el aislamiento. Para obtener más información, consulta Casos de uso de varios clústeres.

Requisitos previos

En esta guía, se da por hecho que tienes dos o más clústeres de GKE de Google Cloud que cumplen los siguientes requisitos:

• Versión 1.11 de Cloud Service Mesh o posterior instalada en los clústeres mediante asmcli install. Necesitas asmcli, la herramienta de istioctl y las muestras que asmcli descarga en el directorio que especificaste en --output_dir cuando ejecutaste asmcli install. Si necesitas realizar la configuración, sigue los pasos que se indican en Instala herramientas dependientes y valida el clúster para hacer lo siguiente:

  • Instala las herramientas requeridas
  • Descarga asmcli
  • Otorga permisos de administrador del clúster
  • Valida tu proyecto y clúster

• Los clústeres de la malla deben tener conectividad entre todos los Pods antes de que configurar Cloud Service Mesh. Además, si unes clústeres que no están en el mismo proyecto, deben estar registrados en el mismo proyecto host de la flota y los clústeres deben estar en la configuración de una VPC compartida en la misma red. También te recomendamos que tengas un proyecto para alojar la VPC compartida y dos proyectos de servicio a fin de crear clústeres. Para obtener más información, consulta Configura clústeres con VPC compartida.

• Si usas la CA de Istio, usa el mismo certificado raíz personalizado para ambos clústeres.

• Si tu Cloud Service Mesh está compilada en clústeres privados, te recomendamos crear una sola subred en la misma VPC, de lo contrario, debes asegurarte de lo siguiente:

  1. Los planos de control pueden alcanzar los planos de control del clúster privado remoto a través de las IP privadas del clúster.
  2. Puedes agregar los rangos de IP de los planos de control de llamadas a las redes autorizadas de los clústeres privados. Para obtener más información, consulta Configura el descubrimiento de extremos entre clústeres privados.

• Las otras instancias de Cloud Service Mesh deben poder acceder al servidor de la API plano de control en la malla de varios clústeres.

  • Asegúrate de que los clústeres tengan habilitado el acceso global.
  • Asegúrate de que la IP del plano de control de Cloud Service Mesh se haya permitido de forma correcta a través de la lista de entidades permitidas en la red autorizada principal.

Configura variables de proyecto y clúster

1. Crea las siguientes variables de entorno para el ID del proyecto, la zona o región del clúster, el nombre y el contexto del clúster.

   export PROJECT_1=PROJECT_ID_1
   export LOCATION_1=CLUSTER_LOCATION_1
   export CLUSTER_1=CLUSTER_NAME_1
   export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}"
   
   export PROJECT_2=PROJECT_ID_2
   export LOCATION_2=CLUSTER_LOCATION_2
   export CLUSTER_2=CLUSTER_NAME_2
   export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
   

2. Si estos clústeres son nuevos, asegúrate de recuperar las credenciales para cada uno con los siguientes comandos de gcloud. De lo contrario, su context asociado no estará disponible para su uso en los pasos siguientes de esta guía.

   Los comandos dependen del tipo de clúster, ya sea regional o zonal:

   Regional

   gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
   

   Zonal

   gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
   

Crear regla de firewall

En algunos casos, debes crear una regla de firewall para permitir el tráfico entre clústeres. Por ejemplo, debes crear una regla de firewall si se cumple lo siguiente:

• Usas subredes diferentes para los clústeres de tu malla.
• Tus Pods abren puertos distintos de 443 y 15002.

GKE agrega automáticamente reglas de firewall a cada nodo para permitir el tráfico dentro de la misma subred. Si tu malla contiene varias subredes, debes configurar explícitamente las reglas de firewall para permitir el tráfico entre subredes. Debes agregar una regla de firewall nueva para cada subred a fin de permitir los bloques CIDR de IP de destino y los puertos de destino de todo el tráfico entrante.

Las siguientes instrucciones permiten la comunicación entre todos los clústeres de tu proyecto o solo entre $CLUSTER_1 y $CLUSTER_2.

1. Recopila información sobre la red de tus clústeres.

   Todos los clústeres del proyecto

   Si los clústeres están en el mismo proyecto, puedes usar el siguiente comando para permitir la comunicación entre todos los clústeres del proyecto. Si hay clústeres en tu proyecto que no deseas exponer, usa el comando en la pestaña Clústeres específicos.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

   Clústeres específicos

   El siguiente comando permite la comunicación entre $CLUSTER_1 y $CLUSTER_2, y no expone otros clústeres en tu proyecto.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list  --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

2. Crea la regla de firewall.

   GKE

   gcloud compute firewall-rules create istio-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --direction=INGRESS \
       --priority=900 \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \
       --network=YOUR_NETWORK
   

   Autopilot

   TAGS=""
   for CLUSTER in ${CLUSTER_1} ${CLUSTER_2}
   do
       TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+=","
   done
   TAGS=${TAGS::-1}
   echo "Network tags for pod ranges are $TAGS"
   
   gcloud compute firewall-rules create asm-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --network=gke-cluster-vpc \
       --direction=INGRESS \
       --priority=900 --network=VPC_NAME \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags=$TAGS
   

Configura la detección de extremos

Nota: Para obtener más información sobre el descubrimiento de extremos, consulta Descubrimiento de extremos con varios planos de control.

Los pasos necesarios para configurar la detección de extremos dependen de si prefieres usar laAPI declarativa en clústeres de una flota o habilitarla de forma manual en clústeres públicos o clústeres privados.

Advertencia: Si el descubrimiento de extremos está habilitado entre clústeres, los servicios entre clústeres no pueden comunicarse entre sí sin la configuración de DNS adecuada. Esto se debe a que los servicios de GKE dependen en el nombre de dominio completamente calificado (FQDN) de cada servicio para el enrutamiento de tráfico. Puedes habilitar el proxy DNS para permitir el descubrimiento entre clústeres. El proxy de DNS captura todas las solicitudes de DNS y las resuelve con la información del Plano de Control.

Habilita el descubrimiento de extremos entre clústeres con la API declarativa (vista previa)

Vista previa — Enable endpoint discovery

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

De manera alternativa, puedes habilitar la detección de extremos en clústeres de una flota si aplicas la configuración "multicluster_mode":"connected" en el configmap de asm-options. Los clústeres con esta configuración habilitada en la misma flota tendrán habilitado el descubrimiento de servicios entre clústeres de forma automática entre sí.

Advertencia: No uses este método si tus clústeres ya usan secretos remotos existentes en el clúster.

Este método está disponible para las instalaciones administradas de Cloud Service Mesh en todos de versiones canary. Antes de continuar, debes crear una regla de firewall.

Para varios proyectos, debes agregar FLEET_PROJECT_ID.svc.id.goog de forma manual a trustDomainAliases en la meshConfig de la revisión si aún no está presente.

Habilitar

Si el Configmap asm-options ya existe en tu clúster, habilita detección de extremos del clúster:

kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

Si el ConfigMap de asm-options aún no existe en tu clúster, créalo con los datos asociados y habilita el descubrimiento de extremos para el clúster:

kubectl --context ${CTX_1} create configmap asm-options -n istio-system --from-file <(echo '{"data":{"multicluster_mode":"connected"}}')

Inhabilitar

Inhabilita la detección de extremos para un clúster:

kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'

Si cancelas el registro de un clúster en la flota sin inhabilitar el descubrimiento de extremos, los secretos podrían permanecer en el clúster. Debes limpiar manualmente los secretos restantes.

1. Ejecuta el siguiente comando para buscar los secretos que requieran limpieza:

   kubectl get secrets -n istio-system -l istio.io/owned-by=mesh.googleapis.com,istio/multiCluster=true
   

2. Borra cada secreto:

   kubectl delete secret SECRET_NAME
   

   Repite este paso para cada secreto restante.

Configura el descubrimiento de extremos entre clústeres públicos

Para configurar la detección de extremos entre clústeres de GKE, ejecuta asmcli create-mesh. Este comando realiza las siguientes acciones:

• Registra todos los clústeres en la misma flota.
• Configura la malla para que confíe en la identidad de carga de trabajo de la flota.
• Crea secretos remotos.

Puedes especificar el URI para cada clúster o la ruta del archivo kubeconfig.

URI del clúster

En el siguiente comando, reemplaza FLEET_PROJECT_ID por el ID del proyecto host de la flota y el URI del clúster por el nombre, la zona o región y el ID del proyecto para cada clúster. En este ejemplo, solo se muestran dos clústeres, pero puedes ejecutar el comando para habilitar el descubrimiento de extremos en clústeres adicionales, sujeto a la cantidad máxima permitida de clústeres que puedes agregar a tu flota.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    ${PROJECT_1}/${LOCATION_1}/${CLUSTER_1} \
    ${PROJECT_2}/${LOCATION_2}/${CLUSTER_2}

Archivo kubeconfig

En el siguiente comando, reemplaza: FLEET_PROJECT_ID por el ID del proyecto del proyecto host de la flota y PATH_TO_KUBECONFIG por la ruta de acceso a archivo kubeconfig. En este ejemplo, solo se muestran dos clústeres, pero puedes ejecutar el comando para habilitar el descubrimiento de extremos en clústeres adicionales, sujeto a la cantidad máxima permitida de clústeres que puedes agregar a tu flota.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2

Configura el descubrimiento de extremos entre clústeres privados

1. Configura secretos remotos para permitir que el servidor de API acceda al clúster al plano de control de Cloud Service Mesh del otro clúster. Los comandos dependen del tipo de Cloud Service Mesh (ya sea en el clúster o administrado):

   Nota: Asegúrate de ejecutar los siguientes comandos con istioctl desde la ubicación --output_dir que especificaste cuando ejecutaste asmcli install. Para ello, ejecuta los comandos istioctl de una manera ../output_dir/istioctl.

   A. Para Cloud Service Mesh en el clúster, debes configurar las IP privadas en su lugar de IP públicas porque no se puede acceder a ellas:

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
    --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PRIV_IP} > ${CTX_1}.secret
   

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
    --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PRIV_IP} > ${CTX_2}.secret
   

   B. Para Managed Cloud Service Mesh:

   PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
    --zone "${LOCATION_1}" --format "value(privateClusterConfig.publicEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PUBLIC_IP} > ${CTX_1}.secret
   

   PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
    --zone "${LOCATION_2}" --format "value(privateClusterConfig.publicEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PUBLIC_IP} > ${CTX_2}.secret
   

2. Aplica los Secrets nuevos en los clústeres:

   kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
   

   kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
   

Configura redes autorizadas para clústeres privados

Sigue esta sección solo si se cumplen todas las siguientes condiciones en la malla:

• Usas clústeres privados.
• Los clústeres no pertenecen a la misma subred.
• Los clústeres habilitaron redes autorizadas.

Cuando se implementan varios clústeres privados, el plano de control de Cloud Service Mesh en cada clúster debe llamar al plano de control de GKE de los clústeres remotos. Para permitir el tráfico, debes agregar el rango de direcciones del Pod en el clúster que realiza la llamada a las redes autorizadas de los clústeres remotos.

1. Obtén el bloque CIDR de IP del Pod para cada clúster:

   POD_IP_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

   POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

2. Agrega los bloques CIDR de IP del Pod de clúster de Kubernetes a los clústeres remotos:

   EXISTING_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_2},${EXISTING_CIDR_1//;/,}
   

   EXISTING_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_1},${EXISTING_CIDR_2//;/,}
   

   Para obtener más información, consulta Crea un clúster con redes autorizadas.

3. Verifica que las redes autorizadas estén actualizadas:

   gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

   gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

Habilita el acceso global al plano de control

Sigue esta sección solo si se cumplen todas las siguientes condiciones en la malla:

• Usas clústeres privados.
• Usas subredes diferentes para los clústeres de tu malla.

Debes habilitar el acceso global al plano de control para permitir que el plano de control de Cloud Service Mesh en cada clúster llame al Plano de control de GKE de los clústeres remotos.

1. Habilita el acceso global al plano de control

   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --enable-master-global-access
   

   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --enable-master-global-access
   

2. Verifica que el acceso global al plano de control esté habilitado:

   gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1}
   

   gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2}
   

   La sección privateClusterConfig en el resultado muestra el estado de masterGlobalAccessConfig.

Verifica la conectividad de varios clústeres

Nota de la plataforma: Estos pasos solo se aplican si usas un plano de control en el clúster. Para conocer las opciones de Cloud Service Mesh administrado, consulta Incorpora proxies de sidecar o Aplica el plano de datos administrado.

En esta sección, se explica cómo implementar los servicios HelloWorld y Sleep de muestra en el entorno de varios clústeres para verificar que el balanceo de cargas entre clústeres funcione.

Nota: Estos servicios de muestra se encuentran en el directorio samples de Istio incluido en el archivo comprimido istioctl (ubicado en OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples) y no en el directorio samples descargado por asmcli (ubicado en OUTPUT_DIR/samples).

Configura una variable para el directorio de muestras

1. Navega al lugar en que se descargó asmcli y ejecuta el siguiente comando para configurar ASM_VERSION

   export ASM_VERSION="$(./asmcli --version)"
   

2. Configura una carpeta de trabajo para las muestras que usas para verificar que funcione el balanceo de cargas entre clústeres. Las muestras se encuentran en un subdirectorio en el directorio --output_dir que especificaste en el comando asmcli install. En el siguiente comando, cambia OUTPUT_DIR por el directorio que especificaste en --output_dir.

   export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
   

Habilite la inyección de sidecar

1. Ubica el valor de la etiqueta de revisión, que usarás en pasos posteriores. El paso depende del tipo de Cloud Service Mesh (administrado o en el clúster).

   Nota: Si tus clústeres tienen diferentes versiones de Cloud Service Mesh, debes ejecutar el siguiente comando para cada clúster.

   Administrado

   Usa el siguiente comando para ubicar la etiqueta de revisión, que usarás en los pasos posteriores.

   kubectl get controlplanerevision -n istio-system

   El resultado es similar al siguiente:

    NAME                RECONCILED   STALLED   AGE
    asm-managed-rapid   True         False     89d
    

   En el resultado, en la columna NAME, observa el valor de la etiqueta de revisión. En este ejemplo, el valor es asm-managed-rapid. Usa el valor de revisión en los pasos de la siguiente sección.

   En el clúster

   Usa el siguiente comando para ubicar la etiqueta de revisión, que usarás en los pasos posteriores.

   kubectl -n istio-system get pods -l app=istiod --show-labels

   El resultado es similar al siguiente:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-173-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-173-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    

   En el resultado, en la columna LABELS, observa el valor de la etiqueta de revisión istiod, que está después del prefijo istio.io/rev=. En este ejemplo, el valor es asm-173-3. Use el valor de revisión en los pasos de la siguiente sección.

Instala el servicio HelloWorld

Nota: En el ejemplo de servicio HelloWorld, se usa Docker Hub. En un clúster privado, el entorno de ejecución del contenedor puede extraer imágenes de contenedor de Artifact Registry de forma predeterminada. El entorno de ejecución del contenedor no puede extraer imágenes de ningún otro registro de imágenes de contenedor en Internet. Puedes descargar la imagen y enviarla a Artifact Registry o usar Cloud NAT a fin de proporcionar acceso a Internet saliente para ciertos nodos privados. Para obtener más información, consulta Migra contenedores externos y Crea un clúster privado.

1. Crea el espacio de nombres de muestra y la definición del servicio en cada clúster. En el siguiente comando, sustituye REVISION por la etiqueta de revisión istiod que anotaste del paso anterior.

   Importante: Si usas el plano de control administrado de Cloud Service Mesh, reemplaza REVISION por asm-managed en los siguientes pasos.

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl create --context=${CTX} namespace sample
       kubectl label --context=${CTX} namespace sample \
           istio-injection- istio.io/rev=REVISION --overwrite
   done
   

   En el ejemplo anterior, REVISION es la etiqueta de revisión istiod que anotaste antes.

   Este es el resultado:

   label "istio-injection" not found.
   namespace/sample labeled
   

   Puedes ignorar a label "istio-injection" not found. de forma segura

2. Crea el servicio HelloWorld en ambos clústeres:

   kubectl create --context=${CTX_1} \
       -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
       -l service=helloworld -n sample
   

   kubectl create --context=${CTX_2} \
       -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
       -l service=helloworld -n sample
   

Implementa HelloWorld v1 y v2 en cada clúster

1. Implementa HelloWorld v1 en CLUSTER_1 y v2 en CLUSTER_2, lo que más adelante ayudará a verificar el balanceo de cargas entre clústeres:

   kubectl create --context=${CTX_1} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v2 -n sample

2. Ejecuta los siguientes comandos para verificar que HelloWorld v1 y v2 se estén ejecutando. Verifica que el resultado sea similar al siguiente:

   kubectl get pod --context=${CTX_1} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v1-86f77cd7bd-cpxhv  2/2       Running   0          40s

   kubectl get pod --context=${CTX_2} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v2-758dd55874-6x4t8  2/2       Running   0          40s

Implementa el servicio de suspensión

1. Implementa el servicio Sleep en ambos clústeres. En este Pod, se genera tráfico de red artificial con fines de demostración:

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl apply --context=${CTX} \
           -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
   done
   

2. Espera a que se inicie el servicio Sleep en cada clúster. Verifica que el resultado sea similar al siguiente:

   kubectl get pod --context=${CTX_1} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-n6bzf           2/2     Running   0          5s

   kubectl get pod --context=${CTX_2} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-dzl9j           2/2     Running   0          5s

Verifica el balanceo de cargas entre clústeres

Llama al servicio HelloWorld varias veces y observa el resultado para verificar respuestas alternativas de v1 y v2:

1. Llama al servicio HelloWorld:

   kubectl exec --context="${CTX_1}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_1}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   El resultado es similar al que se muestra:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

2. Vuelve a llamar al servicio HelloWorld:

   kubectl exec --context="${CTX_2}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_2}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   El resultado es similar al que se muestra:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

Felicitaciones, ya verificaste el funcionamiento de Cloud Service Mesh de varios clústeres con balanceo de cargas.

Limpia el servicio HelloWorld

Cuando termines de verificar el balanceo de cargas, quita los servicios HelloWorld y Sleep del clúster.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}