Some or all of the information on this page might not apply to Trusted Cloud by S3NS. See Differences from Google Cloud for more details.

Esta página se ha traducido con Cloud Translation API.

Desplegar pasarelas

Autopilot Standard

En esta página se describe cómo desplegar recursos de Gateway de Kubernetes para equilibrar la carga del tráfico de entrada a un solo clúster de Google Kubernetes Engine (GKE).

Para desplegar pasarelas con el fin de balancear la carga del tráfico de entrada en varios clústeres (o flotas), consulta Desplegar pasarelas de varios clústeres.

Para obtener más información sobre configuraciones de Gateway específicas, como el enrutamiento entre espacios de nombres y la división del tráfico HTTP, consulta las guías de usuario de la API Gateway.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Asegúrate de que tienes un clúster Autopilot o Standard. Para crear un clúster, consulta Crear un clúster de Autopilot.

Requisitos de GKE Gateway Controller

La API Gateway solo se admite en clústeres nativos de VPC.
Si usas GatewayClasses internas, debes habilitar una subred de solo proxy.
Tu clúster debe tener habilitado el complemento HttpLoadBalancing.
Si usas Istio, debes actualizarlo a una de las siguientes versiones:
- 1.15.2 o posterior
- 1.14.5 o posterior
- 1.13.9 o posterior.
Si utilizas una VPC compartida, en el proyecto host debes asignar el rol Compute Network User a la cuenta de servicio de GKE del proyecto de servicio.

Restricciones y limitaciones

Cuando uses GKE Gateway, ten en cuenta las siguientes limitaciones y restricciones:

Las GatewayClasses de GKE admiten diferentes funciones en función del balanceador de carga que utilicen. Para obtener más información sobre las diferentes funciones compatibles con cada GatewayClass, consulta Funciones de GatewayClass.

Práctica recomendada:
Para obtener un rendimiento óptimo, limita el número de pasarelas a un máximo de 100. Si se supera este límite, el rendimiento puede verse afectado o la latencia puede aumentar.
No puedes usar FrontendConfig ni BackendConfig para configurar una pasarela. Debes usar una política.
GKE Gateway se comporta de forma diferente a Ingress, ya que Gateway no infiere los parámetros de comprobación de estado. Si tu servicio no devuelve 200 para las solicitudes a GET / o tienes otras comprobaciones de disponibilidad 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 del tráfico.
Puedes ver los recursos de balanceador de carga que crea GKE para las pasarelas en la consola de Trusted Cloud , pero estos recursos no hacen referencia a la pasarela ni al clúster de GKE al que están asociados.
No puedes generar automáticamente un certificado SSL gestionado por Google con Gateways, pero sí puedes crear y hacer referencia a un certificado SSL gestionado por Google de forma manual. Para obtener más información, consulta Proteger una pasarela.
HTTPRoute es el único tipo de ruta admitido. No se admiten TCPRoutes, UDPRoutes ni TLSRoutes. Para ver una lista de los campos que admite el controlador de GKE Gateway, consulta Funciones de GatewayClass.
Los encabezados de solicitud y respuesta personalizados con redirecciones de pasarela o de ruta y las reescrituras de URLs con pasarela solo están disponibles en la versión 1.27 de GKE o en versiones posteriores.
No se admite GatewayClass gke-l7-gxlb en los encabezados de solicitud y respuesta personalizados con redirecciones de pasarela y de ruta, ni en las reescrituras de URLs con pasarela.
Cuando se configuran encabezados de solicitud y respuesta personalizados de HTTPRoute, no se admiten las siguientes Trusted Cloud variables:
- cdn_cache_id (Cloud CDN no es compatible con la pasarela de GKE)
- cdn_cache_status (Cloud CDN no es compatible con la pasarela de GKE)
- origin_request_header (Las políticas de CORS no se admiten en GKE Gateway)
GKE Gateway no admite la función de balanceo de carga de Cloud CDN.
No se admiten encabezados personalizados de TLS mutuo (mTLS con GKE Gateway)
Trusted Cloud by S3NS Las limitaciones del balanceador de carga de aplicación clásico se aplican a la puerta de enlace de GKE. Además, no puedes configurar un encabezado de respuesta Host personalizado en el servicio de backend.
Las redirecciones de ruta y las reescrituras de URL son mutuamente excluyentes, por lo que no puedes usar ambos filtros al mismo tiempo en las mismas reglas.
Cloud Load Balancing no admite la redirección del tráfico a otro puerto. Para ver la lista de campos que admite el controlador de GKE Gateway, consulta las funciones de GatewayClass.
GKE Gateway no admite comodines, expresiones regulares ni URLs dinámicas.
Si especificas una pasarela con una clase de pasarela externa regional, el controlador aprovisiona una dirección IP interna en lugar de la dirección externa. Para saber cómo usar una dirección con nombre con el balanceador de carga de aplicación externo regional, consulta el artículo sobre cómo desplegar una pasarela externa regional.
Gateway utiliza NEGs independientes para aprovisionar grupos de puntos finales de red. Para asegurarte de que el controlador de Gateway reconcilia correctamente la configuración del balanceador de carga, no puedes modificar la anotación cloud.google.com/neg de un servicio que forme parte de la Gateway.
La puerta de enlace de GKE no admite referencias a un servicio que también esté referenciado por un Ingress de GKE.
Cuando se configura un Gateway para aprovisionar una dirección IP, no se admite el cambio del Gateway.spec.gatewayClass. Para asegurarte de que el controlador de Gateway reconcilie correctamente el balanceador de carga, elimina el Gateway que ya tengas e implementa de nuevo el archivo de 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 obtener el mismo resultado.
Si usas GKE Gateway con external-dns y el estado de salud de la Gateway es incorrecto, de forma predeterminada, todos los registros DNS asociados a la Gateway se eliminan de tus zonas DNS.

Práctica recomendada:
Cuando se ejecute external-dns, define la marca policy=upsert-only. Esta configuración ayuda a evitar que se eliminen los registros DNS.
Si se elimina un puerto de un Service al que hace referencia GKE Gateway a través de una ruta, también debes actualizar la anotación de NEG independiente en el servicio para eliminar ese puerto. Si no lo haces, el controlador de NEG dejará de sincronizar los endpoints de Pod de este servicio. Para obtener más información, consulta NEG Controller stops managing endpoints when port removed from Service (El controlador NEG deja de gestionar endpoints cuando se elimina el puerto del servicio).
Las implementaciones que usan pasarelas de varios clústeres (MCG) que usan clústeres zonales son susceptibles de sufrir interrupciones del servicio durante las actualizaciones de clústeres. Este problema se produce porque un mecanismo de detección de grupos de endpoints de red (NEG) antiguo puede informar incorrectamente de que hay cero back-ends cuando el plano de control del clúster zonal no está disponible temporalmente. Estamos trabajando en una solución a largo plazo. Para evitar este único punto de fallo, usa clústeres de GKE regionales con MCG.

