Kubernetes Gateway API v1.1: Service mesh, GRPCRoute y mucho más
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.
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.
Nicolás Georger
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: 50Esto 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.
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.
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.
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:
targetRefse convierte entargetRefspara permitir que un BackendTLSPolicy se adjunte a múltiples objetivostlsse convierte envalidationtls.caCertRefsse convierte envalidation.caCertificateRefstls.wellKnownCACertsse convierte envalidation.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:
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)
Nicolás Georger- O únete a la comunidad y colabora a construir el futuro de Kubernetes.
Fuente:
Comment using your social account:
We will redirect you to our SREDevOps.org - OAuth2 in GitHub. You will be prompted to grant read-only access to your public profile and email address.