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 co