Habilitar la API Gateway en tu clúster

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

Antes de actualizar un clúster de GKE para habilitar la API Gateway, asegúrate de que se cumplen los requisitos mínimos antes de continuar con la actualización.

Para habilitar la API Gateway en un clúster de GKE (Autopilot o Standard), usa el siguiente comando. Esta operación puede tardar hasta 45 minutos en reconciliarse e instalar los CRDs.

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

Haz los cambios siguientes:

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

La marca --gateway-api=standard indica a GKE que instale los v1beta1CRDs con el clúster.

Verificar el clúster

Después de crear o actualizar el clúster, el controlador de GKE Gateway instala automáticamente GatewayClasses. El controlador puede tardar unos minutos en reconocer los CRDs e instalar los GatewayClasses.

Confirma que la API Gateway está habilitada en el plano de control de GKE:

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

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

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

Confirma que las GatewayClasses estén instaladas en tu clúster:

kubectl get gatewayclass

El resultado debería ser similar al siguiente:

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 conocer las funciones de cada GatewayClass, consulta Funciones de GatewayClass.

Solo se instalan automáticamente las GatewayClasses de un solo clúster. Para instalar y usar las GatewayClasses de varios clústeres para el balanceo de carga de varios clústeres interno y externo, consulta Habilitar pasarelas de varios clústeres.

Desplegar una pasarela interna

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

Desplegar una pasarela interna regional

En el siguiente ejemplo se muestra cómo desplegar una pasarela interna regional que permita una comunicación eficiente y segura entre los servicios de una región geográfica específica.

Configurar una subred de solo proxy

Debes configurar una subred solo de proxy antes de crear una pasarela que use un balanceador de carga de aplicaciones interno. Cada región de una VPC en la que uses balanceadores de carga de aplicaciones internos debe tener una subred solo proxy. Esta subred proporciona direcciones IP internas a los proxies del balanceador de carga.

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
```
Haz los cambios siguientes:
- 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 VPC en la que creas esta subred de solo proxy. Asegúrate de que sea la misma red VPC en la que se encuentra tu clúster de GKE y en la que vas a implementar la puerta de enlace. Esto es importante para que la comunicación entre el balanceador de carga y los servicios de backend sea fluida.
- CIDR_RANGE: el intervalo de direcciones IP principal de la subred. Debes usar una máscara de subred que no supere /26 para que haya al menos 64 direcciones IP disponibles para los proxies de la región. La máscara de subred recomendada es /23.

Verifica tu subred de solo proxy:

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

El resultado debería ser similar al siguiente:

...
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

Crear una pasarela

Un recurso Gateway representa un plano de datos que enruta el tráfico en Kubernetes. Una puerta de enlace puede representar muchos tipos diferentes de balanceo de carga y de enrutamiento en función de la GatewayClass de la que derive. Para obtener más información sobre el recurso Gateway, consulta la descripción del recurso Gateway o la especificación de la API.

En este caso, el administrador del clúster de GKE quiere crear una pasarela que puedan usar diferentes equipos para exponer sus aplicaciones internamente. El administrador implementa la pasarela y los equipos de aplicaciones implementan sus rutas de forma independiente y las adjuntan a esta pasarela.

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:
  # Specify an existing GatewayClass.
  gatewayClassName: gke-l7-rilb
  listeners:
  # Listen for HTTP traffic on port 80.
  - name: http
    protocol: HTTP
    port: 80
```
Este manifiesto incluye los siguientes campos:
- gatewayClassName: gke-l7-rilb: especifica la GatewayClass de la que deriva este Gateway. gke-l7-rilb corresponde al balanceador de carga de aplicación interno.
- port: 80: especifica que la puerta de enlace solo expone el puerto 80 para escuchar el tráfico HTTP.
Esta puerta de enlace está configurada para gestionar el tráfico HTTP solo en el puerto 80. No admite HTTPS (puerto 443) de forma predeterminada y, si intentas conectarte a través de HTTPS, es posible que la solicitud falle.
Despliega la pasarela en tu clúster:
```
kubectl apply -f gateway.yaml
```

Valida que la pasarela se haya implementado correctamente. Puede que tarde unos minutos en desplegar todos sus recursos.

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

El resultado debería ser similar al siguiente:

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:  2025-03-19T19:53:46Z
     Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
     Observed Generation:   1
     Reason:                Scheduled
     Status:                True
     Type:                  Scheduled
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Accepted
     Status:                True
     Type:                  Accepted
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Programmed
     Status:                True # Indicates that the Gateway is ready.
     Type:                  Programmed
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:               The OSS Gateway API has altered the "Ready" condition semantics and reserved it for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
     Observed Generation:   1
     Reason:                Ready
     Status:                True
     Type:                  Ready
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Healthy
     Status:                True
     Type:                  networking.gke.io/GatewayHealthy
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 resultado, el estado de True de la condición Programmed indica que la pasarela está lista.

En este punto, hay una Gateway implementada en tu clúster que ha aprovisionado un balanceador de carga y una dirección IP. Sin embargo, la pasarela no tiene rutas, por lo que no sabe cómo debe enviar el tráfico a los back-ends. Sin rutas, todo el tráfico se dirige a un backend predeterminado, que devuelve un error HTTP 404. A continuación, implementa una aplicación y las rutas, que indican a la puerta de enlace cómo acceder a los back-ends de la aplicación.

Desplegar las aplicaciones de demostración

Los equipos de aplicaciones pueden implementar sus aplicaciones y rutas independientemente de la implementación de las pasarelas. En algunos casos, el equipo de la aplicación también puede querer ser propietario de la pasarela y desplegarla por su cuenta como recurso dedicado a sus aplicaciones. Consulta Route binding para ver los diferentes modelos de propiedad de las pasarelas y las rutas. Sin embargo, en este ejemplo, el equipo de la tienda implementa su aplicación y una HTTPRoute complementaria para exponer su aplicación a través de la internal-http Gateway creada en la sección anterior.

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

