Implementa puertas de enlace

Autopilot Estándar

---

En esta página, se describe cómo implementar recursos de puerta de enlace de Kubernetes para el balanceo de cargas del tráfico de entrada a un solo clúster de Google Kubernetes Engine (GKE).

Para implementar puertas de enlace con el balanceo de cargas del tráfico de entrada en varios clústeres (o flota), consulta Implementa puertas de enlace de varios clústeres.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Requisitos del controlador de la puerta de enlace de GKE

• Para Standard, la versión 1.24 de GKE o una posterior.

• Para Autopilot, versión 1.26 de GKE o posterior.
• Versión 407.0.0 o posterior de Google Cloud CLI.
• La API de la puerta de enlace solo es compatible con clústeres nativos de VPC.
• Si usas las GatewayClasses internas, debes habilitar una subred de solo proxy.
• El clúster debe tener el complemento HttpLoadBalancing habilitado.
• Si usas Istio, debes actualizarlo a una de las siguientes versiones:
  • 1.15.2 o una versión posterior
  • 1.14.5 o una versión posterior
  • 1.13.9 o una versión posterior.
• Si usas una VPC compartida, en el proyecto host, debes asignar el rol Compute Network User a la cuenta de servicio de GKE para el proyecto de servicio.

Restricciones y limitaciones

• Las GatewayClasses de GKE admiten diferentes capacidades según el balanceador de cargas que usen. Para obtener más información sobre las diferentes funciones que admite cada GatewayClass, consulta Capacidades de GatewayClass.

• No puedes usar un FrontendConfig o un BackendConfig para configurar una puerta de enlace. Debes usar una política.

• GKE Gateway se comporta de manera diferente a Ingress, ya que Gateway no infiere los parámetros de verificación de estado. Si el Service no muestra 200 para las solicitudes a GET / o si tienes otras verificaciones de preparación de Pods ajustadas, debes configurar una HealthCheckPolicy para tu servicio.

• No puedes especificar un número de puerto directamente en el nombre de host (por ejemplo, web.example.com:80) para el enrutamiento de tráfico.

• Puedes ver los recursos del balanceador de cargas que GKE crea para las puertas de enlace de la consola de Google Cloud, pero estos recursos no hacen referencia al clúster de puerta de enlace o GKE al que están conectados.

• No puedes generar de forma automática un certificado SSL administrado por Google con las puertas de enlace, pero puedes crear y hacer referencia a un certificado SSL administrado por Google de forma manual. Para obtener más información, consulta Protege una puerta de enlace.

• HTTPRoute es el único tipo de ruta compatible. No se admiten TCPRoutes, UDPRoutes ni TLSRoutes. Para ver una lista de los campos que admite GKE Gateway Controller, consulta Capacidades de GatewayClass.

• Los encabezados de solicitud y respuesta personalizados con puertas de enlace o redireccionamientos de ruta de acceso y reescrituras de URL con Gateway solo están disponibles en GKE versión 1.27 o posterior.

• Para los encabezados de solicitud y respuesta personalizados con puertas de enlace y redireccionamientos de ruta de acceso y reescrituras de URL con Gateway, la GatewayClass gke-l7-gxlb no es compatible.

• Cuando se configuran encabezados de respuesta y solicitud personalizados HTTPRoute, no se admiten las siguientes variables de Google Cloud:

  • cdn_cache_id (Cloud CDN no es compatible con GKE Gateway)
  • cdn_cache_status (Cloud CDN no es compatible con GKE Gateway)
  • origin_request_header (Las políticas CORS no son compatibles con la puerta de enlace de GKE)

• GKE Gateway no es compatible con la función de balanceo de cargas de Cloud CDN.

• No se admiten los encabezados personalizados de TLS mutua (mTLS con GKE Gateway)

• Las limitaciones del balanceador de cargas clásico de la aplicación de Google Cloud se aplican a la puerta de enlace de GKE con una limitación adicional:

  • No puedes configurar un encabezado de respuesta del host personalizado en el servicio de backend.

• Los redireccionamientos y las reescrituras de las URL son mutuamente excluyentes, no puedes usar ambos filtros al mismo tiempo en las mismas reglas.

• El redireccionamiento del tráfico a un puerto diferente no es compatible con Cloud Load Balancing. Para ver la lista de los campos que admite GKE Gateway Controller, consulta Capacidades de GatewayClass.

• Gateway de GKE no admite comodines, expresiones regulares y URLs dinámicas.

• Si especificas una puerta de enlace con una clase de puerta de enlace externa regional, el controlador aprovisiona una dirección IP interna en lugar de la dirección externa. Para obtener información sobre cómo usar una dirección con nombre con el balanceador de cargas de aplicaciones externo regional, consulta Implementa una puerta de enlace externa regional.

• La puerta de enlace usa NEG independientes para aprovisionar grupos de extremos de red. Para garantizar que el controlador de la puerta de enlace concilie de forma correcta la configuración del balanceador de cargas, no puedes modificar la anotación cloud.google.com/neg para un Service que forma parte de la puerta de enlace.

• La puerta de enlace de GKE no admite la referencia a un servicio que también hace referencia a un Ingress de GKE.

• Cuando se configura una Gateway para aprovisionar una dirección IP, no se admite cambiar la Gateway.spec.gatewayClass. Para asegurarte de que el controlador de la puerta de enlace concilie de forma correcta el balanceador de cargas, borra la puerta de enlace existente y vuelve a implementar el manifiesto con el valor gatewayClass actualizado.

• No se admite la anotación networking.gke.io/app-protocols. En su lugar, usa el campo appProtocol para lograr el mismo resultado.

Habilita la API de la puerta de enlace en tu clúster

Antes de usar los recursos de la puerta de enlace en GKE, tu clúster debe tener habilitada la API de la puerta de enlace.

Crea un clúster nuevo con la API de la puerta de enlace habilitada

GKE admite la API de Gateway en clústeres de Autopilot a partir de la versión 1.26 de GKE. Si creas clústeres de Autopilot nuevos en GKE 1.26 y versiones posteriores, la API de Gateway se habilita de forma predeterminada. Para los clústeres existentes en la versión 1.25 de GKE y versiones anteriores, la API Gateway está inhabilitada de forma predeterminada.

Autopilot

Crea un clúster de GKE Autopilot nuevo con la API de puerta de enlace habilitada:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=CLUSTER_LOCATION \
      --release-channel=RELEASE_CHANNEL \
      --cluster-version=VERSION

Reemplaza lo siguiente:

• CLUSTER_NAME: el nombre del clúster
• CLUSTER_LOCATION: Es la región o zona de Compute Engine para el clúster nuevo.
• RELEASE_CHANNEL: Es el nombre del canal de versiones.
• VERSION: la versión de GKE, que debe ser 1.26 o posterior. También puedes usar la marca --release-channel para seleccionar un canal de versiones. El canal de versiones debe tener una versión predeterminada 1.26 o posterior.

Nota: No necesitas usar gcloud flag --gateway-api=standard durante la creación del clúster.

Standard

Con GKE Standard, la API de Gateway se controla mediante la marca --gateway-api. Puedes usar el valor estándar cuando está habilitado o inhabilitado cuando lo inhabilitas.

Crea un clúster de GKE nativo de la VPC nueva con la API de la puerta de enlace habilitada:

  gcloud container clusters create CLUSTER_NAME \
    --gateway-api=standard \
    --cluster-version=VERSION \
    --location=CLUSTER_LOCATION

Reemplaza lo siguiente:

• RELEASE_CHANNEL: Es el nombre del canal de versiones.
• CLUSTER_NAME: el nombre del clúster
• VERSION: la versión de GKE, que debe ser 1.24 o posterior. También puedes usar la marca --release-channel para seleccionar un canal de versiones. El canal de versiones debe tener una versión predeterminada 1.24 o posterior.
• CLUSTER_LOCATION: es la región o zona de Compute Engine para el clúster nuevo.

La marca --gateway-api=standard indica a GKE que instale las CRD v1beta1 con el clúster.

Habilita la API de la puerta de enlace en un clúster existente

Nota: Cuando habilitas Gateway en un clúster existente, el clúster puede tardar hasta 45 minutos en conciliar e instalar las CRD.

Asegúrate de que la versión de tu clúster de Autopilot sea 1.26 o posterior y la versión de tu clúster Standard sea 1.24 o posterior.

Para habilitar la API de Gateway en un clúster de GKE existente (Autopilot o Standard), usa lo siguiente:

gcloud container clusters update CLUSTER_NAME \
    --location=CLUSTER_LOCATION\
    --gateway-api=standard

Reemplaza lo siguiente:

• CLUSTER_NAME: es el nombre del clúster existente.

