Merge pull request #3231 from cncf/dev-es

[es] Merge dev-es branch into main branch

content/es/.wordlist.txt

@@ -1,4 +1,5 @@
-add
+accionables
+Add
 Agreement
 Amazon
 an
@@ -22,6 +23,7 @@ bare
 based
 becoming
 Benavides
+Berkeley
 blob
 blue
 branch
@@ -32,6 +34,7 @@ BVS
 BY
 CaaS
 calendar
+call
 Canary
 CAPEX
 Carol
@@ -49,6 +52,7 @@ CI
 cifrada
 CLA
 Client
+CLIs
 Cloud
 clúster
 clústeres
@@ -95,6 +99,7 @@ directly
 Docs
 draft
 Dropbox
+eBPF
 edit
 ej
 empoderen
@@ -113,6 +118,7 @@ externalizar
 FaaS
 faltantes
 Feedback
+Filter
 Finance
 Firewall
 first
@@ -161,6 +167,7 @@ Jones
 Kafka
 Katelin
 Kubernetes
+Landscape
 Language
 laptop
 Layer
@@ -188,6 +195,7 @@ Microsoft
 Mike
 mitigarse
 monitorea
+monitoreados
 monitorean
 monitorear
 monitoreará
@@ -215,8 +223,11 @@ on-premises
 Open
 PaaS
 PaC
+packet
 Paganini
 platform
+Pod
+pods
 Política
 portable
 pr
@@ -249,6 +260,7 @@ SaaS
 Salesforce
 SCE
 scripts
+SDK
 search
 Secure
 security
@@ -264,7 +276,7 @@ sobreescriba
 Sockets
 Spanish
 spell
-SRE
+sre
 SSL
 stack
 Started
@@ -276,6 +288,7 @@ submitting
 subrúbricas
 Subversion
 supercomputadoras
+system
 tags
 TCP
 technology

content/es/ebpf.md

@@ -0,0 +1,40 @@
+---
+title: eBPF
+status: Completed
+category: Tecnología
+tags: ["arquitectura", "redes", "seguridad"]
+---
+
+eBPF, o "extended Berkeley Packet Filter", es una tecnología que permite a pequeños programas o scripts aislados ejecutarse en el espacio del kernel de un sistema Linux sin necesidad de cambiar el código fuente ni cargar módulos al kernel Linux.
+
+Un sistema Linux tiene dos espacios: el de kernel y el de usuario. 
+El kernel representa el sistema operativo y es la única parte
+con acceso ilimitado al hardware. 
+
+Las aplicaciones quedan en el espacio de usuario y, cuando necesitan permisos más elevados,
+envían una solicitud al kernel.
+Para aplicaciones que requieren más flexibilidad, como el acceso directo al hardware,
+el kernel puede ser extendido mediante lo que se conoce como el enfoque de "módulos
+del kernel Linux". Este enfoque amplía la funcionalidad predeterminada del kernel,
+permitiendo a las aplicaciones un acceso más profundo a los componentes básicos. 
+Sin embargo, este enfoque también introduce riesgos de seguridad, lo que hace que eBPF sea una alternativa atractiva.
+
+## Problema que soluciona
+Típicamente, las aplicaciones se ejecutan en el espacio de usuario y, si la aplicación requiere algunos privilegios del kernel (por ejemplo, para acceder a algún hardware),
+lo solicita al kernel a través de una llamada al sistema conocida como "system call".  
+En la mayoría de los casos, este enfoque funciona bien. Sin embargo, hay casos en los que los desarrolladores requieren más flexibilidad para acceder al sistema a nivel bajo.
+La observabilidad, la seguridad y las redes son buenos ejemplos.
+Para lograrlo, podemos utilizar módulos del kernel Linux, ampliando la base del kernel sin modificar el código principal del kernel. 
+Si bien hay beneficios en el uso de módulos del kernel Linux, también introduce riesgos de seguridad. 
+Como operan dentro del espacio del kernel, los módulos del kernel Linux pueden hacer que el kernel falle y, cuando el kernel falla, también lo hace toda la máquina.
+Además, los módulos del kernel tienen privilegios elevados y acceso directo a los recursos del sistema. Y si no están adecuadamente aseguradas, los atacantes pueden explotarlas.
+
+## ¿Cómo ayuda?
+eBPF proporciona un entorno más controlado y contenido para ejecutar programas definidos por el usuario que los módulos del kernel Linux.
+Se ejecuta en un entorno aislado dentro del kernel, proporcionando aislamiento y mitigando riesgos. 
+Si se explota una vulnerabilidad o defecto en un programa eBPF, su impacto generalmente se limita al entorno aislado.
+Además, antes de que un programa eBPF pueda comenzar a ejecutarse en el kernel, debe pasar por algunas verificaciones. 
+El componente verificador verifica el programa eBPF en busca de posibles violaciones de seguridad,
+como el acceso a memoria fuera de límites, ciclos infinitos y funciones del kernel no autorizadas.
+De esta manera, asegura que el programa no entre en un ciclos infinitos y provoque un fallo del kernel.
+Estos controles de seguridad hacen que eBPF sea una opción más segura para ejecutar aplicaciones en el kernel Linux que los módulos del kernel Linux.

