Compila una malla de servicios de varios clústeres en GKE mediante una arquitectura de plano de control compartido en una única VPC

En este instructivo, se describe cómo implementar apps en varios clústeres de Kubernetes mediante una malla de servicios de varios clústeres de Istio. Una malla de servicios de varios clústeres de Istio permite que los servicios que se ejecutan en varios clústeres de Kubernetes se comuniquen de forma segura entre sí. Los clústeres de Kubernetes pueden ejecutarse en cualquier lugar, incluso en diferentes plataformas en la nube, por ejemplo, clústeres de Google Kubernetes Engine (GKE) que se ejecutan en Google Cloud o un clúster de Kubernetes en un centro de datos local.

Istio es una implementación de código abierto de una malla de servicios que te permite descubrir servicios que se ejecutan en clústeres de Kubernetes y enrutar y conectarte de forma segura y dinámica a ellos. Istio también proporciona un framework basado en políticas para enrutamiento, balanceo de cargas, limitación, telemetría, interrupción de circuitos, autenticación y autorización de llamadas de servicio en la malla con pocos cambios, o ninguno, en el código de la aplicación. Cuando Istio se instala en un clúster de Kubernetes, usa el registro de servicio de Kubernetes para descubrir y crear de forma automática una malla de servicios interconectados (o microservicios) que se ejecutan en el clúster.

Los componentes de Istio se pueden describir en términos de un plano de datos y un plano de control. El plano de datos es responsable de transportar el tráfico de red en la malla, y el plano de control es responsable de configurar y administrar la malla:

  • Plano de datos: Istio participa en la comunicación del servicio mediante la incorporación de un contenedor de archivo adicional para ejecutar un proxy en cada uno de los pods de los servicios en la malla. El archivo adicional ejecuta un proxy inteligente llamado Envoy para proporcionar enrutamiento, seguridad y observabilidad de los servicios.
  • Plano de control: Un componente llamado Pilot es responsable de proporcionar la configuración a los archivos adicionales de Envoy. Los certificados se asignan a cada servicio mediante un componente llamado Citadel.

Puede que los microservicios que se ejecutan en un clúster de Kubernetes necesiten comunicarse con microservicios que se ejecutan en otros clústeres de Kubernetes. Por ejemplo, puede que los microservicios necesiten comunicarse entre regiones y entornos, y puede que los propietarios de los microservicios mantengan sus propios clústeres de Kubernetes. Istio te permite crear una malla de servicios más allá de un único clúster de Kubernetes para incluir microservicios que se ejecutan en clústeres remotos y microservicios externos que se ejecutan en VM, fuera de Kubernetes.

Istio proporciona dos opciones de configuración principales para implementaciones de varios clústeres:

La configuración del plano de control compartido de Istio usa un plano de control de Istio que se ejecuta en uno de los clústeres. El Pilot del plano de control administra la configuración del servicio en los clústeres locales y remotos, y configura los archivos adicionales de Envoy para todos los clústeres. Esta configuración da como resultado una sola malla de servicios de Istio que abarca los servicios que se ejecutan en varios clústeres de Kubernetes. En una configuración de plano de control compartido, el Pilot que se ejecuta en el clúster del plano de control de Istio debe tener acceso a todos los pods que se ejecutan en cada clúster a través de su dirección IP.

Puedes lograr la conectividad de direcciones IP de pod a pod entre los clústeres de las siguientes maneras:

  1. Puedes crear todos los clústeres en una red plana, por ejemplo, de una sola VPC, mediante reglas de firewall que permitan la conectividad de direcciones IP de pod a pod entre clústeres. Los clústeres también pueden existir en redes VPN conectadas. En cualquier caso, el pod de Pilot en el clúster de control puede acceder a todos los pods de los clústeres remotos directamente a través de las direcciones IP del pod.
  2. Los clústeres no están en una sola red y dependen de un mecanismo diferente para que el pod de Pilot en el clúster de control llegue a los pods en clústeres remotos. En esta situación, el pod de Pilot no puede acceder a otros pods directamente con las IP de pods, por lo que debes usar puertas de enlace de entrada de Istio para lograr la conectividad de red entre clústeres en redes dispares.