• CLUSTER_LOCATION: la región o zona de Compute Engine del clúster.

La marca --gateway-api=standard indica a GKE que instale las CRD v1beta1 con el clúster.

Nota: Si actualizas un clúster de GKE Standard existente para habilitar la API de Gateway, asegúrate de que se cumplan los requisitos mínimos antes de continuar con la actualización. Para obtener más información sobre cómo actualizar la versión del clúster Standard, consulta Actualizaciones de clústeres Standard. Si deseas obtener más información para actualizar la versión del clúster en modo Autopilot, consulta Actualizaciones de clústeres de Autopilot.

Verifica tu clúster

Después de crear o actualizar tu clúster, GKE Gateway Controller instala las GatewayClasses de forma automática. Es posible que el controlador tarde unos minutos en reconocer las CRDs y en instalar las GatewayClasses.

1. Confirma que la API de Gateway esté habilitada en el plano de control de GKE:

   gcloud container clusters describe CLUSTER_NAME \
     --location=CLUSTER_LOCATION \
     --format json
   

   El resultado es similar al siguiente. Si este resultado está vacío, vuelve a ejecutar el comando de actualización del clúster.

   "networkConfig": {
     ...
     "gatewayApiConfig": {
       "channel": "CHANNEL_STANDARD"
     },
     ...
   },
   

2. Confirma que las GatewayClasses estén instaladas en el clúster:

   kubectl get gatewayclass
   

   El resultado es similar a este:

   NAME                             CONTROLLER                  ACCEPTED   AGE
   gke-l7-global-external-managed   networking.gke.io/gateway   True       16h
   gke-l7-regional-external-managed networking.gke.io/gateway   True       16h
   gke-l7-gxlb                      networking.gke.io/gateway   True       16h
   gke-l7-rilb                      networking.gke.io/gateway   True       16h
   

Para comprender las capacidades de cada GatewayClass, consulta Capacidades de GatewayClass.

Nota: Solo se instalan automáticamente las GatewayClasses de un solo clúster. A fin de instalar y usar las GatewayClasses de varios clústeres para el balanceo de cargas interno y externo de varios clústeres, consulta Habilita puertas de enlace de varios clústeres.

Implementa una Gateway interna

Una Gateway interna expone aplicaciones a las que solo se puede acceder desde la VPC o las redes conectadas a la VPC.

Implementa una puerta de enlace interna regional

En el siguiente ejemplo, se muestra cómo implementar una puerta de enlace interna regional que permite una comunicación eficiente y segura entre servicios dentro de una región geográfica específica.

Configura una subred de solo proxy

Debes configurar una subred de solo proxy antes de crear una puerta de enlace que use un balanceador de cargas de aplicaciones interno. Cada región de una VPC en la que uses balanceadores de cargas de aplicaciones internos debe tener una subred de solo proxy. En esta subred, se proporcionan direcciones IP internas a los proxies del balanceador de cargas.

1. Crea una subred de solo proxy:

   gcloud compute networks subnets create SUBNET_NAME \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=COMPUTE_REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE
   

   Reemplaza lo siguiente:

   • SUBNET_NAME: El nombre de la subred de solo proxy
   • COMPUTE_REGION: La región de la subred de solo proxy
   • VPC_NETWORK_NAME: El nombre de la red de VPC que contiene la subred
   • CIDR_RANGE: El rango de direcciones IP principal de la subred Debes usar una máscara de subred de una longitud máxima de /26 para que al menos 64 direcciones IP estén disponibles para los proxies de la región. La máscara de subred recomendada es /23.

2. Verifica tu subred de solo proxy:

   gcloud compute networks subnets describe SUBNET_NAME \
       --region=COMPUTE_REGION
   

   El resultado es similar a este:

   ...
   gatewayAddress: 10.1.1.1
   ipCidrRange: 10.1.1.0/24
   kind: compute#subnetwork
   name: proxy-subnet
   network: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/default
   privateIpGoogleAccess: false
   privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
   purpose: REGIONAL_MANAGED_PROXY
   region: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION
   role: ACTIVE
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION/subnetworks/proxy-subnet
   state: READY
   

Crea una Gateway

Un recurso de puerta de enlace representa un plano de datos que enruta el tráfico en Kubernetes. Una puerta de enlace puede representar muchos tipos diferentes de balanceo de cargas y enrutamiento según la GatewayClass de la que deriva. Si deseas obtener más información sobre el recurso de puerta de enlace, consulta la descripción del recurso de puerta de enlace o la especificación de la API.

En este caso, el administrador del clúster de GKE quiere crear una puerta de enlace que varios equipos puedan usar para exponer sus aplicaciones de forma interna. El administrador implementa la Gateway, y los equipos de aplicaciones implementan sus rutas de forma independiente y las conectan a esta Gateway.

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

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: internal-http
   spec:
     gatewayClassName: gke-l7-rilb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
   

   Este manifiesto incluye los siguientes campos:

   • gatewayClassName: gke-l7-rilb: especifica la GatewayClass de la que deriva esta puerta de enlace. gke-l7-rilb corresponde al balanceador de cargas de aplicaciones interno.
   • port: 80: especifica que la puerta de enlace expone solo el puerto 80 para escuchar el tráfico HTTP.

2. Implementa la puerta de enlace en tu clúster:

   kubectl apply -f gateway.yaml
   

3. Verifica que la puerta de enlace se haya implementado de forma correcta. La implementación de todos sus recursos puede llevar unos minutos.

   kubectl describe gateways.gateway.networking.k8s.io internal-http
   

   El resultado es similar a este:

   Name:         internal-http
   Namespace:    default
   Spec:
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Kinds:
           Group:  gateway.networking.k8s.io
           Kind:   HTTPRoute
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
   Status:
     Addresses:
       Type:   IPAddress
       Value:  192.168.1.14
     Conditions:
       Last Transition Time:  1970-01-01T00:00:00Z
       Message:               Waiting for controller
       Reason:                NotReconciled
       Status:                False
       Type:                  Scheduled
   Events:
     Type    Reason  Age                From                       Message
     ----    ------  ----               ----                       -------
     Normal  ADD     92s                networking.gke.io/gateway  test/internal-http
     Normal  UPDATE  45s (x3 over 91s)  networking.gke.io/gateway  test/internal-http
     Normal  SYNC    45s                networking.gke.io/gateway  SYNC on test/internal-http was a success
   

   En este punto, hay una puerta de enlace implementada en tu clúster que aprovisionó un balanceador de cargas y una dirección IP. Sin embargo, la puerta de enlace no tiene rutas y, por lo tanto, no sabe cómo debe enviar tráfico a los backends. Sin rutas, todo el tráfico se dirige a un backend predeterminado, que muestra un HTTP 404. A continuación, implementarás una aplicación y rutas, que le indican a la puerta de enlace cómo llegar a los backends de aplicaciones.

Implementa las aplicaciones de demostración

Los equipos de aplicaciones pueden implementar sus aplicaciones y rutas independientemente de la implementación de puertas de enlace. En algunos casos, es posible que el equipo de aplicaciones también desee poseer la puerta de enlace y, luego, implementarla como un recurso dedicado a sus aplicaciones. Consulta Vinculación de rutas para ver diferentes modelos de propiedad de puertas de enlace y rutas. En este ejemplo, el equipo de la tienda implementa su aplicación y una HTTPRouter adjunta para exponer su app a través de la puerta de enlace internal-http creada en la sección anterior.

El recurso HTTPRoute tiene muchos campos configurables para la coincidencia de tráfico. Para ver una explicación de los campos de HTTPRoute, consulta la especificación de API.

1. Implementa la aplicación de almacenamiento (implementaciones store-v1, store-v2 y store-german) en su clúster:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Esto crea tres implementaciones y tres servicios, llamados store-v1, store-v2 y store-german

2. Confirma que la aplicación se haya implementado correctamente:

   kubectl get pod
   

   El resultado es similar al siguiente después de que se ejecuta la aplicación:

   NAME                        READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Valida que se hayan implementado los objetos Service:

   kubectl get service
   

   El resultado muestra un objeto Service para cada implementación de la tienda:

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Implementa la HTTPRoute

Los recursos de ruta definen reglas específicas del protocolo para asignar tráfico de una puerta de enlace a backends de Kubernetes. El recurso HTTPRoute realiza coincidencias y filtros de tráfico HTTP y HTTPS, y es compatible con todas las GatewayClasses gke-l7.

En esta sección, implementarás un HTTPRoute, que programa el Gateway con las reglas de enrutamiento necesarias para llegar a la aplicación de almacenamiento.

