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
Imagen original: https://dev.to/aws-builders/securing-kubernetes-api-server-adding-a-new-hostname-or-ip-address-to-kubernetes-api-server-1aej
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.
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.
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.
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.
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.
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.
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.
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 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: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
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 objetivostls se convierte en validationtls.caCertRefs se convierte en validation.caCertificateRefstls.wellKnownCACerts se convierte en validation.wellKnownCACertificatesPara obtener una lista completa de los cambios incluidos en este lanzamiento, consulta las notas de lanzamiento de v1.1.0.
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.
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.
Hay muchas oportunidades para participar y ayudar a definir el futuro de las APIs de Kubernetes, tanto para ingress como para service mesh.
Nicolás GeorgerFuente:
Si tu panorama ideal incluye debatir si Kubernetes es supuestamente un sistema operativo, torturarte gratuitamente por la tabs de un YAML modo sábana o darse apoyo moral comunitario por todas las caídas en producción a las 4 AM... te tenemos mansa noticia weón
La diferencia con el software se resumía en una frase que muchos repetíamos con una sonrisa: "El hardware se puede patear; el software, solo maldecir."
