Puerta de enlace

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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. Para implementar puertas de enlace en GKE, consulta Implementar puertas de enlace o Implementar puertas de enlace de varios clústeres.

La API de Gateway es un estándar de código abierto para herramientas de redes de servicios. La API de Gateway evoluciona el recurso Ingress y lo mejora de las siguientes maneras:

  • Orientado a funciones: 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 Gateway 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.

GKE proporciona clases de Gateway. Los operadores de clústeres crean recursos de puertas de enlace basados en estas clases. Los desarrolladores de aplicaciones crean recursos HTTPRoute que se vinculan a recursos de Gateway.
Figura: Descripción general de la API de Gateway

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. GKE admite las siguientes políticas:
    • LBPolicy define el comportamiento esperado del balanceador de cargas de Google Cloud.
    • HealthCheckPolicy: define el tipo de verificación de estado para los Pods de backend y las características de la verificación de estado.

GatewayClass

Una GatewayClass es un recurso que define una plantilla para balanceadores de cargas de TCP/UDP (nivel 4) y balanceadores de cargas de 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 Gateways 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 clase Descripción
gke-l7-rilb Balanceadores de cargas HTTP(S) regionales internos basados en el balanceo de cargas HTTP(S) interno
gke-l7-gxlb Balanceadores de cargas de HTTP(S) externos globales compilados en el balanceador de cargas HTTP(S) externo global (clásico)
gke-l7-rilb-mc Balanceadores de cargas regionales de varios clústeres basados en el balanceo de cargas HTTP(S) interno
gke-l7-gxlb-mc Balanceadores de cargas globales de varios clústeres compilados en el balanceador de cargas HTTP(S) externo global (clásico)
gke-td Malla de servicios de Traffic Director de varios clústeres

Cada GatewayClass está sujeta a las limitaciones del balanceador de cargas subyacente.

Gateway

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

GKE Gateway Controller admite dos políticas:

  • LBPolicy define parámetros específicos del balanceador de cargas de Google Cloud. Esto es similar a un BackendConfig para un recurso de Ingress.
  • 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.

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.

Un solo propietario puede tener control total sobre la Gateway y la ruta.

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 Gateways 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 Gateways a través de los límites de los espacios de nombres. Las Gateways pueden restringir desde qué espacios de nombres se pueden conectar las Rutas. De manera similar, las Rutas especifican las Gateways a las que se conectan, pero solo pueden conectarse a una Gateway 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 Gateway 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.

Una Gateway por espacio de nombres proporciona acceso exclusivo a una Gateway a ese espacio de nombres.

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.

Una Gateway por clúster permite que diferentes espacios de nombres dentro de un clúster compartan una sola Gateway

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.

Una Gateway por flota proporciona balanceo de cargas de varios clústeres y regiones

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. El controlador para una puerta de enlace de un solo clúster tiene disponibilidad general.
  • Varios clústeres: administra puertas de enlace de varios clústeres para uno o más clústeres de GKE. El controlador para puertas de enlace de varios clústeres se encuentra en la etapa de lanzamiento de vista previa y no tiene ANS ni asistencia técnica.

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.

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.

Los controladores de Gateway de varios clústeres y de un solo clúster implementan y administran los balanceadores de cargas de GKE, pero no procesan el tráfico de red.

Controlador Controlador de Gateway de un solo clúster Controlador de Gateway de varios clústeres
Administrado por Google Google
Alcance 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
  • gke-l7-rilb
  • gke-l7-gxlb
  • gke-l7-rilb-mc
  • gke-l7-gxlb-mc
Etapa de lanzamiento DG Vista previa

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

Migra de Ingress a Gateway

La migración entre Ingress y Gateway es posible mediante la implementación de los recursos Ingress y Gateway de forma simultánea, que apunten al mismo conjunto de Services. Esto crea dos puntos de entrada para las mismas aplicaciones de backend. Cada Ingress y Gateway corresponden a la dirección IP de un balanceador de cargas individual. Prueba la ruta de acceso de Gateway y, una vez que se valide, usa DNS para cambiar el tráfico de Ingress a Gateway.

No se admite la conversión directa de un Ingress a una Gateway. Sin embargo, si usas Ingress en este momento, se recomienda ejecutar ambos de manera simultánea para asegurarte de que la transición a Gateway se realice de forma segura sin ninguna interrupción del tráfico.

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 Gateway, 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 Gateway y HTTPRoute correspondiente. Ten en cuenta que los recursos de Gateway 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 Gateway. Las relaciones entre las Gateways y las Rutas se analizan en Patrones de uso de Gateway.

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 Gateway 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. Puedes usar el controlador de Gateway de varios clústeres sin cargo adicional durante la vista previa. En la etapa de disponibilidad general, las Gateways de varios clústeres se cobrarán de acuerdo con los precios de Ingress y Gateway de varios clústeres.

¿Qué sigue?