1. Guarda el siguiente manifiesto de HTTPRoute en un archivo llamado store-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store
   spec:
     parentRefs:
     - kind: Gateway
       name: internal-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
   

2. Implementa la HTTProute en tu clúster:

   kubectl apply -f store-route.yaml
   

   La HTTPRoute store está vinculada a la puerta de enlace internal-http mediante la propiedad parentRefs. Estas reglas de enrutamiento se configuran en el balanceador de cargas subyacente como se muestra en este diagrama:

   

   Estas reglas de enrutamiento procesan el tráfico HTTP de la siguiente manera:

   • El tráfico a store.example.com/de va al objeto Service store-german.
   • El tráfico a store.example.com con el encabezado HTTP "env: canary" va al objeto Service store-v2.
   • El tráfico restante a store.example.com va al objeto Service store-v1.

3. Verifica que se haya implementado la HTTPRoute:

   kubectl describe httproute store
   

   El resultado es similar a este:

   Name:         store
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1beta1
   Kind:         HTTPRoute
   <...>
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   internal-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       Conditions:
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
   Events:
     Type    Reason  Age                From                   Message
     ----    ------  ----               ----                   -------
     Normal  ADD     24m                sc-gateway-controller  default/store
     Normal  SYNC    16m (x4 over 23m)  sc-gateway-controller  Bind of HTTPRoute "default/store" to ParentRef {Group:       gateway.networking.k8s.io",
     <...>
   

4. Verifica que la HTTPRoute esté vinculada a la puerta de enlace:

   kubectl describe gateway
   

   El resultado es similar a este:

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   <...>
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.128.15.203
     Conditions:
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T03:47:01Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    http
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         <...>
   

Envía tráfico a tu aplicación

Ahora que la puerta de enlace, la ruta y la aplicación están implementadas en el clúster, puedes pasar el tráfico a la aplicación.

1. Recupera la dirección IP de la puerta de enlace para que puedas enviar tráfico a tu aplicación:

   kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}"
   

   El resultado es una dirección IP.

2. Envía tráfico a esta dirección IP desde la shell en una instancia de máquina virtual (VM) con conectividad al clúster. Puedes crear una VM para este fin. Esto es necesario porque la puerta de enlace tiene una dirección IP interna y solo se puede acceder desde tu red de VPC. Debido a que internal-http es un balanceador de cargas regional, la shell del cliente debe estar dentro de la misma región que el clúster de GKE.

   Debido a que no eres propietario del nombre de host example.com, configura el encabezado del host de forma manual para que se pueda observar el enrutamiento de tráfico. Primero, intenta solicitar store.example.com:

   curl -H "host: store.example.com" VIP
   

   Reemplaza VIP por la dirección IP del paso anterior.

   El resultado de la app de demostración muestra información sobre la ubicación en la que se ejecuta la app:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:31:17",
     "zone": "ZONE_NAME"
   }
   

3. Para probar la coincidencia de ruta de acceso, ve a la versión en alemán del servicio de almacenamiento en store.example.com/de:

   curl -H "host: store.example.com" VIP/de
   

   El resultado confirma que un pod store-german entregó la solicitud:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!", 
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl", 
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:35:37",
     "zone": "ZONE_NAME"
   }
   

4. Por último, usa el encabezado HTTP env: canary para enviar tráfico a la versión canary del servicio de almacenamiento:

   curl -H "host: store.example.com" -H "env: canary " VIP
   

   El resultado confirma que un pod store-v2 entregó la solicitud:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2", 
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb", 
     "pod_name_emoji": "🦰",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:38:26",
     "zone": "ZONE_NAME"
   }
   

Implementa una puerta de enlace externa

Una puerta de enlace externa expone las aplicaciones a las que se puede acceder desde Internet o redes fuera de la VPC. La implementación es similar a una implementación de puerta de enlace interna, excepto que debes proteger tus aplicaciones, ya que la Internet pública puede acceder a la puerta de enlace.

Tienes dos opciones para crear una puerta de enlace externa: una puerta de enlace externa global o una puerta de enlace externa regional.

Una puerta de enlace externa global usa una dirección IP global (o dirección IP Anycast) como el frontend de la puerta de enlace anunciada en todas las regiones de Google Cloud Compute. Los clientes que envían tráfico a esta dirección IP Anycast se enrutan a la ubicación de Google más cercana en la que se anuncia la IP. La puerta de enlace externa global solo está disponible en el nivel de servicio de red Premium.

Una puerta de enlace externa regional usa una IP regional como frontend de la puerta de enlace anunciada solo en la región local de Google Cloud Compute en la que se implementa la puerta de enlace externa regional. Los clientes que envían tráfico a esta dirección IP regional se enrutan a través de su ISP local y a través de Internet antes de llegar a la región de Google en la que se anuncia la IP. La puerta de enlace externa regional solo está disponible en el nivel de servicio de red Estándar.

Implementa una puerta de enlace externa global

En el siguiente ejemplo, se muestra cómo exponer una aplicación de almacenamiento con varios certificados adjuntos a la puerta de enlace externa global y agrupados en un mapa de certificados con el administrador de certificados y una HTTPRoute.

Crea un mapa de certificados

Google recomienda que uses el administrador de certificados para administrar certificados cuando necesites 15 o más certificados por puerta de enlace o si necesitas usar certificados comodín.

También puedes proteger tu puerta de enlace externa con objetos Secret de Kubernetes o certificados SSL administrados por Google. Para obtener más información, consulta Seguridad de la puerta de enlace.

En esta sección, crearás certificados con el administrador de certificados para proteger las aplicaciones que se ejecutan en el clúster.

1. Habilita la API de administrador de certificados:

   gcloud services enable certificatemanager.googleapis.com
   

2. Crea un mapa de certificados:

   gcloud beta certificate-manager maps create store-example-com-map
   

3. Carga las claves y el certificado administrado por Google en un certificado:

   gcloud beta certificate-manager certificates create store-example-com-cert \
       --certificate-file="CERTIFICATE_FILE" \
       --private-key-file="PRIVATE_KEY_FILE"
   

   Reemplaza lo siguiente:

   • CERTIFICATE_FILE: el nombre del archivo nuevo que eliges. El archivo debe tener la extensión .pem. Por ejemplo, cert.pem.
   • PRIVATE_KEY_FILE: el nombre de tu archivo de clave privada.

   Para obtener más información, consulta Crea una clave privada y un certificado.

4. Crea una CertificateMapEntry que asigne el certificado al mapa de certificados:

   gcloud beta certificate-manager maps entries create store-example-com-map-entry \
       --map=store-example-com-map \
       --hostname=store.example.com \
       --certificates=store-example-com-cert
   

Si deseas obtener información sobre cómo proteger una puerta de enlace con otras fuentes para certificados, como objetos Secret de Kubernetes o certificados SSL, consulta Protege una puerta de enlace.

Crea una Gateway

Un recurso de puerta de enlace representa un plano de datos que enruta el tráfico en Kubernetes. Una puerta de enlace puede representar muchos tipos diferentes de balanceo de cargas y enrutamiento según la GatewayClass que usa.

Si deseas obtener más información sobre el recurso de puerta de enlace, consulta la descripción del recurso de puerta de enlace o la especificación de la API.

En esta sección, crearás una puerta de enlace. Los equipos de aplicaciones pueden usar la puerta de enlace para exponer sus aplicaciones a Internet mediante la implementación de rutas forma independiente y su conexión segura a la puerta de enlace.

1. Guarda el siguiente manifiesto como un archivo llamado gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
   
   

   En este manifiesto, se describe una puerta de enlace con los siguientes campos:

   • gatewayClassName: gke-l7-global-external-managed: especifica la GatewayClass para esta puerta de enlace. Esta clase de puerta de enlace usa un balanceador de cargas de aplicaciones externo global.
   • protocol: HTTPS y port: 443: especifican que la puerta de enlace expone el puerto 443 para el tráfico HTTPS. Estos campos habilitan TLS.
   • networking.gke.io/certmap: store-example-com-map: especifica el nombre del mapa de certificados en el administrador de certificados.

   No hay sección TLS porque TLS se configura con el administrador de certificados mediante la anotación networking.gke.io/certmap.

2. Aplica el manifiesto al clúster:

   kubectl apply -f gateway.yaml
   

   GKE puede tardar unos minutos en implementar los recursos.

3. Verifica que la puerta de enlace se haya implementado de forma correcta:

   kubectl describe gateway
   

   El resultado es similar a este:

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-global-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
    ...
   

   En este resultado, se muestra que la puerta de enlace implementada en tu clúster tiene un balanceador de cargas y una dirección IP pública. La puerta de enlace no tiene rutas, lo que significa que no puede enviar tráfico a los backends. Sin rutas, todo el tráfico se dirige a un backend predeterminado, que muestra una respuesta HTTP 404. En la siguiente sección, implementarás rutas, que le indican a la puerta de enlace que envíe tráfico a los backends.

