website/content/es/blog/_posts/2023-08-29-Gateway-API-v080.md

---
layout: blog
title: "Gateway API v0.8.0: Soporte para service mesh"
date: 2023-08-29T10:00:00-08:00
slug: gateway-api-v0-8
---

***Autores:*** Flynn (Buoyant), John Howard (Google), Keith Mattix
(Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott
(Google). Traducción desde [el inglés][english] (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][status]. ¡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][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][geps] 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][mesh-routing] 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í:

```yaml
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][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][issue 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][supported-versions]. 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][v0.8.0 release notes].

## 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][impl]
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][concepts]. Además, las
[Guías][guides] 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][status], están disponibles en el
[canal `standard`][ch], porque la iniciativa GAMMA no ha necesito agregar
nuevos recursos o campos hasta ahora.

[gamma]:https://gateway-api.sigs.k8s.io/concepts/gamma/
[status]:https://gateway-api.sigs.k8s.io/geps/overview/#status
[ch]:https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels-eg-experimental-standard
[cel]:/docs/reference/using-api/cel/
[crd]:/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
[concepts]:https://gateway-api.sigs.k8s.io/concepts/api-overview/
[geps]:https://gateway-api.sigs.k8s.io/contributing/enhancement-requests/
[guides]:https://gateway-api.sigs.k8s.io/guides/getting-started/
[impl]:https://gateway-api.sigs.k8s.io/implementations/
[install-crds]:https://gateway-api.sigs.k8s.io/guides/getting-started/#install-the-crds
[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose
[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions
[community]:https://gateway-api.sigs.k8s.io/contributing/community/
[mesh-routing]:https://gateway-api.sigs.k8s.io/concepts/gamma/#how-the-gateway-api-works-for-service-mesh
[GEP-1426]:https://gateway-api.sigs.k8s.io/geps/gep-1426/
[GEP-1324]:https://gateway-api.sigs.k8s.io/geps/gep-1324/
[GEP-1686]:https://gateway-api.sigs.k8s.io/geps/gep-1686/
[GEP-1709]:https://gateway-api.sigs.k8s.io/geps/gep-1709/
[issue 2277]:https://github.com/kubernetes-sigs/gateway-api/issues/2277
[supported-versions]:https://gateway-api.sigs.k8s.io/concepts/versioning/#supported-versions
[v0.8.0 release notes]:https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.0
[versioning docs]:https://gateway-api.sigs.k8s.io/concepts/versioning/
[english]:/blog/2023/08/29/gateway-api-v0-8/