Kubernetes Gateway API v1.1: Service mesh, GRPCRoute y mucho más

Español Kubernetes Microservicios News Open Source Selected content SRE

Author: Nicolás Georger | Published on 14 May 2024

Después del lanzamiento GA de Gateway API el pasado octubre, Kubernetes SIG Network anuncia el lanzamiento de la versión v1.1 de Gateway API. En este lanzamiento, varias características pasan a formar parte del Canal Estándar (GA), incluyendo el soporte para service mesh y GRPCRoute. También introducen algunas características nuevas y experimentales, como persistencia de sesión y verificación de certificados de cliente.

Novedades

Paso al Canal Estándar

Este lanzamiento incluye el paso al Canal Estándar de cuatro características muy esperadas. Esto significa que ya no son conceptos experimentales; la inclusión en el Canal Estándar denota un alto nivel de confianza en la API y proporciona garantías de compatibilidad. Por supuesto, como con cualquier otra API de Kubernetes, las características del Canal Estándar pueden seguir evolucionando con adiciones retrocompatibles y ciertamente vendrán más refinamientos y mejoras a estas nuevas características en el futuro. Para más información sobre cómo funciona todo esto, consulta la Política de Versiones de Gateway API.

Versioning - Kubernetes Gateway API

logo

Soporte para Service Mesh

El soporte para service mesh en Gateway API permite a los usuarios utilizar la misma API para gestionar el tráfico de entrada y el tráfico de malla, reutilizando las mismas interfaces de política y enrutamiento. En Gateway API v1.1, las rutas (como HTTPRoute) ahora pueden tener un Servicio como parentRef, para controlar cómo se comporta el tráfico a servicios específicos. Para más información, lee la documentación de service mesh de Gateway API o consulta la lista de implementaciones de Gateway API.

Como ejemplo, se podría hacer un despliegue Canary de una carga de trabajo (workload) con un HTTPRoute de la siguiente manera:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

Esto dividiría el tráfico enviado al Servicio color en el namespace faces 50/50 entre el Servicio color original y el Servicio color2, utilizando una configuración portátil que es fácil de mover de una malla a otra.

GRPCRoute

Si ya estás utilizando la versión experimental de GRPCRoute, te recomendamos esperar antes de actualizar a la versión del canal estándar de GRPCRoute hasta que los controladores que estés utilizando hayan sido actualizados para soportar la versión v1 de GRPCRoute. Hasta entonces, es seguro actualizar a la versión experimental de GRPCRoute en v1.1 que incluye las versiones de API v1alpha2 y v1.

Puerto en ParentReference

Se agregó el campo port a ParentReference, lo que permite adjuntar recursos a los GatewayListeners, Servicios u otros recursos principales (dependiendo de la implementación). Vincular a un puerto también permite adjuntar a múltiples Listeners a la vez.

Por ejemplo, puedes adjuntar un HTTPRoute a uno o más Listeners específicos de un Gateway según el campo port del Listener, en lugar del campo name del Listener.

Para más información, consulta Attach to Gateways.

HTTPRoute - Kubernetes Gateway API

logo

Perfiles y Reportes Conformance

La API Conformance se ha ampliado con el campo mode (destinado a especificar el modo de la implementación) y el gatewayAPIChannel (estándar o experimental). Tanto gatewayAPIVersion como gatewayAPIChannel ahora se rellenan automáticamente por la API Machinery, junto con una breve descripción del resultado de las pruebas. Los Reportes se han reorganizado de una manera más estructurada, y las implementaciones ahora pueden agregar información sobre cómo se han ejecutado las pruebas y proporcionar pasos de reproducción.

Nuevas características en el Canal Experimental

Verificación de Certificados de Cliente en Gateway

Los Gateways ahora pueden configurar la verificación de certificados de cliente para cada GatewayListener, mediante la introducción de un nuevo campo frontendValidation dentro de tls. Este campo admite la configuración de una lista de Certificados CA (Certificate Authority) que pueden utilizarse como un punto de confianza para validar los certificados presentados por el cliente.

✅ Ejemplo de validación de certificado de cliente en API Gateway:
Cómo un CACertificate almacenado en el ConfigMap foo-example-com-ca-cert se puede utilizar para validar los certificados presentados por los clientes que se conectan al Listener del Gateway foo-https.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

