Configura el balanceo de cargas de HTTP(S) externo para Anthos Service Mesh administrado

Vista previa — service mesh cloud gateway

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.

Descripción general

Cloud Load Balancing proporciona muchas capacidades perimetrales administradas en la nube, incluidos el balanceo de cargas Anycast global, los certificados administrados por Google, la administración de identidades y accesos, y el firewall de nube o IDS. Anthos Service Mesh puede integrar perfectamente estas capacidades perimetrales en el siguiente modelo de entrada de malla. La puerta de enlace de Cloud de malla de servicios proporciona una forma unificada de configurar la puerta de enlace de entrada de Anthos Service Mesh con Cloud Load Balancing de forma simultánea a través de la API de puerta de enlace de Kubernetes.

En comparación con nuestra guía del usuario anterior, Del perímetro a la malla: Exposición de aplicaciones de la malla de servicios a través de Ingress de GKE, con la puerta de enlace de Cloud de la malla de servicios, este modelo ahora se puede implementar a través de un recurso de Kubernetes Gateway que simplifica el proceso de implementación del balanceo de cargas alojado en la nube y en el clúster al mismo tiempo.

Limitaciones de la vista previa

En la versión preliminar de esta función, se aplican las siguientes limitaciones:

• No se admiten las puertas de enlace de varios clústeres.
• No se admiten los clústeres de Autopilot.
• Solo se admite el balanceador de cargas de aplicaciones clásico. No se admiten el balanceador de cargas avanzado ni el balanceador de cargas de HTTP(S) interno.
• El tráfico entre el balanceador de cargas de HTTP(S) externo y la puerta de enlace de entrada de Anthos Service Mesh se encripta mediante TLS. Sin embargo, el balanceador de cargas de HTTP(S) externo no verificará el certificado que proporciona la puerta de enlace de entrada de Anthos Service Mesh. Esta limitación se aplica a todos los usuarios del balanceador de cargas de HTTP(S) de Google Cloud.
• Si se borran GatewayClasses de Anthos Service Mesh de un clúster, no se volverán a instalar de forma automática. Sin embargo, esto no afectará la usabilidad de la función.
• La lógica de coincidencia de ruta no sigue las especificaciones de la API de Gateway y, en cambio, coincide con el orden de HTTPRoute. Esto cambiará en versiones futuras para seguir las especificaciones de la API de puerta de enlace.

Requisitos

• Anthos Service Mesh administrado instalado en un clúster de Google Kubernetes Engine (GKE) que ejecuta la versión 1.24 o posterior No se admiten otros clústeres de GKE Enterprise.
• Solo para la versión v1beta1 de la API de puerta de enlace de Kubernetes.

Requisitos previos

• Habilita las siguientes APIs en tu proyecto:

  • compute.googleapis.com
  • container.googleapis.com
  • certificatemanager.googleapis.com
  • serviceusage.googleapis.com

  gcloud services enable \
     compute.googleapis.com \
     container.googleapis.com \
     certificatemanager.googleapis.com \
     serviceusage.googleapis.com
  

Implementa una puerta de enlace de nube de la malla de servicios para una malla de un solo clúster

En esta sección, se muestra cómo implementar un recurso de puerta de enlace de Kubernetes que implementa un balanceador de cargas de HTTP(S) externo global (clásico) y una puerta de enlace de entrada de Anthos Service Mesh.

Habilita la API de puerta de enlace con Anthos Service Mesh administrado

1. Habilita la API de puerta de enlace en el clúster. El clúster de GKE debe ser de la versión 1.24 o posterior.

2. Instala Anthos Service Mesh administrado con rapid o regular como su canal de versiones.

Implementa el recurso Gateway

Cuando se implementa la puerta de enlace de Cloud de la malla de servicios, los recursos de Kubernetes Gateway se usan para implementar Cloud Load Balancing y la puerta de enlace de entrada de Anthos Service Mesh como un solo paso. Ten en cuenta que los recursos de la puerta de enlace de Kubernetes son diferentes de los recursos de la puerta de enlace de Istio.

Para obtener más información sobre las diferencias, consulta Puertas de enlace de Kubernetes y Puertas de enlace de Istio. Cada puerta de enlace de Kubernetes tiene una GatewayClass que indica su tipo y sus capacidades inherentes. La puerta de enlace de Cloud de malla de servicios tiene una GatewayClass que tiene la capacidad de implementar Cloud Load Balancing y la puerta de enlace de entrada de Anthos Service Mesh.

