Del perímetro a la malla: Implementa aplicaciones de la malla de servicios a través la puerta de enlace de GKE

Last reviewed 2024-01-31 UTC

En esta implementación, se muestra cómo combinar Cloud Service Mesh con Cloud Load Balancing para exponer aplicaciones en una malla de servicios a los clientes de Internet.

Puedes exponer una aplicación a los clientes de muchas maneras, según su ubicación. Esta implementación te muestra cómo exponer una aplicación a los clientes combinando Cloud Load Balancing con Cloud Service Mesh para integrar balanceadores de cargas con una malla de servicios. Esta implementación está destinada a profesionales avanzados que ejecutan Cloud Service Mesh, pero también funciona para Istio en Google Kubernetes Engine.

Arquitectura

En el siguiente diagrama, se muestra cómo puedes usar las puertas de enlace de entrada de la malla para integrar los balanceadores de cargas en una malla de servicios:

Nota: Para las aplicaciones en Cloud Service Mesh, la implementación del balanceador de cargas TCP/UDP externo es el tipo de exposición predeterminado. Debes implementar el balanceador de cargas a través del Service de Kubernetes, que selecciona los Pods de los proxies de entrada de la malla.

En la topología del diagrama anterior, la capa de entrada de la nube, que se programa a través de la puerta de enlace de GKE, origina el tráfico desde el exterior de la malla de servicios y lo dirige a la capa de entrada de la malla. Luego, la capa de entrada de la malla dirige el tráfico a los backends de aplicaciones alojadas en la malla.

La topología anterior tiene las siguientes consideraciones:

• Entrada de la nube: En esta arquitectura de referencia, debes configurar el balanceador de cargas deGoogle Cloud a través de la puerta de enlace de GKE para verificar el estado de los proxies de entrada de la malla en sus puertos de verificación de estado expuestos.
• Entrada de la malla: en la aplicación de la malla, debes realizar verificaciones de estado directamente en los backends, de modo que puedas ejecutar el balanceo de cargas y la administración de tráfico de forma local.

En el diagrama anterior, se ilustra la encriptación HTTPS del cliente al balanceador de cargas de Google Cloud , del balanceador de cargas al proxy de entrada de la malla y del proxy de entrada al proxy de sidecar.

Objetivos

• Implementa un clúster de Google Kubernetes Engine (GKE) en Google Cloud.
• Implementa un Cloud Service Mesh basado en Istio en tu clúster de GKE.
• Configura la puerta de enlace de GKE para finalizar el tráfico de HTTPS público y dirigir ese tráfico a las aplicaciones alojadas en la malla de servicios
• Implementar la aplicación Online Boutique en el clúster de GKE que expones a los clientes en Internet

Optimización de costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• Google Kubernetes Engine
• Compute Engine
• Cloud Load Balancing
• Certificate Manager
• Cloud Service Mesh
• Google Cloud Armor
• Cloud Endpoints

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 califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Make sure that billing is enabled for your Google Cloud project.

3. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   Ejecuta todos los comandos de terminal de esta implementación desde Cloud Shell.

4. Actualiza a la versión más reciente de Google Cloud CLI:

   gcloud components update
   

5. Establece tu proyecto predeterminado de Google Cloud :

   export PROJECT=PROJECT
   export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
   gcloud config set project ${PROJECT}
   

   Reemplaza PROJECT por el ID del proyecto que deseas usar para esta implementación.

6. Crea un directorio de trabajo:

   mkdir -p ${HOME}/edge-to-mesh
   cd ${HOME}/edge-to-mesh
   export WORKDIR=`pwd`
   

   Después de finalizar esta implementación, puedes borrar el directorio de trabajo.

Crea clústeres de GKE

Las funciones que se describen en esta implementación requieren una versión 1.16 o posterior del clúster de GKE.

1. En Cloud Shell, crea un archivo kubeconfig nuevo. Con este paso te aseguras de no causar un conflicto con el archivo kubeconfig (predeterminado) existente.

   touch edge2mesh_kubeconfig
   export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
   

2. Define las variables de entorno para el clúster de GKE:

   export CLUSTER_NAME=edge-to-mesh
   export CLUSTER_LOCATION=us-central1
   

3. Habilita la API de Google Kubernetes Engine:

   gcloud services enable container.googleapis.com
   