content/es/observability.md

@@ -5,18 +5,12 @@ category: Concepto
 tags: ["propiedad", "", ""]
 ---
 
-La observabilidad es la capacidad de generar y descubrir continuamente información procesable basada en señales del sistema bajo observación.
-En otras palabras, la observabilidad permite a los usuarios comprender el estado de un sistema a partir de su salida externa y así tomar medidas (correctivas).
+La observabilidad es una propiedad del sistema que define el grado en que el sistema puede generar conocimientos accionables.
+Permite a los usuarios comprender el estado de un sistema a partir de estas salidas externas y tomar medidas (correctivas).
 
-## Problema que aborda
+Los sistemas informáticos se miden observando señales de bajo nivel como el tiempo de CPU, la memoria, el espacio en disco y señales de nivel superior y empresariales, incluidos los tiempos de respuesta de la API, errores, transacciones por segundo, etc.
+Estos sistemas observables son **observados** (o monitoreados) a través de herramientas especializadas, llamadas herramientas de observabilidad. Una lista de estas herramientas se puede ver en la [Sección de observabilidad de Cloud Native Landscape](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability).
 
-Los sistemas informáticos se miden mediante la observación de señales de bajo nivel, como el tiempo de CPU, la memoria, el espacio en disco y las señales comerciales y de nivel superior, incluidos los tiempos de respuesta de API, errores, transacciones por segundo, etc.
+Los sistemas observables proporcionan datos significativos y accionables a sus operadores, lo que les permite lograr resultados favorables (respuesta más rápida a incidentes, aumento de la productividad del desarrollador) y menos trabajo manual y tiempo de inactividad.
 
-La observabilidad de un sistema tiene un impacto significativo en su costo operativo.
-Los sistemas observables brindan datos significativos y procesables a sus operadores, lo que les permite lograr resultados favorables (respuesta más rápida a incidentes, mayor productividad del desarrollador) y menos trabajo y tiempo de inactividad.
-
-## ¿Cómo ayuda?
-
-Es esencial entender que más información no necesariamente significa que en un sistema sea más observable.
-De hecho, a veces, la cantidad de información generada por un sistema puede dificultar la identificación de señales de salud valiosas debido al ruido generado por la aplicación.
-La observabilidad requiere los datos correctos en el momento correcto para que el consumidor correcto (humano o pieza de software) tome las decisiones correctas.
+Por consiguiente, cuán observable sea un sistema esto afectará significativamente sus costos operativos y de desarrollo.

content/es/pod.md

@@ -0,0 +1,31 @@
+---
+title: Pod
+status: Completed
+category: Concepto
+tags: ["infraestructura", "fundamento", ""]
+---
+
+Dentro de un entorno de [Kubernetes](/es/kubernetes/), un Pod actúa como la unidad más básica desplegable. 
+Representa un bloque de construcción esencial para desplegar y administrar aplicaciones contenedorizadas. 
+Cada Pod contiene una única instancia de la aplicación y puede albergar uno o más [contenedores](/es/container/).
+Kubernetes administra los Pods como parte de un despliegue más grande y puede escalar los Pods [vertical](/es/vertical-scaling/) u [horizontalmente](/es/horizontal-scaling/) según sea necesario.
+
+## Problema que aborda
+
+Mientras los contenedores generalmente actúan como unidades independientes que ejecutan y controlan una carga de trabajo en particular,
+hay casos en los que los contenedores necesitan interactuar y ser controlados de manera estrechamente acoplada.
+
+Si cada uno de estos contenedores estrechamente relacionados se administrara individualmente, se generarían tareas de gestión redundantes.
+Por ejemplo, el operador tendría que determinar repetidamente la ubicación de los contenedores relacionados para asegurarse que permanezcan juntos.
+Y aunque los ciclos de vida de estos contenedores relacionados necesitan estar sincronizados, solo se pueden administrar individualmente.
+
+
+## ¿Cómo ayuda?
+
+Los Pods agrupan contenedores estrechamente vinculados en una única unidad, lo que simplifica significativamente las operaciones de contenedores.
+Por ejemplo, los contenedores auxiliares a menudo se suelen utilizar junto con el contenedor principal para agregar funcionalidades adicionales o configurar aspectos globales. 
+Ejemplos de esto incluyen contenedores que inyectan y aplican configuraciones básicas al contenedor principal, 
+_sidecar_ (contenedores auxiliares) que manejan el enrutamiento del tráfico de red para el contenedor principal (ver [malla de servicios](/es/service-mesh/))
+o contenedores que recolectan registros en conjunto con cada contenedor.
+
+La asignación de memoria y CPU se puede definir a nivel de Pod, permitiendo a los contenedores internos a compartir recursos de forma flexible, o bien se puede definir por contenedor individualmente.

content/es/serverless.md

