From 71fa6190c0ce6a0c6b6ebeb05d3fd2ca0a9d13a8 Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Fri, 1 Aug 2025 17:39:48 +0200 Subject: [PATCH 1/3] Add Spanish translation for security and traffic management tasks (files 109-130) Signed-off-by: Francisco Herrera --- .../authentication/authn-policy/index.md | 8 +- .../authentication/mtls-migration/index.md | 2 +- .../authorization/authz-custom/index.md | 20 +- .../authorization/authz-deny/index.md | 2 +- .../authorization/authz-http/index.md | 4 +- .../security/authorization/authz-tcp/index.md | 2 +- .../authorization/authz-td-migration/index.md | 8 +- .../cert-management/plugin-ca-cert/index.md | 2 +- .../circuit-breaking/index.md | 2 +- .../egress/egress-control/index.md | 18 +- .../egress-gateway-tls-origination/index.md | 2 +- .../egress/egress-gateway/index.md | 14 +- .../egress/http-proxy/index.md | 2 +- .../fault-injection/index.md | 14 +- .../ingress/gateway-api/index.md | 178 +++++++-------- .../ingress/ingress-control/index.md | 6 +- .../ingress-sidecar-tls-termination/index.md | 12 +- .../ingress/secure-ingress/index.md | 215 +++++++++--------- .../traffic-management/mirroring/index.md | 86 +++---- .../request-routing/index.md | 153 +++++++------ .../request-timeouts/index.md | 104 ++++----- .../traffic-shifting/index.md | 89 ++++---- 22 files changed, 465 insertions(+), 478 deletions(-) diff --git a/content/es/docs/tasks/security/authentication/authn-policy/index.md b/content/es/docs/tasks/security/authentication/authn-policy/index.md index a46c7353c5e44..6cba1b8480ab2 100644 --- a/content/es/docs/tasks/security/authentication/authn-policy/index.md +++ b/content/es/docs/tasks/security/authentication/authn-policy/index.md @@ -117,9 +117,9 @@ $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metada ## Habilitar globalmente mTLS de Istio en modo STRICT Aunque Istio actualiza automáticamente todo el tráfico entre los proxies y los workloads a mTLS, -los workloads aún pueden recibir tráfico de texto plano. Para evitar el tráfico no mTLS para toda la malla, -establezca una política de autenticación de pares a nivel de malla con el modo mTLS establecido en `STRICT`. -La política de autenticación de pares a nivel de malla no debe tener un `selector` y debe aplicarse en el **namespace raíz**, por ejemplo: +los workloads aún pueden recibir tráfico de texto plano. Para evitar el tráfico no mTLS para toda la mesh, +establezca una política de autenticación de pares a nivel de meshcon el modo mTLS establecido en `STRICT`. +La política de autenticación de pares a nivel de meshno debe tener un `selector` y debe aplicarse en el **namespace raíz**, por ejemplo: {{< text bash >}} $ kubectl apply -f - <}} Esta política de autenticación de pares configura los workloads para que solo acepten solicitudes cifradas con TLS. -Dado que no especifica un valor para el campo `selector`, la política se aplica a todos los workloads de la malla. +Dado que no especifica un valor para el campo `selector`, la política se aplica a todos los workloads de la mesh. Ejecute el comando de prueba de nuevo: diff --git a/content/es/docs/tasks/security/authentication/mtls-migration/index.md b/content/es/docs/tasks/security/authentication/mtls-migration/index.md index 4cd439a249c49..137c51d2353eb 100644 --- a/content/es/docs/tasks/security/authentication/mtls-migration/index.md +++ b/content/es/docs/tasks/security/authentication/mtls-migration/index.md @@ -129,7 +129,7 @@ Si no puede migrar todos sus services a Istio (es decir, inyectar el sidecar de Sin embargo, cuando se configura con el modo `PERMISSIVE`, no se realizarán comprobaciones de autenticación o autorización para el tráfico de texto plano por defecto. Le recomendamos que utilice la [Autorización de Istio](/es/docs/tasks/security/authorization/authz-http/) para configurar diferentes rutas con diferentes políticas de autorización. -## Bloquear mTLS para toda la malla +## Bloquear mTLS para toda la mesh Puede bloquear los workloads en todos los namespaces para que solo acepten tráfico mTLS colocando la política en el namespace del sistema de su instalación de Istio. diff --git a/content/es/docs/tasks/security/authorization/authz-custom/index.md b/content/es/docs/tasks/security/authorization/authz-custom/index.md index bba4f3f8684d3..9de2161a03ec0 100644 --- a/content/es/docs/tasks/security/authorization/authz-custom/index.md +++ b/content/es/docs/tasks/security/authorization/authz-custom/index.md @@ -46,7 +46,7 @@ La sobrecarga de caché y propagación puede causar algún retraso. ## Desplegar el autorizador externo -Primero, debe desplegar el autorizador externo. Para ello, simplemente desplegará el autorizador externo de ejemplo en un pod independiente en la malla. +Primero, debe desplegar el autorizador externo. Para ello, simplemente desplegará el autorizador externo de ejemplo en un pod independiente en la mesh. 1. Ejecute el siguiente comando para desplegar el autorizador externo de ejemplo: @@ -65,8 +65,8 @@ Primero, debe desplegar el autorizador externo. Para ello, simplemente desplegar {{< /text >}} Alternativamente, también puede desplegar el autorizador externo como un contenedor separado en el mismo pod de la aplicación -que necesita la autorización externa o incluso desplegarlo fuera de la malla. En cualquier caso, también deberá crear un -recurso de entrada de service para registrar el service en la malla y asegurarse de que sea accesible para el proxy. +que necesita la autorización externa o incluso desplegarlo fuera de la mesh. En cualquier caso, también deberá crear un +recurso de entrada de service para registrar el service en la mesh y asegurarse de que sea accesible para el proxy. El siguiente es un ejemplo de entrada de service para un autorizador externo desplegado en un contenedor separado en el mismo pod de la aplicación que necesita la autorización externa. @@ -78,12 +78,12 @@ metadata: name: external-authz-grpc-local spec: hosts: - - "external-authz-grpc.local" # El nombre del service a usar en el proveedor de extensión en la configuración de la malla. + - "external-authz-grpc.local" # El nombre del service a usar en el proveedor de extensión en la configuración de la mesh. endpoints: - address: "127.0.0.1" ports: - name: grpc - number: 9191 # El número de puerto a usar en el proveedor de extensión en la configuración de la malla. + number: 9191 # El número de puerto a usar en el proveedor de extensión en la configuración de la mesh. protocol: GRPC resolution: STATIC {{< /text >}} @@ -91,8 +91,8 @@ spec: ## Definir el autorizador externo Para utilizar la acción `CUSTOM` en la política de autorización, debe definir el autorizador externo que está permitido -utilizar en la malla. Esto se define actualmente en el [proveedor de extensión](https://github.com/istio/api/blob/a205c627e4b955302bbb77dd837c8548e89e6e64/mesh/v1alpha1/config.proto#L534) -en la configuración de la malla. +utilizar en la mesh. Esto se define actualmente en el [proveedor de extensión](https://github.com/istio/api/blob/a205c627e4b955302bbb77dd837c8548e89e6e64/mesh/v1alpha1/config.proto#L534) +en la configuración de la mesh. Actualmente, el único tipo de proveedor de extensión compatible es el proveedor [Envoy `ext_authz`](https://www.envoyproxy.io/docs/envoy/v1.16.2/intro/arch_overview/security/ext_authz_filter). El autorizador externo debe implementar la API de verificación `ext_authz` de Envoy correspondiente. @@ -100,7 +100,7 @@ El autorizador externo debe implementar la API de verificación `ext_authz` de E En esta tarea, utilizará un [autorizador externo de ejemplo]({{< github_tree >}}/samples/extauthz) que permite solicitudes con la cabecera `x-ext-authz: allow`. -1. Edite la configuración de la malla con el siguiente comando: +1. Edite la configuración de la mesh con el siguiente comando: {{< text bash >}} $ kubectl edit configmap istio -n istio-system @@ -168,7 +168,7 @@ El autorizador externo ya está listo para ser utilizado por la política de aut app: httpbin action: CUSTOM provider: - # El nombre del proveedor debe coincidir con el proveedor de extensión definido en la configuración de la malla. + # El nombre del proveedor debe coincidir con el proveedor de extensión definido en la configuración de la mesh. # También puede reemplazar esto con sample-ext-authz-http para probar la otra definición de autorizador externo. name: sample-ext-authz-grpc rules: @@ -230,7 +230,7 @@ El autorizador externo ya está listo para ser utilizado por la política de aut $ kubectl delete namespace foo {{< /text >}} -1. Elimine la definición del proveedor de extensión de la configuración de la malla. +1. Elimine la definición del proveedor de extensión de la configuración de la mesh. ## Expectativas de rendimiento diff --git a/content/es/docs/tasks/security/authorization/authz-deny/index.md b/content/es/docs/tasks/security/authorization/authz-deny/index.md index a86dc4cc79917..f2d4e5e24a711 100644 --- a/content/es/docs/tasks/security/authorization/authz-deny/index.md +++ b/content/es/docs/tasks/security/authorization/authz-deny/index.md @@ -7,7 +7,7 @@ owner: istio/wg-security-maintainers test: yes --- -Esta tarea muestra cómo configurar la política de autorización de Istio de acción `DENY` para denegar explícitamente el tráfico en una malla de Istio. +Esta tarea muestra cómo configurar la política de autorización de Istio de acción `DENY` para denegar explícitamente el tráfico en un mesh de Istio. Esto es diferente de la acción `ALLOW` porque la acción `DENY` tiene mayor prioridad y no será eludida por ninguna acción `ALLOW`. diff --git a/content/es/docs/tasks/security/authorization/authz-http/index.md b/content/es/docs/tasks/security/authorization/authz-http/index.md index 0b2920afaf1d5..6d8bac671b722 100644 --- a/content/es/docs/tasks/security/authorization/authz-http/index.md +++ b/content/es/docs/tasks/security/authorization/authz-http/index.md @@ -10,7 +10,7 @@ owner: istio/wg-security-maintainers test: yes --- -Esta tarea muestra cómo configurar la política de autorización de Istio de acción `ALLOW` para el tráfico HTTP en una malla de Istio. +Esta tarea muestra cómo configurar la política de autorización de Istio de acción `ALLOW` para el tráfico HTTP en un mesh de Istio. ## Antes de empezar @@ -69,7 +69,7 @@ y luego otorgue más acceso al workload de forma gradual e incremental. Apunte su navegador a la `productpage` de Bookinfo (`http://$GATEWAY_URL/productpage`). Debería ver `"RBAC: acceso denegado"`. El error muestra que la política `deny-all` configurada está funcionando como se esperaba, y Istio no tiene ninguna regla que permita ningún acceso a - los workloads en la malla. + los workloads en la mesh. 1. Ejecute el siguiente comando para crear una política `productpage-viewer` para permitir el acceso con el método `GET` al workload `productpage`. La política no establece el campo `from` diff --git a/content/es/docs/tasks/security/authorization/authz-tcp/index.md b/content/es/docs/tasks/security/authorization/authz-tcp/index.md index 9707b95c91f87..520c6bb474267 100644 --- a/content/es/docs/tasks/security/authorization/authz-tcp/index.md +++ b/content/es/docs/tasks/security/authorization/authz-tcp/index.md @@ -9,7 +9,7 @@ owner: istio/wg-security-maintainers test: no --- -Esta tarea muestra cómo configurar la política de autorización de Istio para el tráfico TCP en una malla de Istio. +Esta tarea muestra cómo configurar la política de autorización de Istio para el tráfico TCP en un mesh de Istio. ## Antes de empezar diff --git a/content/es/docs/tasks/security/authorization/authz-td-migration/index.md b/content/es/docs/tasks/security/authorization/authz-td-migration/index.md index af62dba88eb2a..9e3d2c6f55bf4 100644 --- a/content/es/docs/tasks/security/authorization/authz-td-migration/index.md +++ b/content/es/docs/tasks/security/authorization/authz-td-migration/index.md @@ -10,9 +10,9 @@ test: yes Esta tarea muestra cómo migrar de un trust domain a otro sin cambiar la política de autorización. En Istio 1.4, introducimos una feature alfa para soportar la {{< gloss >}}trust domain migration{{}} para la política de autorización. Esto significa que si una -malla de Istio necesita cambiar su {{< gloss >}}trust domain{{}}, la política de autorización no necesita ser cambiada manualmente. +meshde Istio necesita cambiar su {{< gloss >}}trust domain{{}}, la política de autorización no necesita ser cambiada manualmente. En Istio, si un {{< gloss >}}workload{{}} se está ejecutando en el namespace `foo` con la cuenta de service `bar`, y el trust domain del sistema es `my-td`, -la identidad de dicho workload es `spiffe://my-td/ns/foo/sa/bar`. Por defecto, el trust domain de la malla de Istio es `cluster.local`, +la identidad de dicho workload es `spiffe://my-td/ns/foo/sa/bar`. Por defecto, el trust domain de la mesh de Istio es `cluster.local`, a menos que lo especifique durante la instalación. ## Antes de empezar @@ -97,7 +97,7 @@ Antes de comenzar esta tarea, haga lo siguiente: $ kubectl rollout restart deployment -n istio-system istiod {{< /text >}} - La malla de Istio ahora se está ejecutando con un nuevo trust domain, `new-td`. + la mesh de Istio ahora se está ejecutando con un nuevo trust domain, `new-td`. 1. Vuelva a desplegar las applications `httpbin` y `curl` para que recojan los cambios del nuevo control plane de Istio. @@ -165,7 +165,7 @@ Antes de comenzar esta tarea, haga lo siguiente: A partir de Istio 1.4, al escribir la política de autorización, debe considerar usar el valor `cluster.local` como la parte del trust domain en la política. Por ejemplo, en lugar de `old-td/ns/curl-allow/sa/curl`, debería ser `cluster.local/ns/curl-allow/sa/curl`. -Tenga en cuenta que en este caso, `cluster.local` no es el trust domain de la malla de Istio (el trust domain sigue siendo `old-td`). Sin embargo, +Tenga en cuenta que en este caso, `cluster.local` no es el trust domain de la mesh de Istio (el trust domain sigue siendo `old-td`). Sin embargo, en la política de autorización, `cluster.local` es un puntero que apunta al trust domain actual, es decir, `old-td` (y más tarde `new-td`), así como a sus alias. Al usar `cluster.local` en la política de autorización, cuando migre a un nuevo trust domain, Istio detectará esto y tratará el nuevo trust domain como el antiguo trust domain sin que tenga que incluir los alias. diff --git a/content/es/docs/tasks/security/cert-management/plugin-ca-cert/index.md b/content/es/docs/tasks/security/cert-management/plugin-ca-cert/index.md index 7b223cd13348f..1b23f4be0fbfe 100644 --- a/content/es/docs/tasks/security/cert-management/plugin-ca-cert/index.md +++ b/content/es/docs/tasks/security/cert-management/plugin-ca-cert/index.md @@ -18,7 +18,7 @@ y utilizar la CA raíz para emitir certificados intermedios a las CA de Istio qu Una CA de Istio puede firmar certificados de workloads utilizando el certificado y la clave especificados por el administrador, y distribuir un certificado raíz especificado por el administrador a los workloads como la raíz de confianza. -El siguiente gráfico demuestra la jerarquía de CA recomendada en una malla que contiene dos clusters. +El siguiente gráfico demuestra la jerarquía de CA recomendada en un mesh que contiene dos clusters. {{< image width="50%" link="ca-hierarchy.svg" diff --git a/content/es/docs/tasks/traffic-management/circuit-breaking/index.md b/content/es/docs/tasks/traffic-management/circuit-breaking/index.md index 049fdccaa02f2..dd2b144aa5679 100644 --- a/content/es/docs/tasks/traffic-management/circuit-breaking/index.md +++ b/content/es/docs/tasks/traffic-management/circuit-breaking/index.md @@ -10,7 +10,7 @@ test: yes Esta tarea muestra cómo configurar el interruptor de circuito para conexiones, solicitudes y detección de valores atípicos. -el interruptor de circuito es un patrón importante para crear applications de microservices resilientes. +el interruptor de circuito es un patrón importante para crear applications de microservicios resilientes. el interruptor de circuito le permite escribir applications que limitan el impacto de fallos, picos de latencia y otros efectos indeseables de las peculiaridades de la red. En esta tarea, configurará las reglas de interruptor de circuito y luego probará la diff --git a/content/es/docs/tasks/traffic-management/egress/egress-control/index.md b/content/es/docs/tasks/traffic-management/egress/egress-control/index.md index e3fdef790145a..3f65fd462f26a 100644 --- a/content/es/docs/tasks/traffic-management/egress/egress-control/index.md +++ b/content/es/docs/tasks/traffic-management/egress/egress-control/index.md @@ -1,6 +1,6 @@ --- title: Acceso a Services Externos -description: Describe cómo configurar Istio para enrutar el tráfico de services en la malla a services externos. +description: Describe cómo configurar Istio para enrutar el tráfico de services en la mesh a services externos. weight: 10 aliases: - /docs/tasks/egress.html @@ -18,7 +18,7 @@ un control más estricto suele ser preferible. Esta tarea le muestra cómo acceder a services externos de tres maneras diferentes: -1. Permitir que el proxy Envoy pase las solicitudes a services que no están configurados dentro de la malla. +1. Permitir que el proxy Envoy pase las solicitudes a services que no están configurados dentro de la mesh. 1. Configurar [entradas de service](/es/docs/reference/config/networking/service-entry/) para proporcionar acceso controlado a services externos. 1. Omitir completamente el proxy Envoy para un rango específico de IPs. @@ -60,7 +60,7 @@ Istio tiene una [opción de instalación](/es/docs/reference/config/istio.mesh.v de services externos, es decir, aquellos services que no están definidos en el service registry interno de Istio. Si esta opción se establece en `ALLOW_ANY`, el proxy de Istio permite que las llamadas a services desconocidos pasen. Si la opción se establece en `REGISTRY_ONLY`, el proxy de Istio bloquea cualquier host sin un service HTTP o -una entrada de service definida dentro de la malla. +una entrada de service definida dentro de la mesh. `ALLOW_ANY` es el valor predeterminado, lo que le permite comenzar a evaluar Istio rápidamente, sin controlar el acceso a services externos. Luego puede decidir [configurar el acceso a services externos](#controlled-access-to-external-services) más tarde. @@ -97,10 +97,10 @@ Luego puede decidir [configurar el acceso a services externos](#controlled-acces HTTP/2 200 {{< /text >}} -¡Felicidades! Ha enviado tráfico de salida desde su malla con éxito. +¡Felicidades! Ha enviado tráfico de salida desde su meshcon éxito. Este enfoque simple para acceder a services externos tiene el inconveniente de que se pierde el monitoreo y control de Istio -para el tráfico a services externos. La siguiente sección le muestra cómo monitorear y controlar el acceso de su malla a +para el tráfico a services externos. La siguiente sección le muestra cómo monitorear y controlar el acceso de su mesha services externos. ## Acceso controlado a services externos @@ -163,7 +163,7 @@ cualquier otro acceso no intencional. accediendo a `httpbin.org` estableciéndolo en la cabecera `HOST`, mientras que en realidad se conecta a una IP diferente (que no está asociada con `httpbin.org`). El proxy sidecar de Istio confiará en la cabecera HOST, y permitirá incorrectamente el tráfico, aunque se esté entregando a la dirección IP de un host diferente. Ese host puede ser un sitio malicioso, - o un sitio legítimo, prohibido por las políticas de seguridad de la malla. + o un sitio legítimo, prohibido por las políticas de seguridad de la mesh. Con la resolución `DNS`, el proxy sidecar ignorará la dirección IP de destino original y dirigirá el tráfico a `httpbin.org`, realizando una consulta DNS para obtener una dirección IP de `httpbin.org`. @@ -548,17 +548,17 @@ $ istioctl install ## Comprender lo que sucedió -En esta tarea, examinó tres formas de llamar a services externos desde una malla de Istio: +En esta tarea, examinó tres formas de llamar a services externos desde un mesh de Istio: 1. Configurar Envoy para permitir el acceso a cualquier service externo. -1. Usar una entrada de service para registrar un service externo accesible dentro de la malla. Este es el +1. Usar una entrada de service para registrar un service externo accesible dentro de la mesh. Este es el enfoque recomendado. 1. Configurar el sidecar de Istio para excluir IPs externas de su tabla de IPs remapeadas. El primer enfoque dirige el tráfico a través del proxy sidecar de Istio, incluidas las llamadas a services -desconocidos dentro de la malla. Al usar este enfoque, +desconocidos dentro de la mesh. Al usar este enfoque, no puede monitorear el acceso a services externos ni aprovechar las features de control de tráfico de Istio para ellos. Para cambiar fácilmente al segundo enfoque para services específicos, simplemente cree entradas de service para esos services externos. Este proceso le permite acceder inicialmente a cualquier service externo y luego diff --git a/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md b/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md index 60deaebdbc9d6..cc1c897728164 100644 --- a/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md +++ b/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md @@ -463,7 +463,7 @@ Para simular un service externo real que admita el protocolo mTLS, despliegue un servidor [NGINX](https://www.nginx.com) en su cluster de Kubernetes, pero ejecutándose fuera de la service mesh de Istio, es decir, en un namespace sin la inyección de proxy sidecar de Istio habilitada. -1. Cree un namespace para representar services fuera de la malla de Istio, llamado `mesh-external`. Tenga en cuenta que el proxy sidecar +1. Cree un namespace para representar services fuera de la mesh de Istio, llamado `mesh-external`. Tenga en cuenta que el proxy sidecar no se inyectará automáticamente en los pods de este namespace ya que la inyección automática de sidecar no estaba [habilitada](/es/docs/setup/additional-setup/sidecar-injection/#deploying-an-app) en él. diff --git a/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md b/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md index 08b429e0767e0..c1ff031b81bf7 100644 --- a/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md +++ b/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md @@ -14,16 +14,16 @@ Este ejemplo no funciona en Minikube. {{}} La tarea [Acceso a Services Externos](/es/docs/tasks/traffic-management/egress/egress-control) muestra cómo configurar -Istio para permitir el acceso a services HTTP y HTTPS externos desde applications dentro de la malla. +Istio para permitir el acceso a services HTTP y HTTPS externos desde applications dentro de la mesh. Allí, los services externos se llaman directamente desde el sidecar del cliente. Este ejemplo también muestra cómo configurar Istio para llamar a services externos, aunque esta vez indirectamente a través de un service _egress gateway_ dedicado. Istio utiliza [ingress y egress gateways](/es/docs/reference/config/networking/gateway/) para configurar balanceadores de carga que se ejecutan en el borde de una service mesh. -Un ingress gateway le permite definir puntos de entrada a la malla por los que fluye todo el tráfico entrante. -Un egress gateway es un concepto simétrico; define puntos de salida de la malla. Los egress gateways permiten -aplicar features de Istio, por ejemplo, monitoreo y reglas de ruta, al tráfico que sale de la malla. +Un ingress gateway le permite definir puntos de entrada a la mesh por los que fluye todo el tráfico entrante. +Un egress gateway es un concepto simétrico; define puntos de salida de la mesh. Los egress gateways permiten +aplicar features de Istio, por ejemplo, monitoreo y reglas de ruta, al tráfico que sale de la mesh. ## Caso de uso @@ -32,7 +32,7 @@ de la service mesh debe fluir a través de un conjunto de nodos dedicados. Estos separadas del resto de los nodos que ejecutan applications en el cluster. Estos nodos especiales servirán para la aplicación de políticas en el tráfico de salida y serán monitoreados más a fondo que otros nodos. -Otro caso de uso es un cluster donde los nodos de la aplicación no tienen IPs públicas, por lo que los services en malla que se ejecutan +Otro caso de uso es un cluster donde los nodos de la aplicación no tienen IPs públicas, por lo que los services en meshque se ejecutan en ellos no pueden acceder a Internet. Definir un egress gateway, dirigir todo el tráfico de salida a través de él y asignar IPs públicas a los nodos del egress gateway permite que los nodos de la aplicación accedan a services externos de forma controlada. @@ -687,12 +687,12 @@ $ kubectl delete tlsroute forward-cnn-from-egress-gateway Tenga en cuenta que la definición de un `Gateway` de salida en Istio no proporciona por sí misma ningún tratamiento especial para los nodos en los que se ejecuta el service del egress gateway. Depende del administrador del cluster o del proveedor de la nube desplegar los egress gateways en nodos dedicados e introducir medidas de seguridad adicionales para hacer que estos nodos sean más -seguros que el resto de la malla. +seguros que el resto de la mesh. Istio *no puede garantizar de forma segura* que todo el tráfico de salida fluya realmente a través de los egress gateways. Istio solo habilita dicho flujo a través de sus proxies sidecar. Si los atacantes eluden el proxy sidecar, podrían acceder directamente a services externos sin atravesar el egress gateway. Así, los atacantes escapan del control y monitoreo de Istio. -El administrador del cluster o el proveedor de la nube deben asegurarse de que ningún tráfico salga de la malla sin pasar por el egress +El administrador del cluster o el proveedor de la nube deben asegurarse de que ningún tráfico salga de la mesh sin pasar por el egress gateway. Los mecanismos externos a Istio deben hacer cumplir este requisito. Por ejemplo, el administrador del cluster puede configurar un firewall para denegar todo el tráfico que no provenga del egress gateway. Las [políticas de red de Kubernetes](https://kubernetes.io/docs/concepts/services-networking/network-policies/) también diff --git a/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md b/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md index 9907ed45241f5..845fe13f9515e 100644 --- a/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md +++ b/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md @@ -9,7 +9,7 @@ owner: istio/wg-networking-maintainers test: yes --- El ejemplo [Configurar un Egress Gateway](/es/docs/tasks/traffic-management/egress/egress-gateway/) muestra cómo dirigir -el tráfico a services externos desde su malla a través de un componente de borde de Istio llamado _Egress Gateway_. Sin embargo, algunos +el tráfico a services externos desde su mesha través de un componente de borde de Istio llamado _Egress Gateway_. Sin embargo, algunos casos requieren un proxy HTTPS externo y heredado (no Istio) para acceder a services externos. Por ejemplo, su empresa ya puede tener un proxy de este tipo en su lugar y todas las applications dentro de la organización pueden estar obligadas a dirigir su tráfico a través de él. diff --git a/content/es/docs/tasks/traffic-management/fault-injection/index.md b/content/es/docs/tasks/traffic-management/fault-injection/index.md index b3505a94a4d8d..2e01e7bae777c 100644 --- a/content/es/docs/tasks/traffic-management/fault-injection/index.md +++ b/content/es/docs/tasks/traffic-management/fault-injection/index.md @@ -36,8 +36,8 @@ Esta tarea muestra cómo inyectar fallos para probar la resiliencia de su applic ## Inyectar un fallo de retardo HTTP -Para probar la resiliencia de los microservices de la application Bookinfo, inyecte un retardo de 7s -entre los microservices `reviews:v2` y `ratings` para el usuario `jason`. Esta prueba +Para probar la resiliencia de los microservicios de la application Bookinfo, inyecte un retardo de 7s +entre los microservicios `reviews:v2` y `ratings` para el usuario `jason`. Esta prueba descubrirá un bug que se introdujo intencionalmente en la aplicación Bookinfo. Tenga en cuenta que el service `reviews:v2` tiene un tiempo de espera de conexión codificado de 10s para @@ -104,7 +104,7 @@ espera que el flujo de extremo a extremo continúe sin errores. ## Comprender lo que sucedió -Ha encontrado un bug. Hay tiempos de espera codificados en los microservices que han +Ha encontrado un bug. Hay tiempos de espera codificados en los microservicios que han causado que el service `reviews` falle. Como se esperaba, el retardo de 7s que introdujo no afecta al service `reviews` @@ -114,7 +114,7 @@ codificado como 3s + 1 reintento para un total de 6s. Como resultado, la llamada de `productpage` a `reviews` agota el tiempo de espera prematuramente y lanza un error después de 6s. Errores como este pueden ocurrir en applications empresariales típicas donde diferentes equipos -desarrollan diferentes microservices de forma independiente. Las reglas de inyección de fallos de Istio le ayudan a identificar tales anomalías +desarrollan diferentes microservicios de forma independiente. Las reglas de inyección de fallos de Istio le ayudan a identificar tales anomalías sin afectar a los usuarios finales. {{< tip >}} @@ -127,7 +127,7 @@ Observe que la prueba de inyección de fallos se restringe a cuando el usuario c Normalmente, solucionaría el problema de la siguiente manera: 1. Aumentando el tiempo de espera del service `productpage` a `reviews` o disminuyendo el tiempo de espera de `reviews` a `ratings` -1. Deteniendo y reiniciando el microservice corregido +1. Deteniendo y reiniciando el microservicio corregido 1. Confirmando que la página web `/productpage` devuelve su respuesta sin errores. Sin embargo, ya tiene una solución ejecutándose en la v3 del service `reviews`. @@ -141,8 +141,8 @@ que el flujo de extremo a extremo continúa sin errores. ## Inyectar un fallo de aborto HTTP -Otra forma de probar la resiliencia de los microservices es introducir un fallo de aborto HTTP. -En esta tarea, introducirá un aborto HTTP en los microservices `ratings` para +Otra forma de probar la resiliencia de los microservicios es introducir un fallo de aborto HTTP. +En esta tarea, introducirá un aborto HTTP en los microservicios `ratings` para el usuario de prueba `jason`. En este caso, espera que la página se cargue inmediatamente y muestre el mensaje `El service de calificaciones no está disponible actualmente`. diff --git a/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md b/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md index ba0e8005eb3fc..1309152e70145 100644 --- a/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md +++ b/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md @@ -1,6 +1,6 @@ --- title: Kubernetes Gateway API -description: Describes how to configure the Kubernetes Gateway API with Istio. +description: Describe cómo configurar el Kubernetes Gateway API con Istio. weight: 50 aliases: - /docs/tasks/traffic-management/ingress/service-apis/ @@ -10,65 +10,65 @@ owner: istio/wg-networking-maintainers test: yes --- -In addition to its own traffic management API, +Además de su propia API de gestión de tráfico, {{< boilerplate gateway-api-future >}} -This document describes the differences between the Istio and Kubernetes APIs and provides a simple example -that shows you how to configure Istio to expose a service outside the service mesh cluster using the Gateway API. -Note that these APIs are an actively developed evolution of the Kubernetes [Service](https://kubernetes.io/docs/concepts/services-networking/service/) -and [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) APIs. +Este documento describe las diferencias entre las APIs de Istio y Kubernetes y proporciona un ejemplo simple +que te muestra cómo configurar Istio para exponer un servicio fuera del clúster de service mesh usando el Gateway API. +Ten en cuenta que estas APIs son una evolución desarrollada activamente de las APIs de [Service](https://kubernetes.io/docs/concepts/services-networking/service/) +e [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) de Kubernetes. {{< tip >}} -Many of the Istio traffic management documents include instructions for using either the Istio or Kubernetes API -(see the [control ingress traffic task](/es/docs/tasks/traffic-management/ingress/ingress-control), for example). -You can use the Gateway API, right from the start, by following the [getting started instructions](/es/docs/setup/getting-started/). +Muchos de los documentos de gestión de tráfico de Istio incluyen instrucciones para usar tanto la API de Istio como la de Kubernetes +(consulta la [tarea de controlar tráfico de ingreso](/es/docs/tasks/traffic-management/ingress/ingress-control), por ejemplo). +Puedes usar el Gateway API, desde el principio, siguiendo las [instrucciones de comenzar](/es/docs/setup/getting-started/). {{< /tip >}} -## Setup +## Configuración -1. The Gateway APIs do not come installed by default on most Kubernetes clusters. Install the Gateway API CRDs if they are not present: +1. Las APIs de Gateway no vienen instaladas por defecto en la mayoría de los clústeres de Kubernetes. Instala los CRDs del Gateway API si no están presentes: {{< text bash >}} $ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \ { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref={{< k8s_gateway_api_version >}}" | kubectl apply -f -; } {{< /text >}} -1. Install Istio using the `minimal` profile: +1. Instala Istio usando el perfil `minimal`: {{< text bash >}} $ istioctl install --set profile=minimal -y {{< /text >}} -## Differences from Istio APIs +## Diferencias de las APIs de Istio -The Gateway APIs share a lot of similarities to the Istio APIs such as Gateway and VirtualService. -The main resource shares the same name, `Gateway`, and the resources serve similar goals. +Las APIs de Gateway comparten muchas similitudes con las APIs de Istio como Gateway y VirtualService. +El recurso principal comparte el mismo nombre, `Gateway`, y los recursos sirven objetivos similares. -The new Gateway APIs aim to take the learnings from various Kubernetes ingress implementations, including Istio, -to build a standardized vendor neutral API. These APIs generally serve the same purposes as Istio Gateway and VirtualService, -with a few key differences: +Las nuevas APIs de Gateway buscan incorporar las lecciones de varias implementaciones de ingress de Kubernetes, incluyendo Istio, +para crear una API estandarizada neutral de proveedores. Estas APIs generalmente sirven los mismos propósitos que las APIs de Gateway y VirtualService, +con algunas diferencias clave: -* In Istio APIs, a `Gateway` *configures* an existing gateway Deployment/Service that has [been deployed](/es/docs/setup/additional-setup/gateway/). - In the Gateway APIs, the `Gateway` resource both *configures and deploys* a gateway. - See [Deployment Methods](#deployment-methods) for more information. -* In the Istio `VirtualService`, all protocols are configured within a single resource. - In the Gateway APIs, each protocol type has its own resource, such as `HTTPRoute` and `TCPRoute`. -* While the Gateway APIs offer a lot of rich routing functionality, it does not yet cover 100% of Istio's feature set. - Work is ongoing to extend the API to cover these use cases, as well as utilizing the APIs [extensibility](https://gateway-api.sigs.k8s.io/#gateway-api-concepts) - to better expose Istio functionality. +* En las APIs de Istio, un `Gateway` *configura* un Deployment/Service de gateway existente que [ha sido desplegado](/es/docs/setup/additional-setup/gateway/). + En las APIs de Gateway, el recurso `Gateway` tanto *configura como despliega* un gateway. + Consulta [Métodos de despliegue](#métodos-de-despliegue) para más información. +* En el `VirtualService` de Istio, todos los protocolos se configuran en un solo recurso. + En las APIs de Gateway, cada tipo de protocolo tiene su propio recurso, como `HTTPRoute` y `TCPRoute`. +* Aunque las APIs de Gateway ofrecen una gran funcionalidad de enrutamiento, no cubren aún el 100% de la funcionalidad de Istio. + El trabajo continúa para extender la API para cubrir estos casos de uso, así como para utilizar las APIs [extensibilidad](https://gateway-api.sigs.k8s.io/#gateway-api-concepts) + para exponer mejor la funcionalidad de Istio. -## Configuring a Gateway +## Configuración de un Gateway -See the [Gateway API](https://gateway-api.sigs.k8s.io/) documentation for information about the APIs. +Consulta la [documentación de la API de Gateway](https://gateway-api.sigs.k8s.io/) para información sobre las APIs. -In this example, we will deploy a simple application and expose it externally using a `Gateway`. +En este ejemplo, desplegaremos una aplicación simple y la expondremos externamente usando un `Gateway`. -1. First, deploy the `httpbin` test application: +1. Primero, despliega la aplicación de prueba `httpbin`: {{< text bash >}} $ kubectl apply -f @samples/httpbin/httpbin.yaml@ {{< /text >}} -1. Deploy the Gateway API configuration including a single exposed route (i.e., `/get`): +1. Despliega la configuración del Gateway API que incluye una sola ruta expuesta (es decir, `/get`): {{< text bash >}} $ kubectl create namespace istio-ingress @@ -110,14 +110,14 @@ In this example, we will deploy a simple application and expose it externally us EOF {{< /text >}} -1. Set the Ingress Host environment variable: +1. Establece la variable de entorno Ingress Host: {{< text bash >}} $ kubectl wait -n istio-ingress --for=condition=programmed gateways.gateway.networking.k8s.io gateway $ export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io gateway -n istio-ingress -ojsonpath='{.status.addresses[0].value}') {{< /text >}} -1. Access the `httpbin` service using _curl_: +1. Accede al servicio `httpbin` usando _curl_: {{< text bash >}} $ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get" @@ -128,11 +128,11 @@ In this example, we will deploy a simple application and expose it externally us ... {{< /text >}} - Note the use of the `-H` flag to set the _Host_ HTTP header to - "httpbin.example.com". This is needed because the `HTTPRoute` is configured to handle "httpbin.example.com", - but in your test environment you have no DNS binding for that host and are simply sending your request to the ingress IP. + Nota el uso del flag `-H` para establecer el encabezado HTTP _Host_ a + "httpbin.example.com". Esto es necesario porque la regla `HTTPRoute` está configurada para manejar "httpbin.example.com", + pero en tu entorno de prueba no tienes un enlace DNS para ese host y simplemente envías tu solicitud al IP de ingress. -1. Access any other URL that has not been explicitly exposed. You should see an HTTP 404 error: +1. Accede a cualquier otro URL que no haya sido expuesto explícitamente. Deberías ver un error HTTP 404: {{< text bash >}} $ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/headers" @@ -140,7 +140,7 @@ In this example, we will deploy a simple application and expose it externally us ... {{< /text >}} -1. Update the route rule to also expose `/headers` and to add a header to the request: +1. Actualiza la regla de ruta para exponer `/headers` y añade un encabezado a la solicitud: {{< text bash >}} $ kubectl apply -f - <}} -1. Access `/headers` again and notice header `My-Added-Header` has been added to the request: +1. Accede a `/headers` de nuevo y observa que el encabezado `My-Added-Header` ha sido añadido a la solicitud: {{< text bash >}} $ curl -s -HHost:httpbin.example.com "http://$INGRESS_HOST/headers" | jq '.headers["My-Added-Header"][0]' @@ -183,19 +183,19 @@ In this example, we will deploy a simple application and expose it externally us ... {{< /text >}} -## Deployment methods +## Métodos de despliegue -In the example above, you did not need to install an ingress gateway `Deployment` prior to configuring a Gateway. -In the default configuration, a gateway `Deployment` and `Service` is automatically provisioned based on the `Gateway` configuration. -For advanced use cases, manual deployment is still allowed. +En el ejemplo anterior, no necesitaste instalar un gateway de ingress `Deployment` antes de configurar un Gateway. +En la configuración por defecto, un gateway `Deployment` y `Service` se provisionan automáticamente basándose en la configuración del `Gateway`. +Para casos de uso avanzados, el despliegue manual aún está permitido. -### Automated deployment +### Despliegue automático -By default, each `Gateway` will automatically provision a `Service` and `Deployment`. -These will be named `-` (with the exception of the `istio-waypoint` `GatewayClass`, which does not append a suffix). -These configurations will be updated automatically if the `Gateway` changes (for example, if a new port is added). +Por defecto, cada `Gateway` provisionará automáticamente un `Service` y un `Deployment`. +Estos se nombrarán `-` (con la excepción del `GatewayClass` `istio-waypoint`, que no añade un sufijo). +Estas configuraciones se actualizarán automáticamente si el `Gateway` cambia (por ejemplo, si se añade un nuevo puerto). -These resources can be customized by using the `infrastructure` field: +Estos recursos pueden ser personalizados usando el campo `infrastructure`: {{< text yaml >}} apiVersion: gateway.networking.k8s.io/v1 @@ -215,11 +215,11 @@ spec: gatewayClassName: istio {{< /text >}} -Key-value pairs under `labels` and `annotations` will be copied onto the generated resources. -The `parametersRef` can be used to fully customize the generated resources. -This must reference a `ConfigMap` in the same namespace as the `Gateway`. +Los pares clave-valor bajo `labels` y `annotations` se copiarán en los recursos generados. +El `parametersRef` puede ser usado para personalizar completamente los recursos generados. +Este debe referenciar un `ConfigMap` en el mismo namespace que el `Gateway`. -An example configuration: +Un ejemplo de configuración: {{< text yaml >}} apiVersion: v1 @@ -253,8 +253,8 @@ data: port: 15021 {{< /text >}} -These configurations will be overlaid on top of the generated resources using a [Strategic Merge Patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md) strategy. -The following keys are valid: +Estas configuraciones se superpondrán en los recursos generados usando una estrategia de [Strategic Merge Patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md) +Las siguientes claves son válidas: * `service` * `deployment` * `serviceAccount` @@ -262,22 +262,22 @@ The following keys are valid: * `podDisruptionBudget` {{< tip >}} -A `HorizontalPodAutoscaler` and `PodDisruptionBudget` are not created by default. -However, if the corresponding field is present in the customization, they will be created. +Un `HorizontalPodAutoscaler` y un `PodDisruptionBudget` no se crean por defecto. +Sin embargo, si el campo correspondiente está presente en la personalización, se crearán. {{< /tip >}} -#### GatewayClass defaults +#### Configuración por defecto de GatewayClass -Defaults for all `Gateway`s can be configured for each `GatewayClass`. -This is done by a `ConfigMap` with the label `gateway.istio.io/defaults-for-class: `. -This `ConfigMap` must be in the [root namespace](/es/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-root_namespace) (typically, `istio-system`). -Only one `ConfigMap` per `GatewayClass` is allowed. -This `ConfigMap` takes the same format as the `ConfigMap` for a `Gateway`. +Las configuraciones por defecto para todos los `Gateway`s pueden ser configuradas para cada `GatewayClass`. +Esto se hace con un `ConfigMap` con la etiqueta `gateway.istio.io/defaults-for-class: `. +Este `ConfigMap` debe estar en el [namespace raíz](/es/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-root_namespace) (generalmente, `istio-system`). +Solo se permite un `ConfigMap` por `GatewayClass`. +Este `ConfigMap` tiene el mismo formato que el `ConfigMap` para un `Gateway`. -Customization may be present on both a `GatewayClass` and a `Gateway`. -If both are present, the `Gateway` customization applies after the `GatewayClass` customization. +La personalización puede estar presente tanto en un `GatewayClass` como en un `Gateway`. +Si ambos están presentes, la personalización del `Gateway` se aplica después de la personalización del `GatewayClass`. -This `ConfigMap` can also be created at installation time. For example: +Este `ConfigMap` también puede ser creado en el momento de la instalación. Por ejemplo: {{< text yaml >}} kind: IstioOperator @@ -290,16 +290,16 @@ spec: replicas: 2 {{< /text >}} -#### Resource attachment and scaling +#### Asociación de recursos y escalado -Resources can be *attached* to a `Gateway` to customize it. -However, most Kubernetes resources do not currently support attaching directly to a `Gateway`, but they can be attached to the corresponding generated `Deployment` and `Service` instead. -This is easily done because [the resources are generated with well-known labels](https://gateway-api.sigs.k8s.io/geps/gep-1762/#resource-attachment) (`gateway.networking.k8s.io/gateway-name: `) and names: +Los recursos pueden ser *asociados* a un `Gateway` para personalizarlo. +Sin embargo, la mayoría de los recursos de Kubernetes no soportan actualmente la asociación directa a un `Gateway`, pero pueden ser asociados al `Deployment` y `Service` generado correspondiente. +Esto es fácil de hacer porque [los recursos están generados con etiquetas bien conocidas](https://gateway-api.sigs.k8s.io/geps/gep-1762/#resource-attachment) (`gateway.networking.k8s.io/gateway-name: `) y nombres: -* Gateway: `-` -* Waypoint: `` +* Gateway: `-` +* Waypoint: `` -For example, to deploy a `Gateway` with a `HorizontalPodAutoscaler` and `PodDisruptionBudget`: +Por ejemplo, para desplegar un `Gateway` con un `HorizontalPodAutoscaler` y un `PodDisruptionBudget`: {{< text yaml >}} apiVersion: gateway.networking.k8s.io/v1 @@ -322,8 +322,8 @@ kind: HorizontalPodAutoscaler metadata: name: gateway spec: - # Match the generated Deployment by reference - # Note: Do not use `kind: Gateway`. + # Coincide con el Deployment generado por referencia + # Nota: No use `kind: Gateway`. scaleTargetRef: apiVersion: apps/v1 kind: Deployment @@ -345,20 +345,20 @@ metadata: spec: minAvailable: 1 selector: - # Match the generated Deployment by label + # Coincide con el Deployment generado por etiqueta matchLabels: gateway.networking.k8s.io/gateway-name: gateway {{< /text >}} -### Manual deployment +### Despliegue manual -If you do not want to have an automated deployment, a `Deployment` and `Service` can be [configured manually](/es/docs/setup/additional-setup/gateway/). +Si no quieres tener un despliegue automático, un `Deployment` y un `Service` pueden ser [configurados manualmente](/es/docs/setup/additional-setup/gateway/). -When this option is done, you will need to manually link the `Gateway` to the `Service`, as well as keep their port configuration in sync. +Cuando esta opción se realiza, necesitarás enlazar manualmente el `Gateway` al `Service`, así como mantener la configuración de sus puertos sincronizada. -In order to support Policy Attachment, e.g. when you're using the [`targetRef`](/es/docs/reference/config/type/workload-selector/#PolicyTargetReference) field on an AuthorizationPolicy, you will also need to reference the name of your `Gateway` by adding the following label to your gateway pod: `gateway.networking.k8s.io/gateway-name: `. +Para soportar la asociación de políticas, por ejemplo, cuando estás usando el campo [`targetRef`](/es/docs/reference/config/type/workload-selector/#PolicyTargetReference) en una AuthorizationPolicy, también necesitarás referenciar el nombre de tu `Gateway` añadiendo la siguiente etiqueta a tu pod de gateway: `gateway.networking.k8s.io/gateway-name: `. -To link a `Gateway` to a `Service`, configure the `addresses` field to point to a **single** `Hostname`. +Para enlazar un `Gateway` a un `Service`, configura el campo `addresses` para apuntar a un **único** `Hostname`. {{< text yaml >}} apiVersion: gateway.networking.k8s.io/v1 @@ -372,12 +372,12 @@ spec: ... {{< /text >}} -## Mesh Traffic +## Tráfico de Mesh -The Gateway API can also be used to configure mesh traffic. -This is done by configuring the `parentRef` to point to a service, instead of a gateway. +El Gateway API también puede ser usado para configurar el tráfico de mesh. +Esto se hace configurando el `parentRef` para apuntar a un servicio, en lugar de un gateway. -For example, to add a header on all calls to an in-cluster `Service` named `example`: +Por ejemplo, para añadir un encabezado a todas las llamadas a un servicio en clúster `example`: {{< text yaml >}} apiVersion: gateway.networking.k8s.io/v1 @@ -401,11 +401,11 @@ spec: port: 80 {{< /text >}} -More details and examples can be found in other [traffic management tasks](/es/docs/tasks/traffic-management/). +Más detalles y ejemplos pueden ser encontrados en otras [tareas de gestión de tráfico](/es/docs/tasks/traffic-management/). -## Cleanup +## Limpieza -1. Remove the `httpbin` sample and gateway: +1. Elimina la muestra `httpbin` y el gateway: {{< text bash >}} $ kubectl delete -f @samples/httpbin/httpbin.yaml@ @@ -414,14 +414,14 @@ More details and examples can be found in other [traffic management tasks](/es/d $ kubectl delete ns istio-ingress {{< /text >}} -1. Uninstall Istio: +1. Desinstala Istio: {{< text bash >}} $ istioctl uninstall -y --purge $ kubectl delete ns istio-system {{< /text >}} -1. Remove the Gateway API CRDs if they are no longer needed: +1. Elimina los CRDs del Gateway API si ya no son necesarios: {{< text bash >}} $ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref={{< k8s_gateway_api_version >}}" | kubectl delete -f - diff --git a/content/es/docs/tasks/traffic-management/ingress/ingress-control/index.md b/content/es/docs/tasks/traffic-management/ingress/ingress-control/index.md index 691e40239434e..2a67e40026d2b 100644 --- a/content/es/docs/tasks/traffic-management/ingress/ingress-control/index.md +++ b/content/es/docs/tasks/traffic-management/ingress/ingress-control/index.md @@ -42,11 +42,11 @@ Esta tarea describe cómo configurar Istio para exponer un service fuera de la s Tenga en cuenta que, para el propósito de este documento, que muestra cómo usar un gateway para controlar el tráfico de entrada en su "cluster de Kubernetes", puede iniciar el service `httpbin` con o sin - la inyección de sidecar habilitada (es decir, el service de destino puede estar dentro o fuera de la malla de Istio). + la inyección de sidecar habilitada (es decir, el service de destino puede estar dentro o fuera de la mesh de Istio). ## Configuración de la entrada usando un gateway -Un `Gateway` de entrada describe un balanceador de carga que opera en el borde de la malla y que recibe conexiones HTTP/TCP entrantes. +Un `Gateway` de entrada describe un balanceador de carga que opera en el borde de la mesh y que recibe conexiones HTTP/TCP entrantes. Configura los puertos expuestos, protocolos, etc. pero, a diferencia de los [Recursos Ingress de Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/), no incluye ninguna configuración de enrutamiento de tráfico. El enrutamiento de tráfico para el tráfico de entrada se configura @@ -117,7 +117,7 @@ especifica que solo se permiten las solicitudes a través de su `httpbin-gateway Todas las demás solicitudes externas serán rechazadas con una respuesta 404. {{< warning >}} -Las solicitudes internas de otros services en la malla no están sujetas a estas reglas +Las solicitudes internas de otros services en la mesh no están sujetas a estas reglas sino que, en su lugar, se establecerán por defecto en el enrutamiento round-robin. Para aplicar estas reglas también a las llamadas internas, puede agregar el valor especial `mesh` a la lista de `gateways`. Dado que el hostname interno para el service es probablemente diferente (por ejemplo, `httpbin.default.svc.cluster.local`) del externo, diff --git a/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md b/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md index 643bf8f013966..353cd349a07ae 100644 --- a/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md +++ b/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md @@ -7,8 +7,8 @@ owner: istio/wg-networking-maintainers test: yes --- -En un despliegue de malla de Istio regular, la terminación TLS para las solicitudes descendentes se realiza en el Ingress Gateway. -Aunque esto satisface la mayoría de los casos de uso, para algunos (como un API Gateway en la malla) el Ingress Gateway no es necesariamente necesario. Esta tarea muestra cómo eliminar el salto adicional introducido por el Ingress Gateway de Istio y permitir que el sidecar de Envoy, que se ejecuta junto con la aplicación, realice la terminación TLS para las solicitudes que provienen de fuera de la service mesh. +En un despliegue de meshde Istio regular, la terminación TLS para las solicitudes descendentes se realiza en el Ingress Gateway. +Aunque esto satisface la mayoría de los casos de uso, para algunos (como un API Gateway en la mesh) el Ingress Gateway no es necesariamente necesario. Esta tarea muestra cómo eliminar el salto adicional introducido por el Ingress Gateway de Istio y permitir que el sidecar de Envoy, que se ejecuta junto con la aplicación, realice la terminación TLS para las solicitudes que provienen de fuera de la service mesh. El service HTTPS de ejemplo utilizado para esta tarea es un service [httpbin](https://httpbin.org) simple. En los siguientes pasos, desplegará el service httpbin dentro de su service mesh y lo configurará. @@ -34,7 +34,7 @@ En los siguientes pasos, desplegará el service httpbin dentro de su service mes ## Habilitar mTLS global -Aplique la siguiente política `PeerAuthentication` para requerir tráfico mTLS para todos los workloads en la malla. +Aplique la siguiente política `PeerAuthentication` para requerir tráfico mTLS para todos los workloads en la mesh. {{< text bash >}} $ kubectl -n test apply -f - <}} -### Verificar la conectividad de malla interna en el puerto 8080 +### Verificar la conectividad de meshinterna en el puerto 8080 {{< text bash >}} $ export INTERNAL_CLIENT=$(kubectl -n test get pod -l app=curl -o jsonpath={.items..metadata.name}) @@ -255,7 +255,7 @@ content-length: 0 x-envoy-upstream-service-time: 5 {{< /text >}} -### Verificar la conectividad de malla externa a interna en el puerto 8443 +### Verificar la conectividad de meshexterna a interna en el puerto 8443 Para verificar el tráfico mTLS desde un cliente externo, primero copie el certificado de CA y el certificado/clave de cliente al cliente curl que se ejecuta en el namespace predeterminado. diff --git a/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md b/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md index a9916628efaf1..66e0def537809 100644 --- a/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md +++ b/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md @@ -1,6 +1,6 @@ --- -title: Secure Gateways -description: Expose a service outside of the service mesh over TLS or mTLS. +title: Gateways Seguros +description: Expone un servicio fuera del service mesh sobre TLS o mTLS. weight: 20 aliases: - /docs/tasks/traffic-management/ingress/secure-ingress-sds/ @@ -10,54 +10,54 @@ owner: istio/wg-networking-maintainers test: yes --- -The [Control Ingress Traffic task](/es/docs/tasks/traffic-management/ingress/ingress-control) -describes how to configure an ingress gateway to expose an HTTP service to external traffic. -This task shows how to expose a secure HTTPS service using either simple or mutual TLS. +La [tarea de Control de Tráfico de Ingreso](/es/docs/tasks/traffic-management/ingress/ingress-control) +describe cómo configurar un gateway de ingreso para exponer un servicio HTTP al tráfico externo. +Esta tarea muestra cómo exponer un servicio HTTPS seguro usando TLS simple o mutuo. {{< boilerplate gateway-api-support >}} -## Before you begin +## Antes de comenzar -* Setup Istio by following the instructions in the [Installation guide](/es/docs/setup/). +* Configura Istio siguiendo las instrucciones en la [Guía de instalación](/es/docs/setup/). -* Start the [httpbin]({{< github_tree >}}/samples/httpbin) sample: +* Inicia la muestra [httpbin]({{< github_tree >}}/samples/httpbin): {{< text bash >}} $ kubectl apply -f @samples/httpbin/httpbin.yaml@ {{< /text >}} -* For macOS users, verify that you use `curl` compiled with the [LibreSSL](http://www.libressl.org) library: +* Para usuarios de macOS, verifica que uses `curl` compilado con la biblioteca [LibreSSL](http://www.libressl.org): {{< text bash >}} $ curl --version | grep LibreSSL curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0 {{< /text >}} - If the previous command outputs a version of LibreSSL as shown, your `curl` command - should work correctly with the instructions in this task. Otherwise, try - a different implementation of `curl`, for example on a Linux machine. + Si el comando anterior produce una versión de LibreSSL como se muestra, tu comando `curl` + debería funcionar correctamente con las instrucciones en esta tarea. De lo contrario, intenta + una implementación diferente de `curl`, por ejemplo en una máquina Linux. -## Generate client and server certificates and keys +## Generar certificados y claves de cliente y servidor -This task requires several sets of certificates and keys which are used in the following examples. -You can use your favorite tool to create them or use the commands below to generate them using +Esta tarea requiere varios conjuntos de certificados y claves que se usan en los siguientes ejemplos. +Puedes usar tu herramienta favorita para crearlos o usar los comandos a continuación para generarlos usando [openssl](https://man.openbsd.org/openssl.1). -1. Create a root certificate and private key to sign the certificates for your services: +1. Crea un certificado raíz y una clave privada para firmar los certificados para tus servicios: {{< text bash >}} $ mkdir example_certs1 $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example_certs1/example.com.key -out example_certs1/example.com.crt {{< /text >}} -1. Generate a certificate and a private key for `httpbin.example.com`: +1. Genera un certificado y una clave privada para `httpbin.example.com`: {{< text bash >}} $ openssl req -out example_certs1/httpbin.example.com.csr -newkey rsa:2048 -nodes -keyout example_certs1/httpbin.example.com.key -subj "/CN=httpbin.example.com/O=httpbin organization" $ openssl x509 -req -sha256 -days 365 -CA example_certs1/example.com.crt -CAkey example_certs1/example.com.key -set_serial 0 -in example_certs1/httpbin.example.com.csr -out example_certs1/httpbin.example.com.crt {{< /text >}} -1. Create a second set of the same kind of certificates and keys: +1. Crea un segundo conjunto del mismo tipo de certificados y claves: {{< text bash >}} $ mkdir example_certs2 @@ -66,14 +66,14 @@ You can use your favorite tool to create them or use the commands below to gener $ openssl x509 -req -sha256 -days 365 -CA example_certs2/example.com.crt -CAkey example_certs2/example.com.key -set_serial 0 -in example_certs2/httpbin.example.com.csr -out example_certs2/httpbin.example.com.crt {{< /text >}} -1. Generate a certificate and a private key for `helloworld.example.com`: +1. Genera un certificado y una clave privada para `helloworld.example.com`: {{< text bash >}} $ openssl req -out example_certs1/helloworld.example.com.csr -newkey rsa:2048 -nodes -keyout example_certs1/helloworld.example.com.key -subj "/CN=helloworld.example.com/O=helloworld organization" $ openssl x509 -req -sha256 -days 365 -CA example_certs1/example.com.crt -CAkey example_certs1/example.com.key -set_serial 1 -in example_certs1/helloworld.example.com.csr -out example_certs1/helloworld.example.com.crt {{< /text >}} -1. Generate a client certificate and private key: +1. Genera un certificado de cliente y una clave privada: {{< text bash >}} $ openssl req -out example_certs1/client.example.com.csr -newkey rsa:2048 -nodes -keyout example_certs1/client.example.com.key -subj "/CN=client.example.com/O=client organization" @@ -81,7 +81,7 @@ You can use your favorite tool to create them or use the commands below to gener {{< /text >}} {{< tip >}} -You can confirm that you have all of the needed files by running the following command: +Puedes confirmar que tienes todos los archivos necesarios ejecutando el siguiente comando: {{< text bash >}} $ ls example_cert* @@ -98,9 +98,9 @@ example.com.key httpbin.example.com.csr {{< /tip >}} -### Configure a TLS ingress gateway for a single host +### Configurar un gateway de ingreso de TLS para un solo host -1. Create a secret for the ingress gateway: +1. Crea un secreto para el gateway de ingreso: {{< text bash >}} $ kubectl create -n istio-system secret tls httpbin-credential \ @@ -108,15 +108,15 @@ example.com.key httpbin.example.com.csr --cert=example_certs1/httpbin.example.com.crt {{< /text >}} -1. Configure the ingress gateway: +1. Configura el gateway de ingreso: {{< tabset category-name="config-api" >}} {{< tab name="Istio APIs" category-value="istio-apis" >}} -First, define a gateway with a `servers:` section for port 443, and specify values for -`credentialName` to be `httpbin-credential`. The values are the same as the -secret's name. The TLS mode should have the value of `SIMPLE`. +Primero, define un gateway con una sección `servers:` para el puerto 443, y especifica valores para +`credentialName` para ser `httpbin-credential`. Los valores son los mismos que el +nombre del secreto. El modo TLS debe tener el valor de `SIMPLE`. {{< text bash >}} $ cat <}} -Next, configure the gateway's ingress traffic routes by defining a corresponding +Luego, configura las rutas de tráfico de ingreso del gateway definiendo un correspondiente virtual service: {{< text bash >}} @@ -168,14 +168,14 @@ spec: EOF {{< /text >}} -Finally, follow [these instructions](/es/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports) -to set the `INGRESS_HOST` and `SECURE_INGRESS_PORT` variables for accessing the gateway. +Finalmente, sigue [estas instrucciones](/es/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports) +para establecer las variables `INGRESS_HOST` y `SECURE_INGRESS_PORT` para acceder al gateway. {{< /tab >}} {{< tab name="Gateway API" category-value="gateway-api" >}} -First, create a [Kubernetes Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Gateway): +Primero, crea un [Kubernetes Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Gateway): {{< text bash >}} $ cat <}} -Next, configure the gateway's ingress traffic routes by defining a corresponding `HTTPRoute`: +Luego, configura las rutas de tráfico de ingreso del gateway definiendo un correspondiente `HTTPRoute`: {{< text bash >}} $ cat <}} -Finally, get the gateway address and port from the `Gateway` resource: +Finalmente, obtén la dirección y el puerto del gateway desde el recurso `Gateway`: {{< text bash >}} $ kubectl wait --for=condition=programmed gtw mygateway -n istio-system @@ -243,7 +243,7 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw mygateway -n istio-system -o json {{< /tabset >}} -3) Send an HTTPS request to access the `httpbin` service through HTTPS: +3) Envía una solicitud HTTPS para acceder al servicio `httpbin` a través de HTTPS: {{< text bash >}} $ curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ @@ -255,10 +255,10 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw mygateway -n istio-system -o json ... {{< /text >}} - The `httpbin` service will return the [418 I'm a Teapot](https://tools.ietf.org/html/rfc7168#section-2.3.3) code. + El servicio `httpbin` devolverá el código [418 I'm a Teapot](https://tools.ietf.org/html/rfc7168#section-2.3.3). -1) Change the gateway's credentials by deleting the gateway's secret and then recreating it using - different certificates and keys: +1) Cambia las credenciales del gateway eliminando el secreto del gateway y luego recreándolo usando + diferentes certificados y claves: {{< text bash >}} $ kubectl -n istio-system delete secret httpbin-credential @@ -267,7 +267,7 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw mygateway -n istio-system -o json --cert=example_certs2/httpbin.example.com.crt {{< /text >}} -1) Access the `httpbin` service with `curl` using the new certificate chain: +1) Accede al servicio `httpbin` con `curl` usando la nueva cadena de certificados: {{< text bash >}} $ curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ @@ -279,12 +279,11 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw mygateway -n istio-system -o json ... {{< /text >}} -1) If you try to access `httpbin` using the previous certificate chain, the attempt now fails: +1) Si intentas acceder a `httpbin` usando la cadena de certificados anterior, el intento ahora falla: {{< text bash >}} $ curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ --cacert example_certs1/example.com.crt "https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418" - ... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): @@ -292,14 +291,14 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw mygateway -n istio-system -o json * curl: (35) error:04FFF06A:rsa routines:CRYPTO_internal:block type is not 01 {{< /text >}} -### Configure a TLS ingress gateway for multiple hosts +### Configurar un gateway de ingreso de TLS para múltiples hosts -You can configure an ingress gateway for multiple hosts, -`httpbin.example.com` and `helloworld.example.com`, for example. The ingress gateway -is configured with unique credentials corresponding to each host. +Puedes configurar un gateway de ingreso para múltiples hosts, +`httpbin.example.com` y `helloworld.example.com`, por ejemplo. El gateway de ingreso +está configurado con credenciales únicas correspondientes a cada host. -1. Restore the `httpbin` credentials from the previous example by deleting and recreating the secret - with the original certificates and keys: +1. Restaura las credenciales de `httpbin` del ejemplo anterior eliminando y recreando el secreto + con los certificados y claves originales: {{< text bash >}} $ kubectl -n istio-system delete secret httpbin-credential @@ -308,14 +307,14 @@ is configured with unique credentials corresponding to each host. --cert=example_certs1/httpbin.example.com.crt {{< /text >}} -1. Start the `helloworld-v1` sample: +1. Inicia la muestra `helloworld-v1`: {{< text bash >}} $ kubectl apply -f @samples/helloworld/helloworld.yaml@ -l service=helloworld $ kubectl apply -f @samples/helloworld/helloworld.yaml@ -l version=v1 {{< /text >}} -1. Create a `helloworld-credential` secret: +1. Crea un secreto `helloworld-credential`: {{< text bash >}} $ kubectl create -n istio-system secret tls helloworld-credential \ @@ -323,15 +322,14 @@ is configured with unique credentials corresponding to each host. --cert=example_certs1/helloworld.example.com.crt {{< /text >}} -1. Configure the ingress gateway with hosts `httpbin.example.com` and `helloworld.example.com`: +1. Configura el gateway de ingreso con hosts `httpbin.example.com` y `helloworld.example.com`: {{< tabset category-name="config-api" >}} {{< tab name="Istio APIs" category-value="istio-apis" >}} -Define a gateway with two server sections for port 443. Set the value of -`credentialName` on each port to `httpbin-credential` and `helloworld-credential` -respectively. Set TLS mode to `SIMPLE`. +Define un gateway con dos secciones de servidor para el puerto 443. Establece el valor de +`credentialName` en cada puerto a `httpbin-credential` y `helloworld-credential` respectivamente. Establece el modo TLS a `SIMPLE`. {{< text bash >}} $ cat <}} -Configure the gateway's traffic routes by defining a corresponding virtual service. +Configura las rutas de tráfico del gateway definiendo un correspondiente virtual service. {{< text bash >}} $ cat <}} -Configure a `Gateway` with two listeners for port 443. Set the value of -`certificateRefs` on each listener to `httpbin-credential` and `helloworld-credential` -respectively. +Configura un `Gateway` con dos listeners para el puerto 443. Establece el valor de +`certificateRefs` en cada listener a `httpbin-credential` y `helloworld-credential` respectivamente. {{< text bash >}} $ cat <}} -Configure the gateway's traffic routes for the `helloworld` service: +Configura las rutas de tráfico del gateway para el servicio `helloworld`: {{< text bash >}} $ cat <}} -5) Send an HTTPS request to `helloworld.example.com`: +5) Envía una solicitud HTTPS a `helloworld.example.com`: {{< text bash >}} $ curl -v -HHost:helloworld.example.com --resolve "helloworld.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ @@ -476,7 +473,7 @@ EOF ... {{< /text >}} -1) Send an HTTPS request to `httpbin.example.com` and still get [HTTP 418](https://datatracker.ietf.org/doc/html/rfc2324) in return: +1) Envía una solicitud HTTPS a `httpbin.example.com` y aún obtienes [HTTP 418](https://datatracker.ietf.org/doc/html/rfc2324) en retorno: {{< text bash >}} $ curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ @@ -488,12 +485,12 @@ EOF ... {{< /text >}} -### Configure a mutual TLS ingress gateway +### Configurar un gateway de ingreso de TLS mutuo -You can extend your gateway's definition to support [mutual TLS](https://en.wikipedia.org/wiki/Mutual_authentication). +Puedes extender la definición del gateway para soportar [TLS mutuo](https://en.wikipedia.org/wiki/Mutual_authentication). -1. Change the credentials of the ingress gateway by deleting its secret and creating a new one. - The server uses the CA certificate to verify its clients, and we must use the key `ca.crt` to hold the CA certificate. +1. Cambia las credenciales del gateway de ingreso eliminando su secreto y creando uno nuevo. + El servidor usa el certificado de CA para verificar a sus clientes, y debemos usar la clave `ca.crt` para mantener el certificado de CA. {{< text bash >}} $ kubectl -n istio-system delete secret httpbin-credential @@ -506,16 +503,16 @@ You can extend your gateway's definition to support [mutual TLS](https://en.wiki {{< tip >}} {{< boilerplate crl-tip >}} - The credential may also include an [OCSP Staple](https://datatracker.ietf.org/doc/html/rfc6961) using the key `tls.ocsp-staple` which can be specified by an additional argument: `--from-file=tls.ocsp-staple=/some/path/to/your-ocsp-staple.pem`. + El secreto también puede incluir un [OCSP Staple](https://datatracker.ietf.org/doc/html/rfc6961) usando la clave `tls.ocsp-staple` que puede especificarse con un argumento adicional: `--from-file=tls.ocsp-staple=/some/path/to/your-ocsp-staple.pem`. {{< /tip >}} -1. Configure the ingress gateway: +1. Configura el gateway de ingreso: {{< tabset category-name="config-api" >}} {{< tab name="Istio APIs" category-value="istio-apis" >}} -Change the gateway's definition to set the TLS mode to `MUTUAL`. +Cambia la definición del gateway estableciendo el modo TLS a `MUTUAL`. {{< text bash >}} $ cat <}} -Because the Kubernetes Gateway API does not currently support mutual TLS termination in a +Debido a que el Kubernetes Gateway API no soporta actualmente el terminado de TLS mutuo en un [Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Gateway), -we use an Istio-specific option, `gateway.istio.io/tls-terminate-mode: MUTUAL`, -to configure it: +usamos una opción específica de Istio, `gateway.istio.io/tls-terminate-mode: MUTUAL`, +para configurarlo: {{< text bash >}} $ cat <}} -3) Attempt to send an HTTPS request using the prior approach and see how it fails: +3) Intenta enviar una solicitud HTTPS usando el enfoque anterior y verás cómo falla: {{< text bash >}} $ curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ @@ -600,9 +597,9 @@ EOF * OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0 {{< /text >}} -1) Pass a client certificate and private key to `curl` and resend the request. - Pass your client's certificate with the `--cert` flag and your private key - with the `--key` flag to `curl`: +1) Pasa un certificado de cliente y una clave privada a `curl` y vuelve a enviar la solicitud. + Pasa el certificado de su cliente con la bandera `--cert` y su clave privada + con la bandera `--key` a `curl`: {{< text bash >}} $ curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ @@ -617,82 +614,74 @@ EOF ... {{< /text >}} -## More info +## Más información -### Key formats +### Formatos de clave -Istio supports reading a few different Secret formats, to support integration with various tools such as [cert-manager](/es/docs/ops/integrations/certmanager/): +Istio soporta la lectura de varios formatos diferentes de Secret, para soportar la integración con varias herramientas como [cert-manager](/es/docs/ops/integrations/certmanager/): -* A TLS Secret with keys `tls.key` and `tls.crt`, as described above. For mutual TLS, a `ca.crt` key can be used. -* A TLS Secret with keys `tls.key` and `tls.crt`, as described above. For mutual TLS, a separate generic Secret named `-cacert`, with a `cacert` key. For example, `httpbin-credential` has `tls.key` and `tls.crt`, and `httpbin-credential-cacert` has `cacert`. -* A generic Secret with keys `key` and `cert`. For mutual TLS, a `cacert` key can be used. -* A generic Secret with keys `key` and `cert`. For mutual TLS, a separate generic Secret named `-cacert`, with a `cacert` key. For example, `httpbin-credential` has `key` and `cert`, and `httpbin-credential-cacert` has `cacert`. -* The `cacert` key value can be a CA bundle consisting of concatenated individual CA certificates. +* Un secreto TLS con claves `tls.key` y `tls.crt`, como se describe anteriormente. Para TLS mutuo, una clave `ca.crt` puede usarse. +* Un secreto TLS con claves `tls.key` y `tls.crt`, como se describe anteriormente. Para TLS mutuo, un secreto genérico separado llamado `-cacert`, con una clave `cacert`. Por ejemplo, `httpbin-credential` tiene `tls.key` y `tls.crt`, y `httpbin-credential-cacert` tiene `cacert`. +* Un secreto genérico con claves `key` y `cert`. Para TLS mutuo, una clave `cacert` puede usarse. +* Un secreto genérico con claves `key` y `cert`. Para TLS mutuo, un secreto genérico separado llamado `-cacert`, con una clave `cacert`. Por ejemplo, `httpbin-credential` tiene `key` y `cert`, y `httpbin-credential-cacert` tiene `cacert`. +* El valor de la clave `cacert` puede ser un paquete de CA consistente en la concatenación de certificados de CA individuales. -### SNI Routing +### Enrutamiento de SNI -An HTTPS `Gateway` will perform [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) matching against its configured host(s) -before forwarding a request, which may cause some requests to fail. -See [configuring SNI routing](/es/docs/ops/common-problems/network-issues/#configuring-sni-routing-when-not-sending-sni) for details. +Un `Gateway` HTTPS realizará [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) coincidencia contra sus hosts configurados +antes de reenviar una solicitud, lo que puede causar que algunas solicitudes fallen. +Ver [configuración de enrutamiento de SNI](/es/docs/ops/common-problems/network-issues/#configuring-sni-routing-when-not-sending-sni) para más detalles. -## Troubleshooting +## Solución de problemas -* Inspect the values of the `INGRESS_HOST` and `SECURE_INGRESS_PORT` environment - variables. Make sure they have valid values, according to the output of the - following commands: +* Inspecciona los valores de las variables de entorno `INGRESS_HOST` y `SECURE_INGRESS_PORT`. Asegúrate de que tengan valores válidos, según la salida de los siguientes comandos: {{< text bash >}} $ kubectl get svc -n istio-system $ echo "INGRESS_HOST=$INGRESS_HOST, SECURE_INGRESS_PORT=$SECURE_INGRESS_PORT" {{< /text >}} -* Make sure the value of `INGRESS_HOST` is an IP address. In some cloud platforms, e.g., AWS, you may - get a domain name, instead. This task expects an IP address, so you will need to convert it with commands - similar to the following: +* Asegúrate de que el valor de `INGRESS_HOST` sea una dirección IP. En algunas plataformas en la nube, como AWS, podrías + obtener un nombre de dominio en su lugar. Esta tarea espera una dirección IP, por lo que necesitarás convertirla con comandos + similares a los siguientes: {{< text bash >}} $ nslookup ab52747ba608744d8afd530ffd975cbf-330887905.us-east-1.elb.amazonaws.com $ export INGRESS_HOST=3.225.207.109 {{< /text >}} -* Check the log of the gateway controller for error messages: +* Verifica el log del controlador de gateway por mensajes de error: {{< text syntax=bash snip_id=none >}} $ kubectl logs -n istio-system {{< /text >}} -* If using macOS, verify you are using `curl` compiled with the [LibreSSL](http://www.libressl.org) - library, as described in the [Before you begin](#before-you-begin) section. +* Si estás usando macOS, verifica que uses `curl` compilado con la biblioteca [LibreSSL](http://www.libressl.org), + como se describe en la sección [Antes de comenzar](#antes-de-comenzar) anterior. -* Verify that the secrets are successfully created in the `istio-system` - namespace: +* Verifica que los secretos se hayan creado correctamente en el namespace `istio-system`: {{< text bash >}} $ kubectl -n istio-system get secrets {{< /text >}} - `httpbin-credential` and `helloworld-credential` should show in the secrets - list. + `httpbin-credential` y `helloworld-credential` deberían aparecer en la lista de secretos. -* Check the logs to verify that the ingress gateway agent has pushed the - key/certificate pair to the ingress gateway: +* Verifica los logs para asegurarte de que el agente de gateway de ingreso haya enviado + la pareja clave/certificado al gateway de ingreso: {{< text syntax=bash snip_id=none >}} $ kubectl logs -n istio-system {{< /text >}} - The log should show that the `httpbin-credential` secret was added. If using mutual - TLS, then the `httpbin-credential-cacert` secret should also appear. - Verify the log shows that the gateway agent receives SDS requests from the - ingress gateway, that the resource's name is `httpbin-credential`, and that the ingress gateway - obtained the key/certificate pair. If using mutual TLS, the log should show - key/certificate was sent to the ingress gateway, - that the gateway agent received the SDS request with the `httpbin-credential-cacert` - resource name, and that the ingress gateway obtained the root certificate. + El log debería mostrar que el secreto `httpbin-credential` fue añadido. Si usas TLS mutuo, entonces el secreto `httpbin-credential-cacert` también debería aparecer. + Verifica que el log muestre que el agente de gateway recibe solicitudes SDS del gateway de ingreso, que el nombre del recurso es `httpbin-credential`, y que el gateway de ingreso obtiene la pareja clave/certificado. Si usas TLS mutuo, el log debería mostrar + clave/certificado fue enviado al gateway de ingreso, + que el agente de gateway recibió la solicitud SDS con el nombre de recurso `httpbin-credential-cacert`, y que el gateway de ingreso obtuvo el certificado raíz. -## Cleanup +## Limpieza -1. Delete the gateway configuration and routes: +1. Elimina la configuración del gateway y las rutas: {{< tabset category-name="config-api" >}} @@ -716,14 +705,14 @@ $ kubectl delete httproute httpbin helloworld {{< /tabset >}} -2) Delete the secrets, certificates and keys: +2) Elimina los secretos, certificados y claves: {{< text bash >}} $ kubectl delete -n istio-system secret httpbin-credential helloworld-credential $ rm -rf ./example_certs1 ./example_certs2 {{< /text >}} -1) Shutdown the `httpbin` and `helloworld` services: +1) Apaga los servicios `httpbin` y `helloworld`: {{< text bash >}} $ kubectl delete -f samples/httpbin/httpbin.yaml diff --git a/content/es/docs/tasks/traffic-management/mirroring/index.md b/content/es/docs/tasks/traffic-management/mirroring/index.md index 08f25685577cc..799f122d26fe2 100644 --- a/content/es/docs/tasks/traffic-management/mirroring/index.md +++ b/content/es/docs/tasks/traffic-management/mirroring/index.md @@ -1,28 +1,28 @@ --- title: Mirroring -description: This task demonstrates the traffic mirroring/shadowing capabilities of Istio. +description: Esta tarea demuestra las capacidades de mirroring/shadowing de tráfico de Istio. weight: 60 keywords: [traffic-management,mirroring] owner: istio/wg-networking-maintainers test: yes --- -This task demonstrates the traffic mirroring capabilities of Istio. +Esta tarea demuestra las capacidades de mirroring de tráfico de Istio. -Traffic mirroring, also called shadowing, is a powerful concept that allows -feature teams to bring changes to production with as little risk as possible. -Mirroring sends a copy of live traffic to a mirrored service. The mirrored -traffic happens out of band of the critical request path for the primary service. +El mirroring de tráfico, también llamado shadowing, es un concepto poderoso que permite +a los equipos de características llevar cambios a producción con el menor riesgo posible. +El mirroring envía una copia del tráfico en vivo a un servicio espejo. El tráfico +espejo ocurre fuera de banda del camino de solicitud crítico para el servicio primario. -In this task, you will first force all traffic to `v1` of a test service. Then, -you will apply a rule to mirror a portion of traffic to `v2`. +En esta tarea, primero forzarás todo el tráfico a `v1` de un servicio de prueba. Luego, +aplicarás una regla para hacer espejo de una porción del tráfico a `v2`. {{< boilerplate gateway-api-support >}} -## Before you begin +## Antes de comenzar -1. Set up Istio by following the [Installation guide](/es/docs/setup/). -1. Start by deploying two versions of the [httpbin]({{< github_tree >}}/samples/httpbin) service that have access logging enabled: +1. Configura Istio siguiendo la [Guía de instalación](/es/docs/setup/). +1. Comienza desplegando dos versiones del servicio [httpbin]({{< github_tree >}}/samples/httpbin) que tienen el registro de acceso habilitado: 1. Deploy `httpbin-v1`: @@ -84,7 +84,7 @@ you will apply a rule to mirror a portion of traffic to `v2`. EOF {{< /text >}} - 1. Deploy the `httpbin` Kubernetes service: + 1. Deploy el servicio Kubernetes `httpbin`: {{< text bash >}} $ kubectl create -f - <}} -1. Deploy the `curl` workload you'll use to send requests to the `httpbin` service: +1. Despliega el `curl` workload que usarás para enviar solicitudes al servicio `httpbin`: {{< text bash >}} $ cat <}} -## Creating a default routing policy +## Creando una política de enrutamiento por defecto -By default Kubernetes load balances across both versions of the `httpbin` service. -In this step, you will change that behavior so that all traffic goes to `v1`. +Por defecto, Kubernetes balancea el tráfico entre ambas versiones del servicio `httpbin`. +En este paso, cambiarás este comportamiento para que todo el tráfico vaya a `v1`. -1. Create a default route rule to route all traffic to `v1` of the service: +1. Crea una regla de enrutamiento por defecto para enrutar todo el tráfico a `v1` del servicio: {{< tabset category-name="config-api" >}} @@ -224,7 +224,7 @@ In this step, you will change that behavior so that all traffic goes to `v1`. {{< /tabset >}} -1. Now, with all traffic directed to `httpbin:v1`, send a request to the service: +1. Ahora, con todo el tráfico dirigido a `httpbin:v1`, envía una solicitud al servicio: {{< text bash json >}} $ kubectl exec deploy/curl -c curl -- curl -sS http://httpbin:8000/headers @@ -244,7 +244,7 @@ In this step, you will change that behavior so that all traffic goes to `v1`. } {{< /text >}} -1. Check the logs from `httpbin-v1` and `httpbin-v2` pods. You should see access log entries for `v1` and none for `v2`: +1. Verifica los registros de los pods `httpbin-v1` y `httpbin-v2`. Deberías ver entradas de registro para `v1` y ninguna para `v2`: {{< text bash >}} $ kubectl logs deploy/httpbin-v1 -c httpbin @@ -256,9 +256,9 @@ In this step, you will change that behavior so that all traffic goes to `v1`. {{< /text >}} -## Mirroring traffic to `httpbin-v2` +## Mirando tráfico a `httpbin-v2` -1. Change the route rule to mirror traffic to `httpbin-v2`: +1. Cambia la regla de enrutamiento para hacer espejo del tráfico a `httpbin-v2`: {{< tabset category-name="config-api" >}} @@ -287,17 +287,17 @@ In this step, you will change that behavior so that all traffic goes to `v1`. EOF {{< /text >}} - This route rule sends 100% of the traffic to `v1`. The last stanza specifies - that you want to mirror (i.e., also send) 100% of the same traffic to the - `httpbin:v2` service. When traffic gets mirrored, - the requests are sent to the mirrored service with their Host/Authority headers - appended with `-shadow`. For example, `cluster-1` becomes `cluster-1-shadow`. + Esta regla de enrutamiento envía el 100% del tráfico a `v1`. La última estrofa especifica + que quieres hacer espejo (es decir, también enviar) el 100% del mismo tráfico al + servicio `httpbin:v2`. Cuando el tráfico se espeja, + las solicitudes se envían al servicio espejo con sus encabezados Host/Authority + añadidos con `-shadow`. Por ejemplo, `cluster-1` se convierte en `cluster-1-shadow`. - Also, it is important to note that these requests are mirrored as "fire and - forget", which means that the responses are discarded. + También es importante tener en cuenta que estas solicitudes se espejan como "fire and + forget", lo que significa que las respuestas se descartan. - You can use the `value` field under the `mirrorPercentage` field to mirror a fraction of the traffic, - instead of mirroring all requests. If this field is absent, all traffic will be mirrored. + Puedes usar el campo `value` bajo el campo `mirrorPercentage` para hacer espejo de una fracción del tráfico, + en lugar de espejar todas las solicitudes. Si este campo está ausente, todo el tráfico se espejará. {{< /tab >}} @@ -328,27 +328,27 @@ In this step, you will change that behavior so that all traffic goes to `v1`. EOF {{< /text >}} - This route rule sends 100% of the traffic to `v1`. The `RequestMirror` filter - specifies that you want to mirror (i.e., also send) 100% of the same traffic to the - `httpbin:v2` service. When traffic gets mirrored, - the requests are sent to the mirrored service with their Host/Authority headers - appended with `-shadow`. For example, `cluster-1` becomes `cluster-1-shadow`. + Esta regla de enrutamiento envía el 100% del tráfico a `v1`. El filtro `RequestMirror` + especifica que quieres hacer espejo (es decir, también enviar) el 100% del mismo tráfico al + servicio `httpbin:v2`. Cuando el tráfico se espeja, + las solicitudes se envían al servicio espejo con sus encabezados Host/Authority + añadidos con `-shadow`. Por ejemplo, `cluster-1` se convierte en `cluster-1-shadow`. - Also, it is important to note that these requests are mirrored as "fire and - forget", which means that the responses are discarded. + También es importante tener en cuenta que estas solicitudes se espejan como "fire and + forget", lo que significa que las respuestas se descartan. {{< /tab >}} {{< /tabset >}} -1. Send the traffic: +1. Envía el tráfico: {{< text bash >}} $ kubectl exec deploy/curl -c curl -- curl -sS http://httpbin:8000/headers {{< /text >}} - Now, you should see access logging for both `v1` and `v2`. The access logs - created in `v2` are the mirrored requests that are actually going to `v1`. + Ahora, deberías ver registros de acceso para ambos `v1` y `v2`. Los registros de acceso + creados en `v2` son las solicitudes espejadas que realmente van a `v1`. {{< text bash >}} $ kubectl logs deploy/httpbin-v1 -c httpbin @@ -361,9 +361,9 @@ In this step, you will change that behavior so that all traffic goes to `v1`. 127.0.0.1 - - [07/Mar/2018:19:26:44 +0000] "GET /headers HTTP/1.1" 200 361 "-" "curl/7.35.0" {{< /text >}} -## Cleaning up +## Limpieza -1. Remove the rules: +1. Elimina las reglas: {{< tabset category-name="config-api" >}} @@ -387,7 +387,7 @@ In this step, you will change that behavior so that all traffic goes to `v1`. {{< /tabset >}} -1. Delete `httpbin` and `curl` deployments and `httpbin` service: +1. Elimina los despliegues `httpbin` y `curl` y el servicio `httpbin`: {{< text bash >}} $ kubectl delete deploy httpbin-v1 httpbin-v2 curl diff --git a/content/es/docs/tasks/traffic-management/request-routing/index.md b/content/es/docs/tasks/traffic-management/request-routing/index.md index cda099455b85d..8598c096336bf 100644 --- a/content/es/docs/tasks/traffic-management/request-routing/index.md +++ b/content/es/docs/tasks/traffic-management/request-routing/index.md @@ -1,6 +1,6 @@ --- -title: Request Routing -description: This task shows you how to configure dynamic request routing to multiple versions of a microservice. +title: Enrutamiento de Solicitudes +description: Esta tarea te muestra cómo configurar el enrutamiento dinámico de solicitudes a múltiples versiones de un microservicio. weight: 10 aliases: - /docs/tasks/request-routing.html @@ -9,58 +9,58 @@ owner: istio/wg-networking-maintainers test: yes --- -This task shows you how to route requests dynamically to multiple versions of a -microservice. +Esta tarea te muestra cómo enrutar solicitudes dinámicamente a múltiples versiones de un +microservicio. {{< boilerplate gateway-api-support >}} -## Before you begin +## Antes de comenzar -* Setup Istio by following the instructions in the - [Installation guide](/es/docs/setup/). +* Configura Istio siguiendo las instrucciones en la + [Guía de instalación](/es/docs/setup/). -* Deploy the [Bookinfo](/es/docs/examples/bookinfo/) sample application. +* Despliega la aplicación de ejemplo [Bookinfo](/es/docs/examples/bookinfo/). -* Review the [Traffic Management](/es/docs/concepts/traffic-management) concepts doc. +* Revisa el documento de conceptos de [Gestión de Tráfico](/es/docs/concepts/traffic-management). -## About this task +## Acerca de esta tarea -The Istio [Bookinfo](/es/docs/examples/bookinfo/) sample consists of four separate microservices, each with multiple versions. -Three different versions of one of the microservices, `reviews`, have been deployed and are running concurrently. -To illustrate the problem this causes, access the Bookinfo app's `/productpage` in a browser and refresh several times. -The URL is `http://$GATEWAY_URL/productpage`, where `$GATEWAY_URL` is the External IP address of the ingress, as explained in -the [Bookinfo](/es/docs/examples/bookinfo/#determine-the-ingress-ip-and-port) doc. +La muestra de [Bookinfo](/es/docs/examples/bookinfo/) de Istio consiste en cuatro microservicios separados, cada uno con múltiples versiones. +Tres versiones diferentes de uno de los microservicios, `reviews`, han sido desplegadas y están ejecutándose concurrentemente. +Para ilustrar el problema que esto causa, accede a la `/productpage` de la aplicación Bookinfo en un navegador y actualiza varias veces. +La URL es `http://$GATEWAY_URL/productpage`, donde `$GATEWAY_URL` es la dirección IP externa del ingress, como se explica en +la documentación de [Bookinfo](/es/docs/examples/bookinfo/#determine-the-ingress-ip-and-port). -You’ll notice that sometimes the book review output contains star ratings and other times it does not. -This is because without an explicit default service version to route to, Istio routes requests to all available versions -in a round robin fashion. +Notarás que a veces la salida de reseñas del libro contiene calificaciones con estrellas y otras veces no. +Esto es porque sin una versión de servicio predeterminada explícita a la que enrutar, Istio enruta solicitudes a todas las versiones disponibles +de manera round robin. -The initial goal of this task is to apply rules that route all traffic to `v1` (version 1) of the microservices. Later, you -will apply a rule to route traffic based on the value of an HTTP request header. +El objetivo inicial de esta tarea es aplicar reglas que enruten todo el tráfico a `v1` (versión 1) de los microservicios. Más tarde, +aplicarás una regla para enrutar tráfico basado en el valor de una cabecera de solicitud HTTP. -## Route to version 1 +## Enrutar a la versión 1 -To route to one version only, you configure route rules that send traffic to default versions for the microservices. +Para enrutar a solo una versión, configuras reglas de enrutamiento que envían tráfico a versiones predeterminadas para los microservicios. {{< warning >}} -If you haven't already, follow the instructions in [define the service versions](/es/docs/examples/bookinfo/#define-the-service-versions). +Si no lo has hecho ya, sigue las instrucciones en [definir las versiones del servicio](/es/docs/examples/bookinfo/#define-the-service-versions). {{< /warning >}} -1. Run the following command to create the route rules: +1. Ejecuta el siguiente comando para crear las reglas de enrutamiento: {{< tabset category-name="config-api" >}} {{< tab name="Istio APIs" category-value="istio-apis" >}} -Istio uses virtual services to define route rules. -Run the following command to apply virtual services that will route all traffic to `v1` of each microservice: +Istio usa virtual services para definir reglas de enrutamiento. +Ejecuta el siguiente comando para aplicar virtual services que enrutarán todo el tráfico a `v1` de cada microservicio: {{< text bash >}} $ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@ {{< /text >}} -Because configuration propagation is eventually consistent, wait a few seconds -for the virtual services to take effect. +Debido a la consistencia eventual de la configuración, espera unos segundos +para que los virtual services surtan efecto. {{< /tab >}} @@ -89,7 +89,7 @@ EOF {{< /tabset >}} -2) Display the defined routes with the following command: +2) Muestra las rutas definidas con el siguiente comando: {{< tabset category-name="config-api" >}} @@ -143,7 +143,7 @@ $ kubectl get virtualservices -o yaml subset: v1 {{< /text >}} -You can also display the corresponding `subset` definitions with the following command: +También puedes mostrar las definiciones de `subset` correspondientes con el siguiente comando: {{< text bash >}} $ kubectl get destinationrules -o yaml @@ -196,43 +196,42 @@ status: port: 9080 {{< /text >}} -In the resource status, make sure that the `Accepted` condition is `True` for the `reviews` parent. +En el estado del recurso, asegúrate de que la condición `Accepted` sea `True` para el padre `reviews`. {{< /tab >}} {{< /tabset >}} -You have configured Istio to route to the `v1` version of the Bookinfo microservices, -most importantly the `reviews` service version 1. +Has configurado Istio para enrutar a la versión `v1` de los microservicios del Bookinfo, +especialmente la versión del servicio `reviews` 1. -## Test the new routing configuration +## Prueba la nueva configuración de enrutamiento -You can easily test the new configuration by once again refreshing the `/productpage` -of the Bookinfo app in your browser. -Notice that the reviews part of the page displays with no rating stars, no -matter how many times you refresh. This is because you configured Istio to route -all traffic for the reviews service to the version `reviews:v1` and this -version of the service does not access the star ratings service. +Puedes probar fácilmente la nueva configuración refrescando la `/productpage` +de la aplicación Bookinfo en tu navegador. +Observa que la parte de reseñas de la página se muestra sin estrellas, +independientemente de cuántas veces la actualices. Esto es porque configuraste Istio para enrutar +todo el tráfico para el servicio `reviews` a la versión `reviews:v1` y esta +versión del servicio no accede al servicio de calificaciones de estrellas. -You have successfully accomplished the first part of this task: route traffic to one -version of a service. +Has cumplido con la primera parte de esta tarea: enrutar tráfico a una +versión de un servicio. -## Route based on user identity +## Enrutar basado en la identidad del usuario -Next, you will change the route configuration so that all traffic from a specific user -is routed to a specific service version. In this case, all traffic from a user -named Jason will be routed to the service `reviews:v2`. +A continuación, cambiarás la configuración de enrutamiento para que todo el tráfico de un usuario +específico se enrute a una versión de servicio específica. En este caso, todo el tráfico de un usuario +llamado Jason se enrutará al servicio `reviews:v2`. -This example is enabled by the fact that the `productpage` service -adds a custom `end-user` header to all outbound HTTP requests to the reviews -service. +Este ejemplo está habilitado por el hecho de que el servicio `productpage` +añade un encabezado personalizado `end-user` a todas las solicitudes HTTP salientes al servicio `reviews`. -Istio also supports routing based on strongly authenticated JWT on ingress gateway, refer to the -[JWT claim based routing](/es/docs/tasks/security/authentication/jwt-route) for more details. +Istio también admite enrutamiento basado en JWT fuertemente autenticado en el gateway de entrada, consulta la +[Enrutamiento basado en reclamo de JWT](/es/docs/tasks/security/authentication/jwt-route) para más detalles. -Remember, `reviews:v2` is the version that includes the star ratings feature. +Recuerda, `reviews:v2` es la versión que incluye la característica de calificaciones de estrellas. -1. Run the following command to enable user-based routing: +1. Ejecuta el siguiente comando para habilitar el enrutamiento basado en el usuario: {{< tabset category-name="config-api" >}} @@ -242,7 +241,7 @@ Remember, `reviews:v2` is the version that includes the star ratings feature. $ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@ {{< /text >}} -You can confirm the rule is created using the following command: +Puedes confirmar que la regla se ha creado usando el siguiente comando: {{< text bash yaml >}} $ kubectl get virtualservice reviews -o yaml @@ -301,36 +300,36 @@ EOF {{< /tabset >}} -2) On the `/productpage` of the Bookinfo app, log in as user `jason`. +2) En la `/productpage` de la aplicación Bookinfo, inicia sesión como usuario `jason`. - Refresh the browser. What do you see? The star ratings appear next to each - review. + Refresca el navegador. ¿Qué ves? Las calificaciones de estrellas aparecen junto a cada + reseña. -3) Log in as another user (pick any name you wish). +3) Inicia sesión como otro usuario (elige cualquier nombre que desees). - Refresh the browser. Now the stars are gone. This is because traffic is routed - to `reviews:v1` for all users except Jason. + Refresca el navegador. Ahora las estrellas se han ido. Esto es porque el tráfico se enruta + a `reviews:v1` para todos los usuarios excepto Jason. -You have successfully configured Istio to route traffic based on user identity. +Has configurado correctamente Istio para enrutar tráfico basado en la identidad del usuario. -## Understanding what happened +## Entendiendo lo que sucedió -In this task, you used Istio to send 100% of the traffic to the `v1` version -of each of the Bookinfo services. You then set a rule to selectively send traffic -to version `v2` of the `reviews` service based on a custom `end-user` header added -to the request by the `productpage` service. +En esta tarea, usaste Istio para enviar el 100% del tráfico a la versión +`v1` de cada uno de los microservicios del Bookinfo. Luego, estableciste una regla para enviar tráfico +selectivamente a la versión `v2` del servicio `reviews` basado en un encabezado personalizado `end-user` añadido +a la solicitud por el servicio `productpage`. -Note that Kubernetes services, like the Bookinfo ones used in this task, must -adhere to certain restrictions to take advantage of Istio's L7 routing features. -Refer to the [Requirements for Pods and Services](/es/docs/ops/deployment/application-requirements/) for details. +Ten en cuenta que los servicios de Kubernetes, como los del Bookinfo utilizados en esta tarea, deben +cumplir ciertas restricciones para aprovechar las características de enrutamiento L7 de Istio. Consulta la +[Requisitos para Pods y Servicios](/es/docs/ops/deployment/application-requirements/) para más detalles. -In the [traffic shifting](/es/docs/tasks/traffic-management/traffic-shifting) task, you -will follow the same basic pattern you learned here to configure route rules to -gradually send traffic from one version of a service to another. +En la tarea de [desplazamiento de tráfico](/es/docs/tasks/traffic-management/traffic-shifting), seguirás +el mismo patrón básico que aprendiste aquí para configurar reglas de enrutamiento para +enviar gradualmente el tráfico de una versión de un servicio a otra. -## Cleanup +## Limpieza -1. Remove the application route rules: +1. Elimina las reglas de enrutamiento de la aplicación: {{< tabset category-name="config-api" >}} @@ -352,6 +351,6 @@ $ kubectl delete httproute reviews {{< /tabset >}} -2) If you are not planning to explore any follow-on tasks, refer to the - [Bookinfo cleanup](/es/docs/examples/bookinfo/#cleanup) instructions - to shutdown the application. +2) Si no planeas explorar ninguna tarea posterior, consulta las + [Instrucciones de limpieza de Bookinfo](/es/docs/examples/bookinfo/#cleanup) + para apagar la aplicación. diff --git a/content/es/docs/tasks/traffic-management/request-timeouts/index.md b/content/es/docs/tasks/traffic-management/request-timeouts/index.md index 25c83ac4f863b..7e58c3acbcc38 100644 --- a/content/es/docs/tasks/traffic-management/request-timeouts/index.md +++ b/content/es/docs/tasks/traffic-management/request-timeouts/index.md @@ -1,6 +1,6 @@ --- -title: Request Timeouts -description: This task shows you how to set up request timeouts in Envoy using Istio. +title: Timeouts de Solicitud +description: Esta tarea te muestra cómo configurar timeouts de solicitud en Envoy usando Istio. weight: 40 aliases: - /docs/tasks/request-timeouts.html @@ -9,27 +9,27 @@ owner: istio/wg-networking-maintainers test: yes --- -This task shows you how to set up request timeouts in Envoy using Istio. +Esta tarea te muestra cómo configurar timeouts de solicitud en Envoy usando Istio. {{< boilerplate gateway-api-support >}} -## Before you begin +## Antes de comenzar -* Setup Istio by following the instructions in the - [Installation guide](/es/docs/setup/). +* Configura Istio siguiendo las instrucciones en la + [Guía de instalación](/es/docs/setup/). -* Deploy the [Bookinfo](/es/docs/examples/bookinfo/) sample application including the - [service versions](/es/docs/examples/bookinfo/#define-the-service-versions). +* Despliega la aplicación de ejemplo [Bookinfo](/es/docs/examples/bookinfo/) incluyendo las + [versiones del servicio](/es/docs/examples/bookinfo/#define-the-service-versions). -## Request timeouts +## Timeouts de solicitud -A timeout for HTTP requests can be specified using a timeout field in a route rule. -By default, the request timeout is disabled, but in this task you override the `reviews` service -timeout to half a second. -To see its effect, however, you also introduce an artificial 2 second delay in calls -to the `ratings` service. +Un timeout para solicitudes HTTP puede ser especificado usando un campo timeout en una regla de ruta. +Por defecto, el timeout de solicitud está deshabilitado, pero en esta tarea sobrescribes el timeout del servicio `reviews` +a medio segundo. +Para ver su efecto, sin embargo, también introduces un retraso artificial de 2 segundos en las llamadas +al servicio `ratings`. -1. Route requests to v2 of the `reviews` service, i.e., a version that calls the `ratings` service: +1. Ruta las solicitudes al servicio `reviews` v2, es decir, una versión que llama al servicio `ratings`: {{< tabset category-name="config-api" >}} @@ -79,7 +79,7 @@ EOF {{< /tabset >}} -2) Add a 2 second delay to calls to the `ratings` service: +2) Añade un retraso de 2 segundos a las llamadas al servicio `ratings`: {{< tabset category-name="config-api" >}} @@ -111,8 +111,8 @@ EOF {{< tab name="Gateway API" category-value="gateway-api" >}} -Gateway API does not support fault injection yet, so we need to use an Istio `VirtualService` to -add the delay for now: +Gateway API no soporta la inyección de fallos todavía, por lo que necesitamos usar un `VirtualService` de Istio +para añadir el retraso por ahora: {{< text bash >}} $ kubectl apply -f - <}} -3) Open the Bookinfo URL `http://$GATEWAY_URL/productpage` in your browser, where `$GATEWAY_URL` is the External IP address of the ingress, as explained in -the [Bookinfo](/es/docs/examples/bookinfo/#determine-the-ingress-ip-and-port) doc. +3) Abre la URL de Bookinfo `http://$GATEWAY_URL/productpage` en tu navegador, donde `$GATEWAY_URL` es la dirección IP externa del ingress, tal como se explica en +la [Guía de Bookinfo](/es/docs/examples/bookinfo/#determine-the-ingress-ip-and-port) doc. - You should see the Bookinfo application working normally (with ratings stars displayed), - but there is a 2 second delay whenever you refresh the page. + Deberías ver la aplicación Bookinfo funcionando normalmente (con estrellas de valoración mostradas), + pero hay un retraso de 2 segundos cada vez que refrescas la página. -4) Now add a half second request timeout for calls to the `reviews` service: +4) Ahora añade un timeout de solicitud de medio segundo para las llamadas al servicio `reviews`: {{< tabset category-name="config-api" >}} @@ -198,43 +198,43 @@ EOF {{< /tabset >}} -5) Refresh the Bookinfo web page. +5) Refresca la página web de Bookinfo. - You should now see that it returns in about 1 second, instead of 2, and the reviews are unavailable. + Ahora deberías ver que tarda aproximadamente 1 segundo en devolverse, en lugar de 2, y las reseñas no están disponibles. {{< tip >}} - The reason that the response takes 1 second, even though the timeout is configured at half a second, is - because there is a hard-coded retry in the `productpage` service, so it calls the timing out `reviews` service - twice before returning. + La razón por la que la respuesta tarda 1 segundo, incluso aunque el timeout esté configurado a medio segundo, es + porque hay un reintento hardcodeado en el servicio `productpage`, por lo que llama al servicio `reviews` que está tardando + dos veces antes de devolverse. {{< /tip >}} -## Understanding what happened +## Entendiendo lo que ocurrió -In this task, you used Istio to set the request timeout for calls to the `reviews` -microservice to half a second. By default the request timeout is disabled. -Since the `reviews` service subsequently calls the `ratings` service when handling requests, -you used Istio to inject a 2 second delay in calls to `ratings` to cause the -`reviews` service to take longer than half a second to complete and consequently you could see the timeout in action. +En esta tarea, usaste Istio para establecer el timeout de solicitud para las llamadas al servicio `reviews` +a medio segundo. Por defecto, el timeout de solicitud está deshabilitado. +Dado que el servicio `reviews` llama al servicio `ratings` cuando maneja las solicitudes, +usaste Istio para inyectar un retraso de 2 segundos en las llamadas a `ratings` para hacer que +el servicio `reviews` tarde más de medio segundo en completarse y, por lo tanto, pudiste ver el timeout en acción. -You observed that instead of displaying reviews, the Bookinfo product page (which calls the `reviews` service to populate the page) displayed -the message: Sorry, product reviews are currently unavailable for this book. -This was the result of it receiving the timeout error from the `reviews` service. +Observaste que en lugar de mostrar reseñas, la página de producto de Bookinfo (que llama al servicio `reviews` para poblar la página) mostró +el mensaje: Lo sentimos, las reseñas del producto no están disponibles por ahora. +Esto fue el resultado de recibir el error de timeout del servicio `reviews`. -If you examine the [fault injection task](/es/docs/tasks/traffic-management/fault-injection/), you'll find out that the `productpage` -microservice also has its own application-level timeout (3 seconds) for calls to the `reviews` microservice. -Notice that in this task you used an Istio route rule to set the timeout to half a second. -Had you instead set the timeout to something greater than 3 seconds (such as 4 seconds) the timeout -would have had no effect since the more restrictive of the two takes precedence. -More details can be found [here](/es/docs/concepts/traffic-management/#network-resilience-and-testing). +Si examinas la tarea de [inyección de fallos](/es/docs/tasks/traffic-management/fault-injection/), encontrarás que el servicio `productpage` +también tiene su propio timeout de aplicación (3 segundos) para las llamadas al servicio `reviews`. +Observa que en esta tarea usaste una regla de ruta de Istio para establecer el timeout a medio segundo. +Si en su lugar hubieras establecido el timeout a algo mayor que 3 segundos (como 4 segundos), el timeout +no habría tenido efecto ya que el más restrictivo de los dos prevalece. +Más detalles se pueden encontrar [aquí](/es/docs/concepts/traffic-management/#network-resilience-and-testing). -One more thing to note about timeouts in Istio is that in addition to overriding them in route rules, -as you did in this task, they can also be overridden on a per-request basis if the application adds -an `x-envoy-upstream-rq-timeout-ms` header on outbound requests. In the header, -the timeout is specified in milliseconds instead of seconds. +Una cosa más sobre los timeouts en Istio es que, además de sobrescribirlos en las reglas de ruta, +como hiciste en esta tarea, también se pueden sobrescribir a nivel de solicitud por solicitud si la aplicación añade +un encabezado `x-envoy-upstream-rq-timeout-ms` en las solicitudes de salida. En el encabezado, +el timeout se especifica en milisegundos en lugar de segundos. -## Cleanup +## Limpieza -* Remove the application routing rules: +* Elimina las reglas de enrutamiento de la aplicación: {{< tabset category-name="config-api" >}} @@ -257,6 +257,6 @@ $ kubectl delete virtualservice ratings {{< /tabset >}} -* If you are not planning to explore any follow-on tasks, see the - [Bookinfo cleanup](/es/docs/examples/bookinfo/#cleanup) instructions - to shutdown the application. +* Si no tienes intención de explorar ninguna tarea posterior, consulta las + [instrucciones de limpieza de Bookinfo](/es/docs/examples/bookinfo/#cleanup) + para apagar la aplicación. diff --git a/content/es/docs/tasks/traffic-management/traffic-shifting/index.md b/content/es/docs/tasks/traffic-management/traffic-shifting/index.md index 53ade9a21f1a1..6f36ecc498be4 100644 --- a/content/es/docs/tasks/traffic-management/traffic-shifting/index.md +++ b/content/es/docs/tasks/traffic-management/traffic-shifting/index.md @@ -1,6 +1,6 @@ --- -title: Traffic Shifting -description: Shows you how to migrate traffic from an old to new version of a service. +title: Desplazamiento de Tráfico +description: Te muestra cómo migrar tráfico de una versión antigua a una nueva versión de un servicio. weight: 30 keywords: [traffic-management,traffic-shifting] aliases: @@ -9,33 +9,33 @@ owner: istio/wg-networking-maintainers test: yes --- -This task shows you how to shift traffic from one version of a microservice to another. +Esta tarea te muestra cómo desplazar tráfico de una versión de un microservicio a otra. -A common use case is to migrate traffic gradually from an older version of a microservice to a new one. -In Istio, you accomplish this goal by configuring a sequence of routing rules that redirect a percentage of traffic -from one destination to another. +Un caso de uso común es migrar tráfico gradualmente de una versión antigua de un microservicio a una nueva. +En Istio, logras este objetivo configurando una secuencia de reglas de enrutamiento que redirigen un porcentaje de tráfico +de un destino a otro. -In this task, you will use send 50% of traffic to `reviews:v1` and 50% to `reviews:v3`. Then, you will -complete the migration by sending 100% of traffic to `reviews:v3`. +En esta tarea, enviarás 50% del tráfico a `reviews:v1` y 50% a `reviews:v3`. Luego, +completarás la migración enviando 100% del tráfico a `reviews:v3`. {{< boilerplate gateway-api-support >}} -## Before you begin +## Antes de comenzar -* Setup Istio by following the instructions in the - [Installation guide](/es/docs/setup/). +* Configura Istio siguiendo las instrucciones en la + [Guía de instalación](/es/docs/setup/). -* Deploy the [Bookinfo](/es/docs/examples/bookinfo/) sample application. +* Despliega la aplicación de ejemplo [Bookinfo](/es/docs/examples/bookinfo/). -* Review the [Traffic Management](/es/docs/concepts/traffic-management) concepts doc. +* Revisa el documento de conceptos de [Gestión de Tráfico](/es/docs/concepts/traffic-management). -## Apply weight-based routing +## Aplicar enrutamiento basado en peso {{< warning >}} -If you haven't already, follow the instructions in [define the service versions](/es/docs/examples/bookinfo/#define-the-service-versions). +Si no lo has hecho ya, sigue las instrucciones en [definir las versiones del servicio](/es/docs/examples/bookinfo/#define-the-service-versions). {{< /warning >}} -1. To get started, run this command to route all traffic to the `v1` version: +1. Para comenzar, ejecuta este comando para enrutar todo el tráfico a la versión `v1`: {{< tabset category-name="config-api" >}} @@ -57,15 +57,15 @@ $ kubectl apply -f @samples/bookinfo/gateway-api/route-reviews-v1.yaml@ {{< /tabset >}} -2) Open the Bookinfo site in your browser. The URL is `http://$GATEWAY_URL/productpage`, where `$GATEWAY_URL` is the External IP address of the ingress, as explained in -the [Bookinfo](/es/docs/examples/bookinfo/#determine-the-ingress-ip-and-port) doc. +2) Abre el sitio Bookinfo en tu navegador. La URL es `http://$GATEWAY_URL/productpage`, donde `$GATEWAY_URL` es la dirección IP externa del ingress, como se explica en +el documento [Bookinfo](/es/docs/examples/bookinfo/#determine-the-ingress-ip-and-port). - Notice that the reviews part of the page displays with no rating stars, no - matter how many times you refresh. This is because you configured Istio to route - all traffic for the reviews service to the version `reviews:v1` and this - version of the service does not access the star ratings service. + Nota que la parte de reseñas de la página se muestra sin estrellas, + independientemente de cuántas veces la refresques. Esto es porque configuraste Istio para enrutar + todo el tráfico para el servicio de reseñas a la versión `reviews:v1` y esta + versión del servicio no accede al servicio de valoraciones. -3) Transfer 50% of the traffic from `reviews:v1` to `reviews:v3` with the following command: +3) Transfiere el 50% del tráfico de `reviews:v1` a `reviews:v3` con el siguiente comando: {{< tabset category-name="config-api" >}} @@ -87,8 +87,8 @@ $ kubectl apply -f @samples/bookinfo/gateway-api/route-reviews-50-v3.yaml@ {{< /tabset >}} -4) Wait a few seconds for the new rules to propagate and then -confirm the rule was replaced: +4) Espera unos segundos para que las nuevas reglas se propaguen y luego +confirma que la regla se reemplazó: {{< tabset category-name="config-api" >}} @@ -161,18 +161,18 @@ status: {{< /tabset >}} -5) Refresh the `/productpage` in your browser and you now see *red* colored star ratings approximately 50% of the time. This is because the `v3` version of `reviews` accesses -the star ratings service, but the `v1` version does not. +5) Refresca la `/productpage` en tu navegador y ahora verás *rojas* las estrellas de valoración aproximadamente el 50% del tiempo. Esto es porque la versión `v3` de `reviews` accede +al servicio de valoraciones, pero la versión `v1` no. {{< tip >}} - With the current Envoy sidecar implementation, you may need to refresh the - `/productpage` many times --perhaps 15 or more--to see the proper distribution. - You can modify the rules to route 90% of the traffic to `v3` to see red stars - more often. + Con la implementación actual del sidecar de Envoy, puede que necesites refrescar + la `/productpage` muchas veces --quizás 15 o más-- para ver la distribución correcta. + Puedes modificar las reglas para enrutar el 90% del tráfico a `v3` para ver las estrellas rojas + más a menudo. {{< /tip >}} -6) Assuming you decide that the `reviews:v3` microservice is stable, you can -route 100% of the traffic to `reviews:v3` by applying this virtual service: +6) Suponiendo que decides que el microservicio `reviews:v3` es estable, puedes +enrutar el 100% del tráfico a `reviews:v3` aplicando este servicio virtual: {{< tabset category-name="config-api" >}} @@ -194,21 +194,20 @@ $ kubectl apply -f @samples/bookinfo/gateway-api/route-reviews-v3.yaml@ {{< /tabset >}} -7) Refresh the `/productpage` several times. Now you will always see book reviews - with *red* colored star ratings for each review. +7) Refresca la `/productpage` varias veces. Ahora siempre verás reseñas de libros + con *rojas* las estrellas de valoración para cada reseña. -## Understanding what happened +## Entendiendo lo que sucedió -In this task you migrated traffic from an old to new version of the `reviews` service using Istio's weighted routing feature. Note that this is very different than doing version migration using the deployment features of container orchestration platforms, which use instance scaling to manage the traffic. +En esta tarea migras tráfico de una versión antigua a una nueva versión del servicio `reviews` usando la característica de enrutamiento ponderado de Istio. Ten en cuenta que esto es muy diferente a hacer la migración de versiones usando las características de escalado de instancias de orquestación de contenedores, que usan el escalado de instancias para gestionar el tráfico. -With Istio, you can allow the two versions of the `reviews` service to scale up and down independently, without affecting the traffic distribution between them. +Con Istio, puedes permitir que las dos versiones del servicio `reviews` escalen independientemente, sin afectar la distribución del tráfico entre ellas. -For more information about version routing with autoscaling, check out the blog -article [Canary Deployments using Istio](/blog/2017/0.1-canary/). +Para más información sobre el enrutamiento de versiones con autoscaling, consulta el artículo del blog [Desplazamientos de canario usando Istio](/blog/2017/0.1-canary/). -## Cleanup +## Limpieza -1. Remove the application routing rules: +1. Elimina las reglas de enrutamiento de la aplicación: {{< tabset category-name="config-api" >}} @@ -230,6 +229,6 @@ $ kubectl delete httproute reviews {{< /tabset >}} -2) If you are not planning to explore any follow-on tasks, refer to the - [Bookinfo cleanup](/es/docs/examples/bookinfo/#cleanup) instructions - to shutdown the application. +2) Si no planeas explorar ninguna tarea posterior, consulta las + instrucciones de [limpieza del Bookinfo](/es/docs/examples/bookinfo/#cleanup) + para apagar la aplicación. From 893f7333c2295603e8288f3e89bf4363b9fb6cb3 Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Thu, 14 Aug 2025 17:10:41 +0200 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Josune Cordoba <49480155+josunect@users.noreply.github.com> --- .../tasks/security/authentication/authn-policy/index.md | 4 ++-- .../security/authorization/authz-td-migration/index.md | 2 +- .../traffic-management/egress/egress-control/index.md | 8 ++++---- .../egress/egress-gateway-tls-origination/index.md | 2 +- .../traffic-management/egress/egress-gateway/index.md | 2 +- .../tasks/traffic-management/egress/http-proxy/index.md | 2 +- .../ingress/ingress-sidecar-tls-termination/index.md | 6 +++--- .../traffic-management/ingress/secure-ingress/index.md | 4 ++-- 8 files changed, 15 insertions(+), 15 deletions(-) diff --git a/content/es/docs/tasks/security/authentication/authn-policy/index.md b/content/es/docs/tasks/security/authentication/authn-policy/index.md index 6cba1b8480ab2..90b8e32049263 100644 --- a/content/es/docs/tasks/security/authentication/authn-policy/index.md +++ b/content/es/docs/tasks/security/authentication/authn-policy/index.md @@ -118,8 +118,8 @@ $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metada Aunque Istio actualiza automáticamente todo el tráfico entre los proxies y los workloads a mTLS, los workloads aún pueden recibir tráfico de texto plano. Para evitar el tráfico no mTLS para toda la mesh, -establezca una política de autenticación de pares a nivel de meshcon el modo mTLS establecido en `STRICT`. -La política de autenticación de pares a nivel de meshno debe tener un `selector` y debe aplicarse en el **namespace raíz**, por ejemplo: +establezca una política de autenticación de pares a nivel de mesh con el modo mTLS establecido en `STRICT`. +La política de autenticación de pares a nivel de mesh no debe tener un `selector` y debe aplicarse en el **namespace raíz**, por ejemplo: {{< text bash >}} $ kubectl apply -f - <}}trust domain migration{{}} para la política de autorización. Esto significa que si una -meshde Istio necesita cambiar su {{< gloss >}}trust domain{{}}, la política de autorización no necesita ser cambiada manualmente. +mesh de Istio necesita cambiar su {{< gloss >}}trust domain{{}}, la política de autorización no necesita ser cambiada manualmente. En Istio, si un {{< gloss >}}workload{{}} se está ejecutando en el namespace `foo` con la cuenta de service `bar`, y el trust domain del sistema es `my-td`, la identidad de dicho workload es `spiffe://my-td/ns/foo/sa/bar`. Por defecto, el trust domain de la mesh de Istio es `cluster.local`, a menos que lo especifique durante la instalación. diff --git a/content/es/docs/tasks/traffic-management/egress/egress-control/index.md b/content/es/docs/tasks/traffic-management/egress/egress-control/index.md index 3f65fd462f26a..9efaf10e74712 100644 --- a/content/es/docs/tasks/traffic-management/egress/egress-control/index.md +++ b/content/es/docs/tasks/traffic-management/egress/egress-control/index.md @@ -1,6 +1,6 @@ --- title: Acceso a Services Externos -description: Describe cómo configurar Istio para enrutar el tráfico de services en la mesh a services externos. +description: Describe cómo configurar Istio para enrutar el tráfico de services en la mesh a servicios externos. weight: 10 aliases: - /docs/tasks/egress.html @@ -97,11 +97,11 @@ Luego puede decidir [configurar el acceso a services externos](#controlled-acces HTTP/2 200 {{< /text >}} -¡Felicidades! Ha enviado tráfico de salida desde su meshcon éxito. +¡Felicidades! Ha enviado tráfico de salida desde su mesh con éxito. Este enfoque simple para acceder a services externos tiene el inconveniente de que se pierde el monitoreo y control de Istio -para el tráfico a services externos. La siguiente sección le muestra cómo monitorear y controlar el acceso de su mesha -services externos. +para el tráfico a services externos. La siguiente sección le muestra cómo monitorear y controlar el acceso de su mesh a +servicios externos. ## Acceso controlado a services externos diff --git a/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md b/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md index cc1c897728164..adb7a56a04d77 100644 --- a/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md +++ b/content/es/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md @@ -463,7 +463,7 @@ Para simular un service externo real que admita el protocolo mTLS, despliegue un servidor [NGINX](https://www.nginx.com) en su cluster de Kubernetes, pero ejecutándose fuera de la service mesh de Istio, es decir, en un namespace sin la inyección de proxy sidecar de Istio habilitada. -1. Cree un namespace para representar services fuera de la mesh de Istio, llamado `mesh-external`. Tenga en cuenta que el proxy sidecar +1. Cree un namespace para representar servicios fuera de la mesh de Istio, llamado `mesh-external`. Tenga en cuenta que el proxy sidecar no se inyectará automáticamente en los pods de este namespace ya que la inyección automática de sidecar no estaba [habilitada](/es/docs/setup/additional-setup/sidecar-injection/#deploying-an-app) en él. diff --git a/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md b/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md index c1ff031b81bf7..d99a8708e6731 100644 --- a/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md +++ b/content/es/docs/tasks/traffic-management/egress/egress-gateway/index.md @@ -32,7 +32,7 @@ de la service mesh debe fluir a través de un conjunto de nodos dedicados. Estos separadas del resto de los nodos que ejecutan applications en el cluster. Estos nodos especiales servirán para la aplicación de políticas en el tráfico de salida y serán monitoreados más a fondo que otros nodos. -Otro caso de uso es un cluster donde los nodos de la aplicación no tienen IPs públicas, por lo que los services en meshque se ejecutan +Otro caso de uso es un cluster donde los nodos de la aplicación no tienen IPs públicas, por lo que los services en mesh que se ejecutan en ellos no pueden acceder a Internet. Definir un egress gateway, dirigir todo el tráfico de salida a través de él y asignar IPs públicas a los nodos del egress gateway permite que los nodos de la aplicación accedan a services externos de forma controlada. diff --git a/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md b/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md index 845fe13f9515e..08e68deb8cd0f 100644 --- a/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md +++ b/content/es/docs/tasks/traffic-management/egress/http-proxy/index.md @@ -9,7 +9,7 @@ owner: istio/wg-networking-maintainers test: yes --- El ejemplo [Configurar un Egress Gateway](/es/docs/tasks/traffic-management/egress/egress-gateway/) muestra cómo dirigir -el tráfico a services externos desde su mesha través de un componente de borde de Istio llamado _Egress Gateway_. Sin embargo, algunos +el tráfico a services externos desde su mesh a través de un componente de borde de Istio llamado _Egress Gateway_. Sin embargo, algunos casos requieren un proxy HTTPS externo y heredado (no Istio) para acceder a services externos. Por ejemplo, su empresa ya puede tener un proxy de este tipo en su lugar y todas las applications dentro de la organización pueden estar obligadas a dirigir su tráfico a través de él. diff --git a/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md b/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md index 353cd349a07ae..4a8cf86e840bd 100644 --- a/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md +++ b/content/es/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md @@ -7,7 +7,7 @@ owner: istio/wg-networking-maintainers test: yes --- -En un despliegue de meshde Istio regular, la terminación TLS para las solicitudes descendentes se realiza en el Ingress Gateway. +En un despliegue de mesh de Istio regular, la terminación TLS para las solicitudes descendentes se realiza en el Ingress Gateway. Aunque esto satisface la mayoría de los casos de uso, para algunos (como un API Gateway en la mesh) el Ingress Gateway no es necesariamente necesario. Esta tarea muestra cómo eliminar el salto adicional introducido por el Ingress Gateway de Istio y permitir que el sidecar de Envoy, que se ejecuta junto con la aplicación, realice la terminación TLS para las solicitudes que provienen de fuera de la service mesh. El service HTTPS de ejemplo utilizado para esta tarea es un service [httpbin](https://httpbin.org) simple. @@ -240,7 +240,7 @@ ROOTCA CA file-root:/etc/istio/tls-ca-certs/ca.crt Cert Chain ACTIVE true 14033888812979945197 2023-02-14T09:51:56Z 2022-02-14T09:51:56Z {{< /text >}} -### Verificar la conectividad de meshinterna en el puerto 8080 +### Verificar la conectividad de mesh interna en el puerto 8080 {{< text bash >}} $ export INTERNAL_CLIENT=$(kubectl -n test get pod -l app=curl -o jsonpath={.items..metadata.name}) @@ -255,7 +255,7 @@ content-length: 0 x-envoy-upstream-service-time: 5 {{< /text >}} -### Verificar la conectividad de meshexterna a interna en el puerto 8443 +### Verificar la conectividad de mesh externa a interna en el puerto 8443 Para verificar el tráfico mTLS desde un cliente externo, primero copie el certificado de CA y el certificado/clave de cliente al cliente curl que se ejecuta en el namespace predeterminado. diff --git a/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md b/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md index 66e0def537809..ffe7d27debb71 100644 --- a/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md +++ b/content/es/docs/tasks/traffic-management/ingress/secure-ingress/index.md @@ -485,7 +485,7 @@ EOF ... {{< /text >}} -### Configurar un gateway de ingreso de TLS mutuo +### Configurar un gateway de ingress de TLS mutuo Puedes extender la definición del gateway para soportar [TLS mutuo](https://en.wikipedia.org/wiki/Mutual_authentication). @@ -677,7 +677,7 @@ Ver [configuración de enrutamiento de SNI](/es/docs/ops/common-problems/network El log debería mostrar que el secreto `httpbin-credential` fue añadido. Si usas TLS mutuo, entonces el secreto `httpbin-credential-cacert` también debería aparecer. Verifica que el log muestre que el agente de gateway recibe solicitudes SDS del gateway de ingreso, que el nombre del recurso es `httpbin-credential`, y que el gateway de ingreso obtiene la pareja clave/certificado. Si usas TLS mutuo, el log debería mostrar clave/certificado fue enviado al gateway de ingreso, - que el agente de gateway recibió la solicitud SDS con el nombre de recurso `httpbin-credential-cacert`, y que el gateway de ingreso obtuvo el certificado raíz. + que el agente de gateway recibió la solicitud SDS con el nombre de recurso `httpbin-credential-cacert`, y que el gateway de ingreso obtuvo el certificado raíz. ## Limpieza From 777310a55d7fa8765a0a38c233553ba5a12904c0 Mon Sep 17 00:00:00 2001 From: Francisco Herrera Date: Thu, 21 Aug 2025 15:09:59 +0200 Subject: [PATCH 3/3] Update content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md Co-authored-by: Josune Cordoba <49480155+josunect@users.noreply.github.com> --- .../docs/tasks/traffic-management/ingress/gateway-api/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md b/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md index 1309152e70145..284cf5bce767b 100644 --- a/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md +++ b/content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md @@ -14,7 +14,7 @@ Además de su propia API de gestión de tráfico, {{< boilerplate gateway-api-future >}} Este documento describe las diferencias entre las APIs de Istio y Kubernetes y proporciona un ejemplo simple que te muestra cómo configurar Istio para exponer un servicio fuera del clúster de service mesh usando el Gateway API. -Ten en cuenta que estas APIs son una evolución desarrollada activamente de las APIs de [Service](https://kubernetes.io/docs/concepts/services-networking/service/) +Ten en cuenta que estas APIs son una evolución desarrollada activamente de las APIs de [Servicio](https://kubernetes.io/docs/concepts/services-networking/service/) e [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) de Kubernetes. {{< tip >}}