4. Crea un clúster de GKE Autopilot:

   gcloud container --project ${PROJECT} clusters create-auto \
   ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid
   

5. Asegúrate de que el clúster esté en ejecución:

   gcloud container clusters list
   

   El resultado es similar al siguiente:

   NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
   edge-to-mesh  us-central1  1.27.3-gke.1700   34.122.84.52  e2-medium  1.27.3-gke.1700   3          RUNNING
   

Instala una malla de servicios

En esta sección, debes configurar Cloud Service Mesh administrado con la API de Fleet.

1. En Cloud Shell, habilita las APIs requeridas:

   gcloud services enable mesh.googleapis.com
   

2. Habilita Cloud Service Mesh en la flota:

   gcloud container fleet mesh enable
   

3. Registra el clúster en la flota:

   gcloud container fleet memberships register ${CLUSTER_NAME} \
     --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME}
   

4. Aplica la etiqueta mesh_id al clúster edge-to-mesh:

   gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}
   

5. Habilita la administración automática del plano de control y el plano de datos administrados:

   gcloud container fleet mesh update \
     --management automatic \
     --memberships ${CLUSTER_NAME}
   

6. Después de unos minutos, verifica que el estado del plano de control sea ACTIVE:

   gcloud container fleet mesh describe
   

   El resultado es similar al siguiente:

   ...
   membershipSpecs:
     projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
       mesh:
         management: MANAGEMENT_AUTOMATIC
   membershipStates:
     projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
       servicemesh:
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed-rapid'
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
         code: OK
         description: 'Revision(s) ready for use: asm-managed-rapid.'
         updateTime: '2023-08-04T02:54:39.495937877Z'
   name: projects/e2m-doc-01/locations/global/features/servicemesh
   resourceState:
     state: ACTIVE
   ...
   

Implementa la puerta de enlace de GKE

En los siguientes pasos, implementarás el balanceador de cargas de aplicaciones externo a través de GKE Gateway Controller. El recurso de puerta de enlace de GKE automatiza el aprovisionamiento del balanceador de cargas y la verificación de estado del backend. Además, usarás el Administrador de certificados para aprovisionar y administrar un certificado TLS, y Endpoints para aprovisionar de forma automática un nombre de DNS público para la aplicación.

Instala una puerta de enlace de entrada de la malla de servicios

Como práctica recomendada de seguridad, te recomendamos que implementes la puerta de enlace de entrada en un espacio de nombres diferente en el plano de control.

1. En Cloud Shell, crea un espacio de nombres asm-ingress dedicado:

   kubectl create namespace asm-ingress
   

2. Agrega una etiqueta de espacio de nombres al espacio de nombres asm-ingress:

   kubectl label namespace asm-ingress istio-injection=enabled
   

   El resultado es similar a este:

   namespace/asm-ingress labeled
   

   Si etiquetas el espacio de nombres asm-ingress con istio-injection=enabled, se indica a Cloud Service Mesh que inserte de manera automática proxies de sidecar de Envoy cuando se implementa una aplicación.

3. Crea un certificado autofirmado que usa la puerta de enlace de entrada para finalizar las conexiones TLS entre el balanceador de cargas de Google Cloud (que se configurará más adelante a través del controlador de GKE Gateway) y la puerta de enlace de entrada, y almacena el certificado autofirmado como un Secret de Kubernetes:

   openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
    -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \
    -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \
    -out frontend.endpoints.${PROJECT}.cloud.goog.crt
   
   kubectl -n asm-ingress create secret tls edge2mesh-credential \
    --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
    --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
   

   Para obtener más detalles sobre los requisitos para el certificado de puerta de enlace de entrada, consulta la guía de consideraciones del protocolo de backend seguro.