@@ -5,28 +5,28 @@ Category: Tecnología
 tags: ["arquitectura", "", ""]
 ---
 
-Sin servidor (Serverless) es un modelo de desarrollo nativo en la nube que ayuda a los desarrolladores a
-crear y ejecutar aplicaciones sin tener que mantener servidores.
-Hay servidores en el modelo sin servidor, pero han sido [abstraídos](/es/abstraction/) del proceso de desarrollo.
-Un proveedor de nube se encarga del aprovisionamiento, mantenimiento y [escalamiento](/es/scalability/) de la infraestructura de servidores.
-Luego los desarrolladores pueden empacar su código en [contenedores](/es/containers/) para el despliegue.
-Una vez desplegado el código, las aplicaciones sin servidor satisfacen la demanda y escalan automáticamente según sea necesario.
-La modalidad sin servidor en proveedores de nube públicas usualmente es una medida bajo demanda a través de un modelo de ejecución basado en eventos.
-Como resultado, cuando una función sin servidor está inutilizada, no representa costo alguno.
+
+La computación sin servidor [abstrae](/es/abstraction/) los servidores del usuario.
+La gestión operativa recae en el proveedor de servicios, incluido el manejo de máquinas físicas y el aprovisionamiento de Máquinas Virtuales.
+Los proveedores de servicios pueden ser entidades de nube pública o departamentos de TI internos que prestan servicios a sus equipos de desarrollo.
+Estos proveedores ofrecen interfaces de usuario como SDK, CLIs o tiempos de ejecución compatibles con OCI, centrándose en el código y las tareas de implementación.
+Los cargos se basan en un modelo de pago por uso.
+El [escalado](/es/scalability/) y el aprovisionamiento de recursos para cómputo, almacenamiento o redes, se ajustan automáticamente en función de la demanda de la aplicación sin intervención del usuario.
+Un proveedor de plataforma sin servidor consolida recursos para atender a múltiples usuarios en una única máquina física, garantizando el aislamiento mediante la virtualización, especialmente con [Máquinas Virtuales](/es/virtual-machine/).
+
+Sin servidor (Serverless) es un término integral que abarca servicios con estos atributos y se extiende desde [Plataforma como Servicio (PaaS)](/es/platform-as-a-service/) hasta [Software como Servicio (SaaS)]( /es/software-as-a-service/).
 
 ## Problema que aborda
 
-En un modelo de [Infraestructura como Servicio](/es/infrastructure-as-a-service/),
-los usuarios compran unidades de cómputo o capacidad de forma anticipada, es decir, se paga a un proveedor de nube pública por componentes de servidores de ejecución continua para las aplicaciones.
-Es responsabilidad del usuario luego aumentar la capacidad de cómputo durante periodos de alta demanda y
-reducirla cuando ya no sea necesaria.
-La infraestructura en la nube necesaria para ejecutar una aplicación está activa incluso cuando la aplicación no está en uso.
+En los modelos tradicionales de [Infraestructura como Servicio (IaaS)](/es/infrastructure-as-a-service/), [computación en la nube](/es/cloud-computing/), los usuarios se comprometen a una capacidad predefinida, lo que genera cargos por disponibilidad del servidor independientemente del uso real.
+La responsabilidad de ajustar la capacidad del servidor para satisfacer las demandas fluctuantes recae en el usuario, manteniendo la infraestructura activa incluso durante los períodos de inactividad.
 
 ## ¿Cómo ayuda?
 
-En contraste, con la arquitectura sin servidor las aplicaciones son ejecutadas solo cuando es necesario.
-Cuando un evento llama a una aplicación a ejecutarse, el proveedor de nube pública garantiza dinámicamente una serie de recursos para que se ejecute dicho código.
-Además del beneficio de costo y eficiencia,
-el modelo sin servidor libera a los desarrolladores de las tareas rutinarias asociadas al escalado y aprovisionamiento de servidores.
-Con el modelo sin servidor, las tareas rutinarias como mantenimiento de los sistemas operativos y sistemas de archivos, parches de seguridad,
-balanceo de carga, manejo de capacidad, escalado, auditoría y monitoreo pasan a estar en manos del proveedor de servicios de nube.
+La arquitectura sin servidor introduce un enfoque más eficiente, activando servicios únicamente según demanda.
+Este modelo garantiza la asignación dinámica de recursos por parte de un proveedor de nube, eliminando costos por servicios no utilizados.
+Más allá de la eficiencia financiera y operativa, la tecnología sin servidor alivia a los desarrolladores de la carga de escalar aplicaciones y administrar la infraestructura de servidores.
+Tareas como el mantenimiento del sistema operativo, las actualizaciones de seguridad, el equilibrio de carga, la capacidad de planificación y el monitoreo se delegan al proveedor de la nube, lo que agiliza el proceso de desarrollo.
+
+Consulta la entrada del glosario [Función como Servicio (FaaS)](/es/function-as-a-service/) para obtener más información.
+Aunque "sin servidor" y "FaaS" se utilizan a menudo como términos intercambiables, incorporan conceptos distintos.