Despliega la aplicación de tienda (despliegues store-v1, store-v2 y store-german) en tu clúster:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
```
De esta forma, se crean tres implementaciones y tres servicios llamados store-v1, store-v2 y store-german.

Valida que la aplicación se haya desplegado correctamente:

kubectl get pod

La salida es similar a la siguiente después de que se ejecute 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

Valida que los servicios se hayan implementado:

kubectl get service

El resultado muestra un servicio 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

Desplegar el HTTPRoute

Los recursos de ruta definen reglas específicas de protocolo para asignar el tráfico de un elemento Gateway a los back-ends de Kubernetes. El recurso HTTPRoute se encarga de la coincidencia y el filtrado del tráfico HTTP y HTTPS, y es compatible con todas las gke-l7GatewayClasses.

En esta sección, implementará un HTTPRoute, que programa la Gateway con las reglas de enrutamiento necesarias para acceder a su aplicación de tienda.

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:
  # Attach the HTTPRoute to a Gateway.
  parentRefs:
  - kind: Gateway
    name: internal-http
  # Route requests that have `store.example.com` in the Host header.
  hostnames:
  - "store.example.com"
  rules:
  # Send requests with the `env: canary` header to the `store-v2` Service.
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  # Send requests with `/de` in the path to the `store-german` Service.
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080
  # Send unmatched requests to the store-v1 Service.
  - backendRefs:
    - name: store-v1
      port: 8080

Despliega la ruta HTTP en tu clúster:
```
kubectl apply -f store-route.yaml
```
El store HTTPRoute se vincula a la pasarela internal-http mediante la propiedad parentRefs. Estas reglas de enrutamiento se configuran en el balanceador de carga subyacente, tal 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 se dirige al servicio store-german.
- El tráfico a store.example.com con la cabecera HTTP "env: canary" va al servicio store-v2.
- El tráfico restante a store.example.com se dirige al servicio store-v1.

Verifica que se haya implementado el HTTPRoute:

kubectl describe httproute store

El resultado debería ser similar al siguiente:

Name:         store
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         HTTPRoute
# Multiple lines are omitted here.
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",
  # Multiple lines are omitted here.

Verifica que HTTPRoute esté enlazado a la puerta de enlace:

kubectl describe gateway

El resultado debería ser similar al siguiente:

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
      <...>

Enviar tráfico a tu aplicación

Ahora que tu Gateway, Route y aplicación se han desplegado en tu clúster, puedes enviar tráfico a tu aplicación. La pasarela está configurada para servir tráfico HTTP solo en el puerto 80. Las solicitudes realizadas con HTTPS pueden fallar a menos que se haya configurado TLS por separado.

Recupera la dirección IP de la pasarela para poder 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.
Envía tráfico a esta dirección IP desde la shell de una instancia de máquina virtual que tenga conectividad con el clúster. Puedes crear una VM para ello. Esto es necesario porque la pasarela tiene una dirección IP interna y solo se puede acceder a ella desde tu red de VPC. Como internal-http es un balanceador de carga regional, el shell del cliente debe estar en la misma región que el clúster de GKE.

Realiza una solicitud a store.example.com:
```
curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
```
Sustituye GATEWAY_IP_ADDRESS por la dirección IP del paso anterior.

El resultado de la aplicación de demostración muestra información sobre la ubicación en la que se está ejecutando la aplicación:
```
{
  "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"
}
```

Prueba la coincidencia de ruta. Para ello, ve a la versión alemana del servicio de tienda en store.example.com/de:

curl http://store.example.com/de --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

El resultado confirma que la solicitud se ha publicado en un store-german pod:

{
  "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"
}

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

curl -H "env: canary" http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

El resultado confirma que la solicitud se ha publicado en un store-v2 pod:

{
  "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"
}

Desplegar una pasarela externa

Una pasarela externa expone aplicaciones a las que se puede acceder desde Internet o desde redes que no pertenecen a tu red de VPC. La implementación es similar a una implementación de pasarela interna, pero debes proteger tus aplicaciones porque la pasarela es accesible a través de Internet público.

Tienes dos opciones para crear una pasarela externa: una pasarela externa global o una pasarela externa regional.

Pasarela externa global: esta pasarela usa una dirección IP global (o una dirección IP Anycast) como frontend de la pasarela. Esta dirección IP se anuncia en todas las regiones de Compute. Trusted Cloud by S3NS Los clientes que envían tráfico a esta dirección IP Anycast se dirigen a la ubicación de Google más cercana en la que se anuncia la dirección IP. La puerta de enlace externa global solo está disponible en el nivel Premium de los niveles de servicio de red.
Pasarela externa regional: esta pasarela usa una dirección IP regional como frontend de la pasarela. El comportamiento de esta pasarela depende del nivel de servicio de red que selecciones:
- Si eliges el nivel de servicio de red estándar (opción predeterminada), la dirección IP regional solo se anuncia en la región de Compute local en la que se implementa la puerta de enlace externa regional. Trusted Cloud by S3NS Los clientes que envían tráfico a esta dirección IP se enrutan a través de su proveedor de Internet local y de la red pública de Internet antes de llegar a la región de Google en la que se anuncia la dirección IP.
- Si elige el nivel de servicio de red Premium, la dirección IP regional se anuncia en toda la red global de Google. Esto significa que el tráfico de los clientes entra en la red troncal mundial de alta calidad de Google por un punto de emparejamiento perimetral de Google lo más cerca posible del cliente, aunque el destino sea una dirección IP regional. Esta ubicación reduce significativamente la latencia y mejora el rendimiento minimizando la distancia que recorre el tráfico a través de Internet público.

Desplegar una pasarela externa global

En el siguiente ejemplo se muestra cómo exponer una aplicación de tienda con varios certificados adjuntos a la pasarela externa global y agrupados en un mapa de certificados mediante Certificate Manager y un HTTPRoute.

Crear un mapa de certificados

Google recomienda usar Certificate Manager para gestionar los certificados cuando necesites 15 o más por cada pasarela o cuando tengas que usar certificados comodín.

También puedes proteger tu pasarela externa con secretos de Kubernetes o certificados SSL gestionados por Google. Para obtener más información, consulta Seguridad de la pasarela.

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

Habilita la API Certificate Manager:

gcloud services enable certificatemanager.googleapis.com

Crea un mapeado de certificados:

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

Carga tu certificado y tus claves gestionados por Google en un objeto Certificate:
```
gcloud beta certificate-manager certificates create store-example-com-cert \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE"
```
Haz los cambios siguientes:
- CERTIFICATE_FILE: el nombre del archivo de tu certificado. El archivo debe tener la extensión .pem. Por ejemplo, cert.pem.
- PRIVATE_KEY_FILE: el nombre del archivo de tu clave privada.
Para obtener más información, consulta el artículo Crear una clave privada y un certificado.

Crea un 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

Para saber cómo proteger una pasarela con otras fuentes de certificados, como secretos de Kubernetes o certificados SSL, consulta Proteger una pasarela.

Crear una pasarela

Un recurso Gateway representa un plano de datos que enruta el tráfico en Kubernetes. Un Gateway puede representar muchos tipos diferentes de balanceo de carga y de enrutamiento en función de la GatewayClass que utilice.

Para obtener más información sobre el recurso Gateway, consulta la descripción del recurso Gateway o la especificación de la API.

En esta sección, creará una pasarela. Los equipos de aplicaciones pueden usar la pasarela para exponer sus aplicaciones a Internet desplegando rutas de forma independiente y adjuntándolas de forma segura a la pasarela.

Guarda el siguiente manifiesto en 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:
  # This GatewayClass uses a global external Application Load Balancer.
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
```
Este manifiesto describe un Gateway con los siguientes campos:
- gatewayClassName: gke-l7-global-external-managed: especifica la GatewayClass de esta Gateway. Esta clase de pasarela usa un balanceador de carga de aplicación externo global.
- protocol: HTTPS y port: 443: especifica 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 Certificate Manager.
No hay ninguna sección TLS porque TLS se configura con Gestor de certificados mediante la anotación networking.gke.io/certmap.
Aplica el manifiesto a tu clúster:
```
kubectl apply -f gateway.yaml
```
GKE puede tardar unos minutos en desplegar los recursos.
Verifica que la pasarela se haya implementado correctamente:
```
kubectl describe gateway
```
El resultado debería ser similar al siguiente:
```
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 carga y una dirección IP pública. La pasarela 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 devuelve una respuesta HTTP 404. En la siguiente sección, desplegarás rutas que indicarán a la pasarela que envíe tráfico a los back-ends.

Desplegar las aplicaciones de demostración

Los equipos de aplicaciones pueden implementar sus aplicaciones y rutas independientemente de la implementación de las pasarelas. En algunos casos, el equipo de la aplicación también puede querer tener el control de la pasarela y desplegarla por su cuenta como un recurso dedicado a sus aplicaciones. Consulta Vinculación de rutas para ver los diferentes modelos de propiedad de las pasarelas y las rutas. En este ejemplo, el equipo de la tienda implementa su aplicación y un HTTPRoute asociado para exponer su aplicación a través de la external-http Gateway creada en la sección anterior.

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

Despliega la aplicación de ejemplo en tu 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 ejemplo crea tres implementaciones y tres servicios llamados store-v1, store-v2 y store-german.

Comprueba que la aplicación se haya implementado correctamente:

kubectl get pod

El resultado debería ser similar al siguiente:

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

Comprueba que los servicios se hayan implementado correctamente:

kubectl get service

El resultado debería ser similar al siguiente:

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

Crear un HTTPRoute

Los recursos de ruta definen reglas específicas de protocolo para asignar el tráfico de un elemento Gateway a los back-ends de Kubernetes. El recurso HTTPRoute hace coincidir y filtra el tráfico HTTP y HTTPS, y es compatible con todas las gke-l7-* GatewayClasses.

En esta sección, implementará un HTTPRoute, que configura la Gateway con las reglas de enrutamiento necesarias para acceder a la aplicación de ejemplo.

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-external
spec:
  parentRefs:
  # Bind the route to the 'external-http' Gateway.
  - kind: Gateway
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  # Default rule for store.example.com that sends traffic to the store-v1 service.
  - backendRefs:
    - name: store-v1
      port: 8080
  # Match requests with the "env: canary" header and send them to the store-v2 service.
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  # Match requests with the path "/de" and sends them to the store-german service.
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080

Este manifiesto describe un HTTPRoute que hace referencia a la external-http Gateway.

Aplica el manifiesto a tu clúster:
```
kubectl apply -f store-route-external.yaml
```
El store HTTPRoute se vincula a la pasarela external-http mediante la propiedad parentRefs. En el siguiente diagrama se muestran las reglas de enrutamiento configuradas en el balanceador de carga subyacente:

Las reglas de enrutamiento procesan el tráfico HTTP de la siguiente manera:
- El tráfico a store.example.com/de se dirige al servicio store-german.
- El tráfico a store.example.com con la cabecera HTTP "env: canary" se dirige al servicio store-v2.
- El resto del tráfico a store.example.com se dirige al servicio store-v1.

Verifica que se haya implementado el HTTPRoute:

kubectl describe httproute store-external

El resultado debería ser similar al siguiente:

Name:         store-external
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         HTTPRoute
# Multiple lines are omitted here.
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:
    # This section shows the status of this route in relation to each Gateway attached.
    Conditions:
      Last Transition Time:  2022-11-01T05:42:31Z
      Message:
      Reason:                Accepted
      Status:                True # Means that the Gateway has validated and accepted this route's configuration.
      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",
  ...

Verifica que HTTPRoute esté enlazado a la puerta de enlace:

kubectl describe gateway external-http

El resultado debería ser similar al siguiente:

Name:         external-http
Namespace:    default
Labels:       <none>
# Multiple lines are omitted here.
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
      # Multiple lines are omitted here.

Enviar tráfico a tu aplicación

Ahora que tu Gateway, Route y aplicación se han desplegado en tu clúster, puedes enviar tráfico a tu aplicación.

Obtén la dirección IP de la pasarela:

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

El resultado es una dirección IP.

Crea una VM:
```
gcloud cloud-shell ssh
```
Envía tráfico a la dirección IP de la pasarela desde la VM. Debes definir el encabezado Host manualmente porque no eres el propietario del nombre de host example.com.
```
curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
```
Sustituye GATEWAY_IP_ADDRESS por la dirección IP de la puerta de enlace del paso anterior.

cacert.pem: el archivo de certificado que has generado. Debes guardar este archivo en el ordenador que utilices para conectarte a la pasarela.

El resultado muestra información de la aplicación de demostración sobre la ubicación en la que se está ejecutando la aplicación:
```
{
  "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"
}
```

Prueba la concordancia de ruta accediendo a la versión alemana del servicio store en store.example.com/de:

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

El resultado confirma que la solicitud se ha publicado en un store-german pod:

{
  "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"
}

Envía tráfico a la versión canary del servicio store mediante la cabecera HTTP env: canary:

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

El resultado confirma que la solicitud se ha publicado en un store-v2 pod:

{
  "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"
}

Desplegar una pasarela externa regional

En el siguiente ejemplo se muestra cómo exponer una aplicación de tienda con varios certificados adjuntos a la pasarela externa regional mediante certificados autogestionados y un objeto HTTPRoute.

Crear una subred de proxy para tu pasarela regional

Debes configurar una subred solo proxy antes de crear una pasarela que use un balanceador de carga de aplicación externo regional. Cada región de una VPC en la que uses un balanceador de carga de aplicación externo regional debe tener una subred external_managed_proxy. Esta subred proporciona direcciones IP internas a los proxies del balanceador de carga.

Crear un certificado para proteger el tráfico de clientes

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

Para proteger el tráfico entre tus clientes y tu pasarela regional, puedes usar los siguientes métodos:

Certificados gestionados por Google o autogestionados de Certificate Manager
Certificados SSL regionales autogestionados
Secretos de Kubernetes

No se admiten certificados SSL gestionados por Google ni CertificateMap con las puertas de enlace regionales.

Para obtener más información, consulta Certificados y balanceadores de carga Trusted Cloud by S3NS .

Crear una pasarela HTTP(S) externa regional

Crea una dirección IP estática regional para el balanceador de carga externo.
```
gcloud compute addresses create IP_ADDRESS_NAME \
  --region=COMPUTE_REGION \
  --network-tier=STANDARD
