En esta página, se describe la implementación de Google Kubernetes Engine (GKE) de la API de Gateway de Kubernetes mediante el controlador de la Gateway de GKE.
La API de puerta de enlace es un estándar de código abierto para redes de servicios. La API de Gateway evoluciona el recurso Ingress y lo mejora de las siguientes maneras:
Orientado a roles: Gateway se compone de recursos de API que corresponden a las funciones organizativas del operador de clúster, el desarrollador y el proveedor de infraestructura. Esto permite a los operadores de clúster definir cómo numerosos equipos de desarrolladores diferentes y que no coordinan pueden usar la infraestructura compartida.
Portátil: La API de Gateway es un estándar de código abierto con muchas implementaciones. Se diseñó con el concepto de conformidad flexible, que promueve una API central muy portátil (como Ingress) que aún tiene la flexibilidad y extensibilidad para admitir las capacidades nativas del entorno y la implementación. Esto permite que los conceptos y los recursos principales sean coherentes en todas las implementaciones y todos los entornos, lo que reduce la complejidad y aumenta la familiaridad del usuario.
Expresivo: Los recursos de la API de la puerta de enlace proporcionan una funcionalidad integrada para la coincidencia basada en encabezados, la ponderación del tráfico y otras capacidades que solo son posibles en Ingress a través de anotaciones personalizadas.
Recursos de la API de Gateway
La API de Gateway es un modelo de recursos orientado a las funciones, diseñado para quienes interactúan con las herramientas de redes de Kubernetes. Como se muestra en el siguiente diagrama, este modelo permite que diferentes propietarios de servicios no coordinados compartan la misma infraestructura de red subyacente de forma segura, de manera que se centralizan las políticas y el control para el administrador de la plataforma.
La API de Gateway contiene los siguientes tipos de recursos:
- GatewayClass: Define un recurso con alcance de clúster que es una plantilla para crear balanceadores de cargas en un clúster. GKE proporciona GatewayClasses que se pueden usar en clústeres de GKE.
- Gateway: Define dónde y cómo los balanceadores de cargas escuchan el tráfico. Los operadores de clústeres crean Gateways en sus clústeres en función de una GatewayClass. GKE crea balanceadores de cargas que implementan la configuración definida en el recurso de Gateway.
- HTTPRoute: Define reglas específicas del protocolo para enrutar solicitudes desde una Gateway hacia servicios de Kubernetes. GKE admite HTTPRouters para el enrutamiento de tráfico basado en HTTP(S). Los desarrolladores de aplicaciones crean HTTPRoutes para exponer sus aplicaciones HTTP mediante puertas de enlace.
- Política: Define un conjunto de características específicas de la implementación de un recurso Gateway. Puedes adjuntar una política a una puerta de enlace, una ruta o un Service de Kubernetes.
GatewayClass
Una GatewayClass es un recurso que define una plantilla para balanceadores de cargas HTTP(S) (nivel 7) en un clúster de Kubernetes. GKE proporciona GatewayClasses como recursos con alcance de clúster. Los operadores de clúster especifican una GatewayClass cuando crean puertas de enlace en sus clústeres.
Los diferentes GatewayClasses corresponden a diferentes balanceadores de cargas de Google Cloud. Cuando creas una Gateway basada en una GatewayClass, se crea el balanceador de cargas correspondiente para implementar la configuración especificada.
Algunas GatewayClasses admiten el balanceo de cargas de varios clústeres.
En la siguiente tabla, se enumeran las GatewayClasses disponibles en los clústeres de GKE y su tipo de balanceador de cargas subyacente. Para obtener detalles completos sobre las GatewayClasses, consulta las capacidades y especificaciones de GatewayClass.
| Nombre de GatewayClass | Descripción |
|---|---|
gke-l7-global-external-managed |
Balanceadores de cargas de aplicaciones externos globales compilados en el balanceador de cargas de aplicaciones externo global |
gke-l7-regional-external-managed |
Balanceadores de cargas de aplicaciones externos regionales compilados en el balanceador de cargas de aplicaciones externo regional |
gke-l7-rilb |
Balanceadores de cargas de aplicaciones internos compilados en el balanceador de cargas de aplicaciones interno |
gke-l7-gxlb |
Balanceadores de cargas de aplicaciones externos globales compilados en el balanceador de cargas de aplicaciones clásico |
gke-l7-global-external-managed-mc |
Balanceadores de cargas de aplicaciones externos globales de varios clústeres compilados en el balanceador de cargas de aplicaciones externo global |
gke-l7-regional-external-managed-mc |
Balanceadores de cargas de aplicaciones externos regionales de varios clústeres compilados en el balanceador de cargas de aplicaciones externo global |
gke-l7-rilb-mc |
Balanceadores de cargas internos de aplicaciones de varios clústeres compilados en el balanceador de cargas de aplicaciones interno |
gke-l7-gxlb-mc |
Balanceadores de cargas de aplicaciones externos globales de varios clústeres compilados en el balanceador de cargas de aplicaciones clásico |
gke-td |
Malla de servicios de Traffic Director de varios clústeres |
asm-l7-gxlb |
Balanceadores de cargas de aplicaciones externos globales compilados en Anthos Service Mesh |
Cada GatewayClass está sujeta a las limitaciones del balanceador de cargas subyacente.
Puerta de enlace
Los operadores de clústeres crean Gateways para definir dónde y cómo los balanceadores de cargas escuchan el tráfico. Las Gateways toman su comportamiento (es decir, cómo se implementan) desde su GatewayClass asociada.
La especificación de Gateway incluye la GatewayClass para la Gateway, qué puertos y protocolos se escucharán, y qué rutas pueden vincularse a la Gateway. Una Gateway selecciona rutas en función de los metadatos de la Route; específicamente, el tipo, el espacio de nombres y las etiquetas de los recursos de Route.
Para ver un ejemplo de la implementación de una Gateway, consulta Implementa Gateways.
Para ver un ejemplo de implementación de una Gateway de varios clústeres, consulta Implementa Gateways de varios clústeres.
HTTPRoute
Una HTTPRoute define cómo las solicitudes HTTP y HTTPS que recibe una Gateway se dirigen a los servicios. Los desarrolladores de aplicaciones crean HTTPRoutes para exponer sus aplicaciones a través de Gateways.
Una HTTPRoute define desde qué puertas de enlace se puede enrutar el tráfico, hacia qué servicios se debe enrutar y las reglas que definen con qué tráfico coincide la HTTPRoute. La vinculación de una Gateway y una ruta es bidireccional, lo que significa que ambos recursos deben seleccionarse para que se vinculen. HTTPRoutes puede hacer coincidir 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 puerta de enlace, generalmente específicas de la implementación, que los operadores de clústeres pueden adjuntar a una puerta de enlace, una ruta o un servicio de Kubernetes. Una política define cómo debe funcionar la infraestructura subyacente de Google Cloud.
Por lo general, una política se adjunta a un espacio de nombres y puede hacer referencia a un recurso en el mismo espacio de nombres, y se otorga el acceso mediante RBAC. La naturaleza jerárquica de la API de la puerta de enlace te permite adjuntar una política a un recurso superior (puerta de enlace) en un espacio de nombres y hacer que todos los recursos subyacentes en diferentes espacios de nombres reciban las características de esa política.
El controlador de la puerta de enlace de GKE admite las siguientes políticas:
HealthCheckPolicy: define los parámetros y el comportamiento de la verificación de estado que se usa para verificar el estado de los Pods del backend.GCPGatewayPolicy: Define los parámetros específicos del frontend del balanceador de cargas de Google Cloud. Esto es similar a unFrontendConfigpara un recurso de Ingress.GCPBackendPolicy: Define cómo los servicios de backend del balanceador de cargas deben distribuir el tráfico a los extremos. Esto es similar a unBackendConfigpara un recurso de Ingress.
Propiedad de la Gateway y patrones de uso
Los recursos de Gateway y de Ruta proporcionan flexibilidad en cuanto a su propiedad y cómo se implementan dentro de una organización. Esto significa que un equipo de infraestructura puede implementar y administrar un solo balanceador de cargas, pero el enrutamiento en un dominio o una ruta en particular puede delegarse a otro equipo en otro espacio de nombres de Kubernetes. El controlador de Gateway de GKE admite el uso de un balanceador de cargas por parte de varios usuarios, compartido entre espacios de nombres, clústeres y regiones. Tampoco es necesario compartir las Gateways si se requiere una propiedad más distribuida. A continuación, se muestran algunos de los patrones de uso más comunes de Gateway en GKE.
Gateway autoadministrada
Un único propietario puede implementar una Gateway y una Ruta solo para sus aplicaciones y usarlas exclusivamente. Las Gateways y las Rutas implementadas de esta manera son similares a Ingress. En el siguiente diagrama, se muestran dos propietarios diferentes del servicio que implementan y administran sus propias Gateways. Al igual que Ingress, cada Gateway corresponde a su propia dirección IP y balanceador de cargas únicos. El propietario del servicio controla por completo las políticas de TLS, enrutamiento y otras políticas.
Este patrón de uso es común 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 de Gateway habilita los siguientes patrones de uso que proporcionan una variedad de opciones para el control y la propiedad distribuidos.
Gateway administrada por plataforma por espacio de nombres
La separación entre los recursos de Gateway y Ruta permite que los administradores de la plataforma controlen Gateways en nombre de los propietarios del servicio. Los administradores de la plataforma pueden implementar una Gateway por espacio de nombres o equipo, lo que le brinda a ese espacio de nombres acceso exclusivo para usarla. Esto le da al propietario del servicio control total sobre las reglas de enrutamiento sin ningún riesgo de conflicto para otros equipos. Esto permite que el administrador de la plataforma controle 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 puertas de enlace están disponibles para los equipos, como Gateways internas o externas/públicas. Este patrón de uso crea una separación clara de responsabilidades entre diferentes roles.
El enrutamiento entre espacios de nombres es lo que permite que las Rutas se conecten a las puertas de enlace a través de los límites de los espacios de nombres. Las puertas de enlace pueden restringir desde qué espacios de nombres se pueden conectar las Rutas. De manera similar, las Rutas especifican las puertas de enlace a las que se conectan, pero solo pueden conectarse a una puerta de enlace que haya permitido el espacio de nombres de la Ruta. Este adjunto bidireccional proporciona a cada lado controles flexibles que permiten esta diversidad de patrones de uso.
En el siguiente diagrama, el administrador de la plataforma implementó una puerta de enlace para un acceso exclusivo en cada espacio de nombres. Por ejemplo, la Gateway store se configura para que solo las rutas del espacio de nombres store puedan adjuntarse a ella. Cada Gateway representa una dirección IP única y de balanceo de cargas, por lo que permite que cada equipo implemente cualquier cantidad de rutas en la Gateway para cualquier dominio o ruta que elija.
Gateway compartida por clúster
Compartir Gateways entre espacios de nombres ofrece una forma aún más centralizada de propiedad a los administradores de la plataforma. Esto permite que diferentes propietarios de servicios, que se ejecutan en diferentes espacios de nombres, compartan el mismo dominio DNS, dirección IP, certificados o rutas para un enrutamiento detallado entre los servicios. Las Gateways proporcionan control a los administradores de la plataforma sobre qué espacios de nombres se pueden enrutar para un dominio específico. Esto es similar al ejemplo anterior, excepto que las Gateways permiten la conexión de las Rutas desde más de un espacio de nombres.
En el siguiente diagrama, el administrador de la plataforma implementó dos Gateways en el espacio de nombres infra. La Gateway external permite que las Rutas de los espacios de nombres web y mobile se conecten a la Gateway. Las Rutas del espacio de nombres accounts no pueden usar la Gateway external porque el espacio de nombres accounts solo es para servicios internos. La Gateway internal 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 al espacio de nombres mobile, que permite a los propietarios del servicio móvil configurar cualquier regla de enrutamiento que necesiten en el dominio m.example.com. Esto les brinda a los propietarios del servicio un mayor control para ingresar nuevos extremos de API y controlar el tráfico sin solicitar un cambio a los administradores.
Gateway compartida por flota
Mediante las Gateways de varios clústeres, se puede compartir una Gateway entre espacios de nombres, clústeres y regiones. Las organizaciones grandes con apps distribuidas geográficamente podrían beneficiarse de las Gateways de varios clústeres porque pueden controlar de forma detallada el tráfico global mientras delegan la propiedad del enrutamiento. Al igual que en los ejemplos anteriores, un administrador de la plataforma administra la Gateway y delega el enrutamiento. La adición principal a este caso de uso es que las Rutas hacen referencia a Services de varios clústeres, que se implementan en diferentes clústeres. El tráfico se puede enrutar de forma explícita, el tráfico a store.example.com/us va a Pods gke-us o, de manera implícita, el tráfico a example.com/* se enruta al clúster más cercano al cliente. Esta flexibilidad permite a los propietarios del servicio definir la estrategia de enrutamiento óptima para su aplicación.
Controlador de Gateway de GKE
El controlador de Gateway de GKE es la implementación de Google de la API de Gateway para Cloud Load Balancing. Al igual que el controlador de Ingress de GKE, el controlador de Gateway observa una API de Kubernetes para los recursos de la API de Gateway y concilia los recursos de Cloud Load Balancing a fin de implementar el comportamiento de las herramientas de redes especificado por los recursos de la Gateway.
Hay dos versiones del controlador de Gateway de GKE:
- Un solo clúster: Administra las puertas de enlace de un solo clúster para un solo clúster de GKE.
- Varios clústeres: administra puertas de enlace de varios clústeres para uno o más clústeres de GKE.
Ambos controladores de Gateway son controladores alojados en Google que miran la API de Kubernetes para clústeres de GKE. A diferencia del controlador de Ingress de GKE, los controladores de Gateway no se alojan en los planos de control de GKE ni en el proyecto del usuario, lo que permite que sean más escalables y sólidos. Ambos controladores de las puertas de enlace tienen disponibilidad general.
Los controladores de Gateway no son un plano de datos de herramientas de redes y no procesan ningún tráfico. Se mantienen fuera de banda del tráfico y administran diversos planos de datos que procesan el tráfico. En el siguiente diagrama, se muestra la arquitectura de los controladores de Gateway de GKE de un solo clúster y de varios clústeres. El controlador subyacente que se usa depende de la GatewayClass de la Gateway implementada.
| Controlador | Controlador de Gateway de un solo clúster | Controlador de Gateway de varios clústeres |
|---|---|---|
| Administrado por | Google Cloud | Google Cloud |
| Permiso del clúster | Gateways de un solo clúster | Gateways de varios clústeres |
| La ubicación de la implementación | Se implementa de forma regional en la misma región que su clúster de GKE. | Se implementa de forma global en varias regiones de Google Cloud. |
| Cómo habilitar | Se habilita de forma predeterminada en GKE. | Se habilita a través de la API de Ingress de varios clústeres y se registra en una flota. Consulta Habilitar puertas de enlace de varios clústeres. |
| GatewayClasses compatibles |
|
|
Puedes usar varios controladores de Gateway, incluidos los controladores no proporcionados por Google, en un clúster de GKE de forma simultánea. Cada Gateway es compatible con un solo controlador de Gateway, lo que permite que se use simultáneamente el balanceo de cargas de varios clústeres.
Ingress y puerta de enlace
Comparación entre Ingress y Gateway
Ingress y Gateway son estándares de código abierto para enrutar tráfico. La comunidad de Kubernetes diseñó Gateway, sobre la base de las lecciones aprendidas a partir de los ecosistemas de Ingress y de la malla de servicios. Gateway es una evolución de Ingress que proporciona la misma función, entregada como un superconjunto de las capacidades de Ingress. Ambos se pueden usar de forma simultánea sin conflictos, aunque con el tiempo, los recursos de Gateway y Route entregarán más funciones que no están disponibles en Ingress, lo que obligará a los usuarios a comenzar a usar la puerta de enlace, donde podrían haber usado Ingress antes.
En GKE, todos los recursos de Ingress se pueden convertir directamente en recursos de Gateway y HTTPRoute. Un solo Ingress corresponde a un recurso de Gateway (para la configuración de frontend) y de HTTPRoute (para la configuración de enrutamiento). En el siguiente ejemplo, se muestra cómo se ve la configuración de puerta de enlace y HTTPRoute correspondiente. Ten en cuenta que los recursos de puerta de enlace y HTTPRoute se pueden crear por separado y por diferentes usuarios. Las Gateways pueden tener muchas Rutas y una Ruta también puede adjuntarse a más de una puerta de enlace. Las relaciones entre las puertas de enlace y las rutas se analizan en Patrones de uso de puertas de enlace.
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
Puerta de enlace
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
Route
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
Integra la API de Gateway en mallas de servicios
Puedes configurar una malla de servicios de Traffic Director mediante la API de Gateway. Esto permite comunicaciones de servicio a servicio, administración del tráfico, balanceo de cargas global y aplicación de la política de seguridad para casos de uso de la malla de servicios. Para obtener información completa sobre el uso de Traffic Director con la API de Gateway, incluidas las guías de configuración de implementaciones, consulta la descripción general de la malla de servicios de GKE de Traffic Director.
Precios
Todos los recursos de Compute Engine implementados a través del controlador de la puerta de enlace se cobran en el proyecto en el que residen tus clústeres de GKE. El controlador de Gateway de un solo clúster se ofrece sin cargo adicional como parte de los precios de GKE Standard y Autopilot. Los precios de las puertas de enlace de varios clústeres se describen en la página de precios de Ingress y puerta de enlace de varios clústeres.
¿Qué sigue?
- Obtén más información sobre cómo configurar los recursos de la puerta de enlace mediante políticas
- Obtén más información sobre cómo implementar puertas de enlace.
- Obtén más información sobre cómo implementar puertas de enlace de varios clústeres.
- Para obtener información completa sobre el uso de Traffic Director con la API de Gateway, consulta Descripción general de la malla de servicios de GKE de Traffic Director.