1. Guarda el siguiente manifiesto de GatewayClass en un archivo llamado l7-gateway-class.yaml:

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: GatewayClass
   metadata:
     name: asm-l7-gxlb
   spec:
     controllerName: mesh.cloud.google.com/gateway
   

2. Implementa la GatewayClass en tu clúster:

   kubectl apply -f l7-gateway-class.yaml
   

3. Verifica que la GatewayClass esté presente después de la instalación:

   kubectl get gatewayclasses.gateway.networking.k8s.io
   

   El resultado es similar al siguiente:

   NAME          CONTROLLER
   asm-l7-gxlb   mesh.cloud.google.com/gateway
   gke-l7-rilb   networking.gke.io/gateway
   gke-l7-gxlb   networking.gke.io/gateway
   

   Es posible que todos los recursos tarden unos minutos en implementarse. Si no ves el resultado esperado, verifica que hayas cumplido de forma correcta los requisitos previos.

   También verás la siguiente GatewayClass:

   gke-l7-gxlb   networking.gke.io/gateway
   

   Se usa para implementar el balanceador de cargas HTTP(S) externo global de Google Cloud.

4. Crea un espacio de nombres dedicado para la puerta de enlace de Cloud de la malla de servicios:

   kubectl create namespace istio-ingress
   

5. Guarda el siguiente manifiesto de Gateway en un archivo llamado gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: servicemesh-cloud-gw
     namespace: istio-ingress
   spec:
     gatewayClassName: asm-l7-gxlb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         namespaces:
           from: All
   

6. Implementa la puerta de enlace en tu clúster en el espacio de nombres istio-ingress:

   kubectl apply -f gateway.yaml
   

7. Verifica que se hayan creado los objetos de la API de Kubernetes Gateway:

   kubectl get gateways.gateway.networking.k8s.io -n istio-ingress
   

   El resultado es similar al siguiente:

   NAME                                CLASS         ADDRESS         READY   AGE
   asm-gw-gke-servicemesh-cloud-gw     gke-l7-gxlb   34.111.114.64   True    9m40s
   asm-gw-istio-servicemesh-cloud-gw   istio                                 9m44s
   servicemesh-cloud-gw                asm-l7-gxlb                           9m44s
   

Sucedirá lo siguiente cuando se implemente este objeto de la API de Kubernetes Gateway:

• Se implementa y configura un balanceador de cargas HTTP(S) externo. Es posible que tarde unos minutos en aparecer, pero cuando lo haga, la puerta de enlace indicará la dirección IP y se anotará con los nombres de los recursos del balanceador de cargas de Compute Engine que se crearon.
• Se crea una Deployment de puerta de enlace de entrada de Anthos Service Mesh en el espacio de nombres istio-ingress. Esto crea las instancias del proxy de Envoy que recibirán el tráfico del balanceador de cargas de Cloud.
• El balanceador de cargas de Cloud encriptará y enrutará todo el tráfico a la puerta de enlace de entrada de Anthos Service Mesh.

Advertencia: En la actualidad, es necesario tener al menos una carga de trabajo de sidecar incorporada para que la puerta de enlace de entrada de Anthos Service Mesh se active de forma correcta.

Ahora tienes la infraestructura completa que se necesita para aceptar el tráfico de Internet en la malla. Ten en cuenta que esta es la implementación de puerta de enlace más sencilla posible. En las siguientes secciones, agregarás políticas y capacidades adicionales que la prepararán para la producción.

Implementación de apps y enrutamiento

Para demostrar por completo las capacidades, implementarás una aplicación en Anthos Service Mesh y recibirás tráfico de Internet a través de tu puerta de enlace con fines de ejemplo.

1. Etiqueta el espacio de nombres default para habilitar la inserción de sidecar.

   kubectl label namespace default istio-injection=enabled istio.io/rev- --overwrite
   