```
Haz los cambios siguientes:
- IP_ADDRESS_NAME: el nombre de la nueva dirección IP estática.
- COMPUTE_REGION: la región de Compute Engine en la que se ejecuta tu clúster.

Crea un gateway de balanceador de carga de aplicación externo regional con un certificado autogestionado 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:
    # Name of an existing GatewayClass.
    gatewayClassName: gke-l7-regional-external-managed
    # Listen for HTTPS traffic on port 443
    listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        # Terminate the TLS session with the client at the Gateway.
        mode: Terminate
        # Certificates for the Gateway to use to create a new TLS session.
        certificateRefs:
        - name: store-example-com
    # The name of the static IP address of the external load balancer.
    # You can also use the `IPAddress` type to specify the actual IP address.
    addresses:
    - type: NamedAddress
      value: IP_ADDRESS_NAME

Aplica el manifiesto regional-gateway:

  kubectl apply -f regional-gateway.yaml

Verifica tu configuración.

  kubectl get gateway

El resultado debería ser similar al siguiente:

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 de descripción:

kubectl describe gateway

El resultado debería ser similar al siguiente:

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
  ...

Desplegar la aplicación de demostración

Puedes implementar tus aplicaciones y rutas de forma independiente a la implementación de las pasarelas.

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

Crear un HTTPRoute

Debes crear un HTTPRoute para hacer coincidir y filtrar el tráfico HTTP y HTTPS.

Enviar tráfico a tu aplicación

Una vez que haya implementado su aplicación y creado HTTPRoutes, podrá enviar tráfico a su aplicación.

Para obtener más información sobre cómo enviar tráfico a su aplicación, consulte el artículo Enviar tráfico a su aplicación.

Usar pasarelas compartidas

La API Gateway usa recursos independientes (Gateways y Route) para desplegar balanceadores de carga y reglas de enrutamiento. Esto es diferente de Ingress, que combina todo en un solo recurso. Al dividir la responsabilidad entre los recursos, Gateway permite que el balanceador de carga y sus reglas de enrutamiento se implementen por separado y que lo hagan diferentes usuarios o equipos. Esto permite que las pasarelas se conviertan en pasarelas compartidas que se adjuntan a muchas rutas diferentes que pueden ser propiedad y estar gestionadas por equipos independientes, incluso en distintos espacios de nombres.

Desplegar rutas en una pasarela compartida

Este ejemplo se basa en la pasarela internal-http implementada en Implementar una pasarela interna.

En este ejemplo, el equipo del sitio implementa su aplicación, los servicios y una HTTPRoute para que coincida el tráfico de la Gateway con esos servicios.

Despliega la aplicación de ejemplo:

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

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: site-internal
spec:
  # Attach the HTTPRoute to the `internal-http` Gateway.
  parentRefs:
  - kind: Gateway
    name: internal-http
  # Route requests that have `site.example.com` in the Host header.
  hostnames:
  - "site.example.com"
  # Send all requests to the `site-v1` Service.
  rules:
  - backendRefs:
    - name: site-v1
      port: 8080

Este manifiesto describe una HTTPRoute que coincide con todo el tráfico de site.example.com y lo dirige al servicio site-v1.

Aplica el manifiesto a tu clúster:

kubectl apply -f site-route-internal.yaml

Verifica que el HTTPRoute esté asociado a la Gateway:

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

El resultado debería ser similar al siguiente:

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 de la pasarela es True, significa que la ruta HTTP se ha vinculado correctamente a la pasarela. Para obtener más información sobre el campo Estado, consulta Estado de la ruta.

Comprueba que el tráfico a la pasarela se enruta correctamente:

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

Sustituye GATEWAY_IP_ADDRESS por la dirección IP de la pasarela interna.

Debes usar una máquina virtual en la misma VPC que la pasarela.

El resultado debería ser similar al siguiente:

{
  "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"
}

Este resultado indica que las solicitudes con el encabezado site.example.comHost llegan al servicio site-v1, mientras que las solicitudes con el encabezado store.example.comHost llegan al servicio store-v1.

Configurar el nivel de red

Puedes especificar el nivel de red de la dirección de un listener de un balanceador de carga de aplicaciones externo regional mediante el campo type de la matriz addresses[] en la definición de Gateway. Si no especificas un nivel de red, la pasarela usará de forma predeterminada una dirección IP efímera de nivel Estándar.

Utilice los siguientes valores en el campo type:

networking.gke.io/premium-ephemeral-ipv4-address: asigna una dirección IP de nivel Premium.
networking.gke.io/standard-ephemeral-ipv4-address: asigna una dirección IP de nivel estándar.

Para asignar direcciones IP de ambos niveles de red, especifica los dos tipos en el campo addresses.

En el siguiente ejemplo se muestra cómo asignar una dirección IP de nivel Premium a una pasarela. Trusted Cloud by S3NS Para aprovisionar una dirección IP de nivel Estándar, usa networking.gke.io/standard-ephemeral-ipv4-address.

Guarda el siguiente archivo de manifiesto de ejemplo como external-regional-http.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-regional-http
spec:
  # Name of an existing GatewayClass.
  gatewayClassName: gke-l7-regional-external-managed
  # Listen for HTTPS traffic on port 443.
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      # Terminate the TLS session with the client at the Gateway.
      mode: Terminate
      # Certificates for the Gateway to use to create a new TLS session.
      certificateRefs:
      - name: store-example-com
    addresses:
    # Request a Premium Tier ephemeral IPv4 address for the Gateway.
    - type: networking.gke.io/premium-ephemeral-ipv4-address

Aplica el archivo de manifiesto de ejemplo:

kubectl apply -f external-regional-http.yaml

Configurar el backend predeterminado de Gateway

Todas las gke-l7-* GatewayClasses devuelven el error HTTP 404 al tráfico no coincidente. Puedes configurar el backend predeterminado mediante una ruta predeterminada explícita que envíe el tráfico no coincidente a un servicio proporcionado por el usuario.

Las pasarelas están configuradas para gestionar 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. Si quieres tener más control sobre la gestión de errores, puedes configurar back-ends personalizados.

El siguiente HTTPRoute es un ejemplo de cómo personalizar el backend predeterminado. Si aplicas un HTTPRoute similar al siguiente, tendrá 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
  # Omit the `hostnames` field to route all unmatched traffic from the
  # attached Gateway.
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Este HTTPRoute coincide con todo el tráfico de una Gateway concreta. Solo puedes tener una regla de este tipo por cada pasarela. De lo contrario, las reglas entrarán en conflicto y se aplicará el orden de precedencia.

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

Configurar una dirección IP estática para una pasarela

Cada pasarela tiene una dirección IP que usa para detectar el tráfico. Si no especificas una dirección IP en la pasarela, el controlador de la pasarela asignará una automáticamente. También puedes crear una dirección IP estática para que la dirección IP exista independientemente del ciclo de vida de la pasarela.

Una vez que se ha implementado una pasarela, su dirección IP se muestra en el campo de estado:

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

En función de 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 intervalo de direcciones IPv4 o IPv6 del nodo principal
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Direcciones IP públicas regionales de los intervalos IPv4 e 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 intervalos IPv4/IPv6 externos globales de Google

El campo addresses.NamedAddress te permite especificar una dirección IP independientemente de la pasarela. Puedes crear un recurso de dirección IP estática antes de implementar la pasarela. El recurso se hace referencia mediante NamedAddress. Puedes volver a usar la dirección IP estática aunque se elimine la pasarela.

Usar una dirección IP con nombre

Puedes configurar una dirección IPv4 o IPv6 especificando un NamedAddress. Debes aprovisionar una dirección IP estática antes de crear una pasarela.

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
```
Haz los cambios siguientes:
- IP_ADDRESS_NAME: nombre de la nueva dirección IP estática
- COMPUTE_REGION: en el caso de las pasarelas regionales, la región de Compute Engine en la que se ejecuta el clúster. Esta marca no es necesaria para las pasarelas globales externas.
- SUBNET: la subred de la dirección IP. Esta marca no es necesaria para las pasarelas globales externas.
- PROJECT_ID: el proyecto en el que se ejecuta tu clúster de GKE.

