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.

Versioning - Kubernetes 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.

Traefik v3.0 ya está disponible e incluye soporte para Kubernetes Gateway API, WebAssembly y más. Aquí puedes ver cómo actualizar a v3.0
Este año se cumple el noveno aniversario de Traefik y hoy se convirtió en uno de los gateways modernos más utilizados, con más de 3 mil millones de descargas y más de 750 colaboradores. Está en el Top 15 de DockerHub y tiene 47.000 estrellas en GitHub. Aquí en

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

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
Manage TLS Certificates in a Cluster
Kubernetes provides a certificates.k8s.io API, which lets you provision TLS certificates signed by a Certificate Authority (CA) that you control. These CA and certificates can be used by your workloads to establish trust. certificates.k8s.io API uses a protocol that is similar to the ACME draft. Note:Certificates created using the certificates.k8s.io API are signed by a dedicated CA. It is possible to configure your cluster to use the cluster root CA for this purpose, but you should never rely on this.

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

Participa

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

Traefik v3.0 ya está disponible e incluye soporte para Kubernetes Gateway API, WebAssembly y más. Aquí puedes ver cómo actualizar a v3.0
Este año se cumple el noveno aniversario de Traefik y hoy se convirtió en uno de los gateways modernos más utilizados, con más de 3 mil millones de descargas y más de 750 colaboradores. Está en el Top 15 de DockerHub y tiene 47.000 estrellas en GitHub. Aquí en

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.

Comment using your social account:

You will be asked to grant read-only access to your public profile and email address only to verify your identity. We will never post to your account. Select your preferred social account to get started.
Service provided by Spectral Web Services.

  |

Read interesting articles in SREDevOps.org:

Whonix: An Operating System for DevSecOps, Researchers and Paranoids like you and me

Whonix: An Operating System for DevSecOps, Researchers and Paranoids like you and me

Ah, privacy. That mythical beast we all chase in this digital jungle. You think incognito mode is enough? Honey, please. Your ISP knows what you had for breakfast, and they're judging. But fear not, my friend, for there's a solution for the truly paranoid: Whonix. Whonix

DevOps Paradox: OpenTelemetry meets Mobile

DevOps Paradox: OpenTelemetry meets Mobile

OpenTelemetry is transforming the landscape of mobile app observability, providing developers with powerful tools to monitor, understand, and optimize their applications. Embrace, with its open-source SDKs and commitment to community involvement, is at the forefront of this exciting evolution. This episode of DevOps Paradox features Austin Alexander from Embrace (https:

How to fix the Critical 9.9 CVE Linux Vulnerability in CUPS: A Step-by-Step Guide

How to fix the Critical 9.9 CVE Linux Vulnerability in CUPS: A Step-by-Step Guide

Oh No! Not My Printers! Exploiting CUPS on Linux: A How-to Guide (Just Kidding, Please Patch Your Systems) Remember those carefree days when the most terrifying thing about printers was running out of ink at 3 AM just before a big deadline? Yeah, me neither. But hold onto your coffee

Linux could be facing a critical RCE vulnerability, scoring 9.9 (CVE): Let's separate hype, security, facts, and developer drama

Linux could be facing a critical RCE vulnerability, scoring 9.9 (CVE): Let's separate hype, security, facts, and developer drama

The Linux community is abuzz with news of a potential Remote Code Execution (RCE) vulnerability, sending chills down the spines of sysadmins and prompting frantic security checks. But hold on to your penguins, because things are a bit more complicated than they appear. UPDATE 29-09-2024: How to fix the Critical