2. Guarda el siguiente manifiesto de Gateway en un archivo llamado whereami.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami-v1
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami-v1
     template:
       metadata:
         labels:
           app: whereami-v1
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
           ports:
             - containerPort: 8080
           env:
           - name: METADATA
             value: "whereami-v1"
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami-v1
   spec:
     selector:
       app: whereami-v1
     ports:
     - port: 8080
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami-v2
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami-v2
     template:
       metadata:
         labels:
           app: whereami-v2
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
           ports:
             - containerPort: 8080
           env:
           - name: METADATA
             value: "whereami-v2"
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami-v2
   spec:
     selector:
       app: whereami-v2
     ports:
     - port: 8080
       targetPort: 8080
   

   Este manifiesto crea Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 y Deployment/whereami-v2 parawhereami, una aplicación simple que genera JSON con el fin de indicar su identidad y ubicación. Implementarás dos versiones diferentes.

3. Crea los objetos Service y las implementaciones:

   kubectl apply -f whereami.yaml
   

   Una vez que esté en funcionamiento, tendrás cuatro Pods de Forami ejecutándose en tu clúster.

4. Verifica que los cuatro Pods se estén ejecutando:

   kubectl get pods
   

   El resultado es similar al siguiente:

   whereami-v1-7c76d89d55-qg6vs       2/2     Running   0          28s
   whereami-v1-7c76d89d55-vx9nm       2/2     Running   0          28s
   whereami-v2-67f6b9c987-p9kqm       2/2     Running   0          27s
   whereami-v2-67f6b9c987-qhj76       2/2     Running   0          27s
   

5. Guarda el siguiente manifiesto de HTTPRoute en un archivo llamado http-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: where-route
   spec:
    parentRefs:
    - kind: Gateway
      name: servicemesh-cloud-gw
      namespace: istio-ingress
    hostnames:
    - "where.example.com"
    rules:
    - matches:
      - headers:
        - name: version
          value: v2
      backendRefs:
      - name: whereami-v2
        port: 8080
    - backendRefs:
      - name: whereami-v1
        port: 8080
   

6. Implementa http-route.yaml en el clúster:

   kubectl apply -f http-route.yaml
   

   Esta HTTPRoute hace referencia a servicemesh-cloud-gw, lo que significa que configurará la puerta de enlace de Cloud de la malla de servicios para configurar la puerta de enlace de entrada subyacente de Anthos Service Mesh con estas reglas de enrutamiento. HTTPRoute realiza la misma función que Istio VirtualService, pero usa la API de Kubernetes Gateway para hacerlo. Debido a que la API de Gateway es una especificación de OSS con muchas implementaciones subyacentes, es la más adecuada para definir el enrutamiento en una combinación de diferentes balanceadores de cargas (como proxies de Anthos Service Mesh y balanceadores de cargas de Cloud).

7. Recupera la dirección IP de Gateway para poder enviar tráfico a tu aplicación:

   VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)
   

   El resultado es una dirección IP.

   echo $VIP
   
   34.111.61.135
   

8. Envía tráfico a la dirección IP de la puerta de enlace para validar que esta configuración funcione de forma correcta. Envía una solicitud con el encabezado version: v2 y otra sin determinar que el enrutamiento se realice correctamente en las dos versiones de la aplicación.

   Nota: Este proceso puede tardar hasta 10 minutos en completarse y verás el error Empty reply from server o Connection reset by peer mientras esperas.

   curl ${VIP} -H "host: where.example.com"
   
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "whereami-v1",
     "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
     "pod_name": "whereami-v1-67d9c5d48b-zhr4l",
     "pod_name_emoji": "⚒",
     "project_id": "church-243723",
     "timestamp": "2021-02-08T18:55:01",
     "zone": "us-central1-a"
   }
   
   curl ${VIP} -H "host: where.example.com" -H "version: v2"
   
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "whereami-v2",
     "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
     "pod_name": "whereami-v2-67d9c5d48b-zhr4l",
     "pod_name_emoji": "⚒",
     "project_id": "church-243723",
     "timestamp": "2021-02-08T18:55:01",
     "zone": "us-central1-a"
   }
   

Implementación de la puerta de enlace de producción

En la sección anterior, se mostró un ejemplo muy sencillo de la puerta de enlace de Cloud de la malla de servicios. Los siguientes pasos se basan en el ejemplo simple para mostrar una configuración lista para la producción que demuestre las ventajas de delegar algunas de las funciones de enrutamiento de entrada al balanceador de cargas de Cloud.

En el siguiente ejemplo, tomarás el servicemesh-cloud-gw de la sección anterior y agregarás las siguientes capacidades para crear una puerta de enlace más segura y administrable:

• Implementa Gateway con una dirección IP estática que se conservará incluso si cambia la infraestructura subyacente.
• Convierte la puerta de enlace para recibir tráfico HTTPS con un certificado autofirmado.

Nota: Este ejemplo se basa en la implementación de la puerta de enlace, pero debido a que se cambiaron el puerto y el protocolo de la puerta de enlace, estos pasos interrumpirán el tráfico que se dirige a tu puerta de enlace en el puerto 80. En una situación realista, es poco probable que el puerto de frontend de tu puerta de enlace cambie.

1. Crea una dirección IP externa estática. Una IP estática es útil porque la infraestructura subyacente puede cambiar en el futuro, pero la dirección IP se puede conservar.

   gcloud compute addresses create whereami-ip \
       --global \
       --project PROJECT_ID
   

2. Crea un certificado autofirmado para el dominio where-example-com:

   openssl genrsa -out key.pem 2048
   cat <<EOF >ca.conf
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   [dn_requirements]
   0.organizationName        = example
   commonName                = where.example.com
   [sans_list]
   DNS.1                     = where.example.com
   EOF
   

   openssl req -new -key key.pem \
       -out csr.pem \
       -config ca.conf
   

   openssl x509 -req \
       -signkey key.pem \
       -in csr.pem \
       -out cert.pem \
       -extfile ca.conf \
       -extensions extension_requirements \
       -days 365
   

   gcloud compute ssl-certificates create where-example-com \
       --certificate=cert.pem \
       --private-key=key.pem \
       --global \
       --project PROJECT_ID
   

   Existen muchas formas de generar certificados TLS. Se pueden generar manualmente en la línea de comandos, generados mediante certificados administrados por Google, o se pueden generar internamente mediante el sistema de infraestructura de clave pública (PKI) de tu empresa. En este ejemplo, se genera de forma manual un certificado autofirmado. Si bien los certificados autofirmados no suelen usarse para servicios públicos, demuestra estos conceptos con mayor facilidad.

   Para obtener más información sobre la creación de un certificado autofirmado a través de Kubernetes Secret, consulta Protege una puerta de enlace.

3. Actualiza gateway.yaml con el siguiente manifiesto:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: servicemesh-cloud-gw
     namespace: istio-ingress
   spec:
     gatewayClassName: asm-l7-gxlb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         namespaces:
           from: All
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: where-example-com
     addresses:
     - type: NamedAddress
       value: whereami-ip
   

4. Vuelve a implementar la puerta de enlace en tu clúster:

   kubectl apply -f gateway.yaml
   

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

   VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")
   

6. Usa curl para acceder al dominio de la puerta de enlace. Debido a que el DNS no está configurado para este dominio, usa la opción --resolve para indicarle a curl que resuelva el nombre de dominio en la dirección IP de la puerta de enlace:

   curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v
   

   Nota: Este proceso puede tardar hasta 10 minutos en completarse. Mientras esperas, verás el error error:0A000126:SSL routines::unexpected eof while reading.

   Una vez que se complete el proceso, el resultado será similar al siguiente:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=where.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: where.example.com (matched)
   *  issuer: O=example; CN=where.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "where-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "where-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

El resultado detallado incluye un protocolo de enlace TLS exitoso seguido de una respuesta de la aplicación como el siguiente resultado. Esto demuestra que TLS se finaliza correctamente en la puerta de enlace y que la aplicación responde al cliente de forma segura.

Implementaste correctamente la siguiente arquitectura:

El objeto servicemesh-cloud-gw y su GatewayClass asm-l7-gxlb abstraen algunos componentes de infraestructura interna para simplificar la experiencia del usuario. Cloud Load Balancing finaliza el tráfico de TLS con un certificado interno y también verifica el estado de la capa del proxy de la puerta de enlace de entrada de Anthos Service Mesh. El whereami-route implementado en Implementación de apps y enrutamiento configura los proxies de puerta de enlace de entrada de Anthos Service Mesh para enrutar el tráfico al servicio alojado en la malla correcto.

¿Qué sigue?

• Obtén más información sobre la implementación de Google Kubernetes Engine (GKE) de la API de Kubernetes Gateway.
• Consulta cómo habilitar funciones opcionales administradas de Anthos Service Mesh.