From 9a3c89a185658f35295e138fd39f1da340100b2c Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Fri, 1 Aug 2025 17:44:29 +0200 Subject: [PATCH 1/5] Add Spanish translation for first 64 files Signed-off-by: Francisco Herrera --- content/es/about/case-studies/fico/index.md | 2 +- content/es/about/deployment/index.md | 16 +- .../how-to-support-tracing.md | 2 +- content/es/about/faq/general/why-use-istio.md | 2 +- .../faq/metrics-and-logs/life-of-a-request.md | 4 +- .../faq/metrics-and-logs/metric-expiry.md | 2 +- .../faq/metrics-and-logs/mixer-migration.md | 2 +- .../metrics-and-logs/telemetry-v1-vs-v2.md | 6 +- .../about/faq/security/auth-mix-and-match.md | 2 +- .../does-istio-support-authorization.md | 2 +- .../about/faq/security/non-istio-to-istio.md | 2 +- .../blog/2024/ambient-reaches-beta/index.md | 18 +- .../es/blog/2024/ambient-reaches-ga/index.md | 18 +- .../es/blog/2024/ambient-vs-cilium/index.md | 2 +- .../2024/authz-policy-with-kyverno/index.md | 2 +- content/es/blog/2024/gateway-mesh-ga/index.md | 2 +- .../es/blog/2024/happy-7th-birthday/index.md | 4 +- .../index.md | 2 +- .../index.md | 56 +- .../es/blog/2024/l7-policy-with-opa/index.md | 2 +- .../es/blog/2025/istio-at-kubecon-eu/index.md | 6 +- content/es/boilerplates/gateway-api-choose.md | 2 +- .../kubectl-multicluster-contexts.md | 2 +- .../revision-tags-default-intro.md | 2 +- .../es/boilerplates/revision-tags-preamble.md | 2 +- .../ambient/architecture/data-plane/index.md | 30 +- .../architecture/traffic-redirection/index.md | 16 +- .../ambient/getting-started/cleanup/index.md | 2 +- .../deploy-sample-app/index.md | 2 +- .../enforce-auth-policies/index.md | 6 +- .../secure-and-visualize/index.md | 8 +- .../ambient/install/helm/all-in-one/index.md | 4 +- content/es/docs/ambient/install/helm/index.md | 8 +- .../es/docs/ambient/install/istioctl/index.md | 2 +- content/es/docs/ambient/overview/index.md | 8 +- .../ambient/upgrade/helm/all-in-one/index.md | 2 +- content/es/docs/ambient/upgrade/helm/index.md | 10 +- content/es/docs/ambient/usage/_index.md | 2 +- .../docs/ambient/usage/add-workloads/index.md | 24 +- .../usage/extend-waypoint-wasm/index.md | 2 +- .../es/docs/ambient/usage/l4-policy/index.md | 4 +- .../docs/ambient/usage/networkpolicy/index.md | 10 +- .../usage/verify-mtls-enabled/index.md | 6 +- .../es/docs/ambient/usage/waypoint/index.md | 10 +- .../es/docs/concepts/observability/index.md | 26 +- content/es/docs/concepts/security/index.md | 22 +- .../docs/concepts/traffic-management/index.md | 52 +- content/es/docs/examples/_index.md | 4 +- content/es/docs/examples/bookinfo/index.md | 186 +++--- .../examples/microservices-istio/_index.md | 14 +- .../istio-ingress-gateway/index.md | 70 +-- .../microservices-istio/logs-istio/index.md | 86 +-- .../package-service/index.md | 38 +- .../microservices-istio/prereq/index.md | 36 +- .../production-testing/index.md | 60 +- .../setup-kubernetes-cluster/index.md | 112 ++-- .../setup-local-computer/index.md | 34 +- .../microservices-istio/single/index.md | 134 ++-- .../docs/examples/virtual-machines/index.md | 82 +-- content/es/docs/ops/_index.md | 4 +- .../docs/ops/best-practices/security/index.md | 589 +++++++++--------- .../mesh/app-health-check/index.md | 96 +-- .../ops/configuration/mesh/webhook/index.md | 63 +- .../index.md | 107 ++-- 64 files changed, 1064 insertions(+), 1069 deletions(-) diff --git a/content/es/about/case-studies/fico/index.md b/content/es/about/case-studies/fico/index.md index 3537b9c3303a..1ef38c6ddd37 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 d4077a8a7f52..fa7db88bcb04 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últiplesmesh 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](/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/). -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-to-support-tracing.md b/content/es/about/faq/distributed-tracing/how-to-support-tracing.md index f5b257ad3e1b..c956365c6577 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 8eb227fa8bdb..6de1cb80ea2d 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 aee4b1379d72..903d0ce57acb 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 7a65fe084c29..2bc37d14022a 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 7b0ee0b2f073..41d44d38ad57 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 d74850e231d8..5524bd6f09d1 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 faf5083099d9..355e13698301 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 7ddf18db2db3..08d9720dad80 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 9519dbf32e5e..7a0285f3686b 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 1d19e678019f..82bcd476ce08 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 cddf69570d8d..cfdc86559ebc 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 2fa87b047605..874f46404438 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 50a477def1d4..2c65c503b087 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 0179ee9d0064..16ed87937a50 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 75e8caa37cc7..2567945af859 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 faae427631ae..e01185f35a18 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 acec5b96f7c4..3e07030287d1 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 9315210f17e7..ee2e8243c64b 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 94bcd07e7fbe..d532d3981ab4 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 6cdebbffb461..e988d161bcd1 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 35fc3f2c780f..1d171b499775 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 meshusando 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 e0fe21144f95..f30a3b558a50 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 87d804eb003e..c27710f949f5 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 meshpuede 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 97de1f51d970..5c9197aac7c3 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 meshhabilitada. 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 meshcon 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 ae083dfe7513..73f633e029db 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 9a0fa05b9e3d..474e4794e571 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 385ef5c03ae5..f35758c5ca75 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 a40b8e65bf81..ee38ee0ddd29 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 61d38c3a441f..79606ee00219 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 3f77fbc0ab5a..55e136a6385a 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 b41b92393b34..a8664e6f4bb7 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 a4a84bffa58a..71f0e92c96cd 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 126b42d6023b..8489496b9d5b 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 meshque 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 meshque 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 9a45e7ef62e6..8b3c5d88e311 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 db1e80ce3fef..587339186e0b 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 4e4d50749c29..968e78ce1042 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 meshpara 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 5bf8e01b7bf5..187199c0b92a 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 meshde 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 3d1de8198056..2051d10909d9 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 27dee926f292..68565a01caac 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 63d8e582ef25..38c58b07482e 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 7b1724ddf0f0..344c65227221 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 f582c473cb7e..557b8a67ebd6 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 meshL7, 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 ee1eafda61ad..8632779085de 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 meshcreados 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,14 +113,14 @@ 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. diff --git a/content/es/docs/concepts/security/index.md b/content/es/docs/concepts/security/index.md index 06c44cffd5f6..ff759aa2ff8c 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 meshde 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 meshen 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 meshy 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 mesho 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,8 +375,8 @@ 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 mesho 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 mesho de namespace. #### Autenticación de pares @@ -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 meshcon un modo no establecido usan el modo `PERMISIVO` por defecto. La siguiente política de autenticación de pares requiere que todos los workloads en el namespace @@ -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 df0e61f56786..9769a4a0d9ee 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 meshsin 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 meshal 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 meshpuede 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 meshutiliza 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 meshagregado 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 meshen 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 889dd7e35bfc..7468ad677244 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 dc05959264df..da44a59467f6 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 204d3fa1a5ed..ec8221fbc2c5 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 8b8946ad0f60..c028362e849d 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 | grep -o ".*"; sleep 1; done @@ -108,43 +108,43 @@ ingress gateway, in order to apply Istio control on traffic to your microservice ... {{< /text >}} -1. Check the graph of your namespace in the Kiali console +1. Verifica el gráfico de tu namespace en la consola de Kiali `my-kiali.io/kiali/console`. - (The `my-kiali.io` URL should be in your `/etc/hosts` file that you set - [previously](/es/docs/examples/microservices-istio/bookinfo-kubernetes/#update-your-etc-hosts-configuration-file)). + (La URL `my-kiali.io` debería estar en tu archivo `/etc/hosts` que configuraste + [anteriormente](/es/docs/examples/microservices-istio/bookinfo-kubernetes/#update-your-etc-hosts-configuration-file)). - This time, you can see that traffic arrives from two sources, `unknown` (the - Kubernetes Ingress) and from `istio-ingressgateway istio-system` (the Istio + Esta vez, puedes ver que el tráfico llega desde dos fuentes, `unknown` (el + Kubernetes Ingress) y desde `istio-ingressgateway istio-system` (el Istio Ingress Gateway). {{< image width="80%" link="kiali-ingress-gateway.png" - caption="Kiali Graph Tab with Istio Ingress Gateway" + caption="Pestaña de Gráfico de Kiali con Istio Ingress Gateway" >}} -1. At this point you can stop sending requests through the Kubernetes Ingress - and use Istio Ingress Gateway only. Stop the infinite loop (`Ctrl-C` in the - terminal window) you set in the previous steps. - In a real production environment, you would update the DNS entry of your - application to contain the IP of Istio ingress gateway or configure your - external Load Balancer. +1. En este punto puedes dejar de enviar solicitudes a través del Kubernetes Ingress + y usar solo el Istio Ingress Gateway. Detén el bucle infinito (`Ctrl-C` en la + ventana de terminal) que estableciste en los pasos anteriores. + En un entorno de producción real, actualizarías la entrada DNS de tu + aplicación para que contenga la IP del Istio ingress gateway o configurarías tu + Load Balancer externo. -1. Delete the Kubernetes Ingress resource: +1. Elimina el recurso Kubernetes Ingress: {{< text bash >}} $ kubectl delete ingress bookinfo ingress.extensions "bookinfo" deleted {{< /text >}} -1. In a new terminal window, restart the real-world user traffic simulation as described in the previous steps. +1. En una nueva ventana de terminal, reinicia la simulación de tráfico de usuario del mundo real como se describe en los pasos anteriores. -1. Check your graph in the Kiali console. After about a minute, you will see - the Istio Ingress Gateway as a single source of traffic for your - application. +1. Verifica tu gráfico en la consola de Kiali. Después de aproximadamente un minuto, verás + el Istio Ingress Gateway como una sola fuente de tráfico para tu + aplicación. {{< image width="80%" link="kiali-ingress-gateway-only.png" - caption="Kiali Graph Tab with Istio Ingress Gateway as a single source of traffic" + caption="Pestaña de Gráfico de Kiali con Istio Ingress Gateway como única fuente de tráfico" >}} -You are ready to configure [logging with Istio](/es/docs/examples/microservices-istio/logs-istio). +Estás listo para configurar [logging con Istio](/es/docs/examples/microservices-istio/logs-istio). diff --git a/content/es/docs/examples/microservices-istio/logs-istio/index.md b/content/es/docs/examples/microservices-istio/logs-istio/index.md index b4279f0766cf..874f6e75cbee 100644 --- a/content/es/docs/examples/microservices-istio/logs-istio/index.md +++ b/content/es/docs/examples/microservices-istio/logs-istio/index.md @@ -1,84 +1,84 @@ --- -title: Monitoring with Istio -overview: Collecting and querying mesh metrics. +title: Monitoreo con Istio +overview: Recopilación y consulta de métricas de malla. weight: 72 owner: istio/wg-docs-maintainers test: no --- -Monitoring is crucial to support transitioning to the microservices architecture style. +El monitoreo es crucial para apoyar la transición al estilo de arquitectura de microservicios. -With Istio, you gain monitoring of the traffic between microservices by default. -You can use the Istio Dashboard for monitoring your microservices in real time. +Con Istio, obtienes monitoreo del tráfico entre microservicios por defecto. +Puedes usar el Dashboard de Istio para monitorear tus microservicios en tiempo real. -Istio is integrated out-of-the-box with -[Prometheus time series database and monitoring system](https://prometheus.io). Prometheus collects various -traffic-related metrics and provides -[a rich query language](https://prometheus.io/docs/prometheus/latest/querying/basics/) for them. +Istio está integrado de forma nativa con +[Prometheus time series database and monitoring system](https://prometheus.io). Prometheus recopila varias +métricas relacionadas con el tráfico y proporciona +[un lenguaje de consulta enriquecido](https://prometheus.io/docs/prometheus/latest/querying/basics/) para ellas. -See below several examples of Prometheus Istio-related queries. +Ve a continuación varios ejemplos de consultas de Prometheus relacionadas con Istio. -1. Access the Prometheus UI at [http://my-istio-logs-database.io](http://my-istio-logs-database.io). -(The `my-istio-logs-database.io` URL should be in your /etc/hosts file, you set it -[previously](/es/docs/examples/microservices-istio/bookinfo-kubernetes/#update-your-etc-hosts-configuration-file)). +1. Accede a la interfaz de usuario de Prometheus en [http://my-istio-logs-database.io](http://my-istio-logs-database.io). +(La URL `my-istio-logs-database.io` debería estar en tu archivo /etc/hosts, la configuraste +[anteriormente](/es/docs/examples/microservices-istio/bookinfo-kubernetes/#update-your-etc-hosts-configuration-file)). - {{< image width="80%" link="prometheus.png" caption="Prometheus Query UI" >}} + {{< image width="80%" link="prometheus.png" caption="Interfaz de Usuario de Consultas de Prometheus" >}} -1. Run the following example queries in the _Expression_ input box. Push the _Execute_ button to see query results in -the _Console_ tab. The queries use `tutorial` as the name of the application's namespace, substitute it with the name of -your namespace. For best results, run the real-time traffic simulator described in the previous steps when querying data. +1. Ejecuta las siguientes consultas de ejemplo en el cuadro de entrada _Expression_. Presiona el botón _Execute_ para ver los resultados de las consultas en +la pestaña _Console_. Las consultas usan `tutorial` como el nombre del namespace de la aplicación, sustitúyelo con el nombre de +tu namespace. Para mejores resultados, ejecuta el simulador de tráfico en tiempo real descrito en los pasos anteriores al consultar datos. - 1. Get all the requests in your namespace: + 1. Obtener todas las solicitudes en tu namespace: {{< text plain >}} istio_requests_total{destination_service_namespace="tutorial", reporter="destination"} {{< /text >}} - 1. Get the sum of all the requests in your namespace: + 1. Obtener la suma de todas las solicitudes en tu namespace: {{< text plain >}} sum(istio_requests_total{destination_service_namespace="tutorial", reporter="destination"}) {{< /text >}} - 1. Get the requests to `reviews` microservice: + 1. Obtener las solicitudes al microservicio `reviews`: {{< text plain >}} istio_requests_total{destination_service_namespace="tutorial", reporter="destination",destination_service_name="reviews"} {{< /text >}} - 1. [Rate](https://prometheus.io/docs/prometheus/latest/querying/functions/#rate) of requests over the past 5 minutes to all instances of the `reviews` microservice: + 1. [Tasa](https://prometheus.io/docs/prometheus/latest/querying/functions/#rate) de solicitudes durante los últimos 5 minutos a todas las instancias del microservicio `reviews`: {{< text plain >}} rate(istio_requests_total{destination_service_namespace="tutorial", reporter="destination",destination_service_name="reviews"}[5m]) {{< /text >}} -The queries above use the `istio_requests_total` metric, which is a standard Istio metric. You can observe -other metrics, in particular, the ones of Envoy ([Envoy](https://www.envoyproxy.io) is the sidecar proxy of Istio). You -can see the collected metrics in the _insert metric at cursor_ drop-down menu. +Las consultas anteriores usan la métrica `istio_requests_total`, que es una métrica estándar de Istio. Puedes observar +otras métricas, en particular, las de Envoy ([Envoy](https://www.envoyproxy.io) es el sidecar proxy de Istio). Puedes +ver las métricas recopiladas en el menú desplegable _insert metric at cursor_. -## Next steps +## Siguientes pasos -Congratulations on completing the tutorial! +¡Felicidades por completar el tutorial! -These tasks are a great place for beginners to further evaluate Istio's -features using this `demo` installation: +Estas tareas son un excelente lugar para que los principiantes evalúen más +características de Istio usando esta instalación `demo`: -- [Request routing](/es/docs/tasks/traffic-management/request-routing/) -- [Fault injection](/es/docs/tasks/traffic-management/fault-injection/) -- [Traffic shifting](/es/docs/tasks/traffic-management/traffic-shifting/) -- [Querying metrics](/es/docs/tasks/observability/metrics/querying-metrics/) -- [Visualizing metrics](/es/docs/tasks/observability/metrics/using-istio-dashboard/) -- [Accessing external services](/es/docs/tasks/traffic-management/egress/egress-control/) -- [Visualizing your mesh](/es/docs/tasks/observability/kiali/) +- [Enrutamiento de solicitudes](/es/docs/tasks/traffic-management/request-routing/) +- [Inyección de fallas](/es/docs/tasks/traffic-management/fault-injection/) +- [Cambio de tráfico](/es/docs/tasks/traffic-management/traffic-shifting/) +- [Consulta de métricas](/es/docs/tasks/observability/metrics/querying-metrics/) +- [Visualización de métricas](/es/docs/tasks/observability/metrics/using-istio-dashboard/) +- [Acceso a servicios externos](/es/docs/tasks/traffic-management/egress/egress-control/) +- [Visualización de tu malla](/es/docs/tasks/observability/kiali/) -Before you customize Istio for production use, see these resources: +Antes de personalizar Istio para uso en producción, consulta estos recursos: -- [Deployment models](/es/docs/ops/deployment/deployment-models/) -- [Deployment best practices](/es/docs/ops/best-practices/deployment/) -- [Pod requirements](/es/docs/ops/deployment/application-requirements/) -- [General installation instructions](/es/docs/setup/) +- [Modelos de despliegue](/es/docs/ops/deployment/deployment-models/) +- [Mejores prácticas de despliegue](/es/docs/ops/best-practices/deployment/) +- [Requisitos de Pod](/es/docs/ops/deployment/application-requirements/) +- [Instrucciones generales de instalación](/es/docs/setup/) -## Join the Istio community +## Únete a la comunidad de Istio -We welcome you to ask questions and give us feedback by joining the -[Istio community](/get-involved/). +Te damos la bienvenida para que hagas preguntas y nos brindes retroalimentación uniéndote a la +[comunidad de Istio](/get-involved/). diff --git a/content/es/docs/examples/microservices-istio/package-service/index.md b/content/es/docs/examples/microservices-istio/package-service/index.md index fcb78d5aefad..9ec202f66bb4 100644 --- a/content/es/docs/examples/microservices-istio/package-service/index.md +++ b/content/es/docs/examples/microservices-istio/package-service/index.md @@ -1,6 +1,6 @@ --- -title: Run ratings in Docker -overview: Run a single microservice in a Docker container. +title: Ejecutar ratings en Docker +overview: Ejecutar un solo microservicio en un contenedor Docker. weight: 20 @@ -10,32 +10,32 @@ test: no {{< boilerplate work-in-progress >}} -This module shows how you create a [Docker](https://www.docker.com) image and run it locally. +Este módulo muestra cómo crear una imagen [Docker](https://www.docker.com) y ejecutarla localmente. -1. Download the [`Dockerfile`](https://docs.docker.com/engine/reference/builder/) for the `ratings` microservice. +1. Descarga el [`Dockerfile`](https://docs.docker.com/engine/reference/builder/) para el microservicio `ratings`. {{< text bash >}} $ curl -s {{< github_file >}}/samples/bookinfo/src/ratings/Dockerfile -o Dockerfile {{< /text >}} -1. Observe the `Dockerfile`. +1. Observa el `Dockerfile`. {{< text bash >}} $ cat Dockerfile {{< /text >}} - Note that it copies the files - into the container's filesystem and then runs the `npm install` command you ran in the previous module. - The `CMD` command instructs Docker to run the `ratings` service on port `9080`. + Nota que copia los archivos + en el sistema de archivos del contenedor y luego ejecuta el comando `npm install` que ejecutaste en el módulo anterior. + El comando `CMD` instruye a Docker para ejecutar el Service `ratings` en el puerto `9080`. -1. Create an environment variable to store your user id which will be used to tag the docker image for `ratings` service. - For example, `user`. +1. Crea una variable de entorno para almacenar tu ID de usuario que se usará para etiquetar la imagen docker para el Service `ratings`. + Por ejemplo, `user`. {{< text bash >}} $ export USER=user {{< /text >}} -1. Build a Docker image from the `Dockerfile`: +1. Construye una imagen Docker desde el `Dockerfile`: {{< text bash >}} $ docker build -t $USER/ratings . @@ -47,23 +47,23 @@ This module shows how you create a [Docker](https://www.docker.com) image and ru Successfully tagged user/ratings:latest {{< /text >}} -1. Run ratings in Docker. The following [docker run](https://docs.docker.com/engine/reference/commandline/run/) command - instructs Docker to expose port `9080` of the container to port `9081` of your computer, allowing you to access the - `ratings` microservice on port `9081`. +1. Ejecuta ratings en Docker. El siguiente comando [docker run](https://docs.docker.com/engine/reference/commandline/run/) + instruye a Docker para exponer el puerto `9080` del contenedor al puerto `9081` de tu computadora, permitiéndote acceder al + microservicio `ratings` en el puerto `9081`. {{< text bash >}} $ docker run --name my-ratings --rm -d -p 9081:9080 $USER/ratings {{< /text >}} -1. Access [http://localhost:9081/ratings/7](http://localhost:9081/ratings/7) in your browser or use the following `curl` command: +1. Accede a [http://localhost:9081/ratings/7](http://localhost:9081/ratings/7) en tu navegador o usa el siguiente comando `curl`: {{< text bash >}} $ curl localhost:9081/ratings/7 {"id":7,"ratings":{"Reviewer1":5,"Reviewer2":4}} {{< /text >}} -1. Observe the running container. Run the [docker ps](https://docs.docker.com/engine/reference/commandline/ps/) command - to list all the running containers and notice the container with the image `/ratings`. +1. Observa el contenedor en ejecución. Ejecuta el comando [docker ps](https://docs.docker.com/engine/reference/commandline/ps/) + para listar todos los contenedores en ejecución y nota el contenedor con la imagen `/ratings`. {{< text bash >}} $ docker ps @@ -72,10 +72,10 @@ This module shows how you create a [Docker](https://www.docker.com) image and ru ... {{< /text >}} -1. Stop the running container: +1. Detén el contenedor en ejecución: {{< text bash >}} $ docker stop my-ratings {{< /text >}} -You have learned how to package a single service into a container. The next step is to learn how to [deploy the whole application to a Kubernetes cluster](/es/docs/examples/microservices-istio/bookinfo-kubernetes). +Has aprendido cómo empaquetar un solo Service en un contenedor. El siguiente paso es aprender cómo [desplegar toda la aplicación en un Cluster de Kubernetes](/es/docs/examples/microservices-istio/bookinfo-kubernetes). diff --git a/content/es/docs/examples/microservices-istio/prereq/index.md b/content/es/docs/examples/microservices-istio/prereq/index.md index b7b54ac0b03e..50d8c6889d06 100644 --- a/content/es/docs/examples/microservices-istio/prereq/index.md +++ b/content/es/docs/examples/microservices-istio/prereq/index.md @@ -1,6 +1,6 @@ --- -title: Prerequisites -overview: Check the prerequisites for this tutorial. +title: Prerrequisitos +overview: Verificar los prerrequisitos para este tutorial. weight: 1 owner: istio/wg-docs-maintainers test: n/a @@ -8,26 +8,26 @@ test: n/a {{< boilerplate work-in-progress >}} -For this tutorial you need a Kubernetes cluster with a namespace for the -tutorial's modules and a local computer to run the commands. If you have your -own cluster, ensure your cluster satisfies the prerequisites. +Para este tutorial necesitas un Cluster de Kubernetes con un namespace para los +módulos del tutorial y una computadora local para ejecutar los comandos. Si tienes tu +propio cluster, asegúrate de que tu cluster satisfaga los prerrequisitos. -If you are in a workshop and the instructors provide a cluster, let -them handle the cluster prerequisites, while you skip ahead to set up your local -computer. +Si estás en un taller y los instructores proporcionan un cluster, deja que +ellos manejen los prerrequisitos del cluster, mientras tú avanzas para configurar tu computadora +local. -## Kubernetes cluster +## Clúster de Kubernetes -Ensure the following conditions are met: +Asegúrate de que se cumplan las siguientes condiciones: -- You have administrator privileges to the virtual machine running a Kubernetes cluster named - `tutorial-cluster` and administrator privileges to the virtual machine it runs on. -- You can create a namespace in the cluster for each participant. +- Tienes privilegios de administrador en la máquina virtual que ejecuta un Cluster de Kubernetes llamado + `tutorial-cluster` y privilegios de administrador en la máquina virtual donde se ejecuta. +- Puedes crear un namespace en el cluster para cada participante. -## Local computer +## Computadora local -Ensure the following conditions are met: +Asegúrate de que se cumplan las siguientes condiciones: -- You have write access to the local computer's `/etc/hosts` file. -- You have the ability and permission to download, install and run command line tools on the local computer. -- You have Internet connectivity for the duration of the tutorial. +- Tienes acceso de escritura al archivo `/etc/hosts` de la computadora local. +- Tienes la capacidad y permisos para descargar, instalar y ejecutar herramientas de línea de comandos en la computadora local. +- Tienes conectividad a Internet durante la duración del tutorial. diff --git a/content/es/docs/examples/microservices-istio/production-testing/index.md b/content/es/docs/examples/microservices-istio/production-testing/index.md index 0600a310f310..48e4aa230918 100644 --- a/content/es/docs/examples/microservices-istio/production-testing/index.md +++ b/content/es/docs/examples/microservices-istio/production-testing/index.md @@ -1,6 +1,6 @@ --- -title: Test in production -overview: Testing a new version of a microservice in production. +title: Pruebas en producción +overview: Probar una nueva versión de un microservicio en producción. weight: 40 @@ -10,30 +10,30 @@ test: no {{< boilerplate work-in-progress >}} -Test your microservice, in production! +¡Prueba tu microservicio, en producción! -## Testing individual microservices +## Probar microservicios individuales -1. Issue an HTTP request from the testing pod to one of your services: +1. Emite una solicitud HTTP desde el Pod de prueba a uno de tus servicios: {{< text bash >}} $ kubectl exec $(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- curl -sS http://ratings:9080/ratings/7 {{< /text >}} -## Chaos testing +## Pruebas de caos -Perform some [chaos testing](http://www.boyter.org/2016/07/chaos-testing-engineering/) -in production and see how your application reacts. After each chaos operation, -access the application's webpage and see if anything changed. Check -the pods' status with `kubectl get pods`. +Realiza algunas [pruebas de caos](http://www.boyter.org/2016/07/chaos-testing-engineering/) +en producción y ve cómo reacciona tu aplicación. Después de cada operación de caos, +accede a la página web de la aplicación y ve si algo cambió. Verifica +el estado de los pods con `kubectl get pods`. -1. Terminate the `details` service in one pod. +1. Termina el Service `details` en un Pod. {{< text bash >}} $ kubectl exec $(kubectl get pods -l app=details -o jsonpath='{.items[0].metadata.name}') -- pkill ruby {{< /text >}} -1. Check the pods status: +1. Verifica el estado de los pods: {{< text bash >}} $ kubectl get pods @@ -53,24 +53,24 @@ the pods' status with `kubectl get pods`. curl-88ddbcfdd-l9zq4 1/1 Running 0 47m {{< /text >}} - Note that the first pod was restarted once. + Nota que el primer Pod se reinició una vez. -1. Terminate the `details` service in all its pods: +1. Termina el servicio `details` en todos sus pods: {{< text bash >}} $ for pod in $(kubectl get pods -l app=details -o jsonpath='{.items[*].metadata.name}'); do echo terminating "$pod"; kubectl exec "$pod" -- pkill ruby; done {{< /text >}} -1. Check the webpage of the application: +1. Verifica la página web de la aplicación: {{< image width="80%" link="bookinfo-details-unavailable.png" - caption="Bookinfo Web Application, details unavailable" + caption="Aplicación Web Bookinfo, detalles no disponibles" >}} - Note that the details section contains error messages instead of book details. + Nota que la sección de detalles contiene mensajes de error en lugar de detalles del libro. -1. Check the pods status: +1. Verifica el estado de los pods: {{< text bash >}} $ kubectl get pods @@ -90,18 +90,18 @@ the pods' status with `kubectl get pods`. curl-88ddbcfdd-l9zq4 1/1 Running 0 48m {{< /text >}} - The first pod restarted twice and two other `details` pods - restarted once. You may experience the `Error` and the - `CrashLoopBackOff` statuses until the pods reach `Running` status. + El primer Pod se reinició dos veces y otros dos pods `details` + se reiniciaron una vez. Puedes experimentar el estado `Error` y el + estado `CrashLoopBackOff` hasta que los pods alcancen el estado `Running`. -1. Use Ctrl-C in the terminal to stop the infinite loop that is running to simulate traffic. +1. Usa Ctrl-C en la terminal para detener el bucle infinito que se está ejecutando para simular tráfico. -In both cases, the application did not crash. The crash in the `details` -microservice did not cause other microservices to fail. This behavior means you -did not have a **cascading failure** in this situation. Instead, you had -**gradual service degradation**: despite one microservice crashing, the -application could still provide useful functionality. It displayed the reviews -and the basic information about the book. +En ambos casos, la aplicación no falló. El fallo en el +microservicio `details` no causó que otros microservicios fallaran. Este comportamiento significa que +no tuviste una **falla en cascada** en esta situación. En su lugar, tuviste +**degradación gradual del servicio**: a pesar de que un microservicio falló, la +aplicación aún pudo proporcionar funcionalidad útil. Mostró las reseñas +y la información básica sobre el libro. -You are ready to -[add a new version of the reviews application](/es/docs/examples/microservices-istio/add-new-microservice-version). +Estás listo para +[agregar una nueva versión de la aplicación reviews](/es/docs/examples/microservices-istio/add-new-microservice-version). diff --git a/content/es/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md b/content/es/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md index 0c6d7e8ce65b..e6e5efa7b4e4 100644 --- a/content/es/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md +++ b/content/es/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md @@ -1,6 +1,6 @@ --- -title: Set up a Kubernetes Cluster -overview: Set up your Kubernetes cluster for the tutorial. +title: Configurar un Cluster de Kubernetes +overview: Configurar tu Cluster de Kubernetes para el tutorial. weight: 2 owner: istio/wg-docs-maintainers test: no @@ -8,65 +8,65 @@ test: no {{< boilerplate work-in-progress >}} -In this module, you set up a Kubernetes cluster that has Istio installed and a -namespace to use throughout the tutorial. +En este módulo, configuras un Cluster de Kubernetes que tiene Istio instalado y un +namespace para usar durante todo el tutorial. {{< warning >}} -If you are in a workshop and the instructors provide a cluster for you, -proceed to [setting up your local computer](/es/docs/examples/microservices-istio/setup-local-computer). +Si estás en un taller y los instructores proporcionan un cluster para ti, +procede a [configurar tu computadora local](/es/docs/examples/microservices-istio/setup-local-computer). {{}} -1. Ensure you have access to a - [Kubernetes cluster](https://kubernetes.io/docs/tutorials/kubernetes-basics/). - You can use the +1. Asegúrate de tener acceso a un + [Cluster de Kubernetes](https://kubernetes.io/docs/tutorials/kubernetes-basics/). + Puedes usar el [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/quickstart) - or the + o el [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started). -1. Create an environment variable to store the name - of a namespace that you will use when you run the tutorial commands. - You can use any name, for example `tutorial`. +1. Crea una variable de entorno para almacenar el nombre + de un namespace que usarás cuando ejecutes los comandos del tutorial. + Puedes usar cualquier nombre, por ejemplo `tutorial`. {{< text bash >}} $ export NAMESPACE=tutorial {{< /text >}} -1. Create the namespace: +1. Crea el namespace: {{< text bash >}} $ kubectl create namespace $NAMESPACE {{< /text >}} {{< tip >}} - If you are an instructor, you should allocate a separate namespace per each - participant. The tutorial supports work in multiple namespaces - simultaneously by multiple participants. + Si eres instructor, deberías asignar un namespace separado por cada + participante. El tutorial soporta trabajo en múltiples namespaces + simultáneamente por múltiples participantes. {{< /tip >}} -1. [Install Istio](/es/docs/setup/getting-started/) using the `demo` profile. +1. [Instala Istio](/es/docs/setup/getting-started/) usando el perfil `demo`. -1. The [Kiali](/es/docs/ops/integrations/kiali/) and [Prometheus](/es/docs/ops/integrations/prometheus/) addons are used in this example and need to be installed. All addons are installed using: +1. Los addons [Kiali](/es/docs/ops/integrations/kiali/) y [Prometheus](/es/docs/ops/integrations/prometheus/) se usan en este ejemplo y necesitan ser instalados. Todos los addons se instalan usando: {{< text bash >}} $ kubectl apply -f @samples/addons@ {{< /text >}} {{< tip >}} - If there are errors trying to install the addons, try running the command again. There may - be some timing issues which will be resolved when the command is run again. + Si hay errores tratando de instalar los addons, intenta ejecutar el comando nuevamente. Puede que + haya algunos problemas de temporización que se resolverán cuando el comando se ejecute nuevamente. {{< /tip >}} -1. Create a Kubernetes Ingress resource for these common Istio services using - the `kubectl` command shown. It is not necessary to be familiar with each of - these services at this point in the tutorial. +1. Crea un recurso Kubernetes Ingress para estos servicios comunes de Istio usando + el comando `kubectl` mostrado. No es necesario estar familiarizado con cada uno de + estos servicios en este punto del tutorial. - [Grafana](https://grafana.com/docs/guides/getting_started/) - [Jaeger](https://www.jaegertracing.io/docs/1.13/getting-started/) - [Prometheus](https://prometheus.io/docs/prometheus/latest/getting_started/) - [Kiali](https://kiali.io/docs/installation/quick-start/) - The `kubectl` command can accept an in-line configuration to create the - Ingress resources for each service: + El comando `kubectl` puede aceptar una configuración en línea para crear los + recursos Ingress para cada servicio: {{< text bash >}} $ kubectl apply -f - <}} -1. Create a role to provide read access to the `istio-system` namespace. This - role is required to limit permissions of the participants in the steps - below. +1. Crea un rol para proporcionar acceso de lectura al namespace `istio-system`. Este + rol es requerido para limitar los permisos de los participantes en los pasos + a continuación. {{< text bash >}} $ kubectl apply -f - <}} -1. Create a service account for each participant: +1. Crea una service account para cada participante: {{< text bash >}} $ kubectl apply -f - <}} -1. Limit each participant's permissions. During the tutorial, participants only - need to create resources in their namespace and to read resources from - `istio-system` namespace. It is a good practice, even if using your own - cluster, to avoid interfering with other namespaces in - your cluster. +1. Limita los permisos de cada participante. Durante el tutorial, los participantes solo + necesitan crear recursos en su namespace y leer recursos del + namespace `istio-system`. Es una buena práctica, incluso si usas tu propio + cluster, evitar interferir con otros namespaces en + tu cluster. - Create a role to allow read-write access to each participant's namespace. - Bind the participant's service account to this role and to the role for - reading resources from `istio-system`: + Crea un rol para permitir acceso de lectura-escritura al namespace de cada participante. + Vincula la cuenta de servicio del participante a este rol y al rol para + leer recursos desde `istio-system`: {{< text bash >}} $ kubectl apply -f - <}} -1. Each participant needs to use their own Kubernetes configuration file. This configuration file specifies - the cluster details, the service account, the credentials and the namespace of the participant. - The `kubectl` command uses the configuration file to operate on the cluster. +1. Cada participante necesita usar su propio archivo de configuración de Kubernetes. Este archivo de configuración especifica + los detalles del cluster, la service account, las credenciales y el namespace del participante. + El comando `kubectl` usa el archivo de configuración para operar en el cluster. - Generate a Kubernetes configuration file for each participant: + Genera un archivo de configuración de Kubernetes para cada participante: {{< tip >}} - This command assumes your cluster is named `tutorial-cluster`. If your cluster is named differently, replace all references with the name of your cluster. + Este comando asume que tu cluster se llama `tutorial-cluster`. Si tu cluster tiene un nombre diferente, reemplaza todas las referencias con el nombre de tu cluster. {{}} {{< text bash >}} @@ -245,31 +245,31 @@ proceed to [setting up your local computer](/es/docs/examples/microservices-isti EOF {{< /text >}} -1. Set the `KUBECONFIG` environment variable for the `${NAMESPACE}-user-config.yaml` - configuration file: +1. Establece la variable de entorno `KUBECONFIG` para el archivo de configuración + `${NAMESPACE}-user-config.yaml`: {{< text bash >}} $ export KUBECONFIG=$PWD/${NAMESPACE}-user-config.yaml {{< /text >}} -1. Verify that the configuration took effect by printing the current namespace: +1. Verifica que la configuración surtió efecto imprimiendo el namespace actual: {{< text bash >}} $ kubectl config view -o jsonpath="{.contexts[?(@.name==\"$(kubectl config current-context)\")].context.namespace}" tutorial {{< /text >}} - You should see the name of your namespace in the output. + Deberías ver el nombre de tu namespace en la salida. -1. If you are setting up the cluster for yourself, copy the - `${NAMESPACE}-user-config.yaml` file mentioned in the previous steps to your - local computer, where `${NAMESPACE}` is the name of the namespace you - provided in the previous steps. For example, `tutorial-user-config.yaml`. - You will need this file later in the tutorial. +1. Si estás configurando el cluster para ti mismo, copia el + archivo `${NAMESPACE}-user-config.yaml` mencionado en los pasos anteriores a tu + computadora local, donde `${NAMESPACE}` es el nombre del namespace que + proporcionaste en los pasos anteriores. Por ejemplo, `tutorial-user-config.yaml`. + Necesitarás este archivo más tarde en el tutorial. - If you are an instructor, send the generated configuration files to each - participant. The participants must copy their configuration file to their local computer. + Si eres instructor, envía los archivos de configuración generados a cada + participante. Los participantes deben copiar su archivo de configuración a su computadora local. -Congratulations, you configured your cluster for the tutorial! +¡Felicidades, configuraste tu cluster para el tutorial! -You are ready to [set up a local computer](/es/docs/examples/microservices-istio/setup-local-computer). +Estás listo para [configurar una computadora local](/es/docs/examples/microservices-istio/setup-local-computer). diff --git a/content/es/docs/examples/microservices-istio/setup-local-computer/index.md b/content/es/docs/examples/microservices-istio/setup-local-computer/index.md index b16b8892202f..28748153e52e 100644 --- a/content/es/docs/examples/microservices-istio/setup-local-computer/index.md +++ b/content/es/docs/examples/microservices-istio/setup-local-computer/index.md @@ -1,6 +1,6 @@ --- -title: Set up a Local Computer -overview: Set up your local computer for the tutorial. +title: Configurar una Computadora Local +overview: Configurar tu computadora local para el tutorial. weight: 3 owner: istio/wg-docs-maintainers test: no @@ -8,36 +8,36 @@ test: no {{< boilerplate work-in-progress >}} -In this module you prepare your local computer for the tutorial. +En este módulo preparas tu computadora local para el tutorial. -1. Install [`curl`](https://curl.haxx.se/download.html). +1. Instala [`curl`](https://curl.haxx.se/download.html). -1. Install [Node.js](https://nodejs.org/en/download/). +1. Instala [Node.js](https://nodejs.org/en/download/). -1. Install [Docker](https://docs.docker.com/install/). +1. Instala [Docker](https://docs.docker.com/install/). -1. Install [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/). +1. Instala [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/). -1. Set the `KUBECONFIG` environment variable for the configuration file you received from the tutorial instructors, or - created yourself in the previous module. +1. Establece la variable de entorno `KUBECONFIG` para el archivo de configuración que recibiste de los instructores del tutorial, o + creaste tú mismo en el módulo anterior. {{< text bash >}} $ export KUBECONFIG= {{< /text >}} -1. Verify that the configuration took effect by printing the current namespace: +1. Verifica que la configuración surtió efecto imprimiendo el namespace actual: {{< text bash >}} $ kubectl config view -o jsonpath="{.contexts[?(@.name==\"$(kubectl config current-context)\")].context.namespace}" tutorial {{< /text >}} - You should see in the output the name of the namespace, allocated for you by the instructors or allocated by - yourself in the previous module. + Deberías ver en la salida el nombre del namespace, asignado para ti por los instructores o asignado por + ti mismo en el módulo anterior. -1. Download one of the [Istio release archives](https://github.com/istio/istio/releases) and extract - the `istioctl` command line tool from the `bin` directory, and verify that you - can run `istioctl` with the following command: +1. Descarga uno de los [archivos de release de Istio](https://github.com/istio/istio/releases) y extrae + la herramienta de línea de comandos `istioctl` del directorio `bin`, y verifica que puedas + ejecutar `istioctl` con el siguiente comando: {{< text bash >}} $ istioctl version @@ -46,6 +46,6 @@ In this module you prepare your local computer for the tutorial. data plane version: 1.22.0 (4 proxies) {{< /text >}} -Congratulations, you configured your local computer! +¡Felicidades, configuraste tu computadora local! -You are ready to [run a single service locally](/es/docs/examples/microservices-istio/single/). +Estás listo para [ejecutar un solo servicio localmente](/es/docs/examples/microservices-istio/single/). diff --git a/content/es/docs/examples/microservices-istio/single/index.md b/content/es/docs/examples/microservices-istio/single/index.md index 930faa7350d6..de422986bab3 100644 --- a/content/es/docs/examples/microservices-istio/single/index.md +++ b/content/es/docs/examples/microservices-istio/single/index.md @@ -1,6 +1,6 @@ --- -title: Run a Microservice Locally -overview: Learn how to work on a single service on your local machine. +title: Ejecutar un microservicio Localmente +overview: Aprende cómo trabajar en un solo servicio en tu máquina local. weight: 10 owner: istio/wg-docs-maintainers test: no @@ -8,45 +8,45 @@ test: no {{< boilerplate work-in-progress >}} -Before the advent of microservice architecture, development teams built, -deployed and ran the whole application as one large chunk of software. To test a -small change in their module not merely by unit testing, the developers had to -build the whole application. Therefore the builds took large amount of time. -After the build, the developers deployed their version of the application into a -test server. The developers ran the server either on a remote machine, or on their -local computer. In the latter case, the developers had to install and operate a -rather complex environment on their local computer. - -In the era of microservice architecture, the developers write, build, test and -run small software services. Builds are fast. With modern frameworks like -[Node.js](https://nodejs.org/en/) there is no need to install and operate -complex server environments to test a single service, since the service runs as -a regular process. You do not have to deploy your service to some environment to -merely test it, so you just build your service and run it immediately on your -local computer. - -This module covers the different aspects involved in developing a single service -on a local machine. You don't need to write code though. Instead, you build, -run, and test an existing service: `ratings`. - -The `ratings` service is a small web app written in -[Node.js](https://nodejs.org/en/) that can run on its own. It performs similar -actions to those of other web apps: - -- Listen to the port it receives as a parameter. -- Expect `HTTP GET` requests on the `/ratings/{productID}` path and return the - ratings of the product matching the value the client specifies for `productID`. -- Expect `HTTP POST` requests on the `/ratings/{productID}` path and update the - ratings of the product matching the value you specify for `productID`. - -Follow these steps to download the code of the app, install its dependencies, -and run it locally: - -1. Download - [the service's code]({{< github_blob >}}/samples/bookinfo/src/ratings/ratings.js) - and - [the package file]({{< github_blob >}}/samples/bookinfo/src/ratings/package.json) - into a separate directory: +Antes del advenimiento de la arquitectura de microservicios, los equipos de desarrollo construían, +desplegaban y ejecutaban toda la aplicación como un gran bloque de software. Para probar un +pequeño cambio en su módulo no solo mediante pruebas unitarias, los desarrolladores tenían que +construir toda la aplicación. Por lo tanto, las construcciones tomaban una gran cantidad de tiempo. +Después de la construcción, los desarrolladores desplegaban su versión de la aplicación en un +servidor de prueba. Los desarrolladores ejecutaban el servidor ya sea en una máquina remota, o en su +computadora local. En el último caso, los desarrolladores tenían que instalar y operar un +entorno bastante complejo en su computadora local. + +En la era de la arquitectura de microservicios, los desarrolladores escriben, construyen, prueban y +ejecutan pequeños servicios de software. Las construcciones son rápidas. Con frameworks modernos como +[Node.js](https://nodejs.org/en/) no hay necesidad de instalar y operar +entornos de servidor complejos para probar un solo servicio, ya que el servicio se ejecuta como +un proceso regular. No tienes que desplegar tu servicio a algún entorno para +simplemente probarlo, así que solo construyes tu servicio y lo ejecutas inmediatamente en tu +computadora local. + +Este módulo cubre los diferentes aspectos involucrados en desarrollar un solo servicio +en una máquina local. Sin embargo, no necesitas escribir código. En su lugar, construyes, +ejecutas y pruebas un servicio existente: `ratings`. + +El servicio `ratings` es una pequeña aplicación web escrita en +[Node.js](https://nodejs.org/en/) que puede ejecutarse por sí sola. Realiza acciones similares +a las de otras aplicaciones web: + +- Escucha en el puerto que recibe como parámetro. +- Espera solicitudes `HTTP GET` en la ruta `/ratings/{productID}` y retorna las + calificaciones del producto que coincide con el valor que el cliente especifica para `productID`. +- Espera solicitudes `HTTP POST` en la ruta `/ratings/{productID}` y actualiza las + calificaciones del producto que coincide con el valor que especificas para `productID`. + +Sigue estos pasos para descargar el código de la aplicación, instalar sus dependencias, +y ejecutarla localmente: + +1. Descarga + [el código del servicio]({{< github_blob >}}/samples/bookinfo/src/ratings/ratings.js) + y + [el archivo de paquete]({{< github_blob >}}/samples/bookinfo/src/ratings/package.json) + en un directorio separado: {{< text bash >}} $ mkdir ratings @@ -55,24 +55,24 @@ and run it locally: $ curl -s {{< github_file >}}/samples/bookinfo/src/ratings/package.json -o package.json {{< /text >}} -1. Skim the service's code and note the following elements: - - The web server's features: - - listening to a port - - handling requests and responses - - The aspects related to HTTP: +1. Examina superficialmente el código del servicio y nota los siguientes elementos: + - Las características del servidor web: + - escuchar en un puerto + - manejar solicitudes y respuestas + - Los aspectos relacionados con HTTP: - headers - path - - status code + - código de estado {{< tip >}} - In Node.js, the web server's functionality is embedded in the code of the application. A Node.js - web application runs as a standalone process. + En Node.js, la funcionalidad del servidor web está embebida en el código de la aplicación. Una aplicación + web de Node.js se ejecuta como un proceso independiente. {{< /tip >}} -1. Node.js applications are written in JavaScript, which means that there is no - explicit compilation step. Instead, they use [just-in-time compilation](https://en.wikipedia.org/wiki/Just-in-time_compilation). To build a Node.js application, then means to install its dependencies. Install - the dependencies of the `ratings` service in the same folder where you - stored the service code and the package file: +1. Las aplicaciones de Node.js están escritas en JavaScript, lo que significa que no hay + paso de compilación explícito. En su lugar, usan [compilación just-in-time](https://en.wikipedia.org/wiki/Just-in-time_compilation). Construir una aplicación de Node.js, entonces significa instalar sus dependencias. Instala + las dependencias del servicio `ratings` en la misma carpeta donde almacenaste + el código del servicio y el archivo de paquete: {{< text bash >}} $ npm install @@ -84,7 +84,7 @@ and run it locally: added 24 packages in 2.094s {{< /text >}} -1. Run the service, passing `9080` as a parameter. The application then listens on port 9080. +1. Ejecuta el servicio, pasando `9080` como parámetro. La aplicación entonces escucha en el puerto 9080. {{< text bash >}} $ npm start 9080 @@ -94,38 +94,38 @@ and run it locally: {{< /text >}} {{< tip >}} -The `ratings` service is a web app and you can communicate with it as you would -with any other web app. You can use a browser or a command line web client like -[`curl`](https://curl.haxx.se) or [`Wget`](https://www.gnu.org/software/wget/). -Since you run the `ratings` service locally, you can also access it via the -`localhost` hostname. +El servicio `ratings` es una aplicación web y puedes comunicarte con ella como lo harías +con cualquier otra aplicación web. Puedes usar un navegador o un cliente web de línea de comandos como +[`curl`](https://curl.haxx.se) o [`Wget`](https://www.gnu.org/software/wget/). +Ya que ejecutas el servicio `ratings` localmente, también puedes acceder a él a través del +hostname `localhost`. {{< /tip >}} -1. Open [http://localhost:9080/ratings/7](http://localhost:9080/ratings/7) in - your browser or access `ratings` using the `curl` command from a different terminal window: +1. Abre [http://localhost:9080/ratings/7](http://localhost:9080/ratings/7) en + tu navegador o accede a `ratings` usando el comando `curl` desde una ventana de terminal diferente: {{< text bash >}} $ curl localhost:9080/ratings/7 {"id":7,"ratings":{"Reviewer1":5,"Reviewer2":4}} {{< /text >}} -1. Use the `POST` method of the `curl` command to set the ratings for the - product to `1`: +1. Usa el método `POST` del comando `curl` para establecer las calificaciones para el + producto a `1`: {{< text bash >}} $ curl -X POST localhost:9080/ratings/7 -d '{"Reviewer1":1,"Reviewer2":1}' {"id":7,"ratings":{"Reviewer1":1,"Reviewer2":1}} {{< /text >}} -1. Check the updated ratings: +1. Verifica las calificaciones actualizadas: {{< text bash >}} $ curl localhost:9080/ratings/7 {"id":7,"ratings":{"Reviewer1":1,"Reviewer2":1}} {{< /text >}} -1. Use `Ctrl-C` in the terminal running the service to stop it. +1. Usa `Ctrl-C` en la terminal que ejecuta el servicio para detenerlo. -Congratulations, you can now build, test, and run a service on your local computer! +¡Felicidades, ahora puedes construir, probar y ejecutar un servicio en tu computadora local! -You are ready to [package the service](/es/docs/examples/microservices-istio/package-service) into a container. +Estás listo para [empaquetar el servicio](/es/docs/examples/microservices-istio/package-service) en un contenedor. diff --git a/content/es/docs/examples/virtual-machines/index.md b/content/es/docs/examples/virtual-machines/index.md index 692a22debbf9..ba4093fbfa84 100644 --- a/content/es/docs/examples/virtual-machines/index.md +++ b/content/es/docs/examples/virtual-machines/index.md @@ -1,7 +1,7 @@ --- -title: Bookinfo with a Virtual Machine -description: Run the Bookinfo application with a MySQL service running on a virtual - machine within your mesh. +title: Bookinfo con una Virtual Machine +description: Ejecutar la aplicación Bookinfo con un Service MySQL ejecutándose en una virtual + machine dentro de tu malla. weight: 60 keywords: - virtual-machine @@ -15,41 +15,41 @@ owner: istio/wg-environments-maintainers test: yes --- -This example deploys the Bookinfo application across Kubernetes with one -service running on a virtual machine (VM), and illustrates how to control -this infrastructure as a single mesh. +Este ejemplo despliega la aplicación Bookinfo a través de Kubernetes con un +Service ejecutándose en una Virtual Machine (VM), e ilustra cómo controlar +esta infraestructura como una sola malla. -## Overview +## Visión general -{{< image width="80%" link="./vm-bookinfo.svg" caption="Bookinfo running on VMs" >}} +{{< image width="80%" link="./vm-bookinfo.svg" caption="Bookinfo ejecutándose en VMs" >}} -## Before you begin +## Antes de comenzar -- Setup Istio by following the instructions in the - [Virtual Machine Installation guide](/es/docs/setup/install/virtual-machine/). +- Configura Istio siguiendo las instrucciones en la + [guía de instalación de Virtual Machine](/es/docs/setup/install/virtual-machine/). -- Deploy the [Bookinfo](/es/docs/examples/bookinfo/) sample application (in the `bookinfo` namespace). +- Despliega la aplicación de ejemplo [Bookinfo](/es/docs/examples/bookinfo/) (en el namespace `bookinfo`). -- Create a VM and add it to the `vm` namespace, following the steps in - [Configure the virtual machine](/es/docs/setup/install/virtual-machine/#configure-the-virtual-machine). +- Crea una VM y agrégala al namespace `vm`, siguiendo los pasos en + [Configurar la Virtual Machine](/es/docs/setup/install/virtual-machine/#configure-the-virtual-machine). -## Running MySQL on the VM +## Ejecutar MySQL en la VM -We will first install MySQL on the VM, and configure it as a backend for the ratings service. -All commands below should be run on the VM. +Primero instalaremos MySQL en la VM, y lo configuraremos como un backend para el Service ratings. +Todos los comandos a continuación deben ejecutarse en la VM. -Install `mariadb`: +Instala `mariadb`: {{< text bash >}} $ sudo apt-get update && sudo apt-get install -y mariadb-server $ sudo sed -i '/bind-address/c\bind-address = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf {{< /text >}} -Set up authentication: +Configura la autenticación: {{< text bash >}} $ cat <}} -You can find details of configuring MySQL at [Mysql](https://mariadb.com/kb/en/library/download/). +Puedes encontrar detalles sobre configurar MySQL en [Mysql](https://mariadb.com/kb/en/library/download/). -On the VM add ratings database to mysql. +En la VM agrega la base de datos ratings a mysql. {{< text bash >}} $ curl -LO {{< github_file >}}/samples/bookinfo/src/mysql/mysqldb-init.sql $ mysql -u root -ppassword < mysqldb-init.sql {{< /text >}} -To make it easy to visually inspect the difference in the output of the Bookinfo application, you can change the ratings that are generated by using the -following commands to inspect the ratings: +Para facilitar la inspección visual de la diferencia en la salida de la aplicación Bookinfo, puedes cambiar las calificaciones que se generan usando los +siguientes comandos para inspeccionar las calificaciones: {{< text bash >}} $ mysql -u root -ppassword test -e "select * from ratings;" @@ -86,7 +86,7 @@ $ mysql -u root -ppassword test -e "select * from ratings;" +----------+--------+ {{< /text >}} -and to change the ratings +y para cambiar las calificaciones {{< text bash >}} $ mysql -u root -ppassword test -e "update ratings set rating=1 where reviewid=1;select * from ratings;" @@ -98,10 +98,10 @@ $ mysql -u root -ppassword test -e "update ratings set rating=1 where reviewid= +----------+--------+ {{< /text >}} -## Expose the mysql service to the mesh +## Exponer el Service mysql a la mesh -When the virtual machine is started, it will automatically be registered into the mesh. -However, just like when creating a Pod, we still need to create a Service before we can easily access it. +Cuando la Virtual Machine se inicia, se registrará automáticamente en la mesh. +Sin embargo, al igual que cuando se crea un Pod, aún necesitamos crear un Service antes de poder acceder a él fácilmente. {{< text bash >}} $ cat <}} -## Using the mysql service +## Usar el Service mysql -The ratings service in Bookinfo will use the DB on the machine. To verify that it works, create version 2 of the ratings service that uses the mysql db on the VM. Then specify route rules that force the review service to use the ratings version 2. +El Service ratings en Bookinfo usará la DB en la máquina. Para verificar que funciona, crea la versión 2 del Service ratings que usa la base de datos mysql en la VM. Luego especifica reglas de enrutamiento que fuerzan al Service review a usar la versión 2 de ratings. {{< text bash >}} $ kubectl apply -n bookinfo -f @samples/bookinfo/platform/kube/bookinfo-ratings-v2-mysql-vm.yaml@ {{< /text >}} -Create route rules that will force Bookinfo to use the ratings back end: +Crea reglas de enrutamiento que forzarán a Bookinfo a usar el backend ratings: {{< text bash >}} $ kubectl apply -n bookinfo -f @samples/bookinfo/networking/virtual-service-ratings-mysql-vm.yaml@ {{< /text >}} -You can verify the output of the Bookinfo application is showing 1 star from Reviewer1 and 4 stars from Reviewer2 or change the ratings on your VM and see the -results. +Puedes verificar que la salida de la aplicación Bookinfo muestra 1 estrella de Reviewer1 y 4 estrellas de Reviewer2 o cambiar las calificaciones en tu VM y ver los +resultados. -## Reaching Kubernetes services from the virtual machine +## Alcanzar los Services de Kubernetes desde la Virtual Machine -In the above example, we treated our virtual machine as only a server. -We can also seamlessly call Kubernetes services from our virtual machine: +En el ejemplo anterior, tratamos nuestra Virtual Machine solo como un servidor. +También podemos llamar sin problemas a los Services de Kubernetes desde nuestra Virtual Machine: {{< text bash >}} $ curl productpage.bookinfo:9080/productpage @@ -149,16 +149,16 @@ $ curl productpage.bookinfo:9080/productpage ... {{< /text >}} -Istio's [DNS proxying](/es/docs/ops/configuration/traffic-management/dns-proxy/) automatically configures DNS for the virtual machine, allowing us to make calls to Kubernetes hostnames. +El [DNS proxying](/es/docs/ops/configuration/traffic-management/dns-proxy/) de Istio configura automáticamente el DNS para la Virtual Machine, permitiéndonos hacer llamadas a los hostnames de Kubernetes. -## Cleanup +## Limpieza -- Delete the `Bookinfo` sample application and its configuration following the steps in -[`Bookinfo` cleanup](/es/docs/examples/bookinfo/#cleanup). -- Delete the `mysqldb` Service: +- Elimina la aplicación de ejemplo `Bookinfo` y su configuración siguiendo los pasos en +[limpieza de `Bookinfo`](/es/docs/examples/bookinfo/#cleanup). +- Elimina el Service `mysqldb`: {{< text syntax=bash snip_id=none >}} $ kubectl delete service mysqldb {{< /text >}} -- Cleanup the VM following the steps in [virtual-machine uninstall](/es/docs/setup/install/virtual-machine/#uninstall). +- Limpia la VM siguiendo los pasos en [desinstalación de Virtual Machine](/es/docs/setup/install/virtual-machine/#uninstall). diff --git a/content/es/docs/ops/_index.md b/content/es/docs/ops/_index.md index ca6aae9dcda0..20758be18907 100644 --- a/content/es/docs/ops/_index.md +++ b/content/es/docs/ops/_index.md @@ -1,6 +1,6 @@ --- -title: Operations -description: Concepts, tools, and techniques to deploy and manage an Istio mesh. +title: Operaciones +description: Conceptos, herramientas y técnicas para desplegar y gestionar un mesh de Istio. weight: 32 aliases: - /troubleshooting.html diff --git a/content/es/docs/ops/best-practices/security/index.md b/content/es/docs/ops/best-practices/security/index.md index 3f49323e1aa3..92e50155513c 100644 --- a/content/es/docs/ops/best-practices/security/index.md +++ b/content/es/docs/ops/best-practices/security/index.md @@ -1,76 +1,76 @@ --- -title: Security Best Practices -description: Best practices for securing applications using Istio. +title: Mejores Prácticas de Seguridad +description: Mejores prácticas para asegurar aplicaciones usando Istio. force_inline_toc: true weight: 30 owner: istio/wg-security-maintainers test: n/a --- -Istio security features provide strong identity, powerful policy, transparent TLS encryption, and authentication, authorization and audit (AAA) tools to protect your services and data. -However, to fully make use of these features securely, care must be taken to follow best practices. It is recommended to review the [Security overview](/es/docs/concepts/security/) before proceeding. +Las características de seguridad de Istio proporcionan identidad fuerte, política poderosa, cifrado TLS transparente, y herramientas de autenticación, autorización y auditoría (AAA) para proteger tus servicios y datos. +Sin embargo, para aprovechar completamente estas características de manera segura, se debe tener cuidado de seguir las mejores prácticas. Se recomienda revisar la [Visión general de seguridad](/es/docs/concepts/security/) antes de proceder. ## Mutual TLS -Istio will [automatically](/es/docs/ops/configuration/traffic-management/tls-configuration/#auto-mtls) encrypt traffic using [Mutual TLS](/es/docs/concepts/security/#mutual-tls-authentication) whenever possible. -However, proxies are configured in [permissive mode](/es/docs/concepts/security/#permissive-mode) by default, meaning they will accept both mutual TLS and plaintext traffic. +Istio [automáticamente](/es/docs/ops/configuration/traffic-management/tls-configuration/#auto-mtls) cifrará el tráfico usando [Mutual TLS](/es/docs/concepts/security/#mutual-tls-authentication) siempre que sea posible. +Sin embargo, los proxies están configurados en [modo permisivo](/es/docs/concepts/security/#permissive-mode) por defecto, lo que significa que aceptarán tanto tráfico mutual TLS como texto plano. -While this is required for incremental adoption or allowing traffic from clients without an Istio sidecar, it also weakens the security stance. -It is recommended to [migrate to strict mode](/es/docs/tasks/security/authentication/mtls-migration/) when possible, to enforce that mutual TLS is used. +Aunque esto es requerido para adopción incremental o para permitir tráfico de clientes sin un sidecar de Istio, también debilita la postura de seguridad. +Se recomienda [migrar al modo estricto](/es/docs/tasks/security/authentication/mtls-migration/) cuando sea posible, para hacer cumplir que se use mutual TLS. -Mutual TLS alone is not always enough to fully secure traffic, however, as it provides only authentication, not authorization. -This means that anyone with a valid certificate can still access a service. +Mutual TLS por sí solo no siempre es suficiente para asegurar completamente el tráfico, sin embargo, ya que proporciona solo autenticación, no autorización. +Esto significa que cualquiera con un certificado válido aún puede acceder a un servicio. -To fully lock down traffic, it is recommended to configure [authorization policies](/es/docs/tasks/security/authorization/). -These allow creating fine-grained policies to allow or deny traffic. For example, you can allow only requests from the `app` namespace to access the `hello-world` service. +Para bloquear completamente el tráfico, se recomienda configurar [políticas de autorización](/es/docs/tasks/security/authorization/). +Estas permiten crear políticas de grano fino para permitir o denegar tráfico. Por ejemplo, puedes permitir solo solicitudes del namespace `app` para acceder al Service `hello-world`. -## Authorization policies +## Políticas de autorización -Istio [authorization](/es/docs/concepts/security/#authorization) plays a critical part in Istio security. -It takes effort to configure the correct authorization policies to best protect your clusters. -It is important to understand the implications of these configurations as Istio cannot determine the proper authorization for all users. -Please follow this section in its entirety. +La [autorización](/es/docs/concepts/security/#authorization) de Istio juega un papel crítico en la seguridad de Istio. +Toma esfuerzo configurar las políticas de autorización correctas para proteger mejor tus clusters. +Es importante entender las implicaciones de estas configuraciones ya que Istio no puede determinar la autorización apropiada para todos los usuarios. +Por favor sigue esta sección en su totalidad. -### Safer Authorization Policy Patterns +### Patrones de Política de Autorización Más Seguros -#### Use default-deny patterns +#### Usar patrones de denegación por defecto -We recommend you define your Istio authorization policies following the default-deny pattern to enhance your cluster's security posture. -The default-deny authorization pattern means your system denies all requests by default, and you define the conditions in which the requests are allowed. -In case you miss some conditions, traffic will be unexpectedly denied, instead of traffic being unexpectedly allowed. -The latter typically being a security incident while the former may result in a poor user experience, a service outage or will not match your SLO/SLA. +Recomendamos que definas tus políticas de autorización de Istio siguiendo el patrón de denegación por defecto para mejorar la postura de seguridad de tu cluster. +El patrón de autorización de denegación por defecto significa que tu sistema deniega todas las solicitudes por defecto, y defines las condiciones en las que se permiten las solicitudes. +En caso de que omitas algunas condiciones, el tráfico será denegado inesperadamente, en lugar de que el tráfico sea permitido inesperadamente. +Lo último típicamente siendo un incidente de seguridad mientras que lo primero puede resultar en una mala experiencia de usuario, una interrupción del servicio o no cumplirá con tu SLO/SLA. -For example, in the [authorization for HTTP traffic task](/es/docs/tasks/security/authorization/authz-http/), -the authorization policy named `allow-nothing` makes sure all traffic is denied by default. -From there, other authorization policies allow traffic based on specific conditions. +Por ejemplo, en la [tarea de autorización para tráfico HTTP](/es/docs/tasks/security/authorization/authz-http/), +la política de autorización llamada `allow-nothing` se asegura de que todo el tráfico sea denegado por defecto. +Desde ahí, otras políticas de autorización permiten tráfico basado en condiciones específicas. -#### Default-deny pattern with waypoints +#### Patrón de denegación por defecto con waypoints -Istio's new ambient data plane mode introduced a new split data plane architecture. -In this architecture, the waypoint proxy is configured using Kubernetes Gateway API which uses more explicit binding to gateways using `parentRef` and `targetRef`. -Because waypoints adhere more closely to the principles of Kubernetes Gateway API, the default-deny pattern is enabled in a slightly different way when policy is applied waypoints. -Beginning with Istio 1.25, you may bind `AuthorizationPolicy` resources to the `istio-waypoint` `GatewayClass`. -By binding `AuthorizationPolicy` to the `GatewayClass`, you can configure all gateways which implement that `GatewayClass` with a default policy. -It is important to note that `GatewayClass` is a cluster-scoped resource, and binding namespace-scoped policies to it requires special care. -Istio requires that policies which are bound to a `GatewayClass` reside in the root namespace, typically `istio-system`. +El nuevo modo de data plane ambient de Istio introdujo una nueva arquitectura de data plane dividida. +En esta arquitectura, el Proxy waypoint se configura usando Kubernetes Gateway API que usa vinculación más explícita a gateways usando `parentRef` y `targetRef`. +Porque los waypoints se adhieren más estrechamente a los principios de Kubernetes Gateway API, el patrón de denegación por defecto se habilita de manera ligeramente diferente cuando la política se aplica a waypoints. +Comenzando con Istio 1.25, puedes vincular recursos `AuthorizationPolicy` al `GatewayClass` `istio-waypoint`. +Al vincular `AuthorizationPolicy` al `GatewayClass`, puedes configurar todos los gateways que implementan ese `GatewayClass` con una política por defecto. +Es importante notar que `GatewayClass` es un recurso de alcance de cluster, y vincular políticas de alcance de namespace a él requiere cuidado especial. +Istio requiere que las políticas que están vinculadas a un `GatewayClass` residan en el namespace raíz, típicamente `istio-system`. {{< tip >}} -When using the default-deny pattern with waypoints, the policy bound to the `istio-waypoint` `GatewayClass` should be used in addition to the "classic" default-deny policy. The "classic" default-deny policy will be enforced by ztunnel against the workloads in your mesh and still provides meaningful value. +Al usar el patrón de denegación por defecto con waypoints, la política vinculada al `GatewayClass` `istio-waypoint` debería usarse además de la política "clásica" de denegación por defecto. La política "clásica" de denegación por defecto será aplicada por ztunnel contra los workloads en tu meshy aún proporciona valor significativo. {{< /tip >}} -#### Use `ALLOW-with-positive-matching` and `DENY-with-negative-match` patterns +#### Usar patrones `ALLOW-with-positive-matching` y `DENY-with-negative-match` -Use the `ALLOW-with-positive-matching` or `DENY-with-negative-matching` patterns whenever possible. These authorization policy -patterns are safer because the worst result in the case of policy mismatch is an unexpected 403 rejection instead of -an authorization policy bypass. +Usa los patrones `ALLOW-with-positive-matching` o `DENY-with-negative-matching` siempre que sea posible. Estos patrones de política de autorización +son más seguros porque el peor resultado en el caso de un error de coincidencia de política es un rechazo 403 inesperado en lugar de +un bypass de la política de autorización. -The `ALLOW-with-positive-matching` pattern is to use the `ALLOW` action only with **positive** matching fields (e.g. `paths`, `values`) -and do not use any of the **negative** matching fields (e.g. `notPaths`, `notValues`). +El patrón `ALLOW-with-positive-matching` es usar la acción `ALLOW` solo con campos de coincidencia **positivos** (ej. `paths`, `values`) +y no usar ninguno de los campos de coincidencia **negativos** (ej. `notPaths`, `notValues`). -The `DENY-with-negative-matching` pattern is to use the `DENY` action only with **negative** matching fields (e.g. `notPaths`, `notValues`) -and do not use any of the **positive** matching fields (e.g. `paths`, `values`). +El patrón `DENY-with-negative-matching` es usar la acción `DENY` solo con campos de coincidencia **negativos** (ej. `notPaths`, `notValues`) +y no usar ninguno de los campos de coincidencia **positivos** (ej. `paths`, `values`). -For example, the authorization policy below uses the `ALLOW-with-positive-matching` pattern to allow requests to path `/public`: +Por ejemplo, la política de autorización a continuación usa el patrón `ALLOW-with-positive-matching` para permitir solicitudes a la ruta `/public`: {{< text yaml >}} apiVersion: security.istio.io/v1 @@ -85,11 +85,11 @@ spec: paths: ["/public"] {{< /text >}} -The above policy explicitly lists the allowed path (`/public`). This means the request path must be exactly the same as -`/public` to allow the request. Any other requests will be rejected by default eliminating the risk -of unknown normalization behavior causing policy bypass. +La política anterior lista explícitamente la ruta permitida (`/public`). Esto significa que la ruta de la solicitud debe ser exactamente la misma que +`/public` para permitir la solicitud. Cualquier otra solicitud será rechazada por defecto eliminando el riesgo +de que el comportamiento de normalización desconocido cause un bypass de política. -The following is an example using the `DENY-with-negative-matching` pattern to achieve the same result: +El siguiente es un ejemplo usando el patrón `DENY-with-negative-matching` para lograr el mismo resultado: {{< text yaml >}} apiVersion: security.istio.io/v1 @@ -104,140 +104,141 @@ spec: notPaths: ["/public"] {{< /text >}} -### Understand path normalization in authorization policy +### Entender la normalización de rutas en la política de autorización -The enforcement point for authorization policies is the Envoy proxy instead of the usual resource access point in the backend application. A policy mismatch happens when the Envoy proxy and the backend application interpret the request -differently. +El punto de aplicación para las políticas de autorización es el Proxy Envoy en lugar del punto de acceso a recursos usual en la aplicación backend. Un error de coincidencia de política ocurre cuando el Proxy Envoy y la aplicación backend interpretan la solicitud +de manera diferente. -A mismatch can lead to either unexpected rejection or a policy bypass. The latter is usually a security incident that needs to be -fixed immediately, and it's also why we need path normalization in the authorization policy. +Un error de coincidencia puede llevar a rechazo inesperado o a un bypass de política. Lo último es usualmente un incidente de seguridad que necesita ser +arreglado inmediatamente, y también es por qué necesitamos normalización de rutas en la política de autorización. -For example, consider an authorization policy to reject requests with path `/data/secret`. A request with path `/data//secret` will -not be rejected because it does not match the path defined in the authorization policy due to the extra forward slash `/` in the path. +Por ejemplo, considera una política de autorización para rechazar solicitudes con ruta `/data/secret`. Una solicitud con ruta `/data//secret` no +será rechazada porque no coincide con la ruta definida en la política de autorización debido a la barra diagonal `/` extra en la ruta. -The request goes through and later the backend application returns the same response that it returns for the path `/data/secret` -because the backend application normalizes the path `/data//secret` to `/data/secret` as it considers the double forward slashes -`//` equivalent to a single forward slash `/`. +La solicitud pasa y luego la aplicación backend retorna la misma respuesta que retorna para la ruta `/data/secret` +porque la aplicación backend normaliza la ruta `/data//secret` a `/data/secret` ya que considera las barras diagonales dobles +`//` equivalentes a una sola barra diagonal `/`. -In this example, the policy enforcement point (Envoy proxy) had a different understanding of the path than the resource access -point (backend application). The different understanding caused the mismatch and subsequently the bypass of the authorization policy. +En este ejemplo, el punto de aplicación de política (Proxy Envoy) tuvo un entendimiento diferente de la ruta que el punto de acceso a recursos +(aplicación backend). El entendimiento diferente causó el error de coincidencia y posteriormente el bypass de la política de autorización. -This becomes a complicated problem because of the following factors: +Esto se convierte en un problema complicado debido a los siguientes factores: -* Lack of a clear standard for the normalization. +* Falta de un estándar claro para la normalización. -* Backends and frameworks in different layers have their own special normalization. +* Los backends y frameworks en diferentes capas tienen su propia normalización especial. -* Applications can even have arbitrary normalizations for their own use cases. +* Las aplicaciones pueden incluso tener normalizaciones arbitrarias para sus propios casos de uso. -Istio authorization policy implements built-in support of various basic normalization options to help you to better address -the problem: +La política de autorización de Istio implementa soporte incorporado de varias opciones de normalización básicas para ayudarte a abordar mejor +el problema: -* Refer to [Guideline on configuring the path normalization option](/es/docs/ops/best-practices/security/#guideline-on-configuring-the-path-normalization-option) - to understand which normalization options you may want to use. +* Consulta [Guía sobre configurar la opción de normalización de rutas](/es/docs/ops/best-practices/security/#guideline-on-configuring-the-path-normalization-option) + para entender qué opciones de normalización podrías querer usar. -* Refer to [Customize your system on path normalization](/es/docs/ops/best-practices/security/#customize-your-system-on-path-normalization) to - understand the detail of each normalization option. +* Consulta [Personalizar tu sistema en normalización de rutas](/es/docs/ops/best-practices/security/#customize-your-system-on-path-normalization) para + entender el detalle de cada opción de normalización. -* Refer to [Mitigation for unsupported normalization](/es/docs/ops/best-practices/security/#mitigation-for-unsupported-normalization) for - alternative solutions in case you need any unsupported normalization options. +* Consulta [Mitigación para normalización no soportada](/es/docs/ops/best-practices/security/#mitigation-for-unsupported-normalization) para + soluciones alternativas en caso de que necesites cualquier opción de normalización no soportada. -### Guideline on configuring the path normalization option +### Guía sobre configurar la opción de normalización de rutas -#### Case 1: You do not need normalization at all +#### Caso 1: No necesitas normalización en absoluto -Before diving into the details of configuring normalization, you should first make sure that normalizations are needed. +Antes de sumergirse en los detalles de configurar normalización, primero deberías asegurarte de que las normalizaciones sean necesarias. -You do not need normalization if you don't use authorization policies or if your authorization policies don't -use any `path` fields. +No necesitas normalización si no usas políticas de autorización o si tus políticas de autorización no +usan ningún campo `path`. -You may not need normalization if all your authorization policies follow the [safer authorization pattern](/es/docs/ops/best-practices/security/#safer-authorization-policy-patterns) -which, in the worst case, results in unexpected rejection instead of policy bypass. +Podrías no necesitar normalización si todas tus políticas de autorización siguen el [patrón de autorización más seguro](/es/docs/ops/best-practices/security/#safer-authorization-policy-patterns) +que, en el peor caso, resulta en rechazo inesperado en lugar de bypass de política. -#### Case 2: You need normalization but not sure which normalization option to use +#### Caso 2: Necesitas normalización pero no estás seguro de qué opción de normalización usar -You need normalization but you have no idea of which option to use. The safest choice is the strictest normalization option -that provides the maximum level of normalization in the authorization policy. +Necesitas normalización pero no tienes idea de qué opción usar. La elección más segura es la opción de normalización más estricta +que proporciona el máximo nivel de normalización en la política de autorización. -This is often the case due to the fact that complicated multi-layered systems make it practically impossible to figure -out what normalization is actually happening to a request beyond the enforcement point. +Este es a menudo el caso debido al hecho de que los sistemas multi-capas complicados hacen prácticamente imposible averiguar +qué normalización está realmente ocurriendo a una solicitud más allá del punto de aplicación. -You could use a less strict normalization option if it already satisfies your requirements and you are sure of its implications. +Podrías usar una opción de normalización menos estricta si ya satisface tus requisitos y estás seguro de sus implicaciones. -For either option, make sure you write both positive and negative tests specifically for your requirements to verify the -normalization is working as expected. The tests are useful in catching potential bypass issues caused by a misunderstanding -or incomplete knowledge of the normalization happening to your request. +Para cualquier opción, asegúrate de escribir tanto pruebas positivas como negativas específicamente para tus requisitos para verificar que la +normalización esté funcionando como se espera. Las pruebas son útiles para detectar problemas de bypass potenciales causados por un malentendido +o conocimiento incompleto de la normalización que está ocurriendo a tu solicitud. -Refer to [Customize your system on path normalization](/es/docs/ops/best-practices/security/#customize-your-system-on-path-normalization) -for more details on configuring the normalization option. +Consulta [Personalizar tu sistema en normalización de rutas](/es/docs/ops/best-practices/security/#customize-your-system-on-path-normalization) +para más detalles sobre configurar la opción de normalización. -#### Case 3: You need an unsupported normalization option +#### Caso 3: Necesitas una opción de normalización no soportada -If you need a specific normalization option that is not supported by Istio yet, please follow -[Mitigation for unsupported normalization](/es/docs/ops/best-practices/security/#mitigation-for-unsupported-normalization) -for customized normalization support or create a feature request for the Istio community. +Si necesitas una opción de normalización específica que aún no es soportada por Istio, por favor sigue +[Mitigación para normalización no soportada](/es/docs/ops/best-practices/security/#mitigation-for-unsupported-normalization) +para soporte de normalización personalizada o crea una solicitud de característica para la comunidad de Istio. -### Customize your system on path normalization +### Personalizar tu sistema en normalización de rutas -Istio authorization policies can be based on the URL paths in the HTTP request. -[Path normalization (a.k.a., URI normalization)](https://en.wikipedia.org/wiki/URI_normalization) modifies and standardizes the incoming requests' paths, -so that the normalized paths can be processed in a standard way. -Syntactically different paths may be equivalent after path normalization. +Las políticas de autorización de Istio pueden basarse en las rutas URL en la solicitud HTTP. +[Normalización de rutas (también conocida como normalización de URI)](https://en.wikipedia.org/wiki/URI_normalization) modifica y estandariza las rutas de solicitudes entrantes, +para que las rutas normalizadas puedan ser procesadas de manera estándar. +Rutas sintácticamente diferentes pueden ser equivalentes después de la normalización de rutas. -Istio supports the following normalization schemes on the request paths, -before evaluating against the authorization policies and routing the requests: +Istio soporta los siguientes esquemas de normalización en las rutas de solicitud, +antes de evaluar contra las políticas de autorización y enrutar las solicitudes: -| Option | Description | Example | +| Opción | Descripción | Ejemplo | | --- | --- | --- | -| `NONE` | No normalization is done. Anything received by Envoy will be forwarded exactly as-is to any backend service. | `../%2Fa../b` is evaluated by the authorization policies and sent to your service. | -| `BASE` | This is currently the option used in the *default* installation of Istio. This applies the [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path) option on Envoy proxies, which follows [RFC 3986](https://tools.ietf.org/html/rfc3986) with extra normalization to convert backslashes to forward slashes. | `/a/../b` is normalized to `/b`. `\da` is normalized to `/da`. | -| `MERGE_SLASHES` | Slashes are merged after the _BASE_ normalization. | `/a//b` is normalized to `/a/b`. | -| `DECODE_AND_MERGE_SLASHES` | The most strict setting when you allow all traffic by default. This setting is recommended, with the caveat that you will need to thoroughly test your authorization policies routes. [Percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1) slash and backslash characters (`%2F`, `%2f`, `%5C` and `%5c`) are decoded to `/` or `\`, before the `MERGE_SLASHES` normalization. | `/a%2fb` is normalized to `/a/b`. | +| `NONE` | No se hace normalización. Cualquier cosa recibida por Envoy será reenviada exactamente como está a cualquier Service backend. | `../%2Fa../b` es evaluado por las políticas de autorización y enviado a tu servicio. | +| `BASE` | Esta es actualmente la opción usada en la instalación *por defecto* de Istio. Esto aplica la opción [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path) en los proxies Envoy, que sigue [RFC 3986](https://tools.ietf.org/html/rfc3986) con normalización extra para convertir barras invertidas a barras diagonales. | `/a/../b` se normaliza a `/b`. `\da` se normaliza a `/da`. | +| `MERGE_SLASHES` | Las barras diagonales se fusionan después de la normalización _BASE_. | `/a//b` se normaliza a `/a/b`. | +| `DECODE_AND_MERGE_SLASHES` | La configuración más estricta cuando permites todo el tráfico por defecto. Esta configuración se recomienda, con la advertencia de que necesitarás probar exhaustivamente tus políticas de autorización y rutas. Los caracteres de barra diagonal y barra invertida [codificados en porcentaje](https://tools.ietf.org/html/rfc3986#section-2.1) (`%2F`, `%2f`, `%5C` y `%5c`) se decodifican a `/` o `\`, antes de la normalización `MERGE_SLASHES`. | `/a%2fb` se normaliza a `/a/b`. | {{< tip >}} -The configuration is specified via the [`pathNormalization`](/es/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization) -field in the [mesh config](/es/docs/reference/config/istio.mesh.v1alpha1/). +La configuración se especifica a través del campo [`pathNormalization`](/es/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization) +en la [configuración de malla](/es/docs/reference/config/istio.mesh.v1alpha1/). {{< /tip >}} -To emphasize, the normalization algorithms are conducted in the following order: +Para enfatizar, los algoritmos de normalización se conducen en el siguiente orden: -1. Percent-decode `%2F`, `%2f`, `%5C` and `%5c`. -1. The [RFC 3986](https://tools.ietf.org/html/rfc3986) and other normalization implemented by the [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path) option in Envoy. -1. Merge slashes +1. Decodificar en porcentaje `%2F`, `%2f`, `%5C` y `%5c`. +1. La normalización [RFC 3986](https://tools.ietf.org/html/rfc3986) y otra implementada por la opción [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path) en Envoy. +1. Fusionar barras diagonales {{< warning >}} -While these normalization options represent recommendations from HTTP standards and common industry practices, -applications may interpret a URL in any way it chooses to. When using denial policies, ensure that you understand how your application behaves. +Aunque estas opciones de normalización representan recomendaciones de estándares HTTP y prácticas comunes de la industria, +las aplicaciones pueden interpretar una URL de cualquier manera que elijan. +Al usar políticas de denegación, asegúrate de entender cómo se comporta tu aplicación. {{< /warning >}} -For a complete list of supported normalizations, please refer to [authorization policy normalization](/es/docs/reference/config/security/normalization/). +Para una lista completa de normalizaciones soportadas, por favor consulta [normalización de política de autorización](/es/docs/reference/config/security/normalization/). -#### Examples of configuration +#### Ejemplos de configuración -Ensuring Envoy normalizes request paths to match your backend services' expectation is critical to the security of your system. -The following examples can be used as reference for you to configure your system. -The normalized URL paths, or the original URL paths if _NONE_ is selected, will be: +Asegurar que Envoy normalice las rutas de solicitud para coincidir con la expectativa de tus servicios backend es crítico para la seguridad de tu sistema. +Los siguientes ejemplos pueden usarse como referencia para configurar tu sistema. +Las rutas URL normalizadas, o las rutas URL originales si se selecciona _NONE_, serán: -1. Used to check against the authorization policies -1. Forwarded to the backend application +1. Usadas para verificar contra las políticas de autorización +1. Reenviadas a la aplicación backend -| Your application... | Choose... | +| Tu aplicación... | Elige... | | --- | --- | -| Relies on the proxy to do normalization | `BASE`, `MERGE_SLASHES` or `DECODE_AND_MERGE_SLASHES` | -| Normalizes request paths based on [RFC 3986](https://tools.ietf.org/html/rfc3986) and does not merge slashes | `BASE` | -| Normalizes request paths based on [RFC 3986](https://tools.ietf.org/html/rfc3986), merges slashes but does not decode [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1) slashes | `MERGE_SLASHES` | -| Normalizes request paths based on [RFC 3986](https://tools.ietf.org/html/rfc3986), decodes [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1) slashes and merges slashes | `DECODE_AND_MERGE_SLASHES` | -| Processes request paths in a way that is incompatible with [RFC 3986](https://tools.ietf.org/html/rfc3986) | `NONE` | +| Depende del proxy para hacer normalización | `BASE`, `MERGE_SLASHES` o `DECODE_AND_MERGE_SLASHES` | +| Normaliza rutas de solicitud basadas en [RFC 3986](https://tools.ietf.org/html/rfc3986) y no fusiona barras diagonales | `BASE` | +| Normaliza rutas de solicitud basadas en [RFC 3986](https://tools.ietf.org/html/rfc3986), fusiona barras diagonales pero no decodifica barras diagonales [codificadas en porcentaje](https://tools.ietf.org/html/rfc3986#section-2.1) | `MERGE_SLASHES` | +| Normaliza rutas de solicitud basadas en [RFC 3986](https://tools.ietf.org/html/rfc3986), decodifica barras diagonales [codificadas en porcentaje](https://tools.ietf.org/html/rfc3986#section-2.1) y fusiona barras diagonales | `DECODE_AND_MERGE_SLASHES` | +| Procesa rutas de solicitud de una manera que es incompatible con [RFC 3986](https://tools.ietf.org/html/rfc3986) | `NONE` | -#### How to configure +#### Cómo configurar -You can use `istioctl` to update the [mesh config](/es/docs/reference/config/istio.mesh.v1alpha1/): +Puedes usar `istioctl` para actualizar la [configuración de malla](/es/docs/reference/config/istio.mesh.v1alpha1/): {{< text bash >}} $ istioctl upgrade --set meshConfig.pathNormalization.normalization=DECODE_AND_MERGE_SLASHES {{< /text >}} -or by altering your operator overrides file +o alterando tu archivo de overrides del operator {{< text bash >}} $ cat < iop.yaml @@ -251,10 +252,10 @@ EOF $ istioctl install -f iop.yaml {{< /text >}} -Alternatively, if you want to directly edit the mesh config, -you can add the [`pathNormalization`](/es/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization) -to the [mesh config](/es/docs/reference/config/istio.mesh.v1alpha1/), which is the `istio-` configmap in the `istio-system` namespace. -For example, if you choose the `DECODE_AND_MERGE_SLASHES` option, you modify the mesh config as the following: +Alternativamente, si quieres editar directamente la configuración de malla, +puedes agregar el [`pathNormalization`](/es/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization) +a la [configuración de malla](/es/docs/reference/config/istio.mesh.v1alpha1/), que es el configmap `istio-` en el namespace `istio-system`. +Por ejemplo, si eliges la opción `DECODE_AND_MERGE_SLASHES`, modificas la configuración de meshcomo lo siguiente: {{< text yaml >}} apiVersion: v1 @@ -266,27 +267,27 @@ apiVersion: v1 ... {{< /text >}} -### Mitigation for unsupported normalization +### Mitigación para normalización no soportada -This section describes various mitigations for unsupported normalization. These could be useful when you need a specific -normalization that is not supported by Istio. +Esta sección describe varias mitigaciones para normalización no soportada. Estas podrían ser útiles cuando necesitas una normalización específica +que no es soportada por Istio. -Please make sure you understand the mitigation thoroughly and use it carefully as some mitigations rely on things that are -out the scope of Istio and also not supported by Istio. +Por favor asegúrate de entender la mitigación completamente y usarla cuidadosamente ya que algunas mitigaciones dependen de cosas que están +fuera del alcance de Istio y también no son soportadas por Istio. -#### Custom normalization logic +#### Lógica de normalización personalizada -You can apply custom normalization logic using the WASM or Lua filter. It is recommended to use the WASM filter because -it's officially supported and also used by Istio. You could use the Lua filter for a quick proof-of-concept DEMO but we do -not recommend using the Lua filter in production because it is not supported by Istio. +Puedes aplicar lógica de normalización personalizada usando el filtro WASM o Lua. Se recomienda usar el filtro WASM porque +está oficialmente soportado y también usado por Istio. Podrías usar el filtro Lua para una prueba de concepto DEMO rápida pero no +recomendamos usar el filtro Lua en producción porque no está soportado por Istio. -##### Example custom normalization (case normalization) +##### Ejemplo de normalización personalizada (normalización de caso) -In some environments, it may be useful to have paths in authorization policies compared in a case insensitive manner. -For example, treating `https://myurl/get` and `https://myurl/GeT` as equivalent. +En algunos entornos, puede ser útil tener rutas en políticas de autorización comparadas de manera insensible a mayúsculas y minúsculas. +Por ejemplo, tratar `https://myurl/get` y `https://myurl/GeT` como equivalentes. -In those cases, the `EnvoyFilter` shown below can be used to insert a Lua filter to normalize the path to lower case. -This filter will change both the path used for comparison and the path presented to the application. +En esos casos, el `EnvoyFilter` mostrado a continuación puede usarse para insertar un filtro Lua para normalizar la ruta a minúsculas. +Este filtro cambiará tanto la ruta usada para comparación como la ruta presentada a la aplicación. {{< text syntax=yaml snip_id=ingress_case_insensitive_envoy_filter >}} apiVersion: networking.istio.io/v1alpha3 @@ -316,15 +317,15 @@ spec: end {{< /text >}} -#### Writing Host Match Policies +#### Escribir Políticas de Coincidencia de Host -Istio generates hostnames for both the hostname itself and all matching ports. For instance, a virtual service or Gateway -for a host of `example.com` generates a config matching `example.com` and `example.com:*`. However, exact match authorization -policies only match the exact string given for the `hosts` or `notHosts` fields. +Istio genera hostnames tanto para el hostname mismo como para todos los puertos coincidentes. Por ejemplo, un virtual service o Gateway +para un host de `example.com` genera una configuración que coincide con `example.com` y `example.com:*`. Sin embargo, las políticas de autorización de coincidencia exacta +solo coinciden con la cadena exacta dada para los campos `hosts` o `notHosts`. -[Authorization policy rules](/es/docs/reference/config/security/authorization-policy/#Rule) matching hosts should be written using -prefix matches instead of exact matches. For example, for an `AuthorizationPolicy` matching the Envoy configuration generated -for a hostname of `example.com`, you would use `hosts: ["example.com", "example.com:*"]` as shown in the below `AuthorizationPolicy`. +[Las reglas de política de autorización](/es/docs/reference/config/security/authorization-policy/#Rule) que coinciden con hosts deben escribirse usando +coincidencias de prefijo en lugar de coincidencias exactas. Por ejemplo, para una `AuthorizationPolicy` que coincida con la configuración de Envoy generada +para un hostname de `example.com`, usarías `hosts: ["example.com", "example.com:*"]` como se muestra en la `AuthorizationPolicy` a continuación. {{< text yaml >}} apiVersion: security.istio.io/v1 @@ -343,118 +344,118 @@ spec: hosts: ["example.com", "example.com:*"] {{< /text >}} -Additionally, the `host` and `notHosts` fields should generally only be used on gateway for external traffic entering the mesh -and not on sidecars for traffic within the mesh. This is because the sidecar on server side (where the authorization policy is enforced) -does not use the `Host` header when redirecting the request to the application. This makes the `host` and `notHost` meaningless -on sidecar because a client could reach out to the application using explicit IP address and arbitrary `Host` header instead of -the service name. +Adicionalmente, los campos `host` y `notHosts` generalmente solo deben usarse en gateway para tráfico externo entrando a la mesh +y no en sidecars para tráfico dentro de la mesh. Esto es porque el sidecar en el lado del servidor (donde se aplica la política de autorización) +no usa el header `Host` al redirigir la solicitud a la aplicación. Esto hace que `host` y `notHost` no tengan sentido +en sidecar porque un cliente podría alcanzar la aplicación usando dirección IP explícita y header `Host` arbitrario en lugar de +el nombre del servicio. -If you really need to enforce access control based on the `Host` header on sidecars for any reason, follow with the [default-deny patterns](/es/docs/ops/best-practices/security/#use-default-deny-patterns) -which would reject the request if the client uses an arbitrary `Host` header. +Si realmente necesitas aplicar control de acceso basado en el header `Host` en sidecars por cualquier razón, sigue con los [patrones de denegación por defecto](/es/docs/ops/best-practices/security/#use-default-deny-patterns) +que rechazarían la solicitud si el cliente usa un header `Host` arbitrario. -#### Specialized Web Application Firewall (WAF) +#### Web Application Firewall (WAF) Especializado -Many specialized Web Application Firewall (WAF) products provide additional normalization options. They can be deployed in -front of the Istio ingress gateway to normalize requests entering the mesh. The authorization policy will then be enforced -on the normalized requests. Please refer to your specific WAF product for configuring the normalization options. +Muchos productos especializados de Web Application Firewall (WAF) proporcionan opciones de normalización adicionales. Pueden desplegarse en +frente del Istio ingress gateway para normalizar solicitudes entrando a la mesh. La política de autorización será entonces aplicada +en las solicitudes normalizadas. Por favor consulta tu producto WAF específico para configurar las opciones de normalización. -#### Feature request to Istio +#### Solicitud de característica a Istio -If you believe Istio should officially support a specific normalization, you can follow the [reporting a vulnerability](/es/docs/releases/security-vulnerabilities/#reporting-a-vulnerability) -page to send a feature request about the specific normalization to the Istio Product Security Work Group for initial evaluation. +Si crees que Istio debería soportar oficialmente una normalización específica, puedes seguir la página [reportar una vulnerabilidad](/es/docs/releases/security-vulnerabilities/#reporting-a-vulnerability) +para enviar una solicitud de característica sobre la normalización específica al Grupo de Trabajo de Seguridad de Producto de Istio para evaluación inicial. -Please do not open any issues in public without first contacting the Istio Product Security Work Group because the -issue might be considered a security vulnerability that needs to be fixed in private. +Por favor no abras ningún issue en público sin primero contactar al Grupo de Trabajo de Seguridad de Producto de Istio porque el +issue podría considerarse una vulnerabilidad de seguridad que necesita ser arreglada en privado. -If the Istio Product Security Work Group evaluates the feature request as not a security vulnerability, an issue will -be opened in public for further discussions of the feature request. +Si el Grupo de Trabajo de Seguridad de Producto de Istio evalúa la solicitud de característica como no una vulnerabilidad de seguridad, se abrirá un issue +en público para más discusiones de la solicitud de característica. -### Known limitations +### Limitaciones conocidas -This section lists known limitations of the authorization policy. +Esta sección lista limitaciones conocidas de la política de autorización. -#### Server-first TCP protocols are not supported +#### Los protocolos TCP server-first no son soportados -Server-first TCP protocols mean the server application will send the first bytes right after accepting the TCP connection -before receiving any data from the client. +Los protocolos TCP server-first significan que la aplicación del servidor enviará los primeros bytes justo después de aceptar la conexión TCP +antes de recibir cualquier dato del cliente. -Currently, the authorization policy only supports enforcing access control on inbound traffic and not the outbound traffic. +Actualmente, la política de autorización solo soporta aplicar control de acceso en tráfico entrante y no en el tráfico saliente. -It also does not support server-first TCP protocols because the first bytes are sent by the server application even before -it received any data from the client. In this case, the initial first bytes sent by the server are returned to the client -directly without going through the access control check of the authorization policy. +Tampoco soporta protocolos TCP server-first porque los primeros bytes son enviados por la aplicación del servidor incluso antes +de que reciba cualquier dato del cliente. En este caso, los primeros bytes iniciales enviados por el servidor son retornados al cliente +directamente sin pasar por la verificación de control de acceso de la política de autorización. -You should not use the authorization policy if the first bytes sent by the server-first TCP protocols include any sensitive -data that need to be protected by proper authorization. +No deberías usar la política de autorización si los primeros bytes enviados por los protocolos TCP server-first incluyen cualquier dato sensible +que necesite ser protegido por autorización apropiada. -You could still use the authorization policy in this case if the first bytes does not include any sensitive data, for example, -the first bytes are used for negotiating the connection with data that are publicly accessible to any clients. The authorization -policy will work as usual for the following requests sent by the client after the first bytes. +Podrías aún usar la política de autorización en este caso si los primeros bytes no incluyen cualquier dato sensible, por ejemplo, +los primeros bytes se usan para negociar la conexión con datos que son públicamente accesibles a cualquier cliente. La política de autorización +funcionará como usual para las siguientes solicitudes enviadas por el cliente después de los primeros bytes. -## Understand traffic capture limitations +## Entender las limitaciones de captura de tráfico -The Istio sidecar works by capturing both inbound traffic and outbound traffic and directing them through the sidecar proxy. +El sidecar de Istio funciona capturando tanto tráfico entrante como saliente y dirigiéndolos a través del sidecar proxy. -However, not *all* traffic is captured: +Sin embargo, no *todo* el tráfico es capturado: -* Redirection only handles TCP based traffic. Any UDP or ICMP packets will not be captured or modified. -* Inbound capture is disabled on many [ports used by the sidecar](/es/docs/ops/deployment/application-requirements/#ports-used-by-istio) as well as port 22. This list can be expanded by options like `traffic.sidecar.istio.io/excludeInboundPorts`. -* Outbound capture may similarly be reduced through settings like `traffic.sidecar.istio.io/excludeOutboundPorts` or other means. +* La redirección solo maneja tráfico basado en TCP. Cualquier paquete UDP o ICMP no será capturado o modificado. +* La captura entrante está deshabilitada en muchos [puertos usados por el sidecar](/es/docs/ops/deployment/application-requirements/#ports-used-by-istio) así como el puerto 22. Esta lista puede expandirse con opciones como `traffic.sidecar.istio.io/excludeInboundPorts`. +* La captura saliente puede ser reducida similarmente a través de configuraciones como `traffic.sidecar.istio.io/excludeOutboundPorts` u otros medios. -In general, there is minimal security boundary between an application and its sidecar proxy. Configuration of the sidecar is allowed on a per-pod basis, and both run in the same network/process namespace. -As such, the application may have the ability to remove redirection rules and remove, alter, terminate, or replace the sidecar proxy. -This allows a pod to intentionally bypass its sidecar for outbound traffic or intentionally allow inbound traffic to bypass its sidecar. +En general, hay un límite de seguridad mínimo entre una aplicación y su sidecar proxy. La configuración del sidecar está permitida en base por pod, y ambos se ejecutan en el mismo namespace de red/proceso. +Como tal, la aplicación puede tener la habilidad de remover reglas de redirección y remover, alterar, terminar, o reemplazar el sidecar proxy. +Esto permite a un pod bypasear intencionalmente su sidecar para tráfico saliente o intencionalmente permitir que tráfico entrante bypasee su sidecar. -As a result, it is not secure to rely on all traffic being captured unconditionally by Istio. -Instead, the security boundary is that a client may not bypass *another* pod's sidecar. +Como resultado, no es seguro depender de que todo el tráfico sea capturado incondicionalmente por Istio. +En su lugar, el límite de seguridad es que un cliente no puede bypasear el sidecar de *otro* pod. -For example, if I run the `reviews` application on port `9080`, I can assume that all traffic from the `productpage` application will be captured by the sidecar proxy, -where Istio authentication and authorization policies may apply. +Por ejemplo, si ejecuto la aplicación `reviews` en el puerto `9080`, puedo asumir que todo el tráfico de la aplicación `productpage` será capturado por el sidecar proxy, +donde las políticas de autenticación y autorización de Istio pueden aplicar. -### Defense in depth with `NetworkPolicy` +### Defensa en profundidad con `NetworkPolicy` -To further secure traffic, Istio policies can be layered with Kubernetes [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/). -This enables a strong [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) strategy that can be used to further strengthen the security of your mesh. +Para asegurar más el tráfico, las políticas de Istio pueden ser en capas con [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) de Kubernetes. +Esto habilita una estrategia fuerte de [defensa en profundidad](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) que puede usarse para fortalecer más la seguridad de tu malla. -For example, you may choose to only allow traffic to port `9080` of our `reviews` application. -In the event of a compromised pod or security vulnerability in the cluster, this may limit or stop an attackers progress. +Por ejemplo, puedes elegir permitir solo tráfico al puerto `9080` de nuestra aplicación `reviews`. +En el evento de un pod comprometido o vulnerabilidad de seguridad en el cluster, esto puede limitar o detener el progreso de un atacante. -Depending on the actual implementation, changes to network policy may not affect existing connections in the Istio proxies. -You may need to restart the Istio proxies after applying the policy so that existing connections will be closed and -new connections will be subject to the new policy. +Dependiendo de la implementación real, los cambios a la política de red pueden no afectar las conexiones existentes en los proxies de Istio. +Puedes necesitar reiniciar los proxies de Istio después de aplicar la política para que las conexiones existentes sean cerradas y +las nuevas conexiones estén sujetas a la nueva política. -### Securing egress traffic +### Asegurar tráfico de egreso -A common misconception is that options like [`outboundTrafficPolicy: REGISTRY_ONLY`](/es/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services) acts as a security policy preventing all access to undeclared services. -However, this is not a strong security boundary as mentioned above, and should be considered best-effort. +Un concepto erróneo común es que opciones como [`outboundTrafficPolicy: REGISTRY_ONLY`](/es/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services) actúa como una política de seguridad previniendo todo acceso a servicios no declarados. +Sin embargo, esto no es un límite de seguridad fuerte como se mencionó anteriormente, y debería considerarse como mejor esfuerzo. -While this is useful to prevent accidental dependencies, if you want to secure egress traffic, and enforce all outbound traffic goes through a proxy, you should instead rely on an [Egress Gateway](/es/docs/tasks/traffic-management/egress/egress-gateway/). -When combined with a [Network Policy](/es/docs/tasks/traffic-management/egress/egress-gateway/#apply-kubernetes-network-policies), you can enforce all traffic, or some subset, goes through the egress gateway. -This ensures that even if a client accidentally or maliciously bypasses their sidecar, the request will be blocked. +Aunque esto es útil para prevenir dependencias accidentales, si quieres asegurar tráfico de egreso, y hacer cumplir que todo tráfico saliente pase por un proxy, deberías en su lugar depender de un [Egress Gateway](/es/docs/tasks/traffic-management/egress/egress-gateway/). +Cuando se combina con una [Network Policy](/es/docs/tasks/traffic-management/egress/egress-gateway/#apply-kubernetes-network-policies), puedes hacer cumplir que todo el tráfico, o algún subconjunto, pase por el egress gateway. +Esto asegura que incluso si un cliente accidental o maliciosamente bypasea su sidecar, la solicitud será bloqueada. -## Configure TLS verification in Destination Rule when using TLS origination +## Configurar verificación TLS en Destination Rule cuando se usa originación TLS -Istio offers the ability to [originate TLS](/es/docs/tasks/traffic-management/egress/egress-tls-origination/) from a sidecar proxy or gateway. -This enables applications that send plaintext HTTP traffic to be transparently "upgraded" to HTTPS. +Istio ofrece la habilidad de [originar TLS](/es/docs/tasks/traffic-management/egress/egress-tls-origination/) desde un sidecar proxy o gateway. +Esto habilita aplicaciones que envían tráfico HTTP de texto plano para ser transparentemente "actualizadas" a HTTPS. -Care must be taken when configuring the `DestinationRule`'s `tls` setting to specify the `caCertificates`, `subjectAltNames`, and `sni` fields. -The `caCertificate` can be automatically set from the system's certificate store's CA certificate by enabling the environment variable `VERIFY_CERTIFICATE_AT_CLIENT=true` on Istiod. -If the Operating System CA certificate being automatically used is only desired for select host(s), the environment variable `VERIFY_CERTIFICATE_AT_CLIENT=false` on Istiod, `caCertificates` can be set to `system` in the desired `DestinationRule`(s). -Specifying the `caCertificates` in a `DestinationRule` will take priority and the OS CA Cert will not be used. -By default, egress traffic does not send SNI during the TLS handshake. -SNI must be set in the `DestinationRule` to ensure the host properly handle the request. +Se debe tener cuidado al configurar la configuración `tls` del `DestinationRule` para especificar los campos `caCertificates`, `subjectAltNames`, y `sni`. +El `caCertificate` puede establecerse automáticamente desde el certificado CA del almacén de certificados del sistema habilitando la variable de entorno `VERIFY_CERTIFICATE_AT_CLIENT=true` en Istiod. +Si el certificado CA del Sistema Operativo que se está usando automáticamente solo se desea para host(s) seleccionados, la variable de entorno `VERIFY_CERTIFICATE_AT_CLIENT=false` en Istiod, `caCertificates` puede establecerse a `system` en el(los) `DestinationRule`(s) deseado(s). +Especificar los `caCertificates` en un `DestinationRule` tomará prioridad y el Certificado CA del SO no será usado. +Por defecto, el tráfico de egreso no envía SNI durante el handshake TLS. +SNI debe establecerse en el `DestinationRule` para asegurar que el host maneje apropiadamente la solicitud. {{< warning >}} -In order to verify the server's certificate it is important that both `caCertificates` and `subjectAltNames` be set. +Para verificar el certificado del servidor es importante que tanto `caCertificates` como `subjectAltNames` estén establecidos. -Verification of the certificate presented by the server against a CA is not sufficient, as the Subject Alternative Names must also be validated. +La verificación del certificado presentado por el servidor contra un CA no es suficiente, ya que los Nombres Alternativos del Sujeto también deben ser validados. -If `VERIFY_CERTIFICATE_AT_CLIENT` is set, but `subjectAltNames` is not set then you are not verifying all credentials. +Si `VERIFY_CERTIFICATE_AT_CLIENT` está establecido, pero `subjectAltNames` no está establecido entonces no estás verificando todas las credenciales. -If no CA certificate is being used, `subjectAltNames` will not be used regardless of it being set or not. +Si no se está usando ningún certificado CA, `subjectAltNames` no será usado independientemente de si está establecido o no. {{< /warning >}} -For example: +Por ejemplo: {{< text yaml >}} apiVersion: networking.istio.io/v1 @@ -474,20 +475,20 @@ spec: ## Gateways -When running an Istio [gateway](/es/docs/tasks/traffic-management/ingress/), there are a few resources involved: +Al ejecutar un [gateway](/es/docs/tasks/traffic-management/ingress/) de Istio, hay algunos recursos involucrados: -* `Gateway`s, which controls the ports and TLS settings for the gateway. -* `VirtualService`s, which control the routing logic. These are associated with `Gateway`s by direct reference in the `gateways` field and a mutual agreement on the `hosts` field in the `Gateway` and `VirtualService`. +* `Gateway`s, que controlan los puertos y configuraciones TLS para el gateway. +* `VirtualService`s, que controlan la lógica de enrutamiento. Estos están asociados con `Gateway`s por referencia directa en el campo `gateways` y un acuerdo mutuo en el campo `hosts` en el `Gateway` y `VirtualService`. -### Restrict `Gateway` creation privileges +### Restringir privilegios de creación de `Gateway` -It is recommended to restrict creation of Gateway resources to trusted cluster administrators. This can be achieved by [Kubernetes RBAC policies](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) or tools like [Open Policy Agent](https://www.openpolicyagent.org/). +Se recomienda restringir la creación de recursos Gateway a administradores de cluster confiables. Esto puede lograrse por [políticas RBAC de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) o herramientas como [Open Policy Agent](https://www.openpolicyagent.org/). -### Avoid overly broad `hosts` configurations +### Evitar configuraciones de `hosts` demasiado amplias -When possible, avoid overly broad `hosts` settings in `Gateway`. +Cuando sea posible, evita configuraciones de `hosts` demasiado amplias en `Gateway`. -For example, this configuration will allow any `VirtualService` to bind to the `Gateway`, potentially exposing unexpected domains: +Por ejemplo, esta configuración permitirá a cualquier `VirtualService` vincularse al `Gateway`, potencialmente exponiendo dominios inesperados: {{< text yaml >}} servers: @@ -499,7 +500,7 @@ servers: - "*" {{< /text >}} -This should be locked down to allow only specific domains or specific namespaces: +Esto debería ser bloqueado para permitir solo dominios específicos o namespaces específicos: {{< text yaml >}} servers: @@ -513,17 +514,17 @@ servers: - "route-namespace/*" # Allow only VirtualServices in the route-namespace namespace for any host {{< /text >}} -### Isolate sensitive services +### Aislar servicios sensibles -It may be desired to enforce stricter physical isolation for sensitive services. For example, you may want to run a -[dedicated gateway instance](/es/docs/setup/install/istioctl/#configure-gateways) for a sensitive `payments.example.com`, while utilizing a single -shared gateway instance for less sensitive domains like `blog.example.com` and `store.example.com`. -This can offer a stronger defense-in-depth and help meet certain regulatory compliance guidelines. +Puede ser deseado hacer cumplir aislamiento físico más estricto para servicios sensibles. Por ejemplo, puedes querer ejecutar una +[instancia de gateway dedicada](/es/docs/setup/install/istioctl/#configure-gateways) para un `payments.example.com` sensible, mientras utilizas una sola +instancia de gateway compartida para dominios menos sensibles como `blog.example.com` y `store.example.com`. +Esto puede ofrecer una defensa en profundidad más fuerte y ayudar a cumplir ciertas pautas de cumplimiento regulatorio. -### Explicitly disable all the sensitive http host under relaxed SNI host matching +### Deshabilitar explícitamente todos los hosts http sensibles bajo coincidencia de host SNI relajada -It is reasonable to use multiple `Gateway`s to define mutual TLS and simple TLS on different hosts. -For example, use mutual TLS for SNI host `admin.example.com` and simple TLS for SNI host `*.example.com`. +Es razonable usar múltiples `Gateway`s para definir mutual TLS y simple TLS en diferentes hosts. +Por ejemplo, usar mutual TLS para host SNI `admin.example.com` y simple TLS para host SNI `*.example.com`. {{< text yaml >}} kind: Gateway @@ -559,7 +560,7 @@ spec: mode: MUTUAL {{< /text >}} -If the above is necessary, it's highly recommended to explicitly disable the http host `admin.example.com` in the `VirtualService` that attaches to `*.example.com`. The reason is that currently the underlying [envoy proxy does not require](https://github.com/envoyproxy/envoy/issues/6767) the http 1 header `Host` or the http 2 pseudo header `:authority` following the SNI constraints, an attacker can reuse the guest-SNI TLS connection to access admin `VirtualService`. The http response code 421 is designed for this `Host` SNI mismatch and can be used to fulfill the disable. +Si lo anterior es necesario, es altamente recomendado deshabilitar explícitamente el host http `admin.example.com` en el `VirtualService` que se adjunta a `*.example.com`. La razón es que actualmente el [proxy envoy subyacente no requiere](https://github.com/envoyproxy/envoy/issues/6767) que el header http 1 `Host` o el pseudo header http 2 `:authority` sigan las restricciones SNI, un atacante puede reusar la conexión TLS guest-SNI para acceder al `VirtualService` admin. El código de respuesta http 421 está diseñado para este desajuste `Host` SNI y puede usarse para cumplir la deshabilitación. {{< text yaml >}} apiVersion: networking.istio.io/v1 @@ -587,86 +588,86 @@ spec: host: dest.default.cluster.local {{< /text >}} -## Protocol detection +## Detección de protocolo -Istio will [automatically determine the protocol](/es/docs/ops/configuration/traffic-management/protocol-selection/#automatic-protocol-selection) of traffic it sees. -To avoid accidental or intentional miss detection, which may result in unexpected traffic behavior, it is recommended to [explicitly declare the protocol](/es/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection) where possible. +Istio [determinará automáticamente el protocolo](/es/docs/ops/configuration/traffic-management/protocol-selection/#automatic-protocol-selection) del tráfico que ve. +Para evitar detección errónea accidental o intencional, que puede resultar en comportamiento de tráfico inesperado, se recomienda [declarar explícitamente el protocolo](/es/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection) donde sea posible. ## CNI -In order to transparently capture all traffic, Istio relies on `iptables` rules configured by the `istio-init` `initContainer`. -This adds a [requirement](/es/docs/ops/deployment/application-requirements/) for the `NET_ADMIN` and `NET_RAW` [capabilities](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) to be available to the pod. +Para capturar transparentemente todo el tráfico, Istio depende de reglas `iptables` configuradas por el `initContainer` `istio-init`. +Esto agrega un [requisito](/es/docs/ops/deployment/application-requirements/) para que las [capacidades](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) `NET_ADMIN` y `NET_RAW` estén disponibles para el pod. -To reduce privileges granted to pods, Istio offers a [CNI plugin](/es/docs/setup/additional-setup/cni/) which removes this requirement. +Para reducir los privilegios otorgados a los pods, Istio ofrece un [plugin CNI](/es/docs/setup/additional-setup/cni/) que remueve este requisito. -## Use hardened docker images +## Usar imágenes docker endurecidas -Istio's default docker images, including those run by the control plane, gateway, and sidecar proxies, are based on `ubuntu`. -This provides various tools such as `bash` and `curl`, which trades off convenience for an increase attack surface. +Las imágenes docker por defecto de Istio, incluyendo aquellas ejecutadas por el control plane, gateway, y sidecar proxies, están basadas en `ubuntu`. +Esto proporciona varias herramientas como `bash` y `curl`, que intercambia conveniencia por un aumento en la superficie de ataque. -Istio also offers a smaller image based on [distroless images](/es/docs/ops/configuration/security/harden-docker-images/) that reduces the dependencies in the image. +Istio también ofrece una imagen más pequeña basada en [imágenes distroless](/es/docs/ops/configuration/security/harden-docker-images/) que reduce las dependencias en la imagen. {{< warning >}} -Distroless images are currently an alpha feature. +Las imágenes distroless son actualmente una característica alpha. {{< /warning >}} -## Release and security policy +## Política de release y seguridad -In order to ensure your cluster has the latest security patches for known vulnerabilities, it is important to stay on the latest patch release of Istio and ensure that you are on a [supported release](/es/docs/releases/supported-releases) that is still receiving security patches. +Para asegurar que tu cluster tenga los últimos parches de seguridad para vulnerabilidades conocidas, es importante mantenerse en el último patch release de Istio y asegurar que estés en un [release soportado](/es/docs/releases/supported-releases) que aún esté recibiendo parches de seguridad. -## Detect invalid configurations +## Detectar configuraciones inválidas -While Istio provides validation of resources when they are created, these checks cannot catch all issues preventing configuration being distributed in the mesh. -This could result in applying a policy that is unexpectedly ignored, leading to unexpected results. +Aunque Istio proporciona validación de recursos cuando se crean, estas verificaciones no pueden detectar todos los problemas que previenen que la configuración sea distribuida en la mesh. +Esto podría resultar en aplicar una política que es inesperadamente ignorada, llevando a resultados inesperados. -* Run `istioctl analyze` before or after applying configuration to ensure it is valid. -* Monitor the control plane for rejected configurations. These are exposed by the `pilot_total_xds_rejects` metric, in addition to logs. -* Test your configuration to ensure it gives the expected results. - For a security policy, it is useful to run positive and negative tests to ensure you do not accidentally restrict too much or too few traffic. +* Ejecuta `istioctl analyze` antes o después de aplicar configuración para asegurar que sea válida. +* Monitorea el control plane para configuraciones rechazadas. Estas están expuestas por la métrica `pilot_total_xds_rejects`, además de logs. +* Prueba tu configuración para asegurar que da los resultados esperados. + Para una política de seguridad, es útil ejecutar pruebas positivas y negativas para asegurar que no restringes accidentalmente demasiado o muy poco tráfico. -## Avoid alpha and experimental features +## Evitar características alpha y experimentales -All Istio features and APIs are assigned a [feature status](/es/docs/releases/feature-stages/), defining its stability, deprecation policy, and security policy. +Todas las características y APIs de Istio tienen asignado un [estado de característica](/es/docs/releases/feature-stages/), definiendo su estabilidad, política de deprecación, y política de seguridad. -Because alpha and experimental features do not have as strong security guarantees, it is recommended to avoid them whenever possible. -Security issues found in these features may not be fixed immediately or otherwise not follow our standard [security vulnerability](/es/docs/releases/security-vulnerabilities/) process. +Porque las características alpha y experimentales no tienen garantías de seguridad tan fuertes, se recomienda evitarlas siempre que sea posible. +Los problemas de seguridad encontrados en estas características pueden no ser arreglados inmediatamente o de otra manera no seguir nuestro proceso estándar de [vulnerabilidad de seguridad](/es/docs/releases/security-vulnerabilities/). -To determine the feature status of features in use in your cluster, consult the [Istio features](/es/docs/releases/feature-stages/#istio-features) list. +Para determinar el estado de característica de las características en uso en tu cluster, consulta la lista de [características de Istio](/es/docs/releases/feature-stages/#istio-features). -## Lock down ports +## Bloquear puertos -Istio configures a [variety of ports](/es/docs/ops/deployment/application-requirements/#ports-used-by-istio) that may be locked down to improve security. +Istio configura una [variedad de puertos](/es/docs/ops/deployment/application-requirements/#ports-used-by-istio) que pueden ser bloqueados para mejorar la seguridad. ### Control Plane -Istiod exposes a few unauthenticated plaintext ports for convenience by default. If desired, these can be closed: +Istiod expone algunos puertos de texto plano no autenticados por conveniencia por defecto. Si se desea, estos pueden ser cerrados: -* Port `8080` exposes the debug interface, which offers read access to a variety of details about the clusters state. - This can be disabled by set the environment variable `ENABLE_DEBUG_ON_HTTP=false` on Istiod. Warning: many `istioctl` commands - depend on this interface and will not function if it is disabled. -* Port `15010` exposes the XDS service over plaintext. This can be disabled by adding the `--grpcAddr=""` flag to the Istiod Deployment. - Note: highly sensitive services, such as the certificate signing and distribution services, are never served over plaintext. +* El puerto `8080` expone la interfaz de debug, que ofrece acceso de lectura a una variedad de detalles sobre el estado del cluster. + Esto puede deshabilitarse estableciendo la variable de entorno `ENABLE_DEBUG_ON_HTTP=false` en Istiod. Advertencia: muchos comandos `istioctl` + dependen de esta interfaz y no funcionarán si está deshabilitada. +* El puerto `15010` expone el Service XDS sobre texto plano. Esto puede deshabilitarse agregando la bandera `--grpcAddr=""` al Deployment de Istiod. + Nota: servicios altamente sensibles, como los servicios de firma y distribución de certificados, nunca se sirven sobre texto plano. ### data plane -The proxy exposes a variety of ports. Exposed externally are port `15090` (telemetry) and port `15021` (health check). -Ports `15020` and `15000` provide debugging endpoints. These are exposed over `localhost` only. -As a result, the applications running in the same pod as the proxy have access; there is no trust boundary between the sidecar and application. +El proxy expone una variedad de puertos. Expuestos externamente están el puerto `15090` (telemetría) y el puerto `15021` (verificación de salud). +Los puertos `15020` y `15000` proporcionan endpoints de debugging. Estos están expuestos solo sobre `localhost`. +Como resultado, las aplicaciones ejecutándose en el mismo pod que el proxy tienen acceso; no hay límite de confianza entre el sidecar y la aplicación. -## Configure third party service account tokens +## Configurar tokens de cuenta de servicio de terceros -To authenticate with the Istio control plane, the Istio proxy will use a Service Account token. Kubernetes supports two forms of these tokens: +Para autenticarse con el control plane de Istio, el proxy de Istio usará un token de Service Account. Kubernetes soporta dos formas de estos tokens: -* Third party tokens, which have a scoped audience and expiration. -* First party tokens, which have no expiration and are mounted into all pods. +* Tokens de terceros, que tienen una audiencia con alcance y expiración. +* Tokens de primera parte, que no tienen expiración y están montados en todos los pods. -Because the properties of the first party token are less secure, Istio will default to using third party tokens. However, this feature is not enabled on all Kubernetes platforms. +Porque las propiedades del token de primera parte son menos seguras, Istio usará por defecto tokens de terceros. Sin embargo, esta característica no está habilitada en todas las plataformas de Kubernetes. -If you are using `istioctl` to install, support will be automatically detected. This can be done manually as well, and configured by passing `--set values.global.jwtPolicy=third-party-jwt` or `--set values.global.jwtPolicy=first-party-jwt`. +Si estás usando `istioctl` para instalar, el soporte será detectado automáticamente. Esto puede hacerse manualmente también, y configurarse pasando `--set values.global.jwtPolicy=third-party-jwt` o `--set values.global.jwtPolicy=first-party-jwt`. -To determine if your cluster supports third party tokens, look for the `TokenRequest` API. If this returns no response, then the feature is not supported: +Para determinar si tu cluster soporta tokens de terceros, busca la API `TokenRequest`. Si esto no retorna respuesta, entonces la característica no está soportada: {{< text bash >}} $ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceaccounts/token"))' @@ -683,15 +684,15 @@ $ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceac } {{< /text >}} -While most cloud providers support this feature now, many local development tools and custom installations may not prior to Kubernetes 1.20. To enable this feature, please refer to the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection). +Aunque la mayoría de los proveedores de nube soportan esta característica ahora, muchas herramientas de desarrollo local e instalaciones personalizadas pueden no hacerlo antes de Kubernetes 1.20. Para habilitar esta característica, por favor consulta la [documentación de Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection). -## Configure a limit on downstream connections +## Configurar un límite en conexiones downstream -By default, Istio (and Envoy) have no limit on the number of downstream connections. This can be exploited by a malicious actor (see [security bulletin 2020-007](/news/security/istio-security-2020-007/)). To work around you this, you must configure an appropriate connection limit for your environment. +Por defecto, Istio (y Envoy) no tienen límite en el número de conexiones downstream. Esto puede ser explotado por un actor malicioso (ver [boletín de seguridad 2020-007](/news/security/istio-security-2020-007/)). Para solucionar esto, debes configurar un límite de conexión apropiado para tu entorno. -### Configure `global_downstream_max_connections` value +### Configurar valor `global_downstream_max_connections` -The following configuration can be supplied during installation: +La siguiente configuración puede suministrarse durante la instalación: {{< text yaml >}} meshConfig: diff --git a/content/es/docs/ops/configuration/mesh/app-health-check/index.md b/content/es/docs/ops/configuration/mesh/app-health-check/index.md index 8de1c3e35391..326598649846 100644 --- a/content/es/docs/ops/configuration/mesh/app-health-check/index.md +++ b/content/es/docs/ops/configuration/mesh/app-health-check/index.md @@ -1,6 +1,6 @@ --- -title: Health Checking of Istio Services -description: Shows how to do health checking for Istio services. +title: Verificación de Salud de Services de Istio +description: Muestra cómo hacer verificación de salud para Services de Istio. weight: 50 aliases: - /docs/tasks/traffic-management/app-health-check/ @@ -14,37 +14,37 @@ owner: istio/wg-user-experience-maintainers test: yes --- -[Kubernetes liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) -describes several ways to configure liveness and readiness probes: +[Las sondas de liveness y readiness de Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) +describe varias maneras de configurar sondas de liveness y readiness: -1. [Command](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command) -1. [HTTP request](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request) -1. [TCP probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-tcp-liveness-probe) -1. [gRPC probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe) +1. [Comando](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command) +1. [Solicitud HTTP](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request) +1. [Sonda TCP](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-tcp-liveness-probe) +1. [Sonda gRPC](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe) -The command approach works with no changes required, but HTTP requests, TCP probes, and gRPC probes require Istio to make changes to the pod configuration. +El enfoque de comando funciona sin cambios requeridos, pero las solicitudes HTTP, sondas TCP, y sondas gRPC requieren que Istio haga cambios a la configuración del pod. -The health check requests to the `liveness-http` service are sent by Kubelet. -This becomes a problem when mutual TLS is enabled, because the Kubelet does not have an Istio issued certificate. -Therefore the health check requests will fail. +Las solicitudes de verificación de salud al Service `liveness-http` son enviadas por Kubelet. +Esto se convierte en un problema cuando mutual TLS está habilitado, porque el Kubelet no tiene un certificado emitido por Istio. +Por lo tanto, las solicitudes de verificación de salud fallarán. -TCP probe checks need special handling, because Istio redirects all incoming traffic into the sidecar, and so all TCP ports appear open. The Kubelet simply checks if some process is listening on the specified port, and so the probe will always succeed as long as the sidecar is running. +Las verificaciones de sonda TCP necesitan manejo especial, porque Istio redirige todo el tráfico entrante hacia el sidecar, y así todos los puertos TCP aparecen abiertos. El Kubelet simplemente verifica si algún proceso está escuchando en el puerto especificado, y así la sonda siempre tendrá éxito mientras el sidecar esté ejecutándose. -Istio solves both these problems by rewriting the application `PodSpec` readiness/liveness probe, -so that the probe request is sent to the [sidecar agent](/es/docs/reference/commands/pilot-agent/). +Istio resuelve ambos problemas reescribiendo la sonda readiness/liveness de la aplicación `PodSpec`, +para que la solicitud de sonda sea enviada al [sidecar agent](/es/docs/reference/commands/pilot-agent/). -## Liveness probe rewrite example +## Ejemplo de reescritura de sonda liveness -To demonstrate how the readiness/liveness probe is rewritten at the application `PodSpec` level, let us use the [liveness-http-same-port sample]({{< github_file >}}/samples/health-check/liveness-http-same-port.yaml). +Para demostrar cómo la sonda readiness/liveness es reescrita a nivel de `PodSpec` de la aplicación, usemos el [ejemplo liveness-http-same-port]({{< github_file >}}/samples/health-check/liveness-http-same-port.yaml). -First create and label a namespace for the example: +Primero crea y etiqueta un namespace para el ejemplo: {{< text bash >}} $ kubectl create namespace istio-io-health-rewrite $ kubectl label namespace istio-io-health-rewrite istio-injection=enabled {{< /text >}} -And deploy the sample application: +Y despliega la aplicación de ejemplo: {{< text bash yaml >}} $ kubectl apply -f - <}} -Once deployed, you can inspect the pod's application container to see the changed path: +Una vez desplegado, puedes inspeccionar el contenedor de aplicación del pod para ver la ruta cambiada: {{< text bash json >}} $ kubectl get pod "$LIVENESS_POD" -n istio-io-health-rewrite -o json | jq '.spec.containers[0].livenessProbe.httpGet' @@ -89,7 +89,7 @@ $ kubectl get pod "$LIVENESS_POD" -n istio-io-health-rewrite -o json | jq '.spec } {{< /text >}} -The original `livenessProbe` path is now mapped against the new path in the sidecar container environment variable `ISTIO_KUBE_APP_PROBERS`: +La ruta `livenessProbe` original ahora está mapeada contra la nueva ruta en la variable de entorno del contenedor sidecar `ISTIO_KUBE_APP_PROBERS`: {{< text bash json >}} $ kubectl get pod "$LIVENESS_POD" -n istio-io-health-rewrite -o=jsonpath="{.spec.containers[1].env[?(@.name=='ISTIO_KUBE_APP_PROBERS')]}" @@ -99,22 +99,22 @@ $ kubectl get pod "$LIVENESS_POD" -n istio-io-health-rewrite -o=jsonpath="{.spec } {{< /text >}} -For HTTP and gRPC requests, the sidecar agent redirects the request to the application and strips the response body, only returning the response code. For TCP probes, the sidecar agent will then do the port check while avoiding the traffic redirection. +Para solicitudes HTTP y gRPC, el sidecar agent redirige la solicitud a la aplicación y quita el cuerpo de respuesta, retornando solo el código de respuesta. Para sondas TCP, el sidecar agent hará entonces la verificación del puerto mientras evita la redirección de tráfico. -The rewriting of problematic probes is enabled by default in all built-in Istio -[configuration profiles](/es/docs/setup/additional-setup/config-profiles/) but can be disabled as described below. +La reescritura de sondas problemáticas está habilitada por defecto en todos los +[perfiles de configuración](/es/docs/setup/additional-setup/config-profiles/) integrados de Istio pero puede deshabilitarse como se describe a continuación. -## Liveness and readiness probes using the command approach +## Sondas de liveness y readiness usando el enfoque de comando -Istio provides a [liveness sample]({{< github_file >}}/samples/health-check/liveness-command.yaml) that -implements this approach. To demonstrate it working with mutual TLS enabled, -first create a namespace for the example: +Istio proporciona un [ejemplo de liveness]({{< github_file >}}/samples/health-check/liveness-command.yaml) que +implementa este enfoque. Para demostrar que funciona con mutual TLS habilitado, +primero crea un namespace para el ejemplo: {{< text bash >}} $ kubectl create ns istio-io-health {{< /text >}} -To configure strict mutual TLS, run: +Para configurar mutual TLS estricto, ejecuta: {{< text bash >}} $ kubectl apply -f - <}} -Next, change directory to the root of the Istio installation and run the following command to deploy the sample service: +Después, cambia el directorio a la raíz de la instalación de Istio y ejecuta el siguiente comando para desplegar el Service de ejemplo: {{< text bash >}} $ kubectl -n istio-io-health apply -f <(istioctl kube-inject -f @samples/health-check/liveness-command.yaml@) {{< /text >}} -To confirm that the liveness probes are working, check the status of the sample pod to verify that it is running. +Para confirmar que las sondas de liveness están funcionando, verifica el estado del pod de ejemplo para verificar que esté ejecutándose. {{< text bash >}} $ kubectl -n istio-io-health get pod @@ -143,21 +143,21 @@ NAME READY STATUS RESTARTS AGE liveness-6857c8775f-zdv9r 2/2 Running 0 4m {{< /text >}} -## Liveness and readiness probes using the HTTP, TCP, and gRPC approach {#liveness-and-readiness-probes-using-the-http-request-approach} +## Sondas de liveness y readiness usando el enfoque HTTP, TCP, y gRPC {#liveness-and-readiness-probes-using-the-http-request-approach} -As stated previously, Istio uses probe rewrite to implement HTTP, TCP, and gRPC probes by default. You can disable this -feature either for specific pods, or globally. +Como se mencionó anteriormente, Istio usa reescritura de sonda para implementar sondas HTTP, TCP, y gRPC por defecto. Puedes deshabilitar esta +característica ya sea para pods específicos, o globalmente. -### Disable the probe rewrite for a pod {#disable-the-http-probe-rewrite-for-a-pod} +### Deshabilitar la reescritura de sonda para un pod {#disable-the-http-probe-rewrite-for-a-pod} -You can [annotate the pod](/es/docs/reference/config/annotations/) with `sidecar.istio.io/rewriteAppHTTPProbers: "false"` -to disable the probe rewrite option. Make sure you add the annotation to the -[pod resource](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) because it will be ignored -anywhere else (for example, on an enclosing deployment resource). +Puedes [anotar el pod](/es/docs/reference/config/annotations/) con `sidecar.istio.io/rewriteAppHTTPProbers: "false"` +para deshabilitar la opción de reescritura de sonda. Asegúrate de agregar la anotación al +[recurso pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) porque será ignorada +en cualquier otro lugar (por ejemplo, en un recurso deployment envolvente). {{< tabset category-name="disable-probe-rewrite" >}} -{{< tab name="HTTP Probe" category-value="http-probe" >}} +{{< tab name="Sonda HTTP" category-value="http-probe" >}} {{< text yaml >}} kubectl apply -f - <}} -{{< tab name="gRPC Probe" category-value="grpc-probe" >}} +{{< tab name="Sonda gRPC" category-value="grpc-probe" >}} {{< text yaml >}} kubectl apply -f - <}} -This approach allows you to disable the health check probe rewrite gradually on individual deployments, -without reinstalling Istio. +Este enfoque te permite deshabilitar la reescritura de verificación de salud gradualmente en deployments individuales, +sin reinstalar Istio. -### Disable the probe rewrite globally +### Deshabilitar la reescritura de sonda globalmente -[Install Istio](/es/docs/setup/install/istioctl/) using `--set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=false` -to disable the probe rewrite globally. **Alternatively**, update the configuration map for the Istio sidecar injector: +[Instala Istio](/es/docs/setup/install/istioctl/) usando `--set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=false` +para deshabilitar la reescritura de sonda globalmente. **Alternativamente**, actualiza el mapa de configuración para el inyector de sidecar de Istio: {{< text bash >}} $ kubectl get cm istio-sidecar-injector -n istio-system -o yaml | sed -e 's/"rewriteAppHTTPProbe": true/"rewriteAppHTTPProbe": false/' | kubectl apply -f - {{< /text >}} -## Cleanup +## Limpieza -Remove the namespaces used for the examples: +Remueve los namespaces usados para los ejemplos: {{< text bash >}} $ kubectl delete ns istio-io-health istio-io-health-rewrite diff --git a/content/es/docs/ops/configuration/mesh/webhook/index.md b/content/es/docs/ops/configuration/mesh/webhook/index.md index 4881ec5df432..a40567d9df71 100644 --- a/content/es/docs/ops/configuration/mesh/webhook/index.md +++ b/content/es/docs/ops/configuration/mesh/webhook/index.md @@ -1,6 +1,6 @@ --- -title: Dynamic Admission Webhooks Overview -description: Provides a general overview of Istio's use of Kubernetes webhooks and the related issues that can arise. +title: Visión General de Dynamic Admission Webhooks +description: Proporciona una visión general de el uso de webhooks de Kubernetes por parte de Istio y los problemas relacionados que pueden surgir. weight: 10 aliases: - /help/ops/setup/webhook @@ -9,35 +9,34 @@ owner: istio/wg-user-experience-maintainers test: no --- -From [Kubernetes mutating and validating webhook mechanisms](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/): +De [los mecanismos de validating y mutating webhook de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/): {{< tip >}} -Admission webhooks are HTTP callbacks that receive admission requests -and do something with them. You can define two types of admission -webhooks, validating admission webhook and mutating admission -webhook. With validating admission webhooks, you may reject requests -to enforce custom admission policies. With mutating admission -webhooks, you may change requests to enforce custom defaults. +Los admission webhooks son callbacks HTTP que reciben solicitudes de admisión +y hacen algo con ellas. Puedes definir dos tipos de admission +webhooks, validating admission webhook y mutating admission +webhook. Con validating admission webhooks, puedes rechazar solicitudes +para hacer cumplir políticas de admisión personalizadas. Con mutating admission +webhooks, puedes cambiar solicitudes para hacer cumplir valores por defecto personalizados. {{< /tip >}} -Istio uses `ValidatingAdmissionWebhooks` for validating Istio -configuration and `MutatingAdmissionWebhooks` for automatically -injecting the sidecar proxy into user pods. +Istio usa `ValidatingAdmissionWebhooks` para validar configuración de Istio +y `MutatingAdmissionWebhooks` para inyectar automáticamente el sidecar proxy en pods de usuario. -The webhook setup guides assuming general familiarity with Kubernetes -Dynamic Admission Webhooks. Consult the Kubernetes API references for -detailed documentation of the [Mutating Webhook Configuration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) and [Validating Webhook Configuration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io). +Las guías de configuración de webhook asumen familiaridad general con Kubernetes +Dynamic Admission Webhooks. Consulta las referencias de API de Kubernetes para +documentación detallada de la [Configuración de Mutating Webhook](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) y [Configuración de Validating Webhook](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io). -## Verify dynamic admission webhook prerequisites +## Verificar prerrequisitos de dynamic admission webhook -See the [platform setup instructions](/es/docs/setup/platform-setup/) -for Kubernetes provider specific setup instructions. Webhooks will not -function properly if the cluster is misconfigured. You can follow -these steps once the cluster has been configured and dynamic -webhooks and dependent features are not functioning properly. +Ve las [instrucciones de configuración de plataforma](/es/docs/setup/platform-setup/) +para instrucciones de configuración específicas del proveedor de Kubernetes. Los webhooks no +funcionarán correctamente si el cluster está mal configurado. Puedes seguir +estos pasos una vez que el cluster haya sido configurado y los webhooks dinámicos +y características dependientes no estén funcionando correctamente. -1. Verify you’re using a [supported version](/es/docs/releases/supported-releases#support-status-of-istio-releases) ({{< supported_kubernetes_versions >}}) of - [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and of the Kubernetes server: +1. Verifica que estés usando una [versión soportada](/es/docs/releases/supported-releases#support-status-of-istio-releases) ({{< supported_kubernetes_versions >}}) de + [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) y del servidor de Kubernetes: {{< text bash >}} $ kubectl version --short @@ -45,19 +44,19 @@ webhooks and dependent features are not functioning properly. Server Version: v1.29.1 {{< /text >}} -1. `admissionregistration.k8s.io/v1` should be enabled +1. `admissionregistration.k8s.io/v1` debe estar habilitado {{< text bash >}} $ kubectl api-versions | grep admissionregistration.k8s.io/v1 admissionregistration.k8s.io/v1 {{< /text >}} -1. Verify `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook` plugins are - listed in the `kube-apiserver --enable-admission-plugins`. Access - to this flag is [provider specific](/es/docs/setup/platform-setup/). +1. Verifica que los plugins `MutatingAdmissionWebhook` y `ValidatingAdmissionWebhook` estén + listados en el `kube-apiserver --enable-admission-plugins`. El acceso + a esta bandera es [específico del proveedor](/es/docs/setup/platform-setup/). -1. Verify the Kubernetes api-server has network connectivity to the - webhook pod. e.g. incorrect `http_proxy` settings can interfere - api-server operation (see related issues - [here](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) - and [here](https://github.com/kubernetes/kubeadm/issues/666) for more information). +1. Verifica que el kube-apiserver de Kubernetes tenga conectividad de red al + pod webhook. Por ejemplo, configuraciones incorrectas de `http_proxy` pueden interferir + con la operación del api-server (ve problemas relacionados + [aquí](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) + y [aquí](https://github.com/kubernetes/kubeadm/issues/666) para más información). diff --git a/content/es/docs/ops/configuration/telemetry/monitoring-multicluster-prometheus/index.md b/content/es/docs/ops/configuration/telemetry/monitoring-multicluster-prometheus/index.md index 5660619391f7..eb63d0d6fae1 100644 --- a/content/es/docs/ops/configuration/telemetry/monitoring-multicluster-prometheus/index.md +++ b/content/es/docs/ops/configuration/telemetry/monitoring-multicluster-prometheus/index.md @@ -1,6 +1,6 @@ --- -title: Monitoring Multicluster Istio with Prometheus -description: Configure Prometheus to monitor multicluster Istio. +title: Monitoreo de Istio Multicluster con Prometheus +description: Configurar Prometheus para monitorear Istio multicluster. weight: 10 aliases: - /help/ops/telemetry/monitoring-multicluster-prometheus @@ -9,30 +9,30 @@ owner: istio/wg-policies-and-telemetry-maintainers test: no --- -## Overview +## Visión general -This guide is meant to provide operational guidance on how to configure monitoring of Istio meshes comprised of two -or more individual Kubernetes clusters. It is not meant to establish the *only* possible path forward, but rather -to demonstrate a workable approach to multicluster telemetry with Prometheus. +Esta guía está destinada a proporcionar orientación operacional sobre cómo configurar el monitoreo demesh de Istio compuestas por dos +o más clusters individuales de Kubernetes. No está destinada a establecer el *único* camino posible hacia adelante, sino más bien +para demostrar un enfoque viable al telemetría multicluster con Prometheus. -Our recommendation for multicluster monitoring of Istio with Prometheus is built upon the foundation of Prometheus -[hierarchical federation](https://prometheus.io/docs/prometheus/latest/federation/#hierarchical-federation). -Prometheus instances that are deployed locally to each cluster by Istio act as initial collectors that then federate up -to a production mesh-wide Prometheus instance. That mesh-wide Prometheus can either live outside of the mesh (external), or in one -of the clusters within the mesh. +Nuestra recomendación para el monitoreo multicluster de Istio con Prometheus está construida sobre la base de la +[federación jerárquica](https://prometheus.io/docs/prometheus/latest/federation/#hierarchical-federation) de Prometheus. +Las instancias de Prometheus que se despliegan localmente a cada cluster por Istio actúan como recolectores iniciales que luego se federan hasta +una instancia de Prometheus de producción de toda la mesh. Ese Prometheus de toda la mesh puede vivir fuera de la mesh (externo), o en uno +de los clusters dentro de la mesh. -## Multicluster Istio setup +## Configuración de Istio multicluster -Follow the [multicluster installation](/es/docs/setup/install/multicluster/) section to set up your Istio clusters in one of the -supported [multicluster deployment models](/es/docs/ops/deployment/deployment-models/#multiple-clusters). For the purpose of -this guide, any of those approaches will work, with the following caveat: +Sigue la sección de [instalación multicluster](/es/docs/setup/install/multicluster/) para configurar tus clusters de Istio en uno de los +[modelos de despliegue multicluster](/es/docs/ops/deployment/deployment-models/#multiple-clusters) soportados. Para el propósito de +esta guía, cualquiera de esos enfoques funcionará, con la siguiente advertencia: -**Ensure that a cluster-local Istio Prometheus instance is installed in each cluster.** +**Asegúrate de que una instancia local de Prometheus de Istio esté instalada en cada cluster.** -Individual Istio deployment of Prometheus in each cluster is required to form the basis of cross-cluster monitoring by -way of federation to a production-ready instance of Prometheus that runs externally or in one of the clusters. +El despliegue individual de Prometheus de Istio en cada cluster es requerido para formar la base del monitoreo entre clusters por +medio de federación a una instancia lista para producción de Prometheus que se ejecuta externamente o en uno de los clusters. -Validate that you have an instance of Prometheus running in each cluster: +Valida que tienes una instancia de Prometheus ejecutándose en cada cluster: {{< text bash >}} $ kubectl -n istio-system get services prometheus @@ -40,36 +40,35 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE prometheus ClusterIP 10.8.4.109 9090/TCP 20h {{< /text >}} -## Configure Prometheus federation +## Configurar federación de Prometheus -### External production Prometheus +### Prometheus de producción externo -There are several reasons why you may want to have a Prometheus instance running outside of your Istio deployment. -Perhaps you want long-term monitoring disjoint from the cluster being monitored. Perhaps you want to monitor multiple -separate meshes in a single place. Or maybe you have other motivations. Whatever your reason is, you’ll need some special -configurations to make it all work. +Hay varias razones por las que podrías querer tener una instancia de Prometheus ejecutándose fuera de tu despliegue de Istio. +Tal vez quieras monitoreo a largo plazo separado del cluster que está siendo monitoreado. Tal vez quieras monitorear múltiples +mallas separadas en un solo lugar. O tal vez tengas otras motivaciones. Cualquiera que sea tu razón, necesitarás algunas configuraciones especiales +para hacer que todo funcione. {{< image width="80%" link="./external-production-prometheus.svg" - alt="Architecture of external Production Prometheus for monitoring multicluster Istio." - caption="External Production Prometheus for monitoring multicluster Istio" + alt="Arquitectura de Prometheus de Producción externo para monitorear Istio multicluster." + caption="Prometheus de Producción externo para monitorear Istio multicluster" >}} {{< warning >}} -This guide demonstrates connectivity to cluster-local Prometheus instances, but does not address security considerations. -For production use, secure access to each Prometheus endpoint with HTTPS. In addition, take precautions, such as using an -internal load-balancer instead of a public endpoint and the appropriate configuration of firewall rules. +Esta guía demuestra conectividad a instancias locales de Prometheus del cluster, pero no aborda consideraciones de seguridad. +Para uso en producción, asegura el acceso a cada endpoint de Prometheus con HTTPS. Además, toma precauciones, como usar un +load-balancer interno en lugar de un endpoint público y la configuración apropiada de reglas de firewall. {{< /warning >}} -Istio provides a way to expose cluster services externally via [Gateways](/es/docs/reference/config/networking/gateway/). -You can configure an ingress gateway for the cluster-local Prometheus, providing external connectivity to the in-cluster -Prometheus endpoint. +Istio proporciona una manera de exponer servicios de cluster externamente a través de [Gateways](/es/docs/reference/config/networking/gateway/). +Puedes configurar un ingress gateway para el Prometheus local del cluster, proporcionando conectividad externa al endpoint de Prometheus en el cluster. -For each cluster, follow the appropriate instructions from the [Remotely Accessing Telemetry Addons](/es/docs/tasks/observability/gateways/#option-1-secure-access-https) task. -Also note that you **SHOULD** establish secure (HTTPS) access. +Para cada cluster, sigue las instrucciones apropiadas de la tarea [Acceso Remoto a Addons de Telemetría](/es/docs/tasks/observability/gateways/#option-1-secure-access-https). +También nota que **DEBERÍAS** establecer acceso seguro (HTTPS). -Next, configure your external Prometheus instance to access the cluster-local Prometheus instances using a configuration -like the following (replacing the ingress domain and cluster name): +Después, configura tu instancia externa de Prometheus para acceder a las instancias locales de Prometheus del cluster usando una configuración +como la siguiente (reemplazando el dominio de ingress y el nombre del cluster): {{< text yaml >}} scrape_configs: @@ -90,40 +89,40 @@ scrape_configs: cluster: '{{CLUSTER_NAME}}' {{< /text >}} -Notes: +Notas: -* `CLUSTER_NAME` should be set to the same value that you used to create the cluster (set via `values.global.multiCluster.clusterName`). +* `CLUSTER_NAME` debería establecerse al mismo valor que usaste para crear el cluster (establecido a través de `values.global.multiCluster.clusterName`). -* No authentication to the Prometheus endpoint(s) is provided. This means that anyone can query your -cluster-local Prometheus instances. This may not be desirable. +* No se proporciona autenticación a los endpoint(s) de Prometheus. Esto significa que cualquiera puede consultar tus +instancias locales de Prometheus del cluster. Esto puede no ser deseable. -* Without proper HTTPS configuration of the gateway, everything is being transported via plaintext. This may not be -desirable. +* Sin configuración HTTPS apropiada del gateway, todo se está transportando a través de texto plano. Esto puede no ser +deseable. -### Production Prometheus on an in-mesh cluster +### Prometheus de producción en un cluster en malla -If you prefer to run the production Prometheus in one of the clusters, you need to establish connectivity from it to -the other cluster-local Prometheus instances in the mesh. +Si prefieres ejecutar el Prometheus de producción en uno de los clusters, necesitas establecer conectividad desde él hacia +las otras instancias locales de Prometheus del cluster en la mesh. -This is really just a variation of the configuration for external federation. In this case the configuration on the -cluster running the production Prometheus is different from the configuration for remote cluster Prometheus scraping. +Esto es realmente solo una variación de la configuración para federación externa. En este caso, la configuración en el +cluster que ejecuta el Prometheus de producción es diferente de la configuración para el scraping remoto de Prometheus del cluster. {{< image width="80%" link="./in-mesh-production-prometheus.svg" - alt="Architecture of in-mesh Production Prometheus for monitoring multicluster Istio." - caption="In-mesh Production Prometheus for monitoring multicluster Istio" + alt="Arquitectura de Prometheus de Producción en meshpara monitorear Istio multicluster." + caption="Prometheus de Producción en meshpara monitorear Istio multicluster" >}} -Configure your production Prometheus to access both of the *local* and *remote* Prometheus instances. +Configura tu Prometheus de producción para acceder tanto a las instancias *locales* como *remotas* de Prometheus. -First execute the following command: +Primero ejecuta el siguiente comando: {{< text bash >}} $ kubectl -n istio-system edit cm prometheus -o yaml {{< /text >}} -Then add configurations for the *remote* clusters (replacing the ingress domain and cluster name for each cluster) and -add one configuration for the *local* cluster: +Luego agrega configuraciones para los clusters *remotos* (reemplazando el dominio de ingress y el nombre del cluster para cada cluster) y +agrega una configuración para el cluster *local*: {{< text yaml >}} scrape_configs: From 7b585ae43c170e12441441d81651a0117e029f52 Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Fri, 1 Aug 2025 18:40:42 +0200 Subject: [PATCH 2/5] Fix broken internal links in Spanish translation Signed-off-by: Francisco Herrera --- content/es/about/deployment/index.md | 2 +- .../distributed-tracing/how-envoy-based-tracing-works.md | 2 +- content/es/docs/concepts/observability/index.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/content/es/about/deployment/index.md b/content/es/about/deployment/index.md index fa7db88bcb04..8700fff30c81 100644 --- a/content/es/about/deployment/index.md +++ b/content/es/about/deployment/index.md @@ -75,7 +75,7 @@ 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 mesh 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 un mesh. 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 14be476df4b0..48d69bdabddf 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/docs/concepts/observability/index.md b/content/es/docs/concepts/observability/index.md index 8632779085de..32568dbff24a 100644 --- a/content/es/docs/concepts/observability/index.md +++ b/content/es/docs/concepts/observability/index.md @@ -125,15 +125,15 @@ Las trazas permiten a los operadores de la mesh comprender las dependencias del 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). Traza distribuida generada por Istio de ejemplo para una sola solicitud: -{{< image link="/es/docs/tasks/observability/distributed-tracing/zipkin/istio-tracing-details-zipkin.png" caption="Traza distribuida para una sola solicitud" >}} +{{< image link="/docs/tasks/observability/distributed-tracing/zipkin/istio-tracing-details-zipkin.png" caption="Traza distribuida para una sola solicitud" >}} ## Registros de acceso From b75ecffacf8273caebdfb0fc1fe483c47f106cd9 Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Fri, 1 Aug 2025 18:53:18 +0200 Subject: [PATCH 3/5] Fix broken image link Signed-off-by: Francisco Herrera --- content/es/docs/concepts/observability/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/observability/index.md b/content/es/docs/concepts/observability/index.md index 32568dbff24a..d1081f711a08 100644 --- a/content/es/docs/concepts/observability/index.md +++ b/content/es/docs/concepts/observability/index.md @@ -133,7 +133,7 @@ Se puede encontrar más información sobre el rastreo distribuido con Istio en n Traza distribuida generada por Istio de ejemplo para una sola solicitud: -{{< image link="/docs/tasks/observability/distributed-tracing/zipkin/istio-tracing-details-zipkin.png" caption="Traza distribuida para una sola solicitud" >}} +{{< image link="/es/docs/tasks/observability/distributed-tracing/zipkin/istio-tracing-details-zipkin.png" caption="Traza distribuida para una sola solicitud" >}} ## Registros de acceso From 10278503fb129a55766dbea5d0772ecc05c39c15 Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Mon, 4 Aug 2025 08:54:00 +0200 Subject: [PATCH 4/5] Apply suggestions from code review Co-authored-by: German Robayo --- content/es/about/deployment/index.md | 2 +- .../boilerplates/kubectl-multicluster-contexts.md | 2 +- content/es/boilerplates/revision-tags-preamble.md | 2 +- .../docs/ambient/architecture/data-plane/index.md | 4 ++-- content/es/docs/ambient/overview/index.md | 2 +- content/es/docs/ambient/usage/_index.md | 2 +- .../es/docs/ambient/usage/add-workloads/index.md | 2 +- content/es/docs/ambient/usage/waypoint/index.md | 2 +- content/es/docs/concepts/observability/index.md | 2 +- content/es/docs/concepts/security/index.md | 14 +++++++------- .../es/docs/concepts/traffic-management/index.md | 14 +++++++------- .../examples/microservices-istio/single/index.md | 2 +- 12 files changed, 25 insertions(+), 25 deletions(-) diff --git a/content/es/about/deployment/index.md b/content/es/about/deployment/index.md index 8700fff30c81..43d3cd5b5c53 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 clúster de Kubernetes y a la arquitectura de red. Puede optar por ejecutar múltiplesmesh 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. diff --git a/content/es/boilerplates/kubectl-multicluster-contexts.md b/content/es/boilerplates/kubectl-multicluster-contexts.md index 1d171b499775..2d0d60c079e1 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 meshusando 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-preamble.md b/content/es/boilerplates/revision-tags-preamble.md index c27710f949f5..19c47b3ea5f4 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 meshpuede 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 5c9197aac7c3..56604495cb78 100644 --- a/content/es/docs/ambient/architecture/data-plane/index.md +++ b/content/es/docs/ambient/architecture/data-plane/index.md @@ -7,7 +7,7 @@ test: no --- En el {{< gloss "ambient" >}}modo ambient{{< /gloss >}}, los workloads pueden clasificarse en 3 categorías: -1. **Fuera de la mesh**: un pod estándar sin ninguna característica de meshhabilitada. Istio y el {{< gloss >}}data plane{{< /gloss >}} ambient no están habilitados. +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. @@ -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 meshcon 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/overview/index.md b/content/es/docs/ambient/overview/index.md index 8489496b9d5b..f5e93f8abfb2 100644 --- a/content/es/docs/ambient/overview/index.md +++ b/content/es/docs/ambient/overview/index.md @@ -17,7 +17,7 @@ Dado que los pods de workload ya no requieren que los proxies se ejecuten en sid 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 meshque 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 meshque 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). diff --git a/content/es/docs/ambient/usage/_index.md b/content/es/docs/ambient/usage/_index.md index 968e78ce1042..74b868616b85 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 meshpara 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 187199c0b92a..b02206f6a7a0 100644 --- a/content/es/docs/ambient/usage/add-workloads/index.md +++ b/content/es/docs/ambient/usage/add-workloads/index.md @@ -24,7 +24,7 @@ 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 meshde 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 mesh diff --git a/content/es/docs/ambient/usage/waypoint/index.md b/content/es/docs/ambient/usage/waypoint/index.md index 557b8a67ebd6..cef553676f72 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 meshL7, 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 diff --git a/content/es/docs/concepts/observability/index.md b/content/es/docs/concepts/observability/index.md index d1081f711a08..d454b152fe6b 100644 --- a/content/es/docs/concepts/observability/index.md +++ b/content/es/docs/concepts/observability/index.md @@ -22,7 +22,7 @@ Istio genera los siguientes tipos de telemetría para proporcionar observabilida - [**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 mesh](/es/docs/ops/deployment/architecture/). - También se proporciona un conjunto predeterminado de paneles de monitoreo de meshcreados sobre estas métricas. + 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 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 diff --git a/content/es/docs/concepts/security/index.md b/content/es/docs/concepts/security/index.md index ff759aa2ff8c..49865e2b097d 100644 --- a/content/es/docs/concepts/security/index.md +++ b/content/es/docs/concepts/security/index.md @@ -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 meshde Istio utilizando políticas de autenticación de pares y de solicitudes. El operador de la mesh +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,7 +322,7 @@ EOF #### Almacenamiento de políticas -Istio almacena las políticas con alcance de meshen el namespace raíz. Estas políticas 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 @@ -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 meshy 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 mesho 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,8 +375,8 @@ 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 mesho 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 mesho 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 @@ -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 meshcon un modo no establecido usan el modo `PERMISIVO` por +a nivel de mesh con un modo no establecido usan el modo `PERMISIVO` por defecto. La siguiente política de autenticación de pares requiere que todos los workloads en el namespace diff --git a/content/es/docs/concepts/traffic-management/index.md b/content/es/docs/concepts/traffic-management/index.md index 9769a4a0d9ee..2736a69b2c77 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 meshsin 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, @@ -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 meshal 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 @@ -87,7 +87,7 @@ Un virtual service le permite configurar cómo se enrutan las solicitudes a un s 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 mesh. -Su meshpuede requerir múltiples virtual services o ninguno, dependiendo de su caso de uso. +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,7 +127,7 @@ 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 meshutiliza 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 @@ -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 meshagregado 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 >}} @@ -518,7 +518,7 @@ el tráfico para services que se ejecutan fuera de la mesh, incluyendo las sigui 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 meshen 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 @@ -697,7 +697,7 @@ o cuántas veces han fallado las llamadas a este host. Una vez que se alcanza es 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 mesh"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 diff --git a/content/es/docs/examples/microservices-istio/single/index.md b/content/es/docs/examples/microservices-istio/single/index.md index de422986bab3..31bd4f102cee 100644 --- a/content/es/docs/examples/microservices-istio/single/index.md +++ b/content/es/docs/examples/microservices-istio/single/index.md @@ -1,5 +1,5 @@ --- -title: Ejecutar un microservicio Localmente +title: Ejecutar un Microservicio Localmente overview: Aprende cómo trabajar en un solo servicio en tu máquina local. weight: 10 owner: istio/wg-docs-maintainers From d04aa3c7bf22585dbb8adf5d3244d9e3852acb6a Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Mon, 4 Aug 2025 09:05:50 +0200 Subject: [PATCH 5/5] Change PERMISIVO by PERMISSIVE Signed-off-by: Francisco Herrera --- content/es/docs/concepts/security/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/es/docs/concepts/security/index.md b/content/es/docs/concepts/security/index.md index 49865e2b097d..1721a0c5688c 100644 --- a/content/es/docs/concepts/security/index.md +++ b/content/es/docs/concepts/security/index.md @@ -383,7 +383,7 @@ sigue siendo una buena práctica evitar tener múltiples políticas de autentica 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 mesh 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