En esta página se describe la implementación de la API Gateway de Kubernetes en Google Kubernetes Engine (GKE) mediante el controlador Gateway de GKE.
Esta página está dirigida a arquitectos de nube y especialistas en redes que diseñan y definen la arquitectura de la red de su organización. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud
Gateway API es un estándar de código abierto para la creación de redes de servicios. Gateway API desarrolla el recurso Ingress y lo mejora de las siguientes formas:
Orientada a los roles: la API Gateway se compone de recursos de API que corresponden a los roles organizativos de operador de clúster, desarrollador y proveedor de infraestructura. De esta forma, los operadores de clústeres pueden definir cómo pueden usar la infraestructura compartida muchos equipos de desarrolladores diferentes que no se coordinan entre sí.
Portátil: Gateway API es un estándar de código abierto con muchas implementaciones, lo que permite que los conceptos y los recursos principales sean coherentes en todas las implementaciones y los entornos, lo que reduce la complejidad y aumenta la familiaridad de los usuarios. Su diseño se basa en el concepto de conformidad flexible, que usa una API principal muy portátil (como Ingress) que sigue teniendo la flexibilidad y la extensibilidad necesarias para admitir las funciones nativas del entorno y la implementación.
Expresiva: los recursos de la API Gateway ofrecen funciones integradas para la coincidencia basada en encabezados, la ponderación del tráfico y otras funciones que solo son posibles en Ingress mediante anotaciones personalizadas.
Recursos de la API Gateway
La API Gateway es un modelo de recursos orientado a roles diseñado para arquitectos de la nube y especialistas en redes que interactúan con las redes de Kubernetes. Como se muestra en el siguiente diagrama, este modelo permite que diferentes propietarios de servicios que no se coordinan compartan la misma infraestructura de red subyacente de forma segura, lo que centraliza la política y el control para el administrador de la plataforma.
La API Gateway contiene los siguientes tipos de recursos:
- GatewayClass: define un recurso con ámbito de clúster que es una plantilla para crear balanceadores de carga en un clúster. GKE proporciona GatewayClasses que se pueden usar en clústeres de GKE.
- Pasarela: define dónde y cómo escuchan los balanceadores de carga el tráfico. Los operadores de clústeres crean pasarelas en sus clústeres en función de una GatewayClass. GKE crea balanceadores de carga que implementan la configuración definida en el recurso Gateway.
- HTTPRoute define reglas específicas del protocolo para dirigir solicitudes de una pasarela a servicios de Kubernetes. GKE admite HTTPRoutes para el enrutamiento de tráfico basado en HTTP(S). Los desarrolladores de aplicaciones crean HTTPRoutes para exponer sus aplicaciones HTTP mediante Gateways.
- Política: define un conjunto de características específicas de la implementación de un recurso Gateway. Puedes adjuntar una política a un Gateway, una Route o un servicio de Kubernetes.
- ReferenceGrant habilita las referencias entre espacios de nombres en la API Gateway. Para hacer referencia a un objeto fuera de su espacio de nombres, debes crear un recurso ReferenceGrant.
GatewayClass
GatewayClass es un recurso que define una plantilla para balanceadores de carga HTTP(S) (capa 7) en un clúster de Kubernetes. GKE proporciona GatewayClasses como recursos con ámbito de clúster. Los operadores de clústeres especifican un GatewayClass al crear pasarelas en sus clústeres.
Las diferentes GatewayClasses corresponden a diferentes Google Cloud balanceadores de carga. Cuando creas un Gateway basado en un GatewayClass, se crea un balanceador de carga correspondiente para implementar la configuración especificada.
Algunas GatewayClasses admiten el balanceo de carga entre varios clústeres.
En la siguiente tabla se enumeran las GatewayClasses disponibles en los clústeres de GKE y su tipo de balanceador de carga subyacente. Para obtener información detallada sobre los GatewayClasses, consulta las funciones y especificaciones de GatewayClass.
| Nombre de GatewayClass | Descripción |
|---|---|
gke-l7-global-external-managed |
Balanceadores de carga de aplicación externos globales creados en el balanceador de carga de aplicación externo global |
gke-l7-regional-external-managed |
Balanceadores de carga de aplicación externos regionales creados en el balanceador de carga de aplicación externo regional |
gke-l7-rilb |
Balanceadores de carga de aplicación internos creados en el balanceador de carga de aplicación interno |
gke-l7-gxlb |
Balanceadores de carga de aplicación externos globales creados en el balanceador de carga de aplicación clásico |
gke-l7-cross-regional-internal-managed-mc |
Balanceadores de carga de aplicación internos entre regiones multiclúster basados en el balanceador de carga de aplicación interno entre regiones |
gke-l7-global-external-managed-mc |
Balanceadores de carga de aplicación externos globales multiclúster creados en el balanceador de carga de aplicación externo global |
gke-l7-regional-external-managed-mc |
Balanceadores de carga de aplicación externos regionales multiclúster creados en el balanceador de carga de aplicación externo regional |
gke-l7-rilb-mc |
Balanceadores de carga de aplicación internos multiclústeres basados en el balanceador de carga de aplicación interno |
gke-l7-gxlb-mc |
Balanceadores de carga de aplicación externos globales multiclúster basados en el balanceador de carga de aplicación clásico |
gke-td |
Malla de servicios de Cloud Service Mesh multiclúster |
asm-l7-gxlb |
Balanceadores de carga de aplicación externos globales creados en Cloud Service Mesh |
Cada GatewayClass está sujeto a las limitaciones del balanceador de carga subyacente.
Pasarela
Los operadores de clústeres crean Gateways para definir dónde y cómo escuchan el tráfico los balanceadores de carga. Las pasarelas adoptan su comportamiento (es decir, cómo se implementan) de su GatewayClass asociado.
La especificación de Gateway incluye la GatewayClass de la Gateway, los puertos y protocolos en los que se va a escuchar, y las Routes que se pueden enlazar a la Gateway. Un Gateway selecciona rutas en función de los metadatos de la ruta, concretamente el tipo, el espacio de nombres y las etiquetas de los recursos de la ruta.
Para ver un ejemplo de cómo implementar una pasarela, consulta Implementar pasarelas.
Para ver un ejemplo de cómo desplegar una pasarela de varios clústeres, consulta Desplegar pasarelas de varios clústeres.
HTTPRoute
Un objeto HTTPRoute define cómo se dirigen a los servicios las solicitudes HTTP y HTTPS recibidas por una pasarela. Los desarrolladores de aplicaciones crean HTTPRoutes para exponer sus aplicaciones a través de Gateways.
Un objeto HTTPRoute define desde qué objetos Gateway puede enrutar el tráfico, a qué objetos Service puede enrutarlo y las reglas que definen qué tráfico coincide con el objeto HTTPRoute. El enlace de la puerta de enlace y la ruta es bidireccional, lo que significa que ambos recursos deben seleccionarse entre sí para que se enlacen. Los HTTPRoutes pueden coincidir con las solicitudes en función de los detalles del encabezado de la solicitud.
Política
Una política define las características de un recurso de Gateway, normalmente específicas de la implementación, que los operadores de clústeres pueden asociar a un Gateway, una ruta o un servicio de Kubernetes. Una política define cómo debe funcionar laGoogle Cloud infraestructura subyacente.
Una política suele asociarse a un espacio de nombres y puede hacer referencia a un recurso del mismo espacio de nombres. El acceso se concede mediante el control de acceso basado en roles. La naturaleza jerárquica de la API Gateway te permite asociar una política a un recurso superior (Gateway) de un espacio de nombres y hacer que todos los recursos inferiores de diferentes espacios de nombres reciban las características de esa política.
El controlador de GKE Gateway admite las siguientes políticas:
HealthCheckPolicy: define los parámetros y el comportamiento de la comprobación del estado que se usa para comprobar el estado de los pods del backend.GCPGatewayPolicy: define parámetros específicos del frontend delGoogle Cloud balanceador de carga. Esta política es similar a unaFrontendConfigde un recurso Ingress.GCPBackendPolicy: define cómo deben distribuir los servicios de backend del balanceador de carga el tráfico a los endpoints. Esta política es similar aBackendConfigpara un recurso Ingress.GCPBackendPolicy: define cómo distribuyen el tráfico a los backends los servicios de backend del balanceador de carga. La políticaGCPBackendPolicyadmite el modo de equilibrioCUSTOM_METRICS, que permite tomar decisiones de enrutamiento basadas en métricas de aplicaciones definidas por el usuario que se registran mediante los informes de carga de ORCA.GCPTrafficDistributionPolicy: define cómo se distribuye el tráfico entre los endpoints de un backend. Esta política es similar a la forma en que configurarías algoritmos de balanceo de carga de tráfico específicos para el servicio de backend al que hace referencia un recurso Ingress.
ReferenceGrant
ReferenceGrant permite que recursos como HTTPRoute o Gateway hagan referencia a servicios de backend o secretos ubicados en diferentes espacios de nombres mediante referencias entre espacios de nombres. ReferenceGrant actúa como proveedor de permisos, especificando qué recursos (from) pueden hacer referencia a otros recursos (to). Para habilitar las referencias entre espacios de nombres, necesitas un ReferenceGrant en el espacio de nombres del recurso al que se hace referencia.
En el siguiente ejemplo, la HTTPRoute del espacio de nombres frontend debe enrutar el tráfico a un servicio del espacio de nombres backend. Crea un ReferenceGrant en el espacio de nombres backend donde:
- El campo
frommuestra el espacio de nombres de origen y el tipo de recurso que pueden hacer referencias, es decir, HTTPRoute en el espacio de nombresfrontend. - El campo
toespecifica el tipo de recurso de destino al que se puede hacer referencia, es decir, los servicios del espacio de nombresbackend.
apiVersion: networking.gke.io/v1beta1
kind: ReferenceGrant
metadata:
name: allow-frontend-to-access-backend
namespace: backend
spec:
from:
- group: gateway.networking.k8s.io
kind: HTTPRoute
namespace: frontend
to:
- group: ""
kind: Service
Si aparece el mensaje de error "No valid reference grant found" (No se ha encontrado ninguna concesión de referencia válida) en el estado de tu pasarela, comprueba que los valores group, kind, namespace y name definidos en las secciones from y to sean válidos.
Patrones de propiedad y uso de la pasarela
Los recursos Gateway y Route ofrecen flexibilidad en cuanto a la propiedad y la implementación en una organización. Esto significa que un solo balanceador de carga puede implementarlo y gestionarlo un equipo de infraestructura, pero el enrutamiento de un dominio o una ruta concretos se puede delegar en otro equipo de otro espacio de nombres de Kubernetes. El controlador de GKE Gateway admite el uso multiinquilino de un balanceador de carga, compartido entre espacios de nombres, clústeres y regiones. Las pasarelas tampoco tienen que compartirse si se requiere una propiedad más distribuida. A continuación, se muestran algunos de los patrones de uso más habituales de las pasarelas en GKE.
Pasarela autogestionada
Un único propietario puede implementar una pasarela y una ruta solo para sus aplicaciones y usarlas de forma exclusiva. Las pasarelas y las rutas implementadas de esta forma son similares a Ingress. En el siguiente diagrama se muestran dos propietarios de servicios diferentes que implementan y gestionan sus propias pasarelas. Al igual que Ingress, cada Gateway corresponde a su propia dirección IP y balanceador de carga únicos. El propietario del servicio controla por completo el protocolo TLS, el enrutamiento y otras políticas.
Este patrón de uso es habitual en Ingress, pero es difícil de escalar en muchos equipos debido a la falta de recursos compartidos. El modelo de recursos de la API Gateway permite los siguientes patrones de uso, que ofrecen un espectro de opciones para el control y la propiedad distribuidos.
Pasarela gestionada por la plataforma por espacio de nombres
La separación entre los recursos Gateway y Route permite a los administradores de la plataforma controlar las pasarelas en nombre de los propietarios de los servicios. Los administradores de la plataforma pueden implementar una pasarela por espacio de nombres o equipo, lo que da a ese espacio de nombres acceso exclusivo para usar la pasarela. De este modo, el propietario del servicio tiene pleno control sobre las reglas de enrutamiento sin riesgo de que haya conflictos con otros equipos. De esta forma, el administrador de la plataforma puede controlar aspectos como la asignación de IP, la exposición de puertos, los protocolos, los dominios y TLS. Los administradores de la plataforma también pueden decidir qué tipos de pasarelas están disponibles para los equipos, como las pasarelas internas o externas. Este patrón de uso crea una separación clara de responsabilidades entre los diferentes roles.
El enrutamiento entre espacios de nombres permite que las rutas se adjunten a las pasarelas entre límites de espacios de nombres. Las pasarelas pueden restringir los espacios de nombres a los que se pueden adjuntar las rutas. Del mismo modo, las rutas especifican las pasarelas a las que se adjuntan, pero solo pueden adjuntarse a una pasarela que haya permitido el espacio de nombres de la ruta. Esta conexión bidireccional proporciona a cada lado controles flexibles que permiten esta diversidad de patrones de uso.
En el siguiente diagrama, el administrador de la plataforma ha implementado una pasarela para que cada espacio de nombres tenga acceso exclusivo. Por ejemplo, la store pasarela está configurada de forma que solo se le puedan asociar rutas del espacio de nombres store. Cada Gateway representa una dirección IP única con equilibrio de carga, por lo que permite a cada equipo implementar cualquier número de rutas en el Gateway para los dominios o las rutas que elija.
Pasarela compartida por clúster
Compartir pasarelas entre espacios de nombres ofrece a los administradores de la plataforma una forma de propiedad aún más centralizada. De esta forma, los distintos propietarios de servicios que se ejecutan en diferentes espacios de nombres pueden compartir la misma dirección IP, el mismo dominio DNS, los mismos certificados o las mismas rutas para enrutar los servicios de forma precisa. Las pasarelas permiten a los administradores de la plataforma controlar qué espacios de nombres pueden enrutar para un dominio específico. Es similar al ejemplo anterior, pero las pasarelas permiten adjuntar rutas desde varios espacios de nombres.
En el siguiente diagrama, el administrador de la plataforma ha implementado dos Gateways en el espacio de nombres infra. La pasarela external permite que las rutas de los espacios de nombres web y mobile se adjunten a la pasarela. Las rutas del espacio de nombres accounts
no pueden usar la puerta de enlace external porque el espacio de nombres accounts es solo para
servicios internos. La internal pasarela permite que los clientes internos se comuniquen de forma privada
dentro de la VPC mediante direcciones IP privadas.
El dominio m.example.com se delega en el espacio de nombres mobile, lo que permite a los propietarios de servicios móviles configurar las reglas de enrutamiento que necesiten en el dominio m.example.com. De esta forma, los propietarios de los servicios tienen más control para introducir nuevos endpoints de API y controlar el tráfico sin tener que solicitar un cambio a los administradores.
Pasarela compartida por flota
Con las pasarelas de varios clústeres, una pasarela se puede compartir entre espacios de nombres, clústeres y regiones. Las organizaciones grandes con aplicaciones distribuidas geográficamente pueden beneficiarse de las pasarelas de varios clústeres, ya que pueden controlar de forma granular el tráfico global y, al mismo tiempo, delegar la propiedad del enrutamiento. Al igual que en los ejemplos anteriores, un administrador de la plataforma gestiona la pasarela y delega el enrutamiento. La principal novedad de este caso práctico es que las rutas hacen referencia a servicios de varios clústeres, que se despliegan en varios clústeres. El tráfico se puede enrutar de forma explícita (el tráfico a store.example.com/us va a los pods de gke-us) o implícita (el tráfico a example.com/* se enruta al clúster más cercano al cliente). Esta flexibilidad permite a los propietarios de servicios definir la estrategia de enrutamiento óptima para su aplicación.
GKE Gateway Controller
El controlador de GKE Gateway es la implementación de Google de la API Gateway para el balanceo de carga en Cloud. Al igual que el controlador de entrada de GKE, el controlador de Gateway monitoriza una API de Kubernetes para detectar recursos de la API Gateway y reconcilia los recursos de Cloud Load Balancing para implementar el comportamiento de red especificado por los recursos de Gateway.
Hay dos versiones del controlador de GKE Gateway:
- Un solo clúster: gestiona las pasarelas de un solo clúster de un único clúster de GKE.
- Varios clústeres: gestiona pasarelas de varios clústeres para uno o varios clústeres de GKE.
Ambos controladores de Gateway son controladores alojados en Google que monitorizan la API de Kubernetes para clústeres de GKE. A diferencia del controlador Ingress de GKE, los controladores Gateway no están alojados en planos de control de GKE ni en el proyecto del usuario, lo que les permite ser más escalables y robustos. Ambos controladores de pasarela están disponibles para todos los usuarios.
Los propios controladores de la pasarela no son un plano de datos de red y no procesan ningún tráfico. Están fuera de banda del tráfico y gestionan varios planos de datos que procesan el tráfico. En el siguiente diagrama se muestra la arquitectura de los controladores de GKE Gateway de un solo clúster y de varios clústeres. El controlador subyacente que se usa depende de la GatewayClass de la Gateway implementada.
| Mando | Controlador de puerta de enlace de un solo clúster | Controlador de pasarela de varios clústeres |
|---|---|---|
| Gestionado por | Google Cloud | Google Cloud |
| Ámbito de clúster | Pasarelas de un solo clúster | Pasarelas de varios clústeres |
| Ubicación de despliegue | Desplegado regionalmente en la misma región que su clúster de GKE. | Desplegado en varias Google Cloud regiones de todo el mundo. |
| Cómo habilitar | Habilitada de forma predeterminada en GKE. | Se habilita mediante la API Multi Cluster Ingress y el registro en una flota. Consulta Habilitar pasarelas de varios clústeres. |
| GatewayClasses admitidas |
|
Puedes usar varios controladores de Gateway, incluidos los que no proporciona Google, en un clúster de GKE simultáneamente. Cada GatewayClass es compatible con un solo controlador Gateway, lo que permite usar el balanceo de carga de un solo clúster y de varios clústeres simultáneamente.
Extensiones de servicio
El controlador de GKE Gateway admite extensiones de servicio, que te permiten añadir lógica personalizada a Cloud Load Balancing.
El controlador de GKE Gateway admite dos tipos de extensiones:
- GCPTrafficExtension esta extensión proporciona una forma de añadir lógica personalizada a Cloud Load Balancing. El servicio de extensión puede modificar los encabezados y las cargas útiles de las solicitudes y las respuestas sin afectar a la elección de los servicios de backend ni a ninguna otra política de seguridad asociada al servicio de backend.
- GCPRoutingExtension esta extensión proporciona una forma de añadir lógica personalizada a Cloud Load Balancing para controlar a dónde se dirige el tráfico de una solicitud determinada.
Para obtener más información sobre cómo configurar los controladores de GKE Gateway, consulta Personalizar el tráfico de GKE Gateway con extensiones de servicio.
Ingress y Gateway
Ingress y Gateway son estándares de código abierto para enrutar el tráfico, pero tienen diferencias clave.
Comparación entre Ingress y Gateway
Gateway e Ingress son estándares de código abierto para enrutar el tráfico y se pueden usar simultáneamente sin que haya conflictos. Con el tiempo, te recomendamos que pases a usar los recursos Gateway y Route, ya que ofrecen más funciones. La comunidad de Kubernetes diseñó Gateway basándose en las lecciones aprendidas de los ecosistemas de Ingress y de malla de servicios. Gateway es una evolución de Ingress que cumple la misma función, pero se ofrece como un superconjunto de las funciones de Ingress.
En GKE, todos los recursos Ingress se pueden convertir directamente en recursos Gateway y HTTPRoute. Un solo Ingress corresponde tanto a una Gateway (para la configuración del frontend) como a una HTTPRoute (para la configuración del enrutamiento). En el siguiente ejemplo se muestra cómo sería la configuración correspondiente de Gateway y HTTPRoute. Ten en cuenta que los recursos Gateway y HTTPRoute se pueden crear por separado, incluso por diferentes usuarios. Las pasarelas pueden tener muchas rutas y una ruta también puede asociarse a más de una pasarela. Las relaciones entre las pasarelas y las rutas se describen en Patrones de uso de pasarelas.
Entrada
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.class: "gce-internal"
spec:
rules:
- host: "example.com"
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: site
port:
number: 80
- pathType: Prefix
path: /shop
backend:
service:
name: store
port:
number: 80
Pasarela
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
spec:
gatewayClassName: gke-l7-rilb
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
kinds:
- kind: HTTPRoute
Ruta
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: my-route
spec:
parentRefs:
- name: my-gateway
hostnames:
- "example.com"
rules:
- matches:
- path:
value: /
backendRefs:
- name: site
port: 80
- matches:
- path:
value: /shop
backendRefs:
- name: store
port: 80
Integrar Gateway API con mallas de servicios
Puedes configurar una malla de servicios de Cloud con la API Gateway. Esto permite las comunicaciones entre servicios, la gestión del tráfico, el balanceo de carga global y la aplicación de políticas de seguridad en los casos prácticos de mallas de servicios. Para obtener información completa sobre cómo usar Cloud Service Mesh con la API Gateway, incluidas las guías de configuración de la implementación, consulta el artículo Configurar con la API Gateway: descripción general.
Precios
Todos los recursos de Compute Engine implementados a través de los controladores de Gateway se facturan en el proyecto en el que residen tus clústeres de GKE. El controlador de Gateway de un solo clúster se ofrece sin coste adicional como parte de los precios de GKE Standard y Autopilot. Los precios de las pasarelas de varios clústeres se describen en la página de precios de las pasarelas y las entradas de varios clústeres.
Siguientes pasos
- Consulta cómo configurar recursos de Gateway mediante políticas.
- Consulta información sobre la implementación de pasarelas.
- Consulta información sobre cómo desplegar pasarelas de varios clústeres.
- Para obtener información completa sobre cómo usar Cloud Service Mesh con la API Gateway, consulta la información general sobre la malla de servicios de GKE de Cloud Service Mesh.