[release-1.26] [ES] Issue #16684: pendings translations to Spanish (#16751)

* Add Spanish translation for first 64 files

Signed-off-by: Francisco Herrera <fjglira@gmail.com>

* Fix broken internal links in Spanish translation

Signed-off-by: Francisco Herrera <fjglira@gmail.com>

* Fix broken image link

Signed-off-by: Francisco Herrera <fjglira@gmail.com>

* Apply suggestions from code review

Co-authored-by: German Robayo <germanrobayo33@gmail.com>

* Change PERMISIVO by PERMISSIVE

Signed-off-by: Francisco Herrera <fjglira@gmail.com>

---------

Signed-off-by: Francisco Herrera <fjglira@gmail.com>
Co-authored-by: Francisco Herrera <fjglira@gmail.com>
Co-authored-by: German Robayo <germanrobayo33@gmail.com>

Author: 3 people

content/es/about/case-studies/fico/index.md

@@ -18,6 +18,6 @@ type: case-studies
 weight: 70
 ---
 
-FICO comenzó su viaje con la malla en 2019, adoptando Istio en la versión 0.8. Istio ha madurado mucho en ese tiempo, y la implementación y el uso de Istio por parte de la organización también han madurado significativamente. En [esta presentación de IstioCon 2021](https://events.istio.io/istiocon-2021/sessions/fico-istio-journey/), Jeet Kaul, vicepresidente de ingeniería de FICO, recorrió el viaje de FICO con Istio desde 2019 hasta hoy, discutiendo por qué eligieron Istio inicialmente, algunos de los dolores de crecimiento que experimentaron y qué objetivos comerciales han podido lograr gracias a Istio.
+FICO comenzó su viaje con la mesh en 2019, adoptando Istio en la versión 0.8. Istio ha madurado mucho en ese tiempo, y la implementación y el uso de Istio por parte de la organización también han madurado significativamente. En [esta presentación de IstioCon 2021](https://events.istio.io/istiocon-2021/sessions/fico-istio-journey/), Jeet Kaul, vicepresidente de ingeniería de FICO, recorrió el viaje de FICO con Istio desde 2019 hasta hoy, discutiendo por qué eligieron Istio inicialmente, algunos de los dolores de crecimiento que experimentaron y qué objetivos comerciales han podido lograr gracias a Istio.
 
 <iframe width="696" height="392" src="https://www.youtube-nocookie.com/embed/1iueSRNsUww" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

content/es/about/deployment/index.md

@@ -41,7 +41,7 @@ Existen muchas buenas razones para adoptar Istio: desde agregar seguridad a sus
 
 Introduzca gradualmente sus servicios en la service mesh labeling un namespace a la vez. Por defecto, los servicios en múltiples namespaces pueden comunicarse entre sí, pero puede aumentar el aislamiento seleccionando cuáles exponer a otros namespaces. El uso de namespaces también mejora el rendimiento ya que las configuraciones están limitadas.
 
-Istio es flexible para adaptarse a la configuración de su cluster de Kubernetes y a la arquitectura de red. Puede optar por ejecutar múltiples mallas con planos de control independientes o tener uno solo.
+Istio es flexible para adaptarse a la configuración de su clúster de Kubernetes y a la arquitectura de red. Puede optar por ejecutar múltiples mesh con planos de control independientes o tener uno solo.
 
 Mientras los pods puedan conectarse a la red, Istio funcionará; incluso puede configurar gateways de Istio para que actúen como un host bastión entre diferentes redes.
 
@@ -63,7 +63,7 @@ Lea más sobre [cómo habilitar aplicaciones para que las utilice Istio](/es/doc
 
 ### Habilitar seguridad
 
-Istio configurará los servicios en su malla para usar mTLS cuando sea posible. Por defecto, Istio se ejecutará en modo "mTLS permisivo", lo que significa que los servicios aceptarán tanto tráfico cifrado como no cifrado; esto permite mantener la funcionalidad del tráfico entre servicios fuera de la malla temporalmente. Una vez que todos sus servicios estén integrados en la malla, podrá [cambiar la política de autenticación](/es/docs/tasks/security/authentication/mtls-migration/) para permitir solo tráfico seguro (TLS).
+Istio configurará los servicios en su mesh para usar mTLS cuando sea posible. Por defecto, Istio se ejecutará en modo "mTLS permisivo", lo que significa que los servicios aceptarán tanto tráfico cifrado como no cifrado; esto permite mantener la funcionalidad del tráfico entre servicios fuera de la mesh temporalmente. Una vez que todos sus servicios estén integrados en la mesh, podrá [cambiar la política de autenticación](/es/docs/tasks/security/authentication/mtls-migration/) para permitir solo tráfico seguro (TLS).
 
 ### Las dos API de Istio
 
@@ -75,13 +75,13 @@ Istio no es solo para Kubernetes; también puede [añadir servicios en máquinas
 
 ## Monitorizar sus servicios
 
-Explore el tráfico que fluye por su malla usando [Kiali](/es/docs/ops/integrations/kiali/) o haga un seguimiento de las solicitudes con [Zipkin](/es/docs/tasks/observability/distributed-tracing/zipkin/) o [Jaeger](/es/docs/tasks/observability/distributed-tracing/jaeger/).
+Explore el tráfico que fluye por su mesh usando [Kiali](/docs/ops/integrations/kiali/) o haga un seguimiento de las solicitudes con [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/) o [Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/).
 
-Use los paneles predeterminados de [Grafana](/es/docs/ops/integrations/grafana/) para Istio y obtenga informes automáticos de señales doradas para los servicios que se ejecutan en una malla.
+Use los paneles predeterminados de [Grafana](/es/docs/ops/integrations/grafana/) para Istio y obtenga informes automáticos de señales doradas para los servicios que se ejecutan en un mesh.
 
 ## Consideraciones operativas y Día 2
 
-Como propietario de la plataforma, usted es responsable de instalar y mantener la malla actualizada con poco impacto en los equipos de servicios.
+Como propietario de la plataforma, usted es responsable de instalar y mantener la mesh actualizado con poco impacto en los equipos de servicios.
 
 ### Instalación
 
@@ -91,11 +91,11 @@ Con istioctl, puede instalar Istio fácilmente utilizando uno de los perfiles in
 
 Cuando se lanza una nueva versión, Istio permite tanto actualizaciones in-place como canary. Elegir entre ambos implica una compensación entre la simplicidad y el posible tiempo de inactividad. Para entornos de producción, se recomienda utilizar el [método de actualización canary](/es/docs/setup/upgrade/canary/). Después de verificar que las nuevas versiones del control plane y del data plane funcionan correctamente, puede actualizar sus gateways.
 
-### Supervisar la malla
+### Supervisar la mesh
 
-Istio genera telemetría detallada de todas las comunicaciones de servicios dentro de una malla. Estas métricas, trazas y registros de acceso son vitales para comprender cómo interactúan sus aplicaciones entre sí e identificar posibles cuellos de botella en el rendimiento. Utilice esta información para ayudarle a configurar interruptores de circuito, tiempos de espera y reintentos, y fortalecer sus aplicaciones.
+Istio genera telemetría detallada de todas las comunicaciones de servicios dentro de un mesh. Estas métricas, trazas y registros de acceso son vitales para comprender cómo interactúan sus aplicaciones entre sí e identificar posibles cuellos de botella en el rendimiento. Utilice esta información para ayudarle a configurar interruptores de circuito, tiempos de espera y reintentos, y fortalecer sus aplicaciones.
 
-Al igual que sus aplicaciones que se ejecutan en la malla, los componentes del control plane de Istio también exportan métricas. Aproveche estas métricas y los paneles preconfigurados de Grafana para ajustar sus solicitudes de recursos, límites y escalado.
+Al igual que sus aplicaciones que se ejecutan en la mesh, los componentes del control plane de Istio también exportan métricas. Aproveche estas métricas y los paneles preconfigurados de Grafana para ajustar sus solicitudes de recursos, límites y escalado.
 
 ## Únase a la comunidad de Istio
 

content/es/about/faq/distributed-tracing/how-envoy-based-tracing-works.md

@@ -12,4 +12,4 @@ Envoy:
 - envía los tramos de seguimiento generados a los backends de seguimiento
 - reenvía las cabeceras de seguimiento a la aplicación representada
 
-Istio admite [OpenTelemetry](/es/docs/tasks/observability/distributed-tracing/opentelemetry/) y backends compatibles, incluidos [Jaeger](/es/docs/tasks/observability/distributed-tracing/jaeger/). Otras plataformas compatibles incluyen [Zipkin](/es/docs/tasks/observability/distributed-tracing/zipkin/) y [Apache SkyWalking](/es/docs/tasks/observability/distributed-tracing/skywalking/).
+Istio admite [OpenTelemetry](/docs/tasks/observability/distributed-tracing/opentelemetry/) y backends compatibles, incluidos [Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/). Otras plataformas compatibles incluyen [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/) y [Apache SkyWalking](/docs/tasks/observability/distributed-tracing/skywalking/).

content/es/about/faq/distributed-tracing/how-to-support-tracing.md

@@ -3,7 +3,7 @@ title: ¿Qué se requiere para el seguimiento distribuido con Istio?
 weight: 10
 ---
 
-Istio permite la notificación de tramos de seguimiento para las comunicaciones de workload a workload dentro de una malla. Sin embargo, para que los diversos tramos de seguimiento se unan para obtener una vista completa del flujo de tráfico, las aplicaciones deben propagar el contexto de seguimiento entre las solicitudes entrantes y salientes.
+Istio permite la notificación de tramos de seguimiento para las comunicaciones de workload a workload dentro de un mesh. Sin embargo, para que los diversos tramos de seguimiento se unan para obtener una vista completa del flujo de tráfico, las aplicaciones deben propagar el contexto de seguimiento entre las solicitudes entrantes y salientes.
 
 En particular, Istio se basa en que las aplicaciones reenvíen el ID de solicitud generado por Envoy y las cabeceras estándar. Estas cabeceras incluyen:
 

content/es/about/faq/general/why-use-istio.md

@@ -7,4 +7,4 @@ Tradicionalmente, gran parte de la lógica gestionada por Istio se ha integrado
 
 *Desarrolladores de aplicaciones*: Con Istio gestionando cómo fluye el tráfico a través de sus servicios, los desarrolladores pueden centrarse exclusivamente en la lógica empresarial e iterar rápidamente en nuevas funciones.
 
-*Operadores de servicios*: Istio permite la aplicación de políticas y la supervisión de la malla desde un único punto de control centralizado, independientemente de la evolución de la aplicación. Como resultado, los operadores pueden garantizar el cumplimiento continuo de las políticas a través de un plano de gestión simplificado.
+*Operadores de servicios*: Istio permite la aplicación de políticas y la supervisión de la mesh desde un único punto de control centralizado, independientemente de la evolución de la aplicación. Como resultado, los operadores pueden garantizar el cumplimiento continuo de las políticas a través de un plano de gestión simplificado.

content/es/about/faq/metrics-and-logs/life-of-a-request.md

@@ -5,7 +5,7 @@ weight: 80
 
 Puede habilitar el [seguimiento](/es/docs/tasks/observability/distributed-tracing/) para determinar el flujo de una solicitud en Istio.
 
-Además, puede usar los siguientes comandos para saber más sobre el estado de la malla:
+Además, puede usar los siguientes comandos para saber más sobre el estado de la mesh:
 
 * [`istioctl proxy-config`](/es/docs/reference/commands/istioctl/#istioctl-proxy-config): recupera información sobre la configuración del proxy cuando se ejecuta en Kubernetes:
 
@@ -29,7 +29,7 @@ Además, puede usar los siguientes comandos para saber más sobre el estado de l
     $ istioctl proxy-config --help
     {{< /text >}}
 
-* `kubectl get`: obtiene información sobre diferentes recursos en la malla junto con la configuración de enrutamiento:
+* `kubectl get`: obtiene información sobre diferentes recursos en la mesh junto con la configuración de enrutamiento:
 
     {{< text plain >}}
     # Listar todos los virtual services

content/es/about/faq/metrics-and-logs/metric-expiry.md

@@ -10,7 +10,7 @@ Hay varias formas de reducir la cardinalidad de las métricas de Istio:
   La label `destination_service` es una fuente potencial de alta cardinalidad.
   Los valores para `destination_service` se establecen de forma predeterminada en el encabezado del host si el proxy de Istio no puede determinar el servicio de destino a partir de otros metadatos de la solicitud.
   Si los clientes utilizan una variedad de encabezados de host, esto podría dar como resultado una gran cantidad de valores para `destination_service`.
-  En este caso, siga la guía de [personalización de métricas](/es/docs/tasks/observability/metrics/customize-metrics/) para deshabilitar la reserva del encabezado del host en toda la malla.
+  En este caso, siga la guía de [personalización de métricas](/es/docs/tasks/observability/metrics/customize-metrics/) para deshabilitar la reserva del encabezado del host en toda la mesh.
   Para deshabilitar la reserva del encabezado del host para una workload o un namespace en particular, debe copiar la configuración de `EnvoyFilter` de estadísticas, actualizarla para que la reserva del encabezado del host esté deshabilitada y aplicarla con un selector más específico.
   [Este problema](https://github.com/istio/istio/issues/25963#issuecomment-666037411) tiene más detalles sobre cómo lograrlo.
 * Eliminar labels innecesarias de la colección. Si no se necesita la label con alta cardinalidad, puede eliminarla de la colección de métricas a través de la [personalización de métricas](/es/docs/tasks/observability/metrics/customize-metrics/) usando `tags_to_remove`.

content/es/about/faq/metrics-and-logs/mixer-migration.md

@@ -4,7 +4,7 @@ weight: 30
 ---
 
 Mixer fue [eliminado en la versión 1.8 de Istio](/news/releases/1.8.x/announcing-1.8/#deprecations).
-La migración es necesaria si todavía depende de los adaptadores integrados de Mixer o de cualquier adaptador fuera de proceso para la extensión de la malla.
+La migración es necesaria si todavía depende de los adaptadores integrados de Mixer o de cualquier adaptador fuera de proceso para la extensión de la mesh.
 
 Para los adaptadores integrados, se proporcionan varias alternativas:
 

content/es/about/faq/metrics-and-logs/telemetry-v1-vs-v2.md

@@ -9,7 +9,7 @@ y es el mecanismo preferido para mostrar la telemetría en Istio.
 Sin embargo, existen algunas diferencias en la telemetría informada entre v1 y
 v2 que se enumeran a continuación:
 
-* **Faltan labels para el tráfico fuera de la malla**
+* **Faltan etiquetas para el tráfico fuera de la mesh**
   La telemetría en el proxy se basa en el intercambio de metadatos entre los proxies de Envoy para recopilar
   información como el nombre de el workload del par, el namespace y las labels. En la telemetría basada en Mixer
   , esta funcionalidad la realizaba Mixer como parte de la combinación de los atributos de la solicitud
@@ -18,11 +18,11 @@ v2 que se enumeran a continuación:
   el protocolo ALPN para el protocolo TCP como se describe
   [aquí](/es/docs/tasks/observability/metrics/tcp-metrics/#understanding-tcp-telemetry-collection).
   Esto requiere que los proxies de Envoy se inyecten tanto en los workloads del cliente como del servidor,
-  lo que implica que a la telemetría informada cuando un par no está en la malla le faltarán
+  lo que implica que a la telemetría informada cuando un par no está en la mesh le faltarán
   atributos del par como el nombre de el workload, el namespace y las labels.
   Sin embargo, si ambos pares tienen proxies inyectados, todas las labels mencionadas
   [aquí](/es/docs/reference/config/metrics/) están disponibles en las métricas generadas.
-  Cuando el workload del servidor está fuera de la malla, los metadatos de el workload del servidor todavía
+  Cuando el workload del servidor está fuera de la mesh, los metadatos de el workload del servidor todavía
   se distribuyen al sidecar del cliente, lo que hace que las métricas del lado del cliente tengan los metadatos de el workload del servidor
   labels completadas.
 

content/es/about/faq/security/auth-mix-and-match.md

@@ -3,5 +3,5 @@ title: ¿Puedo habilitar TLS mutuo para algunos servicios mientras lo dejo desha
 weight: 20
 ---
 
-La [política de autenticación](/es/docs/concepts/security/#authentication-policies) puede ser mesh-wide (lo que afecta a todos los servicios de la malla), namespace-wide
+La [política de autenticación](/es/docs/concepts/security/#authentication-policies) puede ser mesh-wide (lo que afecta a todos los servicios de la mesh), namespace-wide
 (todos los servicios del mismo namespace) o específicamente del servicio. Puede tener una o varias políticas para configurar TLS mutuo para los servicios de un cluster de la forma que desee.