Guarda el siguiente manifiesto en 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

Este manifiesto describe una pasarela que hace referencia a la dirección IP con nombre.

Aplica el manifiesto a tu clúster:
```
kubectl apply -f named-ip-gateway.yaml
```

Verifica la dirección IP de tu pasarela:

kubectl describe gateway internal-http

El resultado debería ser similar al siguiente:

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 redirecciones de HTTP a HTTPS

Cloud Load Balancing ofrece la función de redirección de HTTP a HTTPS. Un balanceador de carga de aplicaciones externo redirige las solicitudes HTTP sin cifrar a un balanceador de carga HTTPS que usa la misma dirección IP. Cuando creas una pasarela con redirecciones de HTTP a HTTPS habilitadas, ambos balanceadores de carga se crean automáticamente. Las solicitudes a la dirección IP externa de la pasarela en el puerto 80 se redirigen automáticamente a la misma dirección IP externa en el puerto 443.

De forma predeterminada, las redirecciones de HTTP a HTTPS no se definen en la pasarela.

Para redirigir el tráfico HTTP a HTTPS, configura una puerta de enlace para gestionar el tráfico HTTP y HTTPS. Si inhabilitas HTTP o HTTPS, la pasarela no redirigirá el tráfico.

En el siguiente ejemplo se muestra cómo puede usar la redirección de HTTP a HTTPS para asegurarse de que el tráfico de sus clientes a sus aplicaciones web siempre se redirija a una página segura.

