Gateway API v0.8.0: Soporte para service mesh

Autores: Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott (Google). Traducción desde el inglés (y errores relacionados) por Flynn.

¡Mil gracias a María Teresa Rojas y Dani Baeyens por su inestimable ayuda revisando este post!

Es un gran placer anunciar la versión v0.8.0 de Gateway API. Con esta versión, el soporte para service mesh en Gateway API ha alcanzado el estado Experimental. ¡Esperamos tus comentarios en la nueva versión!

Además, nos alegra anunciar que Kuma 2.3+, Linkerd 2.14+ e Istio 1.16+ cumplen completamente con el soporte de service mesh de Gateway API.

Nota: "Gateway API" es un nombre propio de esta API.

Soporte para service mesh en Gateway API

Aunque el foco inicial de Gateway API siempre fue el tráfico de entrada al cluster (norte-sur), estaba claro casi desde el principio que los mismos conceptos básicos de enrutamiento también deberían aplicarse al tráfico de service mesh (este-oeste). En 2022, el subproyecto Gateway API lanzó la iniciativa GAMMA, un flujo de trabajo independiente a los distintos proveedores, para examinar la mejor manera de adaptar el soporte de service mesh al marco de los recursos de Gateway API, sin hacer que los usuarios de Gateway API tuvieran que aprender de nuevo todo lo aprendido.

Durante el último año, GAMMA ha investigado con cuidado los desafíos y posibles soluciones para usar Gateway API para service mesh. El resultado final son unas pocas propuestas de mejora que reflejan muchas horas de reflexión y debate, y proporcionan un camino viable, con cambios mínimos, para permitir que Gateway API soporte service mesh.

¿Cómo funcionará el enrutamiento de mesh con Gateway API?

Todos los detalles se puede encontrar en la documentación de la mesh de Gateway API y en GEP-1426, pero en resumen: en Gateway API v0.8.0, un HTTPRoute puede tener un parentRef que sea un Service, no solo un Gateway. Anticipamos GEPs futuros en esta área a medida que adquirimos más experiencia con los casos de uso de service mesh: la capacidad de asociar un HTTPRoute con un Service permite usar Gateway API para una service mesh, pero hay múltiples casos de uso interesantes que son difíciles de manejar.

Un ejemplo: podrías usar un HTTPRoute para hacer una prueba A-B con la service mesh así:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: bar-route
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: demo-app
    port: 5000
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: v1
    backendRefs:
    - name: demo-app-v1
      port: 5000
  - backendRefs:
    - name: demo-app-v2
      port: 5000

Cualquier solicitud al puerto 5000 del Service demo-app que tenga la cabecera env: v1 se dirigirá a demo-app-v1, y las que no la tengan se dirigirán a demo-app-v2. Dado que esta decisión la toma la service mesh en vez del controlador de ingress, la prueba A-B se puede realizar en cualquier nivel del gráfico de llamadas de la aplicación.

¿Cómo se puede confiar que este soporte será verdaderamente portátil?

Gateway API ha invertido mucho esfuerzo en pruebas de conformidad en todas las funciones que soporta, y las de la service mesh no son excepciones. Uno de los desafíos que enfrentó la iniciativa GAMMA fue que muchas de estas pruebas siempre han requerido que la implementación proporcionara un controlador de ingress. Muchas service meshes no hacen así, y requerir que una mesh implemente un controlador de ingress para cumplir con GAMMA no parece práctico, cuando menos. Por lo tanto, hemos reiniciado el trabajo en perfiles de conformidad de Gateway API, como se describe en GEP-1709.

Con perfiles de conformidad, podemos definir subconjuntos de la funcionalidad de Gateway API, y permitir que las implementaciones elijan (y documenten) a qué subconjuntos se ajustan. GAMMA agrega un nuevo perfil Mesh, descrito en GEP-1686, que sólo verifica la funcionalidad de service mesh definida por GAMMA. Ahora mismo, Kuma 2.3+, Linkerd 2.14+ e Istio 1.16+ son completamente compatibles con el perfil Mesh.