4. Ejecuta los siguientes comandos para crear el YAML del recurso de la puerta de enlace de entrada:

   mkdir -p ${WORKDIR}/asm-ig/base
   cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
   EOF
   
   mkdir ${WORKDIR}/asm-ig/variant
   cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: asm-ingressgateway
   subjects:
     - kind: ServiceAccount
       name: asm-ingressgateway
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml
   apiVersion: v1
   kind: Service
   metadata:
     name: asm-ingressgateway
   spec:
     ports:
     - name: status-port
       port: 15021
       protocol: TCP
       targetPort: 15021
     - name: http
       port: 80
       targetPort: 8080
     - name: https
       port: 443
       targetPort: 8443
       appProtocol: HTTP2
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: asm-ingressgateway
   spec:
     servers:
     - port:
         number: 443
         name: https
         protocol: HTTPS
       hosts:
       - "*" # IMPORTANT: Must use wildcard here when using SSL, as SNI isn't passed from GFE
       tls:
         mode: SIMPLE
         credentialName: edge2mesh-credential
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml
   namespace: asm-ingress
   resources:
   - ../base
   - role.yaml
   - rolebinding.yaml
   patches:
   - path: service-proto-type.yaml
     target:
       kind: Service
   - path: gateway.yaml
     target:
       kind: Gateway
   EOF
   

5. Aplica las CRD de la puerta de enlace de entrada:

   kubectl apply -k ${WORKDIR}/asm-ig/variant
   

6. Asegúrate de que todas las implementaciones estén en funcionamiento:

   kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress
   

   El resultado es similar al siguiente:

   deployment.apps/asm-ingressgateway condition met
   

Aplica una verificación de estado de la puerta de enlace de entrada de la malla de servicios

Cuando se integra una puerta de enlace de entrada de malla de servicios a un balanceador de cargas de aplicaciones de Google Cloud , el balanceador de cargas de aplicaciones se debe configurar para realizar verificaciones de estado en los Pods de la puerta de enlace de entrada. La CRD HealthCheckPolicy proporciona una API para configurar esa verificación de estado.

1. En Cloud Shell, crea el archivo HealthCheckPolicy.yaml:

   cat <<EOF >${WORKDIR}/ingress-gateway-healthcheck.yaml
   apiVersion: networking.gke.io/v1
   kind: HealthCheckPolicy
   metadata:
     name: ingress-gateway-healthcheck
     namespace: asm-ingress
   spec:
     default:
       checkIntervalSec: 20
       timeoutSec: 5
       #healthyThreshold: HEALTHY_THRESHOLD
       #unhealthyThreshold: UNHEALTHY_THRESHOLD
       logConfig:
         enabled: True
       config:
         type: HTTP
         httpHealthCheck:
           #portSpecification: USE_NAMED_PORT
           port: 15021
           portName: status-port
           #host: HOST
           requestPath: /healthz/ready
           #response: RESPONSE
           #proxyHeader: PROXY_HEADER
       #requestPath: /healthz/ready
       #port: 15021
     targetRef:
       group: ""
       kind: Service
       name: asm-ingressgateway
   EOF
   

2. Aplica el HealthCheckPolicy:

   kubectl apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   

Define políticas de seguridad

Google Cloud Armor proporciona defensa contra DSD y políticas de seguridad personalizables que puedes adjuntar a un balanceador de cargas a través de los recursos de Ingress. En los siguientes pasos, crearás una política de seguridad que use reglas preconfiguradas para bloquear ataques de secuencia de comandos entre sitios (XSS). Esta regla ayuda a bloquear el tráfico que coincide con las firmas de ataques conocidas, pero permite el resto del tráfico. Tu entorno puede usar reglas diferentes según la carga de trabajo.

1. En Cloud Shell, crea una política de seguridad llamada edge-fw-policy:

   gcloud compute security-policies create edge-fw-policy \
     --description "Block XSS attacks"
   

2. Crea una regla de política de seguridad que use los filtros de XSS preconfigurados:

   gcloud compute security-policies rules create 1000 \
       --security-policy edge-fw-policy \
       --expression "evaluatePreconfiguredExpr('xss-stable')" \
       --action "deny-403" \
       --description "XSS attack filtering"
   

3. Crea el archivo GCPBackendPolicy.yaml para adjuntar al servicio de puerta de enlace de entrada:

   cat <<EOF > ${WORKDIR}/cloud-armor-backendpolicy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPBackendPolicy
   metadata:
     name: cloud-armor-backendpolicy
     namespace: asm-ingress
   spec:
     default:
       securityPolicy: edge-fw-policy
     targetRef:
       group: ""
       kind: Service
       name: asm-ingressgateway
   EOF
   

4. Aplica el archivo GCPBackendPolicy.yaml:

   kubectl apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   

