Treo Blog

En este espacio puedes explorar las últimas tendencias y noticias en tecnología, seguridad informática e infraestructura TI.

  • Jonathan Rodriguez Paipa

Evolución de las redes de Kubernetes con la API de Gateway

Por: Mark Church (Google), Harry Bagdi (Kong), Daneyon Hanson (Red Hat), Nick Young (VMware), Manuel Zapf (Traefik Labs)




Crédito: Pexels

El recurso Ingress es una de las muchas historias de éxito de Kubernetes. Creó un ecosistema diverso de controladores Ingress que se utilizaron en cientos de miles de clústeres de forma estandarizada y coherente. Esta estandarización ayudó a los usuarios a adoptar Kubernetes. Sin embargo, cinco años después de la creación de Ingress, hay signos de fragmentación en CRD diferentes pero sorprendentemente similares y anotaciones sobrecargadas . La misma portabilidad que hizo que Ingress fuera omnipresente también limitó su futuro.







Fue en Kubecon 2019 San Diego cuando un apasionado grupo de colaboradores se reunió para discutir la evolución de Ingress . La discusión se desbordó hasta el vestíbulo del hotel al otro lado de la calle y lo que surgió más tarde se conocería como la API de Gateway . Esta discusión se basó en algunas suposiciones clave:

  1. Los estándares de API subyacentes a la coincidencia de rutas, la gestión del tráfico y la exposición del servicio se comercializan y proporcionan poco valor a sus implementadores y usuarios como API personalizadas.

  2. Es posible representar el enrutamiento y la gestión del tráfico L4 / L7 a través de recursos API de núcleo común

  3. Es posible proporcionar extensibilidad para capacidades más complejas de una manera que no sacrifique la experiencia del usuario de la API central.

Presentamos la API de Gateway


Esto llevó a principios de diseño que permiten que la API de Gateway mejore el Ingress:

  • Expresividad : además de la coincidencia de host / ruta HTTP y TLS, la API de Gateway puede expresar capacidades como manipulación de encabezados HTTP, ponderación y duplicación de tráfico, enrutamiento TCP / UDP y otras capacidades que solo eran posibles en Ingress a través de anotaciones personalizadas.

  • Diseño orientado a roles : el modelo de recursos de API refleja la separación de responsabilidades que es común en el enrutamiento y las redes de servicios de Kubernetes.

  • Extensibilidad : los recursos permiten adjuntar configuraciones arbitrarias en varias capas dentro de la API. Esto hace posible la personalización granular en los lugares más apropiados.

  • Cumplimiento flexible : la API de Gateway define diferentes niveles de cumplimiento: básico (soporte obligatorio), extendido (portátil si es compatible) y personalizado (sin garantía de portabilidad), conocidos en conjunto como cumplimiento flexible . Esto promueve una API central altamente portátil (como Ingress) que aún brinda flexibilidad para los implementadores de controladores de Gateway.


¿Qué aspecto tiene la API de Gateway?


La API de Gateway presenta algunos tipos de recursos nuevos:

  • GatewayClasses son recursos de ámbito de clúster que actúan como plantillas para definir explícitamente el comportamiento de los Gateways derivados de ellos. Esto es similar en concepto a StorageClasses, pero para planos de datos de red.

  • Las puertas de enlace son las instancias implementadas de GatewayClasses. Son la representación lógica del plano de datos que realiza el enrutamiento, que pueden ser proxies dentro del clúster, LB de hardware o LB de nube.

  • Las rutas no son un recurso único, sino que representan muchos recursos de ruta específicos del protocolo diferentes. El HTTPRoute se pongan en venta, la filtración, y las reglas que consiguen aplicar a puertas de enlace que pueden procesar tráfico HTTP y HTTPS de enrutamiento. De manera similar, existen TCPRoutes , UDPRoutes y TLSRoutes que también tienen semántica específica de protocolo. Este modelo también permite que la API de Gateway amplíe gradualmente su compatibilidad con el protocolo en el futuro.




Implementaciones del controlador de puerta de enlace