Persistencia de Sesión y BackendLBPolicy

Persistencia de Sesión se está introduciendo en Gateway API a través de una nueva política (BackendLBPolicy) para la configuración a nivel de Servicio y como campos dentro de HTTPRoute y GRPCRoute para la configuración a nivel de ruta. BackendLBPolicy y las API a nivel de ruta proporcionan la misma configuración de persistencia de sesión, incluyendo tiempos de espera, nombre de sesión, tipo de sesión y tiempo de vida de cookies.

✅ Ejemplo de BackendLBPolicycon persistencia de sesión basada en cookies para el servicio foo:
Establece el nombre de sesión en foo-session, define tiempos de espera (timeouts), y configura cookies como sesión:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

Más detalles y extras

Aclaraciones de Terminología TLS

Como parte de un objetivo más amplio de hacer que la terminología sobre TLS sea más coherente en toda la API, se han algunos cambios que rompen la compatibilidad en BackendTLSPolicy. Esto ha dado lugar a una nueva versión de API (v1alpha3) y requerirá que cualquier implementación existente de esta política maneje adecuadamente la actualización de versión, por ejemplo, haciendo una copia de seguridad de los datos y desinstalando la versión v1alpha2 antes de instalar esta nueva versión.

Cualquier referencia a los campos de BackendTLSPolicy v1alpha2 deberá actualizarse a v1alpha3. Los cambios específicos en los campos incluyen:

targetRef se convierte en targetRefs para permitir que un BackendTLSPolicy se adjunte a múltiples objetivos
tls se convierte en validation
tls.caCertRefs se convierte en validation.caCertificateRefs
tls.wellKnownCACerts se convierte en validation.wellKnownCACertificates

Para obtener una lista completa de los cambios incluidos en este lanzamiento, consulta las notas de lanzamiento de v1.1.0.

Desarrollo de API Gateway

La idea de Gateway API se propuso inicialmente en KubeCon San Diego 2019 como la próxima generación de la API Ingress. Desde entonces, se ha formado una increíble comunidad para desarrollar lo que probablemente se haya convertido en la API más colaborativa en la historia de Kubernetes. Más de 200 personas han contribuido a esta API hasta ahora, y ese número sigue creciendo.

Los mantenedores quieren agradecer a todos los que han contribuido a Gateway API, ya sea en forma de commits al repositorio, discusiones, ideas o apoyo general. Literalmente no habríamos llegado tan lejos sin el apoyo de esta comunidad dedicada y activa.

¿Cómo utilizar y probar Kubernetes API Gateway fácil?

A diferencia de otras APIs de Kubernetes, no necesitas actualizar a la última versión de Kubernetes para obtener la última versión de Gateway API. Siempre que estés ejecutando Kubernetes 1.26 o posterior, podrás ponerte en marcha con esta versión de Gateway API.

Para probar la API, sigue la Guía de Inicio Rápido:

Getting started - Kubernetes Gateway API

logo

Participa

Hay muchas oportunidades para participar y ayudar a definir el futuro de las APIs de Kubernetes, tanto para ingress como para service mesh.

Revisa las guías de usuario para ver qué casos de uso se pueden abordar.
Prueba uno de los controladores de Gateway existentes (Recientemente publicamos sobre Traefik v3, que tiene soporte para APIGateway)

O únete a la comunidad y colabora a construir el futuro de Kubernetes.

Fuente:

Gateway API v1.1: Service mesh, GRPCRoute, and a whole lot more

Following the GA release of Gateway API last October, Kubernetes SIG Network is pleased to announce the v1.1 release of Gateway API. In this release, several features are graduating to Standard Channel (GA), notably including support for service mesh and GRPCRoute. We’re also introducing some new experimental features, including session persistence and client certificate verification. What’s new Graduation to Standard This release includes the graduation to Standard of four eagerly awaited features.

Kubernetes

Nicolás Georger

Self-taught IT professional driving innovation & social impact with cybernetics, open source (Linux, Kubernetes), AI & ML. Building a thriving SRE/DevOps community at SREDevOps.org. I specialize in simplifying solutions through cloud native technologies and DevOps practices.

Website Twitter Facebook Email Chile