Configura direccionamiento IP y DNS

1. En Cloud Shell, crea una dirección IP estática global para el balanceador de cargas deGoogle Cloud :

   gcloud compute addresses create e2m-gclb-ip --global
   

   El recurso de puerta de enlace de GKE usa esta dirección IP estática, que permite que la dirección IP continúe siendo la misma, incluso si el balanceador de cargas externo cambia.

2. Obtén la dirección IP estática:

   export GCLB_IP=$(gcloud compute addresses describe e2m-gclb-ip \
   --global --format "value(address)")
   echo ${GCLB_IP}
   

   Para crear una asignación estable y fácil de usar para la dirección IP estática del balanceador de cargas de aplicaciones, debes tener un registro DNS público. Puedes usar el proveedor de DNS y la automatización que desees. En esta implementación, se usa Endpoints en lugar de crear una zona del DNS administrada. Endpoints proporciona un registro DNS administrado por Google gratuito para una dirección IP pública.

3. Ejecuta el siguiente comando para crear el archivo de especificación YAML llamado dns-spec.yaml:

   cat <<EOF > ${WORKDIR}/dns-spec.yaml
   swagger: "2.0"
   info:
     description: "Cloud Endpoints DNS"
     title: "Cloud Endpoints DNS"
     version: "1.0.0"
   paths: {}
   host: "frontend.endpoints.${PROJECT}.cloud.goog"
   x-google-endpoints:
   - name: "frontend.endpoints.${PROJECT}.cloud.goog"
     target: "${GCLB_IP}"
   EOF
   

   La especificación YAML define el registro DNS público en el formato frontend.endpoints.${PROJECT}.cloud.goog, en el que ${PROJECT} es tu identificador de proyecto único.

4. Implementa el archivo dns-spec.yaml en tu proyecto de Google Cloud :

   gcloud endpoints services deploy ${WORKDIR}/dns-spec.yaml
   

   El resultado es similar a este:

   project [e2m-doc-01]...
   Operation "operations/acat.p2-892585880385-fb4a01ad-821d-4e22-bfa1-a0df6e0bf589" finished successfully.
   
   Service Configuration [2023-08-04r0] uploaded for service [frontend.endpoints.e2m-doc-01.cloud.goog]
   

   Ahora que la dirección IP y el DNS están configurados, puedes generar un certificado público para proteger el frontend. Para integrar con GKE Gateway, usa los certificados TLS del Administrador de certificados.

Aprovisiona un certificado TLS

En esta sección, crearás un certificado TLS con el Administrador de certificados y lo asociarás con un mapa de certificados a través de una entrada de mapa de certificados. El balanceador de cargas de la aplicación, configurado a través de GKE Gateway, usa el certificado para proporcionar comunicaciones seguras entre el cliente y Google Cloud. Una vez que se crea, el recurso de puerta de enlace de GKE hace referencia a la entrada del mapa de certificados.

1. En Cloud Shell, habilita la API de Certificate Manager:

   gcloud services enable certificatemanager.googleapis.com --project=${PROJECT}
   

2. Crea el certificado TLS:

   gcloud --project=${PROJECT} certificate-manager certificates create edge2mesh-cert \
       --domains="frontend.endpoints.${PROJECT}.cloud.goog"
   

3. Crea el mapa de certificados:

   gcloud --project=${PROJECT} certificate-manager maps create edge2mesh-cert-map
   

4. Adjunta el certificado al mapa de certificados con una entrada de mapa de certificados:

   gcloud --project=${PROJECT} certificate-manager maps entries create edge2mesh-cert-map-entry \
       --map="edge2mesh-cert-map" \
       --certificates="edge2mesh-cert" \
       --hostname="frontend.endpoints.${PROJECT}.cloud.goog"
   

Implementa los recursos de puerta de enlace de GKE y de HTTPRoute

En esta sección, configurarás el recurso de la puerta de enlace de GKE que aprovisiona el balanceador de cargas de aplicaciones de Google Cloud con gke-l7-global-external-managed gatewayClass. Además, configuras recursos HTTPRoute que enrutan solicitudes a la aplicación y realizan redireccionamientos de HTTP a HTTP(S).

