Kubernetes Gateway API: Reimaginando Ingress.

Es innegable que estamos en la era de Kubernetes. Esto puede tener sus pros y contras, pero es un hecho irrefutable. La aparición de nuevos marcos de trabajo basados en el aprovechamiento de Kubernetes y de su API extensible ha provocado una auténtica vorágine de ideas y conceptos, algunos nuevos y otros no tanto, que de una forma u otra terminan siendo introducidos dentro del ecosistema.

Este crecimiento a nivel de herramientas y capacidades dentro de Kubernetes deriva en multitud de iniciativas para crear plataformas comunes donde diferentes equipos coexisten y operan con cierto grado de independencia. Cuando nos planteamos este tipo de escenarios, comenzamos a imaginarnos las premisas de un cluster multitenant y todos los elementos que debemos tener en cuenta para que aquello funcione: seguridad, identidades, límites, namespaces, flujos de despliegue, ciclos de vida… y, uno de ellos, siempre destaca por las dependencias que crea con el resto de componentes:

“¿Cómo voy a exponer mis aplicaciones?”

Inmediatamente, nos surge en la cabeza el concepto de Ingress como solución a este problema. A partir de ahí, comenzamos a hacernos más preguntas: ¿Cuántos puntos de entrada tendrá mi cluster? ¿Cómo gestionar los certificados? ¿Cómo democratizar el Ingress entre mis equipos de desarrollo? ¿Necesito enrutado por cabeceras o por pesos? ¿Usaré balanceadores propios de mi proveedor cloud? ¿Cómo encajar todas estas piezas con el día a día del equipo que gestiona el clúster?

No es un problema nuevo

Para responder a todas esas preguntas y poder dar respuesta bajo una única solución, se han creado multitud de implementaciones de Ingress e Ingress Controller. Siguiendo la especificación básica de Kubernetes, los diferentes proveedores han expandido la funcionalidad de estos para poder provisionar balanceadores de carga, permitir la gestión entre namespaces y añadir políticas avanzadas de enrutado y seguridad (y es solo la punta del iceberg).

Sin embargo, el resultado final ha derivado en una suerte de ecosistema “Frankenstein” en el que los Ingress Controller difieren enormemente entre ellos (aunque todos cubren en mayor medida las necesidades básicas). Y, en este aspecto, algunos puntos claves como el soporte de protocolos distintos al HTTP y la coexistencia de equipos con distintos roles y capacidades son campos en los que Ingress demuestra cierto nivel de “rigidez” y es altamente dependiente del Ingress Controller que se implementa.

Para dar una fundamentación mucho más sólida al modelo de red y, al mismo tiempo, permitir una mayor operatividad y modularidad de sus componentes, existe desde hace un tiempo un proyecto de la comunidad de Kubernetes denominado Gateway API. Gateway no es un reemplazo de Ingress, sino una evolución que pretende mejorar la gestión de la comunicación entre el clúster y su entorno, poniendo el foco en la generalidad y la separación de los distintos roles.

From Scratch: Gateway API

Gateway API es un proyecto open source desarrollado por un grupo de interés especial (SIG) especializado en red dentro de la comunidad de Kubernetes. Este grupo se centra en el desarrollo del modelo de red y en las funcionalidades que estos deben soportar. De hecho, Gateway API no contempla crear una implementación concreta del controlador como ocurre con Ingress (ya que volveríamos a caer en el mismo error, cosa que se nos da de lujo); sino que centran sus esfuerzos en la definición, dejando en manos de los proveedores la responsabilidad de implementarlo. Uno de ellos, Google, ya tiene una implementación en GA disponible para GKE; en este post lo usaremos como ejemplo para explicar cada componente.

Gateway API propone un modelo de red basado en roles como se puede observar en el diagrama:

Se definen nuevos tipos de objetos de Kubernetes dirigidos cada uno a un público/rol en específico, permitiendo una convivencia pacífica en la cual cada nivel de abstracción hereda las restricciones de la capa superior:

• GatewayClass: siguiendo la filosofía de Kubernetes ya aplicada en otros ámbitos como las StorageClasses o las propias Ingress Class, GatewayClass es una especificación abstracta que aísla la implementación física de los elementos de infraestructura, permitiendo su uso de forma genérica. Tomando GKE como ejemplo, cada GatewayClass define un tipo de balanceador gestionado distinto (gke-l7-rilb son balanceadores de capa 7 internos regionales, mientras que gke-l7-gxlb son balanceadores de capa 7 externos globales). La implementación de las Gateway Classes son responsabilidad de los proveedores de infraestructura, Google en el caso del ejemplo.
• Gateway: Gateway no es más que una implementación específica de una GatewayClass. Es decir, siguiendo con el ejemplo, un Gateway es un balanceador específico cuyas características básicas son definidas por la clase (regional, global, capa de red, etc.). No obstante, al ser una implementación concreta, en esta capa los operadores del clúster pueden definir tantos Gateway como quieran y las características específicas de cada uno (certificados asociados, ips, etc.).
  En este punto debemos destacar de forma especial la gobernanza de este elemento, ya que es el propio Gateway quien define quién puede publicarse a través de él en cada uno de los listener. Es posible que queramos que las aplicaciones se puedan exponer solo a través de HTTPs y que el Gateway rechace cualquier intento de publicación al listener HTTP. También podemos discriminar por namespaces, usando selectores, etc.
• Routes: pueden ser de tipo HTTP, TLS, gRPC, etc. Las rutas son objetos que definen cómo se deberían enrutar las peticiones a través del Gateway al que se asocian. Definen el/los servicios que se exponen, bajo qué rutas, pesos, cabeceras, condicionales, etc. Permiten la definición de hostnames concretos, sobreescrituras, redirecciones, etc.
  Las rutas están concebidas para ser gestionadas directamente por los equipos de desarrollo. Esto permite total independencia para publicar o privatizar servicios, aplicar condicionales o estrategias avanzadas de enrutado sin impactar al resto de equipos que desplieguen sus aplicaciones y sin comprometer la correcta implementación del Gateway (certificados, listeners, etc.). Una ruta elige a qué Gateway y listener se asocia, siempre y cuando cumpla el requisito del propio Gateway.

Como podemos ver, la principal ventaja de Gateway API es la distribución de las responsabilidades entre las distintas capas del modelo. La flexibilidad que aporta es enorme, pudiendo dentro de un mismo clúster gestionar desde Gateways privados aislados en un namespace, hasta Gateways compartidos entre todos los namespaces del clúster. Esto también obedece a la necesidad de los componentes a adaptarse a las diferentes morfologías de los equipos involucrados.

El espíritu DevOps nos invita a empoderar al desarrollador/a, permitiendo que la gestión de la infraestructura sea realizada utilizando herramientas, métodos y filosofías concebidas para el desarrollo de software. Siendo puristas con la definición de DevOps, un/a developer debería ser capaz de operar la plataforma de la misma forma que despliega la aplicación. ¿Significa esto que la figura de operador del clúster debería desaparecer en un escenario ideal? Rotundamente no, pero sí debemos buscar la integración de su flujo de trabajo con el de los desarrolladores. En Paradigma, desde nuestro círculo de QSO (Calidad, Seguridad y Sistemas e infraestructuras Cloud) intentamos siempre promover estas sinergias con los equipos de desarrollo para que la vida de todos sea más sencilla, no creemos en los nichos, sino en la responsabilidad compartida y la unificación de equipos. Gateway API en este sentido, comparte todos los valores de esta filosofía DevOps.

Por ejemplo, el operador del clúster podría configurar Gateway con los certificados y políticas necesarias y, a continuación, simplemente instruir al equipo de desarrollo para que sepa cómo puede publicar sus aplicaciones. De hecho, llevando DevOps por bandera, la evolución natural sería automatizar este proceso para estandarizar y aliviar la carga de todo el mundo ;) (con Helm por ejemplo). El clúster, por tanto, a nivel de ingress, no precisa de la intervención del operador cada vez que una aplicación quiera publicarse. Nuestro alter ego del ejemplo podrá dormir tranquilo, sabiendo que las aplicaciones están expuestas de forma adecuada, con los certificados y las medidas de seguridad que proceden. De esta forma, minimizamos las dependencias entre equipos, reducimos el intervencionismo, promovemos la automatización y aceleramos la entrega continúa de valor, permitiendo que el operador se haga cargo de otras tareas menos mecánicas.

Conclusiones

Hasta aquí los puntos básicos de Gateway API para este post. Antes de cerrar, indicar que, siguiendo la filosofía general de Kubernetes; la api de Gateway también es completamente portable, segura y extensible. Esto abre la puerta a funcionalidades adicionales como los Healthchecks customizados de Google Cloud pero siempre con una dirección y gobierno marcados por la definición de la API. Para más información al respecto, es útil revisar los niveles de soporte.

Gateway API implementa muchas más funcionalidades, por lo que os animo desde aquí a revisar su web y su repositorio de GitHub. También recomiendo revisar lo fácil que resulta implementarlo en GKE, aunque no lo digo, lo hago… en el siguiente post ;).