Implementa las aplicaciones de demostración

Los equipos de aplicaciones pueden implementar sus aplicaciones y rutas independientemente de la implementación de puertas de enlace. En algunos casos, es posible que el equipo de aplicaciones también desee poseer la puerta de enlace y, luego, implementarla como un recurso dedicado a sus aplicaciones. Consulta Vinculación de rutas para ver diferentes modelos de propiedad de puertas de enlace y rutas. En este ejemplo, el equipo de la tienda implementa su aplicación y una HTTPRouter adjunta para exponer su app a través de la puerta de enlace external-http creada en la sección anterior.

Para obtener más información sobre los campos HTTPRoute, consulta la especificación de la API.

1. Implementa la aplicación de muestra en el clúster.

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Esta aplicación de muestra crea tres objetos Deployment y tres objetos Service llamados store-v1, store-v2 y store-german.

2. Verifica que la aplicación se haya implementado correctamente:

   kubectl get pod
   

   El resultado es similar a este:

   NAME                            READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Verifica que los objetos Service se hayan implementado de forma correcta:

   kubectl get service
   

   El resultado es similar a este:

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Crea una HTTPRoute

Los recursos de ruta definen reglas específicas del protocolo para asignar tráfico de una puerta de enlace a backends de Kubernetes. El recurso HTTPRoute realiza coincidencias y filtros de tráfico HTTP y HTTPS, y es compatible con todas las GatewayClasses gke-l7-*.

En esta sección, implementarás una HTTPRouter, que configura la puerta de enlace con reglas de enrutamiento necesarias para llegar a la aplicación de muestra.

1. Guarda el siguiente manifiesto como un archivo llamado store-route-external.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
   spec:
     parentRefs:
     - kind: Gateway
       name: external-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
   

   En este manifiesto, se describe una HTTPRouter que hace referencia a la puerta de enlace external-http.

2. Aplica el manifiesto al clúster:

   kubectl apply -f store-route-external.yaml
   

   La HTTPRoute store está vinculada a la puerta de enlace external-http mediante la propiedad parentRefs. En el siguiente diagrama, se muestran las reglas de enrutamiento configuradas en el balanceador de cargas subyacente:

   

   Las reglas de enrutamiento procesan el tráfico HTTP de la siguiente manera:

   • El tráfico a store.example.com/de se enruta al objeto Service store-german.
   • El tráfico a store.example.com con el encabezado HTTP "env: canary" se enruta al objeto Service store-v2.
   • El tráfico restante a store.example.com se enruta al objeto Service store-v1.

3. Verifica que se haya implementado la HTTPRoute:

   kubectl describe httproute store-external
   

   El resultado es similar a este:

   Name:         store-external
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1beta1
   Kind:         HTTPRoute
   <...>
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   external-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       Conditions:
         Last Transition Time:  2022-11-01T05:42:31Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
   Events:
     Type     Reason  Age    From                   Message
     ----     ------  ----   ----                   -------
     Normal   ADD     2m48s  sc-gateway-controller  default/store-external
     Normal  SYNC  61s (x3 over 2m27s)  sc-gateway-controller  Bind of HTTPRoute "default/store-external" to ParentRef Group:       "gateway.networking.k8s.io",
     ...
   

4. Verifica que la HTTPRoute esté vinculada a la puerta de enlace:

   kubectl describe gateway external-http
   

   El resultado es similar a este:

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   <...>
   Status:
     Addresses:
       Type:   IPAddress
       Value:  34.149.207.45
     Conditions:
       Last Transition Time:  2022-11-01T05:37:21Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T05:43:18Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    https
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         <...>
   

Envía tráfico a tu aplicación

Ahora que la puerta de enlace, la ruta y la aplicación están implementadas en el clúster, puedes pasar el tráfico a la aplicación.

1. Obtén la dirección IP de la puerta de enlace:

   kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}"
   

   El resultado es una dirección IP.

2. Crea una VM:

   gcloud cloud-shell ssh
   

3. Envía tráfico a la dirección IP de la puerta de enlace desde la VM. Debes configurar el encabezado del host de forma manual porque no eres propietario del nombre de host example.com.

   curl -H "host: store.example.com" https://GATEWAY_IP_ADDRESS --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Reemplaza GATEWAY_IP_ADDRESS por la dirección IP de la puerta de enlace del paso anterior.

   En el resultado, se muestra información de la app de demostración sobre la ubicación en la que se ejecuta:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:31:17",
     "zone": "us-central1-a"
   }
   

4. Para probar la coincidencia de ruta de acceso, ve a la versión en alemán del objeto Service store en store.example.com/de:

   curl -H "host: store.example.com" https://GATEWAY_IP_ADDRESS/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   El resultado confirma que un pod store-german entregó la solicitud:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!",
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl",
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:35:37",
     "zone": "us-central1-a"
   }
   

5. Envía tráfico a la versión canary del objeto Service store con el encabezado HTTP env: canary:

   curl -H "host: store.example.com" -H "env: canary " https://GATEWAY_IP_ADDRESS/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   El resultado confirma que un pod store-v2 entregó la solicitud:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb",
     "pod_name_emoji": "👩🏿",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:38:26",
     "zone": "us-central1-a"
   }
   

Implementa una puerta de enlace externa regional

En el siguiente ejemplo, se muestra cómo exponer una aplicación de almacenamiento con varios certificados adjuntos a la puerta de enlace externa regional mediante certificados autoadministrados y una HTTPRoute.

Crea una subred de proxy para la puerta de enlace regional

Debes configurar una subred de solo proxy antes de crear una puerta de enlace que use un balanceador de cargas de aplicaciones externo regional. Cada región de una VPC en la que usas el balanceador de cargas de aplicaciones externo regional debe tener una subred external_managed_proxy. En esta subred, se proporcionan direcciones IP internas a los proxies del balanceador de cargas.

Crea un certificado para proteger el tráfico de tus clientes

Puedes usar un certificado emitido y validado por la autoridad certificadora (CA) o crear un certificado autofirmado. Para obtener más información sobre cómo crear un certificado, consulta Almacena un certificado en un Secret de Kubernetes.

Nota: Los certificados SSL administrados por Google o CertificateMap no son compatibles con las puertas de enlace regionales. Usa certificados SSL regionales autoadministrados o secretos para proteger el tráfico entre tus clientes y la puerta de enlace regional. Para obtener más información sobre los certificados y los balanceadores de cargas de Google Cloud, consulta Certificados y balanceadores de cargas de Google Cloud

Crea una puerta de enlace HTTP(S) regional externa

1. Crea una dirección IP estática regional para el balanceador de cargas externo.

   gcloud compute addresses create IP_ADDRESS_NAME \
     --region=COMPUTE_REGION \
     --network-tier=STANDARD
   

   Reemplaza lo siguiente:

   • IP_ADDRESS_NAME: el nombre de la dirección IP estática nueva
   • COMPUTE_REGION: La región de Compute Engine en la que se ejecuta tu clúster

2. Crea una puerta de enlace del balanceador de cargas de aplicaciones externo regional con un certificado autoadministrado de la siguiente manera y guarda el manifiesto como regional-gateway.yaml:

     kind: Gateway
     apiVersion: gateway.networking.k8s.io/v1beta1
     metadata:
       name: external-regional-http
     spec:
       gatewayClassName: gke-l7-regional-external-managed
       listeners:
       - name: https
         protocol: HTTPS
         port: 443
         tls:
           mode: Terminate
           certificateRefs:
           - name: store-example-com
       addresses:
       - type: NamedAddress
         value: IP_ADDRESS_NAME
   

3. Aplica el manifiesto regional-gateway:

     kubectl apply -f regional-gateway.yaml
   

4. Verifica la configuración.

     kubectl get gateway
   

   El resultado es similar a este:

   NAME            CLASS                              ADDRESS         READY   AGE
   external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s
   

   Para obtener más detalles, usa un comando describe:

   kubectl describe gateway
   

   El resultado es similar a este:

   Name:         external-regional-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-regional-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
     ...
   

Implementa la aplicación de demostración

Puedes implementar tus aplicaciones y rutas sin importar la implementación de las puertas de entrada.

Para obtener más información sobre cómo implementar las aplicaciones de demostración, consulta Implementa las aplicaciones de demostración.

Crea una HTTPRoute

Debes crear una HTTPRoute para hacer coincidir el tráfico HTTP y HTTPS y filtrarlo.

