From 491365356f550cd96bc48165b257474941e0453a Mon Sep 17 00:00:00 2001 From: Edith Date: Sat, 2 Oct 2021 18:39:58 -0500 Subject: [PATCH 01/31] [es] Add concepts/storage/storage-capacity.md --- .../docs/concepts/storage/storage-capacity.md | 76 +++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 content/es/docs/concepts/storage/storage-capacity.md diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md new file mode 100644 index 0000000000..a29f4810df --- /dev/null +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -0,0 +1,76 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Capacidad de Almacenamiento +content_type: concept +weight: 45 +--- + + + +La capacidad de almacenamiento es limitada y puede variar según el nodo en el que un Pod se ejecuta: es posible que no todos los nodos puedan acceder al almacenamiento conectado a la red o que, para empezar, el almacenamiento sea local en un nodo. + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el programador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. + +El seguimiento de la capacidad de almacenamiento es compatible con los controladores de la {{< glossary_tooltip +text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y +[necesita estar habilitado](#enabling-storage-capacity-tracking) al instalar un controlador CSI. + + + +## API + +Hay dos extensiones de API para esta función: + +- Los objetos CSIStorageCapacity: + son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. +- [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): + cuando se establece en `true`, el scheduler de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. + +## Planificación + +El scheduler de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: + +- la puerta de la característica `CSIStorageCapacity` es `true`, +- un Pod usa un volumen que aún no se ha creado, +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding + mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), + y +- el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. + +En ese caso, el scheduler sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. + +Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador de almacenamiento decide dónde crear el volumen, independientemente de los pods que usarán el volumen. +Luego, el scheduler programa los pods en los nodos donde el volumen está disponible después de que se haya creado. + +Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), +la programación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. + +## Reprogramar + +Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. + +Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el scheduler de Kubernetes intenta nuevamente encontrar un nodo para el Pod. + +## Limitationes + +El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. + +Una situación en la que la programación puede fallar de forma permanente es cuando un pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ +Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. + +## Habilitación del seguimiento de la capacidad de almacenamiento + +El seguimiento de la capacidad de almacenamiento es una función beta y está habilitada de forma predeterminada en un clúster de Kubernetes desde Kubernetes 1.21. Además de tener la función habilitada en el clúster, un controlador CSI también tiene que admitirlo. Consulte la documentación del controlador para obtener más detalles. + +## {{% heading "whatsnext" %}} + +- Para obtener más información sobre el diseño, consulte las + [Restricciones de Capacidad de Almacenamiento para la Programación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). +- Para obtener más información sobre un mayor desarrollo de esta función, consulte [problema de seguimiento de mejoras #1472](https://github.com/kubernetes/enhancements/issues/1472). +- Aprender sobre [Scheduler de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) From eb34864d3eee3787808a707d60dc84d0155d7755 Mon Sep 17 00:00:00 2001 From: Edith Date: Sat, 2 Oct 2021 19:34:02 -0500 Subject: [PATCH 02/31] [es] Add concepts/storage/volume-pvc-datasource.md --- .../concepts/storage/volume-pvc-datasource.md | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 content/es/docs/concepts/storage/volume-pvc-datasource.md diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md new file mode 100644 index 0000000000..29de717f0e --- /dev/null +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -0,0 +1,66 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Clonación de volumen CSI +content_type: concept +weight: 30 +--- + + + +Este documento describe el concepto para clonar volúmenes CSI existentes en Kubernetes. Se sugiere estar familiarizado con [Volúmenes](/docs/concepts/storage/volumes). + + + +## Introduction + +La función de clonación de volumen {{< glossary_tooltip text="CSI" term_id="csi" >}} agrega soporte para especificar {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s existentes en el campo `dataSource` para indicar que un usuario desea clonar un {{< glossary_tooltip term_id="volume" >}}. + +Un Clon se define como un duplicado de un volumen de Kubernetes existente que se puede consumir como lo sería cualquier volumen estándar. La única diferencia es que al aprovisionar, en lugar de crear un "nuevo" Volumen vacío, el dispositivo de backend crea un duplicado exacto del Volumen especificado. + +La implementación de la clonación, desde la perspectiva de la API de Kubernetes, agrega la capacidad de especificar un PVC existente como dataSource durante la creación de un nuevo PVC. El PVC de origen debe estar vinculado y disponible (no en uso). + +Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: + +- El soporte de clonación (`VolumePVCDataSource`) sólo está disponible para controladores CSI. +- El soporte de clonación sólo está disponible para aprovisionadores dinámicos. +- Los controladores CSI pueden haber implementado o no la funcionalidad de clonación de volúmenes. +- Sólo puede clonar un PVC cuando existe en el mismo espacio de nombres que el PVC de destino (el origen y el destino deben estar en el mismo espacio de nombres). +- La clonación sólo se admite dentro de la misma Clase de Almacenamiento. + - El volumen de destino debe ser de la misma clase de almacenamiento que el origen + - Se puede utilizar la clase de almacenamiento predeterminada y se puede omitir storageClassName en la especificación +- La clonación sólo se puede realizar entre dos volúmenes que usan la misma configuración de VolumeMode (si solicita un volumen en modo de bloqueo, la fuente DEBE también ser en modo de bloqueo) + +## Aprovisionamiento + +Los clones se aprovisionan como cualquier otro PVC con la excepción de agregar un origen de datos que hace referencia a un PVC existente en el mismo espacio de nombres. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: clone-of-pvc-1 + namespace: myns +spec: + accessModes: + - ReadWriteOnce + storageClassName: cloning + resources: + requests: + storage: 5Gi + dataSource: + kind: PersistentVolumeClaim + name: pvc-1 +``` + +{{< note >}} +Debe especificar un valor de capacidad para `spec.resources.requests.storage` y el valor que especifique debe ser igual o mayor que la capacidad del volumen de origen. +{{< /note >}} + +El resultado es un nuevo PVC con el nombre `clone-of-pvc-1` que tiene exactamente el mismo contenido que la fuente especificada `pvc-1`. + +## Uso + +Una vez disponible el nuevo PVC, el PVC clonado se consume igual que el resto de PVC. También se espera en este punto que el PVC recién creado sea un objeto independiente. Se puede consumir, clonar, tomar snapshots, o eliminar de forma independiente y sin tener en cuenta sus datos originales. Esto también implica que la fuente no está vinculada de ninguna manera al clon recién creado, también puede modificarse o eliminarse sin afectar al clon recién creado. From 1788adc35fad244dcbe3ab6935b5c28f04fe968a Mon Sep 17 00:00:00 2001 From: Edith Date: Sat, 2 Oct 2021 20:27:17 -0500 Subject: [PATCH 03/31] [es] Add concepts/storage/dynamic-provisioning.md --- .../concepts/storage/dynamic-provisioning.md | 102 ++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 content/es/docs/concepts/storage/dynamic-provisioning.md diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md new file mode 100644 index 0000000000..e0a8f83960 --- /dev/null +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -0,0 +1,102 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Aprovisionamiento Dinámico de volumen +content_type: concept +weight: 40 +--- + + + +El aprovisionamiento dinámico de volúmenes permite crear volúmenes de almacenamiento bajo demanda. Sin el aprovisionamiento dinámico, los administradores de clústeres tienen que realizar llamadas manualmente a su proveedor de almacenamiento o nube para crear nuevos volúmenes de almacenamiento y luego crear [objetos de `PersistentVolume`](/docs/concepts/storage/persistent-volumes/) +para representarlos en Kubernetes. La función de aprovisionamiento dinámico elimina la necesidad de que los administradores del clúster aprovisionen previamente el almacenamiento. En cambio cuando lo solicitan los usuarios aprovisionan el almacenamiento es automático. + + + +## Antecedentes + +La implementación del aprovisionamiento dinámico de volúmenes se basa en el objeto API `StorageClass` +del grupo API `storage.k8s.io`. Un administrador de clúster puede definir tantos objetos +`StorageClass` como sea necesario, cada uno especificando un _volume plugin_ (aka +_provisioner_) que aprovisiona un volumen y el conjunto de parámetros para pasar a ese aprovisionador. Un administrador de clúster puede definir y exponer varios tipos de almacenamiento (del mismo o de diferentes sistemas de almacenamiento) dentro de un clúster, cada uno con un conjunto personalizado de parámetros. Este diseño también garantiza que los usuarios finales no tengan que preocuparse por la complejidad y los matices de cómo se aprovisiona el almacenamiento, pero que aún tengan la capacidad de seleccionar entre múltiples opciones de almacenamiento. + +Puede encontrar más información sobre las clases de almacenamiento +[aqui](/docs/concepts/storage/storage-classes/). + +## Habilitación del aprovisionamiento dinámico + +Para habilitar el aprovisionamiento dinámico, un administrador de clúster debe crear previamente uno o más objetos StorageClass para los usuarios. Los objetos StorageClass definen qué aprovisionador se debe usar y qué parámetros se deben pasar a ese aprovisionador cuando se invoca el aprovisionamiento dinámico. +El nombre de un objeto StorageClass debe ser un +[nombre de subdominio de DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +El siguiente manifiesto crea una clase de almacenamiento "lenta" que aprovisiona discos persistentes estándar similares a discos. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +``` + +El siguiente manifiesto crea una clase de almacenamiento "rápida" que aprovisiona discos persistentes similares a SSD. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: fast +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-ssd +``` + +## Usar Aprovisionamiento Dinámico + +Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la annotation +`volume.beta.kubernetes.io/storage-class`. Sin embargo, esta anotación está obsoleta desde v1.9. Los usuarios ahora pueden y deben usar el campo +`storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador +(ver [below](#habilitación-del-aprovisionamiento-dinámico)). + +Para seleccionar la clase de almacenamiento "rápido", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: claim1 +spec: + accessModes: + - ReadWriteOnce + storageClassName: fast + resources: + requests: + storage: 30Gi +``` + +Esta afirmación da como resultado que se aprovisione automáticamente un disco persistente similar a SSD. Cuando se elimina la reclamación, se destruye el volumen. + +## Comportamiento Predeterminado + +El aprovisionamiento dinámico se puede habilitar en un clúster de modo que todos los reclamos se aprovisionen dinámicamente si no se especifica una clase de almacenamiento. Un administrador de clúster puede habilitar este comportamiento al: + +- Marcar un objeto `StorageClass` como _default_; +- Asegúrese de que el [controlador de admisión `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) esté habilitado en el servidor de API. + +Un administrador puede marcar un `StorageClass` específico como predeterminada agregando la anotación +`storageclass.kubernetes.io/is-default-class`. +Cuando existe un `StorageClass` predeterminado en un clúster y un usuario crea un +`PersistentVolumeClaim` con `storageClassName` sin especificar, el controlador de admisión +`DefaultStorageClass` agrega automáticamente el campo +`storageClassName` que apunta a la clase de almacenamiento predeterminada. + +Tenga en cuenta que puede haber como máximo una clase de almacenamiento _default_, o un `PersistentVolumeClaim` sin `storageClassName` especificado explícitamente. + +## Conocimiento de la Topología + +En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los pods. Esto se puede lograr configurando el [Volume Binding +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From a03d2ea8e19f776b68dd679f870fc3add54422c9 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:11:33 -0500 Subject: [PATCH 04/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md thanks for this Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index e0a8f83960..3883f9c323 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -11,7 +11,7 @@ weight: 40 El aprovisionamiento dinámico de volúmenes permite crear volúmenes de almacenamiento bajo demanda. Sin el aprovisionamiento dinámico, los administradores de clústeres tienen que realizar llamadas manualmente a su proveedor de almacenamiento o nube para crear nuevos volúmenes de almacenamiento y luego crear [objetos de `PersistentVolume`](/docs/concepts/storage/persistent-volumes/) -para representarlos en Kubernetes. La función de aprovisionamiento dinámico elimina la necesidad de que los administradores del clúster aprovisionen previamente el almacenamiento. En cambio cuando lo solicitan los usuarios aprovisionan el almacenamiento es automático. +para representarlos en Kubernetes. La función de aprovisionamiento dinámico elimina la necesidad de que los administradores del clúster aprovisionen previamente el almacenamiento. En cambio, el aprovisionamiento ocurre automáticamente cuando los usuarios lo solicitan. From b63b180d2d948ee6c2b21e84faee4d83e72910c8 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:16:59 -0500 Subject: [PATCH 05/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md Great! :) Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 3883f9c323..0bf6403e0b 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -31,7 +31,7 @@ Para habilitar el aprovisionamiento dinámico, un administrador de clúster debe El nombre de un objeto StorageClass debe ser un [nombre de subdominio de DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. -El siguiente manifiesto crea una clase de almacenamiento "lenta" que aprovisiona discos persistentes estándar similares a discos. +El siguiente manifiesto crea una clase de almacenamiento llamada "slow" que aprovisiona discos persistentes estándar similares a discos. ```yaml apiVersion: storage.k8s.io/v1 From 4d126eb89bdbc82248c7cf1b404d467ef2bc5087 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:17:40 -0500 Subject: [PATCH 06/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 0bf6403e0b..cf3708accd 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -43,7 +43,7 @@ parameters: type: pd-standard ``` -El siguiente manifiesto crea una clase de almacenamiento "rápida" que aprovisiona discos persistentes similares a SSD. +El siguiente manifiesto crea una clase de almacenamiento llamada "fast" que aprovisiona discos persistentes similares a SSD. ```yaml apiVersion: storage.k8s.io/v1 From 47fd2b3de5658b3b40cc7052241ccc493e8d89c2 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:18:45 -0500 Subject: [PATCH 07/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index cf3708accd..b0e5216cce 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -57,7 +57,7 @@ parameters: ## Usar Aprovisionamiento Dinámico -Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la annotation +Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la anotación `volume.beta.kubernetes.io/storage-class`. Sin embargo, esta anotación está obsoleta desde v1.9. Los usuarios ahora pueden y deben usar el campo `storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador (ver [below](#habilitación-del-aprovisionamiento-dinámico)). From 926be5786e1050a6a2a951131faff47a81e1af64 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:21:26 -0500 Subject: [PATCH 08/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index b0e5216cce..25aeca28e2 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -62,7 +62,7 @@ Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir un `storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador (ver [below](#habilitación-del-aprovisionamiento-dinámico)). -Para seleccionar la clase de almacenamiento "rápido", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: +Para seleccionar la clase de almacenamiento llamada "fast", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: ```yaml apiVersion: v1 From dde74945b9c61177bb193945d1f0de340773cce6 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:22:15 -0500 Subject: [PATCH 09/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 25aeca28e2..77e4bd66d9 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -78,7 +78,7 @@ spec: storage: 30Gi ``` -Esta afirmación da como resultado que se aprovisione automáticamente un disco persistente similar a SSD. Cuando se elimina la reclamación, se destruye el volumen. +Esta afirmación da como resultado que se aprovisione automáticamente un disco persistente similar a SSD. Cuando se elimina la petición, se destruye el volumen. ## Comportamiento Predeterminado From 907020f85f634c5294f6d0aff36cdac15ebe7f6d Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:22:54 -0500 Subject: [PATCH 10/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 77e4bd66d9..0e227627a2 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -82,7 +82,7 @@ Esta afirmación da como resultado que se aprovisione automáticamente un disco ## Comportamiento Predeterminado -El aprovisionamiento dinámico se puede habilitar en un clúster de modo que todos los reclamos se aprovisionen dinámicamente si no se especifica una clase de almacenamiento. Un administrador de clúster puede habilitar este comportamiento al: +El aprovisionamiento dinámico se puede habilitar en un clúster de modo que todas las peticiones se aprovisionen dinámicamente si no se especifica una clase de almacenamiento. Un administrador de clúster puede habilitar este comportamiento al: - Marcar un objeto `StorageClass` como _default_; - Asegúrese de que el [controlador de admisión `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) esté habilitado en el servidor de API. From 838df6cfccce890dc6b0a0c74848851baba24ab4 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:23:35 -0500 Subject: [PATCH 11/31] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 0e227627a2..cdff9b48e1 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -98,5 +98,5 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología -En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los pods. Esto se puede lograr configurando el [Volume Binding +En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From 50f945de77bdb114553c01013a45fe149dc0c939 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:23:59 -0500 Subject: [PATCH 12/31] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index a29f4810df..24616f1aba 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -28,7 +28,7 @@ text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: - son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. + son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): cuando se establece en `true`, el scheduler de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. From f206df1b2e7b1ae06501036520df9a557591c20c Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:24:15 -0500 Subject: [PATCH 13/31] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 24616f1aba..0e95978c2d 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -61,7 +61,7 @@ Debido a que Kubernetes pudo haber elegido un nodo basándose en información de El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. -Una situación en la que la programación puede fallar de forma permanente es cuando un pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ +Una situación en la que la programación puede fallar de forma permanente es cuando un Pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. ## Habilitación del seguimiento de la capacidad de almacenamiento From 2a2f973907c6704d5a17dd2722a3990b37f4d159 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:27:00 -0500 Subject: [PATCH 14/31] Update content/es/docs/concepts/storage/volume-pvc-datasource.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-pvc-datasource.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md index 29de717f0e..80608ef2bb 100644 --- a/content/es/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -14,7 +14,7 @@ Este documento describe el concepto para clonar volúmenes CSI existentes en Kub -## Introduction +## Introducción La función de clonación de volumen {{< glossary_tooltip text="CSI" term_id="csi" >}} agrega soporte para especificar {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s existentes en el campo `dataSource` para indicar que un usuario desea clonar un {{< glossary_tooltip term_id="volume" >}}. From 202b2ad646fd8c471a6ff9be52112089fcf5be91 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:27:28 -0500 Subject: [PATCH 15/31] Update content/es/docs/concepts/storage/volume-pvc-datasource.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-pvc-datasource.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md index 80608ef2bb..2cc1252581 100644 --- a/content/es/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -27,7 +27,7 @@ Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: - El soporte de clonación (`VolumePVCDataSource`) sólo está disponible para controladores CSI. - El soporte de clonación sólo está disponible para aprovisionadores dinámicos. - Los controladores CSI pueden haber implementado o no la funcionalidad de clonación de volúmenes. -- Sólo puede clonar un PVC cuando existe en el mismo espacio de nombres que el PVC de destino (el origen y el destino deben estar en el mismo espacio de nombres). +- Sólo puede clonar un PVC cuando existe en el mismo Namespace que el PVC de destino (el origen y el destino deben estar en el mismo Namespace). - La clonación sólo se admite dentro de la misma Clase de Almacenamiento. - El volumen de destino debe ser de la misma clase de almacenamiento que el origen - Se puede utilizar la clase de almacenamiento predeterminada y se puede omitir storageClassName en la especificación From 31581e5884b343988da5e988710af61c531e6f5b Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:27:37 -0500 Subject: [PATCH 16/31] Update content/es/docs/concepts/storage/volume-pvc-datasource.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-pvc-datasource.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md index 2cc1252581..dcb2690d0e 100644 --- a/content/es/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -35,7 +35,7 @@ Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: ## Aprovisionamiento -Los clones se aprovisionan como cualquier otro PVC con la excepción de agregar un origen de datos que hace referencia a un PVC existente en el mismo espacio de nombres. +Los clones se aprovisionan como cualquier otro PVC con la excepción de agregar un origen de datos que hace referencia a un PVC existente en el mismo Namespace. ```yaml apiVersion: v1 From 7f4fdd57e35db256c22e2c527d1c2ea889902d76 Mon Sep 17 00:00:00 2001 From: edithturn Date: Sun, 24 Oct 2021 21:30:53 -0500 Subject: [PATCH 17/31] fixing word in link --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index cdff9b48e1..2a8b40461a 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -60,7 +60,7 @@ parameters: Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la anotación `volume.beta.kubernetes.io/storage-class`. Sin embargo, esta anotación está obsoleta desde v1.9. Los usuarios ahora pueden y deben usar el campo `storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador -(ver [below](#habilitación-del-aprovisionamiento-dinámico)). +(ver [documentación](#habilitación-del-aprovisionamiento-dinámico)). Para seleccionar la clase de almacenamiento llamada "fast", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: From 02b3b8e4cb407e26c6e949278d927080f65a9e3d Mon Sep 17 00:00:00 2001 From: Edith Puclla Date: Tue, 26 Oct 2021 10:13:09 -0500 Subject: [PATCH 18/31] test --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 2a8b40461a..3aa777a305 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) From 7336477aeddf031410e1d89c9a56b06f3b728a8f Mon Sep 17 00:00:00 2001 From: Edith Puclla Date: Tue, 26 Oct 2021 10:25:58 -0500 Subject: [PATCH 19/31] adding point at the end --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 3aa777a305..2a8b40461a 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From 141bce454fdb05575e9aedb7074aad355136f958 Mon Sep 17 00:00:00 2001 From: edithturn Date: Fri, 29 Oct 2021 14:55:31 -0500 Subject: [PATCH 20/31] test cla --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 2a8b40461a..3aa777a305 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) From eb6efadf1a14cdb66aec14c72b8e1d3813e89ede Mon Sep 17 00:00:00 2001 From: edithturn Date: Fri, 29 Oct 2021 14:56:01 -0500 Subject: [PATCH 21/31] test cla --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 3aa777a305..2a8b40461a 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From f7add99775c21702e065e5fd80202adc48e3849e Mon Sep 17 00:00:00 2001 From: edithturn Date: Tue, 16 Nov 2021 12:43:18 -0500 Subject: [PATCH 22/31] change scheduler with planificador --- content/es/docs/concepts/storage/storage-capacity.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 0e95978c2d..e210b058a7 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -30,11 +30,11 @@ Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): - cuando se establece en `true`, el scheduler de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. + cuando se establece en `true`, el Planificador de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. ## Planificación -El scheduler de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: +El Planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: - la puerta de la característica `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, @@ -43,10 +43,10 @@ El scheduler de Kubernetes utiliza la información sobre la capacidad de almacen y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. -En ese caso, el scheduler sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. +En ese caso, el Planificador sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador de almacenamiento decide dónde crear el volumen, independientemente de los pods que usarán el volumen. -Luego, el scheduler programa los pods en los nodos donde el volumen está disponible después de que se haya creado. +Luego, el Planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), la programación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. @@ -55,7 +55,7 @@ la programación siempre ocurre sin considerar la capacidad de almacenamiento. E Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. -Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el scheduler de Kubernetes intenta nuevamente encontrar un nodo para el Pod. +Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el Planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. ## Limitationes @@ -73,4 +73,4 @@ El seguimiento de la capacidad de almacenamiento es una función beta y está ha - Para obtener más información sobre el diseño, consulte las [Restricciones de Capacidad de Almacenamiento para la Programación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). - Para obtener más información sobre un mayor desarrollo de esta función, consulte [problema de seguimiento de mejoras #1472](https://github.com/kubernetes/enhancements/issues/1472). -- Aprender sobre [Scheduler de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) +- Aprender sobre [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) From 3fe43ea98af1917a7a57c8a2524d18ecdca7fe7c Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:54:17 -0500 Subject: [PATCH 23/31] Update content/es/docs/concepts/storage/storage-capacity.md thank you! Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index e210b058a7..b1e0c089aa 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -36,7 +36,7 @@ Hay dos extensiones de API para esta función: El Planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: -- la puerta de la característica `CSIStorageCapacity` es `true`, +- la Feature Gate de `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, - ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), From a6b8f76520613ae237f28231aa66126b341b918c Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:55:18 -0500 Subject: [PATCH 24/31] Update content/es/docs/concepts/storage/storage-capacity.md Thanks! Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index b1e0c089aa..686be63120 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -38,8 +38,7 @@ El Planificador de Kubernetes utiliza la información sobre la capacidad de alma - la Feature Gate de `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, -- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding - mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el [modo de enlace de volumen](/docs/concepts/storage/storage-classes/#volume-binding-mode) `WaitForFirstConsumer` , y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. From 1b1a5b30b4be7baf327dc9af3fdd25d2b76e666a Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:55:56 -0500 Subject: [PATCH 25/31] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 686be63120..fb24479eb7 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -56,7 +56,7 @@ Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el Planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. -## Limitationes +## Limitaciones El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. From c7a7a60a0ddb9b099fdea4de6a36b730459ec29f Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:56:06 -0500 Subject: [PATCH 26/31] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index fb24479eb7..bdadd7d541 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -58,7 +58,7 @@ Debido a que Kubernetes pudo haber elegido un nodo basándose en información de ## Limitaciones -El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. +El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. Una situación en la que la programación puede fallar de forma permanente es cuando un Pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. From 951f21f79239baee9785ff858a56863e6cb7ffe2 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 17:07:59 -0500 Subject: [PATCH 27/31] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index bdadd7d541..d28a6ca149 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -15,7 +15,7 @@ La capacidad de almacenamiento es limitada y puede variar según el nodo en el q {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} -Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el programador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. +Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el planificador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. El seguimiento de la capacidad de almacenamiento es compatible con los controladores de la {{< glossary_tooltip text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y From 131258881d91d7f548dddb2ec77c286dce024429 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 9 Jan 2022 00:25:04 -0500 Subject: [PATCH 28/31] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Emilano Vazquez --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index d28a6ca149..912ae39a53 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -48,7 +48,7 @@ Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador Luego, el Planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), -la programación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. +la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes ## Reprogramar From e1080031f58c8ca0120a97ade9410101047c6b99 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 9 Jan 2022 00:25:15 -0500 Subject: [PATCH 29/31] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Emilano Vazquez --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 912ae39a53..75b197d2dd 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -50,7 +50,7 @@ Luego, el Planificador programa los pods en los nodos donde el volumen está dis Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes -## Reprogramar +## Replanificar Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. From 5d255db39e70e0860e08e04ea4d239f22a2e705e Mon Sep 17 00:00:00 2001 From: edithturn Date: Sun, 9 Jan 2022 00:34:11 -0500 Subject: [PATCH 30/31] removing version v1.19 --- .../docs/concepts/storage/storage-capacity.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 75b197d2dd..43996dc3e3 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -12,10 +12,9 @@ weight: 45 La capacidad de almacenamiento es limitada y puede variar según el nodo en el que un Pod se ejecuta: es posible que no todos los nodos puedan acceder al almacenamiento conectado a la red o que, para empezar, el almacenamiento sea local en un nodo. -{{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} -Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el planificador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. +Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el planificador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el planificador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de planificación. El seguimiento de la capacidad de almacenamiento es compatible con los controladores de la {{< glossary_tooltip text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y @@ -28,39 +27,40 @@ text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: - son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. + son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): - cuando se establece en `true`, el Planificador de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. + cuando se establece en `true`, el [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. ## Planificación -El Planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: +El planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: -- la Feature Gate de `CSIStorageCapacity` es `true`, +- la puerta de la característica `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, -- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el [modo de enlace de volumen](/docs/concepts/storage/storage-classes/#volume-binding-mode) `WaitForFirstConsumer` , +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding + mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. -En ese caso, el Planificador sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. +En ese caso, el planificador sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador de almacenamiento decide dónde crear el volumen, independientemente de los pods que usarán el volumen. -Luego, el Planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. +Luego, el planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), -la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes +la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. -## Replanificar +## Replanificación Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. -Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el Planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. +Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. -## Limitaciones +## Limitationes -El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. +El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la planificación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la planificación sin información de capacidad de almacenamiento es manejado por los errores de planificación. -Una situación en la que la programación puede fallar de forma permanente es cuando un Pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ +Una situación en la que la planificación puede fallar de forma permanente es cuando un pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. ## Habilitación del seguimiento de la capacidad de almacenamiento @@ -70,6 +70,6 @@ El seguimiento de la capacidad de almacenamiento es una función beta y está ha ## {{% heading "whatsnext" %}} - Para obtener más información sobre el diseño, consulte las - [Restricciones de Capacidad de Almacenamiento para la Programación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). + [Restricciones de Capacidad de Almacenamiento para la Planificación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). - Para obtener más información sobre un mayor desarrollo de esta función, consulte [problema de seguimiento de mejoras #1472](https://github.com/kubernetes/enhancements/issues/1472). - Aprender sobre [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) From 46e0d1b69b94badccab78a1f9e92b353e4a0d59f Mon Sep 17 00:00:00 2001 From: edithturn Date: Tue, 11 Jan 2022 17:19:47 -0500 Subject: [PATCH 31/31] solved Victor's feedback --- content/es/docs/concepts/storage/storage-capacity.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 43996dc3e3..e729232844 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -27,7 +27,7 @@ text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: - son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. + son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): cuando se establece en `true`, el [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. @@ -35,10 +35,9 @@ Hay dos extensiones de API para esta función: El planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: -- la puerta de la característica `CSIStorageCapacity` es `true`, +- la Feature gate de `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, -- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding - mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el [modo de enlace de volumen] (/docs/concepts/storage/storage-classes/#volume-binding-mode)`WaitForFirstConsumer`, y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. @@ -56,7 +55,7 @@ Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. -## Limitationes +## Limitaciones El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la planificación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la planificación sin información de capacidad de almacenamiento es manejado por los errores de planificación.