Más sugerencias desde Dani, gracias!

Signed-off-by: [email protected]

Author: kflynn

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

@@ -25,26 +25,26 @@ Aunque el foco inicial de Gateway API siempre fue el tráfico de entrada al
 cluster (north-south), 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 (east-west). En 2022, el subproyecto Gateway API lanzó [la
-iniciativa GAMMA][gamma], un flujo de trabajo independiente de proveedores,
-para examinar la manera mejor de adaptar el soporte de service mesh al marco
-de los recursos de Gateway API, sin necesitar que los usuarios de Gateway API
-tuvieran que aprender de nuevo todo lo que sepan sobre la API.
+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 la Gateway API para service mesh. El resultado
-final es unos pocos de [propuestas de mejora][geps] que reflejan muchas horas
+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 la service mesh.
+para permitir que Gateway API soporte service mesh.
 
-### ¿Cómo funcionará el enrutamiento de mesh con la Gateway API?
+### ¿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 [GEP-1426], pero en resumen: en Gateway API
-v0.8.0, un HTTPRoute puede tener un `parentRef` que es un Service, no solo un
+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 este á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 permanecen difíciles de manejar.
+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í:
 
@@ -74,10 +74,10 @@ spec:
 ```
 
 Cualquier solicitud al puerto 5000 del Service `demo-app` que tenga la
-cabecera `env: v1` se dirigirá a `demo-app-v1`, y los que no la tengan se
-dirigirá a `demo-app-v2`. Dado que esta decisión está tomando por 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.
+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?
 
@@ -94,12 +94,12 @@ 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+ están completamente
-conformes con el perfil `Mesh`.
+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?
 
-Versión v0.8.0 se trata principalmente de preparar Gateway API para versión
+Versión v0.8.0 trata principalmente de preparar Gateway API para 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.
@@ -142,11 +142,11 @@ soportados por Gateway API, y la versión v0.8.0 no se puede instalar en ellas
 
 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 han
-graduado desde la versión v1alpha1 a v1beta1. Para más información, consulta a
+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 a la versión v0.8.0][v0.8.0 release notes].
 
-## Cómo empezar con la Gateway API
+## 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]