Comparación de las APIs Kubernetes Gateway e Ingress

Hace un par de meses, la nueva API de Gateway de Kubernetes alcanzó la fase beta.

¿Por qué necesitas otra API para manejar el tráfico externo cuando ya tienes la estable API de Ingress de Kubernetes y docenas de implementaciones? ¿Qué problemas de la API de Ingress resuelve la nueva API de Gateway? ¿Significa esto el fin de la API de Ingress?

Intentaré responder estas preguntas en este artículo, trabajando directamente con estas APIs y observando cómo han evolucionado.

Estandarizando el Acceso Externo a los Servicios: La API de Ingress

La API de Ingress de Kubernetes se creó para estandarizar la exposición de servicios en Kubernetes al tráfico externo. La API de Ingress superó las limitaciones de los tipos de servicios predeterminados, NodePort y LoadBalancer, al introducir características como enrutamiento y terminación SSL.

Existen más de 20 implementaciones de controladores de Ingress disponibles. En este artículo, usaré Apache APISIX y su controlador de Ingress para los ejemplos.

Puedes crear un recurso de Ingress para configurar APISIX o cualquier otra implementación de Ingress.

El siguiente ejemplo muestra cómo puedes enrutar el tráfico entre dos versiones de una aplicación con APISIX Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api-v1
                port:
                  number: 8080
            path: /v1
            pathType: Prefix
          - backend:
              service:
                name: bare-minimum-api-v2
                port:
                  number: 8081
            path: /v2
            pathType: Prefix

Consejo: Puedes consultar este tutorial práctico para aprender más sobre cómo configurar Ingress en Kubernetes con el controlador de Ingress de Apache APISIX.

Dado que la API de Ingress no está vinculada a ninguna implementación específica de controlador, puedes intercambiar APISIX con cualquier otro controlador de Ingress, y funcionará de manera similar.

Esto está bien para enrutamientos simples. Pero la API es limitada, y si deseas utilizar todas las funciones proporcionadas por tu controlador de Ingress, te quedas con anotaciones.

Por ejemplo, la API de Ingress de Kubernetes no proporciona un esquema para configurar reescrituras. Las reescrituras son útiles cuando la URL de tu upstream/backend difiere de la ruta configurada en tu regla de Ingress.

APISIX soporta esta característica, y debes usar anotaciones personalizadas para aprovecharla:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
  annotations:
    k8s.apisix.apache.org/rewrite-target-regex: "/app/(.*)"
    k8s.apisix.apache.org/rewrite-target-regex-template: "/$1"
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api
                port:
                  number: 8080
            path: /app
            pathType: Prefix

Esto crea un recurso de Ingress que configura APISIX para enrutar cualquier solicitud con el prefijo /app al backend con el prefijo eliminado. Por ejemplo, una solicitud a /app/version será reenviada a /version.

Las anotaciones son específicas de tu elección de un controlador de Ingress. Estas extensiones "propietarias" limitaron el alcance de la portabilidad que se pretendía inicialmente con la API de Ingress.

CRDs Personalizados > API de Ingress

Quedarse atrapado con anotaciones también sacrifica la usabilidad de los controladores de Ingress.

Por lo tanto, los controladores resolvieron las limitaciones de la API de Ingress creando sus propios recursos personalizados. El siguiente ejemplo muestra cómo configurar Ingress para enrutar el tráfico entre dos versiones de una aplicación usando el recurso personalizado de APISIX:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: api-routes
spec:
  http:
    - name: route-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v1
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
    - name: route-2
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v2
      backends:
        - serviceName: bare-minimum-api-v2
          servicePort: 8081

Estos CRDs hicieron mucho más fácil configurar Ingress, pero estás atado a la implementación específica del controlador de Ingress. Sin que la API de Ingress evolucionara, tenías que elegir entre usabilidad o portabilidad.

Extendiendo Ingress y la Evolución a la API de Gateway

La API de Ingress no estaba rota; era limitada. La API de Gateway fue diseñada para superar estas limitaciones.

(API de Gateway) tiene como objetivo evolucionar la red de servicios de Kubernetes a través de interfaces expresivas, extensibles y orientadas a roles ...

Toma inspiración de los CRDs personalizados de diferentes controladores de Ingress mencionados anteriormente.

La API de Gateway agrega muchas características "sobre" las capacidades de la API de Ingress. Esto incluye coincidencia basada en encabezados HTTP, división de tráfico ponderada y otras características que requieren anotaciones personalizadas y propietarias con la API de Ingress.

División de tráfico con el recurso de Ingress de APISIX (ver referencia de ApisixRoute/v2):

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: traffic-split
spec:
  http:
    - name: rule-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /get*
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
          weight: 90
        - serviceName: bare-minimum-api-v2
          servicePort: 8081
          weight: 10

División de tráfico con la API de Gateway (ver Canary traffic rollout):

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: traffic-split
spec:
  hostnames:
  - local.navendu.me
  rules:
  - backendRefs:
    - name: bare-minimum-api-v1
      port: 8080
      weight: 90
    - name: bare-minimum-api-v2
      port: 8081
      weight: 10

Otra mejora de la API de Ingress es cómo la API de Gateway separa las preocupaciones. Con Ingress, el desarrollador de la aplicación y el operador del clúster trabajan en el mismo objeto de Ingress, sin ser conscientes de las responsabilidades del otro, lo que abre la puerta a configuraciones incorrectas.

La API de Gateway separa las configuraciones en objetos Route y Gateway, proporcionando autonomía tanto para el desarrollador de la aplicación como para el operador del clúster. El siguiente diagrama lo explica claramente:

¿Es Este el Fin de la API de Ingress?

La API de Gateway es relativamente nueva, y sus implementaciones están en constante cambio. Por el contrario, la API de Ingress está en una versión estable y ha resistido la prueba del tiempo.

Si tu caso de uso solo implica enrutamiento simple y si estás de acuerdo con usar anotaciones personalizadas para obtener características adicionales, la API de Ingress sigue siendo una opción sólida.

Dado que la API de Gateway es un superconjunto de la API de Ingress, podría tener sentido consolidar ambas. Gracias a la comunidad de SIG Network, la API de Gateway sigue creciendo y pronto estará lista para producción.

La mayoría de los controladores de Ingress y mallas de servicio ya han implementado la API de Gateway junto con la API de Ingress, y a medida que el proyecto evoluciona, surgirán más implementaciones.

Personalmente, al menos por ahora, me quedaría con los CRDs personalizados proporcionados por los controladores de Ingress como Apache APISIX en lugar de la API de Ingress o Gateway.