Configurar una malla multinube o híbrida

Vista previa — Hybrid and multi-cloud mesh

Esta función está sujetas a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Las funciones previas a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

En esta página se explica cómo configurar una malla multinube o híbrida para las siguientes plataformas:

• Híbrido: GKE on Google Cloud y Google Distributed Cloud (vista previa)
• Híbrido: GKE en Google Cloud y Google Distributed Cloud (vista previa)
• Multicloud: GKE On-Prem Google Cloud y Amazon EKS (vista previa)

Advertencia: Ponte en contacto con el equipo de Asistencia antes de configurar una malla multinube.

Nota sobre la plataforma: El comando asmcli create-mesh que usas para habilitar la detección de endpoints requiere que todos los clústeres de la malla sean una de las combinaciones de plataforma multicloud o híbrida de la lista anterior. No se admiten otras combinaciones de mallas multicloud o híbridas en otras plataformas. Cloud Service Mesh gestionado no se admite en mallas híbridas ni multinube.

Si sigues estas instrucciones, configurarás dos clústeres, pero puedes ampliar este proceso para incorporar cualquier número de clústeres a tu malla.

Requisitos previos

• Todos los clústeres deben registrarse en el mismo proyecto de host de flota.
• Todos los clústeres de GKE deben estar en una configuración de VPC compartida en la misma red.
• La dirección del plano de control de Kubernetes del clúster y la dirección de la puerta de enlace deben ser accesibles desde todos los clústeres de la malla. El proyecto en el que se encuentran los clústeres de GKE debe tener permiso para crear tipos de balanceo de carga externos. Google Cloud Te recomendamos que uses redes autorizadas y reglas de cortafuegos de VPC para restringir el acceso.
• No se admiten clústeres privados, incluidos los clústeres privados de GKE. Si usas clústeres locales, incluidos Google Distributed Cloud y Google Distributed Cloud, la dirección del plano de control de Kubernetes y la dirección de la puerta de enlace deben ser accesibles desde los pods de los clústeres de GKE. Te recomendamos que utilices CloudVPN para conectar la subred del clúster de GKE con la red del clúster on-premise.
• Si usas la AC de Istio, utiliza el mismo certificado raíz personalizado en todos los clústeres.

Antes de empezar

En esta guía se da por hecho que has instalado Cloud Service Mesh con la herramienta asmcli. Necesitas asmcli y el paquete de configuración que asmcli descarga en el directorio que especificaste en --output_dir al ejecutar asmcli install. Para obtener más información, consulta Instalar herramientas dependientes y validar el clúster para:

• Instalar las herramientas necesarias
• Descargar asmcli
• Conceder permisos de administrador de clústeres
• Validar el proyecto y el clúster

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

Advertencia: Utiliza solo archivos kubeconfig de fuentes de confianza. Si se usa un archivo kubeconfig especialmente diseñado, se podría ejecutar código malicioso o se podrían exponer archivos. Si debes usar un archivo kubeconfig que no sea de confianza, inspecciónalo primero con cuidado, como harías con un script de shell.

Configurar variables de entorno y marcadores de posición

Necesitas las siguientes variables de entorno cuando instales la pasarela este-oeste.

Crea variables de entorno para los nombres de las redes:

• Los clústeres de GKE usan de forma predeterminada el nombre de la red del clúster:

  export NETWORK_1="PROJECT_ID-CLUSTER_NETWORK"
  ``````
  

• Otros clústeres usan default:

  export NETWORK_2="default"
  ``````
  

Si has instalado Cloud Service Mesh en otros clústeres con valores diferentes para --network_id, debes pasar los mismos valores a NETWORK_2.

Instalar la pasarela este-oeste

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

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

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

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

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

Exponer servicios

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

Exponer servicios a través de la puerta de enlace este-oeste de 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

Habilitar el descubrimiento de endpoints

Nota: Para obtener más información sobre la detección de endpoints, consulta el artículo Detección de endpoints con varios planos de control.

Ejecuta el comando asmcli create-mesh para habilitar el descubrimiento de endpoints. En este ejemplo solo se muestran dos clústeres, pero puedes ejecutar el comando para habilitar el descubrimiento de endpoints en otros clústeres, sujeto al límite de servicio de GKE Hub.

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

Verificar la conectividad entre clústeres

Nota sobre la plataforma: Estos pasos solo se aplican si utilizas un plano de control en el clúster. En el caso de Cloud Service Mesh gestionado, consulta Inyectar proxies sidecar o Aplicar el plano de datos gestionado.

En esta sección se explica cómo desplegar los servicios de ejemplo HelloWorld y Sleep en tu entorno multiclúster para verificar que el balanceo de carga entre clústeres funciona.

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

Habilitar la inyección de sidecar

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

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

Usa el siguiente comando para localizar la etiqueta de revisión, que usarás en 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, anote el valor de la etiqueta de revisión istiod que sigue al prefijo istio.io/rev=. En este ejemplo, el valor es asm-173-3. Usa el valor de revisión en los pasos de la siguiente sección.

Instalar el servicio HelloWorld

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

1. Crea el espacio de nombres de ejemplo y la definición de servicio en cada clúster. En el siguiente comando, sustituye REVISION por la istiodetiqueta de revisión que has anotado en el 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
   

   donde REVISION es la etiqueta de revisión istiod que has indicado anteriormente.

   El resultado es el siguiente:

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

   Puedes ignorar label "istio-injection" not found. sin problema

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
   

Desplegar HelloWorld v1 y v2 en cada clúster

1. Implementa HelloWorld v1 en CLUSTER_1 y v2 en CLUSTER_2, lo que te ayudará más adelante a verificar el balanceo de carga 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. Confirma que HelloWorld v1 y v2 se están ejecutando con los siguientes comandos. Comprueba que el resultado sea similar al que se muestra:

   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

Desplegar el servicio de sueño

1. Despliega el servicio Sleep en ambos clústeres. Este pod 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. Comprueba que el resultado sea similar al que se muestra:

   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

Verificar el balanceo de carga entre clústeres

Llama al servicio HelloWorld varias veces y comprueba el resultado para verificar respuestas alternas de las versiones 1 y 2:

1. Llama al servicio de 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'
   

   La salida es similar a la que se muestra a continuación:

   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'
   

   La salida es similar a la que se muestra a continuación:

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

Enhorabuena, has verificado tu malla de servicios de Cloud con balanceo de carga y varios clústeres.

Limpieza

Cuando termines de verificar el balanceo de carga, elimina el servicio HelloWorld y Sleep de tu clúster.

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