Las redirecciones de HTTP a HTTPS no se admiten con las clases Gateway gke-l7-gxlb y gke-l7-gxlb-mc. Para obtener más información sobre las diferentes funciones compatibles con cada GatewayClass, consulta Funciones de GatewayClass.

Redirigir 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 la plataforma y los equipos de aplicaciones, por lo que puede resultar difícil evitar el uso inadecuado de la pasarela.

En el siguiente ejemplo se restringe aún más el uso del listener HTTP para evitar que los equipos de aplicaciones usen sin querer el protocolo no seguro. En este ejemplo, se configura la pasarela para que permita que una HTTPRoute use el listener HTTP solo si la ruta está en un espacio de nombres que tenga la etiqueta otherInfra: httpToHttps. Sin embargo, Gateway permite que las HTTPRoutes de cualquier espacio de nombres usen el listener HTTPS. Puedes restringir el espacio de nombres http-redirect mediante el control de acceso basado en roles (RBAC) de Kubernetes para que los equipos de aplicaciones no puedan crear una ruta HTTP en este espacio de nombres por error.

Crea el espacio de nombres de una pasarela. Guarda el archivo de manifiesto como gateway-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-infra
```

Aplica el archivo de manifiesto:

kubectl apply -f gateway-namespace.yaml

Crea el espacio de nombres de una pasarela y guarda el manifiesto como redirect-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: http-redirect
  labels:
    otherInfra: httpToHttps
```
Este espacio de nombres http-redirect tiene la etiqueta otherInfra: httpToHttps.

Aplica el archivo de manifiesto:

kubectl apply -f redirect-namespace.yaml

Para restringir el uso del listener http, crea un Gateway con el siguiente manifiesto. Guarda el archivo de manifiesto como external-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  namespace: gateway-infra
spec:
  # Name of an existing GatewayClass.
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    #  Allow only HTTPRoutes from namespaces that have the
    # `otherInfra: httpToHttps` label to use this listener.
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: Selector
        selector:
          matchLabels:
            otherInfra: httpToHttps
  - name: https
    protocol: HTTPS
    port: 443
    # Allow HTTPRoutes from any namespace to use this listener.
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: All
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: store-example-com

El campo namespace especifica que la pasarela se crea en el espacio de nombres gateway-infra.
El campo namespaces de la sección allowedRoutes restringe el listener HTTP al espacio de nombres que coincida con la etiqueta otherInfra: httpToHttps.

Aplica el archivo de manifiesto:
```
kubectl apply -f external-gateway.yaml
```

Para forzar la redirección HTTPS, crea un HTTPRoute predeterminado con el siguiente manifiesto. Guarda el archivo de manifiesto como http-redirect.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: redirect
  # Create the HTTPRoute in the `http-redirect` namespace.
  namespace: http-redirect
spec:
  # Attach the HTTPRoute to the `http` listener in the `external-http`
  # Gateway.
  parentRefs:
  - namespace: gateway-infra
    name: external-http
    sectionName: http
  rules:
  # Respond to the request with an HTTPS redirection.
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https

El campo sectionName indica a la pasarela que solo debe buscar coincidencias en el http listener. El filtro RequestRedirect fuerza la redirección al listener https.

Aplica el archivo de manifiesto:
```
kubectl apply -f http-redirect.yaml
```

Crea un servicio 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
        ports:
        - containerPort: 8080
        env:
        - name: METADATA
          value: "store-v1"

Aplica el archivo de manifiesto:

kubectl apply -f service-deployment.yaml