Envía tráfico a tu aplicación

Después de implementar la aplicación y crear HTTPRoutes, puedes pasar el tráfico a la aplicación.

Para obtener más información sobre cómo enviar tráfico a tu aplicación, consulta Envía tráfico a tu aplicación.

Usa puertas de enlace compartidas

Las API de Gateway usan recursos separados, de puerta de enlace y de ruta, para implementar balanceadores de cargas y reglas de enrutamiento. Esto difiere de Ingress, que combina todo en un recurso. Cuando se divide la responsabilidad entre los recursos, la puerta de enlace permite que el balanceador de cargas y sus reglas de enrutamiento se implementen por separado y que diferentes usuarios o equipos lo implementen. Esto permite que las Gateways se conviertan en Gateways compartidas que se conectan a muchas rutas diferentes que pueden ser de total propiedad y administración de equipos independientes, incluso en diferentes espacios de nombres.

Implementa rutas en una puerta de enlace compartida

Este ejemplo se basa en la puerta de enlace internal-http implementada en Implementa una puerta de enlace interna.

En este ejemplo, el equipo del sitio implementa su aplicación, Services y una HTTPRoute para hacer coincidir el tráfico de la puerta de enlace con esos Services.

1. Implementa la aplicación de ejemplo

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml
   

2. Guarda el siguiente manifiesto como un archivo llamado site-route-internal.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: site-internal
   spec:
     parentRefs:
     - kind: Gateway
       name: internal-http
     hostnames:
     - "site.example.com"
     rules:
     - backendRefs:
       - name: site-v1
         port: 8080
   

   En este manifiesto, se describe una HTTPRouter que coincide con todo el tráfico para site.example.com y lo enruta al Service site-v1.

3. Aplica el manifiesto al clúster:

   kubectl apply -f site-route-internal.yaml
   

4. Verifica que la HTTPRoute esté vinculada a la puerta de enlace:

   kubectl describe httproute.gateway.networking.k8s.io site-internal
   

   El resultado es similar a este:

   Status:
     Parents:
       Conditions:
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
         ...
   

   Si la condición Accepted para la puerta de enlace es True, la HTTPRoute se vinculó correctamente a la puerta de enlace. Para obtener más información sobre el campo Estado, consulta Estado de la ruta.

5. Verifica que el tráfico a la puerta de enlace se enrute de forma correcta:

   curl -H "host: site.example.com" GATEWAY_IP_ADDRESS
   curl -H "host: store.example.com" GATEWAY_IP_ADDRESS
   

   Reemplaza GATEWAY_IP_ADDRESS por la dirección IP de la puerta de enlace.

   Debes usar una máquina virtual (VM) en la misma VPC que la puerta de enlace.

   El resultado es similar a este:

   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "site.example.com",
     "metadata": "site-v1",
     "pod_name": "site-v1-5d64fc4d7d-fz6f6",
     "pod_name_emoji": "👩🏼‍🍳",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   ...
   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "pod_name": "store-v1-6d8d58d78-vz8pn",
     "pod_name_emoji": "🧝🏻‍♂️",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   

Configura el backend predeterminado de Gateway

Todas las GatewayClasses de gke-l7-* muestran HTTP 404 en tráfico sin igual. Puedes configurar el backend predeterminado con una Route predeterminada explícita que envíe tráfico sin coincidencia a un servicio proporcionado por el usuario.

Nota: Las puertas de enlace están configuradas para controlar códigos de error como 404 (No encontrado) y 500 (Error del servidor), incluso sin definiciones de backend explícitas. El comportamiento predeterminado puede variar entre las implementaciones de Gateway. Para obtener un mayor control sobre el manejo de errores, considera configurar backends personalizados.

La siguiente HTTPRoute es un ejemplo de cómo personalizar el backend predeterminado. Si aplicas una HTTPRoute similar a la siguiente, tiene prioridad sobre el backend predeterminado implícito:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Esta HTTPRoute coincide con todo el tráfico de una puerta de enlace en particular. Solo puedes tener una de esas reglas para cada Gateway; de lo contrario, se aplican las reglas y se aplica el orden de prioridad.

Puedes usar un backend predeterminado para evitar que alguien cree un backend de ruta predeterminado que enrute todo el tráfico de Gateway. Una HTTPRoute explícita siempre tiene prioridad sobre las HTTPRoutes nuevas con reglas de enrutamiento en conflicto.

Configura una dirección IP estática para una puerta de enlace

Cada puerta de enlace tiene una dirección IP que usa para escuchar el tráfico. Si no especificas una dirección IP en la puerta de enlace, el controlador de puerta de enlace proporcionará una dirección IP de forma automática. También puedes crear una dirección IP estática para que la dirección IP exista de forma independiente del ciclo de vida de la puerta de enlace.

Después de implementar una puerta de enlace, su dirección IP se muestra en el campo de estado:

kind: Gateway
...
status:
  addresses:
    - value: 10.15.32.3

Según la GatewayClass, la dirección IP se asigna desde las siguientes subredes:

GatewayClasses	Grupo de direcciones IP predeterminado
gke-l7-rilb gke-l7-rilb-mc	Direcciones IP privadas regionales del rango de direcciones IPv4/IPv6 del nodo principal
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Direcciones IP públicas regionales de los rangos de IPv4/IPv6 externos regionales de Google
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Direcciones IP públicas globales de los rangos IPv4/IPv6 externos globales de Google

El campo addresses.NamedAddress te permite especificar una dirección IP independiente de la puerta de enlace. Puedes crear un recurso de dirección IP estática antes de la implementación de la puerta de enlace y de que la NamedAddress haga referencia al recurso. Puedes volver a usar la dirección IP estática incluso si se borra la puerta de enlace.

Usa una dirección IP con nombre

Para configurar una dirección IP, especifica una NamedAddress. Debes aprovisionar una dirección IP estática antes de crear una puerta de enlace.

1. Crea un recurso de dirección IP estática:

   gcloud compute addresses create IP_ADDRESS_NAME \
       --purpose=SHARED_LOADBALANCER_VIP \
       --region=COMPUTE_REGION \
       --subnet=SUBNET \
       --project=PROJECT_ID
   

   Reemplaza lo siguiente:

   • IP_ADDRESS_NAME: el nombre de la dirección IP estática nueva
   • COMPUTE_REGION: para las puertas de enlace regionales, es la región de Compute Engine en la que se ejecuta el clúster. Esta marca no es necesaria para las puertas de enlace globales externas.
   • SUBNET: la subred de la dirección IP. Esta marca no es necesaria para las puertas de enlace globales externas.
   • PROJECT_ID: es el proyecto en el que se ejecuta tu clúster de GKE.

2. Guarda el siguiente manifiesto como un archivo llamado named-ip-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: internal-http
   spec:
     gatewayClassName: gke-l7-rilb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
     addresses:
     - type: NamedAddress
       value: IP_ADDRESS_NAME
   

   En este manifiesto, se describe una puerta de enlace que hace referencia a la dirección IP con nombre.

3. Aplica el manifiesto al clúster:

   kubectl apply -f named-ip-gateway.yaml
   

4. Verifica la dirección IP de la puerta de enlace:

   kubectl describe gateway internal-http
   

   El resultado es similar a este:

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Addresses:
       Type:              NamedAddress
       Value:             IP_ADDRESS_NAME
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.15.32.103
   

Configurar redireccionamientos de HTTP a HTTPS

Cloud Load Balancing ofrece funcionalidad de redireccionamiento de HTTP a HTTPS. Un balanceador de cargas de aplicaciones externo redirecciona las solicitudes HTTP sin encriptar a un balanceador de cargas HTTPS que use la misma dirección IP. Cuando creas una puerta de enlace con redireccionamientos HTTP a HTTPS habilitados, automáticamente se crean ambos balanceadores de cargas. Las solicitudes a la dirección IP externa de la puerta de enlace en el puerto 80 se redireccionan de manera automática a la misma dirección IP externa en el puerto 443.

De forma predeterminada, los redireccionamientos HTTP a HTTPS no se definen en la puerta de enlace.

Para redireccionar el tráfico HTTP a HTTPS, configura una puerta de enlace que controle el tráfico HTTP y HTTPS. Si inhabilitas HTTP o HTTPS, la puerta de enlace no redirecciona el tráfico.

En los siguientes ejemplos, se muestra cómo puedes usar el redireccionamiento de HTTP a HTTPS como un medio para garantizar que el tráfico de los clientes que se dirigen a tus aplicaciones web siempre se redireccione a una página segura.

Nota: Los redireccionamientos HTTP a HTTPS no son compatibles con los GatewayClasses gke-l7-gxlb ni gke-l7-gxlb-mc. Para obtener más información sobre las diferentes funciones que admite cada GatewayClass, consulta Capacidades de GatewayClass.