¿Qué más hay en Gateway API v0.8.0?

Ésta versión trata principalmente de preparar Gateway API para la versión v.1.0, en la que planeamos que HTTPRoute, Gateway y GatewayClass se graduarán a GA. Hay dos cambios principales relacionados con esta preparación: validación CEL y cambios en la versión de la API.

Validación CEL

Gateway API v0.8.0 comienza la transición desde validación por webhook hasta validación CEL, usando información incluida en los CRDs. Esta transición significa cosas diferentes dependiendo de la versión de Kubernetes que se use:

Kubernetes 1.25+

La validación CEL está completamente soportada, y casi toda la validación de Gateway API está implementada en CEL. La única excepción es que, en los filtros de modificación de cabeceras, CEL solo puede validar los nombres de las cabeceras sin distinguir entre mayúsculas y minúsculas. Hay más información en #2277.

Recomendamos que no uses el webhook de validación en estas versiones de Kubernetes.

Kubernetes 1.23 y 1.24

La validación CEL no está soportada, pero aún se puede instalar los CRDs de Gateway API v0.8.0. Cuando actualices a Kubernetes 1.25+, la validación CEL incluida en los CRDs se activará automáticamente.

Recomendamos que sigas usando el webhook de validación en estas versiones de Kubernetes.

Kubernetes 1.22 y versiones anteriores

Gateway API solo se compromete a admitir las cinco versiones más recientes de Kubernetes. Por lo tanto, estas versiones ya no están soportados por Gateway API, y la versión v0.8.0 no se puede instalar en ellas (porque los CRDs que contengan validación CEL serán rechazados).

Cambios en la versión de la API

En la versión de Gateway API v1.0, se graduarán los recursos Gateway, GatewayClass y HTTPRoute a la versión de API v1 desde v1beta1. Como preparación, seguimos actualizando las versiones de los recursos que se han graduado desde la versión v1alpha1 a v1beta1. Para más información, consulta las notas de lanzamiento de la versión v0.8.0.

Cómo empezar con Gateway API

Gateway API representa el futuro de las APIs de load balancing, enrutamiento y service mesh en Kubernetes. Ya hay mas que 20 implementaciones disponibles (incluidos controlodores de ingress y service meshes) y este número siempre está creciendo.

Si tienes interés en Gateway API, te recomendamos empezar con la documentación oficial sobre conceptos de la API. Además, las Guías cubren la instalación y configuración de Gateway API, y demuestran cómo usar Gateway API para lograr varios casos de uso comunes. Dado que esta API se basa en CRDs, puedes instalar la última versión en cualquier cluster de Kubernetes 1.23+.

Si tienes ganas de contribuir a Gateway API, ¡nos alegra saberlo! Por favor no tengas dudas en crear un nuevo issue en nuestro repositorio de GitHub o unirte a las discusiones. Además puedes consultar la página de la comunidad, que tiene enlaces a Slack e información sobre nuestras reuniones comunitarias cada dos semanas.

Gracias por tu continuo apoyo y comentarios sobre Gateway API. Estamos emocionados de ver cómo usas esta API en producción y esperamos escuchar sobre tus experiencias.

Leer más

• GEP-1324 proporciona una descripción general de los objetivos de GAMMA y algunas definiciones importantes. Leer este GEP vale la pena por su tratamiento del espacio del problema.
• GEP-1426 define cómo usar Gateway API recursos de enrutamiento (p.e. HTTPRoute) para manejar tráfico en una service mesh.
• GEP-1686 se basa en el trabajo del GEP-1709 y define un perfil de conformidad para que una service mesh se declare conforme con Gateway API.

Aunque estos patrones están en Experimental, están disponibles en el canal standard, porque la iniciativa GAMMA no ha necesito agregar nuevos recursos o campos hasta ahora.

• ←Previo
Siguiente→