Crea un HTTPRoute para una aplicación que solo permita HTTPS mediante el siguiente manifiesto. Guarda el archivo de manifiesto como http-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  # Attach the HTTPRoute to the HTTPS listener in the `external-http`
  # Gateway.
  parentRefs:
  - name: external-http
    namespace: gateway-infra
    sectionName: https
  # Match requests that have the `store.example.com` Host header.
  hostnames:
  - "store.example.com"
  # Route requests to the `store-v1` Service.
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

Aplica el archivo de manifiesto:
```
kubectl apply -f http-route.yaml
```

Configurar redirecciones de ruta y reescrituras de URL

Las redirecciones de ruta consisten en redirigir una solicitud entrante de una ruta de URL a otra. Las redirecciones de ruta te permiten cambiar la estructura de la URL cuando necesitas gestionar URLs obsoletas o retiradas.

Las reescrituras de URLs ayudan a modificar la URL entrante antes de procesarla en el servidor. Te permite cambiar la estructura o el formato de la URL sin modificar el contenido o la estructura del archivo subyacentes. La reescritura de URLs es útil para crear URLs intuitivas y optimizadas para SEO que sean fáciles de recordar y entender. De forma predeterminada, las redirecciones de ruta y las reescrituras de URL no están configuradas, por lo que debes configurarlas explícitamente mediante un filtro en tu HTTPRoute.

GKE Gateway admite redirecciones de ruta y reescrituras de URLs. Para obtener más información, consulta Redirecciones y reescrituras de rutas HTTP.

Configurar redirecciones de ruta

Puedes configurar redirecciones de ruta para sustituir toda la ruta o solo un prefijo de la URL.

Sustituir toda la ruta

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

Crea un archivo de manifiesto HTTPRoute de la siguiente manera y llámalo 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:
          # Match requests by a prefix, like `/any-path` and `/any-path/home`.
          type: PathPrefix
          value: /any-path
      filters:
      - type: RequestRedirect
        requestRedirect:
          path:
            # Replace the full path with `/new-path`. For example, both
            # `/any-path/home` and `/any-path` become `/new-path`.
            type: ReplaceFullPath
            replaceFullPath: /new-path
          statusCode: 302

Por ejemplo, este manifiesto define una regla de enrutamiento para un HTTPRoute de la siguiente manera: Cualquier ruta a la URL https://store.example.com/any-path/... debe redirigirse a una nueva ubicación, https://store.example.com/new-path/ (estricta).

Aplica el archivo de manifiesto:
```
kubectl apply -f store.yaml
```

Esta regla de enrutamiento sigue una regla de redirección estricta, lo que significa que el navegador no intenta almacenar en caché la redirección, sino que redirige a la versión más reciente.

Sustituir solo un prefijo

Para sustituir solo un prefijo, configure un filtro en una HTTPRoute que sustituya cualquier URL que contenga el prefijo /any-prefix en la ruta de la URL por el valor estricto /new-prefix.

Crea un archivo de manifiesto HTTPRoute de la siguiente manera y llámalo 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:
          # Match requests by prefix, like `/any-prefix` and
          # `/any-prefix/home`.
          type: PathPrefix
          value: /any-prefix
    filters:
    - type: RequestRedirect
      requestRedirect:
        path:
          # Replace the matched prefix with `/new-prefix`. For example,
          # `/any-prefix` becomes `/new-prefix` and `/any-prefix/home`
          # becomes `/new-prefix/home`.
          type: ReplacePrefixMatch
          replacePrefixMatch: /new-prefix
        statusCode: 302

Por ejemplo, este manifiesto define una regla de enrutamiento para un HTTPRoute de la siguiente manera: Cualquier ruta a la URL https://store.example.com/any-path/v1/... debe redirigirse a una nueva ubicación, https://store.example.com/new-path/v1/... (solo).

Aplica el archivo de manifiesto:
```
  kubectl apply -f store.yaml
```

Esta regla de enrutamiento sigue la única regla de redirección, que asegura que el navegador siempre te redirija a la misma página de destino.

Configurar reescrituras de URLs

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

Reescribir todo el nombre de host

Para reescribir todo el nombre de host, sigue estos pasos:

Configura un filtro en un HTTPRoute que indique a la puerta de enlace que sustituya 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.

Crea un archivo de manifiesto HTTPRoute de la siguiente manera y llámalo 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
        # Replace the hostname in the URL with `store.example.com`.
        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.

Aplica el archivo de manifiesto:
```
  kubectl apply -f www.yaml
```

Reescribir con modificadores de ruta

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

Para reescribir con modificadores de ruta:

Configura un filtro en un HTTPRoute que indique a la puerta de enlace que sustituya la información de "Host" de la cabecera de la solicitud de www.example.comto store.example.com y que sustituya el valor /store por / antes de reenviar la solicitud al servicio de backend.

Crea un archivo de manifiesto HTTPRoute de la siguiente manera y llámalo 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
        # For URLs that have `/store` in the path, replace the hostname with
        # store.example.com and replace the `/store` prefix with `/de`.
        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.

Aplica el archivo de manifiesto:
```
kubectl apply -f www.yaml
```

Verificar tu configuración

Para verificar que el filtro se ha aplicado después de crear tu HTTPRoute con filtros de reescritura de URL o de redirecciones de ruta, haz lo siguiente:

kubectl get httproute www -o yaml

El resultado debería ser similar al siguiente:

  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 el comando describe:

kubectl describe httproute

Configurar encabezados de solicitud y respuesta personalizados

Los encabezados de solicitud y respuesta personalizados te permiten especificar encabezados adicionales para las solicitudes y respuestas HTTP(S). En función de la información detectada por el balanceador de carga, estos encabezados pueden incluir la siguiente información:

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

De forma predeterminada, no se añade ningún encabezado personalizado a la solicitud enviada o recibida a tus servicios de backend. Debes configurar explícitamente los encabezados personalizados mediante un filtro en tu HTTPRoute.

Puedes configurar encabezados personalizados añadiendo una sección de filtro a las reglas de tu HTTPRoute de la siguiente manera:

Configurar encabezados de solicitud personalizados

Crea un manifiesto de 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 archivo de manifiesto:

  kubectl apply -f http-route-request.yaml

Configurar encabezados de respuesta personalizados

Crea un manifiesto de 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 archivo de manifiesto:

  kubectl apply -f http-route-response.yaml

Puedes añadir, definir y quitar encabezados tal como se describe en la implementación de la API Gateway. Puedes configurar tu HTTPRoute con un encabezado personalizado mediante Trusted Cloud variables admitidas.

Ejemplo 1:

Para configurar un HTTPRoute que añada información de la ubicación del cliente a la solicitud HTTP antes de enviarla al servicio de backend, crea un manifiesto de 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:
          # Add custom headers to requests that have `/fr` in the path.
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