Redirecciona el tráfico HTTP desde el espacio de nombres de Gateway

En el siguiente ejemplo, la puerta de enlace está configurada para permitir Same (adjunto del mismo espacio de nombres) en el objeto de escucha HTTP, mientras que el objeto de escucha HTTPS está abierto en todos los espacios de nombres. Cuando se usa esta configuración, solo debe existir el redireccionamiento HTTPRoute en el mismo espacio de nombres que la puerta de enlace.

Esta configuración garantiza que ninguna HTTPRoute adicional pueda vincularse al objeto de escucha HTTP de la Gateway. Esto requiere que las HTTPRoutes del equipo de aplicaciones no estén permitidas en el espacio de nombres gateway-infra.

1. Crea el espacio de nombres gateway-infra de la puerta de enlace. Guarda el manifiesto como gateway-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: gateway-infra
   

2. Aplica el manifiesto

   kubectl apply -f gateway-namespace.yaml
   

3. Crea una puerta de enlace mediante el siguiente manifiesto y guárdalo como external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: Same
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
   

   • El campo namespaces en la sección allowedRoutes restringe el objeto de escucha HTTP al espacio de nombres gateway-infra solo de la puerta de enlace.

   • El objeto de escucha https no incluye una restricción en los espacios de nombres permitidos, por lo que todos los espacios de nombres usan https con una HTTPRoute.

4. Aplica el manifiesto

   kubectl apply -f external-gateway.yaml
   

5. Para forzar el redireccionamiento HTTPS, crea una HTTPRoute predeterminada con el siguiente manifiesto y guarda el manifiesto como redirect-httproute.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: redirect
     namespace: gateway-infra
   spec:
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • El campo sectionName indica a la puerta de enlace que coincida solo con el objeto de escucha HTTP. El filtro RequestRedirect fuerza el redireccionamiento al objeto de escucha https.

   Esta configuración redirecciona cualquier tráfico recibido en el puerto 80 de la puerta de enlace al objeto de escucha en el puerto 443 a través de la aplicación de una comunicación segura entre el cliente y el balanceador de cargas.

6. Aplica el manifiesto

   kubectl apply -f redirect-httproute.yaml
   

7. Crea un Service para una aplicación con el siguiente manifiesto. Guarda el manifiesto como service-deployment.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1
   spec:
     selector:
       app: store
       version: v1
     ports:
     - port: 8080
       targetPort: 8080
   
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: store
         version: v1
     template:
       metadata:
         labels:
           app: store
           version: 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: "store-v1"
   

8. Aplica el manifiesto

   kubectl apply -f service-deployment.yaml
   

9. Crea una HTTPRoute para una aplicación que solo permita HTTPS. Guarda el manifiesto como httproute.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
       namespace: gateway-infra
       sectionName: https
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

   Nota: Cuando configuras redireccionamientos de HTTP a HTTPS en la puerta de enlace, debes especificar el campo sectionName:https en la configuración de la ruta. Si la puerta de enlace tiene varios objetos de escucha configurados (por ejemplo, HTTP y HTTPS), debes especificar de forma explícita sectionName:https en la configuración de HTTPRoute. Esto garantiza que el redireccionamiento se aplique solo al objeto de escucha HTTPS. Si tu puerta de enlace solo tiene un objeto de escucha HTTPS, puedes omitir el campo sectionName, ya que el redireccionamiento se aplica a él de forma predeterminada.

10. Aplica el manifiesto

    kubectl apply -f httproute.yaml
    

Redirecciona el tráfico HTTP desde un espacio de nombres de infraestructura

En algunos casos, no hay una distinción clara entre el equipo de administración de la infraestructura o de plataforma y los equipos de aplicaciones, y evitar el uso inadecuado de la puerta de enlace puede convertirse en un desafío.

En el siguiente ejemplo, se restringe aún más el uso del objeto de escucha HTTP para evitar el uso no intencional del protocolo no seguro por parte de los equipos de aplicaciones. En este ejemplo, se configura la puerta de enlace para permitir que una HTTPRoute use el objeto de escucha HTTP solo si la ruta se encuentra en un espacio de nombres determinado (redireccionamiento HTTP) mientras abre el objeto de escucha HTTPS en todos los espacios de nombres. Puedes restringir el espacio de nombres de redireccionamiento de HTTP mediante el RBAC de Kubernetes para que los equipos de aplicaciones no puedan crear una HTTPRoute en este espacio de nombres por error.

1. Crea el espacio de nombres de una puerta de enlace. Guarda el manifiesto como gateway-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: gateway-infra
   

2. Aplica el manifiesto

   kubectl apply -f gateway-namespace.yaml
   

3. Crea el espacio de nombres de una Gateway y guarda el manifiesto como redirect-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: http-redirect
     labels:
       otherInfra: httpToHttps
   

   • Se configuran etiquetas específicas para este espacio de nombres.

4. Aplica el manifiesto

   kubectl apply -f redirect-namespace.yaml
   