En este instructivo, implementarás Istio en dos clústeres de GKE mediante una arquitectura de plano de control compartido en una sola red de VPC. El pod de Pilot del clúster de plano de control de Istio tendrá conectividad de dirección IP directa con los pods que se ejecutan en el clúster remoto. En este instructivo, usarás una aplicación de microservicios de demostración de 10 niveles llamada Online Boutique que se divide en dos clústeres de GKE. Los microservicios están escritos en diferentes lenguajes de programación. Para ver el lenguaje de cada microservicio, consulta la página README.

Debes compilar la siguiente arquitectura dentro de un proyecto de Google Cloud.

Arquitectura que implementa 10 microservicios en dos clústeres.

En esta arquitectura, tienes un clúster control y un clúster remote. El plano de control de Istio se implementa en el clúster control. Los clústeres se comunican con varios microservicios de forma local (en el mismo clúster) y no local (en el otro clúster).

Objetivos

  • Crear dos clústeres de GKE, control y remote, en una sola VPC
  • Instalar Istio en modo de varios clústeres en ambos clústeres de GKE y, además, implementar el plano de control de Istio en el clúster control
  • Instalar la aplicación Online Boutique dividida en ambos clústeres
  • Observar la malla de servicios expandida en ambos clústeres

Costos

En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud sean aptos para obtener una prueba gratuita.

Cuando finalices este instructivo, podrás borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta cómo hacer una limpieza.

Antes de comenzar

  1. Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
  2. En la página del selector de proyectos de Google Cloud Console, selecciona o crea un proyecto de Google Cloud.

    Ir al selector de proyectos

  3. Comprueba que la facturación esté habilitada en tu proyecto.

    Descubre cómo puedes habilitar la facturación

  4. Habilita las API de GKE and Cloud Source Repositories.

    Habilita las API

  5. En la página del selector de proyectos de Google Cloud Console, selecciona o crea un proyecto de Google Cloud.

    Ir al selector de proyectos

  6. Comprueba que la facturación esté habilitada en tu proyecto.

    Descubre cómo puedes habilitar la facturación

  7. Habilita las API de GKE and Cloud Source Repositories.

    Habilita las API

Configura tu entorno

Ejecuta todos los comandos de terminal en este instructivo desde Cloud Shell.

  1. En Google Cloud Console, abre Cloud Shell.

    Abrir Cloud Shell

  2. Si deseas descargar los archivos necesarios para este instructivo, clona el siguiente repositorio de GitHub:

    cd $HOME
    git clone https://github.com/GoogleCloudPlatform/istio-multicluster-gke.git
    
  3. Convierte la carpeta de repositorio en tu carpeta $WORKDIR desde la que realizas todas las tareas relacionadas con este instructivo:

    cd $HOME/istio-multicluster-gke
    WORKDIR=$(pwd)
    

    Puedes borrar la carpeta cuando termines el instructivo.

  4. Instala kubectx/kubens:

    git clone https://github.com/ahmetb/kubectx $WORKDIR/kubectx
    export PATH=$PATH:$WORKDIR/kubectx
    

    Estas herramientas facilitan el trabajo con varios clústeres de Kubernetes, ya que cambian contextos o espacios de nombres.

Crea clústeres de GKE