La buena noticia es que, aunque Gateway está en Alpha , ya hay varias implementaciones de controladores Gateway que puede ejecutar. Dado que es una especificación estandarizada, el siguiente ejemplo podría ejecutarse en cualquiera de ellos y debería funcionar exactamente de la misma manera. Consulte cómo comenzar para ver cómo instalar y usar uno de estos controladores Gateway.


Ponerse en práctica con la API de Gateway


En el siguiente ejemplo, demostraremos las relaciones entre los diferentes recursos de API y lo guiaremos a través de un caso de uso común:

  • El equipo foo tiene su aplicación implementada en el espacio de nombres foo. Necesitan controlar la lógica de enrutamiento para las diferentes páginas de su aplicación.

  • La barra de equipo se está ejecutando en el espacio de nombres de la barra. Quieren poder hacer implementaciones azul-verde de su aplicación para reducir el riesgo.

  • El equipo de la plataforma es responsable de administrar el equilibrador de carga y la seguridad de la red de todas las aplicaciones en el clúster de Kubernetes.

La siguiente ruta foo hace coincidir la ruta con varios servicios en el espacio de nombres foo y también tiene una ruta predeterminada a un servidor 404. Esto expone los servicios foo-auth y foo-home a través de foo.example.com/loginy foo.example.com/homerespectivamente:




























El equipo de la barra, que opera en el espacio de nombres de la barra del mismo clúster de Kubernetes, también desea exponer su aplicación a Internet, pero también quiere controlar sus propios despliegues canario y azul-verde. La siguiente HTTPRoute está configurada para el siguiente comportamiento:

  • Para tráfico a bar.example.com:

  • Envíe el 90% del tráfico a bar-v1

  • Envía el 10% del tráfico a bar-v2


  • Para el tráfico bar.example.comcon el encabezado HTTP env: canary:

  • Envía todo el tráfico a bar-v2

























Enlace de ruta y puerta de enlace


Así que tenemos dos HTTPRoutes que coinciden y enrutan el tráfico a diferentes Servicios. Quizás se esté preguntando, ¿dónde están accesibles estos Servicios? ¿A través de qué redes o IP están expuestos?


La forma en que las rutas se exponen a los clientes se rige por el enlace de rutas , que describe cómo las rutas y las puertas de enlace crean una relación bidireccional entre sí. Cuando las rutas están vinculadas a una puerta de enlace, significa que sus reglas de enrutamiento colectivo están configuradas en los equilibradores de carga o proxies subyacentes y las rutas son accesibles a través de la puerta de enlace. Por lo tanto, una puerta de enlace es una representación lógica de un plano de datos de red que se puede configurar a través de rutas.




Delegación administrativa


La división entre los recursos de puerta de enlace y ruta permite al administrador del clúster delegar parte de la configuración de enrutamiento a equipos individuales y, al mismo tiempo, conservar el control centralizado. El siguiente recurso de puerta de enlace expone HTTPS en el puerto 443 y finaliza todo el tráfico en el puerto con un certificado controlado por el administrador del clúster.





















La siguiente HTTPRoute muestra cómo la ruta puede garantizar que coincida con el selector de la puerta de enlace a través de su kind(HTTPRoute) y las etiquetas de recursos ( gateway=external-https-prod).












Diseño orientado a roles


Cuando lo pone todo junto, tiene una única infraestructura de equilibrio de carga que varios equipos pueden compartir de forma segura. La API de Gateway no solo es una API más expresiva para enrutamiento avanzado, sino que también es una API orientada a roles, diseñada para infraestructura de múltiples inquilinos. Su extensibilidad asegura que evolucionará para futuros casos de uso mientras preserva la portabilidad. En última instancia, estas características permitirán que la API de Gateway se adapte a diferentes modelos organizativos e implementaciones en el futuro.


Pruébalo e involúcrate


Hay muchos recursos que puede consultar para obtener más información.

  • Consulte las guías de usuario para ver qué casos de uso se pueden abordar.

  • Pruebe uno de los controladores Gateway existentes

  • ¡O participe y ayude a diseñar e influir en el futuro de las redes de servicios de Kubernetes!

Fuente: Blog de Kubernetes

3 vistas0 comentarios