5. Para restringir el uso de objeto de escucha HTTP, crea una puerta de enlace con el siguiente manifiesto. Guarda el manifiesto como external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: selector
           selector:
             matchLabels:
               otherInfra: httpToHttps
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
     ```
   

   • En el campo namespace, se especifica que la puerta de enlace se crea en el espacio de nombres gateway-infra.

   • El campo namespaces en la sección allowedRoutes restringe el objeto de escucha http al espacio de nombres que coincide con la etiqueta otherInfra: httpToHttps.

6. Aplica el manifiesto

   kubectl apply -f external-gateway.yaml
   

7. Para forzar el redireccionamiento HTTPS, crea una HTTPRoute predeterminada con el siguiente manifiesto. Guarda el manifiesto como http-redirect.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: redirect
     namespace: http-redirect
   spec:
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • El campo sectionName indica a la puerta de enlace que coincida solo con el objeto de escucha HTTP. El filtro RequestRedirect fuerza el redireccionamiento al objeto de escucha https.

8. Aplica el manifiesto

   kubectl apply -f http-redirect.yaml
   

9. Crea un Service para una aplicación con el siguiente manifiesto. Guarda el manifiesto como service-deployment.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1
   spec:
     selector:
       app: store
       version: v1
     ports:
     - port: 8080
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: store
         version: v1
     template:
       metadata:
         labels:
           app: store
           version: 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: "store-v1"
   

10. Aplica el manifiesto

    kubectl apply -f service-deployment.yaml
    

11. Crea una HTTPRoute para una aplicación que solo permita HTTPS a través del siguiente manifiesto. Guarda el manifiesto como http-route.yaml:

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: store-external
      labels:
        gateway: external-http
    spec:
      parentRefs:
      - name: external-http
        namespace: gateway-infra
        sectionName: https
      hostnames:
      - "store.example.com"
      rules:
      - backendRefs:
        - name: store-v1
          port: 8080
    

12. Aplica el manifiesto

    kubectl apply -f http-route.yaml
    

Configura redireccionamientos de ruta y reescrituras de URL

Los redireccionamientos de ruta de acceso implican redireccionar una solicitud entrante de una ruta de URL a otra. Los redireccionamientos de ruta de acceso te permiten cambiar la estructura de la URL cuando necesitas manejar URL desactualizadas u obsoletas.

Las reescrituras de URL ayudan a modificar la URL entrante antes de procesarla en el servidor. Te permite cambiar la estructura o el formato de la URL sin cambiar realmente el contenido subyacente o la estructura del archivo. La reescritura de URL es beneficiosa para crear URL fáciles de usar y optimizar con SEO y que además son fáciles de recordar y comprender. De forma predeterminada, los redireccionamientos de ruta y las reescrituras de URL no están configurados. Debes configurar de forma explícita esos redireccionamientos o reescrituras mediante un filtro en tu HTTPRoute.

GKE Gateway admite redireccionamientos de rutas de acceso y reescrituras de URL. Para obtener más información, consulta la página Redireccionamientos y reescrituras de rutas de acceso HTTP.

Configura redireccionamientos de rutas de acceso

Puedes configurar redireccionamientos de ruta de acceso para reemplazar toda la ruta de acceso o solo un prefijo en la URL.

Reemplazar toda la ruta de acceso

1. Para reemplazar una ruta de acceso completa, configura un filtro en una HTTPRoute que reemplace cualquier URL que contenga el prefijo /any-path en la ruta de URL por el valor estricto /new-path.

2. Crea un manifiesto HTTPRoute de la siguiente manera y asígnale el nombre store.yaml:

     apiVersion: gateway.networking.k8s.io/v1beta1
     kind: HTTPRoute
     metadata:
       name: store
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - store.example.com
       rules:
       - matches:
         - path:
             type: PathPrefix
             value: /any-path
         filters:
         - type: RequestRedirect
           requestRedirect:
             path:
               type: ReplaceFullPath
               replaceFullPath: /new-path
             statusCode: 302
   

   Por ejemplo, este manifiesto establece una regla de enrutamiento para una HTTPRoute de la siguiente manera: cualquier ruta a la URL https://store.example.com/any-path/... se debería redireccionar a una ubicación nueva, https://store.example.com/new-path/ (estricta).

3. Aplica el manifiesto

   kubectl apply -f store.yaml
   

Esta regla de enrutamiento sigue una regla de redireccionamiento estricta, lo que significa que el navegador no intenta almacenar en caché el redireccionamiento. En su lugar, redirecciona a la versión más reciente.

Reemplaza solo un prefijo

1. Para reemplazar solo un prefijo, configura un filtro en una HTTPRoute que reemplace cualquier URL que contenga el prefijo /any-prefix en la ruta de URL por el valor estricto /new-prefix.

2. Crea un manifiesto HTTPRoute de la siguiente manera y asígnale el nombre store.yaml:

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: HTTPRoute
   metadata:
     name: store
   spec:
     parentRefs:
       - kind: Gateway
         name: external-http
     hostnames:
     - store.example.com
     rules:
     - matches:
         - path:
             type: PathPrefix
             value: /any-prefix
       filters:
       - type: RequestRedirect
         requestRedirect:
           path:
             type: ReplacePrefixMatch
             replacePrefixMatch: /new-prefix
           statusCode: 302
   

   Por ejemplo, este manifiesto establece una regla de enrutamiento para una HTTPRoute de la siguiente manera: cualquier ruta a la URL https://store.example.com/any-path/v1/... se debe redireccionar a una ubicación nueva, https://store.example.com/new-path/v1/... (solamente).

3. Aplica el manifiesto

     kubectl apply -f store.yaml
   

Esta regla de enrutamiento sigue la única regla de redireccionamiento, lo que garantiza que el navegador siempre te redireccione a la misma página deseada.

Configura reescrituras de URL

Configura las reescrituras de URL para cambiar la forma en que se muestra una URL a los usuarios. Puedes usar las reescrituras de URL para que las URL sean más fáciles de usar, mejorar la SEO o redireccionar a los usuarios a una página nueva.

Vuelve a escribir todo el nombre de host

Para reescribir todo el nombre de host, ejecuta el siguiente comando:

1. Configura un filtro en una HTTPRoute que le indique a la puerta de enlace que reemplace la información de Host en el encabezado de la solicitud de www.example.com a store.example.com antes de reenviar la solicitud al servicio de backend.

2. Crea un manifiesto HTTPRoute de la siguiente manera y asígnale el nombre www.yaml:

     apiVersion: gateway.networking.k8s.io/v1beta1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - filters:
         - type: URLRewrite
           urlRewrite:
             hostname: store.example.com
         backendRefs:
         - name: store-v1
           port: 8080
   

   Por ejemplo, con la configuración anterior, cualquier solicitud a https://www.example.com se reenvía al servicio de backend con el encabezado Host: store.example.com, en lugar de Host: www.example.com.

3. Aplica el manifiesto

     kubectl apply -f www.yaml
   

Vuelve a escribir con modificadores de ruta

Puedes combinar las reescrituras con modificadores de ruta para proporcionar modificaciones avanzadas de URL y de ruta de acceso antes de retransmitir la solicitud al servicio de backend.

Para volver a escribir con modificadores de ruta, haz lo siguiente:

1. Configura un filtro en una HTTPRoute que le indique a la puerta de enlace que reemplace la información de “Host” en el encabezado de la solicitud de www.example.com a store.example.com y reemplace el valor /store por / antes de reenviar la solicitud al servicio de backend.

2. Crea un manifiesto HTTPRoute de la siguiente manera y asígnale el nombre www.yaml:

     apiVersion: gateway.networking.k8s.io/v1beta1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - matches:
         - path:
             type: PathPrefix
             value: /store
         filters:
         - type: URLRewrite
           urlRewrite:
             hostname: store.example.com
             path:
               type: ReplacePrefixMatch
               replacePrefixMatch: /de
         backendRefs:
         - name: store-german
           port: 8080
   

   Por ejemplo, con la configuración anterior, cualquier solicitud a https://www.example.com/store/... se reenvía al servicio de backend con Host: store.example.com en el encabezado de la solicitud (en lugar de Host: www.example.com) y /store se reescribe como /de.

3. Aplica el manifiesto

   kubectl apply -f www.yaml
   

Verifica la configuración

Sigue estos pasos para verificar que el filtro se haya aplicado después de crear tu HTTPRoute con reescritura de URL o filtros de redireccionamientos de ruta:

kubectl get httproute www -o yaml

El resultado es similar a este:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1beta1","kind":"HTTPRoute","metadata":{"annotations":{},"name":"www","namespace":"default"},"spec":{"hostnames":["www.example.com"],"parentRefs":[{"kind":"Gateway","name":"external-http"}],"rules":[{"backendRefs":[{"name":"store-german","port":8080}],"filters":[{"type":"URLRewrite","urlRewrite":{"hostname":"store.example.com","path":{"replacePrefixMatch":"/de","type":"ReplacePrefixMatch"}}}],"matches":[{"path":{"type":"PathPrefix","value":"/store"}}]}]}}
    creationTimestamp: "2023-06-22T01:00:42Z"
    generation: 3
    name: www
    namespace: default
    resourceVersion: "51268631"
    uid: e516493e-806d-44d6-ae0d-1c9ff25682cf
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: external-http
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: store-german
        port: 8080
        weight: 1
      filters:
      - type: URLRewrite
        urlRewrite:
          hostname: store.example.com
          path:
            replacePrefixMatch: /de
            type: ReplacePrefixMatch
      matches:
      - path:
          type: PathPrefix
          value: /store
  status:
    parents:
    - conditions:
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: Accepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: ReconciliationSucceeded
        status: "True"
        type: Reconciled
      controllerName: networking.gke.io/gateway
      parentRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: external-http

Para obtener más detalles, usa un comando describe:

kubectl describe httproute

Configura encabezados personalizados de solicitud y respuesta

Los encabezados de solicitud y respuesta personalizados te permiten especificar encabezados adicionales para las solicitudes y respuestas HTTP(S). Según la información que detecte el balanceador de cargas, estos encabezados pueden incluir la siguiente información:

• Latencia para el cliente
• Ubicación geográfica de la dirección IP del cliente
• Parámetros de la conexión TLS

De forma predeterminada, no hay encabezados personalizados agregados a la solicitud enviada o recibida desde o hacia tus servicios de backend, debes configurar encabezados personalizados de manera explícita con un filtro en tu HTTPRoute.

Para configurar encabezados personalizados, agrega una sección de filtro en las reglas de HTTPRoute de la siguiente manera:

Configura encabezados de solicitud personalizados

Crea un manifiesto HTTPRoute con un filtro RequestHeaderModifier y guárdalo como http-route-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    <...>
    rules:
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              <...>

Aplica el manifiesto

  kubectl apply -f http-route-request.yaml

Configura encabezados de respuesta personalizados

Crea un manifiesto HTTPRoute con un filtro ResponseHeaderModifier y guárdalo como http-route-response.yaml:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Aplica el manifiesto

  kubectl apply -f http-route-response.yaml

Nota:El controlador de puerta de enlace de GKE implementa encabezados personalizados en el mapa de URL y no en el servicio de backend.

Puedes agregar, configurar y quitar encabezados como se describe en la implementación de la API de Gateway. Puedes configurar tu HTTPRoute con un encabezado personalizado mediante las variables compatibles de Google Cloud.

Ejemplo 1:

Para configurar una HTTPRoute que agregue información de la ubicación del cliente a la solicitud HTTP antes de enviarla al servicio de backend, crea un manifiesto HTTPRoute y asígnale el nombre external-http-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

Por ejemplo, para los clientes ubicados en Estrasburgo, Francia, la puerta de enlace agrega un encabezado como X-Client-Geo-Location:FR,Strasbourg.

Ejemplo 2:

Para configurar una HTTPRoute que agregue un encabezado de respuesta personalizado a fin de admitir HTTP con Seguridad de Transporte Estricta, crea un manifiesto HTTPRoute y asígnale el nombre external-http-response.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Verifica la configuración

1. Para verificar la configuración después de configurar encabezados de solicitud y respuesta personalizados, haz lo siguiente:

     kubectl get httproute
   

   El resultado es similar a este:

     NAME    HOSTNAMES               AGE
     store   ["store.example.com"]   4d23h
   

2. Para obtener más detalles, usa el comando describe:

     kubectl describe httproute
   

   El resultado es similar a este:

     Name:         store
     Namespace:    default
     Labels:       <none>
     Annotations:  <none>
     API Version:  gateway.networking.k8s.io/v1beta1
     Kind:         HTTPRoute
     Metadata:
       Creation Timestamp:  2023-05-27T00:51:01Z
       Generation:          5
       Resource Version:    25418887
       UID:                 2e07a1b8-420b-41b4-acd1-cecbfcd39f42
     Spec:
       Hostnames:
         store.example.com
       Parent Refs:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
       Rules:
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v1
           Port:    8080
           Weight:  1
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v2
           Port:    8080
           Weight:  1
         Matches:
           Headers:
             Name:   env
             Type:   Exact
             Value:  canary
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-german
           Port:    8080
           Weight:  1
         Filters:
           Request Header Modifier:
             Add:
               Name:   X-Client-Geo-Location
               Value:  {client_region},{client_city}
           Type:       RequestHeaderModifier
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /de
     Status:
       <...>
   

Estado de la ruta

Los recursos HTTPRoute emiten condiciones y eventos para ayudar a los usuarios a comprender si una HTTPRoute se vinculó correctamente a una o más puertas de enlace o si se rechazó.

Condiciones de HTTPRoute

Las condiciones de HTTPRoute indican el estado de la ruta y las puertas de enlace a las que está vinculada. Debido a que una ruta se puede vincular a varias puertas de enlace, esta es una lista de puertas de enlace y las condiciones individuales entre la ruta y cada puerta de enlace.

• Accepted=True indica que la HTTPRoute está vinculada correctamente a una puerta de enlace.
• Accepted=False indica que la HTTPRoute se rechazó para vincularse con esta puerta de enlace.

Si no hay puertas de enlace enumeradas en el encabezado Gateway bindings, es posible que tus selectores de etiquetas de HTTPRoute y de etiquetas de puerta de enlace no coincidan. Esto puede ocurrir si ninguna puerta de enlace selecciona la ruta.

Eventos de HTTPRouter

Los eventos HTTPRoute proporcionan detalles sobre el estado de HTTPRoute. Los eventos se agrupan por los siguientes motivos:

• Los eventos ADD se activan mediante un recurso que se agrega.
• Los eventos UPDATE se activan mediante un recurso que se actualiza.
• Los eventos SYNC se activan mediante una conciliación periódica.

Combinación, prioridad y validación de rutas

Prioridad de ruta

La API de Gateway define reglas de prioridad estrictas que indican cómo el tráfico coincide con las rutas que tienen reglas de enrutamiento superpuestas. La prioridad entre dos HTTPRoutes superpuestas es la siguiente:

1. Combinación de nombres de host: La coincidencia de nombres de host más larga o más específica.
2. Combinación de rutas de acceso: La coincidencia de rutas de acceso más larga o más específica.
3. Combinación de encabezados: La mayor cantidad de encabezados HTTP que coinciden.
4. Conflicto: Si las tres reglas anteriores no establecen prioridad, la prioridad va al recurso HTTPRouter con la marca de tiempo más antigua.

Combinación de rutas

Para las GatewayClasses gke-l7, todas las HTTPRouters de una puerta de enlace determinada se combinan en el mismo recurso de mapa de URL. La manera en que las HTTPRoutes se combinan depende del tipo de superposición entre las HTTPRoutes. La HTTPRoute del ejemplo anterior se puede dividir en tres HTTPRoutes diferentes para ilustrar la combinación y la prioridad de rutas:

1. Combinación de rutas: Las tres HTTPRoutes se conectan con la misma Gateway internal-http, por lo que se combinan.
2. Combinación de nombres de host: Las tres rutas coinciden para store.example.com, por lo que se combinan sus reglas de nombre de host.
3. Combinación de rutas: tore-german-route tiene una ruta de acceso /de más específica, por lo que no se combina más. store-v1-route y store-v2-route también coinciden en la misma ruta /*, por lo que se combinan en la ruta.
4. Combinación de encabezados: store-v2-route tiene un conjunto más específico de coincidencias de encabezados HTTP que store-v1-route, por lo que no se combinan más.
5. Conflicto: Debido a que las Routes se pueden combinar en el nombre de host, la ruta de acceso y los encabezados, no hay conflictos, y todas las reglas de enrutamiento se aplicarán al tráfico.

La única HTTPRoute que se usa en el ejemplo anterior es equivalente a estas tres rutas separadas:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-v1-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - kind: Service
      name: store-v1
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-v2-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - kind: Service
      name: store-v2
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-german-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /de
    backendRefs:
    - kind: Service
      name: store-german
      port: 8080

Puertas de enlace de Kubernetes y puertas de enlace de Istio

Ten en cuenta que la API de Kubernetes Gateway y la API de Istio tienen un recurso llamado Gateway. Si bien realizan funciones similares, no son el mismo recurso. Si usas Istio y la API de Gateway en el mismo clúster de Kubernetes, estos nombres se superponen cuando usas kubectl en la línea de comandos. kubectl get gateway puede mostrar los recursos de la puerta de enlace de Kubernetes y no los de la puerta de enlace de Istio, o viceversa.

$ kubectl api-resources
NAME       SHORTNAMES   APIGROUP                       NAMESPACED   KIND
gateways   gw           networking.istio.io/v1beta1    true         Gateway
gateways   gtw          networking.k8s.io/v1beta1      true         Gateway

Si usas Istio y actualizas a GKE 1.20 y versiones posteriores, se recomienda comenzar a usar el nombre corto del recurso de Gateway o especificar el grupo de API. El nombre corto de una puerta de enlace de Kubernetes es gtw, y el nombre corto de una puerta de enlace de Istio es gw. Los siguientes comandos muestran los recursos de puerta de enlace de Kubernetes y de puerta de enlace de Istio, respectivamente.

# Kubernetes Gateway
$ kubectl get gtw
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

$ kubectl get gateway.networking.x-k8s.io
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

# Istio Gateway
$ kubectl get gw
NAME               AGE
bookinfo-gateway   64m

$ kubectl get gateway.networking.istio.io
NAME               AGE
bookinfo-gateway   64m

Soluciona problemas

Falta la subred de solo proxy en la región

Síntoma:

El siguiente problema puede ocurrir cuando creas una puerta de enlace regional (interna o externa):

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/[REGION_NAME]/targetHttpProxies/gkegw-x5vt-default-internal-http-[ID]'. A reserved managed proxy subnetwork with purpose REGIONAL_MANAGED_PROXY is required.

Motivo:

Este mensaje de error indica que no existe una subred de solo proxy en la región de la puerta de enlace.

Solución alternativa:

Para resolver este problema, configura una subred de solo proxy.

La subred de solo proxy ya existe en la región con el propósito incorrecto

Síntoma:

El siguiente problema puede ocurrir cuando creas una subred de solo proxy para la puerta de enlace regional (interna o externa):

ERROR: (gcloud.compute.networks.subnets.create) Could not fetch resource:
 - The resource 'projects/[PROJECT_NAME]/regions/[REGION_NAME]/subnetworks/[PROXY_ONLY_SUBNET_NAME]' already exists

Motivo:

Este mensaje de error indica que intentaste crear una subred de solo proxy regional en una región que ya tiene una subred de solo proxy.

Solución alternativa:

Para resolver este problema, sigue estos pasos:

1. Comprueba que ya exista una subred de solo proxy en la región y verifica que tenga el propósito correcto:

   1. Enumera tus subredes para descubrir cuál es la subred de solo proxy en la región:

      gcloud compute networks subnets list --regions=COMPUTE_REGION
      

      Reemplaza COMPUTE_REGION por la región de Compute Engine en la que quieres crear la puerta de enlace regional.

   2. Describe la subred de solo proxy en la región para encontrar su propósito:

      gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
          --region COMPUTE_REGION | grep -E 'name|purpose'
      

      Reemplaza PROXY_ONLY_SUBNET por la subred de solo proxy.

   La puerta de enlace de GKE solo admite subredes de solo proxy REGIONAL_MANAGED_PROXY para puertas de enlace regionales (internas o regionales).

2. Si la subred de solo proxy existente en la región se creó con un propósito INTERNAL_HTTPS_LOAD_BALANCER, migra su propósito a REGIONAL_MANAGED_PROXY.

¿Qué sigue?

• Obtén más información sobre el controlador de Gateway.
• Obtén más información sobre cómo configurar los recursos de la puerta de enlace mediante políticas.