Kubernetes Gateway API v1.0: ¿Deberías cambiar?

Ha pasado más de un mes desde que la API de Gateway de Kubernetes lanzó su versión v1.0, lo que marca su graduación al estado de disponibilidad general para algunas de sus API clave.

Escribí sobre la API de Gateway cuando alcanzó la fase beta el año pasado, pero un año después, la pregunta sigue siendo la misma. ¿Deberías cambiar de la API de Ingress a la API de Gateway?

Mi respuesta del año pasado fue que no deberías hacerlo. Y tenía fuertes razones.

La API de Gateway y sus implementaciones aún estaban en su infancia. Por otro lado, la API de Ingress era estable y cubría algunos casos de uso principales que podrían funcionar para la mayoría de los usuarios.

Para los usuarios que requerían más capacidades, sugerí utilizar los recursos personalizados proporcionados por los controladores de Ingress, sacrificando la portabilidad (cambiar entre diferentes implementaciones de Ingress).

Con el lanzamiento de la versión v1.0, esto podría cambiar. La API de Gateway es mucho más capaz ahora, y sus más de 20 implementaciones están avanzando rápidamente.

Por lo tanto, si estás comenzando de nuevo y eligiendo entre la API de Ingress y la API de Gateway, te sugiero que elijas la API de Gateway si la API y la implementación que elijas admiten todas las funciones que necesitas.

¿Qué tiene de malo la API de Ingress?

La API de Ingress funciona muy bien, pero solo para un pequeño subconjunto de casos de uso comunes. Para extender sus capacidades, las implementaciones de Ingress comenzaron a usar anotaciones personalizadas.

Por ejemplo, si elegiste Nginx Ingress, usarás algunas de sus docenas de anotaciones que no son portables si decides cambiar a otra implementación de Ingress como Apache APISIX.

Estas anotaciones específicas de la implementación también son engorrosas de gestionar y van en contra del propósito de gestionar Ingress de una manera nativa de Kubernetes.

Finalmente, las implementaciones de controladores de Ingress comenzaron a desarrollar sus propios CRDs para exponer más características a los usuarios de Kubernetes. Estos CRDs son específicos del controlador de Ingress. Pero si puedes sacrificar la portabilidad y quedarte con un solo controlador de Ingress, los CRDs son más fáciles de usar y ofrecen más características.

La API de Gateway tiene como objetivo resolver este problema de una vez por todas, proporcionando la independencia de proveedores de la API de Ingress y la flexibilidad de los CRDs. Está muy bien posicionada para lograr este objetivo.

A largo plazo, no se espera que la API de Ingress reciba nuevas características, y todos los esfuerzos se dirigirán a converger con la API de Gateway. Por lo tanto, adoptar la API de Ingress puede causar problemas cuando inadvertidamente llegues a los límites de sus capacidades.

Beneficios evidentes

Expresiva, extensible y orientada a roles son las ideas clave que dieron forma al desarrollo de la API de Gateway.

A diferencia de la API de Ingress, la API de Gateway es una colección de múltiples API (HTTPRoute, Gateway, GatewayClass, etc.), cada una dirigida a diferentes roles organizacionales.

Por ejemplo, los desarrolladores de aplicaciones solo necesitan preocuparse por el recurso HTTPRoute, donde pueden definir reglas para enrutar el tráfico. Pueden delegar los detalles a nivel de clúster a un operador que gestiona el clúster y asegura que cumpla con las necesidades de los desarrolladores utilizando el recurso Gateway.

Este diseño orientado a roles de la API permite que diferentes personas utilicen el clúster mientras mantienen el control.

La API de Gateway también es mucho más capaz que la API de Ingress. Las características que requieren anotaciones en la API de Ingress son compatibles de forma nativa en la API de Gateway.

Una extensión oficial

Aunque la API de Gateway es una API oficial de Kubernetes, se implementa como un conjunto de CRDs.

Esto no es diferente de usar los recursos predeterminados de Kubernetes. Pero simplemente tienes que instalar estos CRDs como una extensión oficial.

Esto permite una iteración rápida en comparación con Kubernetes, que se mueve lentamente hacia la estabilidad a largo plazo.

¿Se proliferará?

Como este famoso cómic de XKCD nos recuerda con frecuencia, los estándares tienden a proliferar.

