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.
Para obtener configuraciones de Gateway más específicas, como el enrutamiento entre espacios de nombres y la división del tráfico HTTP, consulta las guías del usuario de la API de Gateway.
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 el comando
gcloud components updatepara obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
- Asegúrate de tener un clúster de Autopilot o Standard existente. Para crear un clúster nuevo, consulta Crea un clúster de Autopilot.
Requisitos del controlador de la puerta de enlace de GKE
- La API de Gateway 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
HttpLoadBalancinghabilitado. - 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 Usera la cuenta de servicio de GKE para el proyecto de servicio.
Restricciones y limitaciones
Cuando uses GKE Gateway, ten en cuenta las siguientes limitaciones y restricciones:
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.
Práctica recomendada: Para obtener un rendimiento óptimo, limita la cantidad de Gateways a un máximo de 100. Superar este límite puede afectar el rendimiento o aumentar la latencia.
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 en la consola de Google Cloud , pero estos recursos no hacen referencia a la puerta de enlace o al clúster de 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-gxlbno es compatible.Cuando se configuran encabezados de respuesta y solicitud personalizados HTTPRoute, no se admiten las siguientes variables deGoogle 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 de aplicaciones clásicoGoogle Cloud se aplican a GKE Gateway. Además, 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/negpara 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
Gatewaypara aprovisionar una dirección IP, no se admite cambiar laGateway.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 valorgatewayClassactualizado.No se admite la anotación
networking.gke.io/app-protocols. En su lugar, usa el campoappProtocolpara lograr el mismo resultado.Si usas GKE Gateway con
external-dnsy el estado de la puerta de enlace es incorrecto, de forma predeterminada, todos los registros DNS asociados con la puerta de enlace se borran de tus zonas DNS.Práctica recomendada: Cuando ejecutes
external-dns, establece la marcapolicy=upsert-only. Esta configuración ayuda a evitar el borrado de los registros DNS existentes.Si se quita un puerto de un
Serviceal 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 quitar ese puerto. De lo contrario, el controlador de NEG dejará de sincronizar los extremos de Pod para este servicio. Para obtener más información, consulta El controlador de NEG deja de administrar extremos cuando se quita el puerto del servicio.Las implementaciones que usan Gateways de varios clústeres (MCG) que utilizan clústeres zonales son susceptibles a interrupciones del servicio durante las actualizaciones de clústeres. Este problema se produce porque un mecanismo heredado de detección de grupos de extremos de red (NEG) puede informar de forma incorrecta que no hay backends cuando el plano de control del clúster zonal no está disponible temporalmente. Se está trabajando en una solución a largo plazo. Para evitar este punto único de falla, usa clústeres de GKE regionales con MCG.
Habilita la API de Gateway en tu clúster
Antes de usar recursos de puerta de enlace en GKE, tu clúster debe tener habilitada la API de Gateway.
Antes de actualizar un clúster de GKE 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 habilitar la API de Gateway en un clúster de GKE existente (Autopilot o Standard), usa el siguiente comando. Esta operación puede tardar hasta 45 minutos en completarse mientras el clúster reconcilia e instala las CRD.
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.
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.
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 jsonEl 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" }, ... },Confirma que las GatewayClasses estén instaladas en el clúster:
kubectl get gatewayclassEl 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.
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 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.
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_RANGEReemplaza lo siguiente:
SUBNET_NAME: El nombre de la subred de solo proxyCOMPUTE_REGION: La región de la subred de solo proxyVPC_NETWORK_NAME: Es el nombre de la red de VPC en la que creas esta subred de solo proxy. Asegúrate de que sea la misma red de VPC en la que reside tu clúster de GKE y en la que implementas la puerta de enlace. Esto es importante para una comunicación fluida entre el balanceador de cargas y tus servicios de backend.CIDR_RANGE: El rango de direcciones IP principal de la subred Debes usar una máscara de subred de una longitud máxima de/26para que al menos 64 direcciones IP estén 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_REGIONEl 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. Para 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.
Guarda el siguiente manifiesto de Gateway en un archivo llamado
gateway.yaml:kind: Gateway apiVersion: gateway.networking.k8s.io/v1 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: 80Este manifiesto incluye los siguientes campos:
gatewayClassName: gke-l7-rilb: especifica la GatewayClass de la que deriva esta puerta de enlace.gke-l7-rilbcorresponde 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.
Este Gateway está configurado para controlar 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.
Implementa la puerta de enlace en tu clúster:
kubectl apply -f gateway.yamlVerifica 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-httpEl 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: 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 successEn este resultado, el estado de
Truepara la condiciónProgrammedindica que la puerta de enlace está lista.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.
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.yamlEsto crea tres implementaciones y tres servicios, llamados store-v1, store-v2 y store-german
Confirma que la aplicación se haya implementado correctamente:
kubectl get podEl 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 14mValida que se hayan implementado los objetos Service:
kubectl get serviceEl 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.
Guarda el siguiente manifiesto de HTTPRoute en un archivo llamado
store-route.yaml:kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 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: 8080Implementa la HTTProute en tu clúster:
kubectl apply -f store-route.yamlLa HTTPRoute
storeestá vinculada a la puerta de enlaceinternal-httpmediante la propiedadparentRefs. 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/deva al objeto Servicestore-german. - El tráfico a
store.example.comcon el encabezado HTTP"env: canary"va al objeto Servicestore-v2. - El tráfico restante a
store.example.comva al objeto Servicestore-v1.
- El tráfico a
Verifica que se haya implementado la HTTPRoute:
kubectl describe httproute storeEl resultado es similar a este:
Name: store Namespace: default Labels: <none> Annotations: <none> API Version: gateway.networking.k8s.io/v1 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 la HTTPRoute esté vinculada a la puerta de enlace:
kubectl describe gatewayEl 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. La puerta de enlace está configurada para entregar tráfico HTTP solo en el puerto 80. Las solicitudes realizadas con HTTPS podrían fallar, a menos que se haya configurado TLS por separado.
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.
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-httpes un balanceador de cargas regional, la shell del cliente debe estar dentro de 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 -vReemplaza
GATEWAY_IP_ADDRESSpor 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" }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 http://store.example.com/de --resolve store.example.com:80:GATEWAY_IP_ADDRESS -vEl resultado confirma que un pod
store-germanentregó 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" }Por último, usa el encabezado HTTP
env: canarypara enviar tráfico a la versión canary del servicio de almacenamiento:curl -H "env: canary" http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -vEl resultado confirma que un pod
store-v2entregó 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 tu red de 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.
- Puerta de enlace externa global: Esta puerta de enlace usa una dirección IP global (o dirección IP Anycast) como el frontend de la puerta de enlace. Esta dirección IP se anuncia en todas las regiones de Google Cloud Compute. Los clientes que envían tráfico a esta dirección IP de Anycast se enrutan 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 de servicio de red Premium.
- Puerta de enlace externa regional: Esta puerta de enlace usa una dirección IP regional como frontend. El comportamiento de esta puerta de enlace depende del Nivel de servicio de red que selecciones:
- Si eliges el nivel de servicio de red Estándar (predeterminado), la dirección IP regional se anuncia solo en la región de Compute Google Cloud local en la que se implementa la puerta de enlace externa regional. Los clientes que envían tráfico a esta dirección IP se enrutan a través de su ISP local y a través de Internet público antes de llegar a la región de Google en la que se anuncia la dirección IP.
- Si eliges el nivel Premium de servicio de red, la dirección IP regional se anuncia en toda la red global de Google. Esto significa que el tráfico del cliente ingresa a la red troncal global de alta calidad de Google en un punto de intercambio de tráfico perimetral de Google lo más cercano posible al cliente, incluso si el destino es una dirección IP regional. Esta ubicación reduce significativamente la latencia y mejora el rendimiento, ya que minimiza la distancia que recorre el tráfico a través de la Internet pública.
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.
Habilita la API de administrador de certificados:
gcloud services enable certificatemanager.googleapis.comCrea un mapa de certificados:
gcloud beta certificate-manager maps create store-example-com-mapCarga 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 de tu archivo de certificado. 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.
Crea una
CertificateMapEntryque 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.
Guarda el siguiente manifiesto como un archivo llamado
gateway.yaml:kind: Gateway apiVersion: gateway.networking.k8s.io/v1 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: 443En 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: HTTPSyport: 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.Aplica el manifiesto al clúster:
kubectl apply -f gateway.yamlGKE puede tardar unos minutos en implementar los recursos.
Verifica que la puerta de enlace se haya implementado de forma correcta:
kubectl describe gatewayEl 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.
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.yamlEsta aplicación de muestra crea tres objetos Deployment y tres objetos Service llamados
store-v1,store-v2ystore-german.Verifica que la aplicación se haya implementado correctamente:
kubectl get podEl 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 14mVerifica que los objetos Service se hayan implementado de forma correcta:
kubectl get serviceEl 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.
Guarda el siguiente manifiesto como un archivo llamado
store-route-external.yaml:kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 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: 8080En este manifiesto, se describe una HTTPRouter que hace referencia a la puerta de enlace
external-http.Aplica el manifiesto al clúster:
kubectl apply -f store-route-external.yamlLa HTTPRoute
storeestá vinculada a la puerta de enlaceexternal-httpmediante la propiedadparentRefs. 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/dese enruta al objeto Servicestore-german. - El tráfico a
store.example.comcon el encabezado HTTP"env: canary"se enruta al objeto Servicestore-v2. - El tráfico restante a
store.example.comse enruta al objeto Servicestore-v1.
- El tráfico a
Verifica que se haya implementado la HTTPRoute:
kubectl describe httproute store-externalEl resultado es similar a este:
Name: store-external Namespace: default Labels: <none> Annotations: <none> API Version: gateway.networking.k8s.io/v1 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 la HTTPRoute esté vinculada a la puerta de enlace:
kubectl describe gateway external-httpEl resultado es similar a este:
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.
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.
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.
Crea una VM:
gcloud cloud-shell sshEnví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 https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -vReemplaza
GATEWAY_IP_ADDRESSpor la dirección IP de la puerta de enlace del paso anterior.cacert.pem: Es el archivo de certificado que generaste. Debes guardar este archivo en la máquina que usas para conectarte a la puerta de enlace.
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" }Para probar la coincidencia de ruta de acceso, ve a la versión en alemán del objeto Service
storeenstore.example.com/de:curl https://store.example.com/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -vEl resultado confirma que un pod
store-germanentregó 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" }Envía tráfico a la versión canary del objeto Service
storecon el encabezado HTTPenv: canary:curl -H "env: canary" https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -vEl resultado confirma que un pod
store-v2entregó 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.
Para proteger el tráfico entre tus clientes y la puerta de enlace regional, puedes usar los siguientes métodos:
- Certificados del Administrador de certificados autoadministrados o administrados por Google
- Certificados SSL regionales autoadministrados
- Secretos de Kubernetes
CertificateMap o los certificados SSL administrados por Google no son compatibles con las puertas de enlace regionales.
Para obtener más información, consulta Certificados y Google Cloud balanceadores de cargas.
Crea una puerta de enlace HTTP(S) regional externa
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=STANDARDReemplaza lo siguiente:
IP_ADDRESS_NAME: el nombre de la dirección IP estática nuevaCOMPUTE_REGION: La región de Compute Engine en la que se ejecuta tu clúster
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/v1 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_NAMEAplica el manifiesto
regional-gateway:kubectl apply -f regional-gateway.yamlVerifica la configuración.
kubectl get gatewayEl resultado es similar a este:
NAME CLASS ADDRESS READY AGE external-http gke-l7-regional-external-managed 35.118.32.224 True 49sPara obtener más detalles, usa un comando describe:
kubectl describe gatewayEl 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
La API de Gateway usa 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.
Implementa la aplicación de ejemplo
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yamlGuarda el siguiente manifiesto como un archivo llamado
site-route-internal.yaml:kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 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: 8080En este manifiesto, se describe una HTTPRouter que coincide con todo el tráfico para
site.example.comy lo enruta al Servicesite-v1.Aplica el manifiesto al clúster:
kubectl apply -f site-route-internal.yamlVerifica que la HTTPRoute esté vinculada a la puerta de enlace:
kubectl describe httproute.gateway.networking.k8s.io site-internalEl 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
Acceptedpara la puerta de enlace esTrue, 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.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_ADDRESSReemplaza
GATEWAY_IP_ADDRESSpor la dirección IP de la puerta de enlace interna.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" }Este resultado indica que las solicitudes con el encabezado Host
site.example.comllegan al serviciosite-v1, mientras que las solicitudes con el encabezado Hoststore.example.comllegan al serviciostore-v1.
Configura el nivel de red
Puedes especificar el nivel de red para la dirección de escucha de un balanceador de cargas de aplicaciones externo regional con el campo type dentro del array addresses[] en la definición de Gateway. Si no especificas un nivel de red, la puerta de enlace usará de forma predeterminada una dirección IP efímera del nivel Estándar.
Usa los siguientes valores para el campo type:
networking.gke.io/premium-ephemeral-ipv4-address: Asigna una dirección IP del 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 ambos tipos en el campo addresses.
En el siguiente ejemplo, se muestra cómo Google Cloud asignar una dirección IP de nivel Premium a una puerta de enlace. Para aprovisionar una dirección IP del nivel Estándar, usa networking.gke.io/standard-ephemeral-ipv4-address.
Guarda el siguiente manifiesto de muestra como
external-regional-http.yaml:kind: Gateway apiVersion: gateway.networking.k8s.io/v1 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-addressAplica el manifiesto de muestra:
kubectl apply -f external-regional-http.yaml
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.
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/v1
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
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 |
|---|---|
|
|
Direcciones IP privadas regionales del rango de direcciones IPv4/IPv6 del nodo principal |
|
|
Direcciones IP públicas regionales de los rangos de IPv4/IPv6 externos regionales de Google |
|
|
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 IPv4 o IPv6, especifica un NamedAddress. Debes aprovisionar una dirección IP estática antes de crear una puerta de enlace.
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_IDReemplaza lo siguiente:
IP_ADDRESS_NAME: el nombre de la dirección IP estática nuevaCOMPUTE_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.
Guarda el siguiente manifiesto como un archivo llamado
named-ip-gateway.yaml:kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: internal-http spec: gatewayClassName: gke-l7-rilb listeners: - name: http protocol: HTTP port: 80 addresses: - type: NamedAddress value: IP_ADDRESS_NAMEEn este manifiesto, se describe una puerta de enlace que hace referencia a la dirección IP con nombre.
Aplica el manifiesto al clúster:
kubectl apply -f named-ip-gateway.yamlVerifica la dirección IP de la puerta de enlace:
kubectl describe gateway internal-httpEl 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.
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 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 que tiene la etiqueta otherInfra: httpToHttps. Sin embargo, la puerta de enlace permite que las HTTPRoutes de cualquier espacio de nombres usen el objeto de escucha HTTPS. Puedes restringir el espacio de nombres de redireccionamiento de HTTP con el RBAC de Kubernetes para que los equipos de aplicaciones no puedan crear una HTTPRoute en este espacio de nombres por error.
Crea el espacio de nombres de una puerta de enlace. Guarda el manifiesto como
gateway-namespace.yaml:apiVersion: v1 kind: Namespace metadata: name: gateway-infraAplica el manifiesto
kubectl apply -f gateway-namespace.yamlCrea 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: httpToHttpsEste espacio de nombres
http-redirecttiene la etiquetaotherInfra: httpToHttps.Aplica el manifiesto
kubectl apply -f redirect-namespace.yamlPara 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/v1 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-comEn el campo
namespace, se especifica que la puerta de enlace se crea en el espacio de nombresgateway-infra.El campo
namespacesen la secciónallowedRoutesrestringe el objeto de escucha http al espacio de nombres que coincide con la etiquetaotherInfra: httpToHttps.
Aplica el manifiesto
kubectl apply -f external-gateway.yamlPara 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/v1 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
sectionNameindica a la puerta de enlace que coincida solo con el objeto de escucha HTTP. El filtroRequestRedirectfuerza el redireccionamiento al objeto de escucha https.
- El campo
Aplica el manifiesto
kubectl apply -f http-redirect.yamlCrea 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 ports: - containerPort: 8080 env: - name: METADATA value: "store-v1"Aplica el manifiesto
kubectl apply -f service-deployment.yamlCrea 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/v1 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: 8080Aplica 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
Para reemplazar una ruta de acceso completa, configura un filtro en una HTTPRoute que reemplace cualquier URL que contenga el prefijo
/any-pathen la ruta de URL por el valor estricto/new-path.Crea un manifiesto
HTTPRoutede la siguiente manera y asígnale el nombrestore.yaml:apiVersion: gateway.networking.k8s.io/v1 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: 302Por 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).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
Para reemplazar solo un prefijo, configura un filtro en una HTTPRoute que reemplace cualquier URL que contenga el prefijo
/any-prefixen la ruta de URL por el valor estricto/new-prefix.Crea un manifiesto
HTTPRoutede la siguiente manera y asígnale el nombrestore.yaml:apiVersion: gateway.networking.k8s.io/v1 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: 302Por 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/...(solo).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:
Configura un filtro en una HTTPRoute que le indique a la puerta de enlace que reemplace la información de
Hosten el encabezado de la solicitud dewww.example.comastore.example.comantes de reenviar la solicitud al servicio de backend.Crea un manifiesto
HTTPRoutede la siguiente manera y asígnale el nombrewww.yaml:apiVersion: gateway.networking.k8s.io/v1 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: 8080Por ejemplo, con la configuración anterior, cualquier solicitud a
https://www.example.comse reenvía al servicio de backend con el encabezadoHost: store.example.com, en lugar deHost: www.example.com.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:
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
to store.example.comy reemplace el valor/storepor/antes de reenviar la solicitud al servicio de backend.Crea un manifiesto
HTTPRoutede la siguiente manera y asígnale el nombrewww.yaml:apiVersion: gateway.networking.k8s.io/v1 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: 8080Por ejemplo, con la configuración anterior, cualquier solicitud a
https://www.example.com/store/...se reenvía al servicio de backend conHost: store.example.comen el encabezado de la solicitud (en lugar deHost: www.example.com) y/storese reescribe como/de.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/v1
kind: HTTPRoute
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"gateway.networking.k8s.io/v1","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/v1
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/v1
kind: HTTPRoute
metadata:
name: store
spec:
<...>
rules:
filters:
- type: ResponseHeaderModifier
responseHeaderModifier:
<...>
Aplica el manifiesto
kubectl apply -f http-route-response.yaml
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 usando las variables compatibles conGoogle 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/v1
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, 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/v1
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
Verifica la configuración
Para verificar la configuración después de configurar encabezados de solicitud y respuesta personalizados, haz lo siguiente:
kubectl get httprouteEl resultado es similar a este:
NAME HOSTNAMES AGE store ["store.example.com"] 4d23hPara obtener más detalles, usa el comando describe:
kubectl describe httprouteEl resultado es similar a este:
Name: store Namespace: default Labels: <none> Annotations: <none> API Version: gateway.networking.k8s.io/v1 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=Trueindica que la HTTPRoute está vinculada correctamente a una puerta de enlace.Accepted=Falseindica 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
ADDse activan mediante un recurso que se agrega. - Los eventos
UPDATEse activan mediante un recurso que se actualiza. - Los eventos
SYNCse 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:
- Combinación de nombres de host: La coincidencia de nombres de host más larga o más específica.
- Combinación de rutas de acceso: La coincidencia de rutas de acceso más larga o más específica.
- Combinación de encabezados: La mayor cantidad de encabezados HTTP que coinciden.
- 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:
- Combinación de rutas: Las tres HTTPRoutes se conectan con la misma Gateway
internal-http, por lo que se combinan. - 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. - Combinación de rutas: tore-german-route tiene una ruta de acceso
/demá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. - 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: 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/v1
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/v1
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/v1
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:
Comprueba que ya exista una subred de solo proxy en la región y verifica que tenga el propósito correcto:
Enumera tus subredes para descubrir cuál es la subred de solo proxy en la región:
gcloud compute networks subnets list --regions=COMPUTE_REGIONReemplaza
COMPUTE_REGIONpor la región de Compute Engine en la que quieres crear la puerta de enlace regional.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_SUBNETpor la subred de solo proxy.
La puerta de enlace de GKE solo admite subredes de solo proxy
REGIONAL_MANAGED_PROXYpara puertas de enlace regionales (internas o regionales).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 aREGIONAL_MANAGED_PROXY.
Sin upstream en buen estado
Síntoma:
El siguiente problema puede ocurrir cuando creas una puerta de enlace, pero no puedes acceder a los servicios de backend (código de respuesta 503):
no healthy upstream
Motivo:
Este mensaje de error indica que el sistema de sondeo de verificación de estado no puede encontrar servicios de backend en buen estado. Es posible que tus servicios de backend estén en buen estado, pero es posible que debas personalizar las verificaciones de estado.
Solución alternativa:
Para resolver este problema, personaliza la verificación de estado según los requisitos de tu aplicación (por ejemplo, /health) mediante un HealthCheckPolicy.
¿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.
- Obtén información sobre otras configuraciones de Gateway en la documentación de la API de Gateway.