1. En Cloud Shell, ejecuta el siguiente comando para crear el manifiesto Gateway como gke-gateway.yaml:

   cat <<EOF > ${WORKDIR}/gke-gateway.yaml
   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
     namespace: asm-ingress
     annotations:
       networking.gke.io/certmap: edge2mesh-cert-map
   spec:
     gatewayClassName: gke-l7-global-external-managed # gke-l7-gxlb
     listeners:
     - name: http # list the port only so we can redirect any incoming http requests to https
       protocol: HTTP
       port: 80
     - name: https
       protocol: HTTPS
       port: 443
     addresses:
     - type: NamedAddress
       value: e2m-gclb-ip # reference the static IP created earlier
   EOF
   

2. Aplica el manifiesto Gateway para crear un Gateway llamado external-http:

   kubectl apply -f ${WORKDIR}/gke-gateway.yaml
   

3. Crea el archivo HTTPRoute.yaml predeterminado:

   cat << EOF > ${WORKDIR}/default-httproute.yaml
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: default-httproute
     namespace: asm-ingress
   spec:
     parentRefs:
     - name: external-http
       namespace: asm-ingress
       sectionName: https
     rules:
     - matches:
       - path:
           value: /
       backendRefs:
       - name: asm-ingressgateway
         port: 443
   EOF
   

4. Aplica el HTTPRoute predeterminado:

   kubectl apply -f ${WORKDIR}/default-httproute.yaml
   

5. Crea un archivo HTTPRoute.yaml adicional para realizar redireccionamientos HTTP a HTTP(S):

   cat << EOF > ${WORKDIR}/default-httproute-redirect.yaml
   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: http-to-https-redirect-httproute
     namespace: asm-ingress
   spec:
     parentRefs:
     - name: external-http
       namespace: asm-ingress
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
           statusCode: 301
   EOF
   

6. Aplica el redireccionamiento HTTPRoute:

   kubectl apply -f ${WORKDIR}/default-httproute-redirect.yaml
   

   La conciliación lleva tiempo. Usa el siguiente comando hasta programmed=true:

   kubectl get gateway external-http -n asm-ingress -w
   

Instala la app de muestra Online Boutique

1. En Cloud Shell, crea un espacio de nombres onlineboutique dedicado:

   kubectl create namespace onlineboutique
   

2. Agrega una etiqueta al espacio de nombres onlineboutique:

   kubectl label namespace onlineboutique istio-injection=enabled
   

   Si etiquetas el espacio de nombres onlineboutique con istio-injection=enabled, se indica a Cloud Service Mesh que inserte de manera automática proxies de sidecar de Envoy cuando se implementa una aplicación.

3. Descarga los archivos YAML de Kubernetes para la app de muestra Online Boutique:

   curl -LO \
   https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml
   

4. Implementa la app Online Boutique:

   kubectl apply -f kubernetes-manifests.yaml -n onlineboutique
   

   El resultado es similar al siguiente (incluidas las advertencias sobre la configuración de solicitudes y límites de recursos predeterminados de GKE Autopilot):

   Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/emailservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
   deployment.apps/emailservice created
   service/emailservice created
   Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/checkoutservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
   deployment.apps/checkoutservice created
   service/checkoutservice created
   Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/recommendationservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
   deployment.apps/recommendationservice created
   service/recommendationservice created
   ...
   

5. Asegúrate de que todas las implementaciones estén en funcionamiento:

   kubectl get pods -n onlineboutique
   

   El resultado es similar al siguiente:

   NAME                                     READY   STATUS    RESTARTS   AGE
   adservice-64d8dbcf59-krrj9               2/2     Running   0          2m59s
   cartservice-6b77b89c9b-9qptn             2/2     Running   0          2m59s
   checkoutservice-7668b7fc99-5bnd9         2/2     Running   0          2m58s
   ...
   

   Espera unos minutos a que el clúster de GKE Autopilot aprovisione la infraestructura de procesamiento necesaria para admitir la aplicación.

6. Ejecuta el siguiente comando para crear el manifiesto VirtualService como frontend-virtualservice.yaml:

   cat <<EOF > frontend-virtualservice.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: frontend-ingress
     namespace: onlineboutique
   spec:
     hosts:
     - "frontend.endpoints.${PROJECT}.cloud.goog"
     gateways:
     - asm-ingress/asm-ingressgateway
     http:
     - route:
       - destination:
           host: frontend
           port:
             number: 80
   EOF
   

   VirtualService se crea en el espacio de nombres de la aplicación (onlineboutique). Por lo general, el propietario de la aplicación decide y configura cómo y qué tráfico se enruta a la aplicación frontend para que el propietario de la app implemente VirtualService.