Una versión de esto se vio en las API de Ingress y Gateway. Suele ser así:

1. Surge un estándar para unificar diferentes proyectos/sus estándares (API de Ingress de Kubernetes).
2. El estándar unificado tiene limitaciones que los implementadores quieren superar (la API de Ingress era limitada).
3. Las implementaciones divergen del estándar debido a estas limitaciones (CRDs personalizados, anotaciones).
4. Cada implementación ahora tiene su propio estándar (CRDs no portables, anotaciones).
5. Surge un nuevo estándar para unificar estos diferentes estándares (API de Gateway de Kubernetes).

Es razonable pensar que la API de Gateway podría no ser el final aquí. Pero creo que tiene todas las posibilidades de ser el estándar para el enrutamiento en Kubernetes.

De nuevo, tengo mis fuertes razones.

La adopción generalizada es crucial para evitar la proliferación de estándares, ya que hay menos incentivos para que las implementaciones trabajen en un estándar diferente. La API de Gateway ya tiene más de 25 implementaciones.

Una implementación puede conformarse con la API de Gateway en diferentes niveles:

1. Núcleo: Se espera que todas las implementaciones se ajusten a estos.
2. Extendido: Estos podrían estar disponibles solo en algunas implementaciones, pero son API estándar.
3. Específico de la implementación: Específico de las implementaciones, pero añadido a través de puntos de extensión estándar.

Una característica de nicho puede pasar de ser específica de la implementación a extendida y luego al núcleo a medida que más implementaciones admitan estas características. Es decir, la API permite espacio para extensiones personalizadas mientras asegura que sigue el estándar.

El proyecto Service Mesh Interface (SMI) fue un intento similar de estandarizar la configuración de mallas de servicios en Kubernetes. Sin embargo, el proyecto recibió poca tracción después de la participación inicial de los proyectos de malla de servicios y lentamente se desvaneció.

SMI no admitía muchas características comunes que los usuarios esperaban en una malla de servicios. Tampoco avanzó lo suficientemente rápido para admitir estas características. Finalmente, las implementaciones de mallas de servicios se quedaron atrás en la conformidad con SMI (trabajé estrechamente con SMI bajo el CNCF TAG Network en un proyecto que informaba sobre la conformidad de SMI).

Estas son razones universales, pero el proyecto ahora está siendo resucitado a través de la API de Gateway. La iniciativa Gateway API for Mesh Management and Administration (GAMMA) tiene como objetivo extender la API de Gateway para trabajar con mallas de servicios.

El proyecto SMI recientemente se fusionó con la iniciativa GAMMA, lo cual es excelente para la API de Gateway. Istio, sin duda la malla de servicios más popular, también anunció que la API de Gateway será la API predeterminada para gestionar Istio en el futuro. Tales adopciones previenen la proliferación.

Guía de migración

La documentación de la API de Gateway tiene una guía completa sobre cómo migrar tus recursos de Ingress a recursos de Gateway. En lugar de repetirla, intentemos usar la herramienta ingress2gateway para convertir nuestros recursos de Ingress en recursos correspondientes de la API de Gateway.

Puedes descargar e instalar el binario para tu sistema operativo directamente desde la página de lanzamientos.

Tomemos un recurso de Ingress simple:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

Esto enrutará todo el tráfico con la dirección de host proporcionada al servicio httpbin.

Para convertirlo en un recurso de la API de Gateway, podemos ejecutar:

ingress2gateway print --input_file=ingress.yaml

Este recurso de la API de Gateway será como se muestra a continuación:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

Alternativas viables

Existen otras alternativas viables para configurar puertas de enlace en Kubernetes.

En Apache APISIX, puedes implementarlo en modo independiente y definir configuraciones de ruta en un archivo yaml. Puedes actualizar este archivo yaml a través de flujos de trabajo tradicionales, y puede ser bastante útil en escenarios donde no se requiere gestionar la configuración de la puerta de enlace a través de la API de Kubernetes.

Los CRDs específicos de la implementación también son alternativas viables si no planeas cambiar a una solución diferente o si tu configuración es lo suficientemente pequeña como para migrar fácilmente.

En cualquier caso, la API de Gateway está aquí para quedarse.