En esta sección, crearás dos clústeres de GKE en la VPC predeterminada con alias de direcciones IP habilitadas. Con los rangos de alias de IP, los clústeres de GKE pueden asignar direcciones IP desde un bloque CIDR conocido por Google Cloud. Esta configuración hace que las direcciones IP del pod se puedan enrutar de forma nativa dentro de la VPC, lo que permite que los pods de diferentes clústeres tengan conectividad de dirección IP directa.

  1. En Cloud Shell, crea dos clústeres de GKE: un clúster llamado control en el que está instalado el plano de control de Istio y un segundo clúster llamado remote para agregarlo a la malla de servicios de varios clústeres de Istio. Puedes crear ambos clústeres en la VPC predeterminada, pero en regiones diferentes.

    gcloud container clusters create control --zone us-west2-a \
        --machine-type "e2-standard-4" --disk-size "100" \
        --num-nodes "4" --network "default" --enable-ip-alias --async
    
    gcloud container clusters create remote --zone us-central1-f \
        --machine-type "e2-standard-4" --disk-size "100" \
        --num-nodes "4" --network "default" --enable-ip-alias
    
  2. Espera unos minutos hasta que se creen ambos clústeres. Verifica que el estado de cada clúster sea RUNNING:

    gcloud container clusters list
    

    El resultado es similar al siguiente:

    NAME     LOCATION       MASTER_VERSION   MASTER_IP      MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
    remote   us-central1-f  1.19.9-gke.1400  34.70.12.109   e2-standard-4  1.19.9-gke.1400  4          RUNNING
    control  us-west2-a     1.19.9-gke.1400  34.94.220.232  e2-standard-4  1.19.9-gke.1400  4          RUNNING
    
  3. Establece la variable KUBECONFIG a fin de usar un nuevo archivo kubeconfig para este instructivo:

    touch ${WORKDIR}/istiokubecfg
    export KUBECONFIG=${WORKDIR}/istiokubecfg
    
  4. Conéctate a ambos clústeres para generar entradas en el archivo kubeconfig:

    export PROJECT_ID=$(gcloud info --format='value(config.project)')
    gcloud container clusters get-credentials control --zone us-west2-a --project ${PROJECT_ID}
    gcloud container clusters get-credentials remote --zone us-central1-f --project ${PROJECT_ID}
    

    Se usa un archivo kubeconfig para la autenticación de clústeres. Después de crear el archivo kubeconfig, puedes cambiar el contexto entre clústeres con rapidez.

  5. Usa kubectx a fin de cambiar el nombre de los contextos para mayor comodidad:

    kubectx control=gke_${PROJECT_ID}_us-west2-a_control
    kubectx remote=gke_${PROJECT_ID}_us-central1-f_remote
    

Configura Herramientas de redes

En esta sección, configuras las rutas de VPC para permitir que los pods en ambos clústeres tengan conectividad de dirección IP directa. Cuando habilitas rangos de alias de IP en clústeres de GKE, se crean dos subredes secundarias para cada clúster. La subred principal se usa para las direcciones IP de nodo, y las dos subredes secundarias se usan para las direcciones IP de CIDR de pod y de servicio.

  1. En Cloud Shell, inspecciona las direcciones IP secundarias para ambos clústeres:

    gcloud compute networks subnets describe default --region=us-west2 --format=json | jq '.secondaryIpRanges[]'
    gcloud compute networks subnets describe default --region=us-central1 --format=json | jq '.secondaryIpRanges[]'
    

    Para el clúster control, el resultado es similar al siguiente:

    {
      "ipCidrRange": "10.56.0.0/14",
      "rangeName": "gke-control-pods-47496b0c"
    }
    {
      "ipCidrRange": "10.0.0.0/20",
      "rangeName": "gke-control-services-47496b0c"
    }
    

    Para el clúster remote, el resultado es similar al siguiente:

    {
      "ipCidrRange": "10.0.16.0/20",
      "rangeName": "gke-remote-services-66101313"
    }
    {
      "ipCidrRange": "10.60.0.0/14",
      "rangeName": "gke-remote-pods-66101313"
    }
    
  2. Almacena el rango de IP del Pod de los clústeres y el rango de direcciones IP principal en las variables para usarlos más adelante:

    CONTROL_POD_CIDR=$(gcloud container clusters describe control --zone us-west2-a --format=json | jq -r '.clusterIpv4Cidr')
    REMOTE_POD_CIDR=$(gcloud container clusters describe remote --zone us-central1-f --format=json | jq -r '.clusterIpv4Cidr')
    CONTROL_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-west2 --format=json | jq -r '.ipCidrRange')
    REMOTE_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-central1 --format=json | jq -r '.ipCidrRange')
    
  3. Crea una variable de lista para todos los rangos de IP de CIDR:

    ALL_CLUSTER_CIDRS=$CONTROL_POD_CIDR,$REMOTE_POD_CIDR,$CONTROL_PRIMARY_CIDR,$REMOTE_PRIMARY_CIDR
    

    Necesitas que todos los nodos se puedan comunicar entre sí y con los rangos de CIDR del pod.

  4. Almacena las etiquetas de red de los nodos del clúster en una variable:

    ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --format=json | jq -r '.[].tags.items[0]' | uniq | awk -vORS=, '{ print $1 }' | sed 's/,$/\n/')
    

    Usarás estas etiquetas de red más adelante en las reglas de firewall.

  5. Crea una regla de firewall que permita el tráfico entre los nodos y rangos de CIDR del pod de los clústeres:

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