7. Implementa frontend-virtualservice.yaml en el clúster:

   kubectl apply -f frontend-virtualservice.yaml
   

8. Accede al siguiente vínculo:

   echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
   

   Se mostrará el frontend de Online Boutique.

   

   Nota: Es posible que recibas un error ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Este error ocurre cuando los certificados aún no se propagaron a todos los Google Front End (GFE) a nivel global. Espera unos minutos y vuelve a intentarlo.

9. Para ver los detalles del certificado, haz clic en Consulta la información del sitio en la barra de direcciones del navegador y, luego, haz clic en Certificado (Válido).

   En el visualizador de certificados, se muestran los detalles del certificado administrado, incluida la fecha de vencimiento y quién emitió el certificado.

Ahora tienes un balanceador de cargas de HTTPS global que funciona como frontend en tu aplicación alojada en la malla de servicios.

Limpia

Una vez que hayas terminado la implementación, puedes limpiar los recursos que creaste en Google Cloud para que no se te cobre por ellos en el futuro. Puedes borrar el proyecto por completo o borrar los recursos del clúster y, luego, borrar el clúster.

Borra el proyecto

Precaución: Borrar un proyecto tiene las siguientes consecuencias:
• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Borra los recursos individuales

Si deseas conservar el proyecto de Google Cloud que usaste en esta implementación, borra los recursos individuales:

1. En Cloud Shell, borra los recursos de HTTPRoute:

   kubectl delete -f ${WORKDIR}/default-httproute-redirect.yaml
   kubectl delete -f ${WORKDIR}/default-httproute.yaml
   

2. Borra el recurso de puerta de enlace de GKE:

   kubectl delete -f ${WORKDIR}/gke-gateway.yaml
   

3. Borra los recursos del certificado TLS (incluida la entrada de mapa de certificados y su mapa de certificados superior):

   gcloud --project=${PROJECT} certificate-manager maps entries delete edge2mesh-cert-map-entry --map="edge2mesh-cert-map" --quiet
   gcloud --project=${PROJECT} certificate-manager maps delete edge2mesh-cert-map --quiet
   gcloud --project=${PROJECT} certificate-manager certificates delete edge2mesh-cert --quiet
   

4. Borra la entrada de DNS de Endpoints:

   gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"
   

   El resultado es similar a este:

   Are you sure? This will set the service configuration to be deleted, along
   with all of the associated consumer information. Note: This does not
   immediately delete the service configuration or data and can be undone using
   the undelete command for 30 days. Only after 30 days will the service be
   purged from the system.
   

5. Cuando se te solicite continuar, ingresa Y.

   El resultado es similar a este:

   Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete...
   Operation finished successfully. The following command can describe the Operation details:
    gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5
   

6. Borra la dirección IP estática:

   gcloud compute addresses delete ingress-ip --global
   

   El resultado es similar a este:

   The following global addresses will be deleted:
   
    - [ingress-ip]
   

7. Cuando se te solicite continuar, ingresa Y.

   El resultado es similar a este:

   Deleted
   [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
   

8. Borra el clúster de GKE:

   gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
   

   El resultado es similar al siguiente:

   The following clusters will be deleted.
   - [edge-to-mesh] in [us-central1]
   

9. Cuando se te solicite continuar, ingresa Y.

   Después de unos minutos, el resultado que verás será similar al siguiente:

   Deleting cluster edge-to-mesh...done.
   Deleted
   [https://container.googleapis.com/v1/projects/e2m-doc-01/zones/us-central1/clusters/edge-to-mesh].
   

¿Qué sigue?

• Obtén más información sobre las otras funciones que ofrece Ingress de GKE que puedes usar con la malla de servicios.
• Obtén más información sobre los distintos tipos de balanceo de cargas en la nube disponibles para GKE.
• Obtén información sobre las características y funciones que ofrece Cloud Service Mesh.
• Consulta cómo implementar Ingress en varios clústeres de GKE para el balanceo de cargas multirregional.
• Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.