Configura una malla híbrida o de múltiples nubes

Vista previa — Hybrid and multi-cloud mesh

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.

En esta página, se explica cómo configurar una malla híbrida o de múltiples nubes para las siguientes plataformas:

• Híbrido: GKE en Google Cloud y GKE en VMware (versión preliminar)
• Híbrido: GKE en Google Cloud y GKE en Bare Metal (versión preliminar)
• Multi-cloud: GKE on Google Cloud y Amazon EKS (vista previa)

Advertencia: Comunícate con el equipo de asistencia antes de configurar una malla de múltiples nubes.

Nota de la plataforma: El comando de asmcli create-mesh que usas para habilitar el descubrimiento de extremos requiere que todos los clústeres de la malla sean una de las combinaciones de plataformas híbridas y de múltiples nubes que se indican en la lista anterior. No se admiten otras combinaciones de mallas híbridas o de múltiples nubes en otras plataformas. Anthos Service Mesh administrado no es compatible con mallas híbridas o de múltiples nubes.

Requisitos previos

• Todos los clústeres deben estar registrados en el mismo proyecto host de la flota.
• Todos los clústeres de GKE deben estar en una configuración de VPC compartida en la misma red.
• La dirección de la puerta de enlace y la dirección del plano de control de Kubernetes del clúster deben ser accesibles desde cada clúster de la malla. El proyecto de Google Cloud en el que se ubican los clústeres de GKE debe poder crear tipos de balanceo de cargas externo. Te recomendamos usar redes autorizadas y reglas de firewall de VPC para restringir el acceso.
• Los clústeres privados, incluidos los clústeres privados de GKE, no se admiten. Si usas clústeres locales, incluidos GKE on VMware y GKE en Bare Metal, la dirección del plano de control de Kubernetes y la dirección de la puerta de enlace deben ser accesibles desde los Pods en los clústeres de GKE. Te recomendamos usar CloudVPN para conectar la subred del clúster de GKE con la red del clúster local.
• Si usas la CA de Istio, usa el mismo certificado raíz personalizado para todos los clústeres.

Antes de comenzar

En esta guía, se da por sentado que instalaste Anthos Service Mesh con la herramienta de asmcli. Necesitas asmcli y el paquete de configuración que asmcli descarga en el directorio que especificaste en --output_dir cuando ejecutaste asmcli install. Para obtener más información, consulta Instala herramientas dependientes y valida el clúster a fin de realizar lo siguiente:

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

Necesitas acceso a los archivos kubeconfig para todos los clústeres que configuras en la malla. En el caso del clúster de GKE, a fin de crear un archivo kubeconfig nuevo para el clúster, puedes exportar el entorno KUBECONFIG con la ruta de acceso completa del archivo como valor en tu terminal y generar la entrada de kubeconfig. .

Advertencia: Usa solo archivos kubeconfig de fuentes de confianza. Usar un archivo kubeconfig creado especialmente podría dar como resultado una ejecución de código malicioso o una exposición del archivo. Si debes usar un archivo kubeconfig no confiable, primero inspecciónalo con cuidado, como lo harías con una secuencia de comandos de shell.

Configura variables de entorno y marcadores de posición

Necesitas las siguientes variables de entorno para instalar la puerta de enlace este-oeste.

1. Crea una variable de entorno para el número de proyecto. En el siguiente comando, reemplaza FLEET_PROJECT_ID por el ID del proyecto host de la flota.

   export PROJECT_NUMBER=$(gcloud projects describe FLEET_PROJECT_ID --format="value(projectNumber)")
   

2. Crea una variable de entorno para el identificador de malla.

   export MESH_ID="proj-${PROJECT_NUMBER}"
   

3. Crea variables de entorno para los nombres de red.

   • Los clústeres de GKE se establecen de forma predeterminada con el siguiente nombre de red del clúster:

     export NETWORK_1="PROJECT_ID-CLUSTER_NETWORK"

   • Otros clústeres usan default:

     export NETWORK_2="default"

   Ten en cuenta que si instalaste Anthos Service Mesh en otros clústeres con valores diferentes para --network_id, debes pasar los mismos valores a NETWORK_2.

Instala la puerta de enlace este-oeste

1. Instala una puerta de enlace en CLUSTER_1 (tu clúster de GKE) que esté dedicada al tráfico este-oeste a CLUSTER_2 (tu clúster de múltiples nubes o local):

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID} \
       --network ${NETWORK_1}  \
       --revision asm-1167-22 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 install -y -f -
   

   Ten en cuenta que esta puerta de enlace es pública en Internet de forma predeterminada. Los sistemas de producción pueden requerir restricciones de acceso adicionales, por ejemplo, reglas de firewall, para evitar ataques externos.

2. Instala una puerta de enlace en CLUSTER_2 que esté dedicada al tráfico este-oeste para CLUSTER_1.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID} \
       --network ${NETWORK_2} \
       --revision asm-1167-22 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 install -y -f -
   

Expón servicios

Como los clústeres se encuentran en redes separadas, deberás exponer todos los servicios (\*.local) en la puerta de enlace este-oeste en ambos clústeres. Aunque esta puerta de enlace es pública en Internet, solo los servicios que tengan un certificado mTLS y un ID de carga de trabajo de confianza podrán acceder a los servicios subyacentes, como si estuvieran en la misma red.

Expón servicios a través de la puerta de enlace este-oeste para cada clúster

    kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \
        asm/istio/expansion/expose-services.yaml
    kubectl --kubeconfig=PATH_TO_KUBECONFIG_2 apply -n istio-system -f \
        asm/istio/expansion/expose-services.yaml

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

Ejecuta el comando asmcli create-mesh para habilitar la detección de extremos. 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 al límite de servicio de GKE Hub.

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

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 Anthos Service Mesh administrado, consulta Inserta 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).

Habilite la inyección de sidecar

Ubica el valor de la etiqueta de revisión, que usarás en pasos posteriores.

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

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.

   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 Anthos Service Mesh de varios clústeres con balanceo de cargas.

Limpia

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}