Instala Istio en ambos clústeres de GKE

En esta sección, debes usar Istio Operator para instalar y configurar Istio en una configuración de varios clústeres en ambos clústeres de GKE.

  1. En Cloud Shell, descarga Istio:

    cd ${WORKDIR}
    export ISTIO_VER=1.9.5
    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VER} TARGET_ARCH=x86_64 sh -
    

    En producción, recomendamos que integres una versión de la app en el código (es decir, usa el número de versión de una versión conocida y probada) a fin de garantizar un comportamiento coherente.

La implementación de una malla de servicios de varios clústeres requiere que establezcas la confianza entre todos los clústeres de la malla. Puedes usar una autoridad certificadora (CA) raíz común para generar certificados intermedios para los diversos clústeres. De forma predeterminada, todos los clústeres crean certificados autofirmados. Todas las cargas de trabajo dentro de una malla usan una CA raíz como raíz de confianza. Cada CA de Istio usa una clave y un certificado intermedios de firma de CA, firmados por la CA raíz. Cuando existen varias CA de Istio dentro de una malla, se establece una jerarquía de confianza entre las CA. El repositorio de Istio incluye certificados de muestra que puedes usar solo con fines educativos. Dentro de cada clúster, debes crear el espacio de nombres istio-system y un secreto llamado cacrts con los certificados de clúster adecuados que creaste antes.

  1. Crea un espacio de nombres istio-system y secretos cacerts en ambos clústeres de GKE:

    kubectl --context control create namespace istio-system
    kubectl --context control create secret generic cacerts -n istio-system \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
    kubectl --context remote create namespace istio-system
    kubectl --context remote create secret generic cacerts -n istio-system \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
    
  2. Crea la configuración de Istio para el clúster control:

    cat <<EOF > ${WORKDIR}/istio_control.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    metadata:
      name: istio-control
    spec:
      values:
        global:
          meshID: mesh1
          multiCluster:
            clusterName: control
          network: network1
      components:
        ingressGateways:
          - name: istio-eastwestgateway
            label:
              istio: eastwestgateway
              app: istio-eastwestgateway
              topology.istio.io/network: network1
            enabled: true
            k8s:
              env:
                # sni-dnat adds the clusters required for AUTO_PASSTHROUGH mode
                - name: ISTIO_META_ROUTER_MODE
                  value: "sni-dnat"
                # traffic through this gateway should be routed inside the network
                - name: ISTIO_META_REQUESTED_NETWORK_VIEW
                  value: network1
              serviceAnnotations:
                cloud.google.com/load-balancer-type: "Internal"
                networking.gke.io/internal-load-balancer-allow-global-access: "true"
              service:
                ports:
                  - name: status-port
                    port: 15021
                    targetPort: 15021
                  - name: tls
                    port: 15443
                    targetPort: 15443
                  - name: tls-istiod
                    port: 15012
                    targetPort: 15012
                  - name: tls-webhook
                    port: 15017
                    targetPort: 15017
    EOF
    
  3. Instala el plano de control de Istio en el clúster control:

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context control -f ${WORKDIR}/istio_control.yaml
    

    Ingresa y para continuar con la instalación. Istio tarda entre 2 y 3 minutos en instalarse.

  4. Verifica que todas las implementaciones de Istio estén en ejecución:

    kubectl --context control get pods -n istio-system
    

    Istio está listo cuando todos los pods están en ejecución o se completaron.

    El resultado es similar al siguiente:

    NAME                                     READY   STATUS    RESTARTS   AGE
    istio-eastwestgateway-69b49b9785-f5msp   1/1     Running   0          9m11s
    istio-ingressgateway-5c65f88f66-rdd2r    1/1     Running   0          52m
    istiod-6c56d9cbd8-k9klt                  1/1     Running   0          52m
    
  5. Espera hasta que se asigne una dirección IP externa al servicio istio-eastwestgateway. Inspecciona la dirección IP externa de istio-eastwestgateway:

    kubectl --context control get svc istio-eastwestgateway -n istio-system
    

    El resultado es similar al siguiente:

    NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                                                           AGE
    istio-eastwestgateway   LoadBalancer   10.60.7.19   10.168.0.6    15021:31557/TCP,15443:30306/TCP,15012:31791/TCP,15017:32341/TCP   14m
    

    Ten en cuenta que la dirección IP externa es una dirección IP del balanceador de cargas interno. Necesitas un balanceador de cargas interno, ya que ambos clústeres están en la misma VPC y se pueden comunicar a través de un balanceador de cargas interno.

  6. Expón el servicio istiod en el indicador control mediante la puerta de enlace istio-eastwestgateway y un VirtualService. Los proxies Envoy del clúster remote deben poder comunicarse con el servicio istiod en el clúster de control. Para crear la puerta de enlace y VirtualService, ejecuta el siguiente comando:

    kubectl --context control apply -f ${WORKDIR}/istio-"${ISTIO_VER}"/samples/multicluster/expose-istiod.yaml
    

    El resultado es similar al siguiente:

    gateway.networking.istio.io/istiod-gateway created
    virtualservice.networking.istio.io/istiod-vs created
    

    Otorga al plano de control de Istio en el clúster control acceso al servidor de la API del clúster remote. Esto permite las siguientes acciones:

    1. Permite que el plano de control autentique las solicitudes de conexión desde cargas de trabajo que se ejecutan en el clúster remote. Sin acceso al servidor de la API, el plano de control rechazará las solicitudes.
    2. Habilita el descubrimiento de extremos de servicio que se ejecutan en el clúster remote.
  7. Ejecuta el siguiente comando para otorgar al plano de control de Istio en el clúster control acceso al servidor de la API del clúster remote.

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl x create-remote-secret \
    --context=remote \
    --name=remote | \
    kubectl apply -f - --context=control
    

    El resultado es similar al siguiente:

    secret/istio-remote-secret-remote created
    

    En los próximos pasos, debes configurar el clúster control con permisos para acceder a los recursos en el clúster remote.

    El plano de control de Istio requiere acceso a todos los clústeres de la malla para descubrir los atributos de los servicios, extremos y pods. Si quieres obtener este acceso, crea un archivo kubeconfig para el clúster remote que se agregó como un secreto en el clúster control. El gráfico de Helm istio-remote crea una cuenta de servicio de Kubernetes llamada istio-multi en el clúster remote con el acceso mínimo requerido de control de acceso según la función (RBAC). Los siguientes pasos generan el archivo kubeconfig del clúster remote mediante las credenciales de la cuenta de servicio istio-multi.

  8. Obtén la dirección de ILB istio-eastwestgateway:

    export DISCOVERY_ADDRESS=$(kubectl --context control -n istio-system get svc istio-eastwestgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    

    Los proxies de sidecar de Envoy que se ejecutan en el clúster remote usan esta dirección para conectarse a istiod en el clúster control.

  9. Crea la configuración de Istio para el clúster remote:

    cat <<EOF > ${WORKDIR}/istio_remote.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      profile: remote
      values:
        global:
          meshID: mesh1
          multiCluster:
            clusterName: remote
          network: network1
          remotePilotAddress: ${DISCOVERY_ADDRESS}
    EOF
    
  10. Instala Istio en el clúster remote:

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context=remote -f ${WORKDIR}/istio_remote.yaml
    

    Ingresa y para continuar con la instalación. Istio tarda entre 2 y 3 minutos en instalarse.

  11. Inspecciona la implementación de Istio en el clúster remote:

    kubectl --context remote -n istio-system get pods
    

    El resultado es similar al siguiente:

    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-c68779485-4fpmm   1/1     Running   0          3m50s
    istiod-866555cf49-w6qsx                1/1     Running   0          3m57s
    

    Los dos clústeres ahora están configurados con el clúster de control, que proporciona el plano de control de Istio al clúster remote. En la siguiente sección, implementarás una división de aplicación de muestra entre los dos clústeres.

Implementa la app de Online Boutique

En esta sección, instalarás la aplicación Online Boutique en ambos clústeres.

  1. En Cloud Shell, crea el espacio de nombres online-boutique en ambos clústeres:

    for cluster in $(kubectx);
    do
        kubectx $cluster;
        kubectl create namespace online-boutique;
    done
    
  2. Etiqueta el espacio de nombres online-boutique en ambos clústeres para la inyección del proxy del archivo adicional automática de Istio:

    for cluster in $(kubectx);
    do
        kubectx $cluster;
        kubectl label namespace online-boutique istio-injection=enabled
    done
    

    En este paso, se garantiza que todos los pods que se crean en el espacio de nombres online-boutique tengan implementado el contenedor del archivo adicional Envoy.

  3. Instala los recursos de la app de Online Boutique en el clúster control:

    kubectl --context control -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/control
    

    El resultado es similar al siguiente:

    deployment.apps/emailservice created
    deployment.apps/checkoutservice created
    deployment.apps/frontend created
    deployment.apps/paymentservice created
    deployment.apps/productcatalogservice created
    deployment.apps/currencyservice created
    deployment.apps/shippingservice created
    deployment.apps/adservice created
    gateway.networking.istio.io/frontend-gateway created
    virtualservice.networking.istio.io/frontend-ingress created
    serviceentry.networking.istio.io/currency-provider-external created
    virtualservice.networking.istio.io/frontend created
    serviceentry.networking.istio.io/whitelist-egress-googleapis created
    service/emailservice created
    service/checkoutservice created
    service/recommendationservice created
    service/frontend created
    service/paymentservice created
    service/productcatalogservice created
    service/cartservice created
    service/currencyservice created
    service/shippingservice created
    service/redis-cart created
    service/adservice created
    
  4. Instala los recursos de la app de Online Boutique en el clúster remote:

    kubectl --context remote -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/remote
    

    El resultado es similar al siguiente:

    deployment.apps/loadgenerator created
    deployment.apps/cartservice created
    deployment.apps/recommendationservice created
    service/emailservice created
    service/checkoutservice created
    service/recommendationservice created
    service/frontend created
    service/paymentservice created
    service/productcatalogservice created
    service/cartservice created
    service/currencyservice created
    service/shippingservice created
    service/redis-cart created
    service/adservice created
    
  5. Verifica que todas las cargas de trabajo se ejecuten en el clúster control:

    kubectl --context control -n online-boutique get pods
    

    El resultado es similar a este:

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-5db678b487-zs6g9               2/2     Running   0          69s
    checkoutservice-b5b8858c7-djnzk          2/2     Running   0          70s
    currencyservice-954d8c5f-mv7kh           2/2     Running   0          70s
    emailservice-5c5555556b-9jk59            2/2     Running   0          71s
    frontend-6fbb48ffc6-gmnsv                2/2     Running   0          70s
    paymentservice-5684b97df7-l9ccn          2/2     Running   0          70s
    productcatalogservice-55479b967c-vqw6w   2/2     Running   0          70s
    shippingservice-59bd8c7b8c-wln4v         2/2     Running   0          69s
    
  6. Verifica que todas las cargas de trabajo se ejecuten en el clúster remote:

    kubectl --context remote -n online-boutique get pods
    

    El resultado es similar al siguiente:

    NAME                                     READY   STATUS    RESTARTS   AGE
    cartservice-5db5d5c5f9-vvwgx             2/2     Running   0          63s
    loadgenerator-8bcfd68db-gmlfk            2/2     Running   0          63s
    recommendationservice-859c7c66d5-f2x9m   2/2     Running   0          63s
    

El resultado de los dos pasos anteriores muestra que los microservicios de la app de Online Boutique se dividen entre los clústeres control y remote.

Accede a la aplicación de Online Boutique

  1. En Cloud Shell, obtén la dirección IP de la puerta de enlace de entrada de Istio para el clúster control:

    kubectl --context control get -n istio-system service istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip'
    

    El resultado muestra la dirección IP de la puerta de enlace de entrada de Istio.

  2. Copia y pega la dirección IP de la puerta de enlace de entrada de Istio en una pestaña del navegador web y, luego, actualiza la página. Verás la página principal de Online Boutique.

    Página principal de Online Boutique, en la que se muestran imágenes de varios productos, como bicicletas, cámaras, máquinas de escribir y demás.

    Navega por la app, explora varios productos, colócalos en tu carrito, paga, y mucho más.

    Observa que la aplicación Online Boutique es completamente funcional y se ejecuta en dos clústeres de Kubernetes en dos entornos.

Supervisa la malla de servicios

Puedes usar Kiali para visualizar la malla de servicios. Kiali es una herramienta de observabilidad de malla de servicios. Para usar Kiali, debes instalar Prometheus y Kiali en el clúster control.

  1. Implementa los complementos de Prometheus y Kiali en el clúster de control:

    kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VER:0:3}/samples/addons/prometheus.yaml
    kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VER:0:3}/samples/addons/kiali.yaml
    

    Si la instalación de Kiali falla con errores, intente ejecutar el mismo comando nuevamente. Pueden existir algunos problemas de sincronización que se resolverán cuando el comando vuelva a ejecutarse.

  2. Asegúrate de que los Pods de Prometheus y Kiali estén en ejecución:

    kubectl --context control get pods -n istio-system
    

    El resultado es similar al siguiente:

    kiali-cb9fb9554-x2r5z                    1/1     Running   0          7m46s
    prometheus-6d87d85c88-zv8cr              2/2     Running   0          3m57s
    
  3. En Cloud Shell, expone Kiali en el clúster control:

    kubectl --context control port-forward svc/kiali 8080:20001 -n istio-system --context control >> /dev/null &
    
  4. Abre la interfaz web de Kiali en el clúster control. Selecciona Web Preview y, luego, Preview on port 8080.

  5. En la ventana de acceso de Kiali, accede con el nombre de usuario admin y la contraseña admin.

  6. En el menú, selecciona Graph.

  7. En la lista desplegable Seleccionar un espacio de nombres, selecciona online-boutique.

  8. En el menú Gráfico, selecciona Service graph.

  9. De manera opcional, desde el menú Display, selecciona Cluster Boxes y Traffic Animation para ver como loadgenerator genera tráfico a la app.

    Animación de tráfico que muestra cómo el “loadgenerator” genera tráfico a la app.

En la imagen anterior, se muestra una malla de servicios de Istio compartida para microservicios que se distribuyen en dos clústeres. Sin importar el clúster, a medida que se agregan microservicios nuevos, se descubren de forma automática y se agregan a la malla. La conectividad de red plana permite la flexibilidad de tener varios clústeres y, a la vez, adapta la facilidad de gobernar todos los microservicios mediante un plano de control compartido.

Limpia

Una vez que completaste el instructivo, borra los recursos que creaste en Google Cloud a fin de que no se te cobre por ellos en el futuro. En las siguientes secciones, se describe cómo borrar estos recursos.

Borra el proyecto

  1. En Cloud Console, ve a la página Administrar recursos.

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Restablece kubeconfig

  • Anula la variable KUBECONFIG:

    unset KUBECONFIG
    rm ${WORKDIR}/istiokubecfg
    

¿Qué sigue?