Por ejemplo, en el caso de los clientes ubicados en Estrasburgo (Francia), la pasarela añade un encabezado como X-Client-Geo-Location:FR,Strasbourg.

Ejemplo 2:

Para configurar un HTTPRoute que añada una cabecera de respuesta personalizada para admitir la seguridad de transporte estricta mediante HTTP, crea un manifiesto de 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:
          # Add custom headers to responses to requests that have `/de` in the
          # path.
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Verificar tu configuración

Para verificar la configuración después de configurar encabezados de solicitud y respuesta personalizados, siga estos pasos:
```
  kubectl get httproute
```
El resultado debería ser similar al siguiente:
```
  NAME    HOSTNAMES               AGE
  store   ["store.example.com"]   4d23h
```

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

  kubectl describe httproute

El resultado debería ser similar al siguiente:

  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 saber si un HTTPRoute se ha vinculado correctamente con una o varias Gateways o si se ha rechazado.

Condiciones de HTTPRoute

Las condiciones de HTTPRoute indican el estado de la ruta y las pasarelas a las que está vinculada. Como una ruta se puede vincular a varias pasarelas, se trata de una lista de pasarelas y de las condiciones individuales entre la ruta y cada pasarela.

Accepted=True indica que el objeto HTTPRoute se ha vinculado correctamente a un objeto Gateway.
Accepted=False indica que se ha rechazado la vinculación de HTTPRoute con esta Gateway.

Si no aparece ninguna pasarela en el encabezado Gateway bindings, es posible que las etiquetas HTTPRoute y los selectores de etiquetas de pasarela no coincidan. Esto puede ocurrir si ninguna pasarela selecciona tu ruta.

Eventos HTTPRoute

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

Los eventos ADD se activan cuando se añade un recurso.
Los eventos UPDATE se activan cuando se actualiza un recurso.
Los eventos SYNC se activan mediante una conciliación periódica.

Fusión, precedencia y validación de rutas

Prioridad de las rutas

Gateway API define reglas de precedencia estrictas para determinar cómo se asigna el tráfico a las rutas que tienen reglas de enrutamiento superpuestas. La precedencia entre dos HTTPRoutes superpuestas es la siguiente:

Combinación de nombres de host: la coincidencia de nombre de host más larga o específica.
Fusión de rutas: la ruta más larga o específica que coincida.
Combinación de encabezados: el mayor número de encabezados HTTP que coinciden.
Conflicto: si las tres reglas anteriores no establecen ninguna precedencia, se le asigna al recurso HTTPRoute con la marca de tiempo más antigua.

Fusión de rutas

En el caso de gke-l7 GatewayClasses, todas las HTTPRoutes de una Gateway determinada se combinan en el mismo recurso de mapa de URLs. La forma en que se combinan los HTTPRoutes depende del tipo de superposición entre ellos. El HTTPRoute del ejemplo anterior se puede dividir en tres HTTPRoutes independientes para ilustrar la combinación y la precedencia de las rutas:

Fusión de rutas: las tres HTTPRoutes se adjuntan a la misma internal-http Gateway, por lo que se fusionan.
Combinación de nombres de host: las tres rutas coinciden con store.example.com, por lo que sus reglas de nombre de host se combinan.
Combinación de rutas: store-german-route tiene una ruta más específica /de, 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.
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.
Conflicto: como las rutas se pueden combinar por nombre de host, ruta y encabezados, no hay conflictos y todas las reglas de enrutamiento se aplican al tráfico.

La única HTTPRoute que se ha usado en el ejemplo anterior equivale a estas tres rutas independientes:

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

Gateways de Kubernetes y Gateways de Istio

Tenga en cuenta que tanto la API de Kubernetes Gateway como la API de Istio tienen un recurso llamado Gateway. Aunque realizan funciones similares, no son el mismo recurso. Si usas Istio y la API Gateway en el mismo clúster de Kubernetes, estos nombres se solapan al usar kubectl en la línea de comandos. kubectl get gateway puede devolver los recursos de Kubernetes Gateway y no los recursos de Istio Gateway, 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 o una versión posterior, te recomendamos que empieces a usar el nombre abreviado del recurso Gateway o que especifiques el grupo de APIs. El nombre abreviado de una pasarela de Kubernetes es gtw y el de una pasarela de Istio es gw. Los siguientes comandos devuelven los recursos de Kubernetes Gateway e Istio Gateway, 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

Solución de problemas

Falta la subred de solo proxy en la región

Síntoma:

Puede producirse el siguiente problema al crear una pasarela 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 hay ninguna subred de solo proxy en la región de tu gateway.

Solución alternativa:

Para solucionar este problema, configure una subred de solo proxy.

Ya existe una subred de solo proxy en la región con un propósito incorrecto

Síntoma:

Puede producirse el siguiente problema al crear una subred de solo proxy para tu pasarela 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 has intentado crear una subred de solo proxy regional en una región que ya tiene una subred de solo proxy.

Solución alternativa:

Para solucionar este problema, sigue estos pasos:

Comprueba que ya exista una subred solo proxy en la región y verifica que tenga el propósito correcto:
1. Enumera tus subredes para encontrar cuál es la subred de solo proxy de la región:
```
gcloud compute networks subnets list --regions=COMPUTE_REGION
```
  Sustituye COMPUTE_REGION por la región de Compute Engine en la que quieras crear tu pasarela regional.
2. Describe tu subred de solo proxy en la región para saber cuál es su finalidad:
```
gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
    --region COMPUTE_REGION | grep -E 'name|purpose'
```
  Sustituye PROXY_ONLY_SUBNET por la subred de solo proxy.
GKE Gateway solo admite subredes REGIONAL_MANAGED_PROXY solo proxy para las pasarelas regionales (internas o regionales).
Si la subred de solo proxy de la región se creó con el propósito INTERNAL_HTTPS_LOAD_BALANCER, migra su propósito a REGIONAL_MANAGED_PROXY.

No hay upstream en buen estado

Síntoma:

El siguiente problema puede producirse cuando crea una pasarela, pero no puede acceder a los servicios de backend (código de respuesta 503):

no healthy upstream

Motivo:

Este mensaje de error indica que el comprobador de estado no puede encontrar servicios de backend en buen estado. Es posible que tus servicios de backend estén en buen estado, pero que tengas que personalizar las comprobaciones del estado.

Solución alternativa:

Para solucionar este problema, personaliza la comprobación de estado según los requisitos de tu aplicación (por ejemplo, /health) mediante un HealthCheckPolicy.

Siguientes pasos

Más información sobre el controlador de la pasarela
Consulta cómo configurar recursos de Gateway con políticas.
Consulta otras configuraciones de Gateway en la documentación de la API Gateway.