diff --git a/content/es/about/case-studies/fico/index.md b/content/es/about/case-studies/fico/index.md
index 3537b9c3303ac..1ef38c6ddd37a 100644
--- a/content/es/about/case-studies/fico/index.md
+++ b/content/es/about/case-studies/fico/index.md
@@ -18,6 +18,6 @@ type: case-studies
weight: 70
---
-FICO comenzó su viaje con la malla en 2019, adoptando Istio en la versión 0.8. Istio ha madurado mucho en ese tiempo, y la implementación y el uso de Istio por parte de la organización también han madurado significativamente. En [esta presentación de IstioCon 2021](https://events.istio.io/istiocon-2021/sessions/fico-istio-journey/), Jeet Kaul, vicepresidente de ingeniería de FICO, recorrió el viaje de FICO con Istio desde 2019 hasta hoy, discutiendo por qué eligieron Istio inicialmente, algunos de los dolores de crecimiento que experimentaron y qué objetivos comerciales han podido lograr gracias a Istio.
+FICO comenzó su viaje con la mesh en 2019, adoptando Istio en la versión 0.8. Istio ha madurado mucho en ese tiempo, y la implementación y el uso de Istio por parte de la organización también han madurado significativamente. En [esta presentación de IstioCon 2021](https://events.istio.io/istiocon-2021/sessions/fico-istio-journey/), Jeet Kaul, vicepresidente de ingeniería de FICO, recorrió el viaje de FICO con Istio desde 2019 hasta hoy, discutiendo por qué eligieron Istio inicialmente, algunos de los dolores de crecimiento que experimentaron y qué objetivos comerciales han podido lograr gracias a Istio.
diff --git a/content/es/about/deployment/index.md b/content/es/about/deployment/index.md
index d4077a8a7f52a..43d3cd5b5c538 100644
--- a/content/es/about/deployment/index.md
+++ b/content/es/about/deployment/index.md
@@ -41,7 +41,7 @@ Existen muchas buenas razones para adoptar Istio: desde agregar seguridad a sus
Introduzca gradualmente sus servicios en la service mesh labeling un namespace a la vez. Por defecto, los servicios en múltiples namespaces pueden comunicarse entre sí, pero puede aumentar el aislamiento seleccionando cuáles exponer a otros namespaces. El uso de namespaces también mejora el rendimiento ya que las configuraciones están limitadas.
-Istio es flexible para adaptarse a la configuración de su cluster de Kubernetes y a la arquitectura de red. Puede optar por ejecutar múltiples mallas con planos de control independientes o tener uno solo.
+Istio es flexible para adaptarse a la configuración de su clúster de Kubernetes y a la arquitectura de red. Puede optar por ejecutar múltiples mesh con planos de control independientes o tener uno solo.
Mientras los pods puedan conectarse a la red, Istio funcionará; incluso puede configurar gateways de Istio para que actúen como un host bastión entre diferentes redes.
@@ -63,7 +63,7 @@ Lea más sobre [cómo habilitar aplicaciones para que las utilice Istio](/es/doc
### Habilitar seguridad
-Istio configurará los servicios en su malla para usar mTLS cuando sea posible. Por defecto, Istio se ejecutará en modo "mTLS permisivo", lo que significa que los servicios aceptarán tanto tráfico cifrado como no cifrado; esto permite mantener la funcionalidad del tráfico entre servicios fuera de la malla temporalmente. Una vez que todos sus servicios estén integrados en la malla, podrá [cambiar la política de autenticación](/es/docs/tasks/security/authentication/mtls-migration/) para permitir solo tráfico seguro (TLS).
+Istio configurará los servicios en su mesh para usar mTLS cuando sea posible. Por defecto, Istio se ejecutará en modo "mTLS permisivo", lo que significa que los servicios aceptarán tanto tráfico cifrado como no cifrado; esto permite mantener la funcionalidad del tráfico entre servicios fuera de la mesh temporalmente. Una vez que todos sus servicios estén integrados en la mesh, podrá [cambiar la política de autenticación](/es/docs/tasks/security/authentication/mtls-migration/) para permitir solo tráfico seguro (TLS).
### Las dos API de Istio
@@ -75,13 +75,13 @@ Istio no es solo para Kubernetes; también puede [añadir servicios en máquinas
## Monitorizar sus servicios
-Explore el tráfico que fluye por su malla usando [Kiali](/es/docs/ops/integrations/kiali/) o haga un seguimiento de las solicitudes con [Zipkin](/es/docs/tasks/observability/distributed-tracing/zipkin/) o [Jaeger](/es/docs/tasks/observability/distributed-tracing/jaeger/).
+Explore el tráfico que fluye por su mesh usando [Kiali](/docs/ops/integrations/kiali/) o haga un seguimiento de las solicitudes con [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/) o [Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/).
-Use los paneles predeterminados de [Grafana](/es/docs/ops/integrations/grafana/) para Istio y obtenga informes automáticos de señales doradas para los servicios que se ejecutan en una malla.
+Use los paneles predeterminados de [Grafana](/es/docs/ops/integrations/grafana/) para Istio y obtenga informes automáticos de señales doradas para los servicios que se ejecutan en un mesh.
## Consideraciones operativas y Día 2
-Como propietario de la plataforma, usted es responsable de instalar y mantener la malla actualizada con poco impacto en los equipos de servicios.
+Como propietario de la plataforma, usted es responsable de instalar y mantener la mesh actualizado con poco impacto en los equipos de servicios.
### Instalación
@@ -91,11 +91,11 @@ Con istioctl, puede instalar Istio fácilmente utilizando uno de los perfiles in
Cuando se lanza una nueva versión, Istio permite tanto actualizaciones in-place como canary. Elegir entre ambos implica una compensación entre la simplicidad y el posible tiempo de inactividad. Para entornos de producción, se recomienda utilizar el [método de actualización canary](/es/docs/setup/upgrade/canary/). Después de verificar que las nuevas versiones del control plane y del data plane funcionan correctamente, puede actualizar sus gateways.
-### Supervisar la malla
+### Supervisar la mesh
-Istio genera telemetría detallada de todas las comunicaciones de servicios dentro de una malla. Estas métricas, trazas y registros de acceso son vitales para comprender cómo interactúan sus aplicaciones entre sí e identificar posibles cuellos de botella en el rendimiento. Utilice esta información para ayudarle a configurar interruptores de circuito, tiempos de espera y reintentos, y fortalecer sus aplicaciones.
+Istio genera telemetría detallada de todas las comunicaciones de servicios dentro de un mesh. Estas métricas, trazas y registros de acceso son vitales para comprender cómo interactúan sus aplicaciones entre sí e identificar posibles cuellos de botella en el rendimiento. Utilice esta información para ayudarle a configurar interruptores de circuito, tiempos de espera y reintentos, y fortalecer sus aplicaciones.
-Al igual que sus aplicaciones que se ejecutan en la malla, los componentes del control plane de Istio también exportan métricas. Aproveche estas métricas y los paneles preconfigurados de Grafana para ajustar sus solicitudes de recursos, límites y escalado.
+Al igual que sus aplicaciones que se ejecutan en la mesh, los componentes del control plane de Istio también exportan métricas. Aproveche estas métricas y los paneles preconfigurados de Grafana para ajustar sus solicitudes de recursos, límites y escalado.
## Únase a la comunidad de Istio
diff --git a/content/es/about/faq/distributed-tracing/how-envoy-based-tracing-works.md b/content/es/about/faq/distributed-tracing/how-envoy-based-tracing-works.md
index 14be476df4b01..48d69bdabddfb 100644
--- a/content/es/about/faq/distributed-tracing/how-envoy-based-tracing-works.md
+++ b/content/es/about/faq/distributed-tracing/how-envoy-based-tracing-works.md
@@ -12,4 +12,4 @@ Envoy:
- envía los tramos de seguimiento generados a los backends de seguimiento
- reenvía las cabeceras de seguimiento a la aplicación representada
-Istio admite [OpenTelemetry](/es/docs/tasks/observability/distributed-tracing/opentelemetry/) y backends compatibles, incluidos [Jaeger](/es/docs/tasks/observability/distributed-tracing/jaeger/). Otras plataformas compatibles incluyen [Zipkin](/es/docs/tasks/observability/distributed-tracing/zipkin/) y [Apache SkyWalking](/es/docs/tasks/observability/distributed-tracing/skywalking/).
+Istio admite [OpenTelemetry](/docs/tasks/observability/distributed-tracing/opentelemetry/) y backends compatibles, incluidos [Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/). Otras plataformas compatibles incluyen [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/) y [Apache SkyWalking](/docs/tasks/observability/distributed-tracing/skywalking/).
diff --git a/content/es/about/faq/distributed-tracing/how-to-support-tracing.md b/content/es/about/faq/distributed-tracing/how-to-support-tracing.md
index f5b257ad3e1b5..c956365c65777 100644
--- a/content/es/about/faq/distributed-tracing/how-to-support-tracing.md
+++ b/content/es/about/faq/distributed-tracing/how-to-support-tracing.md
@@ -3,7 +3,7 @@ title: ¿Qué se requiere para el seguimiento distribuido con Istio?
weight: 10
---
-Istio permite la notificación de tramos de seguimiento para las comunicaciones de workload a workload dentro de una malla. Sin embargo, para que los diversos tramos de seguimiento se unan para obtener una vista completa del flujo de tráfico, las aplicaciones deben propagar el contexto de seguimiento entre las solicitudes entrantes y salientes.
+Istio permite la notificación de tramos de seguimiento para las comunicaciones de workload a workload dentro de un mesh. Sin embargo, para que los diversos tramos de seguimiento se unan para obtener una vista completa del flujo de tráfico, las aplicaciones deben propagar el contexto de seguimiento entre las solicitudes entrantes y salientes.
En particular, Istio se basa en que las aplicaciones reenvíen el ID de solicitud generado por Envoy y las cabeceras estándar. Estas cabeceras incluyen:
diff --git a/content/es/about/faq/general/why-use-istio.md b/content/es/about/faq/general/why-use-istio.md
index 8eb227fa8bdb2..6de1cb80ea2d7 100644
--- a/content/es/about/faq/general/why-use-istio.md
+++ b/content/es/about/faq/general/why-use-istio.md
@@ -7,4 +7,4 @@ Tradicionalmente, gran parte de la lógica gestionada por Istio se ha integrado
*Desarrolladores de aplicaciones*: Con Istio gestionando cómo fluye el tráfico a través de sus servicios, los desarrolladores pueden centrarse exclusivamente en la lógica empresarial e iterar rápidamente en nuevas funciones.
-*Operadores de servicios*: Istio permite la aplicación de políticas y la supervisión de la malla desde un único punto de control centralizado, independientemente de la evolución de la aplicación. Como resultado, los operadores pueden garantizar el cumplimiento continuo de las políticas a través de un plano de gestión simplificado.
\ No newline at end of file
+*Operadores de servicios*: Istio permite la aplicación de políticas y la supervisión de la mesh desde un único punto de control centralizado, independientemente de la evolución de la aplicación. Como resultado, los operadores pueden garantizar el cumplimiento continuo de las políticas a través de un plano de gestión simplificado.
\ No newline at end of file
diff --git a/content/es/about/faq/metrics-and-logs/life-of-a-request.md b/content/es/about/faq/metrics-and-logs/life-of-a-request.md
index aee4b1379d728..903d0ce57acb8 100644
--- a/content/es/about/faq/metrics-and-logs/life-of-a-request.md
+++ b/content/es/about/faq/metrics-and-logs/life-of-a-request.md
@@ -5,7 +5,7 @@ weight: 80
Puede habilitar el [seguimiento](/es/docs/tasks/observability/distributed-tracing/) para determinar el flujo de una solicitud en Istio.
-Además, puede usar los siguientes comandos para saber más sobre el estado de la malla:
+Además, puede usar los siguientes comandos para saber más sobre el estado de la mesh:
* [`istioctl proxy-config`](/es/docs/reference/commands/istioctl/#istioctl-proxy-config): recupera información sobre la configuración del proxy cuando se ejecuta en Kubernetes:
@@ -29,7 +29,7 @@ Además, puede usar los siguientes comandos para saber más sobre el estado de l
$ istioctl proxy-config --help
{{< /text >}}
-* `kubectl get`: obtiene información sobre diferentes recursos en la malla junto con la configuración de enrutamiento:
+* `kubectl get`: obtiene información sobre diferentes recursos en la mesh junto con la configuración de enrutamiento:
{{< text plain >}}
# Listar todos los virtual services
diff --git a/content/es/about/faq/metrics-and-logs/metric-expiry.md b/content/es/about/faq/metrics-and-logs/metric-expiry.md
index 7a65fe084c29a..2bc37d14022a2 100644
--- a/content/es/about/faq/metrics-and-logs/metric-expiry.md
+++ b/content/es/about/faq/metrics-and-logs/metric-expiry.md
@@ -10,7 +10,7 @@ Hay varias formas de reducir la cardinalidad de las métricas de Istio:
La label `destination_service` es una fuente potencial de alta cardinalidad.
Los valores para `destination_service` se establecen de forma predeterminada en el encabezado del host si el proxy de Istio no puede determinar el servicio de destino a partir de otros metadatos de la solicitud.
Si los clientes utilizan una variedad de encabezados de host, esto podría dar como resultado una gran cantidad de valores para `destination_service`.
- En este caso, siga la guía de [personalización de métricas](/es/docs/tasks/observability/metrics/customize-metrics/) para deshabilitar la reserva del encabezado del host en toda la malla.
+ En este caso, siga la guía de [personalización de métricas](/es/docs/tasks/observability/metrics/customize-metrics/) para deshabilitar la reserva del encabezado del host en toda la mesh.
Para deshabilitar la reserva del encabezado del host para una workload o un namespace en particular, debe copiar la configuración de `EnvoyFilter` de estadísticas, actualizarla para que la reserva del encabezado del host esté deshabilitada y aplicarla con un selector más específico.
[Este problema](https://github.com/istio/istio/issues/25963#issuecomment-666037411) tiene más detalles sobre cómo lograrlo.
* Eliminar labels innecesarias de la colección. Si no se necesita la label con alta cardinalidad, puede eliminarla de la colección de métricas a través de la [personalización de métricas](/es/docs/tasks/observability/metrics/customize-metrics/) usando `tags_to_remove`.
diff --git a/content/es/about/faq/metrics-and-logs/mixer-migration.md b/content/es/about/faq/metrics-and-logs/mixer-migration.md
index 7b0ee0b2f0734..41d44d38ad576 100644
--- a/content/es/about/faq/metrics-and-logs/mixer-migration.md
+++ b/content/es/about/faq/metrics-and-logs/mixer-migration.md
@@ -4,7 +4,7 @@ weight: 30
---
Mixer fue [eliminado en la versión 1.8 de Istio](/news/releases/1.8.x/announcing-1.8/#deprecations).
-La migración es necesaria si todavía depende de los adaptadores integrados de Mixer o de cualquier adaptador fuera de proceso para la extensión de la malla.
+La migración es necesaria si todavía depende de los adaptadores integrados de Mixer o de cualquier adaptador fuera de proceso para la extensión de la mesh.
Para los adaptadores integrados, se proporcionan varias alternativas:
diff --git a/content/es/about/faq/metrics-and-logs/telemetry-v1-vs-v2.md b/content/es/about/faq/metrics-and-logs/telemetry-v1-vs-v2.md
index d74850e231d89..5524bd6f09d10 100644
--- a/content/es/about/faq/metrics-and-logs/telemetry-v1-vs-v2.md
+++ b/content/es/about/faq/metrics-and-logs/telemetry-v1-vs-v2.md
@@ -9,7 +9,7 @@ y es el mecanismo preferido para mostrar la telemetría en Istio.
Sin embargo, existen algunas diferencias en la telemetría informada entre v1 y
v2 que se enumeran a continuación:
-* **Faltan labels para el tráfico fuera de la malla**
+* **Faltan etiquetas para el tráfico fuera de la mesh**
La telemetría en el proxy se basa en el intercambio de metadatos entre los proxies de Envoy para recopilar
información como el nombre de el workload del par, el namespace y las labels. En la telemetría basada en Mixer
, esta funcionalidad la realizaba Mixer como parte de la combinación de los atributos de la solicitud
@@ -18,11 +18,11 @@ v2 que se enumeran a continuación:
el protocolo ALPN para el protocolo TCP como se describe
[aquí](/es/docs/tasks/observability/metrics/tcp-metrics/#understanding-tcp-telemetry-collection).
Esto requiere que los proxies de Envoy se inyecten tanto en los workloads del cliente como del servidor,
- lo que implica que a la telemetría informada cuando un par no está en la malla le faltarán
+ lo que implica que a la telemetría informada cuando un par no está en la mesh le faltarán
atributos del par como el nombre de el workload, el namespace y las labels.
Sin embargo, si ambos pares tienen proxies inyectados, todas las labels mencionadas
[aquí](/es/docs/reference/config/metrics/) están disponibles en las métricas generadas.
- Cuando el workload del servidor está fuera de la malla, los metadatos de el workload del servidor todavía
+ Cuando el workload del servidor está fuera de la mesh, los metadatos de el workload del servidor todavía
se distribuyen al sidecar del cliente, lo que hace que las métricas del lado del cliente tengan los metadatos de el workload del servidor
labels completadas.
diff --git a/content/es/about/faq/security/auth-mix-and-match.md b/content/es/about/faq/security/auth-mix-and-match.md
index faf5083099d9a..355e136983014 100644
--- a/content/es/about/faq/security/auth-mix-and-match.md
+++ b/content/es/about/faq/security/auth-mix-and-match.md
@@ -3,5 +3,5 @@ title: ¿Puedo habilitar TLS mutuo para algunos servicios mientras lo dejo desha
weight: 20
---
-La [política de autenticación](/es/docs/concepts/security/#authentication-policies) puede ser mesh-wide (lo que afecta a todos los servicios de la malla), namespace-wide
+La [política de autenticación](/es/docs/concepts/security/#authentication-policies) puede ser mesh-wide (lo que afecta a todos los servicios de la mesh), namespace-wide
(todos los servicios del mismo namespace) o específicamente del servicio. Puede tener una o varias políticas para configurar TLS mutuo para los servicios de un cluster de la forma que desee.
diff --git a/content/es/about/faq/security/does-istio-support-authorization.md b/content/es/about/faq/security/does-istio-support-authorization.md
index 7ddf18db2db34..08d9720dad809 100644
--- a/content/es/about/faq/security/does-istio-support-authorization.md
+++ b/content/es/about/faq/security/does-istio-support-authorization.md
@@ -3,5 +3,5 @@ title: ¿Admite Istio la autorización?
weight: 110
---
-Sí. Istio proporciona funciones de autorización tanto para servicios HTTP como para servicios TCP sin formato en la malla.
+Sí. Istio proporciona funciones de autorización tanto para servicios HTTP como para servicios TCP sin formato en la mesh.
[Más información](/es/docs/concepts/security/#authorization).
diff --git a/content/es/about/faq/security/non-istio-to-istio.md b/content/es/about/faq/security/non-istio-to-istio.md
index 9519dbf32e5ef..7a0285f3686bf 100644
--- a/content/es/about/faq/security/non-istio-to-istio.md
+++ b/content/es/about/faq/security/non-istio-to-istio.md
@@ -5,6 +5,6 @@ weight: 30
Cuando TLS mutuo `STRICT` está habilitado, los workloads que no son de Istio no pueden comunicarse con los servicios de Istio, ya que no tendrán un certificado de cliente de Istio válido.
Si necesita permitir estos clientes, el modo TLS mutuo se puede configurar en `PERMISSIVE`, lo que permite tanto texto sin formato como TLS mutuo.
-Esto se puede hacer para workloads individuales o para toda la malla.
+Esto se puede hacer para workloads individuales o para toda la mesh.
Consulte [Política de autenticación](/es/docs/tasks/security/authentication/authn-policy) para obtener más detalles.
diff --git a/content/es/blog/2024/ambient-reaches-beta/index.md b/content/es/blog/2024/ambient-reaches-beta/index.md
index 1d19e678019fa..82bcd476ce08e 100644
--- a/content/es/blog/2024/ambient-reaches-beta/index.md
+++ b/content/es/blog/2024/ambient-reaches-beta/index.md
@@ -15,12 +15,12 @@ El modo ambient [se anunció en septiembre de 2022](/blog/2022/introducing-ambie
Desde entonces, nuestra comunidad ha dedicado 20 meses de arduo trabajo y colaboración, con
contribuciones de Solo.io, Google, Microsoft, Intel, Aviatrix, Huawei, IBM, Red Hat y muchos otros.
El estado Beta en la 1.22 indica que las características del modo ambient ya están listas para los workloads de producción, con las precauciones adecuadas.
-Este es un hito enorme para Istio, que lleva las características de la malla de capa 4 y capa 7 a la
+Este es un hito enorme para Istio, que lleva las características de la mesh de capa 4 y capa 7 a la
preparación para producción sin sidecars.
## ¿Por qué el modo ambient?
-Al escuchar los comentarios de los usuarios de Istio, observamos una creciente demanda de capacidades de malla para las aplicaciones, pero
+Al escuchar los comentarios de los usuarios de Istio, observamos una creciente demanda de capacidades de mesh para las aplicaciones, pero
escuchamos que a muchos de ustedes les resultaba difícil superar la sobrecarga de recursos y la complejidad operativa de los sidecars. Los desafíos que los usuarios de sidecar
compartieron con nosotros incluyen cómo Istio puede romper las aplicaciones después de agregar los sidecars, el gran consumo de CPU y memoria por parte de los
sidecars, y la inconveniencia del requisito de reiniciar los pods de las aplicaciones con cada nueva versión del proxy.
@@ -30,8 +30,8 @@ de complejidad que enfrentaban los usuarios que buscaban implementar una service
se denominó 'modo ambient' ya que fue diseñado para ser transparente para tu aplicación, asegurando que no se requiriera ninguna configuración adicional
para adoptarlo, y no requería que los usuarios reiniciaran las aplicaciones.
-En el modo ambient es trivial agregar o eliminar aplicaciones de la malla. Ahora puedes simplemente [etiquetar un namespace](/es/docs/ambient/usage/add-workloads/), y todas las aplicaciones
-en ese namespace se agregan a la malla. Esto asegura inmediatamente todo el tráfico con mTLS, todo sin sidecars o la necesidad de
+En el modo ambient es trivial agregar o eliminar aplicaciones de la mesh. Ahora puedes simplemente [etiquetar un namespace](/es/docs/ambient/usage/add-workloads/), y todas las aplicaciones
+en ese namespace se agregan a la mesh. Esto asegura inmediatamente todo el tráfico con mTLS, todo sin sidecars o la necesidad de
reiniciar las aplicaciones.
Consulta el [blog Introducing Ambient Mesh](/blog/2022/introducing-ambient-mesh/)
@@ -46,13 +46,13 @@ suave de ninguna malla, a una superposición segura (L4), a un procesamiento com
tu flota.
El modo ambient funciona sin necesidad de ninguna modificación en tus implementaciones de Kubernetes existentes. Puedes etiquetar un namespace para
-agregar todas sus workloads a la malla, o incluir ciertas implementaciones según sea necesario. Al utilizar el modo ambient, los usuarios
+agregar todas sus workloads al mesh, o incluir ciertas implementaciones según sea necesario. Al utilizar el modo ambient, los usuarios
evitan algunos de los elementos previamente restrictivos del modelo de sidecar. Los protocolos de envío primero del servidor ahora
funcionan, la mayoría de los puertos reservados ahora están disponibles y se elimina la capacidad de los contenedores para omitir el sidecar, ya sea
maliciosamente o no.
El proxy de nodo L4 ligero y compartido se llama *[ztunnel](/es/docs/ambient/overview/#ztunnel)* (túnel de zero-trust). Ztunnel reduce drásticamente la sobrecarga de
-ejecutar una malla al eliminar la necesidad de aprovisionar en exceso la memoria y la CPU dentro de un cluster para manejar las cargas esperadas. En
+ejecutar un mesh al eliminar la necesidad de aprovisionar en exceso la memoria y la CPU dentro de un cluster para manejar las cargas esperadas. En
algunos casos de uso, los ahorros pueden superar el 90% o más, sin dejar de proporcionar seguridad de zero-trust mediante TLS mutuo con
identidad criptográfica, políticas de autorización L4 simples y telemetría.
@@ -73,7 +73,7 @@ Te recomendamos que explores las siguientes funciones Beta del modo ambient en p
en entornos de prueba:
- [Instalación de Istio con soporte para el modo ambient](/es/docs/ambient/install/).
-- [Agregar tus workloads a la malla](/es/docs/ambient/usage/add-workloads/) para obtener TLS mutuo con identidad criptográfica, [políticas de autorización L4](/es/docs/ambient/usage/l4-policy/) y telemetría.
+- [Agregar tus workloads a la mesh](/es/docs/ambient/usage/add-workloads/) para obtener TLS mutuo con identidad criptográfica, [políticas de autorización L4](/es/docs/ambient/usage/l4-policy/) y telemetría.
- [Configuración de waypoints](/es/docs/ambient/usage/waypoint/) para [usar funciones L7](/es/docs/ambient/usage/l7-features/) como el desvío de tráfico, el enrutamiento de solicitudes y la aplicación de políticas de autorización enriquecidas.
- Conexión del ingress gateway de Istio a los workloads en modo ambient, compatible con todas las API de Istio existentes.
- Uso de `istioctl` para operar waypoints y solucionar problemas de ztunnel y waypoints.
@@ -96,7 +96,7 @@ Tenemos una serie de características que aún no están implementadas en el mod
- Tráfico de egress controlado
- Soporte multi-red
-- Mejorar los mensajes de `status` en los recursos para ayudar a solucionar problemas y comprender la malla
+- Mejorar los mensajes de `status` en los recursos para ayudar a solucionar problemas y comprender la mesh
- Soporte de VM
## ¿Y qué hay de los sidecars?
@@ -104,7 +104,7 @@ Tenemos una serie de características que aún no están implementadas en el mod
Los sidecars no van a desaparecer y siguen siendo ciudadanos de primera clase en Istio. Puedes seguir usando sidecars, y seguirán siendo
totalmente compatibles. Para cualquier característica fuera del alcance de Alpha o Beta para el modo ambient, debes considerar usar el modo
sidecar hasta que la característica se agregue al modo ambient. Algunos casos de uso, como el desvío de tráfico basado en etiquetas de origen, seguirán
-siendo mejor implementados usando el modo sidecar. Si bien creemos que la mayoría de los casos de uso se atenderán mejor con una malla en
+siendo mejor implementados usando el modo sidecar. Si bien creemos que la mayoría de los casos de uso se atenderán mejor con un mesh en
modo ambient, el proyecto Istio sigue comprometido con el soporte continuo del modo sidecar.
## Prueba el modo ambient hoy
diff --git a/content/es/blog/2024/ambient-reaches-ga/index.md b/content/es/blog/2024/ambient-reaches-ga/index.md
index cddf69570d8d5..cfdc86559ebc0 100644
--- a/content/es/blog/2024/ambient-reaches-ga/index.md
+++ b/content/es/blog/2024/ambient-reaches-ga/index.md
@@ -12,10 +12,10 @@ Ambient mesh — y su implementación de referencia con el modo ambient de Istio
## ¿Por qué ambient mesh?
-Desde el lanzamiento de Istio en 2017, hemos observado una demanda clara y creciente de capacidades de malla para aplicaciones, pero escuchamos que a muchos usuarios les resultaba difícil superar la sobrecarga de recursos y la complejidad operativa de los sidecars. Los desafíos que los usuarios de Istio compartieron con nosotros incluyen cómo los sidecars pueden romper las aplicaciones después de que se agregan, el gran requisito de CPU y memoria para un proxy con cada workload, y la inconveniencia de necesitar reiniciar los pods de la aplicación con cada nueva versión de Istio.
+Desde el lanzamiento de Istio en 2017, hemos observado una demanda clara y creciente de capacidades de mesh para aplicaciones, pero escuchamos que a muchos usuarios les resultaba difícil superar la sobrecarga de recursos y la complejidad operativa de los sidecars. Los desafíos que los usuarios de Istio compartieron con nosotros incluyen cómo los sidecars pueden romper las aplicaciones después de que se agregan, el gran requisito de CPU y memoria para un proxy con cada workload, y la inconveniencia de necesitar reiniciar los pods de la aplicación con cada nueva versión de Istio.
Como comunidad, diseñamos ambient mesh desde cero para abordar estos problemas, aliviando las barreras anteriores de complejidad que enfrentaban los usuarios que buscaban implementar una service mesh. El nuevo concepto se denominó 'ambient mesh' ya que fue diseñado para ser transparente para tu aplicación, sin infraestructura de proxy ubicada junto con los workloads del usuario, sin cambios sutiles en la configuración necesarios para la incorporación y sin necesidad de reiniciar la aplicación.
-En el modo ambient es trivial agregar o eliminar aplicaciones de la malla. Todo lo que necesitas hacer es [etiquetar un namespace](/es/docs/ambient/usage/add-workloads/), y todas las aplicaciones en ese namespace se agregan instantáneamente a la malla. Esto asegura inmediatamente todo el tráfico dentro de ese namespace con cifrado TLS mutuo estándar de la industria, ¡sin necesidad de otra configuración o reinicios!
+En el modo ambient es trivial agregar o eliminar aplicaciones de la mesh. Todo lo que necesitas hacer es [etiquetar un namespace](/es/docs/ambient/usage/add-workloads/), y todas las aplicaciones en ese namespace se agregan instantáneamente a la mesh. Esto asegura inmediatamente todo el tráfico dentro de ese namespace con cifrado TLS mutuo estándar de la industria, ¡sin necesidad de otra configuración o reinicios!
Consulta el [blog Introducing Ambient Mesh](/blog/2022/introducing-ambient-mesh/) para obtener más información sobre por qué creamos el modo ambient de Istio.
## ¿Cómo facilita la adopción el modo ambient?
@@ -24,7 +24,7 @@ La innovación principal detrás de ambient mesh es que divide el procesamiento
Al utilizar ambient mesh, los usuarios evitan algunos de los elementos previamente restrictivos del modelo de sidecar. Los protocolos de envío primero del servidor ahora funcionan, la mayoría de los puertos reservados ahora están disponibles y se elimina la capacidad de los contenedores para omitir el sidecar, ya sea maliciosamente o no.
-El proxy de nodo L4 ligero y compartido se llama *[ztunnel](/es/docs/ambient/overview/#ztunnel)* (túnel de zero-trust). ztunnel reduce drásticamente la sobrecarga de ejecutar una malla al eliminar la necesidad de aprovisionar en exceso la memoria y la CPU dentro de un cluster para manejar las cargas esperadas. En algunos casos de uso, los ahorros pueden superar el 90% o más, sin dejar de proporcionar seguridad de zero-trust mediante TLS mutuo con identidad criptográfica, políticas de autorización L4 simples y telemetría.
+El proxy de nodo L4 ligero y compartido se llama *[ztunnel](/es/docs/ambient/overview/#ztunnel)* (túnel de zero-trust). ztunnel reduce drásticamente la sobrecarga de ejecutar un mesh al eliminar la necesidad de aprovisionar en exceso la memoria y la CPU dentro de un cluster para manejar las cargas esperadas. En algunos casos de uso, los ahorros pueden superar el 90% o más, sin dejar de proporcionar seguridad de zero-trust mediante TLS mutuo con identidad criptográfica, políticas de autorización L4 simples y telemetría.
Los proxies L7 se llaman *[waypoints](/es/docs/ambient/overview/#waypoint-proxies)*. Los waypoints procesan funciones L7 como el enrutamiento de tráfico, la aplicación de políticas de autorización enriquecidas y la resiliencia de nivel empresarial. Los waypoints se ejecutan fuera de las implementaciones de tu aplicación y pueden escalar de forma independiente según tus necesidades, que podrían ser para todo el namespace o para múltiples servicios dentro de un namespace. En comparación con los sidecars, no necesitas un waypoint por pod de aplicación, y puedes escalar tu waypoint de manera efectiva en función de su alcance, ahorrando así cantidades significativas de CPU y memoria en la mayoría de los casos.
@@ -42,7 +42,7 @@ La imagen de ztunnel en Docker Hub ha alcanzado más de [1 millón de descargas]
Les pedimos a algunos de nuestros usuarios su opinión sobre la GA del modo ambient:
{{< quote >}}
-**La implementación de Istio de una service mesh con su diseño de ambient mesh ha sido una gran adición a nuestros clusteres de Kubernetes para simplificar las responsabilidades del equipo y la arquitectura de red general de la malla. Junto con el proyecto Gateway API, me ha dado una excelente manera de permitir que los desarrolladores satisfagan sus necesidades de red al mismo tiempo que solo delegan el control necesario. Si bien es un proyecto en rápida evolución, ha sido sólido y confiable en producción y será nuestra opción predeterminada para implementar controles de red en una implementación de Kubernetes en el futuro.**
+**La implementación de Istio de una service mesh con su diseño de ambient mesh ha sido una gran adición a nuestros clusteres de Kubernetes para simplificar las responsabilidades del equipo y la arquitectura de red general de la mesh. Junto con el proyecto Gateway API, me ha dado una excelente manera de permitir que los desarrolladores satisfagan sus necesidades de red al mismo tiempo que solo delegan el control necesario. Si bien es un proyecto en rápida evolución, ha sido sólido y confiable en producción y será nuestra opción predeterminada para implementar controles de red en una implementación de Kubernetes en el futuro.**
— [Daniel Loader](https://uk.linkedin.com/in/danielloader), Ingeniero de Plataforma Principal en Quotech
@@ -91,13 +91,13 @@ Les pedimos a algunos de nuestros usuarios su opinión sobre la GA del modo ambi
{{< /quote >}}
{{< quote >}}
-**Nuestro equipo eligió Istio por sus características de service mesh y su fuerte alineación con la Gateway API para crear una solución de alojamiento robusta basada en Kubernetes. A medida que integramos aplicaciones en la malla, enfrentamos desafíos de recursos con los proxies sidecar, lo que nos llevó a hacer la transición al modo ambient en Beta para mejorar la escalabilidad y la seguridad. Comenzamos con la seguridad y observabilidad de L4 a través de ztunnel, obteniendo cifrado automático del tráfico dentro del cluster y monitoreo transparente del flujo de tráfico. Al habilitar selectivamente las características de L7 y desacoplar el proxy de las aplicaciones, logramos una escalabilidad perfecta y una utilización y latencia de recursos reducidas. Este enfoque permitió a los desarrolladores centrarse en el desarrollo de aplicaciones, lo que resultó en una plataforma más resistente, segura y escalable impulsada por el modo ambient.**
+**Nuestro equipo eligió Istio por sus características de service mesh y su fuerte alineación con la Gateway API para crear una solución de alojamiento robusta basada en Kubernetes. A medida que integramos aplicaciones en la mesh, enfrentamos desafíos de recursos con los proxies sidecar, lo que nos llevó a hacer la transición al modo ambient en Beta para mejorar la escalabilidad y la seguridad. Comenzamos con la seguridad y observabilidad de L4 a través de ztunnel, obteniendo cifrado automático del tráfico dentro del cluster y monitoreo transparente del flujo de tráfico. Al habilitar selectivamente las características de L7 y desacoplar el proxy de las aplicaciones, logramos una escalabilidad perfecta y una utilización y latencia de recursos reducidas. Este enfoque permitió a los desarrolladores centrarse en el desarrollo de aplicaciones, lo que resultó en una plataforma más resistente, segura y escalable impulsada por el modo ambient.**
— [Jose Marques](https://www.linkedin.com/in/jdcmarques/), DevOps Senior en Blip.pt
{{< /quote >}}
{{< quote >}}
-**Estamos usando Istio para garantizar un tráfico mTLS L4 estricto en nuestra malla y estamos entusiasmados con el modo ambient. En comparación con el modo sidecar, es un ahorro masivo de recursos y, al mismo tiempo, hace que la configuración de las cosas sea aún más simple y transparente.**
+**Estamos usando Istio para garantizar un tráfico mTLS L4 estricto en nuestra meshy estamos entusiasmados con el modo ambient. En comparación con el modo sidecar, es un ahorro masivo de recursos y, al mismo tiempo, hace que la configuración de las cosas sea aún más simple y transparente.**
— [Andrea Dolfi](https://www.linkedin.com/in/andrea-dolfi-58b427128/), Ingeniero de DevOps
{{< /quote >}}
@@ -107,10 +107,10 @@ Les pedimos a algunos de nuestros usuarios su opinión sobre la GA del modo ambi
La disponibilidad general del modo ambient significa que las siguientes cosas ahora se consideran estables:
- [Instalación de Istio con soporte para el modo ambient](/es/docs/ambient/install/), con Helm o `istioctl`.
-- [Agregar tus workloads a la malla](/es/docs/ambient/usage/add-workloads/) para obtener TLS mutuo con identidad criptográfica, [políticas de autorización L4](/es/docs/ambient/usage/l4-policy/) y telemetría.
+- [Agregar tus workloads a la mesh](/es/docs/ambient/usage/add-workloads/) para obtener TLS mutuo con identidad criptográfica, [políticas de autorización L4](/es/docs/ambient/usage/l4-policy/) y telemetría.
- [Configuración de waypoints](/es/docs/ambient/usage/waypoint/) para [usar funciones L7](/es/docs/ambient/usage/l7-features/) como el desvío de tráfico, el enrutamiento de solicitudes y la aplicación de políticas de autorización enriquecidas.
- Conexión del ingress gateway de Istio a los workloads en modo ambient, compatible con las API de Kubernetes Gateway y todas las API de Istio existentes.
-- Uso de waypoints para el egress controlado de la malla
+- Uso de waypoints para el egress controlado de la mesh
- Uso de `istioctl` para operar waypoints y solucionar problemas de ztunnel y waypoints.
Consulta la [página de estado de las características](/es/docs/releases/feature-stages/#ambient-mode) para obtener más información.
@@ -128,7 +128,7 @@ En nuestras próximas versiones, esperamos avanzar rápidamente en las siguiente
## ¿Y qué hay de los sidecars?
-Los sidecars no van a desaparecer y siguen siendo ciudadanos de primera clase en Istio. Puedes seguir usando sidecars, y seguirán siendo totalmente compatibles. Si bien creemos que la mayoría de los casos de uso se atenderán mejor con una malla en modo ambient, el proyecto Istio sigue comprometido con el soporte continuo del modo sidecar.
+Los sidecars no van a desaparecer y siguen siendo ciudadanos de primera clase en Istio. Puedes seguir usando sidecars, y seguirán siendo totalmente compatibles. Si bien creemos que la mayoría de los casos de uso se atenderán mejor con un mesh en modo ambient, el proyecto Istio sigue comprometido con el soporte continuo del modo sidecar.
## Prueba el modo ambient hoy
diff --git a/content/es/blog/2024/ambient-vs-cilium/index.md b/content/es/blog/2024/ambient-vs-cilium/index.md
index 2fa87b0476050..874f464044384 100644
--- a/content/es/blog/2024/ambient-vs-cilium/index.md
+++ b/content/es/blog/2024/ambient-vs-cilium/index.md
@@ -33,7 +33,7 @@ Istio pudo entregar un 56% más de consultas con una latencia de cola un 20% má
Teniendo en cuenta el recurso utilizado, Istio procesó 2178 consultas por núcleo, frente a las 1815 de Cilium, una mejora del 20%.
-* **La ralentización de Cilium:** Cilium, si bien cuenta con una latencia baja impresionante con los parámetros de instalación predeterminados, se ralentiza sustancialmente cuando se activan las características básicas de Istio, como la política L7 y el cifrado. Además, la utilización de memoria y CPU de Cilium se mantuvo alta incluso cuando no fluía tráfico en la malla. Esto puede afectar la estabilidad y confiabilidad generales de tu cluster, especialmente a medida que crece.
+* **La ralentización de Cilium:** Cilium, si bien cuenta con una latencia baja impresionante con los parámetros de instalación predeterminados, se ralentiza sustancialmente cuando se activan las características básicas de Istio, como la política L7 y el cifrado. Además, la utilización de memoria y CPU de Cilium se mantuvo alta incluso cuando no fluía tráfico en la mesh. Esto puede afectar la estabilidad y confiabilidad generales de tu cluster, especialmente a medida que crece.
* **Istio, el actor constante:** El modo ambient de Istio, por otro lado, mostró su fortaleza en la estabilidad y el mantenimiento de un rendimiento decente, incluso con la sobrecarga adicional del cifrado. Si bien Istio consumió más memoria y CPU que Cilium bajo prueba, su utilización de CPU se estabilizó en una fracción de la de Cilium cuando no estaba bajo carga.
## Tras bambalinas: ¿Por qué la diferencia?
diff --git a/content/es/blog/2024/authz-policy-with-kyverno/index.md b/content/es/blog/2024/authz-policy-with-kyverno/index.md
index 50a477def1d40..2c65c503b0879 100644
--- a/content/es/blog/2024/authz-policy-with-kyverno/index.md
+++ b/content/es/blog/2024/authz-policy-with-kyverno/index.md
@@ -85,7 +85,7 @@ apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: my-kyverno-authz
- namespace: istio-system # Esto aplica la política en toda la malla, siendo istio-system el namespace raíz de la malla
+ namespace: istio-system # Esto aplica la política en toda la mesh, siendo istio-system el namespace raíz de la mesh
spec:
selector:
matchLabels:
diff --git a/content/es/blog/2024/gateway-mesh-ga/index.md b/content/es/blog/2024/gateway-mesh-ga/index.md
index 0179ee9d00645..16ed87937a509 100644
--- a/content/es/blog/2024/gateway-mesh-ga/index.md
+++ b/content/es/blog/2024/gateway-mesh-ga/index.md
@@ -1,5 +1,5 @@
---
-title: "El soporte de malla de la API de Gateway es promovido a Estable"
+title: "El soporte de mesh de la API de Gateway es promovido a Estable"
description: Las API de enrutamiento de tráfico de Kubernetes de próxima generación ya están disponibles de forma general para casos de uso de service mesh.
publishdate: 2024-05-13
attribution: John Howard - solo.io
diff --git a/content/es/blog/2024/happy-7th-birthday/index.md b/content/es/blog/2024/happy-7th-birthday/index.md
index 75e8caa37cc74..2567945af8595 100644
--- a/content/es/blog/2024/happy-7th-birthday/index.md
+++ b/content/es/blog/2024/happy-7th-birthday/index.md
@@ -93,7 +93,7 @@ y no tener que implementar eso en nuestra base de código de aplicación.**
{{< /quote >}}
{{< quote >}}
-**Usamos Istio en Predibase ampliamente para simplificar la comunicación entre nuestra malla multi-cluster que ayuda a implementar
+**Usamos Istio en Predibase ampliamente para simplificar la comunicación entre nuestra mesh multi-cluster que ayuda a implementar
y entrenar modelos LLM de código abierto ajustados con baja latencia y conmutación por error. Con Istio, obtenemos una gran cantidad de funcionalidades listas para usar que de otro modo
nos llevaría semanas implementar.**
@@ -191,7 +191,7 @@ asombrado por lo que hace la comunidad y espero ver qué éxitos tendremos en el
{{< /quote >}}
{{< quote >}}
-**Istio es la columna vertebral de la infraestructura de la service mesh de Salesforce, que hoy en día impulsa unos pocos billones de solicitudes por día en todos nuestros servicios. Resolvemos muchos problemas complicados con la malla. Es genial ser parte de este viaje y contribuir a la comunidad. Istio ha madurado hasta convertirse en una service mesh confiable a lo largo de los años y, al mismo tiempo, continúa innovando. ¡Estamos entusiasmados con lo que vendrá en el futuro!**
+**Istio es la columna vertebral de la infraestructura de la service mesh de Salesforce, que hoy en día impulsa unos pocos billones de solicitudes por día en todos nuestros servicios. Resolvemos muchos problemas complicados con la mesh. Es genial ser parte de este viaje y contribuir a la comunidad. Istio ha madurado hasta convertirse en una service mesh confiable a lo largo de los años y, al mismo tiempo, continúa innovando. ¡Estamos entusiasmados con lo que vendrá en el futuro!**
— Rama Chavali, líder del Grupo de Trabajo de Redes de Istio y Arquitecto de Ingeniería de Software en Salesforce
{{< /quote >}}
diff --git a/content/es/blog/2024/in-cluster-operator-deprecation-announcement/index.md b/content/es/blog/2024/in-cluster-operator-deprecation-announcement/index.md
index faae427631aea..e01185f35a18d 100644
--- a/content/es/blog/2024/in-cluster-operator-deprecation-announcement/index.md
+++ b/content/es/blog/2024/in-cluster-operator-deprecation-announcement/index.md
@@ -50,7 +50,7 @@ Usando el nombre de tu recurso, descarga la configuración de tu operador en for
$ kubectl get IstioOperator -o yaml > istio.yaml
{{< /text >}}
-Deshabilita el Operador In-Cluster. Esto no deshabilitará tu control plane ni interrumpirá el tráfico de tu malla actual.
+Deshabilita el Operador In-Cluster. Esto no deshabilitará tu control plane ni interrumpirá el tráfico de tu mesh actual.
{{< text bash >}}
$ kubectl scale deployment -n istio-system istio-operator –replicas 0
diff --git a/content/es/blog/2024/inpod-traffic-redirection-ambient/index.md b/content/es/blog/2024/inpod-traffic-redirection-ambient/index.md
index acec5b96f7c43..3e07030287d11 100644
--- a/content/es/blog/2024/inpod-traffic-redirection-ambient/index.md
+++ b/content/es/blog/2024/inpod-traffic-redirection-ambient/index.md
@@ -21,7 +21,7 @@ funcione en cualquier plataforma de Kubernetes y con cualquier implementación d
En Solo, hemos estado integrando el modo ambient en nuestro producto Gloo Mesh, y se nos ocurrió una solución innovadora a este problema.
Decidimos [hacer upstream](https://github.com/istio/istio/issues/48212) de nuestros cambios a finales de 2023 para ayudar a que ambient llegue a beta más rápido,
-para que más usuarios puedan operar ambient en Istio 1.21 o más reciente, y disfrutar de los beneficios de la malla sin sidecar ambient en sus plataformas
+para que más usuarios puedan operar ambient en Istio 1.21 o más reciente, y disfrutar de los beneficios de la mesh sin sidecar ambient en sus plataformas
independientemente de su implementación de CNI existente o preferida.
## ¿Cómo llegamos aquí?
@@ -52,10 +52,10 @@ compatibilidad con las ofertas gestionadas, el soporte entre proveedores y la co
El componente [istio-cni](/es/docs/setup/additional-setup/cni/) es un componente opcional en el modo de data plane de sidecar,
comúnmente utilizado para eliminar el [requisito de las capacidades `NET_ADMIN` y `NET_RAW`](/es/docs/ops/deployment/application-requirements/) para
-los usuarios que implementan pods en la malla. `istio-cni` es un componente obligatorio en el modo de data plane
+los usuarios que implementan pods en la mesh. `istio-cni` es un componente obligatorio en el modo de data plane
ambient. El componente `istio-cni` _no_ es una implementación de CNI primaria, es un agente de nodo que extiende cualquier implementación de CNI primaria que ya esté presente en el cluster.
-Cada vez que se agregan pods a una malla ambient, el componente `istio-cni` configura la redirección de tráfico para todo
+Cada vez que se agregan pods a un ambient mesh, el componente `istio-cni` configura la redirección de tráfico para todo
el tráfico entrante y saliente entre los pods y el [ztunnel](/blog/2023/rust-based-ztunnel/) que se ejecuta en
el nodo del pod, a través del namespace de red a nivel de nodo. La diferencia clave entre el mecanismo de sidecar y el mecanismo alfa de ambient
es que en este último, el tráfico del pod se redirigía fuera del namespace de red del pod y hacia el namespace de red del pod ztunnel coubicado, pasando necesariamente por el namespace de red del host en el camino, que es donde se implementó la mayor parte de las reglas de redirección de tráfico para lograr esto.
@@ -114,7 +114,7 @@ Cuando un proceso que se ejecuta dentro de un namespace de red crea un paquete T
procesado primero por cualquier regla local dentro del namespace de red local, luego abandonar el namespace de red local, pasando
a otro.
-Por ejemplo, en un Kubernetes simple sin ninguna malla instalada, un pod podría crear un paquete y enviarlo a otro pod, y
+Por ejemplo, en un Kubernetes simple sin ninguna meshinstalada, un pod podría crear un paquete y enviarlo a otro pod, y
el paquete podría (dependiendo de cómo se configuró la red):
- Ser procesado por cualquier regla dentro del namespace de red del pod de origen.
- Abandonar el namespace de red del pod de origen y subir al namespace de red del nodo, donde es procesado por cualquier regla en ese namespace.
@@ -127,21 +127,21 @@ entran al nuevo pod puedan llegar a donde se supone que deben ir. A Kubernetes o
### ¿Por qué abandonamos el modelo anterior?
-En la malla ambient de Istio, cada nodo tiene un mínimo de dos contenedores que se ejecutan como DaemonSets de Kubernetes:
-- Un ztunnel eficiente que se encarga de las tareas de proxy de tráfico de la malla y la aplicación de políticas L4.
-- Un agente de nodo `istio-cni` que se encarga de agregar pods nuevos y existentes a la malla ambient.
+En la mesh ambient de Istio, cada nodo tiene un mínimo de dos contenedores que se ejecutan como DaemonSets de Kubernetes:
+- Un ztunnel eficiente que se encarga de las tareas de proxy de tráfico de la mesh y la aplicación de políticas L4.
+- Un agente de nodo `istio-cni` que se encarga de agregar pods nuevos y existentes a la mesh ambient.
-En la implementación anterior de la malla ambient, así es como se agrega un pod de aplicación a la malla ambient:
-- El agente de nodo `istio-cni` detecta un pod de Kubernetes existente o recién iniciado con su namespace etiquetado con `istio.io/data plane-mode=ambient`, lo que indica que debe incluirse en la malla ambient.
+En la implementación anterior de la mesh ambient, así es como se agrega un pod de aplicación a la mesh ambient:
+- El agente de nodo `istio-cni` detecta un pod de Kubernetes existente o recién iniciado con su namespace etiquetado con `istio.io/data plane-mode=ambient`, lo que indica que debe incluirse en la mesh ambient.
- El agente de nodo `istio-cni` luego establece reglas de redirección de red en el namespace de red del host, de modo que
los paquetes que entran o salen del pod de la aplicación serían interceptados y redirigidos al ztunnel de ese nodo en los [puertos](https://github.com/istio/ztunnel/blob/master/ARCHITECTURE.md#ports) de proxy
relevantes (15008, 15006 o 15001).
-Esto significa que para un paquete creado por un pod en la malla ambient, ese paquete saldría de ese pod de origen, entraría en el namespace de red del host
+Esto significa que para un paquete creado por un pod en la mesh ambient, ese paquete saldría de ese pod de origen, entraría en el namespace de red del host
del nodo y luego, idealmente, sería interceptado y redirigido al ztunnel de ese nodo (que se ejecuta en su propio namespace de red
) para el proxy al pod de destino, con un viaje de regress similar.
-Este modelo funcionó lo suficientemente bien como un marcador de posición para la implementación alfa inicial de la malla ambient, pero como se mencionó, tiene un problema fundamental
+Este modelo funcionó lo suficientemente bien como un marcador de posición para la implementación alfa inicial de la mesh ambient, pero como se mencionó, tiene un problema fundamental
: hay muchas implementaciones de CNI, y en Linux hay muchas formas fundamentalmente diferentes e incompatibles
en las que puedes configurar cómo los paquetes van de un namespace de red a otro. Puedes usar túneles, redes superpuestas,
pasar por el namespace de red del host o evitarlo. Puedes pasar por la pila de red del espacio de usuario de Linux,
@@ -158,13 +158,13 @@ de cada CNI popular?
### Redirección de tráfico ambient de Istio: el nuevo modelo
-En el nuevo modelo ambient, así es como se agrega un pod de aplicación a la malla ambient:
-- El agente de nodo `istio-cni` detecta un pod de Kubernetes (existente o recién iniciado) con su namespace etiquetado con `istio.io/data plane-mode=ambient`, lo que indica que debe incluirse en la malla ambient.
- - Si se inicia un pod *nuevo* que debe agregarse a la malla ambient, un complemento CNI (instalado y administrado por el agente `istio-cni`) es activado por la CRI.
+En el nuevo modelo ambient, así es como se agrega un pod de aplicación a la mesh ambient:
+- El agente de nodo `istio-cni` detecta un pod de Kubernetes (existente o recién iniciado) con su namespace etiquetado con `istio.io/data plane-mode=ambient`, lo que indica que debe incluirse en la mesh ambient.
+ - Si se inicia un pod *nuevo* que debe agregarse a la mesh ambient, un complemento CNI (instalado y administrado por el agente `istio-cni`) es activado por la CRI.
Este complemento se utiliza para enviar un nuevo evento de pod al agente `istio-cni` del nodo y bloquear el inicio del pod hasta que el agente configure correctamente la
redirección. Dado que los complementos CNI son invocados por la CRI lo antes posible en el proceso de creación de pods de Kubernetes, esto garantiza que podamos
establecer la redirección de tráfico lo suficientemente temprano como para evitar que el tráfico se escape durante el inicio, sin depender de cosas como los contenedores de inicialización.
- - Si un pod *ya en ejecución* se agrega a la malla ambient, se activa un nuevo evento de pod. El observador de la API de Kubernetes
+ - Si un pod *ya en ejecución* se agrega a la mesh ambient, se activa un nuevo evento de pod. El observador de la API de Kubernetes
del agente de nodo `istio-cni` detecta esto y la redirección se configura de la misma manera.
- El agente de nodo `istio-cni` ingresa al namespace de red del pod y establece reglas de redirección de red dentro del namespace de red del pod, de modo que los paquetes que entran y salen del pod se interceptan y se redirigen de forma transparente a la instancia de proxy ztunnel local del nodo que escucha en los [puertos conocidos](https://github.com/istio/ztunnel/blob/master/ARCHITECTURE.md#ports) (15008, 15006, 15001).
- El agente de nodo `istio-cni` luego informa al ztunnel del nodo a través de un socket de dominio Unix que debe establecer puertos de escucha de proxy
@@ -176,28 +176,28 @@ namespace de red cree sockets de escucha en otro namespace de red, asumiendo que
en el momento de la creación.
- El ztunnel local del nodo internamente crea una nueva instancia de proxy y un conjunto de puertos de escucha, dedicados al pod recién agregado.
- Una vez que las reglas de redirección in-Pod están en su lugar y el ztunnel ha establecido los puertos de escucha, el pod se agrega a la
-malla y el tráfico comienza a fluir a través del ztunnel local del nodo, como antes.
+meshy el tráfico comienza a fluir a través del ztunnel local del nodo, como antes.
-Aquí hay un diagrama básico que muestra el flujo de un pod de aplicación que se agrega a la malla ambient:
+Aquí hay un diagrama básico que muestra el flujo de un pod de aplicación que se agrega a la mesh ambient:
{{< image width="100%"
link="./pod-added-to-ambient.svg"
- alt="flujo de pod agregado a la malla ambient"
+ alt="flujo de pod agregado a la mesh ambient"
>}}
-Una vez que el pod se agrega con éxito a la malla ambient, el tráfico hacia y desde los pods en la malla se cifrará completamente con mTLS de forma predeterminada, como siempre con Istio.
+Una vez que el pod se agrega con éxito a la mesh ambient, el tráfico hacia y desde los pods en la mesh se cifrará completamente con mTLS de forma predeterminada, como siempre con Istio.
-El tráfico ahora entrará y saldrá del namespace de red del pod como tráfico cifrado; parecerá que cada pod en la malla ambient tiene la capacidad de hacer cumplir la política de la malla y cifrar el tráfico de forma segura, aunque la aplicación de usuario que se ejecuta en el pod
+El tráfico ahora entrará y saldrá del namespace de red del pod como tráfico cifrado; parecerá que cada pod en la mesh ambient tiene la capacidad de hacer cumplir la política de la mesh y cifrar el tráfico de forma segura, aunque la aplicación de usuario que se ejecuta en el pod
no tiene conocimiento de ninguna de las dos cosas.
-Aquí hay un diagrama para ilustrar cómo fluye el tráfico cifrado entre los pods en la malla ambient en el nuevo modelo:
+Aquí hay un diagrama para ilustrar cómo fluye el tráfico cifrado entre los pods en la mesh ambient en el nuevo modelo:
{{< image width="100%"
link="./traffic-flows-between-pods-in-ambient.svg"
- alt="El tráfico HBONE fluye entre los pods en la malla ambient"
+ alt="El tráfico HBONE fluye entre los pods en la mesh ambient"
>}}
-Y, como antes, el tráfico de texto sin cifrar no cifrado desde fuera de la malla todavía se puede manejar y la política se puede aplicar, para los casos de uso
+Y, como antes, el tráfico de texto sin cifrar no cifrado desde fuera de la mesh todavía se puede manejar y la política se puede aplicar, para los casos de uso
en los que sea necesario:
{{< image width="100%"
@@ -213,17 +213,17 @@ en absoluto. Recuerda que el trabajo de las implementaciones de CNI es llevar pa
no les importa lo que suceda con los paquetes después de ese punto.
Este enfoque elimina automáticamente los conflictos con una amplia gama de implementaciones de CNI y NetworkPolicy, y mejora drásticamente
-la compatibilidad de la malla ambient de Istio con todas las principales ofertas de Kubernetes gestionadas en todas las principales CNI.
+la compatibilidad de la mesh ambient de Istio con todas las principales ofertas de Kubernetes gestionadas en todas las principales CNI.
## Conclusión
-Gracias a la cantidad significativa de esfuerzo de nuestra encantadora comunidad en probar el cambio con una gran variedad de plataformas de Kubernetes y CNI, y muchas rondas de revisiones de los mantenedores de Istio, nos complace anunciar que los PR de [ztunnel](https://github.com/istio/ztunnel/pull/747) e [istio-cni](https://github.com/istio/istio/pull/48253) que implementan esta característica se fusionaron en Istio 1.21 y están habilitados de forma predeterminada para ambient, por lo que los usuarios de Istio pueden comenzar a ejecutar la malla ambient en cualquier plataforma de Kubernetes con cualquier CNI en Istio 1.21 o más reciente. Hemos probado esto con GKE,
+Gracias a la cantidad significativa de esfuerzo de nuestra encantadora comunidad en probar el cambio con una gran variedad de plataformas de Kubernetes y CNI, y muchas rondas de revisiones de los mantenedores de Istio, nos complace anunciar que los PR de [ztunnel](https://github.com/istio/ztunnel/pull/747) e [istio-cni](https://github.com/istio/istio/pull/48253) que implementan esta característica se fusionaron en Istio 1.21 y están habilitados de forma predeterminada para ambient, por lo que los usuarios de Istio pueden comenzar a ejecutar la mesh ambient en cualquier plataforma de Kubernetes con cualquier CNI en Istio 1.21 o más reciente. Hemos probado esto con GKE,
AKS y EKS y todas las implementaciones de CNI que ofrecen, así como con CNI de terceros como
Calico y Cilium, así como plataformas como OpenShift, con resultados sólidos.
Estamos extremadamente emocionados de poder
-hacer avanzar la malla ambient de Istio para que se ejecute en todas partes con este innovador enfoque de redirección de tráfico in-Pod entre ztunnel
+hacer avanzar la mesh ambient de Istio para que se ejecute en todas partes con este innovador enfoque de redirección de tráfico in-Pod entre ztunnel
y los pods de aplicación de los usuarios. Con este principal obstáculo técnico para la beta de ambient resuelto, ¡estamos ansiosos por trabajar con el
-resto de la comunidad de Istio para llevar la malla ambient a beta pronto! Para obtener más información sobre el progreso de la beta de la malla ambient, únete a nosotros en
+resto de la comunidad de Istio para llevar la mesh ambient a beta pronto! Para obtener más información sobre el progreso de la beta de la mesh ambient, únete a nosotros en
el canal #ambient y #ambient-dev en el [slack](https://slack.istio.io) de Istio, o asiste a la [reunión semanal de contribuyentes de ambient](https://github.com/istio/community/blob/master/WORKING-GROUPS.md#working-group-meetings) los miércoles,
-o echa un vistazo al [tablero del proyecto](https://github.com/orgs/istio/projects/9/views/3?filterQuery=beta) beta de la malla ambient y ¡ayúdanos a arreglar algo!
+o echa un vistazo al [tablero del proyecto](https://github.com/orgs/istio/projects/9/views/3?filterQuery=beta) beta de la mesh ambient y ¡ayúdanos a arreglar algo!
diff --git a/content/es/blog/2024/l7-policy-with-opa/index.md b/content/es/blog/2024/l7-policy-with-opa/index.md
index 9315210f17e73..ee2e8243c64b5 100644
--- a/content/es/blog/2024/l7-policy-with-opa/index.md
+++ b/content/es/blog/2024/l7-policy-with-opa/index.md
@@ -141,7 +141,7 @@ apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: my-opa-authz
- namespace: istio-system # Esto aplica la política en toda la malla, siendo istio-system el namespace de configuración de la malla
+ namespace: istio-system # Esto aplica la política en toda la mesh, siendo istio-system el namespace de configuración de la mesh
spec:
selector:
matchLabels:
diff --git a/content/es/blog/2025/istio-at-kubecon-eu/index.md b/content/es/blog/2025/istio-at-kubecon-eu/index.md
index 94bcd07e7fbeb..d532d3981ab41 100644
--- a/content/es/blog/2025/istio-at-kubecon-eu/index.md
+++ b/content/es/blog/2025/istio-at-kubecon-eu/index.md
@@ -16,7 +16,7 @@ Dimos el pistoletazo de salida a las actividades en Londres con el Istio Day, un
caption="Istio Day Europe 2025, Bienvenida"
>}}
-El Istio Day comenzó con una [ponencia de apertura](https://youtu.be/v10UpNQIoT0?si=CEOwz3nMMPVP7XWE) de los presidentes del Comité del Programa, Keith Mattix y Denis Jannot. La ponencia fue seguida por [la tan esperada charla de Microsoft sobre el soporte de Istio Ambient Mesh en Windows](https://youtu.be/sULnWlj8sR8?si=ewQ2hgdEZ5ZSRGuK). Tuvimos una charla muy interesante de Lior Lieberman de Google y Erik Parienty de Riskified [sobre la arquitectura de Istio para implementaciones a gran escala](https://youtu.be/GNi9ZJFuups?si=7gjH_tW6dURyJOLZ), seguida de una charla de los mantenedores de Kiali, Josune Cordoba y Hayk Hovsepyan, de RedHat, sobre [la solución de problemas de la malla ambient de Istio con Kiali 2.0](https://youtu.be/kodNy436ND0?si=Qyh4ebtfnYV2H6Ap).
+El Istio Day comenzó con una [ponencia de apertura](https://youtu.be/v10UpNQIoT0?si=CEOwz3nMMPVP7XWE) de los presidentes del Comité del Programa, Keith Mattix y Denis Jannot. La ponencia fue seguida por [la tan esperada charla de Microsoft sobre el soporte de Istio Ambient Mesh en Windows](https://youtu.be/sULnWlj8sR8?si=ewQ2hgdEZ5ZSRGuK). Tuvimos una charla muy interesante de Lior Lieberman de Google y Erik Parienty de Riskified [sobre la arquitectura de Istio para implementaciones a gran escala](https://youtu.be/GNi9ZJFuups?si=7gjH_tW6dURyJOLZ), seguida de una charla de los mantenedores de Kiali, Josune Cordoba y Hayk Hovsepyan, de RedHat, sobre [la solución de problemas de la mesh ambient de Istio con Kiali 2.0](https://youtu.be/kodNy436ND0?si=Qyh4ebtfnYV2H6Ap).
{{< image width="75%"
link="./istioday-session-1.jpg"
@@ -46,7 +46,7 @@ Hubo varias ponencias principales en el escenario principal donde se mencionó a
caption="KubeCon Europe 2025, Anunciando NeoNephos"
>}}
-Stephen Connolly compartió el viaje de HSBC con Kubernetes y también discutió [los planes para adoptar la malla ambient de Istio](https://youtu.be/6D8EZ1fZyh4?si=GvcSG28Lnuy5eTLD) para ahorrar en costos. Ant Group, que ganó el Premio de Usuario Final de la CNCF, también [destacó su uso de Istio](https://youtu.be/bjCT7-mFYEo?si=AUMoTzN713_qUVhh). Idit Levine y Keith Babo, de Solo.io, anunciaron [un estimador de ahorro de costos y una herramienta de migración gratuitos](https://youtu.be/-k1CdrRAGMM?si=sDKdfJG5GDn7FWfw) para la malla ambient de Istio. Faseela K tuvo una ponencia principal en un panel de usuarios finales de telecomunicaciones sobre [la evolución nativa de la nube en las telecomunicaciones](https://youtu.be/qj9q_-S91L8?si=8r3f1d396DSzp1Mg) con Vodafone, Orange y Swisscom, que nuevamente destacó el uso de Istio para las funciones de red de telecomunicaciones.
+Stephen Connolly compartió el viaje de HSBC con Kubernetes y también discutió [los planes para adoptar la mesh ambient de Istio](https://youtu.be/6D8EZ1fZyh4?si=GvcSG28Lnuy5eTLD) para ahorrar en costos. Ant Group, que ganó el Premio de Usuario Final de la CNCF, también [destacó su uso de Istio](https://youtu.be/bjCT7-mFYEo?si=AUMoTzN713_qUVhh). Idit Levine y Keith Babo, de Solo.io, anunciaron [un estimador de ahorro de costos y una herramienta de migración gratuitos](https://youtu.be/-k1CdrRAGMM?si=sDKdfJG5GDn7FWfw) para la mesh ambient de Istio. Faseela K tuvo una ponencia principal en un panel de usuarios finales de telecomunicaciones sobre [la evolución nativa de la nube en las telecomunicaciones](https://youtu.be/qj9q_-S91L8?si=8r3f1d396DSzp1Mg) con Vodafone, Orange y Swisscom, que nuevamente destacó el uso de Istio para las funciones de red de telecomunicaciones.
{{< image width="75%"
link="./kubecon-keynote-2.jpg"
@@ -90,7 +90,7 @@ Istio tenía un quiosco en el pabellón de proyectos, y la mayoría de las pregu
caption="KubeCon Europe 2025, Quiosco de Istio"
>}}
-Muchos de nuestros miembros del TOC y mantenedores también ofrecieron apoyo en el stand, donde también tuvieron lugar muchas discusiones interesantes sobre la malla ambient de Istio.
+Muchos de nuestros miembros del TOC y mantenedores también ofrecieron apoyo en el stand, donde también tuvieron lugar muchas discusiones interesantes sobre la mesh ambient de Istio.
{{< image width="75%"
link="./istio-booth-2.jpg"
diff --git a/content/es/boilerplates/gateway-api-choose.md b/content/es/boilerplates/gateway-api-choose.md
index 6cdebbffb461a..e988d161bcd1c 100644
--- a/content/es/boilerplates/gateway-api-choose.md
+++ b/content/es/boilerplates/gateway-api-choose.md
@@ -1,5 +1,5 @@
---
---
Las siguientes instrucciones te permiten elegir usar la API de Gateway o la API de configuración de Istio al configurar
-la gestión del tráfico en la malla. Sigue las instrucciones en las pestañas `Gateway API` o `Istio APIs`,
+la gestión del tráfico en la mesh. Sigue las instrucciones en las pestañas `Gateway API` o `Istio APIs`,
según tu preferencia.
diff --git a/content/es/boilerplates/kubectl-multicluster-contexts.md b/content/es/boilerplates/kubectl-multicluster-contexts.md
index 35fc3f2c780f3..2d0d60c079e15 100644
--- a/content/es/boilerplates/kubectl-multicluster-contexts.md
+++ b/content/es/boilerplates/kubectl-multicluster-contexts.md
@@ -21,6 +21,6 @@
{{< /text >}}
{{< tip >}}
- Si tienes más de dos clusteres en la lista de contextos y quieres configurar tu malla usando clusteres que no sean
+ Si tienes más de dos clusteres en la lista de contextos y quieres configurar tu mesh usando clusteres que no sean
los dos primeros, deberás establecer manualmente las variables de entorno a los nombres de contexto apropiados.
{{< /tip >}}
diff --git a/content/es/boilerplates/revision-tags-default-intro.md b/content/es/boilerplates/revision-tags-default-intro.md
index e0fe21144f959..f30a3b558a50f 100644
--- a/content/es/boilerplates/revision-tags-default-intro.md
+++ b/content/es/boilerplates/revision-tags-default-intro.md
@@ -6,6 +6,6 @@ realiza las siguientes funciones:
- Inyecta sidecars para el selector de namespace `istio-injection=enabled`, el selector de objetos `sidecar.istio.io/inject=true`
y los selectores `istio.io/rev=default`
- Valida los recursos de Istio
-- Roba el bloqueo de líder de las revisiones no predeterminadas y realiza responsabilidades de malla singleton (como actualizar los estados de los recursos)
+- Roba el bloqueo de líder de las revisiones no predeterminadas y realiza responsabilidades de meshsingleton (como actualizar los estados de los recursos)
Para hacer que una revisión `{{< istio_full_version_revision >}}` sea la predeterminada, ejecuta:
diff --git a/content/es/boilerplates/revision-tags-preamble.md b/content/es/boilerplates/revision-tags-preamble.md
index 87d804eb003e5..19c47b3ea5f47 100644
--- a/content/es/boilerplates/revision-tags-preamble.md
+++ b/content/es/boilerplates/revision-tags-preamble.md
@@ -2,4 +2,4 @@
---
Reetiquetar manualmente los namespaces al moverlos a una nueva revisión puede ser tedioso y propenso a errores.
Las [etiquetas de revisión](/es/docs/reference/commands/istioctl/#istioctl-tag) resuelven este problema.
-Las [etiquetas de revisión](/es/docs/reference/commands/istioctl/#istioctl-tag) son identificadores estables que apuntan a revisiones y se pueden usar para evitar reetiquetar namespaces. En lugar de reetiquetar el namespace, un operador de malla puede simplemente cambiar la etiqueta para que apunte a una nueva revisión. Todos los namespaces etiquetados con esa etiqueta se actualizarán al mismo tiempo.
+Las [etiquetas de revisión](/es/docs/reference/commands/istioctl/#istioctl-tag) son identificadores estables que apuntan a revisiones y se pueden usar para evitar reetiquetar namespaces. En lugar de reetiquetar el namespace, un operador de mesh puede simplemente cambiar la etiqueta para que apunte a una nueva revisión. Todos los namespaces etiquetados con esa etiqueta se actualizarán al mismo tiempo.
diff --git a/content/es/docs/ambient/architecture/data-plane/index.md b/content/es/docs/ambient/architecture/data-plane/index.md
index 97de1f51d9709..56604495cb78d 100644
--- a/content/es/docs/ambient/architecture/data-plane/index.md
+++ b/content/es/docs/ambient/architecture/data-plane/index.md
@@ -1,28 +1,28 @@
---
title: data plane Ambient
-description: Comprende cómo el data plane ambient enruta el tráfico entre los workloads en una malla ambient.
+description: Comprende cómo el data plane ambient enruta el tráfico entre los workloads en un ambient mesh.
weight: 2
owner: istio/wg-networking-maintainers
test: no
---
En el {{< gloss "ambient" >}}modo ambient{{< /gloss >}}, los workloads pueden clasificarse en 3 categorías:
-1. **Fuera de la malla**: un pod estándar sin ninguna característica de malla habilitada. Istio y el {{< gloss >}}data plane{{< /gloss >}} ambient no están habilitados.
-1. **En la malla**: un pod que está incluido en el {{< gloss >}}data plane{{< /gloss >}} ambient, y tiene el tráfico interceptado en el nivel de capa 4 por {{< gloss >}}ztunnel{{< /gloss >}}. En este modo, se pueden aplicar políticas L4 para el tráfico del pod. Este modo se puede habilitar estableciendo la etiqueta `istio.io/data plane-mode=ambient`. Consulta [etiquetas](/es/docs/ambient/usage/add-workloads/#ambient-labels) para obtener más detalles.
-1. **En la malla, con waypoint habilitado**: un pod que está _en la malla_ *y* tiene un {{< gloss "waypoint" >}}waypoint proxy{{< /gloss >}} desplegado. En este modo, se pueden aplicar políticas L7 para el tráfico del pod. Este modo se puede habilitar estableciendo la etiqueta `istio.io/use-waypoint`. Consulta [etiquetas](/es/docs/ambient/usage/add-workloads/#ambient-labels) para obtener más detalles.
+1. **Fuera de la mesh**: un pod estándar sin ninguna característica de mesh habilitada. Istio y el {{< gloss >}}data plane{{< /gloss >}} ambient no están habilitados.
+1. **En la mesh**: un pod que está incluido en el {{< gloss >}}data plane{{< /gloss >}} ambient, y tiene el tráfico interceptado en el nivel de capa 4 por {{< gloss >}}ztunnel{{< /gloss >}}. En este modo, se pueden aplicar políticas L4 para el tráfico del pod. Este modo se puede habilitar estableciendo la etiqueta `istio.io/data plane-mode=ambient`. Consulta [etiquetas](/es/docs/ambient/usage/add-workloads/#ambient-labels) para obtener más detalles.
+1. **En la mesh, con waypoint habilitado**: un pod que está _en la mesh_ *y* tiene un {{< gloss "waypoint" >}}waypoint proxy{{< /gloss >}} desplegado. En este modo, se pueden aplicar políticas L7 para el tráfico del pod. Este modo se puede habilitar estableciendo la etiqueta `istio.io/use-waypoint`. Consulta [etiquetas](/es/docs/ambient/usage/add-workloads/#ambient-labels) para obtener más detalles.
Dependiendo de la categoría en la que se encuentre una workload, la ruta del tráfico será diferente.
-## Enrutamiento en la malla
+## Enrutamiento en la mesh
### Saliente
-Cuando un pod en una malla ambient realiza una solicitud saliente, será [redirigido de forma transparente](/es/docs/ambient/architecture/traffic-redirection) al ztunnel local del nodo, que determinará dónde y cómo reenviar la solicitud.
+Cuando un pod en un ambient mesh realiza una solicitud saliente, será [redirigido de forma transparente](/es/docs/ambient/architecture/traffic-redirection) al ztunnel local del nodo, que determinará dónde y cómo reenviar la solicitud.
En general, el enrutamiento del tráfico se comporta igual que el enrutamiento de tráfico predeterminado de Kubernetes;
las solicitudes a un `Service` se enviarán a un endpoint dentro del `Service`, mientras que las solicitudes directas a una IP de `Pod` irán directamente a esa IP.
Sin embargo, dependiendo de las capacidades del destino, se producirá un comportamiento diferente.
-Si el destino también está agregado en la malla, o si tiene capacidades de proxy de Istio (como un sidecar), la solicitud se actualizará a un túnel {{< gloss "HBONE" >}}HBONE{{< /gloss >}} cifrado.
+Si el destino también está agregado en la mesh, o si tiene capacidades de proxy de Istio (como un sidecar), la solicitud se actualizará a un túnel {{< gloss "HBONE" >}}HBONE{{< /gloss >}} cifrado.
Si el destino tiene un waypoint proxy, además de actualizarse a HBONE, la solicitud se reenviará a ese waypoint para la aplicación de la política L7.
Ten en cuenta que en el caso de una solicitud a un `Service`, si el servicio *tiene* un waypoint, la solicitud se enviará a su waypoint para aplicar las políticas L7 al tráfico.
@@ -32,16 +32,16 @@ algunos pods usen un waypoint mientras que otros no. Generalmente se recomienda
### Entrante
-Cuando un pod en una malla ambient recibe una solicitud entrante, será [redirigido de forma transparente](/es/docs/ambient/architecture/traffic-redirection) al ztunnel local del nodo.
+Cuando un pod en un ambient mesh recibe una solicitud entrante, será [redirigido de forma transparente](/es/docs/ambient/architecture/traffic-redirection) al ztunnel local del nodo.
Cuando ztunnel recibe la solicitud, aplicará las Políticas de Autorización y reenviará la solicitud solo si la solicitud pasa estas comprobaciones.
Un pod puede recibir tráfico HBONE o tráfico de texto sin formato.
De forma predeterminada, ztunnel aceptará ambos.
-Las solicitudes de fuentes fuera de la malla no tendrán identidad de par cuando se evalúen las Políticas de Autorización,
+Las solicitudes de fuentes fuera de la mesh no tendrán identidad de par cuando se evalúen las Políticas de Autorización,
un usuario puede establecer una política que requiera una identidad (ya sea *cualquier* identidad o una específica) para bloquear todo el tráfico de texto sin formato.
-Cuando el destino está habilitado para waypoint, si el origen está en la malla ambient, el ztunnel del origen garantiza que la solicitud **pasará** a través
-del waypoint donde se aplica la política. Sin embargo, una workload fuera de la malla no sabe nada sobre los proxies de waypoint, por lo que envía
+Cuando el destino está habilitado para waypoint, si el origen está en la mesh ambient, el ztunnel del origen garantiza que la solicitud **pasará** a través
+del waypoint donde se aplica la política. Sin embargo, una workload fuera de la mesh no sabe nada sobre los proxies de waypoint, por lo que envía
solicitudes directamente al destino sin pasar por ningún proxy de waypoint, incluso si el destino está habilitado para waypoint.
Actualmente, el tráfico de los sidecars y las gateways tampoco pasará por ningún proxy de waypoint y se les informará sobre los proxies de waypoint
en una versión futura.
@@ -50,13 +50,13 @@ en una versión futura.
##### Identidad
-Todo el tráfico TCP L4 entrante y saliente entre los workloads en la malla ambient está protegido por el data plane, utilizando mTLS a través de {{< gloss >}}HBONE{{< /gloss >}}, ztunnel y certificados x509.
+Todo el tráfico TCP L4 entrante y saliente entre los workloads en la mesh ambient está protegido por el data plane, utilizando mTLS a través de {{< gloss >}}HBONE{{< /gloss >}}, ztunnel y certificados x509.
Según lo exige {{< gloss "mutual tls authentication" >}}mTLS{{< /gloss >}}, el origen y el destino deben tener identidades x509 únicas, y esas identidades deben usarse para establecer el canal cifrado para esa conexión.
Esto requiere que ztunnel gestione múltiples certificados de workload distintos, en nombre de los workloads proxiadas, uno para cada identidad única (cuenta de servicio) para cada pod local del nodo. La propia identidad de Ztunnel nunca se utiliza para las conexiones mTLS entre los workloads.
-Al obtener certificados, ztunnel se autenticará en la CA con su propia identidad, pero solicitará la identidad de otra workload. Críticamente, la CA debe hacer cumplir que el ztunnel tiene permiso para solicitar esa identidad. Las solicitudes de identidades que no se ejecutan en el nodo se rechazan. Esto es fundamental para garantizar que un nodo comprometido no comprometa toda la malla.
+Al obtener certificados, ztunnel se autenticará en la CA con su propia identidad, pero solicitará la identidad de otra workload. Críticamente, la CA debe hacer cumplir que el ztunnel tiene permiso para solicitar esa identidad. Las solicitudes de identidades que no se ejecutan en el nodo se rechazan. Esto es fundamental para garantizar que un nodo comprometido no comprometa toda la mesh.
Esta aplicación de la CA la realiza la CA de Istio utilizando un token JWT de la Cuenta de Servicio de Kubernetes, que codifica la información del pod. Esta aplicación también es un requisito para cualquier CA alternativa que se integre con ztunnel.
@@ -77,7 +77,7 @@ link="ztunnel-datapath-1.png"
caption="Ruta de datos básica de solo L4 de ztunnel"
>}}
-La figura muestra varios workloads agregadas a la malla ambient, que se ejecutan en los nodos W1 y W2 de un cluster de Kubernetes. Hay una única instancia del proxy ztunnel en cada nodo. En este escenario, los pods de cliente de la aplicación C1, C2 y C3 necesitan acceder a un servicio proporcionado por el pod S1. No hay ningún requisito para las características avanzadas de L7, como el enrutamiento de tráfico L7 o la gestión de tráfico L7, por lo que un data plane L4 es suficiente para obtener {{< gloss "mutual tls authentication" >}}mTLS{{< /gloss >}} y la aplicación de políticas L4; no se requiere ningún proxy de waypoint.
+La figura muestra varios workloads agregadas a la mesh ambient, que se ejecutan en los nodos W1 y W2 de un cluster de Kubernetes. Hay una única instancia del proxy ztunnel en cada nodo. En este escenario, los pods de cliente de la aplicación C1, C2 y C3 necesitan acceder a un servicio proporcionado por el pod S1. No hay ningún requisito para las características avanzadas de L7, como el enrutamiento de tráfico L7 o la gestión de tráfico L7, por lo que un data plane L4 es suficiente para obtener {{< gloss "mutual tls authentication" >}}mTLS{{< /gloss >}} y la aplicación de políticas L4; no se requiere ningún proxy de waypoint.
La figura muestra que los pods C1 y C2, que se ejecutan en el nodo W1, se conectan con el pod S1 que se ejecuta en el nodo W2.
@@ -89,7 +89,7 @@ Nota: Aunque la figura muestra que los túneles HBONE se encuentran entre los do
Ten en cuenta que el tráfico local, que se muestra en la figura desde el pod C3 hasta el pod de destino S1 en el nodo de trabajo W2, también atraviesa la instancia de proxy ztunnel local, de modo que las funciones de gestión de tráfico L4, como la Autorización L4 y la Telemetría L4, se aplicarán de forma idéntica en el tráfico, ya sea que cruce o no un límite de nodo.
-## Enrutamiento en malla con waypoint habilitado
+## Enrutamiento en mesh con waypoint habilitado
Los waypoints de Istio reciben exclusivamente tráfico HBONE.
Al recibir una solicitud, el waypoint se asegurará de que el tráfico sea para un `Pod` o `Service` que lo utilice.
diff --git a/content/es/docs/ambient/architecture/traffic-redirection/index.md b/content/es/docs/ambient/architecture/traffic-redirection/index.md
index ae083dfe75137..73f633e029db8 100644
--- a/content/es/docs/ambient/architecture/traffic-redirection/index.md
+++ b/content/es/docs/ambient/architecture/traffic-redirection/index.md
@@ -21,14 +21,14 @@ La siguiente figura ilustra la secuencia de eventos cuando se inicia un nuevo po
{{< image width="100%"
link="./pod-added-to-ambient.svg"
-alt="flujo de pod agregado a la malla ambient"
+alt="flujo de pod agregado a la mesh ambient"
>}}
El agente de nodo `istio-cni` responde a los eventos de CNI, como la creación y eliminación de pods, y también observa el servidor de la API de Kubernetes subyacente en busca de eventos como la adición de la etiqueta ambient a un pod o namespaces.
El agente de nodo `istio-cni` además instala un complemento CNI encadenado que es ejecutado por el tiempo de ejecución del contenedor después de que se ejecuta el complemento CNI principal dentro de ese cluster de Kubernetes. Su único propósito es notificar al agente de nodo `istio-cni` cuando el tiempo de ejecución del contenedor crea un nuevo pod en un namespaces que ya está inscrito en el modo ambient, y propagar el contexto del nuevo pod a `istio-cni`.
-Una vez que se notifica al agente de nodo `istio-cni` que se debe agregar un pod a la malla (ya sea desde el complemento CNI, si el pod es nuevo, o desde el servidor de la API de Kubernetes, si el pod ya se está ejecutando pero necesita ser agregado), se realiza la siguiente secuencia de operaciones:
+Una vez que se notifica al agente de nodo `istio-cni` que se debe agregar un pod a la mesh (ya sea desde el complemento CNI, si el pod es nuevo, o desde el servidor de la API de Kubernetes, si el pod ya se está ejecutando pero necesita ser agregado), se realiza la siguiente secuencia de operaciones:
- `istio-cni` ingresa al namespaces de red del pod y establece reglas de redirección de red, de modo que los paquetes que entran y salen del pod se interceptan y se redirigen de forma transparente a la instancia de proxy ztunnel local del nodo que escucha en los [puertos conocidos](https://github.com/istio/ztunnel/blob/master/ARCHITECTURE.md#ports) (15008, 15006, 15001).
@@ -37,17 +37,17 @@ Una vez que se notifica al agente de nodo `istio-cni` que se debe agregar un pod
- El ztunnel local del nodo internamente crea una nueva instancia de proxy lógico y un conjunto de puertos de escucha, dedicados al pod recién agregado. Ten en cuenta que esto todavía se está ejecutando dentro del mismo proceso y es simplemente una tarea dedicada para el pod.
-- Una vez que las reglas de redirección en el pod están en su lugar y el ztunnel ha establecido los puertos de escucha, el pod se agrega a la malla y el tráfico comienza a fluir a través del ztunnel local del nodo.
+- Una vez que las reglas de redirección en el pod están en su lugar y el ztunnel ha establecido los puertos de escucha, el pod se agrega a la mesh y el tráfico comienza a fluir a través del ztunnel local del nodo.
-El tráfico hacia y desde los pods en la malla se cifrará completamente con mTLS de forma predeterminada.
+El tráfico hacia y desde los pods en la mesh se cifrará completamente con mTLS de forma predeterminada.
-Los datos ahora entrarán y saldrán del namespace de red del pod cifrados. Cada pod en la malla tiene la capacidad de hacer cumplir la política de la malla y cifrar el tráfico de forma segura, aunque la aplicación de usuario que se ejecuta en el pod no tiene conocimiento de ninguna de las dos cosas.
+Los datos ahora entrarán y saldrán del namespace de red del pod cifrados. Cada pod en la mesh tiene la capacidad de hacer cumplir la política de la mesh y cifrar el tráfico de forma segura, aunque la aplicación de usuario que se ejecuta en el pod no tiene conocimiento de ninguna de las dos cosas.
-Este diagrama ilustra cómo fluye el tráfico cifrado entre los pods en la malla ambient en el nuevo modelo:
+Este diagrama ilustra cómo fluye el tráfico cifrado entre los pods en la mesh ambient en el nuevo modelo:
{{< image width="100%"
link="./traffic-flows-between-pods-in-ambient.svg"
- alt="El tráfico HBONE fluye entre los pods en la malla ambient"
+ alt="El tráfico HBONE fluye entre los pods en la mesh ambient"
>}}
## Observación y depuración de la redirección de tráfico en modo ambient
@@ -56,7 +56,7 @@ Si la redirección de tráfico no funciona correctamente en el modo ambient, se
### Comprobar los registros del proxy ztunnel
-Cuando un pod de aplicación forma parte de una malla ambient, puedes comprobar los registros del proxy ztunnel para confirmar que la malla está redirigiendo el tráfico. Como se muestra en el siguiente ejemplo, los registros de ztunnel relacionados con `inpod` indican que el modo de redirección en el pod está habilitado, que el proxy ha recibido la información del namespace de red (netns) sobre un pod de aplicación ambient y que ha comenzado a actuar como proxy para él.
+Cuando un pod de aplicación forma parte de un ambient mesh, puedes comprobar los registros del proxy ztunnel para confirmar que la mesh está redirigiendo el tráfico. Como se muestra en el siguiente ejemplo, los registros de ztunnel relacionados con `inpod` indican que el modo de redirección en el pod está habilitado, que el proxy ha recibido la información del namespace de red (netns) sobre un pod de aplicación ambient y que ha comenzado a actuar como proxy para él.
{{< text bash >}}
$ kubectl logs ds/ztunnel -n istio-system | grep inpod
diff --git a/content/es/docs/ambient/getting-started/cleanup/index.md b/content/es/docs/ambient/getting-started/cleanup/index.md
index 9a0fa05b9e3dd..474e4794e571d 100644
--- a/content/es/docs/ambient/getting-started/cleanup/index.md
+++ b/content/es/docs/ambient/getting-started/cleanup/index.md
@@ -20,7 +20,7 @@ $ istioctl waypoint delete --all
## Eliminar el namespace del data plane ambient
-La etiqueta que indica a Istio que incluya automáticamente las aplicaciones enel namespace `default` en la malla ambient no se elimina al desinstalar Istio. Utiliza el siguiente comando para eliminarla:
+La etiqueta que indica a Istio que incluya automáticamente las aplicaciones enel namespace `default` en la mesh ambient no se elimina al desinstalar Istio. Utiliza el siguiente comando para eliminarla:
{{< text bash >}}
$ kubectl label namespace default istio.io/data plane-mode-
diff --git a/content/es/docs/ambient/getting-started/deploy-sample-app/index.md b/content/es/docs/ambient/getting-started/deploy-sample-app/index.md
index 385ef5c03ae55..f35758c5ca758 100644
--- a/content/es/docs/ambient/getting-started/deploy-sample-app/index.md
+++ b/content/es/docs/ambient/getting-started/deploy-sample-app/index.md
@@ -77,4 +77,4 @@ Si actualizas la página, deberías ver que la visualización de las calificacio
## Próximos pasos
-[Continúa con la siguiente sección](../secure-and-visualize/) para agregar la aplicación a la malla y aprender a proteger y visualizar la comunicación entre las aplicaciones.
+[Continúa con la siguiente sección](../secure-and-visualize/) para agregar la aplicación a la mesh y aprender a proteger y visualizar la comunicación entre las aplicaciones.
diff --git a/content/es/docs/ambient/getting-started/enforce-auth-policies/index.md b/content/es/docs/ambient/getting-started/enforce-auth-policies/index.md
index a40b8e65bf81f..ee38ee0ddd299 100644
--- a/content/es/docs/ambient/getting-started/enforce-auth-policies/index.md
+++ b/content/es/docs/ambient/getting-started/enforce-auth-policies/index.md
@@ -1,14 +1,14 @@
---
title: Aplicar políticas de autorización
-description: Aplicar políticas de autorización de capa 4 y capa 7 en una malla ambient.
+description: Aplicar políticas de autorización de capa 4 y capa 7 en un ambient mesh.
weight: 4
owner: istio/wg-networking-maintainers
test: yes
---
-Después de haber agregado tu aplicación a la malla ambient, puedes proteger el acceso a la aplicación utilizando políticas de autorización de capa 4.
+Después de haber agregado tu aplicación a la mesh ambient, puedes proteger el acceso a la aplicación utilizando políticas de autorización de capa 4.
-Esta característica te permite controlar el acceso hacia y desde un servicio en función de las identidades de los workloads del cliente que se emiten automáticamente a todas los workloads en la malla.
+Esta característica te permite controlar el acceso hacia y desde un servicio en función de las identidades de los workloads del cliente que se emiten automáticamente a todas los workloads en la mesh.
## Aplicar la política de autorización de capa 4
diff --git a/content/es/docs/ambient/getting-started/secure-and-visualize/index.md b/content/es/docs/ambient/getting-started/secure-and-visualize/index.md
index 61d38c3a441f9..79606ee00219a 100644
--- a/content/es/docs/ambient/getting-started/secure-and-visualize/index.md
+++ b/content/es/docs/ambient/getting-started/secure-and-visualize/index.md
@@ -6,18 +6,18 @@ owner: istio/wg-networking-maintainers
test: yes
---
-Agregar aplicaciones a una malla ambient es tan simple como etiquetarel namespace donde reside la aplicación. Al agregar las aplicaciones a la malla, proteges automáticamente la comunicación entre ellas e Istio comienza a recopilar telemetría TCP. Y no, ¡no necesitas reiniciar ni volver a desplegar las aplicaciones!
+Agregar aplicaciones a un ambient mesh es tan simple como etiquetarel namespace donde reside la aplicación. Al agregar las aplicaciones a la mesh, proteges automáticamente la comunicación entre ellas e Istio comienza a recopilar telemetría TCP. Y no, ¡no necesitas reiniciar ni volver a desplegar las aplicaciones!
-## Agregar Bookinfo a la malla
+## Agregar Bookinfo a la mesh
-Puedes habilitar que todos los pods en un namespaces determinado formen parte de una malla ambient simplemente etiquetandoel namespace:
+Puedes habilitar que todos los pods en un namespaces determinado formen parte de un ambient mesh simplemente etiquetandoel namespace:
{{< text bash >}}
$ kubectl label namespace default istio.io/data plane-mode=ambient
namespace/default labeled
{{< /text >}}
-¡Felicidades! Has agregado correctamente todos los pods enel namespace predeterminado a la malla ambient. 🎉
+¡Felicidades! Has agregado correctamente todos los pods enel namespace predeterminado a la mesh ambient. 🎉
Si abres la aplicación Bookinfo en tu navegador, verás la página del producto, como antes. La diferencia esta vez es que la comunicación entre los pods de la aplicación Bookinfo está cifrada mediante mTLS. Además, Istio está recopilando telemetría TCP para todo el tráfico entre los pods.
diff --git a/content/es/docs/ambient/install/helm/all-in-one/index.md b/content/es/docs/ambient/install/helm/all-in-one/index.md
index 3f77fbc0ab5a4..55e136a6385ad 100644
--- a/content/es/docs/ambient/install/helm/all-in-one/index.md
+++ b/content/es/docs/ambient/install/helm/all-in-one/index.md
@@ -8,7 +8,7 @@ draft: true
---
{{< tip >}}
-Sigue esta guía para instalar y configurar una malla de Istio con soporte para el modo ambient.
+Sigue esta guía para instalar y configurar un mesh de Istio con soporte para el modo ambient.
Si eres nuevo en Istio y solo quieres probarlo, sigue las
[instrucciones de inicio rápido](/es/docs/ambient/getting-started) en su lugar.
{{< /tip >}}
@@ -134,7 +134,7 @@ ztunnel-c2z4s 1/1 Running 0 10m
### Verificar con la aplicación de ejemplo
Después de instalar el modo ambient con Helm, puedes seguir la guía [Desplegar la aplicación de ejemplo](/es/docs/ambient/getting-started/deploy-sample-app/) para desplegar la aplicación de ejemplo y las gateways de entrada, y luego puedes
-[agregar tu aplicación a la malla ambient](/es/docs/ambient/getting-started/secure-and-visualize/#add-bookinfo-to-the-mesh).
+[agregar tu aplicación a la mesh ambient](/es/docs/ambient/getting-started/secure-and-visualize/#add-bookinfo-to-the-mesh).
## Desinstalar
diff --git a/content/es/docs/ambient/install/helm/index.md b/content/es/docs/ambient/install/helm/index.md
index b41b92393b34a..a8664e6f4bb74 100644
--- a/content/es/docs/ambient/install/helm/index.md
+++ b/content/es/docs/ambient/install/helm/index.md
@@ -12,7 +12,7 @@ test: yes
---
{{< tip >}}
-Sigue esta guía para instalar y configurar una malla de Istio con soporte para el modo ambient.
+Sigue esta guía para instalar y configurar un mesh de Istio con soporte para el modo ambient.
Si eres nuevo en Istio y solo quieres probarlo, sigue las
[instrucciones de inicio rápido](/es/docs/ambient/getting-started) en su lugar.
{{< /tip >}}
@@ -60,7 +60,7 @@ $ helm install istio-base istio/base -n istio-system --create-namespace --wait
### control plane istiod
El chart `istiod` instala una revisión de Istiod. Istiod es el componente del control plane que gestiona y
-configura los proxies para enrutar el tráfico dentro de la malla.
+configura los proxies para enrutar el tráfico dentro de la mesh.
{{< text syntax=bash snip_id=install_istiod >}}
$ helm install istiod istio/istiod --namespace istio-system --set profile=ambient --wait
@@ -68,7 +68,7 @@ $ helm install istiod istio/istiod --namespace istio-system --set profile=ambien
### Agente de nodo CNI
-El chart `cni` instala el agente de nodo CNI de Istio. Es responsable de detectar los pods que pertenecen a la malla ambient y de configurar la redirección del tráfico entre los pods y el proxy de nodo ztunnel (que se instalará más adelante).
+El chart `cni` instala el agente de nodo CNI de Istio. Es responsable de detectar los pods que pertenecen a la mesh ambient y de configurar la redirección del tráfico entre los pods y el proxy de nodo ztunnel (que se instalará más adelante).
{{< text syntax=bash snip_id=install_cni >}}
$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --wait
@@ -136,7 +136,7 @@ ztunnel-c2z4s 1/1 Running 0 10m
### Verificar con la aplicación de ejemplo
Después de instalar el modo ambient con Helm, puedes seguir la guía [Desplegar la aplicación de ejemplo](/es/docs/ambient/getting-started/deploy-sample-app/) para desplegar la aplicación de ejemplo y las gateways de entrada, y luego puedes
-[agregar tu aplicación a la malla ambient](/es/docs/ambient/getting-started/secure-and-visualize/#add-bookinfo-to-the-mesh).
+[agregar tu aplicación a la mesh ambient](/es/docs/ambient/getting-started/secure-and-visualize/#add-bookinfo-to-the-mesh).
## Desinstalar
diff --git a/content/es/docs/ambient/install/istioctl/index.md b/content/es/docs/ambient/install/istioctl/index.md
index a4a84bffa58a3..71f0e92c96cdb 100644
--- a/content/es/docs/ambient/install/istioctl/index.md
+++ b/content/es/docs/ambient/install/istioctl/index.md
@@ -8,7 +8,7 @@ test: yes
---
{{< tip >}}
-Sigue esta guía para instalar y configurar una malla de Istio con soporte para el modo ambient.
+Sigue esta guía para instalar y configurar un mesh de Istio con soporte para el modo ambient.
Si eres nuevo en Istio y solo quieres probarlo, sigue las
[instrucciones de inicio rápido](/es/docs/ambient/getting-started) en su lugar.
{{< /tip >}}
diff --git a/content/es/docs/ambient/overview/index.md b/content/es/docs/ambient/overview/index.md
index 126b42d6023bd..f5e93f8abfb2d 100644
--- a/content/es/docs/ambient/overview/index.md
+++ b/content/es/docs/ambient/overview/index.md
@@ -10,14 +10,14 @@ En el **modo ambient**, Istio implementa sus [características](/es/docs/concept
Este enfoque por capas te permite adoptar Istio de una manera más incremental, pasando sin problemas de ninguna malla, a una superposición L4 segura, a un procesamiento y políticas L7 completos, por namespaces, según sea necesario. Además, los workloads que se ejecutan en diferentes modos de {{< gloss >}}data plane{{< /gloss >}} de Istio interoperan sin problemas, lo que permite a los usuarios mezclar y combinar capacidades en función de sus necesidades particulares a medida que cambian con el tiempo.
-Dado que los pods de workload ya no requieren que los proxies se ejecuten en sidecars para participar en la malla, el modo ambient a menudo se conoce informalmente como "malla sin sidecar".
+Dado que los pods de workload ya no requieren que los proxies se ejecuten en sidecars para participar en la mesh, el modo ambient a menudo se conoce informalmente como "sidecarless mesh".
## Cómo funciona
El modo ambient divide la funcionalidad de Istio en dos capas distintas. En la base, la superposición segura **ztunnel** se encarga del enrutamiento y la seguridad de zero-trust para el tráfico. Por encima de eso, cuando sea necesario, los usuarios pueden habilitar los **waypoint proxies** L7 para obtener acceso a la gama completa de características de Istio. Los proxies de waypoint, aunque más pesados que la superposición de ztunnel sola, todavía se ejecutan como un componente ambient de la infraestructura, sin requerir modificaciones en los pods de la aplicación.
{{< tip >}}
-Los pods y los workloads que usan el modo sidecar pueden coexistir dentro de la misma malla que los pods que usan el modo ambient. El término "malla ambient" se refiere a una malla de Istio que se instaló con soporte para el modo ambient y, por lo tanto, puede admitir pods de malla que usan cualquier tipo de data plane.
+Los pods y los workloads que usan el modo sidecar pueden coexistir dentro de la misma mesh que los pods que usan el modo ambient. El término "ambient mesh" se refiere a un mesh de Istio que se instaló con soporte para el modo ambient y, por lo tanto, puede admitir pods de mesh que usan cualquier tipo de data plane.
{{< /tip >}}
Para obtener detalles sobre el diseño del modo ambient y cómo interactúa con el {{< gloss >}}control plane{{< /gloss >}} de Istio, consulta la documentación de arquitectura del [data plane](/es/docs/ambient/architecture/data-plane) y del [control plane](/es/docs/ambient/architecture/control-plane).
@@ -26,9 +26,9 @@ Para obtener detalles sobre el diseño del modo ambient y cómo interactúa con
El componente ztunnel (túnel de Zero Trust) es un proxy por nodo especialmente diseñado que impulsa el modo de data plane ambient de Istio.
-Ztunnel es responsable de conectar y autenticar de forma segura los workloads dentro de la malla. El proxy ztunnel está escrito en Rust y tiene un alcance intencional para manejar funciones L3 y L4 como mTLS, autenticación, autorización L4 y telemetría. Ztunnel no termina el tráfico HTTP de el workload ni analiza los encabezados HTTP de el workload. El ztunnel garantiza que el tráfico L3 y L4 se transporte de manera eficiente y segura directamente a los workloads, a otros proxies ztunnel o a los proxies de waypoint.
+Ztunnel es responsable de conectar y autenticar de forma segura los workloads dentro de la mesh. El proxy ztunnel está escrito en Rust y tiene un alcance intencional para manejar funciones L3 y L4 como mTLS, autenticación, autorización L4 y telemetría. Ztunnel no termina el tráfico HTTP de el workload ni analiza los encabezados HTTP de el workload. El ztunnel garantiza que el tráfico L3 y L4 se transporte de manera eficiente y segura directamente a los workloads, a otros proxies ztunnel o a los proxies de waypoint.
-El término "superposición segura" se utiliza para describir colectivamente el conjunto de funciones de red L4 implementadas en una malla ambient a través del proxy ztunnel. En la capa de transporte, esto se implementa a través de un protocolo de tunelización de tráfico basado en HTTP CONNECT llamado [HBONE](/es/docs/ambient/architecture/hbone).
+El término "superposición segura" se utiliza para describir colectivamente el conjunto de funciones de red L4 implementadas en un ambient mesh a través del proxy ztunnel. En la capa de transporte, esto se implementa a través de un protocolo de tunelización de tráfico basado en HTTP CONNECT llamado [HBONE](/es/docs/ambient/architecture/hbone).
## Waypoint proxies
diff --git a/content/es/docs/ambient/upgrade/helm/all-in-one/index.md b/content/es/docs/ambient/upgrade/helm/all-in-one/index.md
index 9a45e7ef62e69..8b3c5d88e3119 100644
--- a/content/es/docs/ambient/upgrade/helm/all-in-one/index.md
+++ b/content/es/docs/ambient/upgrade/helm/all-in-one/index.md
@@ -43,7 +43,7 @@ $ helm repo update istio
### Actualizar el control plane y el data plane ambient de Istio
{{< warning >}}
-La actualización mediante el chart contenedor in-place interrumpirá brevemente todo el tráfico de la malla ambient en el nodo, **incluso con el uso de revisiones**. En la práctica, el período de interrupción es una ventana muy pequeña, que afecta principalmente a las conexiones de larga duración.
+La actualización mediante el chart contenedor in-place interrumpirá brevemente todo el tráfico de la mesh ambient en el nodo, **incluso con el uso de revisiones**. En la práctica, el período de interrupción es una ventana muy pequeña, que afecta principalmente a las conexiones de larga duración.
Se recomienda el acordonamiento de nodos y los grupos de nodos azul/verde para mitigar el riesgo del radio de explosión durante las actualizaciones de producción. Consulta la documentación de tu proveedor de Kubernetes para obtener más detalles.
{{< /warning >}}
diff --git a/content/es/docs/ambient/upgrade/helm/index.md b/content/es/docs/ambient/upgrade/helm/index.md
index db1e80ce3fef9..587339186e0ba 100644
--- a/content/es/docs/ambient/upgrade/helm/index.md
+++ b/content/es/docs/ambient/upgrade/helm/index.md
@@ -56,7 +56,7 @@ No se necesitan preparaciones adicionales para las actualizaciones in-place, pro
### Organiza tus etiquetas y revisiones
-Para actualizar una malla en modo ambient de manera controlada, recomendamos que tus gateways y namespaces usen la etiqueta `istio.io/rev` para especificar una etiqueta de revisión para controlar qué versiones de gateway y control plane se usarán para administrar el tráfico de tus workloads. Recomendamos dividir tu cluster de producción en múltiples etiquetas para organizar tu actualización. Todos los miembros de una etiqueta determinada se actualizarán simultáneamente, por lo que es aconsejable comenzar la actualización con tus aplicaciones de menor riesgo. No recomendamos hacer referencia a las revisiones directamente a través de etiquetas para las actualizaciones, ya que este proceso puede resultar fácilmente en la actualización accidental de una gran cantidad de proxies y es difícil de segmentar. Para ver qué etiquetas y revisiones estás usando en tu cluster, consulta la sección sobre la actualización de etiquetas.
+Para actualizar un mesh en modo ambient de manera controlada, recomendamos que tus gateways y namespaces usen la etiqueta `istio.io/rev` para especificar una etiqueta de revisión para controlar qué versiones de gateway y control plane se usarán para administrar el tráfico de tus workloads. Recomendamos dividir tu cluster de producción en múltiples etiquetas para organizar tu actualización. Todos los miembros de una etiqueta determinada se actualizarán simultáneamente, por lo que es aconsejable comenzar la actualización con tus aplicaciones de menor riesgo. No recomendamos hacer referencia a las revisiones directamente a través de etiquetas para las actualizaciones, ya que este proceso puede resultar fácilmente en la actualización accidental de una gran cantidad de proxies y es difícil de segmentar. Para ver qué etiquetas y revisiones estás usando en tu cluster, consulta la sección sobre la actualización de etiquetas.
### Elige un nombre de revisión
@@ -91,7 +91,7 @@ $ helm upgrade istio-base istio/base -n istio-system
### control plane istiod
-El control plane [Istiod](/es/docs/ops/deployment/architecture/#istiod) gestiona y configura los proxies que enrutan el tráfico dentro de la malla. El siguiente comando instalará una nueva instancia del control plane junto con la actual, pero no introducirá nuevos proxies de gateway o waypoints, ni tomará el control de los existentes.
+El control plane [Istiod](/es/docs/ops/deployment/architecture/#istiod) gestiona y configura los proxies que enrutan el tráfico dentro de la mesh. El siguiente comando instalará una nueva instancia del control plane junto con la actual, pero no introducirá nuevos proxies de gateway o waypoints, ni tomará el control de los existentes.
Si has personalizado tu instalación de istiod, puedes reutilizar el archivo `values.yaml` de actualizaciones o instalaciones anteriores para mantener la coherencia de tus planos de control.
@@ -117,14 +117,14 @@ $ helm install istiod-"$REVISION" istio/istiod -n istio-system --set revision="$
### Agente de nodo CNI
-El agente de nodo CNI de Istio es responsable de detectar los pods agregados a la malla ambient, informar a ztunnel que se deben establecer los puertos de proxy dentro de los pods agregados y configurar la redirección del tráfico dentro del namespace de red del pod. No forma parte del data plane ni del control plane.
+El agente de nodo CNI de Istio es responsable de detectar los pods agregados a la mesh ambient, informar a ztunnel que se deben establecer los puertos de proxy dentro de los pods agregados y configurar la redirección del tráfico dentro del namespace de red del pod. No forma parte del data plane ni del control plane.
El CNI en la versión 1.x es compatible con el control plane en la versión 1.x+1 y 1.x. Esto significa que el control plane debe actualizarse antes que el CNI de Istio, siempre que la diferencia de versión sea de una versión menor.
{{< warning >}}
Istio actualmente no admite actualizaciones canary de istio-cni, **incluso con el uso de revisiones**. Si esto es una preocupación de interrupción significativa para tu entorno, o si se desean controles de radio de explosión más estrictos para las actualizaciones de CNI, se recomienda posponer las actualizaciones de `istio-cni` hasta que los propios nodos se drenen y actualicen, o aprovechar los taints de los nodos y orquestar manualmente la actualización para este componente.
-El agente de nodo CNI de Istio es un DaemonSet [system-node-critical](https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/). **Debe** estar ejecutándose en cada nodo para que se mantengan las garantías de seguridad y operativas del tráfico ambient de Istio en ese nodo. De forma predeterminada, el DaemonSet del agente de nodo CNI de Istio admite actualizaciones seguras in-place y, mientras se actualiza o reinicia, evitará que se inicien nuevos pods en ese nodo hasta que haya una instancia del agente disponible en el nodo para manejarlos, con el fin de evitar fugas de tráfico no seguras. Los pods existentes que ya se hayan agregado con éxito a la malla ambient antes de la actualización continuarán operando bajo los requisitos de seguridad de tráfico de Istio durante la actualización.
+El agente de nodo CNI de Istio es un DaemonSet [system-node-critical](https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/). **Debe** estar ejecutándose en cada nodo para que se mantengan las garantías de seguridad y operativas del tráfico ambient de Istio en ese nodo. De forma predeterminada, el DaemonSet del agente de nodo CNI de Istio admite actualizaciones seguras in-place y, mientras se actualiza o reinicia, evitará que se inicien nuevos pods en ese nodo hasta que haya una instancia del agente disponible en el nodo para manejarlos, con el fin de evitar fugas de tráfico no seguras. Los pods existentes que ya se hayan agregado con éxito a la mesh ambient antes de la actualización continuarán operando bajo los requisitos de seguridad de tráfico de Istio durante la actualización.
{{< /warning >}}
{{< text syntax=bash snip_id=upgrade_cni >}}
@@ -138,7 +138,7 @@ $ helm upgrade istio-cni istio/cni -n istio-system
El DaemonSet de {{< gloss >}}ztunnel{{< /gloss >}} es el componente de proxy de nodo. El ztunnel en la versión 1.x es compatible con el control plane en la versión 1.x+1 y 1.x. Esto significa que el control plane debe actualizarse antes que ztunnel, siempre que la diferencia de versión sea de una versión menor. Si has personalizado previamente tu instalación de ztunnel, puedes reutilizar el archivo `values.yaml` de actualizaciones o instalaciones anteriores para mantener la coherencia de tu {{< gloss >}}data plane{{< /gloss >}}.
{{< warning >}}
-La actualización de ztunnel in-place interrumpirá brevemente todo el tráfico de la malla ambient en el nodo, **incluso con el uso de revisiones**. En la práctica, el período de interrupción es una ventana muy pequeña, que afecta principalmente a las conexiones de larga duración.
+La actualización de ztunnel in-place interrumpirá brevemente todo el tráfico de la mesh ambient en el nodo, **incluso con el uso de revisiones**. En la práctica, el período de interrupción es una ventana muy pequeña, que afecta principalmente a las conexiones de larga duración.
Se recomienda el acordonamiento de nodos y los grupos de nodos azul/verde para mitigar el riesgo del radio de explosión durante las actualizaciones de producción. Consulta la documentación de tu proveedor de Kubernetes para obtener más detalles.
{{< /warning >}}
diff --git a/content/es/docs/ambient/usage/_index.md b/content/es/docs/ambient/usage/_index.md
index 4e4d50749c298..74b868616b851 100644
--- a/content/es/docs/ambient/usage/_index.md
+++ b/content/es/docs/ambient/usage/_index.md
@@ -1,6 +1,6 @@
---
title: Guías de usuario
-description: Cómo configurar tu malla para aprovechar el modo ambient.
+description: Cómo configurar tu mesh para aprovechar el modo ambient.
weight: 15
aliases:
- /docs/ops/ambient/usage
diff --git a/content/es/docs/ambient/usage/add-workloads/index.md b/content/es/docs/ambient/usage/add-workloads/index.md
index 5bf8e01b7bf5f..b02206f6a7a09 100644
--- a/content/es/docs/ambient/usage/add-workloads/index.md
+++ b/content/es/docs/ambient/usage/add-workloads/index.md
@@ -1,18 +1,18 @@
---
-title: Agregar workloads a la malla
-description: Comprende cómo agregar workloads a una malla ambient.
+title: Agregar workloads a la mesh
+description: Comprende cómo agregar workloads a un ambient mesh.
weight: 10
owner: istio/wg-networking-maintainers
test: no
---
-En la mayoría de los casos, un administrador de cluster desplegará la infraestructura de la malla de Istio. Una vez que Istio se despliegue con éxito con soporte para el modo de {{< gloss >}}data plane{{< /gloss >}} ambient, estará disponible de forma transparente para las aplicaciones desplegadas por todos los usuarios en los namespaces que se hayan configurado para usarlo.
+En la mayoría de los casos, un administrador de cluster desplegará la infraestructura de la mesh de Istio. Una vez que Istio se despliegue con éxito con soporte para el modo de {{< gloss >}}data plane{{< /gloss >}} ambient, estará disponible de forma transparente para las aplicaciones desplegadas por todos los usuarios en los namespaces que se hayan configurado para usarlo.
-## Habilitar el modo ambient para aplicaciones en la malla
+## Habilitar el modo ambient para aplicaciones en la mesh
-Para agregar aplicaciones o namespaces a la malla en modo ambient, agrega la etiqueta `istio.io/data plane-mode=ambient` al recurso correspondiente. Puedes aplicar esta etiqueta a un namespaces o a un pod individual.
+Para agregar aplicaciones o namespaces a la mesh en modo ambient, agrega la etiqueta `istio.io/data plane-mode=ambient` al recurso correspondiente. Puedes aplicar esta etiqueta a un namespaces o a un pod individual.
-El modo ambient se puede habilitar (o deshabilitar) de forma completamente transparente en lo que respecta a los pods de la aplicación. A diferencia del modo de data plane de {{< gloss >}}sidecar{{< /gloss >}}, no es necesario reiniciar las aplicaciones para agregarlas a la malla, y no se mostrarán con un contenedor adicional desplegado en su pod.
+El modo ambient se puede habilitar (o deshabilitar) de forma completamente transparente en lo que respecta a los pods de la aplicación. A diferencia del modo de data plane de {{< gloss >}}sidecar{{< /gloss >}}, no es necesario reiniciar las aplicaciones para agregarlas a la mesh, y no se mostrarán con un contenedor adicional desplegado en su pod.
### Funcionalidad de capa 4 y capa 7
@@ -24,15 +24,15 @@ Consulta [ambient y NetworkPolicy de Kubernetes](/es/docs/ambient/usage/networkp
## Comunicación entre pods en diferentes modos de data plane
-Existen múltiples opciones para la interoperabilidad entre los pods de la aplicación que utilizan el modo de data plane ambient y los puntos finales no ambient (incluidos los pods de la aplicación de Kubernetes, las gateways de Istio o las instancias de la API de Gateway de Kubernetes). Esta interoperabilidad proporciona múltiples opciones para integrar sin problemas los workloads ambient y no ambient dentro de la misma malla de Istio, lo que permite una introducción por fases de la capacidad ambient según las necesidades de despliegue y operación de tu malla.
+Existen múltiples opciones para la interoperabilidad entre los pods de la aplicación que utilizan el modo de data plane ambient y los puntos finales no ambient (incluidos los pods de la aplicación de Kubernetes, las gateways de Istio o las instancias de la API de Gateway de Kubernetes). Esta interoperabilidad proporciona múltiples opciones para integrar sin problemas los workloads ambient y no ambient dentro de la misma mesh de Istio, lo que permite una introducción por fases de la capacidad ambient según las necesidades de despliegue y operación de tu malla.
-### Pods fuera de la malla
+### Pods fuera de la mesh
-Puede que tengas namespaces que no forman parte de la malla en absoluto, ni en modo sidecar ni en modo ambient. En este caso, los pods que no están en la malla inician el tráfico directamente a los pods de destino sin pasar por el ztunnel del nodo de origen, mientras que el ztunnel del pod de destino aplica cualquier política L4 para controlar si se debe permitir o denegar el tráfico.
+Puede que tengas namespaces que no forman parte de la mesh en absoluto, ni en modo sidecar ni en modo ambient. En este caso, los pods que no están en la mesh inician el tráfico directamente a los pods de destino sin pasar por el ztunnel del nodo de origen, mientras que el ztunnel del pod de destino aplica cualquier política L4 para controlar si se debe permitir o denegar el tráfico.
-Por ejemplo, establecer una política `PeerAuthentication` con el modo mTLS establecido en `STRICT`, en un namespaces con el modo ambient habilitado, hará que se deniegue el tráfico desde fuera de la malla.
+Por ejemplo, establecer una política `PeerAuthentication` con el modo mTLS establecido en `STRICT`, en un namespaces con el modo ambient habilitado, hará que se deniegue el tráfico desde fuera de la mesh.
-### Pods dentro de la malla usando el modo sidecar
+### Pods dentro de la mesh usando el modo sidecar
Istio admite la interoperabilidad Este-Oeste entre un pod con un sidecar y un pod que usa el modo ambient, dentro de la misma malla. El proxy sidecar sabe que debe usar el protocolo HBONE, ya que se ha descubierto que el destino es un destino HBONE.
@@ -44,7 +44,7 @@ Una política `PeerAuthentication` con el modo mTLS establecido en `STRICT` perm
### gateways de entrada y salida y pods en modo ambient
-Una gateway de entrada puede ejecutarse en un namespace no ambient y exponer los servicios proporcionados por los pods en modo ambient, modo sidecar o que no están en la malla. También se admite la interoperabilidad entre los pods en modo ambient y las gateways de Istio.
+Una gateway de entrada puede ejecutarse en un namespace no ambient y exponer los servicios proporcionados por los pods en modo ambient, modo sidecar o que no están en la mesh. También se admite la interoperabilidad entre los pods en modo ambient y las gateways de Istio.
## Lógica de selección de pods para los modos ambient y sidecar
diff --git a/content/es/docs/ambient/usage/extend-waypoint-wasm/index.md b/content/es/docs/ambient/usage/extend-waypoint-wasm/index.md
index 3d1de81980560..2051d10909d9b 100644
--- a/content/es/docs/ambient/usage/extend-waypoint-wasm/index.md
+++ b/content/es/docs/ambient/usage/extend-waypoint-wasm/index.md
@@ -17,7 +17,7 @@ Una de las ventajas clave de la extensibilidad de Wasm es que las extensiones se
1. Configura Istio siguiendo las instrucciones de la [guía de introducción al modo ambient](/es/docs/ambient/getting-started).
1. Despliega la [aplicación de ejemplo Bookinfo](/es/docs/ambient/getting-started/deploy-sample-app).
-1. [Agrega el namespace predeterminado a la malla ambient](/es/docs/ambient/getting-started/secure-and-visualize).
+1. [Agrega el namespace predeterminado a la mesh ambient](/es/docs/ambient/getting-started/secure-and-visualize).
1. Despliega la aplicación de ejemplo [curl]({{< github_tree >}}/samples/curl) para usarla como fuente de prueba para enviar solicitudes.
{{< text syntax=bash >}}
diff --git a/content/es/docs/ambient/usage/l4-policy/index.md b/content/es/docs/ambient/usage/l4-policy/index.md
index 27dee926f292b..68565a01caacd 100644
--- a/content/es/docs/ambient/usage/l4-policy/index.md
+++ b/content/es/docs/ambient/usage/l4-policy/index.md
@@ -101,12 +101,12 @@ Con solo la superposición segura, el tráfico aparece en el ztunnel de destino
Los proxies de waypoint no se hacen pasar por la identidad de la carga de trabajo de origen. Una vez que has introducido un waypoint en la ruta del tráfico, el ztunnel de destino verá el tráfico con la identidad del *waypoint*, no con la identidad de origen.
-Esto significa que cuando tienes un waypoint instalado, **el lugar ideal para aplicar la política cambia**. Incluso si solo deseas aplicar la política contra los atributos L4, si dependes de la identidad de origen, debes adjuntar tu política a tu proxy de waypoint. Se puede dirigir una segunda política a tu carga de trabajo para que su ztunnel aplique políticas como "el tráfico dentro de la malla debe provenir de mi waypoint para llegar a mi aplicación".
+Esto significa que cuando tienes un waypoint instalado, **el lugar ideal para aplicar la política cambia**. Incluso si solo deseas aplicar la política contra los atributos L4, si dependes de la identidad de origen, debes adjuntar tu política a tu proxy de waypoint. Se puede dirigir una segunda política a tu carga de trabajo para que su ztunnel aplique políticas como "el tráfico dentro de la mesh debe provenir de mi waypoint para llegar a mi aplicación".
## Autenticación de pares
Las [políticas de autenticación de pares](/es/docs/concepts/security/#peer-authentication) de Istio, que configuran los modos de TLS mutuo (mTLS), son compatibles con ztunnel.
-La política predeterminada para el modo ambient es `PERMISSIVE`, que permite que los pods acepten tanto el tráfico cifrado con mTLS (desde dentro de la malla) como el tráfico de texto sin formato (desde fuera). Habilitar el modo `STRICT` significa que los pods solo aceptarán tráfico cifrado con mTLS.
+La política predeterminada para el modo ambient es `PERMISSIVE`, que permite que los pods acepten tanto el tráfico cifrado con mTLS (desde dentro de la mesh) como el tráfico de texto sin formato (desde fuera). Habilitar el modo `STRICT` significa que los pods solo aceptarán tráfico cifrado con mTLS.
Como ztunnel y {{< gloss >}}HBONE{{< /gloss >}} implican el uso de mTLS, no es posible usar el modo `DISABLE` en una política. Dichas políticas serán ignoradas.
diff --git a/content/es/docs/ambient/usage/networkpolicy/index.md b/content/es/docs/ambient/usage/networkpolicy/index.md
index 63d8e582ef25e..38c58b07482e9 100644
--- a/content/es/docs/ambient/usage/networkpolicy/index.md
+++ b/content/es/docs/ambient/usage/networkpolicy/index.md
@@ -14,7 +14,7 @@ Una implicación de esto es que es posible crear una `NetworkPolicy` de Kubernet
## Superposición de tráfico ambient y NetworkPolicy de Kubernetes
-Una vez que hayas agregado aplicaciones a la malla ambient, la superposición segura L4 de ambient tunelizará el tráfico entre tus pods a través del puerto 15008. Una vez que el tráfico seguro ingrese al pod de destino con un puerto de destino de 15008, el tráfico se redirigirá al puerto de destino original.
+Una vez que hayas agregado aplicaciones a la mesh ambient, la superposición segura L4 de ambient tunelizará el tráfico entre tus pods a través del puerto 15008. Una vez que el tráfico seguro ingrese al pod de destino con un puerto de destino de 15008, el tráfico se redirigirá al puerto de destino original.
Sin embargo, la `NetworkPolicy` se aplica en el host, fuera del pod. Esto significa que si tienes una `NetworkPolicy` preexistente que, por ejemplo, denegará el tráfico entrante a un pod ambient en todos los puertos excepto en el 443, tendrás que agregar una excepción a esa `NetworkPolicy` para el puerto 15008. Las cargas de trabajo de sidecar que reciben tráfico también deberán permitir el tráfico entrante en el puerto 15008 para permitir que las cargas de trabajo ambient se comuniquen con ellas.
@@ -54,7 +54,7 @@ spec:
protocol: TCP
{{< /text >}}
-si `my-app` se agrega a la malla.
+si `my-app` se agrega a la mesh.
## Ambient, sondas de salud y NetworkPolicy de Kubernetes
@@ -64,9 +64,9 @@ Varias implementaciones de CNI resuelven esto de diferentes maneras y buscan sol
En Istio ambient, este problema se resuelve mediante una combinación de reglas de iptables y traducción de direcciones de red de origen (SNAT) para reescribir solo los paquetes que se originan de manera demostrable en el nodo local con una IP de enlace local fija, de modo que puedan ser ignorados explícitamente por la aplicación de políticas de Istio como tráfico de sonda de salud no seguro. Se eligió una IP de enlace local como predeterminada, ya que generalmente se ignoran para los controles de entrada y salida, y [por estándar de la IETF](https://datatracker.ietf.org/doc/html/rfc3927) no se pueden enrutar fuera de la subred local.
-Este comportamiento se habilita de forma transparente cuando agregas pods a la malla ambient, y de forma predeterminada, ambient usa la dirección de enlace local `169.254.7.127` para identificar y permitir correctamente los paquetes de sondeo de salud de kubelet.
+Este comportamiento se habilita de forma transparente cuando agregas pods a la mesh ambient, y de forma predeterminada, ambient usa la dirección de enlace local `169.254.7.127` para identificar y permitir correctamente los paquetes de sondeo de salud de kubelet.
-Sin embargo, si tu carga de trabajo, namespace o cluster tiene una `NetworkPolicy` de entrada o salida preexistente, dependiendo del CNI que estés utilizando, los paquetes con esta dirección de enlace local pueden ser bloqueados por la `NetworkPolicy` explícita, lo que hará que las sondas de salud de tu pod de aplicación comiencen a fallar cuando agregues tus pods a la malla ambient.
+Sin embargo, si tu carga de trabajo, namespace o cluster tiene una `NetworkPolicy` de entrada o salida preexistente, dependiendo del CNI que estés utilizando, los paquetes con esta dirección de enlace local pueden ser bloqueados por la `NetworkPolicy` explícita, lo que hará que las sondas de salud de tu pod de aplicación comiencen a fallar cuando agregues tus pods a la mesh ambient.
Por ejemplo, aplicar la siguiente `NetworkPolicy` en un namespace bloquearía todo el tráfico (de Istio o de otro tipo) al pod `my-app`, **incluidas** las sondas de salud de kubelet. Dependiendo de tu CNI, las sondas de kubelet y las direcciones de enlace local pueden ser ignoradas por esta política o ser bloqueadas por ella:
@@ -83,7 +83,7 @@ spec:
- Ingress
{{< /text >}}
-Una vez que el pod esté inscrito en la malla ambient, los paquetes de sondeo de salud comenzarán a recibir una dirección de enlace local a través de SNAT, lo que significa que las sondas de salud pueden comenzar a ser bloqueadas por la implementación de `NetworkPolicy` de tu CNI. Para permitir que las sondas de salud ambient omitan la `NetworkPolicy`, permite explícitamente el tráfico desde el nodo host a tu pod permitiendo la dirección de enlace local que ambient usa para este tráfico:
+Una vez que el pod esté inscrito en la mesh ambient, los paquetes de sondeo de salud comenzarán a recibir una dirección de enlace local a través de SNAT, lo que significa que las sondas de salud pueden comenzar a ser bloqueadas por la implementación de `NetworkPolicy` de tu CNI. Para permitir que las sondas de salud ambient omitan la `NetworkPolicy`, permite explícitamente el tráfico desde el nodo host a tu pod permitiendo la dirección de enlace local que ambient usa para este tráfico:
{{< text syntax=yaml snip_id=none >}}
apiVersion: networking.k8s.io/v1
diff --git a/content/es/docs/ambient/usage/verify-mtls-enabled/index.md b/content/es/docs/ambient/usage/verify-mtls-enabled/index.md
index 7b1724ddf0f0a..344c652272211 100644
--- a/content/es/docs/ambient/usage/verify-mtls-enabled/index.md
+++ b/content/es/docs/ambient/usage/verify-mtls-enabled/index.md
@@ -1,12 +1,12 @@
---
title: Verificar que mTLS está habilitado
-description: Comprende cómo verificar que mTLS está habilitado entre las cargas de trabajo en una malla ambient.
+description: Comprende cómo verificar que mTLS está habilitado entre las cargas de trabajo en un ambient mesh.
weight: 15
owner: istio/wg-networking-maintainers
test: no
---
-Una vez que hayas agregado aplicaciones a una malla ambient, puedes validar fácilmente que mTLS está habilitado entre tus cargas de trabajo usando uno o más de los siguientes métodos:
+Una vez que hayas agregado aplicaciones a un ambient mesh, puedes validar fácilmente que mTLS está habilitado entre tus cargas de trabajo usando uno o más de los siguientes métodos:
## Validar mTLS usando las configuraciones de ztunnel de la carga de trabajo
@@ -67,7 +67,7 @@ Valida que los valores de `src.identity` y `dst.identity` sean correctos. Son la
## Validar con el panel de control de Kiali
-Si tienes Kiali y Prometheus instalados, puedes visualizar la comunicación de tu carga de trabajo en la malla ambient usando el panel de control de Kiali. Puedes ver si la conexión entre dos cargas de trabajo tiene el icono del candado para validar que mTLS está habilitado, junto con la información de identidad del par:
+Si tienes Kiali y Prometheus instalados, puedes visualizar la comunicación de tu carga de trabajo en la mesh ambient usando el panel de control de Kiali. Puedes ver si la conexión entre dos cargas de trabajo tiene el icono del candado para validar que mTLS está habilitado, junto con la información de identidad del par:
{{< image link="./kiali-mtls.png" caption="Panel de control de Kiali" >}}
diff --git a/content/es/docs/ambient/usage/waypoint/index.md b/content/es/docs/ambient/usage/waypoint/index.md
index f582c473cb7ee..cef553676f727 100644
--- a/content/es/docs/ambient/usage/waypoint/index.md
+++ b/content/es/docs/ambient/usage/waypoint/index.md
@@ -23,7 +23,7 @@ El enfoque por capas de ambient permite a los usuarios adoptar Istio de una mane
La mayoría de las características del modo ambient son proporcionadas por el proxy de nodo ztunnel. Ztunnel está diseñado para procesar solo el tráfico en la capa 4 (L4), de modo que pueda operar de forma segura como un componente compartido.
-Cuando configuras la redirección a un waypoint, el tráfico será reenviado por ztunnel a ese waypoint. Si tus aplicaciones requieren alguna de las siguientes funciones de malla L7, deberás usar un proxy de waypoint:
+Cuando configuras la redirección a un waypoint, el tráfico será reenviado por ztunnel a ese waypoint. Si tus aplicaciones requieren alguna de las siguientes funciones de mesh L7, deberás usar un proxy de waypoint:
* **Gestión del tráfico**: enrutamiento y balanceo de carga HTTP, interrupción de circuito, limitación de velocidad, inyección de fallas, reintentos, tiempos de espera
* **Seguridad**: políticas de autorización enriquecidas basadas en primitivas L7 como el tipo de solicitud o el encabezado HTTP
@@ -165,7 +165,7 @@ $ kubectl label service reviews istio.io/use-waypoint=reviews-svc-waypoint
service/reviews labeled
{{< /text >}}
-Cualquier solicitud de los pods en la malla al servicio `reviews` ahora se enrutará a través del waypoint `reviews-svc-waypoint`.
+Cualquier solicitud de los pods en la mesh al servicio `reviews` ahora se enrutará a través del waypoint `reviews-svc-waypoint`.
### Configurar un pod para que use un waypoint específico
@@ -187,11 +187,11 @@ $ kubectl label pod -l version=v2,app=reviews istio.io/use-waypoint=reviews-v2-p
pod/reviews-v2-5b667bcbf8-spnnh labeled
{{< /text >}}
-Cualquier solicitud de los pods en la malla ambient a la IP del pod `reviews-v2` ahora se enrutará a través del waypoint `reviews-v2-pod-waypoint` para el procesamiento L7 y la aplicación de políticas.
+Cualquier solicitud de los pods en la mesh ambient a la IP del pod `reviews-v2` ahora se enrutará a través del waypoint `reviews-v2-pod-waypoint` para el procesamiento L7 y la aplicación de políticas.
{{< tip >}}
-El tipo de destino original del tráfico se utiliza para determinar si se utilizará un waypoint de servicio o de carga de trabajo. Al usar el tipo de destino original, la malla ambient evita que el tráfico transite dos veces por el waypoint, incluso si tanto el servicio como la carga de trabajo tienen waypoints adjuntos.
-Por ejemplo, el tráfico que se dirige a un servicio, aunque finalmente se resuelva en una IP de pod, siempre es tratado por la malla ambient como para el servicio y usaría un waypoint adjunto al servicio.
+El tipo de destino original del tráfico se utiliza para determinar si se utilizará un waypoint de servicio o de carga de trabajo. Al usar el tipo de destino original, la mesh ambient evita que el tráfico transite dos veces por el waypoint, incluso si tanto el servicio como la carga de trabajo tienen waypoints adjuntos.
+Por ejemplo, el tráfico que se dirige a un servicio, aunque finalmente se resuelva en una IP de pod, siempre es tratado por la mesh ambient como para el servicio y usaría un waypoint adjunto al servicio.
{{< /tip >}}
## Uso de waypoint entre namespaces {#usewaypointnamespace}
diff --git a/content/es/docs/concepts/observability/index.md b/content/es/docs/concepts/observability/index.md
index ee1eafda61ad9..d454b152fe6bc 100644
--- a/content/es/docs/concepts/observability/index.md
+++ b/content/es/docs/concepts/observability/index.md
@@ -14,18 +14,18 @@ owner: istio/wg-policies-and-telemetry-maintainers
test: n/a
---
-Istio genera telemetría detallada para todas las comunicaciones de servicios dentro de una malla. Esta telemetría proporciona *observabilidad* del comportamiento del servicio,
+Istio genera telemetría detallada para todas las comunicaciones de servicios dentro de un mesh. Esta telemetría proporciona *observabilidad* del comportamiento del servicio,
lo que permite a los operadores solucionar problemas, mantener y optimizar sus aplicaciones, sin imponer ninguna carga adicional a los desarrolladores de servicios. A través de
Istio, los operadores obtienen una comprensión profunda de cómo interactúan los servicios monitoreados, tanto con otros servicios como con los propios componentes de Istio.
Istio genera los siguientes tipos de telemetría para proporcionar observabilidad general de la service mesh:
- [**Métricas**](#metrics). Istio genera un conjunto de métricas de servicio basadas en las cuatro "señales doradas" de monitoreo (latencia, tráfico, errores y
- saturación). Istio también proporciona métricas detalladas para el [control plane de la malla](/es/docs/ops/deployment/architecture/).
- También se proporciona un conjunto predeterminado de paneles de monitoreo de malla creados sobre estas métricas.
+ saturación). Istio también proporciona métricas detalladas para el [control plane de la mesh](/es/docs/ops/deployment/architecture/).
+ También se proporciona un conjunto predeterminado de paneles de monitoreo de mesh creados sobre estas métricas.
- [**Trazas distribuidas**](#distributed-traces). Istio genera tramos de traza distribuidos para cada servicio, lo que proporciona a los operadores una comprensión detallada
- de los flujos de llamadas y las dependencias de los servicios dentro de una malla.
-- [**Registros de acceso**](#access-logs). A medida que el tráfico fluye hacia un servicio dentro de una malla, Istio puede generar un registro completo de cada solicitud, incluidos los metadatos de origen y
+ de los flujos de llamadas y las dependencias de los servicios dentro de un mesh.
+- [**Registros de acceso**](#access-logs). A medida que el tráfico fluye hacia un servicio dentro de un mesh, Istio puede generar un registro completo de cada solicitud, incluidos los metadatos de origen y
destino. Esta información permite a los operadores auditar el comportamiento del servicio hasta el nivel de
[workload instance](/es/docs/reference/glossary/#workload-instance) individual.
@@ -36,21 +36,21 @@ Las métricas proporcionan una forma de monitorear y comprender el comportamient
Para monitorear el comportamiento del servicio, Istio genera métricas para todo el tráfico del servicio dentro, fuera y dentro de una service mesh de Istio. Estas métricas proporcionan información sobre
comportamientos como el volumen general de tráfico, las tasas de error dentro del tráfico y los tiempos de respuesta para las solicitudes.
-Además de monitorear el comportamiento de los services dentro de una malla, también es importante monitorear el comportamiento de la malla misma. Los componentes de Istio exportan
-métricas sobre sus propios comportamientos internos para proporcionar información sobre la salud y el funcionamiento del control plane de la malla.
+Además de monitorear el comportamiento de los services dentro de un mesh, también es importante monitorear el comportamiento de la mesh misma. Los componentes de Istio exportan
+métricas sobre sus propios comportamientos internos para proporcionar información sobre la salud y el funcionamiento del control plane de la mesh.
### Métricas a nivel de proxy
La recopilación de métricas de Istio comienza con los proxies sidecar (Envoy). Cada proxy genera un amplio conjunto de métricas sobre todo el tráfico que pasa a través del proxy (tanto
de entrada como de salida). Los proxies también proporcionan estadísticas detalladas sobre las funciones administrativas del propio proxy, incluida la información de configuración y salud.
-Las métricas generadas por Envoy proporcionan un monitoreo de la malla con la granularidad de los recursos de Envoy (como listeners y clusters). Como resultado, se requiere comprender la
-conexión entre los services de la malla y los recursos de Envoy para monitorear las métricas de Envoy.
+Las métricas generadas por Envoy proporcionan un monitoreo de la mesh con la granularidad de los recursos de Envoy (como listeners y clusters). Como resultado, se requiere comprender la
+conexión entre los services de la mesh y los recursos de Envoy para monitorear las métricas de Envoy.
Istio permite a los operadores seleccionar cuáles de las métricas de Envoy se generan y recopilan en cada workload instance. De forma predeterminada, Istio habilita solo un pequeño
subconjunto de las estadísticas generadas por Envoy para evitar sobrecargar los backends de métricas y reducir la sobrecarga de CPU asociada con la recopilación de métricas. Sin embargo,
los operadores pueden ampliar fácilmente el conjunto de métricas de proxy recopiladas cuando sea necesario. Esto permite la depuración dirigida del comportamiento de la red, al tiempo que reduce el
-costo general del monitoreo en toda la malla.
+costo general del monitoreo en toda la mesh.
El [sitio de documentación de Envoy](httpshttps://www.envoyproxy.io/docs/envoy/latest/) incluye una descripción detallada de la [recopilación de estadísticas de Envoy](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/statistics.html?highlight=statistics).
La guía de operaciones sobre [Estadísticas de Envoy](/es/docs/ops/configuration/telemetry/envoy-stats/) proporciona más información sobre cómo controlar la generación de métricas a nivel de proxy.
@@ -113,20 +113,20 @@ istio_requests_total{
### Métricas del control plane
El control plane de Istio también proporciona una colección de métricas de autocontrol. Estas métricas permiten monitorear el comportamiento
-de Istio mismo (a diferencia del de los services dentro de la malla).
+de Istio mismo (a diferencia del de los services dentro de la mesh).
Para obtener más información sobre qué métricas se mantienen, consulte la [documentación de referencia](/es/docs/reference/commands/pilot-discovery/#metrics).
## Trazas distribuidas
-El rastreo distribuido proporciona una forma de monitorear y comprender el comportamiento al monitorear solicitudes individuales a medida que fluyen a través de una malla.
-Las trazas permiten a los operadores de la malla comprender las dependencias del servicio y las fuentes de latencia dentro de su service mesh.
+El rastreo distribuido proporciona una forma de monitorear y comprender el comportamiento al monitorear solicitudes individuales a medida que fluyen a través de un mesh.
+Las trazas permiten a los operadores de la mesh comprender las dependencias del servicio y las fuentes de latencia dentro de su service mesh.
Istio admite el rastreo distribuido a través de los proxies de Envoy. Los proxies generan automáticamente tramos de traza en nombre de las aplicaciones que representan,
requiriendo solo que las aplicaciones reenvíen el contexto de solicitud apropiado.
-Istio admite una serie de backends de rastreo, incluidos [Zipkin](/es/docs/tasks/observability/distributed-tracing/zipkin/),
-[Jaeger](/es/docs/tasks/observability/distributed-tracing/jaeger/) y muchas herramientas y servicios que admiten [OpenTelemetry](/es/docs/tasks/observability/distributed-tracing/opentelemetry/). Los operadores controlan la frecuencia de muestreo para la generación de trazas (es decir, la frecuencia con la
+Istio admite una serie de backends de rastreo, incluidos [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/),
+[Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/) y muchas herramientas y servicios que admiten [OpenTelemetry](/docs/tasks/observability/distributed-tracing/opentelemetry/). Los operadores controlan la frecuencia de muestreo para la generación de trazas (es decir, la frecuencia con la
que se generan los datos de rastreo por solicitud). Esto permite a los operadores controlar la cantidad y la velocidad de los datos de rastreo que se producen para su malla.
Se puede encontrar más información sobre el rastreo distribuido con Istio en nuestras [Preguntas frecuentes sobre el rastreo distribuido](/es/about/faq/#distributed-tracing).
diff --git a/content/es/docs/concepts/security/index.md b/content/es/docs/concepts/security/index.md
index 06c44cffd5f6b..1721a0c5688c0 100644
--- a/content/es/docs/concepts/security/index.md
+++ b/content/es/docs/concepts/security/index.md
@@ -16,7 +16,7 @@ test: n/a
Descomponer una aplicación monolítica en services atómicos ofrece varios
beneficios, incluyendo mayor agilidad, mejor escalabilidad y mayor capacidad de
-reutilizar services. Sin embargo, los microservices también tienen necesidades de seguridad particulares:
+reutilizar services. Sin embargo, los microservicios también tienen necesidades de seguridad particulares:
- Para defenderse de ataques de intermediario, necesitan cifrado de tráfico.
- Para proporcionar un control de acceso flexible a los services, necesitan mTLS y
@@ -254,7 +254,7 @@ antes de que el Envoy del lado del cliente reciba el tráfico.
### Arquitectura de autenticación
Puede especificar los requisitos de autenticación para los workloads que reciben solicitudes en
-una malla de Istio utilizando políticas de autenticación de pares y de solicitudes. El operador de la malla
+una mesh de Istio utilizando políticas de autenticación de pares y de solicitudes. El operador de la mesh
utiliza ficheros `.yaml` para especificar las políticas. Las políticas se guardan en el
almacén de configuración de Istio una vez desplegadas. El controlador de Istio observa el
almacén de configuración.
@@ -322,8 +322,8 @@ EOF
#### Almacenamiento de políticas
-Istio almacena las políticas con alcance de malla en el namespace raíz. Estas políticas tienen un
-selector vacío que se aplica a todos los workloads de la malla. Las políticas que tienen un
+Istio almacena las políticas con alcance de mesh en el namespace raíz. Estas políticas tienen un
+selector vacío que se aplica a todos los workloads de la mesh. Las políticas que tienen un
alcance de namespace se almacenan en el namespace correspondiente. Solo se aplican a
los workloads dentro de su namespace. Si configura un campo `selector`, la
política de autenticación solo se aplica a los workloads que coinciden con las condiciones que
@@ -360,9 +360,9 @@ Las políticas de autenticación de pares y de solicitudes siguen los mismos pri
para los campos `selector`, pero Istio los combina y aplica de formas ligeramente
diferentes.
-Solo puede haber una política de autenticación de pares a nivel de malla y solo una
+Solo puede haber una política de autenticación de pares a nivel de mesh y solo una
política de autenticación de pares a nivel de namespace por namespace. Cuando configura
-múltiples políticas de autenticación de pares a nivel de malla o de namespace para la misma malla
+múltiples políticas de autenticación de pares a nivel de mesh o de namespace para la misma malla
o namespace, Istio ignora las políticas más nuevas. Cuando más de una
política de autenticación de pares específica del workload coincide, Istio elige la más antigua.
@@ -375,15 +375,15 @@ siguiente orden:
Istio puede combinar todas las políticas de autenticación de solicitudes coincidentes para que funcionen como si
provinieran de una única política de autenticación de solicitudes. Por lo tanto, puede tener
-múltiples políticas de autenticación de solicitudes a nivel de malla o de namespace en una malla o namespace. Sin embargo,
-sigue siendo una buena práctica evitar tener múltiples políticas de autenticación de solicitudes a nivel de malla o de namespace.
+múltiples políticas de autenticación de solicitudes a nivel de mesh o de namespace en un mesh o namespace. Sin embargo,
+sigue siendo una buena práctica evitar tener múltiples políticas de autenticación de solicitudes a nivel de mesh o de namespace.
#### Autenticación de pares
Las políticas de autenticación de pares especifican el modo mTLS que Istio aplica a
los workloads de destino. Se admiten los siguientes modos:
-- PERMISIVO: Los workloads aceptan tanto tráfico mTLS como tráfico de texto plano. Este
+- PERMISSIVE: Los workloads aceptan tanto tráfico mTLS como tráfico de texto plano. Este
modo es más útil durante las migraciones cuando los workloads sin sidecar no pueden
usar mTLS. Una vez que los workloads se migran con inyección de sidecar, debe
cambiar el modo a ESTRICTO.
@@ -392,7 +392,7 @@ los workloads de destino. Se admiten los siguientes modos:
no debe usar este modo a menos que proporcione su propia solución de seguridad.
Cuando el modo no está establecido, se hereda el modo del ámbito padre. Las políticas de autenticación de pares
-a nivel de malla con un modo no establecido usan el modo `PERMISIVO` por
+a nivel de mesh con un modo no establecido usan el modo `PERMISSIVE` por
defecto.
La siguiente política de autenticación de pares requiere que todos los workloads en el namespace
@@ -486,7 +486,7 @@ políticas a los workloads casi en tiempo real. Sin embargo, Istio no puede gara
que todos los workloads reciban la nueva política al mismo tiempo. Las siguientes
recomendaciones ayudan a evitar interrupciones al actualizar sus políticas de autenticación:
-- Utilice políticas de autenticación de pares intermedias utilizando el modo `PERMISIVO`
+- Utilice políticas de autenticación de pares intermedias utilizando el modo `PERMISSIVE`
al cambiar el modo de `DISABLE` a `STRICT` y viceversa. Cuando todos
los workloads cambien con éxito al modo deseado, puede aplicar la política
con el modo final. Puede usar la telemetría de Istio para verificar que los workloads
@@ -500,7 +500,7 @@ recomendaciones ayudan a evitar interrupciones al actualizar sus políticas de a
## Autorización
Las features de autorización de Istio proporcionan control de acceso a nivel de malla, namespace y workload
-para sus workloads en la malla. Este nivel de control proporciona
+para sus workloads en la mesh. Este nivel de control proporciona
los siguientes beneficios:
- Autorización de workload a workload y de usuario final a workload.
@@ -893,7 +893,7 @@ en la política de autorización.
Suponiendo que tiene un service MongoDB en el puerto `27017`, el siguiente ejemplo
configura una política de autorización para permitir que solo el service `bookinfo-ratings-v2`
-en la malla de Istio acceda al workload MongoDB.
+en la mesh de Istio acceda al workload MongoDB.
{{< text yaml >}}
apiVersion: security.istio.io/v1
diff --git a/content/es/docs/concepts/traffic-management/index.md b/content/es/docs/concepts/traffic-management/index.md
index df0e61f567860..2736a69b2c775 100644
--- a/content/es/docs/concepts/traffic-management/index.md
+++ b/content/es/docs/concepts/traffic-management/index.md
@@ -27,7 +27,7 @@ sea más resiliente contra fallos de services dependientes o de la red.
El modelo de gestión de tráfico de Istio se basa en los proxies {{< gloss >}}Envoy{{}}
que se despliegan junto con sus services. Todo el tráfico que sus services de malla
envían y reciben (tráfico del {{< gloss >}}data plane{{}}) se proxy a través de Envoy, lo que facilita
-dirigir y controlar el tráfico alrededor de su malla sin realizar ningún
+dirigir y controlar el tráfico alrededor de su mesh sin realizar ningún
cambio en sus services.
Si está interesado en los detalles de cómo funcionan las features descritas en esta guía,
@@ -44,7 +44,7 @@ descubrimiento de services. Por ejemplo, si ha instalado Istio en un cluster de
entonces Istio detecta automáticamente los services y endpoints en ese cluster.
Utilizando este service registry, los proxies Envoy pueden dirigir el tráfico a los
-services relevantes. La mayoría de las applications basadas en microservices tienen múltiples instancias
+services relevantes. La mayoría de las applications basadas en microservicios tienen múltiples instancias
de cada workload de service para manejar el tráfico de service, a veces denominado
pool de balanceo de carga. Por defecto, los proxies Envoy distribuyen el tráfico entre
el pool de balanceo de carga de cada service utilizando un modelo de menos solicitudes, donde cada
@@ -59,7 +59,7 @@ Es posible que desee dirigir un porcentaje particular de tráfico a una nueva ve
un service como parte de las pruebas A/B, o aplicar una política de balanceo de carga diferente al
tráfico para un subconjunto particular de instancias de service. También es posible que desee
aplicar reglas especiales al tráfico que entra o sale de su malla, o agregar una
-dependencia externa de su malla al service registry. Puede hacer todo esto
+dependencia externa de su mesh al service registry. Puede hacer todo esto
y más agregando su propia configuración de tráfico a Istio utilizando la API de gestión de tráfico de Istio.
Al igual que otras configuraciones de Istio, la API se especifica utilizando definiciones de recursos personalizados de Kubernetes
@@ -86,8 +86,8 @@ junto con las [reglas de destino](#destination-rules), son los bloques de constr
Un virtual service le permite configurar cómo se enrutan las solicitudes a un service dentro de una service mesh de Istio,
basándose en la conectividad y el descubrimiento básicos proporcionados por Istio y su plataforma. Cada virtual
service consta de un conjunto de reglas de enrutamiento que se evalúan en orden, lo que permite
-a Istio hacer coincidir cada solicitud dada al virtual service con un destino real específico dentro de la malla.
-Su malla puede requerir múltiples virtual services o ninguno, dependiendo de su caso de uso.
+a Istio hacer coincidir cada solicitud dada al virtual service con un destino real específico dentro de la mesh.
+Su mesh puede requerir múltiples virtual services o ninguno, dependiendo de su caso de uso.
### ¿Por qué usar virtual services? {#why-use-virtual-services}
@@ -127,13 +127,13 @@ los virtual services ayudan con los despliegues canary en [Despliegues Canary us
Los virtual services también le permiten:
- Dirigir múltiples applications de services a través de un único virtual service. Si
- su malla utiliza Kubernetes, por ejemplo, puede configurar un virtual service
+ su mesh utiliza Kubernetes, por ejemplo, puede configurar un virtual service
para manejar todos los services en un namespace específico. Mapear un único
virtual service a múltiples services "reales" es particularmente útil para
facilitar la transformación de una aplicación monolítica en un service compuesto
- por microservices distintos sin requerir que los consumidores del service
+ por microservicios distintos sin requerir que los consumidores del service
se adapten a la transición. Sus reglas de enrutamiento pueden especificar "las llamadas a estas URIs de
- `monolith.com` van al `microservice A`", y así sucesivamente. Puede ver cómo funciona esto
+ `monolith.com` van al `microservicio A`", y así sucesivamente. Puede ver cómo funciona esto
en [uno de nuestros ejemplos a continuación](#more-about-routing-rules).
- Configurar reglas de tráfico en combinación con
[gateways](/es/docs/concepts/traffic-management/#gateways) para controlar el tráfico de entrada
@@ -191,7 +191,7 @@ implícita o explícitamente, en un nombre de dominio completamente calificado (
utilizar prefijos comodín ("*"), lo que le permite crear un único conjunto de reglas de enrutamiento para
todos los services coincidentes. Los hosts del virtual service no tienen que formar parte del
service registry de Istio, son simplemente destinos virtuales. Esto le permite modelar
-el tráfico para hosts virtuales que no tienen entradas enrutables dentro de la malla.
+el tráfico para hosts virtuales que no tienen entradas enrutables dentro de la mesh.
#### Reglas de enrutamiento {#routing-rules}
@@ -223,7 +223,7 @@ El campo `destination` de la sección de ruta especifica el destino real para
el tráfico que coincide con esta condición. A diferencia de los hosts del virtual service,
el host de destino debe ser un destino real que exista en el service registry de Istio
o Envoy no sabrá a dónde enviar el tráfico. Puede ser un service de malla
-con proxies o un service no de malla agregado mediante una entrada de service. En este
+con proxies o un service no de mesh agregado mediante una entrada de service. En este
caso, nos estamos ejecutando en Kubernetes y el nombre de host es un nombre de service de Kubernetes:
{{< text yaml >}}
@@ -430,8 +430,8 @@ del subconjunto.
Utiliza un [gateway](/es/docs/reference/config/networking/gateway/#Gateway) para
gestionar el tráfico de entrada y salida de su malla, lo que le permite especificar qué
-tráfico desea que entre o salga de la malla. Las configuraciones de gateway se aplican
-a proxies Envoy independientes que se ejecutan en el borde de la malla, en lugar
+tráfico desea que entre o salga de la mesh. Las configuraciones de gateway se aplican
+a proxies Envoy independientes que se ejecutan en el borde de la mesh, en lugar
de proxies Envoy sidecar que se ejecutan junto a sus workloads de service.
A diferencia de otros mecanismos para controlar el tráfico que ingresa a sus sistemas, como
@@ -441,11 +441,11 @@ simplemente le permite configurar propiedades de balanceo de carga de capa 4-6,
puertos a exponer, configuraciones TLS, etc. Luego, en lugar de agregar
enrutamiento de tráfico a nivel de aplicación (L7) al mismo recurso de API, vincula un
virtual service de Istio regular al gateway. Esto le permite
-básicamente gestionar el tráfico del gateway como cualquier otro tráfico del data plane en una malla de Istio.
+básicamente gestionar el tráfico del gateway como cualquier otro tráfico del data plane en un mesh de Istio.
Los gateways se utilizan principalmente para gestionar el tráfico de entrada, pero también puede
configurar egress gateways. Un egress gateway le permite configurar un nodo de salida dedicado
-para el tráfico que sale de la malla, lo que le permite limitar qué services pueden o
+para el tráfico que sale de la mesh, lo que le permite limitar qué services pueden o
deben acceder a redes externas, o para habilitar
el [control seguro del tráfico de salida](/blog/2019/egress-traffic-control-in-istio-part-1/)
para agregar seguridad a su malla, por ejemplo. También puede usar un gateway para
@@ -484,7 +484,7 @@ spec:
credentialName: ext-host-cert
{{< /text >}}
-Esta configuración de gateway permite el tráfico HTTPS de `ext-host.example.com` en la malla en
+Esta configuración de gateway permite el tráfico HTTPS de `ext-host.example.com` en la mesh en
el puerto 443, pero no especifica ningún enrutamiento para el tráfico.
Para especificar el enrutamiento y para que el gateway funcione según lo previsto, también debe vincular
@@ -512,22 +512,22 @@ Utiliza una
una entrada al service registry que Istio mantiene internamente. Después de agregar
la entrada de service, los proxies Envoy pueden enviar tráfico al service como si
fuera un service en su malla. La configuración de entradas de service le permite gestionar
-el tráfico para services que se ejecutan fuera de la malla, incluyendo las siguientes tareas:
+el tráfico para services que se ejecutan fuera de la mesh, incluyendo las siguientes tareas:
- Redirigir y reenviar tráfico para destinos externos, como API
consumidas de la web, o tráfico a services en infraestructura heredada.
- Definir políticas de [reintentos](#retries), [tiempos de espera](#timeouts) e
[inyección de fallos](#fault-injection) para destinos externos.
-- Ejecutar un service de malla en una Máquina Virtual (VM) [agregando VMs a su malla](/es/docs/examples/virtual-machines/).
+- Ejecutar un service de mesh en una Máquina Virtual (VM) [agregando VMs a su malla](/es/docs/examples/virtual-machines/).
No necesita agregar una entrada de service para cada service externo que desee
que utilicen sus services de malla. Por defecto, Istio configura los proxies Envoy para
pasar las solicitudes a services desconocidos. Sin embargo, no puede usar las features de Istio
-para controlar el tráfico a destinos que no están registrados en la malla.
+para controlar el tráfico a destinos que no están registrados en la mesh.
### Ejemplo de entrada de service {#service-entry-example}
-El siguiente ejemplo de entrada de service externa a la malla agrega la dependencia externa
+El siguiente ejemplo de entrada de service externa a la mesh agrega la dependencia externa
`ext-svc.example.com` al service registry de Istio:
{{< text yaml >}}
@@ -551,7 +551,7 @@ completamente o usar un nombre de dominio con prefijo comodín.
Puede configurar virtual services y reglas de destino para controlar el tráfico a una
entrada de service de una manera más granular, de la misma manera que configura el tráfico para
-cualquier otro service en la malla. Por ejemplo, la siguiente regla de destino
+cualquier otro service en la mesh. Por ejemplo, la siguiente regla de destino
ajusta el tiempo de espera de conexión TCP para las solicitudes al service externo
`ext-svc.example.com` que configuramos utilizando la entrada de service:
@@ -575,15 +575,15 @@ para obtener más opciones de configuración posibles.
## Sidecars {#sidecars}
Por defecto, Istio configura cada proxy Envoy para aceptar tráfico en todos los
-puertos de su workload asociado, y para alcanzar cada workload en la malla al
+puertos de su workload asociado, y para alcanzar cada workload en la mesh al
reenviar tráfico. Puede usar una configuración de [sidecar](/es/docs/reference/config/networking/sidecar/#Sidecar) para hacer lo siguiente:
- Ajustar el conjunto de puertos y protocolos que acepta un proxy Envoy.
- Limitar el conjunto de services a los que puede llegar el proxy Envoy.
Es posible que desee limitar la accesibilidad del sidecar de esta manera en applications más grandes,
-donde tener cada proxy configurado para alcanzar cada otro service en la malla puede
-potencialmente afectar el rendimiento de la malla debido al alto uso de memoria.
+donde tener cada proxy configurado para alcanzar cada otro service en la mesh puede
+potencialmente afectar el rendimiento de la mesh debido al alto uso de memoria.
Puede especificar que desea que una configuración de sidecar se aplique a todos los workloads
en un namespace particular, o elegir workloads específicos usando un
@@ -691,13 +691,13 @@ spec:
### Disyuntores {#circuit-breakers}
Los disyuntores son otro mecanismo útil que Istio proporciona para crear
-applications basadas en microservices resilientes. En un disyuntor, se establecen límites
+applications basadas en microservicios resilientes. En un disyuntor, se establecen límites
para las llamadas a hosts individuales dentro de un service, como el número de conexiones concurrentes
o cuántas veces han fallado las llamadas a este host. Una vez que se alcanza ese límite,
el disyuntor se "dispara" y detiene más conexiones a ese host. El uso de un patrón de disyuntor
permite un fallo rápido en lugar de que los clientes intenten conectarse a un host sobrecargado o fallido.
-Como el interruptor de circuito se aplica a destinos de malla "reales" en un pool de balanceo de carga,
+Como el interruptor de circuito se aplica a destinos de mesh "reales" en un pool de balanceo de carga,
se configuran umbrales de disyuntor en
[reglas de destino](#destination-rules), con la configuración aplicándose a cada
host individual en el service. El siguiente ejemplo limita el número de
@@ -794,7 +794,7 @@ aplicación se activa primero, por lo que el tiempo de espera y el intento de re
no tienen ningún efecto.
Si bien las features de recuperación de fallos de Istio mejoran la fiabilidad y
-disponibilidad de los services en la malla, las applications deben manejar el fallo
+disponibilidad de los services en la mesh, las applications deben manejar el fallo
o los errores y tomar las acciones de respaldo apropiadas. Por ejemplo, cuando todas
las instancias en un pool de balanceo de carga han fallado, Envoy devuelve un código `HTTP 503`.
La aplicación debe implementar cualquier lógica de respaldo necesaria para manejar el
diff --git a/content/es/docs/examples/_index.md b/content/es/docs/examples/_index.md
index 889dd7e35bfc8..7468ad677244e 100644
--- a/content/es/docs/examples/_index.md
+++ b/content/es/docs/examples/_index.md
@@ -1,6 +1,6 @@
---
-title: Examples
-description: A variety of fully working example uses for Istio that you can experiment with.
+title: Ejemplos
+description: Una variedad de ejemplos de uso completamente funcionales para Istio con los que puedes experimentar.
weight: 30
aliases:
- /docs/samples/index.html
diff --git a/content/es/docs/examples/bookinfo/index.md b/content/es/docs/examples/bookinfo/index.md
index dc05959264dfd..da44a59467f63 100644
--- a/content/es/docs/examples/bookinfo/index.md
+++ b/content/es/docs/examples/bookinfo/index.md
@@ -1,6 +1,6 @@
---
-title: Bookinfo Application
-description: Deploys a sample application composed of four separate microservices used to demonstrate various Istio features.
+title: Aplicación Bookinfo
+description: Despliega una aplicación de ejemplo compuesta por cuatro microservicios separados usados para demostrar varias características de Istio.
weight: 10
aliases:
- /docs/samples/bookinfo.html
@@ -10,93 +10,92 @@ owner: istio/wg-docs-maintainers
test: yes
---
-This example deploys a sample application composed of four separate microservices used
-to demonstrate various Istio features.
+Este ejemplo despliega una aplicación de ejemplo compuesta por cuatro microservicios separados usados
+para demostrar varias características de Istio.
{{< tip >}}
-If you installed Istio using the [Getting Started](/es/docs/setup/getting-started/)
-instructions, you already have Bookinfo installed and you can skip most of these steps
-and go directly to [Define the service versions](/es/docs/examples/bookinfo/#define-the-service-versions).
+Si instalaste Istio usando las instrucciones de [Comenzando](/es/docs/setup/getting-started/),
+ya tienes Bookinfo instalado y puedes omitir la mayoría de estos pasos
+e ir directamente a [Definir las versiones del servicio](/es/docs/examples/bookinfo/#define-the-service-versions).
{{< /tip >}}
-The application displays information about a
-book, similar to a single catalog entry of an online book store. Displayed
-on the page is a description of the book, book details (ISBN, number of
-pages, and so on), and a few book reviews.
+La aplicación muestra información sobre un
+libro, similar a una sola entrada de catálogo de una librería en línea. Mostrado
+en la página está una descripción del libro, detalles del libro (ISBN, número de
+páginas, etc.), y algunas reseñas del libro.
-The Bookinfo application is broken into four separate microservices:
+La aplicación Bookinfo está dividida en cuatro microservicios separados:
-* `productpage`. The `productpage` microservice calls the `details` and `reviews` microservices to populate the page.
-* `details`. The `details` microservice contains book information.
-* `reviews`. The `reviews` microservice contains book reviews. It also calls the `ratings` microservice.
-* `ratings`. The `ratings` microservice contains book ranking information that accompanies a book review.
+* `productpage`. El microservicio `productpage` llama a los microservicios `details` y `reviews` para poblar la página.
+* `details`. El microservicio `details` contiene información del libro.
+* `reviews`. El microservicio `reviews` contiene reseñas del libro. También llama al microservicio `ratings`.
+* `ratings`. El microservicio `ratings` contiene información de clasificación del libro que acompaña a una reseña del libro.
-There are 3 versions of the `reviews` microservice:
+Hay 3 versiones del microservicio `reviews`:
-* Version v1 doesn't call the `ratings` service.
-* Version v2 calls the `ratings` service, and displays each rating as 1 to 5 black stars.
-* Version v3 calls the `ratings` service, and displays each rating as 1 to 5 red stars.
+* La versión v1 no llama al servicio `ratings`.
+* La versión v2 llama al servicio `ratings`, y muestra cada calificación como 1 a 5 estrellas negras.
+* La versión v3 llama al servicio `ratings`, y muestra cada calificación como 1 a 5 estrellas rojas.
-The end-to-end architecture of the application is shown below.
+La arquitectura de extremo a extremo de la aplicación se muestra a continuación.
-{{< image width="80%" link="./noistio.svg" caption="Bookinfo Application without Istio" >}}
+{{< image width="80%" link="./noistio.svg" caption="Aplicación Bookinfo sin Istio" >}}
-This application is polyglot, i.e., the microservices are written in different languages.
-It’s worth noting that these services have no dependencies on Istio, but make an interesting
-service mesh example, particularly because of the multitude of services, languages and versions
-for the `reviews` service.
+Esta aplicación es políglota, es decir, los microservicios están escritos en diferentes lenguajes.
+Vale la pena señalar que estos servicios no tienen dependencias en Istio, pero hacen un ejemplo
+interesante de service mesh, particularmente debido a la multitud de servicios, lenguajes y versiones
+para el servicio `reviews`.
-## Before you begin
+## Antes de comenzar
-If you haven't already done so, setup Istio by following the instructions
-in the [installation guide](/es/docs/setup/).
+Si no has hecho esto aún, configura Istio siguiendo las instrucciones
+en la guía de [instalación](/es/docs/setup/).
{{< boilerplate gateway-api-support >}}
-## Deploying the application
+## Desplegando la aplicación
-To run the sample with Istio requires no changes to the
-application itself. Instead, you simply need to configure and run the services in an
-Istio-enabled environment, with Envoy sidecars injected along side each service.
-The resulting deployment will look like this:
+Para ejecutar el ejemplo con Istio no se necesitan cambios en
+la aplicación en sí. En su lugar, simplemente necesitas configurar y ejecutar los servicios en un
+entorno habilitado para Istio, con sidecars de Envoy inyectados junto a cada servicio.
+El resultado del despliegue será así:
-{{< image width="80%" link="./withistio.svg" caption="Bookinfo Application" >}}
+{{< image width="80%" link="./withistio.svg" caption="Aplicación Bookinfo" >}}
-All of the microservices will be packaged with an Envoy sidecar that intercepts incoming
-and outgoing calls for the services, providing the hooks needed to externally control,
-via the Istio control plane, routing, telemetry collection, and policy enforcement
-for the application as a whole.
+Todos los microservicios estarán empaquetados con un sidecar de Envoy que intercepta
+llamadas entrantes y salientes para los servicios, proporcionando los ganchos necesarios para controlar externamente,
+a través del plano de control de Istio, la enrutamiento, la recopilación de métricas, y la aplicación de políticas.
-### Start the application services
+### Iniciar los servicios de la aplicación
{{< tip >}}
-If you use GKE, please ensure your cluster has at least 4 standard GKE nodes. If you use Minikube, please ensure you have at least 4GB RAM.
+Si usas GKE, asegúrate de que tu clúster tenga al menos 4 nodos estándar de GKE. Si usas Minikube, asegúrate de que tengas al menos 4GB de RAM.
{{< /tip >}}
-1. Change directory to the root of the Istio installation.
+1. Cambia al directorio raíz de la instalación de Istio.
-1. The default Istio installation uses [automatic sidecar injection](/es/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection).
- Label the namespace that will host the application with `istio-injection=enabled`:
+1. La instalación de Istio por defecto usa [inyección de sidecar automática](/es/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection).
+ Etiqueta el namespace que alojará la aplicación con `istio-injection=enabled`:
{{< text bash >}}
$ kubectl label namespace default istio-injection=enabled
{{< /text >}}
-1. Deploy your application using the `kubectl` command:
+1. Despliega tu aplicación usando el comando `kubectl`:
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@
{{< /text >}}
- The command launches all four services shown in the `bookinfo` application architecture diagram.
- All 3 versions of the reviews service, v1, v2, and v3, are started.
+ El comando instala todos los cuatro servicios mostrados en el diagrama de arquitectura de la aplicación Bookinfo.
+ Todas las 3 versiones del servicio `reviews`, v1, v2 y v3, se inician.
{{< tip >}}
- In a realistic deployment, new versions of a microservice are deployed
- over time instead of deploying all versions simultaneously.
+ En un despliegue real, las nuevas versiones de un microservicio se implementan
+ con el tiempo en lugar de desplegar todas las versiones simultáneamente.
{{< /tip >}}
-1. Confirm all services and pods are correctly defined and running:
+1. Confirma que todos los servicios y pods están definidos y ejecutándose correctamente:
{{< text bash >}}
$ kubectl get services
@@ -108,7 +107,7 @@ If you use GKE, please ensure your cluster has at least 4 standard GKE nodes. If
reviews ClusterIP 10.0.0.170 9080/TCP 6m
{{< /text >}}
- and
+ y
{{< text bash >}}
$ kubectl get pods
@@ -121,26 +120,25 @@ If you use GKE, please ensure your cluster has at least 4 standard GKE nodes. If
reviews-v3-1813607990-8ch52 2/2 Running 0 6m
{{< /text >}}
-1. To confirm that the Bookinfo application is running, send a request to it by a `curl` command from some pod, for
- example from `ratings`:
+1. Para confirmar que la aplicación Bookinfo está funcionando, envía una solicitud a ella mediante un comando `curl` desde algún pod, por ejemplo desde `ratings`:
{{< text bash >}}
$ kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS productpage:9080/productpage | grep -o ".*"
Simple Bookstore App
{{< /text >}}
-### Determine the ingress IP and port
+### Determinar la IP de entrada y el puerto
-Now that the Bookinfo services are up and running, you need to make the application accessible from outside of your
-Kubernetes cluster, e.g., from a browser. A gateway is used for this purpose.
+Ahora que los servicios de Bookinfo están en funcionamiento, necesitas hacer que la aplicación sea accesible desde fuera de tu
+clúster de Kubernetes, por ejemplo, desde un navegador. Se usa un gateway para este propósito.
-1. Create a gateway for the Bookinfo application:
+1. Crea un gateway para la aplicación Bookinfo:
{{< tabset category-name="config-api" >}}
{{< tab name="Istio APIs" category-value="istio-apis" >}}
- Create an [Istio Gateway](/es/docs/concepts/traffic-management/#gateways) using the following command:
+ Crea un [Istio Gateway](/es/docs/concepts/traffic-management/#gateways) usando el siguiente comando:
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
@@ -148,7 +146,7 @@ Kubernetes cluster, e.g., from a browser. A gateway is used for this purpose.
virtualservice.networking.istio.io/bookinfo created
{{< /text >}}
- Confirm the gateway has been created:
+ Confirma que el gateway se ha creado:
{{< text bash >}}
$ kubectl get gateway
@@ -156,7 +154,7 @@ Kubernetes cluster, e.g., from a browser. A gateway is used for this purpose.
bookinfo-gateway 32s
{{< /text >}}
- Follow [these instructions](/es/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports) to set the `INGRESS_HOST` and `INGRESS_PORT` variables for accessing the gateway. Return here, when they are set.
+ Sigue [estas instrucciones](/es/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports) para establecer las variables `INGRESS_HOST` y `INGRESS_PORT` para acceder al gateway. Vuelve aquí cuando estén configuradas.
{{< /tab >}}
@@ -164,7 +162,7 @@ Kubernetes cluster, e.g., from a browser. A gateway is used for this purpose.
{{< boilerplate external-loadbalancer-support >}}
- Create a [Kubernetes Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) using the following command:
+ Crea un [Kubernetes Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) usando el siguiente comando:
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/gateway-api/bookinfo-gateway.yaml@
@@ -172,15 +170,15 @@ Kubernetes cluster, e.g., from a browser. A gateway is used for this purpose.
httproute.gateway.networking.k8s.io/bookinfo created
{{< /text >}}
- Because creating a Kubernetes `Gateway` resource will also
- [deploy an associated proxy service](/es/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment),
- run the following command to wait for the gateway to be ready:
+ Debido a que la creación de un recurso `Gateway` de Kubernetes también
+ [implementará un servicio proxy asociado](/es/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment),
+ ejecuta el siguiente comando para esperar a que el gateway esté listo:
{{< text bash >}}
$ kubectl wait --for=condition=programmed gtw bookinfo-gateway
{{< /text >}}
- Get the gateway address and port from the bookinfo gateway resource:
+ Obtén la dirección y el puerto del gateway de la recurso del gateway de bookinfo:
{{< text bash >}}
$ export INGRESS_HOST=$(kubectl get gtw bookinfo-gateway -o jsonpath='{.status.addresses[0].value}')
@@ -191,52 +189,50 @@ Kubernetes cluster, e.g., from a browser. A gateway is used for this purpose.
{{< /tabset >}}
-1. Set `GATEWAY_URL`:
+1. Establece `GATEWAY_URL`:
{{< text bash >}}
$ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
{{< /text >}}
-## Confirm the app is accessible from outside the cluster
+## Confirmar que la aplicación es accesible desde fuera del clúster
-To confirm that the Bookinfo application is accessible from outside the cluster, run the following `curl` command:
+Para confirmar que la aplicación Bookinfo es accesible desde fuera del clúster, ejecuta el siguiente comando `curl`:
{{< text bash >}}
$ curl -s "http://${GATEWAY_URL}/productpage" | grep -o ".*"
Simple Bookstore App
{{< /text >}}
-You can also point your browser to `http://$GATEWAY_URL/productpage`
-to view the Bookinfo web page. If you refresh the page several times, you should
-see different versions of reviews shown in `productpage`, presented in a round robin style (red
-stars, black stars, no stars), since we haven't yet used Istio to control the
-version routing.
+También puedes apuntar tu navegador a `http://$GATEWAY_URL/productpage`
+para ver la página web de Bookinfo. Si refrescas la página varias veces, deberías
+ver diferentes versiones de reseñas mostradas en `productpage`, presentadas en un estilo round robin (estrellas rojas, estrellas negras, sin estrellas), ya que aún no hemos usado Istio para controlar el
+enrutamiento de versiones.
-## Define the service versions
+## Definir las versiones del servicio
-Before you can use Istio to control the Bookinfo version routing, you need to define the available
-versions.
+Antes de poder usar Istio para controlar el enrutamiento de versiones de Bookinfo, necesitas definir las versiones disponibles.
{{< tabset category-name="config-api" >}}
{{< tab name="Istio APIs" category-value="istio-apis" >}}
-Istio uses *subsets*, in [destination rules](/es/docs/concepts/traffic-management/#destination-rules),
-to define versions of a service.
-Run the following command to create default destination rules for the Bookinfo services:
+Istio usa *subsets*, en [destination rules](/es/docs/concepts/traffic-management/#destination-rules),
+para definir versiones de un servicio.
+Ejecuta el siguiente comando para crear reglas de destino por defecto para los servicios de Bookinfo:
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
{{< /text >}}
{{< tip >}}
-The `default` and `demo` [configuration profiles](/es/docs/setup/additional-setup/config-profiles/) have [auto mutual TLS](/es/docs/tasks/security/authentication/authn-policy/#auto-mutual-tls) enabled by default.
-To enforce mutual TLS, use the destination rules in `samples/bookinfo/networking/destination-rule-all-mtls.yaml`.
+Las configuraciones de perfil `default` y `demo` de [perfiles de configuración](/es/docs/setup/additional-setup/config-profiles/) tienen habilitado [auto mutual TLS](/es/docs/tasks/security/authentication/authn-policy/#auto-mutual-tls) por defecto.
+Para aplicar mutual TLS, usa las reglas de destino en `samples/bookinfo/networking/destination-rule-all-mtls.yaml`.
{{< /tip >}}
-Wait a few seconds for the destination rules to propagate.
+Espera unos segundos para que las reglas de destino se propaguen.
-You can display the destination rules with the following command:
+Puedes mostrar las reglas de destino con el siguiente comando:
{{< text bash >}}
$ kubectl get destinationrules -o yaml
@@ -246,10 +242,10 @@ $ kubectl get destinationrules -o yaml
{{< tab name="Gateway API" category-value="gateway-api" >}}
-Unlike the Istio API, which uses `DestinationRule` subsets to define the versions of a service,
-the Kubernetes Gateway API uses backend service definitions for this purpose.
+A diferencia de la API de Istio, que usa `DestinationRule` subsets para definir las versiones de un servicio,
+la API de Kubernetes Gateway usa definiciones de servicios de backend para este propósito.
-Run the following command to create backend service definitions for the three versions of the `reviews` service:
+Ejecuta el siguiente comando para crear definiciones de servicios de backend para las tres versiones del servicio `reviews`:
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-versions.yaml@
@@ -259,18 +255,18 @@ $ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-versions.yaml@
{{< /tabset >}}
-## What's next
+## ¿Qué sigue?
-You can now use this sample to experiment with Istio's features for
-traffic routing, fault injection, rate limiting, etc.
-To proceed, refer to one or more of the [Istio Tasks](/es/docs/tasks),
-depending on your interest. [Configuring Request Routing](/es/docs/tasks/traffic-management/request-routing/)
-is a good place to start for beginners.
+Ahora puedes usar este ejemplo para experimentar con las características de Istio
+para el enrutamiento de tráfico, inyección de fallos, límites de velocidad, etc.
+Para proceder, visita una o más de las [Tareas de Istio](/es/docs/tasks),
+dependiendo de tu interés. [Configurar el enrutamiento de solicitudes](/es/docs/tasks/traffic-management/request-routing/)
+es un buen lugar para empezar para los principiantes.
-## Cleanup
+## Limpieza
-When you're finished experimenting with the Bookinfo sample, uninstall and clean
-it up using the following command:
+Cuando hayas terminado de experimentar con el ejemplo Bookinfo, desinstala y limpia
+usando el siguiente comando:
{{< text bash >}}
$ @samples/bookinfo/platform/kube/cleanup.sh@
diff --git a/content/es/docs/examples/microservices-istio/_index.md b/content/es/docs/examples/microservices-istio/_index.md
index 204d3fa1a5ed0..ec8221fbc2c52 100644
--- a/content/es/docs/examples/microservices-istio/_index.md
+++ b/content/es/docs/examples/microservices-istio/_index.md
@@ -1,17 +1,17 @@
---
-title: Learn Microservices using Kubernetes and Istio
-description: This modular tutorial provides new users with hands-on experience using Istio for common microservices scenarios, one step at a time.
+title: Aprender microservicios usando Kubernetes e Istio
+description: Este tutorial modular proporciona a nuevos usuarios experiencia práctica usando Istio para escenarios comunes de microservicios, paso a paso.
weight: 100
simple_list: true
content_above: true
test: table-of-contents
---
-It is intended for self-guided users or instructors who train
-others. It begins with the steps to set up a cluster to
-control an example microservice running on a local computer, and culminates into
-demonstrating several crucial microservice management tasks using Istio.
+Está dirigido a usuarios autoguiados o instructores que entrenan
+a otros. Comienza con los pasos para configurar un clúster para
+controlar un microservicio de ejemplo ejecutándose en una computadora local, y culmina
+demostrando varias tareas cruciales de gestión de microservicios usando Istio.
-For the best experience, follow the modules in the order provided.
+Para la mejor experiencia, sigue los módulos en el orden proporcionado.
{{< boilerplate work-in-progress >}}
diff --git a/content/es/docs/examples/microservices-istio/istio-ingress-gateway/index.md b/content/es/docs/examples/microservices-istio/istio-ingress-gateway/index.md
index 8b8946ad0f600..c028362e849df 100644
--- a/content/es/docs/examples/microservices-istio/istio-ingress-gateway/index.md
+++ b/content/es/docs/examples/microservices-istio/istio-ingress-gateway/index.md
@@ -1,18 +1,18 @@
---
-title: Configure Istio Ingress Gateway
-overview: Control traffic starting from Ingress.
+title: Configurar Istio Ingress Gateway
+overview: Controlar el tráfico que comienza desde Ingress.
weight: 71
owner: istio/wg-docs-maintainers
test: no
---
-Until now, you used a Kubernetes Ingress to access your application from the
-outside. In this module, you configure the traffic to enter through an Istio
-ingress gateway, in order to apply Istio control on traffic to your microservices.
+Hasta ahora, has usado un Kubernetes Ingress para acceder a tu aplicación desde el
+exterior. En este módulo, configuras el tráfico para que ingrese a través de un Istio
+ingress gateway, para aplicar control de Istio en el tráfico hacia tus microservicios.
-1. Store the name of your namespace in the `NAMESPACE` environment variable.
- You will need it to recognize your microservices in the logs:
+1. Almacena el nombre de tu namespace en la variable de entorno `NAMESPACE`.
+ La necesitarás para reconocer tus microservicios en los logs:
{{< text bash >}}
$ export NAMESPACE=$(kubectl config view -o jsonpath="{.contexts[?(@.name == \"$(kubectl config current-context)\")].context.namespace}")
@@ -20,7 +20,7 @@ ingress gateway, in order to apply Istio control on traffic to your microservice
tutorial
{{< /text >}}
-1. Create an environment variable for the hostname of the Istio ingress gateway:
+1. Crea una variable de entorno para el hostname del Istio ingress gateway:
{{< text bash >}}
$ export MY_INGRESS_GATEWAY_HOST=istio.$NAMESPACE.bookinfo.com
@@ -28,7 +28,7 @@ ingress gateway, in order to apply Istio control on traffic to your microservice
istio.tutorial.bookinfo.com
{{< /text >}}
-1. Configure an Istio ingress gateway:
+1. Configura un Istio ingress gateway:
{{< text bash >}}
$ kubectl apply -f - <}}
-1. Set `INGRESS_HOST` and `INGRESS_PORT` using the instructions in the
- [Determining the Ingress IP and ports](/es/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports) section.
+1. Establece `INGRESS_HOST` e `INGRESS_PORT` usando las instrucciones en la
+ sección [Determinando la IP y puertos de Ingress](/es/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports).
-1. Add the output of this command to your `/etc/hosts` file:
+1. Agrega la salida de este comando a tu archivo `/etc/hosts`:
{{< text bash >}}
$ echo $INGRESS_HOST $MY_INGRESS_GATEWAY_HOST
{{< /text >}}
-1. Access the application's home page from the command line:
+1. Accede a la página principal de la aplicación desde la línea de comandos:
{{< text bash >}}
$ curl -s $MY_INGRESS_GATEWAY_HOST:$INGRESS_PORT/productpage | grep -o ".*"
Simple Bookstore App
{{< /text >}}
-1. Paste the output of the following command in your browser address bar:
+1. Pega la salida del siguiente comando en la barra de direcciones de tu navegador:
{{< text bash >}}
$ echo http://$MY_INGRESS_GATEWAY_HOST:$INGRESS_PORT/productpage
{{< /text >}}
-1. Simulate real-world user traffic to your application by setting an infinite
- loop in a new terminal window:
+1. Simula tráfico de usuario del mundo real hacia tu aplicación estableciendo un
+ bucle infinito en una nueva ventana de terminal:
{{< text bash >}}
$ while :; do curl -s