From 1fb6685925764ab7f605e9b22f40c85b936f3a51 Mon Sep 17 00:00:00 2001 From: Zhang Yong Date: Sun, 28 Mar 2021 11:05:23 +0800 Subject: [PATCH 01/79] Fix line separation in concepts/architecture/nodes --- content/fr/docs/concepts/architecture/nodes.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/fr/docs/concepts/architecture/nodes.md b/content/fr/docs/concepts/architecture/nodes.md index fd211a1a35..b6718c6750 100644 --- a/content/fr/docs/concepts/architecture/nodes.md +++ b/content/fr/docs/concepts/architecture/nodes.md @@ -141,6 +141,7 @@ Sinon, le contrôleur de nœud supprime le nœud de sa liste de nœuds. La troisième est la surveillance de la santé des nœuds. Le contrôleur de noeud est responsable de la mise à jour de la condition NodeReady de NodeStatus vers ConditionUnknown lorsqu'un noeud devient inaccessible (le contrôleur de noeud cesse de recevoir des heartbeats pour une raison quelconque, par exemple en raison d'une panne du noeud), puis de l'éviction ultérieure de tous les pods du noeud. (en utilisant une terminaison propre) si le nœud continue d’être inaccessible. (Les délais d'attente par défaut sont de 40 secondes pour commencer à signaler ConditionUnknown et de 5 minutes après cela pour commencer à expulser les pods.) + Le contrôleur de nœud vérifie l'état de chaque nœud toutes les `--node-monitor-period` secondes. Dans les versions de Kubernetes antérieures à 1.13, NodeStatus correspond au heartbeat du nœud. @@ -157,6 +158,7 @@ Dans la plupart des cas, le contrôleur de noeud limite le taux d’expulsion à Le comportement d'éviction de noeud change lorsqu'un noeud d'une zone de disponibilité donnée devient défaillant. Le contrôleur de nœud vérifie quel pourcentage de nœuds de la zone est défaillant (la condition NodeReady est ConditionUnknown ou ConditionFalse) en même temps. Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à ` --large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde. + Ces stratégies sont implémentées par zone de disponibilité car une zone de disponibilité peut être partitionnée à partir du master, tandis que les autres restent connectées. Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité de fournisseur de cloud, il n'existe qu'une seule zone de disponibilité (la totalité du cluster). From b16ccb3d1d9db30015d49816818ba1c739c13c67 Mon Sep 17 00:00:00 2001 From: kartik494 Date: Wed, 9 Jun 2021 22:25:53 +0530 Subject: [PATCH 02/79] Adding output for ingress-nginx namespace --- .../ingress-minikube.md | 49 +++++++++++++------ 1 file changed, 35 insertions(+), 14 deletions(-) diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md index 5b3fd114b0..ce7d4d4dde 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md @@ -44,23 +44,44 @@ This page shows you how to set up a simple Ingress which routes requests to Serv 1. Verify that the NGINX Ingress controller is running - ```shell - kubectl get pods -n kube-system - ``` + {{< tabs name="tab_with_md" >}} + {{% tab name="minikube v1.19 or later" %}} +```shell +kubectl get pods -n ingress-nginx +``` + {{< note >}}This can take up to a minute.{{< /note >}} - {{< note >}}This can take up to a minute.{{< /note >}} +Output: - Output: +``` +NAME READY STATUS RESTARTS AGE +ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m +ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m +ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m +``` + {{% /tab %}} + + {{% tab name="minikube v1.18.1 or earlier" %}} +```shell +kubectl get pods -n kube-system +``` +{{< note >}}This can take up to a minute.{{< /note >}} + +Output: + +``` +NAME READY STATUS RESTARTS AGE +default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m +kube-addon-manager-minikube 1/1 Running 0 3m +kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m +kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m +nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m +storage-provisioner 1/1 Running 0 2m +``` + {{% /tab %}} + {{< /tabs >}} + - ```shell - NAME READY STATUS RESTARTS AGE - default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m - kube-addon-manager-minikube 1/1 Running 0 3m - kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m - kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m - nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m - storage-provisioner 1/1 Running 0 2m - ``` ## Deploy a hello, world app From b9252e59826f5b775f1aabc7b7b6755f42aa8769 Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Wed, 30 Jun 2021 23:38:30 +0530 Subject: [PATCH 03/79] Added ha-control-plane.svg --- static/images/docs/ha-control-plane.svg | 1 + 1 file changed, 1 insertion(+) create mode 100644 static/images/docs/ha-control-plane.svg diff --git a/static/images/docs/ha-control-plane.svg b/static/images/docs/ha-control-plane.svg new file mode 100644 index 0000000000..6667a91c2c --- /dev/null +++ b/static/images/docs/ha-control-plane.svg @@ -0,0 +1 @@ + \ No newline at end of file From 71507509b30c6fa28bc83ae67d68aa990622ae2f Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Thu, 1 Jul 2021 14:47:28 +0530 Subject: [PATCH 04/79] Update highly-available-control-plane.md --- .../tasks/administer-cluster/highly-available-control-plane.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md index a71fa4a45c..622b80ec57 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -133,7 +133,7 @@ the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-mi ## Implementation notes -![ha-master-gce](/images/docs/ha-master-gce.png) +![ha-control-plane](/images/docs/ha-control-plane.svg) ### Overview From 6cb9177e2bbbf9e69124b9fa588b1162047745aa Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Thu, 1 Jul 2021 15:07:17 +0530 Subject: [PATCH 05/79] Update ha-control-plane.svg --- static/images/docs/ha-control-plane.svg | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/static/images/docs/ha-control-plane.svg b/static/images/docs/ha-control-plane.svg index 6667a91c2c..eb5bbdba81 100644 --- a/static/images/docs/ha-control-plane.svg +++ b/static/images/docs/ha-control-plane.svg @@ -1 +1,4 @@ - \ No newline at end of file + + + + From 436d3fe8c49db1e74e4679096bde456bbe90f739 Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Wed, 14 Jul 2021 08:48:53 +0530 Subject: [PATCH 06/79] Update content/en/docs/tasks/administer-cluster/highly-available-control-plane.md Co-authored-by: chrismetz09 --- .../administer-cluster/highly-available-control-plane.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md index 622b80ec57..543abbfe44 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -136,7 +136,15 @@ the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-mi ![ha-control-plane](/images/docs/ha-control-plane.svg) ### Overview +The figure above illustrates three control plane nodes and their components in a highly available cluster. The control plane node’s components employ the following methods: +- etcd: instances are clustered together using consensus. + +- Controllers, scheduler and cluster auto-scaler: only one instance of each will be active in a cluster using a lease mechanism. + +- Add-on manager: each works independently to keep add-ons in sync. + +In addition, a load balancer operating in front of the API servers routes external and internal traffic to the control plane nodes. Each of the control plane nodes will run the following components in the following mode: * etcd instance: all instances will be clustered together using consensus; @@ -215,4 +223,3 @@ server coordination (for example, the `StorageVersionAPI` feature gate). [Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) - From d9e498250948c99df8ca6f6862bd0e2fb3e59a40 Mon Sep 17 00:00:00 2001 From: anyulled Date: Sat, 31 Jul 2021 11:52:20 +0200 Subject: [PATCH 07/79] docs: volumes - spanish translation --- content/es/docs/concepts/storage/volumes.md | 1334 +++++++++++++++++++ 1 file changed, 1334 insertions(+) create mode 100644 content/es/docs/concepts/storage/volumes.md diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md new file mode 100644 index 0000000000..536763e06b --- /dev/null +++ b/content/es/docs/concepts/storage/volumes.md @@ -0,0 +1,1334 @@ +--- +title: Volumes +content_type: concept +weight: 10 +--- + + + +Los ficheros en disco dentro de un contenedor son efímeros, lo cual presenta problemas +para aplicaciones no triviales cuando se ejecutan en contenedores. Un problema es la +pérdida de ficheros cuando el contenedor se cae. El kubelet reinicia el contenedor pero con un estado limpio. +Un segundo problema ocurre cuando compartimos ficheros entre contenedores corriendo juntos dentro de un `Pod`. La abstracción {{< glossary_tooltip text="volume" term_id="volume" >}} de Kubernetes resuelve ambos problemas. +Se sugiere familiaridad con [Pods](/docs/concepts/workloads/pods/) + + + +## Trasfondo + +Docker tiene el concepto de [volúmenes](https://docs.docker.com/storage/), aunque es algo más flojo y menos controlado. +Un volumen de docker es un directorio en disco o en otro contenedor. Docker provee controladores de volúmenes, pero la funcionalidad es algo limitada. + +Kubernetes soporta muchos tipos de volúmenes. Un {{< glossary_tooltip term_id="pod" text="Pod" >}} +puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el tiempo de vida de un pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un pod. Cuando un pod deja de existir, +Kubernetes destruye los volúmenes efímeros; sin embargo, Kubernetes no destruye los volúmenes persistentes. Para cualquier tipo de volumen en un pod dado, los datos son preservados a través de los reinicios del contenedor. + +En su núcleo, un volumen es un directorio, posiblemente con algunos datos en este, que puede ser accesible para los contenedores en un pod. Cómo ese directorio llega a crearse, el medio que lo respalda, y el contenido de este se determinan por el tipo de volumen usado. + +Para usar un volumen, especifica los volúmenes a proveer al por en `.spec.volumes` y declara +dónde montar estos volúmenes dentro de los contenedores en `.spec.containers[*].volumeMounts`. +Un proceso en el contenedor observa una vista del sistema de archivos compuesta por la imagen Docker y volúmenes. +La [imagen Docker](https://docs.docker.com/userguide/dockerimages/) está en la raíz de la jerarquía del sistema de archivos. +Los volúmenes se montan en las rutas especificadas dentro de la imagen. Los volúmenes no se pueden montar en otros volúmenes o tener enlaces duros a otros volúmenes. Cada contenedor en la configuración del Pod debe especificar de forma independiente donde montar cada volumen. + +## Tipos de volúmenes {#volume-types} + +Kubernetes soporta varios tipos de volúmenes + +### awsElasticBlockStore {#awselasticblockstore} + +Un volumen `awsElasticBlockStore` monta un +[volumen EBS](https://aws.amazon.com/ebs/) de Amazon Web Services (AWS) en tu pod. A diferencia de +`emptyDir`, que se borra cuando se quita un pod, el contenido de un volumen EBS es persistido cuando se desmonta el volumen. +esto significa que un volumen EBS puede ser prepoblado con datos, y que los datos puedes ser compartidos entre pods. + +{{< note >}} +Debes crear un volumen EBS usando `aws ec2 create-volume` o la API de AWS antes de poder usarlo. +{{< /note >}} + +Existen algunas restricciones cuando usas un volumen `awsElasticBlockStore`: + +- Los nodos en los que corren los pods deben ser instances AWS EC2. +- Estas instancias deben estar en la misma región y zona de disponibilidad que el volumen EBS +- EBS solo soporta una única instancia EC2 montando un volumen + +#### Creando un volumen AWS EBS + +Antes poder usar un volumen EBS en un pod, necesitas crearlo. + +```shell +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 +``` + +Asegúrate de que la zona coincide con la zona en que has creado el clúster. Revisa que el tamaño y el tipo de +volumen EBS son compatibles para tu uso. + +#### Ejemplo de configuración AWS EBS + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-ebs +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-ebs + name: test-volume + volumes: + - name: test-volume + # Este volumen EBS debe existir anteriormente. + awsElasticBlockStore: + volumeID: "" + fsType: ext4 +``` + +Si el volumen EBS está particionado, puedes suministrar el campo opcional `partition: ""` para especificar cuál partición montar. + +#### Migración CSI AWS EBS CSI + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +La función `CSIMigration` para `awsElasticBlockStore`, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `ebs.csi.aws.com`. Para utilizar esta función, el [controlador AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) debe ser instalado en el clúster y las características beta +`CSIMigration` y `CSIMigrationAWS` deben estar habilitadas. + +#### Migración CSI AWS EBS CSI completa + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +Para desactivar el complemento de almacenamiento `awsElasticBlockStore` de ser cargado por el administrador de controladores y el kubelet, establece el atributo `CSIMigrationAWSComplete` a `true`. Esta función requiere tener instalado el controlador de interfaz de almacenamiento del contenedor (CSI) en todos los nodos en obreros. + +### azureDisk {#azuredisk} + +El tipo de volumen `azureDisk` monta un [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) de Microsoft Azure en el pod. + +Para más detalles, mira el [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md). + +#### Migración CSI azureDisk + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +La función `CSIMigration` para `azureDisk`, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `disk.csi.azure.com`. Para utilizar esta función, el [controlador Azure Disk CSI](https://github.com/kubernetes-sigs/azuredisk-csi-driver) debe ser instalado en el clúster y las características beta +`CSIMigration` y `CSIMigrationAzureDisk` deben estar habilitadas. + +### azureFile {#azurefile} + +El tipo de volumen `azureFile` monta un volumen de ficheros de Microsoft Azure (SMB 2.1 and 3.0) en un pod. + +Para más detalles, mira el [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). + +#### Migración CSI azureFile CSI + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +La función `CSIMigration` para `azureFile`, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `file.csi.azure.com`. Para utilizar esta función, el [controlador Azure File CSI +Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) +debe ser instalado en el clúster y las [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigration` y `CSIMigrationAzureFile` deben estar habilitadas. + +El controlador Azure File CSI no soporta usar el mismo volumen con fsgroups diferentes, si está habilitadla migración CSI Azurefile, usar el mismo volumen con fsgorups diferentes no será compatible en absoluto. + +### cephfs + +Un volumen `cephfs` permite montar un volumen CephFS existente en tu Pod. +A diferencia de `emptydir`, que es borrado cuando se remueve el pod, el contenido de un volumen `cephfs` es preservado y el volumen es meramente desmontado. Esto significa que un volumen `cephfs`puede ser prepoblado por múltiples escritores simultáneamente. + +{{< note >}} +Debes tener tu propio seervidor Ceph corriendo con el recurso compartido exportado antes de usarlo. +{{< /note >}} + +Mira el [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) para más detalles. + +### cinder + +{{< note >}} +Kubernetes no debe ser configurado con el proveedor cloud OpenStack. +{{< /note >}} + +El tipo de volumen `cinder` se usa para montar un volumen Cinder de OpenStck en tu pod. + +#### Cinder volume configuration example + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-cinder +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-cinder-container + volumeMounts: + - mountPath: /test-cinder + name: test-volume + volumes: + - name: test-volume + # Este volumen de OpenStack debe existir anteriormente. + cinder: + volumeID: "" + fsType: ext4 +``` + +#### Migración CSI OpenStack + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +La función `CSIMigration` para Cinder está habilidata por defecto en Kubernetes 1.21. +Esta redirige todas las operaciones de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `cinder.csi.openstack.org`. +El controlador [OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) debe estar instalado en el clúster. + +Puedes deshabilitar la migración CSI para tu clúster estrableciendo el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigrationOpenStack` a `false`. +Si deshabilitas la función `CSIMigrationOpenStack`, el complemento del volumen Cinder dentro del árbol toma la responsablidad para todos los aspectos de la administración del almacenamiento del volumen Cinder. + +### configMap + +Un [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) +provee una manera de inyectar datos de configuración a los pods. +Los datos almacenados en un ConfigMap se pueden referenciar en un volumen de tipo `configMap` +y luego ser consumidos por aplicaciones contenerizadas corriendo en un pod. + +Cuando haces referencia a un ConfigMap, provees el nombre del ConfigMap en el volumen. +Puedes personalizar la ruta para una entrada específica en el ConfigMap. +La siguiente configuración muestra cómo montar un ConfigMap `log-config` en un Pod llamado `configmap-pod:` + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: test + image: busybox + volumeMounts: + - name: config-vol + mountPath: /etc/config + volumes: + - name: config-vol + configMap: + name: log-config + items: + - key: log_level + path: log_level +``` + +El ConfigMap `log-config` es montado como un volumen, y todo el contenido almacenado en su entrada `log_level` es +montado en el Pod en la ruta `/etc/config/log_level`. Ten en cuenta que esta ruta se deriva del `mountPath`del volumen y el `path` cuya clave es `log_level`. + +{{< note >}} + +- Debes crear un [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) antes de usarlo. +- Un contenedor usando un ConfigMap montado como un volumen [`subPath`](#using-subpath) no recibirá actualizaciones del ConfigMap +- Los datos de texto son expuestos como ficheros usando la codificación de caracteres UTF-8. Para otras codificaciones de caracteres, use `binaryData`. + {{< /note >}} + +### downwardAPI {#downwardapi} + +Un volumen de `downwardAPI` hace que los datos API descendentes estén disponibles para las aplicaciones. +Monta un directorio y escribe los datos solicitados en archivos de texto sin formato. + +{{< note >}} +Un contenedor usando la API descendiente montado como un volumen [`subPath`](#using-subpath) no recibirá actualizaciones API descendientes. +{{< /note >}} + +Mira el [downward API example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) para mayores detalles. + +### emptyDir {#emptydir} + +Un volumen `emptyDir`es creado primero cuando se asigna un pod a un nodo, y existe mientras el Pod está corriendo en el nodo. +Como su nombre lo indica un volumen `emptydir`está vacío inicialmente. Todos los contenedores en el Pod pueden leer y escribir +los mismos ficheros en el volumen `emptyDir`, aunque ese volumen se puede montar en la misma ruta o diferentes en cada contenedor. Cuando un Pod es removido del nodo por alguna razón, los datos en `emptydir` se borran permanentemente. + +{{< note >}} +Un contenedor que colapsa _no_ remueve el Pod del nodo. Los datos en un volumen `emptyDir` están seguros en caso de +colapso del contenedor. +{{< /note >}} + +Algunos usos para un `emptyDir` son: + +- Espacio temporal, como para una clasificación de combinación basada en disco +- Marcar un largo cálculo para la recuperación de fallos +- Contener archivos que un contenedor de administrador de contenido recupera mientras un contenedor de servidor web + sirve los datos + +Dependiendo de tu entorno, volúmenes `eptydir` se almacenan en cualquier medio que respalde el nodo tales como discoo SSD, o almacenamiento de red. Sin embargo, si estableces el campo `emptydir.medium` a `Memory`, Kubernetes monta en su lugar un tmpfs (sistema de ficheros respaldado por la RAM). Mientras que tmpfs es muy rápido, ten en cuenta que a diferencia de los discos, tmpfs se limpia cuando el nodo reinicia y cualquier fichero que escribas cuante contra el límite de memoria del contenedor. + +{{< note >}} +Si el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SizeMemoryBackedVolumes` está habilitado, +puedes especificar un tamaño para los volúmenes respaldados en memoria. Si no se especifica ningún tamaño los volúmenes respaldados en memoria tienen un tamaño del 50% de la memoria en un host Linux. + +{{< /note>}} + +#### ejemplo de configuración de emptyDir + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /cache + name: cache-volume + volumes: + - name: cache-volume + emptyDir: {} +``` + +### fc (canal de fibra) {#fc} + +Un tipo de volumen `fc` permite que un volumen de almacenamiento de bloque de canal de fibra existente se monte en un Pod. +Puede especificar nombres mundiales de destino únicos o múltiples (WWN) utilizando el parámetro `targetWWNs` en su configuración de Volumen. +Si se especifican varios WWN, targettWWNs esperan que esos WWN sean de conexiones de múltiples rutas. + +{{< note >}} +Debes configurar FC SAN zoning para asignar y enmascarar esos (volúmenes) LUNs para apuntar a los WWNs de destino de antemano +para que los hosts Kubernetes pueda acceder a ellos. +{{< /note >}} + +Revisa el [ejemplo de canal de fibra](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) para más detalles. + +### flocker (deprecado) {#flocker} + +[Flocker](https://github.com/ClusterHQ/flocker) es un administrador open-source de volúmenes de contenedor agrupado por clúster. +Flocker proporciona administración y orquestación de volúmenes de datos respaldados por una variedad de backends de almacenamiento. + +Un volumen `flocker` permite montar un conjunto de datos Flocker en un Pod. Si el conjunto de datos no existe en Flocker, necesita ser creado primero con el CLI de Flocker o usando la API de Flocker. Si el conjunto de datos existe será adjuntado +de nuevo por Flocker al nodo donde el pod está programado. Esto significa que los datos pueden ser compartidos entre pods como sea necesario. + +{{< note >}} +Debes tener una instalación propia de Flocker ejecutándose antes de poder usarla. +{{< /note >}} + +Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) para más detalles. + +### gcePersistentDisk + +Un volumen `gcePersistentDisk` monta un volumen de Google Compute Engine (GCE) +[persistent disk](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. +A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un DP es preservado +y el volumen solamente se desmonta. Esto significa que un PD puede ser prepoblado con datos, +y que esos datos se pueden compartir entre pods. + +{{< note >}} +Debes crear un PD usando `gcloud` or la API de GCE o la UI antes de poder usarlo. +{{< /note >}} + +Existen algunas restricciones cuando usas `gcePersistentDisk`: + +- Los nodos en los que se ejecutan los pods deben ser máquinas virtuales GCE. +- Esas máquinas virtuales deben estar en el mismo proyecto GCE y zona que el disco persistente. + +Una de las características del disco persistente CGE es acceso concurrente de solo lectura al disco persistente. +Un volumen `gcePersistentDisk` permite montar simultáneamente un disco de solo lectura a múltiples consumidores. +Esto significa que puedes pr-epoblar un DP con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los DPs solo se pueden montar por un único consumidor en modo lectura-escritura. +No están permitidos escritores simultáneos. + +Usar un disco persistente GCE con un Pod controlado por un ReplicaSet fallará a manos que el DP sea de solo lectura o el número de réplicas sea 0 o 1. + +#### Creando un disco persistente GCE {#gce-create-persistent-disk} + +Antes de poder usar un disco persistente GCE en un Pod, necesitas crearlo. + +```shell +gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk +``` + +#### Ejemplo de configuración de un disco persistente GCE + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # Este PD GCE debe existir con anterioridad. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### Discos regionales persistentes + +La función de [discos regionales persistentes](https://cloud.google.com/compute/docs/disks/#repds) +permite la creación de discos persistentes que están disponibles en dos zonas dentro de la misma región. +Para usar esta función, el volumen debe ser provisto como un PersistentVolumen; referenciar el volumen directamente desde un pod no está soportado. + +#### Aprovisionamiento manual de un PD PersistentVolume Regional + +El aprovisionamiento dinámico es posible usando un [StorageClass para el DP GCE](/docs/concepts/storage/storage-classes/#gce). +Antes de crear un PersistentVolume, debes crear el disco persistente: + +```shell +gcloud compute disks create --size=500GB my-data-disk + --region us-central1 + --replica-zones us-central1-a,us-central1-b +``` + +#### Ejemplo de configuración de un disco persistente regional + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b +``` + +#### Migración CSI GCE + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +La función `CSIMigration` para el DP GCE, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `pd.csi.storage.gke.io`. Para poder usar esta función, el [controlador PD GCE](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) debe ser instalado en el clúster y habilitar las funciones beta +`CSIMigration` y `CSIMigrationGCE`. + +### gitRepo (deprecado) {#gitrepo} + +{{< warning >}} +El volumen `gitRepo` está deprecado. Para aprovisionar un contenedor con un repositorio git, monta un [EmptyDir](#emptydir) en un InitContainer que clona un repositorio usando git, luego monta el [EmptyDir](#emptydir) en el contenedor del Pod. +{{< /warning >}} + +Un volumen `gitRepo` es un ejemplo de un complemento de volumen. Este complemento monta un directorio vacío y clona un repositorio git en este directorio para que tu Pod pueda usarlo. + +Aquí un ejemplo de un volumen `gitrepo`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: server +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /mypath + name: git-volume + volumes: + - name: git-volume + gitRepo: + repository: "git@somewhere:me/my-git-repository.git" + revision: "22f1d8406d464b0c0874075539c1f2e96c253775" +``` + +### glusterfs + +Un volumen `glusterfs` permite montar un volumen [Glusterfs](https://www.gluster.org) en tu Pod. +A diferencia de `emptyDir`, que se borra cuando se remueve un pod, el contenido de un volumen `glusterfs` es preservado +y el volumen solamente se desmonta. Esto significa que un volumen glusterfs puede ser pre-poblado con datos, +y que los datos pueden ser compartidos entre pods. GlusterFS puede ser montado por múltiples escritores simultáneamente. + +{{< note >}} +Debes tener tu propia instalación de GlusterFS ejecutándose antes de poder usarla. +{{< /note >}} + +Mira el [ejemplo de GlusterFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) para más detalles. + +### hostPath {#hostpath} + +Un volumen `hostPath` mona un fichero o un directorio del sistema de archivos del nodo host a tu Pod. +Esto no es algo de muchos Pods necesiten, pero ofrece una trampa de escape poderosa para algunas aplicaciones. + +Por ejemplo, algunos usos de un `hostPath` son: + +- ejecutar un contenedor que necesita acceso a los directorios internos de docker, usa un `hostPath` de `/var/lib/docker` +- ejecutar un cAdvisor en un contenedor; usa un `hostPath` de `/sys` +- permitir a un Pod especificar si un `hostPath` dado debería existir ante de correr el Pod, si debe crearse, cómo debe existir + +Además de la propiedad requerida `path`, puedes especificar opcionalmente un `tipo`para un volumen `hostPath`. + +Los valores soportados para el campo `tipo` son: + +| Valor | Comportamiento | +| :------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| | Una cadena vacía (por defecto) es para compatibilidad con versiones anteriores, lo que significa que no se harán revisiones antes de montar el volumen hostPath. | +| `DirectoryOrCreate` | Si no hay nada en la ruta dada, se creará un directorio vacío como es requerido con los permisos a 0755, teniendo el mismo grupo y propiedad que el Kubelet. | +| `Directory` | Un directorio debe existir en la ruta dada | +| `FileOrCreate` | Si no hay nada en la ruta dada, se creará un fichero vacío como es requerido con los permisos a 0644, teniendo el mismo grupo y propiedad que el Kubelet. | +| `File` | Un fichero debe existir en la ruta dada | +| `Socket` | Un socket de UNIX debe existir en la ruta dada | +| `CharDevice` | Un dispositivo de caracteres debe existir en la ruta data | +| `BlockDevice` | Un dispositivo de bloques dbe existir en la ruta dada | + +Ten cuidado cuando uses este tipo de volumen, porque: + +- Los Pods con configuración idéntica (tales como los creados por un PodTemplate) pueden comportarse de forma distinta + en nodos distintos debido a diferentes ficheros en los nodos. +- Los ficheros o directorios creados en los host subyacentes son modificables solo por root. Debes ejecutar tu proceso como root en un [Contenedor privilegiado](/docs/tasks/configure-pod-container/security-context/) o modificar los permisos de archivo en el host para escribir a un volumen `hostPath` + +#### Ejemplo de configuración hostPath + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + hostPath: + # localización del directorio en el host + path: /data + # este campo es opcional + type: Directory +``` + +{{< caution >}} +El modo `FileOrCreate` no crea el directorio padre del fichero. Si el directorio padre del fichero montado no existe, +el pod falla en iniciar. Para asegurar que este modo funciona, puedes intentar montar directorios y ficheros de forma separada, +tal como se muestra en la [ confugiración `FileOrCreate`](#hostpath-fileorcreate-example) +{{< /caution >}} + +#### ejemplo de configuración hostPath FileOrCreate {#hostpath-fileorcreate-example} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-webserver +spec: + containers: + - name: test-webserver + image: k8s.gcr.io/test-webserver:latest + volumeMounts: + - mountPath: /var/local/aaa + name: mydir + - mountPath: /var/local/aaa/1.txt + name: myfile + volumes: + - name: mydir + hostPath: + # Asegúrate que el directorio del fichero es creado. + path: /var/local/aaa + type: DirectoryOrCreate + - name: myfile + hostPath: + path: /var/local/aaa/1.txt + type: FileOrCreate +``` + +### iscsi + +Un volumen `iscsi` permite que se monte un volumen ISCSI (SCSI sobre IP) existente +en tu Pod. A diferencia de `emptydir`, que es removido cuando se remueve un Pod, +el contenido de un volumen `iscsi` es preservado y el volumen solamente se desmonta. +Esto significa que un volumen iscsi puede ser pre-poblado con dato, y que estos datos se pueden compartir entre pods. + +{{< note >}} +Debes tener tu propio servidor ISCSI corriendo con el volumen creado antes de poder usarlo. +{{< /note >}} + +Una función de SCSI es que puede ser montado como de solo lectura por múltiples consumidores simultáneamente. +Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y servirlo en paralelo para tantos Pods como necesites. +Desafortunadamente, los volúmenes ISCSI solo se pueden montar por un único consumidor en modo lectura-escritura. +Escritores simultáneos no está permitido. + +Mira el [ ejemplo iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) para más detalles. + +### local + +Un volumen `local` representa un dispositivo de almacenamiento local como un dico, una partición o un directorio. + +Los volúmenes locales solo se pueden usar como un PersistenVolume creado estáticamente. +El aprovisionamiento dinámico no está soportado. + +Comparados con volúmenes `hostPath`, los volúmenes `local` se usan de manera duradera y portátil sin programar pods manualmente +a los nodos. El sistema está consciente de las limitaciones del nodo del volumen al mirar la afinidad del nodo en el PersistenVolumen. + +Sn embargo, los volúmenes `local`están sujetos a la disponibilidad del nodo subyacente y no son compatibles para todas las aplicaciones. + +Si un nodo deja de estar sano, entonces el volumen `local` se vuelve inaccesible al pod. +El pod que utiliza este volumen no se puede ejecutar. +Las aplicaciones que usan volúmenes `local` deben ser capaces de tolerar esta disponibilidad reducida, +así como la pérdida potencial de datos, dependiendo de las características de durabilidad del disco subyacente. + +El siguiente ejemplo muestra un PersistentVolume usando un volumen `local`y `nodeAffinity`: + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: example-pv +spec: + capacity: + storage: 100Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: local-storage + local: + path: /mnt/disks/ssd1 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/hostname + operator: In + values: + - example-node +``` + +Debes establecer un valor de `nodeAffinity` del PersistenVolume cuando uses volúmenes `local`. +El programador de Kubernetes usa esta `nodeaffinity` del PersistenVolume para programar estos Pods al nodo correcto. + +El `volumeMode` del PersistentVolume se puede establecer en "Block" (en lugar del valor por defecto, "Filesystem") +para exponer el volumen local como un dispositivo de bloque sin formato. + +Cuando usas volúmenes locales, se recomienda crear un StorageClass con `volumeBindingMode` en `WaitForFirstConsumer`. +Para más detalles, mira el ejemplo de [StorageClass](/docs/concepts/storage/storage-classes/#local). Retrasar el enlace con el volumen asegura que la decisión del PersistenVolumeClaim sea evaluada con otras limitaciones que el Pod pueda tener, +tales como requisitos de recuersos del nodo, selectores de nodo, afinidad del Pod, y anti-afinidad del Pod. + +Se puede ejecutar un aprovisionador estático externo para un manejo mejorado del ciclo de vida del volumen local. +Ten en cuenta que este aprovisionador no soporta aprovisionamiento dinámico todavía. Para un ejemplo de un aprovisionador local externo, mira la [guía de usuario de aprovisionador de volumen local](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) + +{{< note >}} +El PersistentVolume local requiere limpieza y borrado manual por el usuario si no se utiliza el aprovisionador estático externo +para manejar el ciclo de vida del volumen. +{{< /note >}} + +### nfs + +Un volumen `nfs` permite montar un NFS (Sistema de Ficheros de Red) compartido en tu Pod. +A diferencia de `emptyDir` que se borra cuando el Pod es removido, el contenido de un volumen `nfs` solamente se desmonta. +Esto significa que un volumen NFS puede ser pre-poblado con datos, y que estos datos puedes ser compartidos entre pods. +NFS puede ser montado por múltiples escritores simultáneamente. + +{{< note >}} +Debes tener tu propio servidor NFS en ejecución con el recurso compartido exportado antes de poder usarlo. +{{< /note >}} + +Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) para más información. + +### persistentVolumeClaim {#persistentvolumeclaim} + +Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del ambiente de la nube en particular. + +Mira la información spbre [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) para más detalles. + +### portworxVolume {#portworxvolume} + +Un `portworxVolume` es un almacenamiento de bloque elástico que corre hiperconvergido con Kubernetes. +Almacenamiento de huellas de [Portworx](https://portworx.com/use-case/kubernetes-storage/) en un servidor, niveles basados en capacidades y capacidad agregada en múltiples servidores. +Portworx se ejecuta como invitado en máquinas virtuales o en nodos Linux nativos. + +Un `portworxVolume` puede ser creado dinámicamente a través de Kubernetes o puede ser pre-aprovisionado y referido dentro de un Pod. Aquí un Pod de ejemplo refiriendo a un volumen Portworx pre-aprovisionado: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # Este volumen portworx debe sxistir con anterioridad. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< note >}} +Asegúrate de tener un PortworxVolume con el nombre `pxvol` antes de usarlo en el Pod. +{{< /note >}} + +Para más detalles, mira los ejemplos de [volumen Portworx](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md). + +### projected + +Un volumen `projected` mapea distintas fuentes de volúmenes existentes en un mismo directorio. + +Actualmente, se pueden los siguientes tipos de volúmenes: + +- [`secret`](#secret) +- [`downwardAPI`](#downwardapi) +- [`configMap`](#configmap) +- `serviceAccountToken` + +Se requiere que todas las fuentes estén en el mismo namespace que el Pod. Para más detalles mira el [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). + +#### Configuración de ejemplo con un secret, un downwardAPI, y un configMap {#example-configuration-secret-downwardapi-configmap} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "cpu_limit" + resourceFieldRef: + containerName: container-test + resource: limits.cpu + - configMap: + name: myconfigmap + items: + - key: config + path: my-group/my-config +``` + +#### Configuración de ejemplo: secrets con un modo de permisos no predeterminados {#example-configuration-secrets-nondefault-permission-mode} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - secret: + name: mysecret2 + items: + - key: password + path: my-group/my-password + mode: 511 +``` + +Cada volumen proyectado está listado en spec bajo `sources`. Los parámetros son casi los mismos salvo dos excepciones: + +- Para los secrets, el campo `secretName` ha sido cambiado a `name` para ser consistente con el nombre del configMap. +- El `defaultMode` solo se puede especificar en el nivel proyectado y no para cada fuente de volumen. Sin, como se muestra arriba, puedes establecer explicaitamente el `mode` para cada proyección individual. + +Cuando la función `TokenRequestProjection` está habilitada, puedes inyectar el token para el [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens) actual en un Pod en la ruta especificada. +Por ejemplo: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: sa-token-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: token-vol + mountPath: "/service-account" + readOnly: true + volumes: + - name: token-vol + projected: + sources: + - serviceAccountToken: + audience: api + expirationSeconds: 3600 + path: token +``` + +El Pod de ejemplo tiene un volumen proyectado que contiene el token del serviceAccount inyectado. +Este token se puede usar por el contenedor de un Pod para acceder al API del servidor de Kubernetes. +El `audience` contiene la audiencia dirigida del token. Un recipiente del token debe identificarse a sí mismo con +un identificador especificado en la audiencia del token, de lo contrario debería rechazar el token. Este campo es opcional y por defecto tiene el valor del identificador del servidor API. + +EL campo `expirationSeconds` es la duración esperada de la validez del token del serviceAccount. +Su valor por defecto es 1 hora y debe ser al menos 10 minutos (600 segundos). Un administrador puede limitar +su valor máximo al especificar la opción `--service-account-max-token-expiration` para el servidor API. El campo `path` especifica una ruta relativa al punto de montaje del volumen proyectado. + +{{< note >}} +Un contenedor que usa una fuente de volumen proyectado como un volumen [`subPath`](#using-subpath) no recibirá actualizaciones de estas fuentes de volumen. +{{< /note >}} + +### quobyte + +Un volumen `quobyte` permite montar un volumen [Quobyte](https://www.quobyte.com) en tu Pod. + +{{< note >}} +Debes tener tu propia configuración Quobyte ejecutándose con los volúmenes creados antes de usarlo. +{{< /note >}} + +Quobyte soporta el {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. +CSI es el complemento recomendado para usar Quobyte dentro de Kubernetes. El proyeto Github de Quobyte tiene [instrucciones](https://github.com/quobyte/quobyte-csi#quobyte-csi) para desplegar usando CSI, junto con ejemplos. + +### rbd + +Un volumen `rbd` permite montar un volumen [Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) en tu Pod. +A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un volumen `rbd` es preservado y el volumen se desmonta. Esto significa que un volumen RBD puebe ser pre-poblado con datos, y que estos datos pueden ser compartidos entre pods. + +{{< note >}} +Debes tener una instalación de Ceph ejetutándose antes de usar RBD. +{{< /note >}} + +Una función de RBD es que solo se puede montar como de solo lectura por múltiples consumidores simultaneamente. +Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los volúmenes RBD solo se pueden montar por un único consumidor en modo lectura-escritura. No se permiten escritores simultáneos. + +Mira el [ejemplo RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) para más detalles. + +### scaleIO (deprecado) {#scaleio} + +ScaleIO es una plataforma de almacenamiento basada en software que usa el hardware existente para crear clústeres de almacenamiento en red de bloques compartidos escalables. El complemento de volumen `scaleIO` permite a los pods desplegados acceder a volúmenes existentes ScaleIO. Para información acerca de aprovisionamiento dinámico de nuevos persistence volumen claims, mira [ScaleIO persistent volumes](/docs/concepts/storage/persistent-volumes/#scaleio) + +{{< note >}} +Debes tener un Cluster ScaleIO ya configurado y ejecutándose con los volúmenes creados antes de poder usarlos. +{{< /note >}} + +El siguiente ejemplo es una configuración de un Pod con ScaleIO: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-0 +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: pod-0 + volumeMounts: + - mountPath: /test-pd + name: vol-0 + volumes: + - name: vol-0 + scaleIO: + gateway: https://localhost:443/api + system: scaleio + protectionDomain: sd0 + storagePool: sp1 + volumeName: vol-0 + secretRef: + name: sio-secret + fsType: xfs +``` + +Para más detalles, mira los ejempplos de [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) + +### secret + +Un volumen `seret` se utiliza para pasar información sensible, como contraseñas, a los Pods. +Puedes guardar secrets en la API de Kubernetes y montarlos como ficheros para usarlos con los pods sin acoplarlos con Kubernetes directamente. Los volúmenes `secret` son respaldados por tmpfs (un sistema de ficheros respaldado por la RAM) así que nunca se escriben en un almacenamiento no volátil. + +{{< note >}} +Debes crear un secreto en la API de Kubernetes antes de poder usarlo. +{{< /note >}} + +{{< note >}} +Un contenedor que usa un Secret como un volumen [`subPath`](#using-subpath) no recibirá las actualizaciones del Secret. +{{< /note >}} + +Para más detalles, mira [Configurando Secrets](/docs/concepts/configuration/secret/). + +### storageOS {#storageos} + +Un volumen `storageos` permite monar un voluen existente [StorageOS](https://www.storageos.com) en tu Pod. + +StorageOS corre como un contenedor dentro de tu contenedor Kubernetes, haciendo accesible el amacenamiento local o adjunto desde cualquier node dentro del cluster de Kubernetes. +Los datos pueden ser replicados para protegerlos contra fallos del nodo. Este aprovisionamiento y compresión pueden mejorar el uso y reducir costes. + +El contenedor StorageOs requiere Linux de 64 bits y no tiene dependencias adicionales. +Una licencia gratuita para desarrolladores está disponible. + +{{< caution >}} +Debes correr un contenedor StorageOS en cada nodo que quiera acceder a los volúmenes StorageOS o que contribuyan a la capacidad de almacenamiento al grupo. +Para instrucciones de instalación, consulta la [documentación StorageOS](https://docs.storageos.com) +{{< /caution >}} + +El siguiente ejemplo es una configuración de un Pod con Storage OS: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + name: redis + role: master + name: test-storageos-redis +spec: + containers: + - name: master + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + volumeMounts: + - mountPath: /redis-master-data + name: redis-data + volumes: + - name: redis-data + storageos: + # El volumen `redis-vol01` debe existir dentro de StorageOS en el namespace `default`. + volumeName: redis-vol01 + fsType: ext4 +``` + +Para más información sobre StorageOS, aprovisionamiento dinámico, y PersistentVolumeClaims, mira los +[ ejemplos de StorageOS examples](https://github.com/kubernetes/examples/blob/master/volumes/storageos). + +### vsphereVolume {#vspherevolume} + +{{< note >}} +Debes configurar el proveedor en la nube de vSphere de Kubernetes. +Para configuración de proveedores en la nube, mira la [ guía de inicio de vSphere ](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/). +{{< /note >}} + +Un volumen `vsphereVolume` se usa para montar un volumen VMDK vSphere en tu Pod. El contenido de un volumen es preservado cuando se desmonta. Tiene soporte para almacén de datos VMFS y VSAN. + +{{< note >}} +Debes crear un volumen vSphere VMDK usando uno de los siguientes métodos antes de usarlo con un Pod. +{{< /note >}} + +#### Creando un volumen VMDK {#creating-vmdk-volume} + +Elige uno de los siguientes métodos para crear un VMDK. + +{{< tabs name="tabs_volumes" >}} +{{% tab name="Create using vmkfstools" %}} +Primero entra mediante ssh en ESX, luego usa uno de los siguientes comandos para crear un VMDK: + +```shell +vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk +``` + +{{% /tab %}} +{{% tab name="Create using vmware-vdiskmanager" %}} +Usa el siguietne comando para crear un VMDK: + +```shell +vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk +``` + +{{% /tab %}} + +{{< /tabs >}} + +#### Ejemplo de configuración vSphere VMDK {#vsphere-vmdk-configuration} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-vmdk +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-vmdk + name: test-volume + volumes: + - name: test-volume + # Este volumen VMDK ya debe existir. + vsphereVolume: + volumePath: "[DatastoreName] volumes/myDisk" + fsType: ext4 +``` + +Para mayor información, mira el ejemplo de [vSphere volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere). + +#### Migración CSI vSphere {#vsphere-csi-migration} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} +Cuando la función `CSIMigration` está habilitada, redirige todas las operaciones de complemento desde el complemento existente en el árbol al controlador {{< glossary_tooltip text="CSI" term_id="csi" >}} `csi.vsphere.vmware.com`. Para +usar esta función, el [controlador vSphere CSI](https://github.com/kubernetes-sigs/vsphere-csi-driver) debe estar instalado en el clúster y las [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigration` y `CSIMigrationvSphere` deben estar habilitadas. + +Esto también requiere que la versión de vSphere vCenter/ESXi sea la 7.0u1 y la versión mínima de HW version sea VM versión 15. + +{{< note >}} +Los siguientes parámetros de Storageclass desde el complemento incorporado `vsphereVolume` no están soportados por el controlador vSphere CSI: + +- `diskformat` +- `hostfailurestotolerate` +- `forceprovisioning` +- `cachereservation` +- `diskstripes` +- `objectspacereservation` +- `iopslimit` + +Los volúmenes existentes creados usando estos parámetros serán migrados al controlador vSphere CSI, pero los volúmenes nuevos creados por el controlador vSphere CSI no respetarán estos parámetros +{{< /note >}} + +#### vSphere CSI migration complete {#vsphere-csi-migration-complete} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +To turn off the `vsphereVolume` plugin from being loaded by the controller manager and the kubelet, you need to set this feature flag to `true`. You must install a `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver on all worker nodes. + +## Using subPath {#using-subpath} + +Sometimes, it is useful to share one volume for multiple uses in a single pod. +The `volumeMounts.subPath` property specifies a sub-path inside the referenced volume +instead of its root. + +The following example shows how to configure a Pod with a LAMP stack (Linux Apache MySQL PHP) +using a single, shared volume. This sample `subPath` configuration is not recommended +for production use. + +The PHP application's code and assets map to the volume's `html` folder and +the MySQL database is stored in the volume's `mysql` folder. For example: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-lamp-site +spec: + containers: + - name: mysql + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "rootpasswd" + volumeMounts: + - mountPath: /var/lib/mysql + name: site-data + subPath: mysql + - name: php + image: php:7.0-apache + volumeMounts: + - mountPath: /var/www/html + name: site-data + subPath: html + volumes: + - name: site-data + persistentVolumeClaim: + claimName: my-lamp-site-data +``` + +### Using subPath with expanded environment variables {#using-subpath-expanded-environment} + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + +Use the `subPathExpr` field to construct `subPath` directory names from +downward API environment variables. +The `subPath` and `subPathExpr` properties are mutually exclusive. + +In this example, a `Pod` uses `subPathExpr` to create a directory `pod1` within +the `hostPath` volume `/var/log/pods`. +The `hostPath` volume takes the `Pod` name from the `downwardAPI`. +The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod1 +spec: + containers: + - name: container1 + env: + - name: POD_NAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: metadata.name + image: busybox + command: + [ + "sh", + "-c", + "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt", + ] + volumeMounts: + - name: workdir1 + mountPath: /logs + subPathExpr: $(POD_NAME) + restartPolicy: Never + volumes: + - name: workdir1 + hostPath: + path: /var/log/pods +``` + +## Resources + +The storage media (such as Disk or SSD) of an `emptyDir` volume is determined by the +medium of the filesystem holding the kubelet root dir (typically +`/var/lib/kubelet`). There is no limit on how much space an `emptyDir` or +`hostPath` volume can consume, and no isolation between containers or between +pods. + +To learn about requesting space using a resource specification, see +[how to manage resources](/docs/concepts/configuration/manage-resources-containers/). + +## Out-of-tree volume plugins + +The out-of-tree volume plugins include +{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) +and FlexVolume. These plugins enable storage vendors to create custom storage plugins +without adding their plugin source code to the Kubernetes repository. + +Previously, all volume plugins were "in-tree". The "in-tree" plugins were built, linked, compiled, +and shipped with the core Kubernetes binaries. This meant that adding a new storage system to +Kubernetes (a volume plugin) required checking code into the core Kubernetes code repository. + +Both CSI and FlexVolume allow volume plugins to be developed independent of +the Kubernetes code base, and deployed (installed) on Kubernetes clusters as +extensions. + +For storage vendors looking to create an out-of-tree volume plugin, please refer +to the [volume plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### csi + +[Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) +(CSI) defines a standard interface for container orchestration systems (like +Kubernetes) to expose arbitrary storage systems to their container workloads. + +Please read the [CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for more information. + +{{< note >}} +Support for CSI spec versions 0.2 and 0.3 are deprecated in Kubernetes +v1.13 and will be removed in a future release. +{{< /note >}} + +{{< note >}} +CSI drivers may not be compatible across all Kubernetes releases. +Please check the specific CSI driver's documentation for supported +deployments steps for each Kubernetes release and a compatibility matrix. +{{< /note >}} + +Once a CSI compatible volume driver is deployed on a Kubernetes cluster, users +may use the `csi` volume type to attach or mount the volumes exposed by the +CSI driver. + +A `csi` volume can be used in a Pod in three different ways: + +- through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim) +- with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) + (alpha feature) +- with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) + if the driver supports that (beta feature) + +The following fields are available to storage administrators to configure a CSI +persistent volume: + +- `driver`: A string value that specifies the name of the volume driver to use. + This value must correspond to the value returned in the `GetPluginInfoResponse` + by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). + It is used by Kubernetes to identify which CSI driver to call out to, and by + CSI driver components to identify which PV objects belong to the CSI driver. +- `volumeHandle`: A string value that uniquely identifies the volume. This value + must correspond to the value returned in the `volume.id` field of the + `CreateVolumeResponse` by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). + The value is passed as `volume_id` on all calls to the CSI volume driver when + referencing the volume. +- `readOnly`: An optional boolean value indicating whether the volume is to be + "ControllerPublished" (attached) as read only. Default is false. This value is + passed to the CSI driver via the `readonly` field in the + `ControllerPublishVolumeRequest`. +- `fsType`: If the PV's `VolumeMode` is `Filesystem` then this field may be used + to specify the filesystem that should be used to mount the volume. If the + volume has not been formatted and formatting is supported, this value will be + used to format the volume. + This value is passed to the CSI driver via the `VolumeCapability` field of + `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and + `NodePublishVolumeRequest`. +- `volumeAttributes`: A map of string to string that specifies static properties + of a volume. This map must correspond to the map returned in the + `volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as + defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). + The map is passed to the CSI driver via the `volume_context` field in the + `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and + `NodePublishVolumeRequest`. +- `controllerPublishSecretRef`: A reference to the secret object containing + sensitive information to pass to the CSI driver to complete the CSI + `ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is + optional, and may be empty if no secret is required. If the Secret + contains more than one secret, all secrets are passed. +- `nodeStageSecretRef`: A reference to the secret object containing + sensitive information to pass to the CSI driver to complete the CSI + `NodeStageVolume` call. This field is optional, and may be empty if no secret + is required. If the Secret contains more than one secret, all secrets + are passed. +- `nodePublishSecretRef`: A reference to the secret object containing + sensitive information to pass to the CSI driver to complete the CSI + `NodePublishVolume` call. This field is optional, and may be empty if no + secret is required. If the secret object contains more than one secret, all + secrets are passed. + +#### CSI raw block volume support + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +Vendors with external CSI drivers can implement raw block volume support +in Kubernetes workloads. + +You can set up your +[PersistentVolume/PersistentVolumeClaim with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) as usual, without any CSI specific changes. + +#### CSI ephemeral volumes + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +You can directly configure CSI volumes within the Pod +specification. Volumes specified in this way are ephemeral and do not +persist across pod restarts. See [Ephemeral +Volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) +for more information. + +For more information on how to develop a CSI driver, refer to the +[kubernetes-csi documentation](https://kubernetes-csi.github.io/docs/) + +#### Migrating to CSI drivers from in-tree plugins + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +The `CSIMigration` feature, when enabled, directs operations against existing in-tree +plugins to corresponding CSI plugins (which are expected to be installed and configured). +As a result, operators do not have to make any +configuration changes to existing Storage Classes, PersistentVolumes or PersistentVolumeClaims +(referring to in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin. + +The operations and features that are supported include: +provisioning/delete, attach/detach, mount/unmount and resizing of volumes. + +In-tree plugins that support `CSIMigration` and have a corresponding CSI driver implemented +are listed in [Types of Volumes](#volume-types). + +### flexVolume + +FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes +since version 1.2 (before CSI). It uses an exec-based model to interface with +drivers. The FlexVolume driver binaries must be installed in a pre-defined volume +plugin path on each node and in some cases the control plane nodes as well. + +Pods interact with FlexVolume drivers through the `flexvolume` in-tree volume plugin. +For more details, see the [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) examples. + +## Mount propagation + +Mount propagation allows for sharing volumes mounted by a container to +other containers in the same pod, or even to other pods on the same node. + +Mount propagation of a volume is controlled by the `mountPropagation` field +in `Container.volumeMounts`. Its values are: + +- `None` - This volume mount will not receive any subsequent mounts + that are mounted to this volume or any of its subdirectories by the host. + In similar fashion, no mounts created by the container will be visible on + the host. This is the default mode. + + This mode is equal to `private` mount propagation as described in the + [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + +- `HostToContainer` - This volume mount will receive all subsequent mounts + that are mounted to this volume or any of its subdirectories. + + In other words, if the host mounts anything inside the volume mount, the + container will see it mounted there. + + Similarly, if any Pod with `Bidirectional` mount propagation to the same + volume mounts anything there, the container with `HostToContainer` mount + propagation will see it. + + This mode is equal to `rslave` mount propagation as described in the + [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + +- `Bidirectional` - This volume mount behaves the same the `HostToContainer` mount. + In addition, all volume mounts created by the container will be propagated + back to the host and to all containers of all pods that use the same volume. + + A typical use case for this mode is a Pod with a FlexVolume or CSI driver or + a Pod that needs to mount something on the host using a `hostPath` volume. + + This mode is equal to `rshared` mount propagation as described in the + [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + + {{< warning >}} + `Bidirectional` mount propagation can be dangerous. It can damage + the host operating system and therefore it is allowed only in privileged + containers. Familiarity with Linux kernel behavior is strongly recommended. + In addition, any volume mounts created by containers in pods must be destroyed + (unmounted) by the containers on termination. + {{< /warning >}} + +### Configuration + +Before mount propagation can work properly on some deployments (CoreOS, +RedHat/Centos, Ubuntu) mount share must be configured correctly in +Docker as shown below. + +Edit your Docker's `systemd` service file. Set `MountFlags` as follows: + +```shell +MountFlags=shared +``` + +Or, remove `MountFlags=slave` if present. Then restart the Docker daemon: + +```shell +sudo systemctl daemon-reload +sudo systemctl restart docker +``` + +## {{% heading "whatsnext" %}} + +Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). From 69c70cd41873d826a330da86d6bfbfb3da021a57 Mon Sep 17 00:00:00 2001 From: anyulled Date: Sat, 31 Jul 2021 12:26:57 +0200 Subject: [PATCH 08/79] docs: volumes - spanish translation --- content/es/docs/concepts/storage/volumes.md | 32 +++++++++------------ 1 file changed, 13 insertions(+), 19 deletions(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 536763e06b..6d5e5d5111 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -1015,22 +1015,19 @@ Los siguientes parámetros de Storageclass desde el complemento incorporado `vsp Los volúmenes existentes creados usando estos parámetros serán migrados al controlador vSphere CSI, pero los volúmenes nuevos creados por el controlador vSphere CSI no respetarán estos parámetros {{< /note >}} -#### vSphere CSI migration complete {#vsphere-csi-migration-complete} +#### migración completa de vSphere CSI {#vsphere-csi-migration-complete} {{< feature-state for_k8s_version="v1.19" state="beta" >}} +Para apagar el complemento `vsphereVolume` y no cargarlo por el administrador del controlador y el kubelet, necesitas establecer eta función a `true`. Debes instalar un controlador de tipo `csi.vsphere.vmware.com` en todos los nodos worker. -To turn off the `vsphereVolume` plugin from being loaded by the controller manager and the kubelet, you need to set this feature flag to `true`. You must install a `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver on all worker nodes. +## Uso de subPath {#using-subpath} -## Using subPath {#using-subpath} +Algunas veces es útil compartir un volumen para múltiples usos en un único pod. +La propiedad `volumeMounts.subPath` especifica una sub-ruta dentro del volumen referenciado en lugar de su raíz. -Sometimes, it is useful to share one volume for multiple uses in a single pod. -The `volumeMounts.subPath` property specifies a sub-path inside the referenced volume -instead of its root. - -The following example shows how to configure a Pod with a LAMP stack (Linux Apache MySQL PHP) -using a single, shared volume. This sample `subPath` configuration is not recommended -for production use. +El siguiente ejemplo muestra cómo configurar un Pod con la pila LAMP (Linux Apache MySQL PHP) usando un único volumen compartido. Esta configuración de ejemplo usando `subPath` no se recomienda para su uso en producción. +El código de la aplicación PHP y los recursos apuntan al directorio `html` del volumen y la base de datos MySQL se almacena en el directorio `mysql`. Por ejemplo: The PHP application's code and assets map to the volume's `html` folder and the MySQL database is stored in the volume's `mysql` folder. For example: @@ -1062,18 +1059,15 @@ spec: claimName: my-lamp-site-data ``` -### Using subPath with expanded environment variables {#using-subpath-expanded-environment} +### Uso de subPath con variables de entorno expandidas {#using-subpath-expanded-environment} {{< feature-state for_k8s_version="v1.17" state="stable" >}} +Usa el campo `subPathExpr` para construir un nombres de directorio `subPath` desde variables de entorno de la API. +Las propiedades `subPath` y `subPathExpr` son mutuamente exclusivas. -Use the `subPathExpr` field to construct `subPath` directory names from -downward API environment variables. -The `subPath` and `subPathExpr` properties are mutually exclusive. - -In this example, a `Pod` uses `subPathExpr` to create a directory `pod1` within -the `hostPath` volume `/var/log/pods`. -The `hostPath` volume takes the `Pod` name from the `downwardAPI`. -The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container. +En este ejemplo, un `Pod` usa `subPathExpr` para crear un directorio `pod1` dentro del volumen `hostPath` `var/logs/pods`. +El volumen `hostPath` toma el nombre del `Pod` desde la `downwardAPI`. +El directorio anfitrión `var/log/pods/pod1` se monta en `/logs` en el contenedor. ```yaml apiVersion: v1 From a1801a3416ee29a2100469f70617b1c2e3616a3a Mon Sep 17 00:00:00 2001 From: anyulled Date: Sun, 1 Aug 2021 10:36:37 +0200 Subject: [PATCH 09/79] docs: volumes - spanish translation CSI --- content/es/docs/concepts/storage/volumes.md | 121 ++++++-------------- 1 file changed, 33 insertions(+), 88 deletions(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 6d5e5d5111..68cd41f030 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -1062,7 +1062,7 @@ spec: ### Uso de subPath con variables de entorno expandidas {#using-subpath-expanded-environment} {{< feature-state for_k8s_version="v1.17" state="stable" >}} -Usa el campo `subPathExpr` para construir un nombres de directorio `subPath` desde variables de entorno de la API. +Usa el campo `subPathExpr` para construir un nombre de directorio `subPath` desde variables de entorno de la API. Las propiedades `subPath` y `subPathExpr` son mutuamente exclusivas. En este ejemplo, un `Pod` usa `subPathExpr` para crear un directorio `pod1` dentro del volumen `hostPath` `var/logs/pods`. @@ -1101,112 +1101,57 @@ spec: path: /var/log/pods ``` -## Resources +## Recursos +El medio de almacenamiento (como un disco o un SSD) de un volumen `emptyDir` +se determina por el medio del sistema de archivos que contiene el directorio raíz +del kubelet (típicamente `/var/lib/kubelet`). +No hay límite de cuánto espacio puede consumir un volumen `emptydir` o `hostPath`, +y no hay aislamiento entre contenedores o entre pods. -The storage media (such as Disk or SSD) of an `emptyDir` volume is determined by the -medium of the filesystem holding the kubelet root dir (typically -`/var/lib/kubelet`). There is no limit on how much space an `emptyDir` or -`hostPath` volume can consume, and no isolation between containers or between -pods. +Para aprender más sobre requerir espacio usando una espacificación de recurso, mira [cómo administrar recursos](/docs/concepts/configuration/manage-resources-containers/). -To learn about requesting space using a resource specification, see -[how to manage resources](/docs/concepts/configuration/manage-resources-containers/). +## Complementos de volúmenes fuera del árbol +Los complementos de volumen fuera del árbol incluyen {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) y FlexVolume. Estos complementos permiten a los proveedores de almacenamiento crear complementos de almacenamiento personalizados sin añadir su código fuente al repositorio de Kubernetes. -## Out-of-tree volume plugins +Anteriormente, todos los complementos de volumen estaban "en el árbol". Los complementos "en el árbol" se construían, enlazaban, compilaban y enviaban con los binarios del núcleo de Kubernetes. Esto significaba que agregar un nuevo sistema de almacenamiento a Kubernetes ( un complemento de volumen) requería verificar el código en el repositorio de código del núcleo de Kubernetes. -The out-of-tree volume plugins include -{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) -and FlexVolume. These plugins enable storage vendors to create custom storage plugins -without adding their plugin source code to the Kubernetes repository. +Tanto CSI como FlexVolume permiten que se desarrollen complementos de volúmenes independientemente del código base de Kubernetes, y se desplieguen (instalen) en los clústeres de Kubernetes como extensiones. -Previously, all volume plugins were "in-tree". The "in-tree" plugins were built, linked, compiled, -and shipped with the core Kubernetes binaries. This meant that adding a new storage system to -Kubernetes (a volume plugin) required checking code into the core Kubernetes code repository. - -Both CSI and FlexVolume allow volume plugins to be developed independent of -the Kubernetes code base, and deployed (installed) on Kubernetes clusters as -extensions. - -For storage vendors looking to create an out-of-tree volume plugin, please refer -to the [volume plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). +Para los proveedores de almacenamiento que buscan crear un complemento de volumen fuera del árbol, por favor refiéranse a [Preguntas frecuentees de complementos de volumen](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). ### csi +La [interfaz de almacenamiento del contenedor](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) define una interfaz estándar para sistemas de orquestación del contenedor (como Kubernetes) para exponer sistemas de almacenamiento arbitrario a sus cargas de trabajo del contenedor. -[Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) -(CSI) defines a standard interface for container orchestration systems (like -Kubernetes) to expose arbitrary storage systems to their container workloads. - -Please read the [CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for more information. +Por favor, lee la [propuesta de diseño CSI](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) para más información. {{< note >}} -Support for CSI spec versions 0.2 and 0.3 are deprecated in Kubernetes -v1.13 and will be removed in a future release. +El soporte para las especificaciones de las versiones CSI 0.2 y 0.3 es´´an deprecadas en Kubernetes v1.13 y serán removidos en una versión futura. {{< /note >}} {{< note >}} -CSI drivers may not be compatible across all Kubernetes releases. -Please check the specific CSI driver's documentation for supported -deployments steps for each Kubernetes release and a compatibility matrix. +Los controladores CSI podrían no ser compatibles con todas las versiones de Kubernetes. +por favor, revisa la documentación específica del controlador CSI para los pasos de despliegue soportados para cada versión de Kubernetes y una matriz de compatibilidad. {{< /note >}} -Once a CSI compatible volume driver is deployed on a Kubernetes cluster, users -may use the `csi` volume type to attach or mount the volumes exposed by the -CSI driver. +Una vez que se despliega un controlador de volumen CSI compatible, los usuarios pueden usar el tipo de volumen `csi` para adjuntar o montar los volúmenes expuestos por el controlador CSI. -A `csi` volume can be used in a Pod in three different ways: +Un olumen `csi` puede ser usado en un Pod en tres maneras distintas: -- through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim) -- with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) - (alpha feature) -- with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) - if the driver supports that (beta feature) +- a través de una referencia a [PersistentVolumeClaim](#persistentvolumeclaim) +- con un [volumen general efímero](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) + (característica alpha) +- con un [volumen efímero CSI](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) si el controlador permite esta (característica beta) -The following fields are available to storage administrators to configure a CSI -persistent volume: +Los siguientes campos están disponibles para que los administradores de almacenamiento configuren el volumen persistente CSI -- `driver`: A string value that specifies the name of the volume driver to use. - This value must correspond to the value returned in the `GetPluginInfoResponse` - by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). - It is used by Kubernetes to identify which CSI driver to call out to, and by - CSI driver components to identify which PV objects belong to the CSI driver. -- `volumeHandle`: A string value that uniquely identifies the volume. This value - must correspond to the value returned in the `volume.id` field of the - `CreateVolumeResponse` by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). - The value is passed as `volume_id` on all calls to the CSI volume driver when - referencing the volume. -- `readOnly`: An optional boolean value indicating whether the volume is to be - "ControllerPublished" (attached) as read only. Default is false. This value is - passed to the CSI driver via the `readonly` field in the - `ControllerPublishVolumeRequest`. -- `fsType`: If the PV's `VolumeMode` is `Filesystem` then this field may be used - to specify the filesystem that should be used to mount the volume. If the - volume has not been formatted and formatting is supported, this value will be - used to format the volume. - This value is passed to the CSI driver via the `VolumeCapability` field of - `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and - `NodePublishVolumeRequest`. -- `volumeAttributes`: A map of string to string that specifies static properties - of a volume. This map must correspond to the map returned in the - `volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as - defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). - The map is passed to the CSI driver via the `volume_context` field in the - `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and - `NodePublishVolumeRequest`. -- `controllerPublishSecretRef`: A reference to the secret object containing - sensitive information to pass to the CSI driver to complete the CSI - `ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is - optional, and may be empty if no secret is required. If the Secret - contains more than one secret, all secrets are passed. -- `nodeStageSecretRef`: A reference to the secret object containing - sensitive information to pass to the CSI driver to complete the CSI - `NodeStageVolume` call. This field is optional, and may be empty if no secret - is required. If the Secret contains more than one secret, all secrets - are passed. -- `nodePublishSecretRef`: A reference to the secret object containing - sensitive information to pass to the CSI driver to complete the CSI - `NodePublishVolume` call. This field is optional, and may be empty if no - secret is required. If the secret object contains more than one secret, all - secrets are passed. +- `driver`: Un valor de cadena de caracteres que especifica el nombre del controlador de volumen a usar. Este valor debe corresponder al valor de respuesta en el `GetPluginInfoResponse` por el controlador CSI tal como se define en la [especificación CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). Es usado por Kubernetes para identificar cuál controlador llamar, y por los ocmponentes del controlador CSI para identificar cuáles objetos PV pertenecen al controlador CSI. +- `volumenHandle`: Un valor de cadena de caracteres que identifica el volumen unívocamente. Este valor debe corresponder al valor en el campo `volumen.id` del `CreateVolumeResponse` por el controlador CSI como se define en la [especificación CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). El valor es pasado como `volume.id` en todas las llamadas al controlador de volumen CSI cuando referencias el volumen. +- `readOnly`: Un valor booleano opcional que indica si el volumen es para ser "ControllerPublished" (adjuntado) como solo lectura. Por defecto es falso. Este valor es pasado el conttrolador CSI en el campo `readOnly` en el `ControllerPublishVolumeRequest`. +- `fsType`: Si el `VolumeMode`del PV es `Filesystem` entonces este campo se puede usar para especificar el sistema de archivos que debería usarse para montar el volumen. Si el volumen no ha sido formateado y soportado, este valor se utilizará para formatear el volumen. Este valor se para al controlador CSI con el campo `VolumeCapability` de `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, y `NodePublishVolumeRequest`. +- `volumeAttributes`: Un mapa de cadena de caracteres que especifica las propiedades estáticas de un volumen. Este mapa debe corresponder al map devuelto por el campo `volume.attributes` del `CreateVolumeResponse` por el controlador CSI tal como se define en la [especificación CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). El mapa es pasado al controlador CSI con el campo `volume.context` en el `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, y `NodePublishVolumeRequest`. +- `controllerPublishSecretRef`: Una referencia al objeto secret que contiene información sensible para pasar al controlador CSI para completar las llamadas CSI `ControllerPublishVolume` y `ControllerUnpublishVolume`. Este campo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene mas de un secret, se pasan todos los secrets. +- `nodeStageSecretRef`: Una referencia al objeto secret que contiene información sensible a pasar al ontrolador CSI para completar la llamada CSI `NodeStageVolume`. Este ampo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, todos los secrets son pasados. +- `nodePublishSecretRef`: Una referencia al objeto que contiene información sensible a pasar al controlador CSI para completar la llamada CSI `NodePublishVolume`. Este ampo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, todos los secrets son pasados. #### CSI raw block volume support From f1f300645b4ce4f9452edd65d5de0af84bac03ba Mon Sep 17 00:00:00 2001 From: anyulled Date: Sun, 1 Aug 2021 10:36:37 +0200 Subject: [PATCH 10/79] docs: volumes - spanish translation --- content/es/docs/concepts/storage/volumes.md | 165 ++++++++------------ 1 file changed, 69 insertions(+), 96 deletions(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 68cd41f030..1f71af0d21 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -40,7 +40,7 @@ Kubernetes soporta varios tipos de volúmenes Un volumen `awsElasticBlockStore` monta un [volumen EBS](https://aws.amazon.com/ebs/) de Amazon Web Services (AWS) en tu pod. A diferencia de `emptyDir`, que se borra cuando se quita un pod, el contenido de un volumen EBS es persistido cuando se desmonta el volumen. -esto significa que un volumen EBS puede ser prepoblado con datos, y que los datos puedes ser compartidos entre pods. +Esto significa que un volumen EBS puede ser pre-poblado con datos, y que los datos puedes ser compartidos entre pods. {{< note >}} Debes crear un volumen EBS usando `aws ec2 create-volume` o la API de AWS antes de poder usarlo. @@ -135,10 +135,10 @@ El controlador Azure File CSI no soporta usar el mismo volumen con fsgroups dife ### cephfs Un volumen `cephfs` permite montar un volumen CephFS existente en tu Pod. -A diferencia de `emptydir`, que es borrado cuando se remueve el pod, el contenido de un volumen `cephfs` es preservado y el volumen es meramente desmontado. Esto significa que un volumen `cephfs`puede ser prepoblado por múltiples escritores simultáneamente. +A diferencia de `emptydir`, que es borrado cuando se remueve el pod, el contenido de un volumen `cephfs` es preservado y el volumen es meramente desmontado. Esto significa que un volumen `cephfs`puede ser pre-poblado por múltiples escritores simultáneamente. {{< note >}} -Debes tener tu propio seervidor Ceph corriendo con el recurso compartido exportado antes de usarlo. +Debes tener tu propio servidor Ceph corriendo con el recurso compartido exportado antes de usarlo. {{< /note >}} Mira el [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) para más detalles. @@ -149,7 +149,7 @@ Mira el [CephFS example](https://github.com/kubernetes/examples/tree/{{< param " Kubernetes no debe ser configurado con el proveedor cloud OpenStack. {{< /note >}} -El tipo de volumen `cinder` se usa para montar un volumen Cinder de OpenStck en tu pod. +El tipo de volumen `cinder` se usa para montar un volumen Cinder de OpenStack en tu pod. #### Cinder volume configuration example @@ -177,12 +177,12 @@ spec: {{< feature-state for_k8s_version="v1.21" state="beta" >}} -La función `CSIMigration` para Cinder está habilidata por defecto en Kubernetes 1.21. +La función `CSIMigration` para Cinder está habilitada por defecto en Kubernetes 1.21. Esta redirige todas las operaciones de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `cinder.csi.openstack.org`. El controlador [OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) debe estar instalado en el clúster. -Puedes deshabilitar la migración CSI para tu clúster estrableciendo el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigrationOpenStack` a `false`. -Si deshabilitas la función `CSIMigrationOpenStack`, el complemento del volumen Cinder dentro del árbol toma la responsablidad para todos los aspectos de la administración del almacenamiento del volumen Cinder. +Puedes deshabilitar la migración CSI para tu clúster estableciendo el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigrationOpenStack` a `false`. +Si deshabilitas la función `CSIMigrationOpenStack`, el complemento del volumen Cinder dentro del árbol toma la responsabilidad para todos los aspectos de la administración del almacenamiento del volumen Cinder. ### configMap @@ -224,7 +224,7 @@ montado en el Pod en la ruta `/etc/config/log_level`. Ten en cuenta que esta rut - Debes crear un [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) antes de usarlo. - Un contenedor usando un ConfigMap montado como un volumen [`subPath`](#using-subpath) no recibirá actualizaciones del ConfigMap - Los datos de texto son expuestos como ficheros usando la codificación de caracteres UTF-8. Para otras codificaciones de caracteres, use `binaryData`. - {{< /note >}} +{{< /note >}} ### downwardAPI {#downwardapi} @@ -255,15 +255,14 @@ Algunos usos para un `emptyDir` son: - Contener archivos que un contenedor de administrador de contenido recupera mientras un contenedor de servidor web sirve los datos -Dependiendo de tu entorno, volúmenes `eptydir` se almacenan en cualquier medio que respalde el nodo tales como discoo SSD, o almacenamiento de red. Sin embargo, si estableces el campo `emptydir.medium` a `Memory`, Kubernetes monta en su lugar un tmpfs (sistema de ficheros respaldado por la RAM). Mientras que tmpfs es muy rápido, ten en cuenta que a diferencia de los discos, tmpfs se limpia cuando el nodo reinicia y cualquier fichero que escribas cuante contra el límite de memoria del contenedor. +Dependiendo de tu entorno, volúmenes `eptydir` se almacenan en cualquier medio que respalde el nodo tales como disco SSD, o almacenamiento de red. Sin embargo, si estableces el campo `emptydir.medium` a `Memory`, Kubernetes monta en su lugar un tmpfs (sistema de ficheros respaldado por la RAM). Mientras que tmpfs es muy rápido, ten en cuenta que a diferencia de los discos, tmpfs se limpia cuando el nodo reinicia y cualquier fichero que escribas cuenta contra el límite de memoria del contenedor. {{< note >}} Si el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SizeMemoryBackedVolumes` está habilitado, puedes especificar un tamaño para los volúmenes respaldados en memoria. Si no se especifica ningún tamaño los volúmenes respaldados en memoria tienen un tamaño del 50% de la memoria en un host Linux. - {{< /note>}} -#### ejemplo de configuración de emptyDir +#### Ejemplo de configuración de emptyDir ```yaml apiVersion: v1 @@ -314,7 +313,7 @@ Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< pa Un volumen `gcePersistentDisk` monta un volumen de Google Compute Engine (GCE) [persistent disk](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un DP es preservado -y el volumen solamente se desmonta. Esto significa que un PD puede ser prepoblado con datos, +y el volumen solamente se desmonta. Esto significa que un PD puede ser pre-poblado con datos, y que esos datos se pueden compartir entre pods. {{< note >}} @@ -328,7 +327,7 @@ Existen algunas restricciones cuando usas `gcePersistentDisk`: Una de las características del disco persistente CGE es acceso concurrente de solo lectura al disco persistente. Un volumen `gcePersistentDisk` permite montar simultáneamente un disco de solo lectura a múltiples consumidores. -Esto significa que puedes pr-epoblar un DP con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los DPs solo se pueden montar por un único consumidor en modo lectura-escritura. +Esto significa que puedes pre-poblar un DP con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los DPs solo se pueden montar por un único consumidor en modo lectura-escritura. No están permitidos escritores simultáneos. Usar un disco persistente GCE con un Pod controlado por un ReplicaSet fallará a manos que el DP sea de solo lectura o el número de réplicas sea 0 o 1. @@ -446,7 +445,7 @@ spec: ### glusterfs Un volumen `glusterfs` permite montar un volumen [Glusterfs](https://www.gluster.org) en tu Pod. -A diferencia de `emptyDir`, que se borra cuando se remueve un pod, el contenido de un volumen `glusterfs` es preservado +A diferencia de `emptyDir`, que se borra cuando se remueve un pod, el contenido de un volumen `glusterfs` es preservado y el volumen solamente se desmonta. Esto significa que un volumen glusterfs puede ser pre-poblado con datos, y que los datos pueden ser compartidos entre pods. GlusterFS puede ser montado por múltiples escritores simultáneamente. @@ -486,7 +485,7 @@ Ten cuidado cuando uses este tipo de volumen, porque: - Los Pods con configuración idéntica (tales como los creados por un PodTemplate) pueden comportarse de forma distinta en nodos distintos debido a diferentes ficheros en los nodos. -- Los ficheros o directorios creados en los host subyacentes son modificables solo por root. Debes ejecutar tu proceso como root en un [Contenedor privilegiado](/docs/tasks/configure-pod-container/security-context/) o modificar los permisos de archivo en el host para escribir a un volumen `hostPath` +- Los ficheros o directorios creados en los hosts subyacentes son modificables solo por root. Debes ejecutar tu proceso como root en un [Contenedor privilegiado](/docs/tasks/configure-pod-container/security-context/) o modificar los permisos de archivo en el host para escribir a un volumen `hostPath` #### Ejemplo de configuración hostPath @@ -565,7 +564,7 @@ Mira el [ ejemplo iSCSI](https://github.com/kubernetes/examples/tree/{{< param " ### local -Un volumen `local` representa un dispositivo de almacenamiento local como un dico, una partición o un directorio. +Un volumen `local` representa un dispositivo de almacenamiento local como un disco, una partición o un directorio. Los volúmenes locales solo se pueden usar como un PersistenVolume creado estáticamente. El aprovisionamiento dinámico no está soportado. @@ -615,14 +614,13 @@ para exponer el volumen local como un dispositivo de bloque sin formato. Cuando usas volúmenes locales, se recomienda crear un StorageClass con `volumeBindingMode` en `WaitForFirstConsumer`. Para más detalles, mira el ejemplo de [StorageClass](/docs/concepts/storage/storage-classes/#local). Retrasar el enlace con el volumen asegura que la decisión del PersistenVolumeClaim sea evaluada con otras limitaciones que el Pod pueda tener, -tales como requisitos de recuersos del nodo, selectores de nodo, afinidad del Pod, y anti-afinidad del Pod. +tales como requisitos de recursos del nodo, selectores de nodo, afinidad del Pod, y anti-afinidad del Pod. Se puede ejecutar un aprovisionador estático externo para un manejo mejorado del ciclo de vida del volumen local. Ten en cuenta que este aprovisionador no soporta aprovisionamiento dinámico todavía. Para un ejemplo de un aprovisionador local externo, mira la [guía de usuario de aprovisionador de volumen local](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) {{< note >}} -El PersistentVolume local requiere limpieza y borrado manual por el usuario si no se utiliza el aprovisionador estático externo -para manejar el ciclo de vida del volumen. +El PersistentVolume local requiere limpieza y borrado manual por el usuario si no se utiliza el aprovisionador estático externo para manejar el ciclo de vida del volumen. {{< /note >}} ### nfs @@ -766,7 +764,7 @@ spec: Cada volumen proyectado está listado en spec bajo `sources`. Los parámetros son casi los mismos salvo dos excepciones: - Para los secrets, el campo `secretName` ha sido cambiado a `name` para ser consistente con el nombre del configMap. -- El `defaultMode` solo se puede especificar en el nivel proyectado y no para cada fuente de volumen. Sin, como se muestra arriba, puedes establecer explicaitamente el `mode` para cada proyección individual. +- El `defaultMode` solo se puede especificar en el nivel proyectado y no para cada fuente de volumen. Sin, como se muestra arriba, puedes establecer explícitamente el `mode` para cada proyección individual. Cuando la función `TokenRequestProjection` está habilitada, puedes inyectar el token para el [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens) actual en un Pod en la ruta especificada. Por ejemplo: @@ -795,7 +793,7 @@ spec: ``` El Pod de ejemplo tiene un volumen proyectado que contiene el token del serviceAccount inyectado. -Este token se puede usar por el contenedor de un Pod para acceder al API del servidor de Kubernetes. +Este token se puede usar por el contenedor de un Pod para acceder a la API del servidor de Kubernetes. El `audience` contiene la audiencia dirigida del token. Un recipiente del token debe identificarse a sí mismo con un identificador especificado en la audiencia del token, de lo contrario debería rechazar el token. Este campo es opcional y por defecto tiene el valor del identificador del servidor API. @@ -816,18 +814,18 @@ Debes tener tu propia configuración Quobyte ejecutándose con los volúmenes cr {{< /note >}} Quobyte soporta el {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. -CSI es el complemento recomendado para usar Quobyte dentro de Kubernetes. El proyeto Github de Quobyte tiene [instrucciones](https://github.com/quobyte/quobyte-csi#quobyte-csi) para desplegar usando CSI, junto con ejemplos. +CSI es el complemento recomendado para usar Quobyte dentro de Kubernetes. El proyecto Github de Quobyte tiene [instrucciones](https://github.com/quobyte/quobyte-csi#quobyte-csi) para desplegar usando CSI, junto con ejemplos. ### rbd Un volumen `rbd` permite montar un volumen [Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) en tu Pod. -A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un volumen `rbd` es preservado y el volumen se desmonta. Esto significa que un volumen RBD puebe ser pre-poblado con datos, y que estos datos pueden ser compartidos entre pods. +A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un volumen `rbd` es preservado y el volumen se desmonta. Esto significa que un volumen RBD puede ser pre-poblado con datos, y que estos datos pueden ser compartidos entre pods. {{< note >}} -Debes tener una instalación de Ceph ejetutándose antes de usar RBD. +Debes tener una instalación de Ceph ejecutándose antes de usar RBD. {{< /note >}} -Una función de RBD es que solo se puede montar como de solo lectura por múltiples consumidores simultaneamente. +Una función de RBD es que solo se puede montar como de solo lectura por múltiples consumidores simultáneamente. Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los volúmenes RBD solo se pueden montar por un único consumidor en modo lectura-escritura. No se permiten escritores simultáneos. Mira el [ejemplo RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) para más detalles. @@ -867,7 +865,7 @@ spec: fsType: xfs ``` -Para más detalles, mira los ejempplos de [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) +Para más detalles, mira los ejemplos de [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) ### secret @@ -886,9 +884,9 @@ Para más detalles, mira [Configurando Secrets](/docs/concepts/configuration/sec ### storageOS {#storageos} -Un volumen `storageos` permite monar un voluen existente [StorageOS](https://www.storageos.com) en tu Pod. +Un volumen `storageos` permite montar un volumen existente [StorageOS](https://www.storageos.com) en tu Pod. -StorageOS corre como un contenedor dentro de tu contenedor Kubernetes, haciendo accesible el amacenamiento local o adjunto desde cualquier node dentro del cluster de Kubernetes. +StorageOS corre como un contenedor dentro de tu contenedor Kubernetes, haciendo accesible el almacenamiento local o adjunto desde cualquier node dentro del cluster de Kubernetes. Los datos pueden ser replicados para protegerlos contra fallos del nodo. Este aprovisionamiento y compresión pueden mejorar el uso y reducir costes. El contenedor StorageOs requiere Linux de 64 bits y no tiene dependencias adicionales. @@ -959,7 +957,7 @@ vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk {{% /tab %}} {{% tab name="Create using vmware-vdiskmanager" %}} -Usa el siguietne comando para crear un VMDK: +Usa el siguiente comando para crear un VMDK: ```shell vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk @@ -1102,40 +1100,43 @@ spec: ``` ## Recursos -El medio de almacenamiento (como un disco o un SSD) de un volumen `emptyDir` + +El medio de almacenamiento (como un disco o un SSD) de un volumen `emptyDir` se determina por el medio del sistema de archivos que contiene el directorio raíz del kubelet (típicamente `/var/lib/kubelet`). -No hay límite de cuánto espacio puede consumir un volumen `emptydir` o `hostPath`, +No hay límite de cuánto espacio puede consumir un volumen `emptydir` o `hostPath`, y no hay aislamiento entre contenedores o entre pods. Para aprender más sobre requerir espacio usando una espacificación de recurso, mira [cómo administrar recursos](/docs/concepts/configuration/manage-resources-containers/). ## Complementos de volúmenes fuera del árbol + Los complementos de volumen fuera del árbol incluyen {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) y FlexVolume. Estos complementos permiten a los proveedores de almacenamiento crear complementos de almacenamiento personalizados sin añadir su código fuente al repositorio de Kubernetes. -Anteriormente, todos los complementos de volumen estaban "en el árbol". Los complementos "en el árbol" se construían, enlazaban, compilaban y enviaban con los binarios del núcleo de Kubernetes. Esto significaba que agregar un nuevo sistema de almacenamiento a Kubernetes ( un complemento de volumen) requería verificar el código en el repositorio de código del núcleo de Kubernetes. +Anteriormente, todos los complementos de volumen estaban "en el árbol". Los complementos "en el árbol" se construían, enlazaban, compilaban y enviaban con los binarios del núcleo de Kubernetes. Esto significaba que agregar un nuevo sistema de almacenamiento a Kubernetes (un complemento de volumen) requería verificar el código en el repositorio de código del núcleo de Kubernetes. Tanto CSI como FlexVolume permiten que se desarrollen complementos de volúmenes independientemente del código base de Kubernetes, y se desplieguen (instalen) en los clústeres de Kubernetes como extensiones. Para los proveedores de almacenamiento que buscan crear un complemento de volumen fuera del árbol, por favor refiéranse a [Preguntas frecuentees de complementos de volumen](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). ### csi + La [interfaz de almacenamiento del contenedor](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) define una interfaz estándar para sistemas de orquestación del contenedor (como Kubernetes) para exponer sistemas de almacenamiento arbitrario a sus cargas de trabajo del contenedor. Por favor, lee la [propuesta de diseño CSI](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) para más información. {{< note >}} -El soporte para las especificaciones de las versiones CSI 0.2 y 0.3 es´´an deprecadas en Kubernetes v1.13 y serán removidos en una versión futura. +El soporte para las especificaciones de las versiones CSI 0.2 y 0.3 están deprecadas en Kubernetes v1.13 y serán removidos en una versión futura. {{< /note >}} {{< note >}} -Los controladores CSI podrían no ser compatibles con todas las versiones de Kubernetes. -por favor, revisa la documentación específica del controlador CSI para los pasos de despliegue soportados para cada versión de Kubernetes y una matriz de compatibilidad. +Los controladores CSI podrían no ser compatibles con todas las versiones de Kubernetes. +Por favor, revisa la documentación específica del controlador CSI para los pasos de despliegue soportados para cada versión de Kubernetes y una matriz de compatibilidad. {{< /note >}} Una vez que se despliega un controlador de volumen CSI compatible, los usuarios pueden usar el tipo de volumen `csi` para adjuntar o montar los volúmenes expuestos por el controlador CSI. -Un olumen `csi` puede ser usado en un Pod en tres maneras distintas: +Un volumen `csi` puede ser usado en un Pod en tres maneras distintas: - a través de una referencia a [PersistentVolumeClaim](#persistentvolumeclaim) - con un [volumen general efímero](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) @@ -1144,50 +1145,40 @@ Un olumen `csi` puede ser usado en un Pod en tres maneras distintas: Los siguientes campos están disponibles para que los administradores de almacenamiento configuren el volumen persistente CSI -- `driver`: Un valor de cadena de caracteres que especifica el nombre del controlador de volumen a usar. Este valor debe corresponder al valor de respuesta en el `GetPluginInfoResponse` por el controlador CSI tal como se define en la [especificación CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). Es usado por Kubernetes para identificar cuál controlador llamar, y por los ocmponentes del controlador CSI para identificar cuáles objetos PV pertenecen al controlador CSI. +- `driver`: Un valor de cadena de caracteres que especifica el nombre del controlador de volumen a usar. Este valor debe corresponder al valor de respuesta en el `GetPluginInfoResponse` por el controlador CSI tal como se define en la [especificación CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). Es usado por Kubernetes para identificar cuál controlador llamar, y por los componentes del controlador CSI para identificar cuáles objetos PV pertenecen al controlador CSI. - `volumenHandle`: Un valor de cadena de caracteres que identifica el volumen unívocamente. Este valor debe corresponder al valor en el campo `volumen.id` del `CreateVolumeResponse` por el controlador CSI como se define en la [especificación CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). El valor es pasado como `volume.id` en todas las llamadas al controlador de volumen CSI cuando referencias el volumen. -- `readOnly`: Un valor booleano opcional que indica si el volumen es para ser "ControllerPublished" (adjuntado) como solo lectura. Por defecto es falso. Este valor es pasado el conttrolador CSI en el campo `readOnly` en el `ControllerPublishVolumeRequest`. +- `readOnly`: Un valor booleano opcional que indica si el volumen es para ser "ControllerPublished" (adjuntado) como solo lectura. Por defecto es falso. Este valor es pasado el controlador CSI en el campo `readOnly` en el `ControllerPublishVolumeRequest`. - `fsType`: Si el `VolumeMode`del PV es `Filesystem` entonces este campo se puede usar para especificar el sistema de archivos que debería usarse para montar el volumen. Si el volumen no ha sido formateado y soportado, este valor se utilizará para formatear el volumen. Este valor se para al controlador CSI con el campo `VolumeCapability` de `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, y `NodePublishVolumeRequest`. -- `volumeAttributes`: Un mapa de cadena de caracteres que especifica las propiedades estáticas de un volumen. Este mapa debe corresponder al map devuelto por el campo `volume.attributes` del `CreateVolumeResponse` por el controlador CSI tal como se define en la [especificación CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). El mapa es pasado al controlador CSI con el campo `volume.context` en el `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, y `NodePublishVolumeRequest`. -- `controllerPublishSecretRef`: Una referencia al objeto secret que contiene información sensible para pasar al controlador CSI para completar las llamadas CSI `ControllerPublishVolume` y `ControllerUnpublishVolume`. Este campo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene mas de un secret, se pasan todos los secrets. -- `nodeStageSecretRef`: Una referencia al objeto secret que contiene información sensible a pasar al ontrolador CSI para completar la llamada CSI `NodeStageVolume`. Este ampo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, todos los secrets son pasados. +- `volumeAttributes`: Un mapa de cadena de caracteres que especifica las propiedades estáticas de un volumen. Este mapa debe corresponder al map devuelto por el campo `volume.attributes` del `CreateVolumeResponse` por el controlador CSI tal como se define en la [especificación CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). El mapa es pasado al controlador CSI con el campo `volume.context` en el `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, y `NodePublishVolumeRequest`. +- `controllerPublishSecretRef`: Una referencia al objeto secret que contiene información sensible para pasar al controlador CSI para completar las llamadas CSI `ControllerPublishVolume` y `ControllerUnpublishVolume`. Este campo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, se pasan todos los secrets. +- `nodeStageSecretRef`: Una referencia al objeto secret que contiene información sensible a pasar al controlador CSI para completar la llamada CSI `NodeStageVolume`. Este ampo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, todos los secrets son pasados. - `nodePublishSecretRef`: Una referencia al objeto que contiene información sensible a pasar al controlador CSI para completar la llamada CSI `NodePublishVolume`. Este ampo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, todos los secrets son pasados. -#### CSI raw block volume support +#### Soporte de volumen CSI de fila de bloques {{< feature-state for_k8s_version="v1.18" state="stable" >}} -Vendors with external CSI drivers can implement raw block volume support -in Kubernetes workloads. +Los proveedores con controladores CSI externos pueden implementar soporte de volumen de bloques sin procesar en cargas de trabajo de Kubernetes. -You can set up your -[PersistentVolume/PersistentVolumeClaim with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) as usual, without any CSI specific changes. +Puedes configurar tu +You can set up your [PersistentVolume/PersistentVolumeClaim with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) como de costumbre, sin ningún cambio específico CSI. -#### CSI ephemeral volumes +#### Volúmenes efímeros CSI {{< feature-state for_k8s_version="v1.16" state="beta" >}} -You can directly configure CSI volumes within the Pod -specification. Volumes specified in this way are ephemeral and do not -persist across pod restarts. See [Ephemeral -Volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) -for more information. +Puedes configurar directamente volúmenes CSI dentro de la especificación del Pod. +Los volúmenes especificados de esta manera son efímeros y no se persisten entre reinicios del pod. Mira [Volúmenes efímeros](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) para más información. -For more information on how to develop a CSI driver, refer to the -[kubernetes-csi documentation](https://kubernetes-csi.github.io/docs/) +Para más información de cómo desarrollador un controlador CSI, mira la [documentación kubernetes-csi](https://kubernetes-csi.github.io/docs/) -#### Migrating to CSI drivers from in-tree plugins +#### Migrando a controladores CSI desde complementos en el árbol. {{< feature-state for_k8s_version="v1.17" state="beta" >}} +La función `CSIMigration`, cuando está habilitada, dirige todas las operaciones hacia complementos existentes en el árbol a complementos CSI correspondientes (que se espera que estén instalados y configurados). Como resultado, los operadores no tienen que hacer ningún cambio de configuración a las clases de almacenamiento, PersistentVolumes o PersistentVolumeClaims (refiriéndose a complementos en el árbol) cuando haces la transición a un controlador CSI que un reemplaza complemento en el árbol. -The `CSIMigration` feature, when enabled, directs operations against existing in-tree -plugins to corresponding CSI plugins (which are expected to be installed and configured). -As a result, operators do not have to make any -configuration changes to existing Storage Classes, PersistentVolumes or PersistentVolumeClaims -(referring to in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin. - -The operations and features that are supported include: -provisioning/delete, attach/detach, mount/unmount and resizing of volumes. +Las operaciones y funciones que están soportadas incluye: +aprovisionamiento/borrado, adjuntar/separar, montar/desmontar y redimensionar volúmenes. In-tree plugins that support `CSIMigration` and have a corresponding CSI driver implemented are listed in [Types of Volumes](#volume-types). @@ -1202,51 +1193,33 @@ plugin path on each node and in some cases the control plane nodes as well. Pods interact with FlexVolume drivers through the `flexvolume` in-tree volume plugin. For more details, see the [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) examples. -## Mount propagation +## Propagación del montaje -Mount propagation allows for sharing volumes mounted by a container to -other containers in the same pod, or even to other pods on the same node. +La propagación del montaje permite compartir volúmenes montados por un contenedor para otros contenedores en el mismo pod, o aun para otros pods en el mismo nodo. -Mount propagation of a volume is controlled by the `mountPropagation` field -in `Container.volumeMounts`. Its values are: +La propagación del montaje de un volumen es controlada por el campo `mountPropagation` en `Container.volumeMounts`. Sus valores son: -- `None` - This volume mount will not receive any subsequent mounts - that are mounted to this volume or any of its subdirectories by the host. - In similar fashion, no mounts created by the container will be visible on - the host. This is the default mode. +- `None` - Este montaje de volumen no recibirá ningún montaje posterior que el host haya montado en este volumen o en cualquiera de sus subdirectorios. De manera similar, los montajes creados por el contenedor no serán visibles en el host. Este es el modo por defecto. - This mode is equal to `private` mount propagation as described in the - [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + Este modo es igual la propagación del montaje `private` tal como se describe en la [ documentación Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) -- `HostToContainer` - This volume mount will receive all subsequent mounts - that are mounted to this volume or any of its subdirectories. +- `HostToContainer` - Este montaje de volumen recibirá todos los montajes subsecuentes que son montados a este volumen o cualquiera de sus subdirectorios. - In other words, if the host mounts anything inside the volume mount, the - container will see it mounted there. + En otras palabras, si el host monta algo dentro del montaje del volumen, el contenedor lo verá montado allí. - Similarly, if any Pod with `Bidirectional` mount propagation to the same - volume mounts anything there, the container with `HostToContainer` mount - propagation will see it. + De manera similar, si cualquier Pod con propagación de montaje `Bidirectional` al mismo volumen monta algo allí, el contenedor con propagación de montaje` HostToContainer` lo verá. - This mode is equal to `rslave` mount propagation as described in the - [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + Este modo es igual a la propagación de montaje `rslave` tal como se describe en la [documentación del kernel de Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) -- `Bidirectional` - This volume mount behaves the same the `HostToContainer` mount. - In addition, all volume mounts created by the container will be propagated - back to the host and to all containers of all pods that use the same volume. +- `Bidirectional`- Este montaje de volumen se comporta de la misma manera de el montaje`HostToContainer`. Adicionalmente, todos los montajes de volúmenes creados por el contenedor serán propagados de vuelta al host y a todos los contenedores de todos los pods que usan el mismo volumen. - A typical use case for this mode is a Pod with a FlexVolume or CSI driver or - a Pod that needs to mount something on the host using a `hostPath` volume. + Un uso típico para este modo es un Pod con un FlexVolumen o un controlador CSI o un Pod que necesita montar al en el host usando un volumen `hostPath`. - This mode is equal to `rshared` mount propagation as described in the - [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + Este modo es igual a la propagación de montaje `rshared` tal como se describe en la [documentación del kernel de Linux documentación](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) {{< warning >}} - `Bidirectional` mount propagation can be dangerous. It can damage - the host operating system and therefore it is allowed only in privileged - containers. Familiarity with Linux kernel behavior is strongly recommended. - In addition, any volume mounts created by containers in pods must be destroyed - (unmounted) by the containers on termination. + La propagación por montaje `Bidirectional` puede ser peligrosa. Puede dañar el sistema operativo host y, por lo tanto, solo se permite en contenedores privilegiados. Se recomienda encarecidamente estar familiarizado con el comportamiento del kernel de Linux. + Además, cualquier montaje de volumen creado por contenedores en pods debe destruirse (desmontado) por los contenedores en el momento de la terminación. {{< /warning >}} ### Configuration @@ -1270,4 +1243,4 @@ sudo systemctl restart docker ## {{% heading "whatsnext" %}} -Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). +Sigue un ejemplo de [desplegar WordPrss y MySQL con volúmenes persistentes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). From 30996f3b66c6c1a5b5710ff80d115d9cdea20b67 Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 04:58:43 +0200 Subject: [PATCH 11/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 1f71af0d21..def33ebd3a 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -311,7 +311,7 @@ Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< pa ### gcePersistentDisk Un volumen `gcePersistentDisk` monta un volumen de Google Compute Engine (GCE) -[persistent disk](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. +de [disco persistente](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un DP es preservado y el volumen solamente se desmonta. Esto significa que un PD puede ser pre-poblado con datos, y que esos datos se pueden compartir entre pods. From f0a52d106f4f2c44636d1faabdc2037b2b07e5ed Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:05:11 +0200 Subject: [PATCH 12/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index def33ebd3a..a084d849de 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -6,9 +6,9 @@ weight: 10 -Los ficheros en disco dentro de un contenedor son efímeros, lo cual presenta problemas +Los archivos localizados dentro de un contenedor son efímeros, lo cual presenta problemas para aplicaciones no triviales cuando se ejecutan en contenedores. Un problema es la -pérdida de ficheros cuando el contenedor se cae. El kubelet reinicia el contenedor pero con un estado limpio. +pérdida de archivos cuando el contenedor termina. Kubelet reinicia el contenedor con un estado limpio. Un segundo problema ocurre cuando compartimos ficheros entre contenedores corriendo juntos dentro de un `Pod`. La abstracción {{< glossary_tooltip text="volume" term_id="volume" >}} de Kubernetes resuelve ambos problemas. Se sugiere familiaridad con [Pods](/docs/concepts/workloads/pods/) From 9a112c60c917df68579b4780e6d58893e4c100ca Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:05:26 +0200 Subject: [PATCH 13/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index a084d849de..30eb0d0799 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -17,7 +17,7 @@ Se sugiere familiaridad con [Pods](/docs/concepts/workloads/pods/) ## Trasfondo Docker tiene el concepto de [volúmenes](https://docs.docker.com/storage/), aunque es algo más flojo y menos controlado. -Un volumen de docker es un directorio en disco o en otro contenedor. Docker provee controladores de volúmenes, pero la funcionalidad es algo limitada. +Un volumen de Docker es un directorio en disco o en otro contenedor. Docker provee controladores de volúmenes, pero la funcionalidad es algo limitada. Kubernetes soporta muchos tipos de volúmenes. Un {{< glossary_tooltip term_id="pod" text="Pod" >}} puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el tiempo de vida de un pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un pod. Cuando un pod deja de existir, From e509859458d07e2e70775132b222fb68c736ce9f Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:05:44 +0200 Subject: [PATCH 14/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 30eb0d0799..3c45144294 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -20,7 +20,7 @@ Docker tiene el concepto de [volúmenes](https://docs.docker.com/storage/), aunq Un volumen de Docker es un directorio en disco o en otro contenedor. Docker provee controladores de volúmenes, pero la funcionalidad es algo limitada. Kubernetes soporta muchos tipos de volúmenes. Un {{< glossary_tooltip term_id="pod" text="Pod" >}} -puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el tiempo de vida de un pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un pod. Cuando un pod deja de existir, +puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el mismo tiempo de vida que un Pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un Pod. Cuando un Pod deja de existir, Kubernetes destruye los volúmenes efímeros; sin embargo, Kubernetes no destruye los volúmenes persistentes. Para cualquier tipo de volumen en un pod dado, los datos son preservados a través de los reinicios del contenedor. En su núcleo, un volumen es un directorio, posiblemente con algunos datos en este, que puede ser accesible para los contenedores en un pod. Cómo ese directorio llega a crearse, el medio que lo respalda, y el contenido de este se determinan por el tipo de volumen usado. From c1f24b152966b0a03ba529dae30b1d16d5996d6e Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:05:57 +0200 Subject: [PATCH 15/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 3c45144294..506e09b96d 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -21,7 +21,7 @@ Un volumen de Docker es un directorio en disco o en otro contenedor. Docker prov Kubernetes soporta muchos tipos de volúmenes. Un {{< glossary_tooltip term_id="pod" text="Pod" >}} puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el mismo tiempo de vida que un Pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un Pod. Cuando un Pod deja de existir, -Kubernetes destruye los volúmenes efímeros; sin embargo, Kubernetes no destruye los volúmenes persistentes. Para cualquier tipo de volumen en un pod dado, los datos son preservados a través de los reinicios del contenedor. +Kubernetes destruye los volúmenes efímeros; sin embargo, Kubernetes no destruye los volúmenes persistentes. Para cualquier tipo de volumen en un Pod dado, los datos son preservados a lo largo de los reinicios del contenedor. En su núcleo, un volumen es un directorio, posiblemente con algunos datos en este, que puede ser accesible para los contenedores en un pod. Cómo ese directorio llega a crearse, el medio que lo respalda, y el contenido de este se determinan por el tipo de volumen usado. From 0b62eba4419a8eab4a0fe80b3c3c767eeb38f11d Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:06:08 +0200 Subject: [PATCH 16/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 506e09b96d..80cb6eaff5 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -240,7 +240,7 @@ Mira el [downward API example](/docs/tasks/inject-data-application/downward-api- ### emptyDir {#emptydir} Un volumen `emptyDir`es creado primero cuando se asigna un pod a un nodo, y existe mientras el Pod está corriendo en el nodo. -Como su nombre lo indica un volumen `emptydir`está vacío inicialmente. Todos los contenedores en el Pod pueden leer y escribir +Como su nombre lo indica un volumen `emptydir`está inicialmente vacío. Todos los contenedores en el Pod pueden leer y escribir los mismos ficheros en el volumen `emptyDir`, aunque ese volumen se puede montar en la misma ruta o diferentes en cada contenedor. Cuando un Pod es removido del nodo por alguna razón, los datos en `emptydir` se borran permanentemente. {{< note >}} From 1bb637a36dc306d492e11ea00e9cfbc4c7559e52 Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:06:28 +0200 Subject: [PATCH 17/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 80cb6eaff5..1cad311a14 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -241,7 +241,7 @@ Mira el [downward API example](/docs/tasks/inject-data-application/downward-api- Un volumen `emptyDir`es creado primero cuando se asigna un pod a un nodo, y existe mientras el Pod está corriendo en el nodo. Como su nombre lo indica un volumen `emptydir`está inicialmente vacío. Todos los contenedores en el Pod pueden leer y escribir -los mismos ficheros en el volumen `emptyDir`, aunque ese volumen se puede montar en la misma ruta o diferentes en cada contenedor. Cuando un Pod es removido del nodo por alguna razón, los datos en `emptydir` se borran permanentemente. +los archivos en el volumen `emptyDir`, aunque ese volumen se puede montar en la misma o diferente ruta en cada contenedor. Cuando un Pod es removido del nodo por alguna razón, los datos en `emptydir` se borran permanentemente. {{< note >}} Un contenedor que colapsa _no_ remueve el Pod del nodo. Los datos en un volumen `emptyDir` están seguros en caso de From 752aaafc2585be2f80ff1abdcc18fa229b07f12a Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:06:48 +0200 Subject: [PATCH 18/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 1cad311a14..edee5b04cd 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -255,7 +255,7 @@ Algunos usos para un `emptyDir` son: - Contener archivos que un contenedor de administrador de contenido recupera mientras un contenedor de servidor web sirve los datos -Dependiendo de tu entorno, volúmenes `eptydir` se almacenan en cualquier medio que respalde el nodo tales como disco SSD, o almacenamiento de red. Sin embargo, si estableces el campo `emptydir.medium` a `Memory`, Kubernetes monta en su lugar un tmpfs (sistema de ficheros respaldado por la RAM). Mientras que tmpfs es muy rápido, ten en cuenta que a diferencia de los discos, tmpfs se limpia cuando el nodo reinicia y cualquier fichero que escribas cuenta contra el límite de memoria del contenedor. +Dependiendo de tu entorno, los volúmenes `emptydir` se almacenan en cualquier medio que respalde el nodo tales como disco SSD, o almacenamiento de red. Sin embargo, si se establece el campo `emptydir.medium` a `Memory`, Kubernetes monta en su lugar un tmpfs (sistema de ficheros respaldado por la RAM). Mientras que tmpfs es muy rápido, ten en cuenta que a diferencia de los discos, tmpfs se limpia cuando el nodo reinicia y cualquier archivo que escribas cuenta con el límite de memoria del contenedor. {{< note >}} Si el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SizeMemoryBackedVolumes` está habilitado, From faf4af3354efb925365e219525d0656dd3f49177 Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:06:58 +0200 Subject: [PATCH 19/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index edee5b04cd..cfeeacb832 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -259,7 +259,7 @@ Dependiendo de tu entorno, los volúmenes `emptydir` se almacenan en cualquier m {{< note >}} Si el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SizeMemoryBackedVolumes` está habilitado, -puedes especificar un tamaño para los volúmenes respaldados en memoria. Si no se especifica ningún tamaño los volúmenes respaldados en memoria tienen un tamaño del 50% de la memoria en un host Linux. +puedes especificar un tamaño para los volúmenes respaldados en memoria. Si no se especifica ningún tamaño, los volúmenes respaldados en memoria tienen un tamaño del 50% de la memoria en un host Linux. {{< /note>}} #### Ejemplo de configuración de emptyDir From 059b7c53ac1fc407a5bbfb207298a28c9f35c38e Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:07:10 +0200 Subject: [PATCH 20/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index cfeeacb832..d6a677e634 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -284,7 +284,7 @@ spec: ### fc (canal de fibra) {#fc} Un tipo de volumen `fc` permite que un volumen de almacenamiento de bloque de canal de fibra existente se monte en un Pod. -Puede especificar nombres mundiales de destino únicos o múltiples (WWN) utilizando el parámetro `targetWWNs` en su configuración de Volumen. +Puede especificar nombres mundiales de destino únicos o múltiples (WWN) utilizando el parámetro `targetWWNs` en su configuración de volumen. Si se especifican varios WWN, targettWWNs esperan que esos WWN sean de conexiones de múltiples rutas. {{< note >}} From 3718b999285a58d232b9634a8a2acf989a470062 Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:07:22 +0200 Subject: [PATCH 21/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index d6a677e634..46e5ca743e 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -312,7 +312,7 @@ Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< pa Un volumen `gcePersistentDisk` monta un volumen de Google Compute Engine (GCE) de [disco persistente](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. -A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un DP es preservado +A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un disco persistente es preservado y el volumen solamente se desmonta. Esto significa que un PD puede ser pre-poblado con datos, y que esos datos se pueden compartir entre pods. From 75872b71cd8d2c20e0ad0eadb01fec23508c5c2d Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:07:30 +0200 Subject: [PATCH 22/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 46e5ca743e..e86ca37fc7 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -313,7 +313,7 @@ Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< pa Un volumen `gcePersistentDisk` monta un volumen de Google Compute Engine (GCE) de [disco persistente](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un disco persistente es preservado -y el volumen solamente se desmonta. Esto significa que un PD puede ser pre-poblado con datos, +y el volumen solamente se desmonta. Esto significa que un disco persistente puede ser pre-poblado con datos, y que esos datos se pueden compartir entre pods. {{< note >}} From fb1e0fbd86490250142aab159b87f3d8b5ffd2b3 Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:07:52 +0200 Subject: [PATCH 23/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index e86ca37fc7..7de15bed95 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -317,7 +317,7 @@ y el volumen solamente se desmonta. Esto significa que un disco persistente pued y que esos datos se pueden compartir entre pods. {{< note >}} -Debes crear un PD usando `gcloud` or la API de GCE o la UI antes de poder usarlo. +Debes crear un disco persistente usando `gcloud`, la API de GCE o la UI antes de poder usarlo. {{< /note >}} Existen algunas restricciones cuando usas `gcePersistentDisk`: From dd316d55250dec70c62caeda512df3af7a73df1b Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:08:16 +0200 Subject: [PATCH 24/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 7de15bed95..42d83a0937 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -323,7 +323,7 @@ Debes crear un disco persistente usando `gcloud`, la API de GCE o la UI antes de Existen algunas restricciones cuando usas `gcePersistentDisk`: - Los nodos en los que se ejecutan los pods deben ser máquinas virtuales GCE. -- Esas máquinas virtuales deben estar en el mismo proyecto GCE y zona que el disco persistente. +- Esas máquinas virtuales deben estar en el mismo proyecto GCE y zona que el disco persistente se encuentra. Una de las características del disco persistente CGE es acceso concurrente de solo lectura al disco persistente. Un volumen `gcePersistentDisk` permite montar simultáneamente un disco de solo lectura a múltiples consumidores. From 0f97e0c5acc9c769482183df0cd5dad855e6e9b6 Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:08:32 +0200 Subject: [PATCH 25/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 42d83a0937..1a430e91f8 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -549,7 +549,7 @@ spec: Un volumen `iscsi` permite que se monte un volumen ISCSI (SCSI sobre IP) existente en tu Pod. A diferencia de `emptydir`, que es removido cuando se remueve un Pod, el contenido de un volumen `iscsi` es preservado y el volumen solamente se desmonta. -Esto significa que un volumen iscsi puede ser pre-poblado con dato, y que estos datos se pueden compartir entre pods. +Esto significa que un volumen iscsi puede ser pre-poblado con datos, y que estos datos se pueden compartir entre pods. {{< note >}} Debes tener tu propio servidor ISCSI corriendo con el volumen creado antes de poder usarlo. From 563b74e02ec79b28d0bbcd4f522781aa5d62b11e Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:08:41 +0200 Subject: [PATCH 26/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 1a430e91f8..9743c55320 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -560,7 +560,7 @@ Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y servi Desafortunadamente, los volúmenes ISCSI solo se pueden montar por un único consumidor en modo lectura-escritura. Escritores simultáneos no está permitido. -Mira el [ ejemplo iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) para más detalles. +Mira el [ejemplo iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) para más detalles. ### local From c73166a15a35febac3128d9862fc8ea33ff265ba Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:08:48 +0200 Subject: [PATCH 27/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 9743c55320..bcb35a48dd 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -572,7 +572,7 @@ El aprovisionamiento dinámico no está soportado. Comparados con volúmenes `hostPath`, los volúmenes `local` se usan de manera duradera y portátil sin programar pods manualmente a los nodos. El sistema está consciente de las limitaciones del nodo del volumen al mirar la afinidad del nodo en el PersistenVolumen. -Sn embargo, los volúmenes `local`están sujetos a la disponibilidad del nodo subyacente y no son compatibles para todas las aplicaciones. +Sin embargo, los volúmenes `local`están sujetos a la disponibilidad del nodo subyacente y no son compatibles para todas las aplicaciones. Si un nodo deja de estar sano, entonces el volumen `local` se vuelve inaccesible al pod. El pod que utiliza este volumen no se puede ejecutar. From 9960d32d983417f5ac3d3573bf2d953418a1f314 Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:08:55 +0200 Subject: [PATCH 28/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index bcb35a48dd..acf9a0c943 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -575,7 +575,7 @@ a los nodos. El sistema está consciente de las limitaciones del nodo del volume Sin embargo, los volúmenes `local`están sujetos a la disponibilidad del nodo subyacente y no son compatibles para todas las aplicaciones. Si un nodo deja de estar sano, entonces el volumen `local` se vuelve inaccesible al pod. -El pod que utiliza este volumen no se puede ejecutar. +El Pod que utiliza este volumen no se puede ejecutar. Las aplicaciones que usan volúmenes `local` deben ser capaces de tolerar esta disponibilidad reducida, así como la pérdida potencial de datos, dependiendo de las características de durabilidad del disco subyacente. From 21f41c68308a1e3a0244a60d3b46c397243cd54d Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Wed, 4 Aug 2021 05:09:07 +0200 Subject: [PATCH 29/79] Update content/es/docs/concepts/storage/volumes.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index acf9a0c943..1cefd76f2c 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -607,7 +607,7 @@ spec: ``` Debes establecer un valor de `nodeAffinity` del PersistenVolume cuando uses volúmenes `local`. -El programador de Kubernetes usa esta `nodeaffinity` del PersistenVolume para programar estos Pods al nodo correcto. +El Scheduler de Kubernetes usa `nodeaffinity` del PersistenVolume para programar estos Pods al nodo correcto. El `volumeMode` del PersistentVolume se puede establecer en "Block" (en lugar del valor por defecto, "Filesystem") para exponer el volumen local como un dispositivo de bloque sin formato. From 03d287c19ded02c730a171929bdf515886c71315 Mon Sep 17 00:00:00 2001 From: anyulled Date: Wed, 4 Aug 2021 05:13:21 +0200 Subject: [PATCH 30/79] docs: volumes - style correction --- content/es/docs/concepts/storage/volumes.md | 56 ++++++++++----------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index 1cefd76f2c..fa2f781a69 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -23,7 +23,7 @@ Kubernetes soporta muchos tipos de volúmenes. Un {{< glossary_tooltip term_id=" puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el mismo tiempo de vida que un Pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un Pod. Cuando un Pod deja de existir, Kubernetes destruye los volúmenes efímeros; sin embargo, Kubernetes no destruye los volúmenes persistentes. Para cualquier tipo de volumen en un Pod dado, los datos son preservados a lo largo de los reinicios del contenedor. -En su núcleo, un volumen es un directorio, posiblemente con algunos datos en este, que puede ser accesible para los contenedores en un pod. Cómo ese directorio llega a crearse, el medio que lo respalda, y el contenido de este se determinan por el tipo de volumen usado. +En su núcleo, un volumen es un directorio, posiblemente con algunos datos en este, que puede ser accesible para los contenedores en un Pod. Cómo ese directorio llega a crearse, el medio que lo respalda, y el contenido de este se determinan por el tipo de volumen usado. Para usar un volumen, especifica los volúmenes a proveer al por en `.spec.volumes` y declara dónde montar estos volúmenes dentro de los contenedores en `.spec.containers[*].volumeMounts`. @@ -38,8 +38,8 @@ Kubernetes soporta varios tipos de volúmenes ### awsElasticBlockStore {#awselasticblockstore} Un volumen `awsElasticBlockStore` monta un -[volumen EBS](https://aws.amazon.com/ebs/) de Amazon Web Services (AWS) en tu pod. A diferencia de -`emptyDir`, que se borra cuando se quita un pod, el contenido de un volumen EBS es persistido cuando se desmonta el volumen. +[volumen EBS](https://aws.amazon.com/ebs/) de Amazon Web Services (AWS) en tu Pod. A diferencia de +`emptyDir`, que se borra cuando se quita un Pod, el contenido de un volumen EBS es persistido cuando se desmonta el volumen. Esto significa que un volumen EBS puede ser pre-poblado con datos, y que los datos puedes ser compartidos entre pods. {{< note >}} @@ -54,7 +54,7 @@ Existen algunas restricciones cuando usas un volumen `awsElasticBlockStore`: #### Creando un volumen AWS EBS -Antes poder usar un volumen EBS en un pod, necesitas crearlo. +Antes poder usar un volumen EBS en un Pod, necesitas crearlo. ```shell aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 @@ -103,7 +103,7 @@ Para desactivar el complemento de almacenamiento `awsElasticBlockStore` de ser c ### azureDisk {#azuredisk} -El tipo de volumen `azureDisk` monta un [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) de Microsoft Azure en el pod. +El tipo de volumen `azureDisk` monta un [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) de Microsoft Azure en el Pod. Para más detalles, mira el [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md). @@ -117,7 +117,7 @@ de complemento desde el complemento existente dentro del árbol existente al con ### azureFile {#azurefile} -El tipo de volumen `azureFile` monta un volumen de ficheros de Microsoft Azure (SMB 2.1 and 3.0) en un pod. +El tipo de volumen `azureFile` monta un volumen de ficheros de Microsoft Azure (SMB 2.1 and 3.0) en un Pod. Para más detalles, mira el [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). @@ -135,7 +135,7 @@ El controlador Azure File CSI no soporta usar el mismo volumen con fsgroups dife ### cephfs Un volumen `cephfs` permite montar un volumen CephFS existente en tu Pod. -A diferencia de `emptydir`, que es borrado cuando se remueve el pod, el contenido de un volumen `cephfs` es preservado y el volumen es meramente desmontado. Esto significa que un volumen `cephfs`puede ser pre-poblado por múltiples escritores simultáneamente. +A diferencia de `emptydir`, que es borrado cuando se remueve el Pod, el contenido de un volumen `cephfs` es preservado y el volumen es meramente desmontado. Esto significa que un volumen `cephfs`puede ser pre-poblado por múltiples escritores simultáneamente. {{< note >}} Debes tener tu propio servidor Ceph corriendo con el recurso compartido exportado antes de usarlo. @@ -149,7 +149,7 @@ Mira el [CephFS example](https://github.com/kubernetes/examples/tree/{{< param " Kubernetes no debe ser configurado con el proveedor cloud OpenStack. {{< /note >}} -El tipo de volumen `cinder` se usa para montar un volumen Cinder de OpenStack en tu pod. +El tipo de volumen `cinder` se usa para montar un volumen Cinder de OpenStack en tu Pod. #### Cinder volume configuration example @@ -189,11 +189,11 @@ Si deshabilitas la función `CSIMigrationOpenStack`, el complemento del volumen Un [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) provee una manera de inyectar datos de configuración a los pods. Los datos almacenados en un ConfigMap se pueden referenciar en un volumen de tipo `configMap` -y luego ser consumidos por aplicaciones contenerizadas corriendo en un pod. +y luego ser consumidos por aplicaciones contenerizadas corriendo en un Pod. Cuando haces referencia a un ConfigMap, provees el nombre del ConfigMap en el volumen. Puedes personalizar la ruta para una entrada específica en el ConfigMap. -La siguiente configuración muestra cómo montar un ConfigMap `log-config` en un Pod llamado `configmap-pod:` +La siguiente configuración muestra cómo montar un ConfigMap `log-config` en un Pod llamado `configmap-pod`: ```yaml apiVersion: v1 @@ -239,7 +239,7 @@ Mira el [downward API example](/docs/tasks/inject-data-application/downward-api- ### emptyDir {#emptydir} -Un volumen `emptyDir`es creado primero cuando se asigna un pod a un nodo, y existe mientras el Pod está corriendo en el nodo. +Un volumen `emptyDir`es creado primero cuando se asigna un Pod a un nodo, y existe mientras el Pod está corriendo en el nodo. Como su nombre lo indica un volumen `emptydir`está inicialmente vacío. Todos los contenedores en el Pod pueden leer y escribir los archivos en el volumen `emptyDir`, aunque ese volumen se puede montar en la misma o diferente ruta en cada contenedor. Cuando un Pod es removido del nodo por alguna razón, los datos en `emptydir` se borran permanentemente. @@ -300,7 +300,7 @@ Revisa el [ejemplo de canal de fibra](https://github.com/kubernetes/examples/tre Flocker proporciona administración y orquestación de volúmenes de datos respaldados por una variedad de backends de almacenamiento. Un volumen `flocker` permite montar un conjunto de datos Flocker en un Pod. Si el conjunto de datos no existe en Flocker, necesita ser creado primero con el CLI de Flocker o usando la API de Flocker. Si el conjunto de datos existe será adjuntado -de nuevo por Flocker al nodo donde el pod está programado. Esto significa que los datos pueden ser compartidos entre pods como sea necesario. +de nuevo por Flocker al nodo donde el Pod está programado. Esto significa que los datos pueden ser compartidos entre pods como sea necesario. {{< note >}} Debes tener una instalación propia de Flocker ejecutándose antes de poder usarla. @@ -312,7 +312,7 @@ Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< pa Un volumen `gcePersistentDisk` monta un volumen de Google Compute Engine (GCE) de [disco persistente](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. -A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un disco persistente es preservado +A diferencia de `emptyDir`, que se borra cuando el Pod es removido, el contenido de un disco persistente es preservado y el volumen solamente se desmonta. Esto significa que un disco persistente puede ser pre-poblado con datos, y que esos datos se pueden compartir entre pods. @@ -366,7 +366,7 @@ spec: La función de [discos regionales persistentes](https://cloud.google.com/compute/docs/disks/#repds) permite la creación de discos persistentes que están disponibles en dos zonas dentro de la misma región. -Para usar esta función, el volumen debe ser provisto como un PersistentVolumen; referenciar el volumen directamente desde un pod no está soportado. +Para usar esta función, el volumen debe ser provisto como un PersistentVolumen; referenciar el volumen directamente desde un Pod no está soportado. #### Aprovisionamiento manual de un PD PersistentVolume Regional @@ -445,7 +445,7 @@ spec: ### glusterfs Un volumen `glusterfs` permite montar un volumen [Glusterfs](https://www.gluster.org) en tu Pod. -A diferencia de `emptyDir`, que se borra cuando se remueve un pod, el contenido de un volumen `glusterfs` es preservado +A diferencia de `emptyDir`, que se borra cuando se remueve un Pod, el contenido de un volumen `glusterfs` es preservado y el volumen solamente se desmonta. Esto significa que un volumen glusterfs puede ser pre-poblado con datos, y que los datos pueden ser compartidos entre pods. GlusterFS puede ser montado por múltiples escritores simultáneamente. @@ -457,12 +457,12 @@ Mira el [ejemplo de GlusterFS](https://github.com/kubernetes/examples/tree/{{< p ### hostPath {#hostpath} -Un volumen `hostPath` mona un fichero o un directorio del sistema de archivos del nodo host a tu Pod. +Un volumen `hostPath` monta un archivo o un directorio del sistema de archivos del nodo host a tu Pod. Esto no es algo de muchos Pods necesiten, pero ofrece una trampa de escape poderosa para algunas aplicaciones. Por ejemplo, algunos usos de un `hostPath` son: -- ejecutar un contenedor que necesita acceso a los directorios internos de docker, usa un `hostPath` de `/var/lib/docker` +- ejecutar un contenedor que necesita acceso a los directorios internos de Docker, usa un `hostPath` de `/var/lib/docker` - ejecutar un cAdvisor en un contenedor; usa un `hostPath` de `/sys` - permitir a un Pod especificar si un `hostPath` dado debería existir ante de correr el Pod, si debe crearse, cómo debe existir @@ -475,8 +475,8 @@ Los valores soportados para el campo `tipo` son: | | Una cadena vacía (por defecto) es para compatibilidad con versiones anteriores, lo que significa que no se harán revisiones antes de montar el volumen hostPath. | | `DirectoryOrCreate` | Si no hay nada en la ruta dada, se creará un directorio vacío como es requerido con los permisos a 0755, teniendo el mismo grupo y propiedad que el Kubelet. | | `Directory` | Un directorio debe existir en la ruta dada | -| `FileOrCreate` | Si no hay nada en la ruta dada, se creará un fichero vacío como es requerido con los permisos a 0644, teniendo el mismo grupo y propiedad que el Kubelet. | -| `File` | Un fichero debe existir en la ruta dada | +| `FileOrCreate` | Si no hay nada en la ruta dada, se creará un archivo vacío como es requerido con los permisos a 0644, teniendo el mismo grupo y propiedad que el Kubelet. | +| `File` | Un archivo debe existir en la ruta dada | | `Socket` | Un socket de UNIX debe existir en la ruta dada | | `CharDevice` | Un dispositivo de caracteres debe existir en la ruta data | | `BlockDevice` | Un dispositivo de bloques dbe existir en la ruta dada | @@ -511,8 +511,8 @@ spec: ``` {{< caution >}} -El modo `FileOrCreate` no crea el directorio padre del fichero. Si el directorio padre del fichero montado no existe, -el pod falla en iniciar. Para asegurar que este modo funciona, puedes intentar montar directorios y ficheros de forma separada, +El modo `FileOrCreate` no crea el directorio padre del archivo. Si el directorio padre del archivo montado no existe, +el Pod falla en iniciar. Para asegurar que este modo funciona, puedes intentar montar directorios y ficheros de forma separada, tal como se muestra en la [ confugiración `FileOrCreate`](#hostpath-fileorcreate-example) {{< /caution >}} @@ -535,7 +535,7 @@ spec: volumes: - name: mydir hostPath: - # Asegúrate que el directorio del fichero es creado. + # Asegúrate que el directorio del archivo es creado. path: /var/local/aaa type: DirectoryOrCreate - name: myfile @@ -574,7 +574,7 @@ a los nodos. El sistema está consciente de las limitaciones del nodo del volume Sin embargo, los volúmenes `local`están sujetos a la disponibilidad del nodo subyacente y no son compatibles para todas las aplicaciones. -Si un nodo deja de estar sano, entonces el volumen `local` se vuelve inaccesible al pod. +Si un nodo deja de estar sano, entonces el volumen `local` se vuelve inaccesible al Pod. El Pod que utiliza este volumen no se puede ejecutar. Las aplicaciones que usan volúmenes `local` deben ser capaces de tolerar esta disponibilidad reducida, así como la pérdida potencial de datos, dependiendo de las características de durabilidad del disco subyacente. @@ -638,7 +638,7 @@ Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/{{< param "g ### persistentVolumeClaim {#persistentvolumeclaim} -Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del ambiente de la nube en particular. +Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del ambiente de la nube en particular. Mira la información spbre [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) para más detalles. @@ -819,7 +819,7 @@ CSI es el complemento recomendado para usar Quobyte dentro de Kubernetes. El pro ### rbd Un volumen `rbd` permite montar un volumen [Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) en tu Pod. -A diferencia de `emptyDir`, que se borra cuando el pod es removido, el contenido de un volumen `rbd` es preservado y el volumen se desmonta. Esto significa que un volumen RBD puede ser pre-poblado con datos, y que estos datos pueden ser compartidos entre pods. +A diferencia de `emptyDir`, que se borra cuando el Pod es removido, el contenido de un volumen `rbd` es preservado y el volumen se desmonta. Esto significa que un volumen RBD puede ser pre-poblado con datos, y que estos datos pueden ser compartidos entre pods. {{< note >}} Debes tener una instalación de Ceph ejecutándose antes de usar RBD. @@ -1020,7 +1020,7 @@ Para apagar el complemento `vsphereVolume` y no cargarlo por el administrador de ## Uso de subPath {#using-subpath} -Algunas veces es útil compartir un volumen para múltiples usos en un único pod. +Algunas veces es útil compartir un volumen para múltiples usos en un único Pod. La propiedad `volumeMounts.subPath` especifica una sub-ruta dentro del volumen referenciado en lugar de su raíz. El siguiente ejemplo muestra cómo configurar un Pod con la pila LAMP (Linux Apache MySQL PHP) usando un único volumen compartido. Esta configuración de ejemplo usando `subPath` no se recomienda para su uso en producción. @@ -1168,7 +1168,7 @@ You can set up your [PersistentVolume/PersistentVolumeClaim with raw block volum {{< feature-state for_k8s_version="v1.16" state="beta" >}} Puedes configurar directamente volúmenes CSI dentro de la especificación del Pod. -Los volúmenes especificados de esta manera son efímeros y no se persisten entre reinicios del pod. Mira [Volúmenes efímeros](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) para más información. +Los volúmenes especificados de esta manera son efímeros y no se persisten entre reinicios del Pod. Mira [Volúmenes efímeros](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) para más información. Para más información de cómo desarrollador un controlador CSI, mira la [documentación kubernetes-csi](https://kubernetes-csi.github.io/docs/) @@ -1195,7 +1195,7 @@ For more details, see the [FlexVolume](https://github.com/kubernetes/community/b ## Propagación del montaje -La propagación del montaje permite compartir volúmenes montados por un contenedor para otros contenedores en el mismo pod, o aun para otros pods en el mismo nodo. +La propagación del montaje permite compartir volúmenes montados por un contenedor para otros contenedores en el mismo Pod, o aun para otros pods en el mismo nodo. La propagación del montaje de un volumen es controlada por el campo `mountPropagation` en `Container.volumeMounts`. Sus valores son: From a7639240eac739b94acb02108153ad587f15b973 Mon Sep 17 00:00:00 2001 From: Daniel Rotter Date: Thu, 12 Aug 2021 08:17:58 +0200 Subject: [PATCH 31/79] Fix a typo in Deplyoments --- .../overview/working-with-objects/kubernetes-objects.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 38165d0024..c763b40e05 100644 --- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -84,7 +84,7 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes. For example, the reference for Pod details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) -for a Pod in the API, and the reference for Deployment details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec) for Deployents. +for a Pod in the API, and the reference for Deployment details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec) for Deployments. In those API reference pages you'll see mention of PodSpec and DeploymentSpec. These names are implementation details of the Golang code that Kubernetes uses to implement its API. From cfccbdfb1f390ee4f8339d4eda8761aea32e239a Mon Sep 17 00:00:00 2001 From: Victuos <1408582+victuos@users.noreply.github.com> Date: Thu, 12 Aug 2021 17:28:53 +0200 Subject: [PATCH 32/79] Adjust broken link in service.md --- content/en/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index c3a93921b0..d501ffe309 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -429,7 +429,7 @@ variables and DNS. When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. It supports both [Docker links compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see -[makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) +[makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/envvars/envvars.go#L72)) and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. From b4ef0b940e1d3b57184f90a5911b981ad549ac36 Mon Sep 17 00:00:00 2001 From: Pankaj Patil Date: Sat, 14 Aug 2021 20:27:40 +0530 Subject: [PATCH 33/79] Replace cascade=false -> cascade=orphan --- .../2021-05-14-using-finalizers-to-control-deletion.md | 6 +++--- content/en/docs/concepts/workloads/controllers/daemonset.md | 2 +- content/en/docs/concepts/workloads/controllers/job.md | 2 +- .../concepts/workloads/controllers/replicationcontroller.md | 2 +- .../docs/tasks/administer-cluster/use-cascading-deletion.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md b/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md index 1f6403b301..19d79d3f44 100644 --- a/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md +++ b/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md @@ -190,9 +190,9 @@ kubectl get configmap No resources found in default namespace. ``` -To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=false option for `kubectl delete` to delete an object and orphan its children. +To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=orphan option for `kubectl delete` to delete an object and orphan its children. -In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=false, the parent is deleted but the child still exists: +In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=orphan, the parent is deleted but the child still exists: ``` kubectl get configmap @@ -200,7 +200,7 @@ NAME DATA AGE mymap-child 0 13m8s mymap-parent 0 13m8s -kubectl delete --cascade=false configmap/mymap-parent +kubectl delete --cascade=orphan configmap/mymap-parent configmap "mymap-parent" deleted kubectl get configmap diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index c5d3c4c6c8..df3c4bdd8d 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -185,7 +185,7 @@ You can modify the Pods that a DaemonSet creates. However, Pods do not allow al fields to be updated. Also, the DaemonSet controller will use the original template the next time a node (even with the same name) is created. -You can delete a DaemonSet. If you specify `--cascade=false` with `kubectl`, then the Pods +You can delete a DaemonSet. If you specify `--cascade=orphan` with `kubectl`, then the Pods will be left on the nodes. If you subsequently create a new DaemonSet with the same selector, the new DaemonSet adopts the existing Pods. If any Pods need replacing the DaemonSet replaces them according to its `updateStrategy`. diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 6d90ce1cbb..4808bf4647 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -523,7 +523,7 @@ to keep running, but you want the rest of the Pods it creates to use a different pod template and for the Job to have a new name. You cannot update the Job because these fields are not updatable. Therefore, you delete Job `old` but _leave its pods -running_, using `kubectl delete jobs/old --cascade=false`. +running_, using `kubectl delete jobs/old --cascade=orphan`. Before deleting it, you make a note of what selector it uses: ```shell diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index 2b06539fd6..5a10271b01 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md @@ -192,7 +192,7 @@ When using the REST API or Go client library, you need to do the steps explicitl You can delete a ReplicationController without affecting any of its pods. -Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). +Using kubectl, specify the `--cascade=orphan` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). When using the REST API or Go client library, you can delete the ReplicationController object. diff --git a/content/en/docs/tasks/administer-cluster/use-cascading-deletion.md b/content/en/docs/tasks/administer-cluster/use-cascading-deletion.md index eb72d68de0..977278ae60 100644 --- a/content/en/docs/tasks/administer-cluster/use-cascading-deletion.md +++ b/content/en/docs/tasks/administer-cluster/use-cascading-deletion.md @@ -302,7 +302,7 @@ For details, read the [documentation for your Kubernetes version](/docs/home/sup Run the following command: ```shell -kubectl delete deployment nginx-deployment --cascade=false +kubectl delete deployment nginx-deployment --cascade=orphan ``` **Using the Kubernetes API** From 340125aa5baf4bd2efdc0b0f277d3b9a020633fc Mon Sep 17 00:00:00 2001 From: astraw99 Date: Fri, 20 Aug 2021 14:40:08 +0800 Subject: [PATCH 34/79] fix typo and its related `en` doc sync --- .../tasks/extend-kubernetes/configure-aggregation-layer.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md index 6203bd5bee..baa40e2f5c 100644 --- a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md +++ b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md @@ -27,7 +27,7 @@ Kubernetes API 的一部分。 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< note >}} 要使聚合层在你的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证， @@ -550,10 +550,10 @@ APIService 对象的名称必须是合法的 + +En Kubernetes, un _VolumeSnapshot_ representa un Snapshot de un volumen en un sistema de almacenamiento. Este documento asume que ya está familiarizado con Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/). + + + + + + +## Introducción + +Al igual que los recursos de API `PersistentVolume` y `PersistentVolumeClaim` se utilizan para aprovisionar volúmenes para usuarios y administradores, `VolumeSnapshotContent` y `VolumeSnapshot` se proporcionan para crear Snapshots de volumen para usuarios y administradores. + +Un `VolumeSnapshotContent` es un Snapshot tomado de un volumen en el clúster que ha sido aprovisionado por un administrador. Es un recurso en el clúster al igual que un PersistentVolume es un recurso de clúster. + +Un `VolumeSnapshot` es una solicitud de Snapshot de un volumen por parte del usuario. Es similar a un PersistentVolumeClaim. + +`VolumeSnapshotClass` permite especificar diferentes atributos que pertenecen a un `VolumeSnapshot`. Estos atributos pueden diferir entre Snapshots tomados del mismo volumen en el sistema de almacenamiento y, por lo tanto, no se pueden expresar mediante el mismo `StorageClass` de un `PersistentVolumeClaim`. + +Los Snapshots de volumen brindan a los usuarios de Kubernetes una forma estandarizada de copiar el contenido de un volumen en un momento determinado, sin crear uno completamente nuevo. Esta funcionalidad permite, por ejemplo, a los administradores de bases de datos realizar copias de seguridad de las bases de datos antes de realizar una edición o eliminar modificaciones. + +Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: + +* Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, no parte de la API principal. +* La compatibilidad con `VolumeSnapshot` solo está disponible para controladores CSI. +* Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. +* También hay un servidor webhook de validación que proporciona una validación más estricta en los objetos Snapshot. Esto debe ser instalado por las distribuciones de Kubernetes junto con el controlador de instantáneas y los CRDs, no los controladores CSI. Debe instalarse en todos los clústeres de Kubernetes que tengan habilitada la función de Snapshot. +* Los controladores CSI pueden haber implementado o no la funcionalidad de Snapshot de volumen. Los controladores CSI que han proporcionado soporte para Snapshot de volumen probablemente usarán csi-snapshotter. Consulte [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) para obtener más detalles. +* Los CRDs y las instalaciones del controlador de Snapshot son responsabilidad de la distribución de Kubernetes. + +## Ciclo de vida de un Snapshot de volumen y el contenido de un Snapshot de volumen. + +`VolumeSnapshotContents` son recursos en el clúster. `VolumeSnapshots` son solicitudes de esos recursos. La interacción entre `VolumeSnapshotContents` y `VolumeSnapshots` sigue este ciclo de vida: + +### Snapshot del volumen de aprovisionamiento + +Hay dos formas de aprovisionar las instantáneas: aprovisionadas previamente o aprovisionadas dinámicamente. + +#### Pre-aprovisionado {#static} +Un administrador de clúster crea una serie de `VolumeSnapshotContents`. Llevan los detalles de la instantánea del volumen real en el sistema de almacenamiento que está disponible para que lo utilicen los usuarios del clúster. Existen en la API de Kubernetes y están disponibles para su consumo. + +#### Dinámica +En lugar de utilizar un Snapshot preexistente, puede solicitar que se tome una Snapshot dinámicamente de un PersistentVolumeClaim. El [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) especifica los parámetros específicos del proveedor de almacenamiento para usar al tomar una Snapshot. + +### Vinculante + +El controlador de instantáneas maneja el enlace de un objeto `VolumeSnapshot` con un objeto `VolumeSnapshotContent` apropiado, tanto en escenarios de aprovisionamiento previo como de aprovisionamiento dinámico. El enlace es un mapeo uno a uno. + +En el caso de un enlace aprovisionado previamente, el VolumeSnapshot permanecerá sin enlazar hasta que se cree el objeto VolumeSnapshotContent solicitado. + +### Persistent Volume Claim como Protección de fuente de Snapshot + +El propósito de esta protección es garantizar que los objetos de la API +{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} +en uso, no se eliminen del sistema mientras se toma un Snapshot (ya que esto puede resultar en la pérdida de datos). + +Mientras se toma un Snapshot de un PersistentVolumeClaim, ese PersistentVolumeClaim está en uso. Si elimina un objeto de la API PersistentVolumeClaim en uso activo como fuente de Snapshot, el objeto PersistentVolumeClaim no se elimina de inmediato. En cambio, la eliminación del objeto PersistentVolumeClaim se pospone hasta que el Snapshot esté readyToUse o se cancele. + +### Borrar + +La eliminación se activa al eliminar el objeto `VolumeSnapshot`, y se seguirá la `DeletionPolicy`. Sí `DeletionPolicy` es `Delete`, entonces el Snapshot de almacenamiento subyacente se eliminará junto con el objeto `VolumeSnapshotContent`. Sí `DeletionPolicy` es `Retain`, tanto la instantánea subyacente como `VolumeSnapshotContent` permanecen. + +## VolumeSnapshots + +Cada VolumeSnapshot contiene una especificación y un estado. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshot +metadata: + name: new-snapshot-test +spec: + volumeSnapshotClassName: csi-hostpath-snapclass + source: + persistentVolumeClaimName: pvc-test +``` + +`persistentVolumeClaimName` es el nombre de la fuente de datos PersistentVolumeClaim para el Snapshot. Este campo es obligatorio para aprovisionar dinámicamente un Snapshot. + +Un Snapshot de volumen puede solicitar una clase particular especificando el nombre de un [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) +utilizando el atributo `volumeSnapshotClassName`. Si no se establece nada, se usa la clase predeterminada si está disponible. + +Para los Snapshots aprovisionadas previamente, debe especificar un `volumeSnapshotContentName` como el origen del Snapshot, como se muestra en el siguiente ejemplo. El campo de origen `volumeSnapshotContentName` es obligatorio para los Snapshots aprovisionados previamente. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshot +metadata: + name: test-snapshot +spec: + source: + volumeSnapshotContentName: test-content +``` + +## Contenido del Snapshot de volumen + +Cada VolumeSnapshotContent contiene una especificación y un estado. En el aprovisionamiento dinámico, el controlador común de Snapshots crea objetos `VolumeSnapshotContent`. Aquí hay un ejemplo: + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotContent +metadata: + name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455 +spec: + deletionPolicy: Delete + driver: hostpath.csi.k8s.io + source: + volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002 + volumeSnapshotClassName: csi-hostpath-snapclass + volumeSnapshotRef: + name: new-snapshot-test + namespace: default + uid: 72d9a349-aacd-42d2-a240-d775650d2455 +``` + +`volumeHandle` es el identificador único del volumen creado en el backend de almacenamiento y devuelto por el controlador CSI durante la creación del volumen. Este campo es obligatorio para aprovisionar dinámicamente un Snapshot. Especifica el origen del volumen del Snapshot. + +Para los Snapshots aprovisionados previamente, usted (como administrador del clúster) es responsable de crear el objeto `VolumeSnapshotContent` de la siguiente manera. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotContent +metadata: + name: new-snapshot-content-test +spec: + deletionPolicy: Delete + driver: hostpath.csi.k8s.io + source: + snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 + volumeSnapshotRef: + name: new-snapshot-test + namespace: default +``` + +`snapshotHandle` es el identificador único del Snapshot de volumen creado en el backend de almacenamiento. Este campo es obligatorio para las Snapshots aprovisionadas previamente. Especifica el ID del Snapshot CSI en el sistema de almacenamiento que representa el `VolumeSnapshotContent`. + +## Aprovisionamiento de Volúmenes a partir de Snapshots + +Puede aprovisionar un nuevo volumen, rellenado previamente con datos de una Snapshot, mediante el campo *dataSource* en el objeto `PersistentVolumeClaim`. + +Para obtener más detalles, consulte +[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). From b7c57a160ca560797d805936b38057bcd7e94e1b Mon Sep 17 00:00:00 2001 From: Marat <1203Marat@gmail.com> Date: Tue, 7 Sep 2021 11:41:59 +0600 Subject: [PATCH 36/79] [ru] Add translate addons.md file in the content/ru/docs/concepts/cluster-administration --- .../concepts/cluster-administration/_index.md | 70 +++++++++++++++++++ .../concepts/cluster-administration/addons.md | 53 ++++++++++++++ 2 files changed, 123 insertions(+) create mode 100644 content/ru/docs/concepts/cluster-administration/_index.md create mode 100644 content/ru/docs/concepts/cluster-administration/addons.md diff --git a/content/ru/docs/concepts/cluster-administration/_index.md b/content/ru/docs/concepts/cluster-administration/_index.md new file mode 100644 index 0000000000..b596e111f3 --- /dev/null +++ b/content/ru/docs/concepts/cluster-administration/_index.md @@ -0,0 +1,70 @@ +--- +title: Администрирование кластера +reviewers: +- davidopp +- lavalamp +weight: 100 +content_type: concept +description: > + Lower-level detail relevant to creating or administering a Kubernetes cluster. +no_list: true +--- + + +Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями] (/docs/concepts/) Kubernetes. + + + +## Планирование кластера + +См. Руководства в разделе [настройка](/docs/setup/) для получения примеров того, как планировать, устанавливать и настраивать кластеры Kubernetes. Решения, перечисленные в этой статье, называются *distros*. + + {{< note >}} + не все дистрибутивы активно поддерживаются. Выбирайте дистрибутивы, протестированные с последней версией Kubernetes. + {{< /note >}} + +Прежде чем выбрать руководство, вот некоторые соображения: + + - Вы хотите опробовать Kubernetes на вашем компьюторе или собрать многоузловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд. + - будете ли вы использовать **размещенный кластер Kubernetes**, такой как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**? + - Будет ли ваш кластер **в помещений** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров. + - **Если вы будете настроаивать Kubernetes в помещений (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего. + - Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **вирутальных машинах (VMs)**? + - Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают болле широкий выбор. + - Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходивые для запуска кластера. + + +## Управление кластером + +* Узнайте как [управлять узлами](/docs/concepts/architecture/nodes/). + +* Узнайте как настроить и управлять [квотами ресурсов](/docs/concepts/policy/resource-quotas/) для общих кластеров. + +## Обеспечение безопасности кластера + +* [Сгенерировать сертификаты](/docs/tasks/administer-cluster/certificates/) описывает шаги по созданию сертификатов с использованием различных цепочек инструментов. + +* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) описывает среду для управляемых контейнеров Kubelet на узле Kubernetes. + +* [Управление доступом к Kubernetes API](/docs/concepts/security/controlling-access) описывает как Kubernetes реализует контроль доступа для своего собственного API. + +* [Аутентификация](/docs/reference/access-authn-authz/authentication/) объясняет аутентификацию в Kubernetes, включая различные варианты аутентификации. + +* [Авторизация](/docs/reference/access-authn-authz/authorization/) отделена от аутентификации и контролирует обработку HTTP-вызовов. + +* [Использование контроллеров допуска](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. + +* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctlинструмент командной строки для установки параметров ядра. + +* [Аудит](/docs/tasks/debug-application-cluster/audit/) описывает, как взаимодействовать с журналами аудита Kubernetes. + +### Обеспечение безопасности kubelet + * [Связь между плоскостью управления и узлом](/docs/concepts/architecture/control-plane-node-communication/) + * [Загрузка TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Аутентификация/авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + +## Дополнительные кластерные услуги + +* [Интеграция DNS](/docs/concepts/services-networking/dns-pod-service/) описывает как разрешить DNS имя непосредственно службе Kubernetes. + +* [Ведение журнала и мониторинг активности кластера](/docs/concepts/cluster-administration/logging/) объясняет, как работает ведение журнала в Kubernetes и как его реализовать. diff --git a/content/ru/docs/concepts/cluster-administration/addons.md b/content/ru/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..82c8ab1695 --- /dev/null +++ b/content/ru/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,53 @@ +--- +title: Установка дополнений +content_type: concept +--- + + + +{{% thirdparty-content %}} + +Надстройки расширяют функциональность Kubernetes. + +На этой странице перечислены некоторые из доступных надстроек и ссылки на соответствующие инструкции по установке. + + + +## Сеть и сетевыя политика + +* [ACI](https://www.github.com/noironetworks/aci-containers) обеспечивает интегрированную сеть контейнеров и сетевую безопасность с помощью Cisco ACI. +* [Antrea](https://antrea.io/) работает на уровне 3, обеспечивая сетевые службы и службы безопасности для Kubernetes, используя Open vSwitch в качестве уровня сетевых данных. +* [Calico](https://docs.projectcalico.org/latest/introduction/) Calico поддерживает гибкий набор сетевых опций, поэтому вы можете выбрать наиболее эффективный вариант для вашей ситуации, включая сети без оверлея и оверлейные сети, с или без BGP. Calico использует тот же механизм для обеспечения соблюдения сетевой политики для хостов, модулей и (при использовании Istio и Envoy) приложений на уровне сервисной сети (mesh layer). +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политик. +* [Cilium](https://github.com/cilium/cilium) - это плагин сети L3 и сетевой политики, который может прозрачно применять политики HTTP/API/L7. Поддерживаются как режим маршрутизации, так и режим наложения/инкапсуляции, и он может работать поверх других подключаемых модулей CNI. +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) позволяет Kubernetes легко подключаться к выбору плагинов CNI, таких как Calico, Canal, Flannel, Romana или Weave. +* [Contiv](https://contiv.github.io) предоставляет настраиваемую сеть (собственный L3 с использованием BGP, слоя с использованием vxlan, классический L2 и Cisco-SDN/ACI) для различных вариантов использования и обширную структуру политик. Проект Contiv имеет полностью [открытый исходный код](https://github.com/contiv). [Установка](https://github.com/contiv/install) обеспечивает варианты на основе как kubeadm так и без kubeadm. +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric are интегрированы с системами оркестровки, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/pod-ов и рабочих нагрузок без операционной системы. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) - это поставщик оверлейной сети, который можно использовать с Kubernetes. +* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes pod-ов. +* [Multus](https://github.com/Intel-Corp/multus-cni) - это плагин Multi для поддержки нексольких сетейв Kubernetes для поддержки всех CNI плагинов (наприме: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes. +* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуалной сети a появившейся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS. +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложеных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) плагин для контейнера (NCP) обеспечивающий интеграцию между VMware NSX-T и контейнерами оркестраторов, таких как Kubernetes, а так же интеграцию между NSX-T и контейнеров на основе платформы CaaS/PaaS, таких как Pivotal Container Service (PKS) и OpenShift. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes Pod-ами и не Kubernetes окружением с отображением и мониторингом безопасности. +* [Romana](https://romana.io) - это сетевое решение уровня 3 для pod сетей, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize). +* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) обеспечивает сетевуюи политику сетей, будет работать в сетевого раздела и не требует внешней базы данных. + +## Обнаружение служб + +* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для pod-ов. + +## Визуализация и контроль + +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) - это веб-интерфейс панели инструментов для Kubernetes. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, pod-ов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно. + +## Инфраструктура + +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) - это дополнение для запуска виртуальных машин в Kubernetes. Обычно работает на bare-metal кластерах. + +## Legacy Add-ons + +В устаревшем каталоге [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) задокументировано несколько других дополнений. + +Ссылки на те, в хорошем состоянии, должны быть здесь. PR приветствуются! From 8555d69bb52a7370b43f8a7120beaddc1e679b4d Mon Sep 17 00:00:00 2001 From: Maxym Zalata Date: Wed, 8 Sep 2021 13:51:27 +0300 Subject: [PATCH 37/79] fix duplicate words --- content/en/docs/reference/kubectl/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index 611065eead..72a60f96a2 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -75,7 +75,7 @@ If you need help, run `kubectl help` from the terminal window. By default `kubectl` will first determine if it is running within a pod, and thus in a cluster. It starts by checking for the `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT` environment variables and the existence of a service account token file at `/var/run/secrets/kubernetes.io/serviceaccount/token`. If all three are found in-cluster authentication is assumed. -To maintain backwards compatibility, if the `POD_NAMESPACE` environment variable is set during in-cluster authentication it will override the default namespace from the from the service account token. Any manifests or tools relying on namespace defaulting will be affected by this. +To maintain backwards compatibility, if the `POD_NAMESPACE` environment variable is set during in-cluster authentication it will override the default namespace from the service account token. Any manifests or tools relying on namespace defaulting will be affected by this. **`POD_NAMESPACE` environment variable** From c0c54fca4da49f0bff615f4731b77704f6d2ba5e Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 11:50:36 -0500 Subject: [PATCH 38/79] Update content/es/docs/concepts/storage/volume-snapshots.md ups, se me fue! gracias! Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index 7cd0750ea0..06f7e284ea 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -33,7 +33,7 @@ Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: * Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, no parte de la API principal. * La compatibilidad con `VolumeSnapshot` solo está disponible para controladores CSI. * Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. -* También hay un servidor webhook de validación que proporciona una validación más estricta en los objetos Snapshot. Esto debe ser instalado por las distribuciones de Kubernetes junto con el controlador de instantáneas y los CRDs, no los controladores CSI. Debe instalarse en todos los clústeres de Kubernetes que tengan habilitada la función de Snapshot. +* También hay un servidor webhook de validación que proporciona una validación más estricta en los objetos Snapshot. Esto debe ser instalado por las distribuciones de Kubernetes junto con el controlador de Snapshots y los CRDs, no los controladores CSI. Debe instalarse en todos los clústeres de Kubernetes que tengan habilitada la función de Snapshot. * Los controladores CSI pueden haber implementado o no la funcionalidad de Snapshot de volumen. Los controladores CSI que han proporcionado soporte para Snapshot de volumen probablemente usarán csi-snapshotter. Consulte [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) para obtener más detalles. * Los CRDs y las instalaciones del controlador de Snapshot son responsabilidad de la distribución de Kubernetes. From f3b24cd30b462f55079d03d08a377c67d9cb82d2 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 11:53:34 -0500 Subject: [PATCH 39/79] Update content/es/docs/concepts/storage/volume-snapshots.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I translated instantáneas it :O, bad bad! :) Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index 06f7e284ea..ecc6f90e87 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -53,7 +53,7 @@ En lugar de utilizar un Snapshot preexistente, puede solicitar que se tome una S ### Vinculante -El controlador de instantáneas maneja el enlace de un objeto `VolumeSnapshot` con un objeto `VolumeSnapshotContent` apropiado, tanto en escenarios de aprovisionamiento previo como de aprovisionamiento dinámico. El enlace es un mapeo uno a uno. +El controlador de Snapshots maneja el enlace de un objeto `VolumeSnapshot` con un objeto `VolumeSnapshotContent` apropiado, tanto en escenarios de aprovisionamiento previo como de aprovisionamiento dinámico. El enlace es un mapeo uno a uno. En el caso de un enlace aprovisionado previamente, el VolumeSnapshot permanecerá sin enlazar hasta que se cree el objeto VolumeSnapshotContent solicitado. From 2c410e31c02c623c9808d4708f91a73439a0d015 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 11:59:05 -0500 Subject: [PATCH 40/79] Update content/es/docs/concepts/storage/volume-snapshots.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index ecc6f90e87..2a29f70d4f 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -57,7 +57,7 @@ El controlador de Snapshots maneja el enlace de un objeto `VolumeSnapshot` con u En el caso de un enlace aprovisionado previamente, el VolumeSnapshot permanecerá sin enlazar hasta que se cree el objeto VolumeSnapshotContent solicitado. -### Persistent Volume Claim como Protección de fuente de Snapshot +### Persistent Volume Claim como Snapshot Source Protection El propósito de esta protección es garantizar que los objetos de la API {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} From 76b2e13255cc25612d698b5ac3c39dfe738927a2 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 13:52:25 -0500 Subject: [PATCH 41/79] Update content/es/docs/concepts/storage/volume-snapshots.md great! Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index 2a29f70d4f..f7d625c2a5 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -67,7 +67,7 @@ Mientras se toma un Snapshot de un PersistentVolumeClaim, ese PersistentVolumeCl ### Borrar -La eliminación se activa al eliminar el objeto `VolumeSnapshot`, y se seguirá la `DeletionPolicy`. Sí `DeletionPolicy` es `Delete`, entonces el Snapshot de almacenamiento subyacente se eliminará junto con el objeto `VolumeSnapshotContent`. Sí `DeletionPolicy` es `Retain`, tanto la instantánea subyacente como `VolumeSnapshotContent` permanecen. +La eliminación se activa al eliminar el objeto `VolumeSnapshot`, y se seguirá la `DeletionPolicy`. Sí `DeletionPolicy` es `Delete`, entonces el Snapshot de almacenamiento subyacente se eliminará junto con el objeto `VolumeSnapshotContent`. Sí `DeletionPolicy` es `Retain`, tanto el Snapshot subyacente como el `VolumeSnapshotContent` permanecen. ## VolumeSnapshots From 4df48b736dc39536699f7059eae5af87b5135a2a Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 13:54:09 -0500 Subject: [PATCH 42/79] Update content/es/docs/concepts/storage/volume-snapshots.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index f7d625c2a5..84eeba7cd4 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -32,7 +32,7 @@ Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: * Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, no parte de la API principal. * La compatibilidad con `VolumeSnapshot` solo está disponible para controladores CSI. -* Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. +* Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. * También hay un servidor webhook de validación que proporciona una validación más estricta en los objetos Snapshot. Esto debe ser instalado por las distribuciones de Kubernetes junto con el controlador de Snapshots y los CRDs, no los controladores CSI. Debe instalarse en todos los clústeres de Kubernetes que tengan habilitada la función de Snapshot. * Los controladores CSI pueden haber implementado o no la funcionalidad de Snapshot de volumen. Los controladores CSI que han proporcionado soporte para Snapshot de volumen probablemente usarán csi-snapshotter. Consulte [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) para obtener más detalles. * Los CRDs y las instalaciones del controlador de Snapshot son responsabilidad de la distribución de Kubernetes. From 63a685522af10f73d21d9dca0f151c003277a7b8 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 13:54:40 -0500 Subject: [PATCH 43/79] Update content/es/docs/concepts/storage/volume-snapshots.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index 84eeba7cd4..af028f670a 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -28,7 +28,7 @@ Un `VolumeSnapshot` es una solicitud de Snapshot de un volumen por parte del usu Los Snapshots de volumen brindan a los usuarios de Kubernetes una forma estandarizada de copiar el contenido de un volumen en un momento determinado, sin crear uno completamente nuevo. Esta funcionalidad permite, por ejemplo, a los administradores de bases de datos realizar copias de seguridad de las bases de datos antes de realizar una edición o eliminar modificaciones. -Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: +Cuando utilicen esta función los usuarios deben tener en cuenta lo siguiente: * Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, no parte de la API principal. * La compatibilidad con `VolumeSnapshot` solo está disponible para controladores CSI. From 065922912f9f630b5a5843c30949d7872d8bc2c8 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 13:54:56 -0500 Subject: [PATCH 44/79] Update content/es/docs/concepts/storage/volume-snapshots.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index af028f670a..854be78202 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -30,7 +30,7 @@ Los Snapshots de volumen brindan a los usuarios de Kubernetes una forma estandar Cuando utilicen esta función los usuarios deben tener en cuenta lo siguiente: -* Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, no parte de la API principal. +* Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, y no forman parte de la API principal. * La compatibilidad con `VolumeSnapshot` solo está disponible para controladores CSI. * Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. * También hay un servidor webhook de validación que proporciona una validación más estricta en los objetos Snapshot. Esto debe ser instalado por las distribuciones de Kubernetes junto con el controlador de Snapshots y los CRDs, no los controladores CSI. Debe instalarse en todos los clústeres de Kubernetes que tengan habilitada la función de Snapshot. From 2a020aeaa3b0f7bd476050d6f20c43eb5a0b811f Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 13:55:22 -0500 Subject: [PATCH 45/79] Update content/es/docs/concepts/storage/volume-snapshots.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index 854be78202..d0a537360b 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -9,7 +9,7 @@ weight: 20 -En Kubernetes, un _VolumeSnapshot_ representa un Snapshot de un volumen en un sistema de almacenamiento. Este documento asume que ya está familiarizado con Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/). +En Kubernetes, un _VolumeSnapshot_ representa un Snapshot de un volumen en un sistema de almacenamiento. Este documento asume que está familiarizado con [volúmenes persistentes](/docs/concepts/storage/persistent-volumes/) de Kubernetes. From 1ba143bafa50b70d4f657f7018ce0dd10bdb364f Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Wed, 8 Sep 2021 13:55:31 -0500 Subject: [PATCH 46/79] Update content/es/docs/concepts/storage/volume-snapshots.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-snapshots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index d0a537360b..9c60cfa5ad 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -2,7 +2,7 @@ reviewers: - edithturn - raelga -title: Volume Snapshots +title: Snapshots de Volúmenes content_type: concept weight: 20 --- From 6aa8b805b0184df88c4fbf5ace422231d1d08075 Mon Sep 17 00:00:00 2001 From: Edith Date: Wed, 8 Sep 2021 14:18:49 -0500 Subject: [PATCH 47/79] grammar error --- content/es/docs/concepts/storage/volume-snapshots.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md index 9c60cfa5ad..dcb0417a6f 100644 --- a/content/es/docs/concepts/storage/volume-snapshots.md +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -2,6 +2,7 @@ reviewers: - edithturn - raelga +- electrocucaracha title: Snapshots de Volúmenes content_type: concept weight: 20 @@ -32,7 +33,7 @@ Cuando utilicen esta función los usuarios deben tener en cuenta lo siguiente: * Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, y no forman parte de la API principal. * La compatibilidad con `VolumeSnapshot` solo está disponible para controladores CSI. -* Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. +* Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. * También hay un servidor webhook de validación que proporciona una validación más estricta en los objetos Snapshot. Esto debe ser instalado por las distribuciones de Kubernetes junto con el controlador de Snapshots y los CRDs, no los controladores CSI. Debe instalarse en todos los clústeres de Kubernetes que tengan habilitada la función de Snapshot. * Los controladores CSI pueden haber implementado o no la funcionalidad de Snapshot de volumen. Los controladores CSI que han proporcionado soporte para Snapshot de volumen probablemente usarán csi-snapshotter. Consulte [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) para obtener más detalles. * Los CRDs y las instalaciones del controlador de Snapshot son responsabilidad de la distribución de Kubernetes. @@ -43,10 +44,10 @@ Cuando utilicen esta función los usuarios deben tener en cuenta lo siguiente: ### Snapshot del volumen de aprovisionamiento -Hay dos formas de aprovisionar las instantáneas: aprovisionadas previamente o aprovisionadas dinámicamente. +Hay dos formas de aprovisionar los Snapshots: aprovisionadas previamente o aprovisionadas dinámicamente. #### Pre-aprovisionado {#static} -Un administrador de clúster crea una serie de `VolumeSnapshotContents`. Llevan los detalles de la instantánea del volumen real en el sistema de almacenamiento que está disponible para que lo utilicen los usuarios del clúster. Existen en la API de Kubernetes y están disponibles para su consumo. +Un administrador de clúster crea una serie de `VolumeSnapshotContents`. Llevan los detalles del Snapshot del volumen real en el sistema de almacenamiento que está disponible para que lo utilicen los usuarios del clúster. Existen en la API de Kubernetes y están disponibles para su consumo. #### Dinámica En lugar de utilizar un Snapshot preexistente, puede solicitar que se tome una Snapshot dinámicamente de un PersistentVolumeClaim. El [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) especifica los parámetros específicos del proveedor de almacenamiento para usar al tomar una Snapshot. @@ -84,7 +85,7 @@ spec: persistentVolumeClaimName: pvc-test ``` -`persistentVolumeClaimName` es el nombre de la fuente de datos PersistentVolumeClaim para el Snapshot. Este campo es obligatorio para aprovisionar dinámicamente un Snapshot. +`persistentVolumeClaimName` es el nombre de la fuente de datos PersistentVolumeClaim para el Snapshot. Este campo es obligatorio para aprovisionar dinámicamente un Snapshot. Un Snapshot de volumen puede solicitar una clase particular especificando el nombre de un [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) utilizando el atributo `volumeSnapshotClassName`. Si no se establece nada, se usa la clase predeterminada si está disponible. From 809ff37d3b34a0c48004f02bf2240fd7fec2f35c Mon Sep 17 00:00:00 2001 From: Chris Henzie Date: Fri, 16 Jul 2021 12:08:09 -0700 Subject: [PATCH 48/79] ReadWriteOncePod access mode alpha feature blog --- ...3-read-write-once-pod-access-mode-alpha.md | 287 ++++++++++++++++++ 1 file changed, 287 insertions(+) create mode 100644 content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md diff --git a/content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md b/content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md new file mode 100644 index 0000000000..c04df56284 --- /dev/null +++ b/content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md @@ -0,0 +1,287 @@ +--- +layout: blog +title: "Introducing Single Pod Access Mode for PersistentVolumes" +date: 2021-09-13 +slug: read-write-once-pod-access-mode-alpha +--- + +**Author:** Chris Henzie (Google) + +Last month's release of Kubernetes v1.22 introduced a new ReadWriteOncePod access mode for [PersistentVolumes](/docs/concepts/storage/persistent-volumes/#persistent-volumes) and [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). +With this alpha feature, Kubernetes allows you to restrict volume access to a single pod in the cluster. + +## What are access modes and why are they important? + +When using storage, there are different ways to model how that storage is consumed. + +For example, a storage system like a network file share can have many users all reading and writing data simultaneously. +In other cases maybe everyone is allowed to read data but not write it. +For highly sensitive data, maybe only one user is allowed to read and write data but nobody else. + +In the world of Kubernetes, [access modes](/docs/concepts/storage/persistent-volumes/#access-modes) are the way you can define how durable storage is consumed. +These access modes are a part of the spec for PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs). + +```yaml +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: shared-cache +spec: + accessModes: + - ReadWriteMany # Allow many pods to access shared-cache simultaneously. + resources: + requests: + storage: 1Gi +``` + +Before v1.22, Kubernetes offered three access modes for PVs and PVCs: + +- ReadWriteOnce – the volume can be mounted as read-write by a single node +- ReadOnlyMany – the volume can be mounted read-only by many nodes +- ReadWriteMany – the volume can be mounted as read-write by many nodes + +These access modes are enforced by Kubernetes components like the `kube-controller-manager` and `kubelet` to ensure only certain pods are allowed to access a given PersistentVolume. + +## What is this new access mode and how does it work? + +Kubernetes v1.22 introduced a fourth access mode for PVs and PVCs, that you can use for CSI volumes: + +- ReadWriteOncePod – the volume can be mounted as read-write by a single pod + +If you create a pod with a PVC that uses the ReadWriteOncePod access mode, Kubernetes ensures that pod is the only pod across your whole cluster that can read that PVC or write to it. + +If you create another pod that references the same PVC with this access mode, the pod will fail to start because the PVC is already in use by another pod. +For example: + +``` +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Warning FailedScheduling 1s default-scheduler 0/1 nodes are available: 1 node has pod using PersistentVolumeClaim with the same name and ReadWriteOncePod access mode. +``` + +### How is this different than the ReadWriteOnce access mode? + +The ReadWriteOnce access mode restricts volume access to a single *node*, which means it is possible for multiple pods on the same node to read from and write to the same volume. +This could potentially be a major problem for some applications, especially if they require at most one writer for data safety guarantees. + +With ReadWriteOncePod these issues go away. +Set the access mode on your PVC, and Kubernetes guarantees that only a single pod has access. + +## How do I use it? + +The ReadWriteOncePod access mode is in alpha for Kubernetes v1.22 and is only supported for CSI volumes. +As a first step you need to enable the ReadWriteOncePod [feature gate](/docs/reference/command-line-tools-reference/feature-gates) for `kube-apiserver`, `kube-scheduler`, and `kubelet`. +You can enable the feature by setting command line arguments: + +``` +--feature-gates="...,ReadWriteOncePod=true" +``` + +You also need to update the following CSI sidecars to these versions or greater: + +- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) +- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) +- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0) + +### Creating a PersistentVolumeClaim + +In order to use the ReadWriteOncePod access mode for your PVs and PVCs, you will need to create a new PVC with the access mode: + +```yaml +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: single-writer-only +spec: + accessModes: + - ReadWriteOncePod # Allow only a single pod to access single-writer-only. + resources: + requests: + storage: 1Gi +``` + +If your storage plugin supports [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/), new PersistentVolumes will be created with the ReadWriteOncePod access mode applied. + +#### Migrating existing PersistentVolumes + +If you have existing PersistentVolumes, they can be migrated to use ReadWriteOncePod. + +In this example, we already have a "cat-pictures-pvc" PersistentVolumeClaim that is bound to a "cat-pictures-pv" PersistentVolume, and a "cat-pictures-writer" Deployment that uses this PersistentVolumeClaim. + +As a first step, you need to edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set it to `Retain`. +This ensures your PersistentVolume will not be deleted when we delete the corresponding PersistentVolumeClaim: + +```shell +kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' +``` + +Next you need to stop any workloads that are using the PersistentVolumeClaim bound to the PersistentVolume you want to migrate, and then delete the PersistentVolumeClaim. + +Once that is done, you need to clear your PersistentVolume's `spec.claimRef.uid` to ensure PersistentVolumeClaims can bind to it upon recreation: + +```shell +kubectl scale --replicas=0 deployment cat-pictures-writer +kubectl delete pvc cat-pictures-pvc +kubectl patch pv cat-pictures-pv -p '{"spec":{"claimRef":{"uid":""}}}' +``` + +After that you need to replace the PersistentVolume's access modes with ReadWriteOncePod: + +```shell +kubectl patch pv cat-pictures-pv -p '{"spec":{"accessModes":["ReadWriteOncePod"]}}' +``` + +{{< note >}} +The ReadWriteOncePod access mode cannot be combined with other access modes. +Make sure ReadWriteOncePod is the only access mode on the PersistentVolume when updating, otherwise the request will fail. +{{< /note >}} + +Next you need to modify your PersistentVolumeClaim to set ReadWriteOncePod as the only access mode. +You should also set your PersistentVolumeClaim's `spec.volumeName` to the name of your PersistentVolume. + +Once this is done, you can recreate your PersistentVolumeClaim and start up your workloads: + +```shell +# IMPORTANT: Make sure to edit your PVC in cat-pictures-pvc.yaml before applying. You need to: +# - Set ReadWriteOncePod as the only access mode +# - Set spec.volumeName to "cat-pictures-pv" + +kubectl apply -f cat-pictures-pvc.yaml +kubectl apply -f cat-pictures-writer-deployment.yaml +``` + +Lastly you may edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set to it back to `Delete` if you previously changed it. + +```shell +kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}' +``` + +You can read [Configure a Pod to Use a PersistentVolume for Storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) for more details on working with PersistentVolumes and PersistentVolumeClaims. + +## What volume plugins support this? + +The only volume plugins that support this are CSI drivers. +SIG Storage does not plan to support this for in-tree plugins because they are being deprecated as part of [CSI migration](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#what-is-the-timeline-status). +Support may be considered for beta for users that prefer to use the legacy in-tree volume APIs with CSI migration enabled. + +## As a storage vendor, how do I add support for this access mode to my CSI driver? + +The ReadWriteOncePod access mode will work out of the box without any required updates to CSI drivers, but [does require updates to CSI sidecars](#update-your-csi-sidecars). +With that being said, if you would like to stay up to date with the latest changes to the CSI specification (v1.5.0+), read on. + +Two new access modes were introduced to the CSI specification in order to disambiguate the legacy [`SINGLE_NODE_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L418-L420) access mode. +They are [`SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L437-L447). +In order to communicate to sidecars (like the [external-provisioner](https://github.com/kubernetes-csi/external-provisioner)) that your driver understands and accepts these two new CSI access modes, your driver will also need to advertise the `SINGLE_NODE_MULTI_WRITER` capability for the [controller service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1073-L1081) and [node service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1515-L1524). + +If you'd like to read up on the motivation for these access modes and capability bits, you can also read the [CSI Specification Changes, Volume Capabilities](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md#csi-specification-changes-volume-capabilities) section of KEP-2485 (ReadWriteOncePod PersistentVolume Access Mode). + +### Update your CSI driver to use the new interface + +As a first step you will need to update your driver's `container-storage-interface` dependency to v1.5.0+, which contains support for these new access modes and capabilities. + +### Accept new CSI access modes + +If your CSI driver contains logic for validating CSI access modes for requests , it may need updating. +If it currently accepts `SINGLE_NODE_WRITER`, it should be updated to also accept `SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`. + +Using the [GCP PD CSI driver validation logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/utils.go#L116-L130) as an example, here is how it can be extended: + +```diff +diff --git a/pkg/gce-pd-csi-driver/utils.go b/pkg/gce-pd-csi-driver/utils.go +index 281242c..b6c5229 100644 +--- a/pkg/gce-pd-csi-driver/utils.go ++++ b/pkg/gce-pd-csi-driver/utils.go +@@ -123,6 +123,8 @@ func validateAccessMode(am *csi.VolumeCapability_AccessMode) error { + case csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY: + case csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY: + case csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER: ++ case csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER: ++ case csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER: + default: + return fmt.Errorf("%v access mode is not supported for for PD", am.GetMode()) + } +``` + +### Advertise new CSI controller and node service capabilities + +Your CSI driver will also need to return the new `SINGLE_NODE_MULTI_WRITER` capability as part of the `ControllerGetCapabilities` and `NodeGetCapabilities` RPCs. + +Using the [GCP PD CSI driver capability advertisement logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/gce-pd-driver.go#L54-L77) as an example, here is how it can be extended: + +```diff +diff --git a/pkg/gce-pd-csi-driver/gce-pd-driver.go b/pkg/gce-pd-csi-driver/gce-pd-driver.go +index 45903f3..0d7ea26 100644 +--- a/pkg/gce-pd-csi-driver/gce-pd-driver.go ++++ b/pkg/gce-pd-csi-driver/gce-pd-driver.go +@@ -56,6 +56,8 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu + csi.VolumeCapability_AccessMode_SINGLE_NODE_WRITER, + csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY, + csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER, ++ csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER, ++ csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER, + } + gceDriver.AddVolumeCapabilityAccessModes(vcam) + csc := []csi.ControllerServiceCapability_RPC_Type{ +@@ -67,12 +69,14 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu + csi.ControllerServiceCapability_RPC_EXPAND_VOLUME, + csi.ControllerServiceCapability_RPC_LIST_VOLUMES, + csi.ControllerServiceCapability_RPC_LIST_VOLUMES_PUBLISHED_NODES, ++ csi.ControllerServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER, + } + gceDriver.AddControllerServiceCapabilities(csc) + ns := []csi.NodeServiceCapability_RPC_Type{ + csi.NodeServiceCapability_RPC_STAGE_UNSTAGE_VOLUME, + csi.NodeServiceCapability_RPC_EXPAND_VOLUME, + csi.NodeServiceCapability_RPC_GET_VOLUME_STATS, ++ csi.NodeServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER, + } + gceDriver.AddNodeServiceCapabilities(ns) +``` + +### Implement `NodePublishVolume` behavior + +The CSI spec outlines expected behavior for the `NodePublishVolume` RPC when called more than once for the same volume but with different arguments (like the target path). +Please refer to [the second table in the NodePublishVolume section of the CSI spec](https://github.com/container-storage-interface/spec/blob/v1.5.0/spec.md#nodepublishvolume) for more details on expected behavior when implementing in your driver. + +### Update your CSI sidecars + +When deploying your CSI drivers, you must update the following CSI sidecars to versions that depend on CSI spec v1.5.0+ and the Kubernetes v1.22 API. +The minimum required versions are: + +- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) +- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) +- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0) + +## What’s next? + +As part of the beta graduation for this feature, SIG Storage plans to update the Kubenetes scheduler to support pod preemption in relation to ReadWriteOncePod storage. +This means if two pods request a PersistentVolumeClaim with ReadWriteOncePod, the pod with highest priority will gain access to the PersistentVolumeClaim and any pod with lower priority will be preempted from the node and be unable to access the PersistentVolumeClaim. + +## How can I learn more? + +Please see [KEP-2485](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md) for more details on the ReadWriteOncePod access mode and motivations for CSI spec changes. + +## How do I get involved? + +The [Kubernetes #csi Slack channel](https://kubernetes.slack.com/messages/csi) and any of the [standard SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and the CSI teams. + +Special thanks to the following people for their insightful reviews and design considerations: + +* Abdullah Gharaibeh (ahg-g) +* Aldo Culquicondor (alculquicondor) +* Ben Swartzlander (bswartz) +* Deep Debroy (ddebroy) +* Hemant Kumar (gnufied) +* Humble Devassy Chirammal (humblec) +* James DeFelice (jdef) +* Jan Šafránek (jsafrane) +* Jing Xu (jingxu97) +* Jordan Liggitt (liggitt) +* Michelle Au (msau42) +* Saad Ali (saad-ali) +* Tim Hockin (thockin) +* Xing Yang (xing-yang) + +If you’re interested in getting involved with the design and development of CSI or any part of the Kubernetes storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). +We’re rapidly growing and always welcome new contributors. From 1ba9380f7320d0eb7a65823a42d7c728a8ceddf5 Mon Sep 17 00:00:00 2001 From: likakuli <1154584512@qq.com> Date: Thu, 9 Sep 2021 18:36:21 +0800 Subject: [PATCH 49/79] Update nodelocaldns.md use ",__PILLAR__DNS__SERVER__" as old pattern instead of "__PILLAR__DNS__SERVER__" when use ipvs mode --- content/zh/docs/tasks/administer-cluster/nodelocaldns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/administer-cluster/nodelocaldns.md b/content/zh/docs/tasks/administer-cluster/nodelocaldns.md index 64cd1a02c6..46d92d0c8f 100644 --- a/content/zh/docs/tasks/administer-cluster/nodelocaldns.md +++ b/content/zh/docs/tasks/administer-cluster/nodelocaldns.md @@ -174,7 +174,7 @@ If you are using the sample manifest from the previous point, this will require * If kube-proxy is running in IPVS mode: ``` bash - sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml + sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml ``` In this mode, node-local-dns pods listen only on ``. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address. `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods. From 69be6060ca6e39bfb6945a9341fc6458c0869c72 Mon Sep 17 00:00:00 2001 From: Arsh Sharma <56963264+RinkiyaKeDad@users.noreply.github.com> Date: Thu, 9 Sep 2021 19:18:10 +0530 Subject: [PATCH 50/79] explaining the interactions of topology spread constraints and node affinity/selector (#29632) * explaining the interactions of topology spread constraints and node affinity/selector Signed-off-by: RinkiyaKeDad * udpates from code review Signed-off-by: RinkiyaKeDad * more updated from code reviews Signed-off-by: RinkiyaKeDad --- .../pods/pod-topology-spread-constraints.md | 30 +++++++++++-------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 3639873382..719fcee457 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -230,20 +230,9 @@ If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" sta To overcome this situation, you can either increase the `maxSkew` or modify one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`. -### Conventions +### Interaction With Node Affinity and Node Selectors -There are some implicit conventions worth noting here: - -- Only the Pods holding the same namespace as the incoming Pod can be matching candidates. - -- Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that: - - 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA". - 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". - -- Be aware of what will happen if the incomingPod's `topologySpreadConstraints[*].labelSelector` doesn't match its own labels. In the above example, if we remove the incoming Pod's labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it's still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload's `topologySpreadConstraints[*].labelSelector` to match its own labels. - -- If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed. +The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined. Suppose you have a 5-node cluster ranging from zoneA to zoneC: @@ -283,6 +272,21 @@ There are some implicit conventions worth noting here: {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} +The scheduler doesn't have prior knowledge of all the zones or other topology domains that a cluster has. They are determined from the existing nodes in the cluster. This could lead to a problem in autoscaled clusters, when a node pool (or node group) is scaled to zero nodes and the user is expecting them to scale up, because, in this case, those topology domains won't be considered until there is at least one node in them. + +### Other Noticeable Semantics + +There are some implicit conventions worth noting here: + +- Only the Pods holding the same namespace as the incoming Pod can be matching candidates. + +- The scheduler will bypass the nodes without `topologySpreadConstraints[*].topologyKey` present. This implies that: + + 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA". + 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". + +- Be aware of what will happen if the incomingPod's `topologySpreadConstraints[*].labelSelector` doesn't match its own labels. In the above example, if we remove the incoming Pod's labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it's still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload's `topologySpreadConstraints[*].labelSelector` to match its own labels. + ### Cluster-level default constraints It is possible to set default topology spread constraints for a cluster. Default From a0e52ff56fc9880c5c0aa7e7abe2a50791490b9a Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Thu, 9 Sep 2021 20:17:21 +0530 Subject: [PATCH 51/79] Changed ha-control-plane.svg location --- .../images/docs => content/en/docs/images}/ha-control-plane.svg | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {static/images/docs => content/en/docs/images}/ha-control-plane.svg (100%) diff --git a/static/images/docs/ha-control-plane.svg b/content/en/docs/images/ha-control-plane.svg similarity index 100% rename from static/images/docs/ha-control-plane.svg rename to content/en/docs/images/ha-control-plane.svg From 2e361073b126f9aad7cac4fe8b54cc546685b759 Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Thu, 9 Sep 2021 20:20:49 +0530 Subject: [PATCH 52/79] Update highly-available-control-plane.md --- .../tasks/administer-cluster/highly-available-control-plane.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md index 543abbfe44..ede6492c9a 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -133,7 +133,7 @@ the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-mi ## Implementation notes -![ha-control-plane](/images/docs/ha-control-plane.svg) +![ha-control-plane](content/en/docs/images/ha-control-plane.svg) ### Overview The figure above illustrates three control plane nodes and their components in a highly available cluster. The control plane node’s components employ the following methods: From 82c3bf13a3522d649026205230e33091cacbea84 Mon Sep 17 00:00:00 2001 From: Arhell Date: Fri, 10 Sep 2021 00:39:28 +0300 Subject: [PATCH 53/79] [pt-br] Fix secret name to be consistent with examples --- .../tasks/configmap-secret/managing-secret-using-kubectl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl.md index 7e6ca6dc7c..575bc13253 100644 --- a/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl.md +++ b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -64,7 +64,7 @@ Na maioria dos shells, a forma mais fácil de escapar as senhas é usar aspas si Por exemplo, se sua senha atual é `S!B\*d$zDsb=`, você precisa executar o comando dessa forma: ```shell -kubectl create secret generic dev-db-secret \ +kubectl create secret generic db-user-pass \ --from-literal=username=devuser \ --from-literal=password='S!B\*d$zDsb=' ``` From 84c2324c2b977873955b1afc3c697763059b51aa Mon Sep 17 00:00:00 2001 From: deepsan Date: Tue, 7 Sep 2021 14:34:49 -0700 Subject: [PATCH 54/79] Fix service-catalog usage of apiserver aggregation The Service Catalog architecture changed from using api aggregation to CRDs, but the docs still refer to the older architecture using api aggregation. Couple of changes here: 1. Change the sentence on how Service Catalog is implemented 2. Replace the example for usage of api aggregation from service-catalog to metrics-server. There are multiple implementations that can be linked to(keda, prometheus, datadog,...), but keeping the documentation neutral by pointing to kubernetes-sigs/metrics-server References: - Service Catalog [v0.3.0 release notes](https://github.com/kubernetes-sigs/service-catalog/releases/tag/v0.3.0): > In release 0.3.0, we've focused on replacing the Aggregated API Server with the CustomResourceDefinitions (CRDs) and the Admission Webhook solution. - Project [README](https://github.com/kubernetes-sigs/service-catalog/pull/2691/files) > Service Catalog recently switched to a new CRDs-based architecture. The old API Server-based implementation is available on the v0.2 branch. We support this implementation by providing bug fixes until July 2020. --- .../extend-kubernetes/api-extension/apiserver-aggregation.md | 2 +- content/en/docs/concepts/extend-kubernetes/service-catalog.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index f9ab8647e3..f6bb478d73 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -11,7 +11,7 @@ weight: 20 The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. -The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself. +The additional APIs can either be ready-made solutions such as a [metrics server](https://github.com/kubernetes-sigs/metrics-server), or APIs that you develop yourself. The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object. diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md index af0271d9ab..26517de9c6 100644 --- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/en/docs/concepts/extend-kubernetes/service-catalog.md @@ -32,7 +32,7 @@ The application can access the message queue as a service. Service Catalog uses the [Open service broker API](https://github.com/openservicebrokerapi/servicebroker) to communicate with service brokers, acting as an intermediary for the Kubernetes API Server to negotiate the initial provisioning and retrieve the credentials necessary for the application to use a managed service. -It is implemented as an extension API server and a controller, using etcd for storage. It also uses the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) available in Kubernetes 1.7+ to present its API. +It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) architecture.
From c9568cbaafd160ad3a7a5ca01cc0700761a27ab3 Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Fri, 10 Sep 2021 09:44:25 +0530 Subject: [PATCH 55/79] Update highly-available-control-plane.md --- .../tasks/administer-cluster/highly-available-control-plane.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md index ede6492c9a..30c3ec3acd 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -133,7 +133,7 @@ the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-mi ## Implementation notes -![ha-control-plane](content/en/docs/images/ha-control-plane.svg) +![ha-control-plane](/docs/images/ha-control-plane.svg) ### Overview The figure above illustrates three control plane nodes and their components in a highly available cluster. The control plane node’s components employ the following methods: From 732e88bd7e96749eba8145c77d1fa28539a0fe97 Mon Sep 17 00:00:00 2001 From: wangyamei Date: Fri, 10 Sep 2021 15:52:46 +0800 Subject: [PATCH 56/79] zh: update scheduling-hugepages.md --- .../zh/docs/tasks/manage-hugepages/scheduling-hugepages.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md index dc803ec583..0cdc82eda4 100644 --- a/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -154,10 +154,6 @@ term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=false`) `proc/sys/vm/hugetlb_shm_group` 匹配的补充组下。 - 通过 ResourceQuota 资源，可以使用 `hugepages-` 标记控制每个命名空间下的巨页使用量， 类似于使用 `cpu` 或 `memory` 来控制其他计算资源。 -- 多种尺寸的巨页的支持需要特性门控配置。它可以通过 `HugePageStorageMediumSize` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)在 {{< -glossary_tooltip text="kubelet" term_id="kubelet" >}} 和 {{< -glossary_tooltip text="kube-apiserver" -term_id="kube-apiserver" >}} 中开启（`--feature-gates=HugePageStorageMediumSize=false`）。 From 787e703fa05654a58e71e3ca3645803221eb455f Mon Sep 17 00:00:00 2001 From: Philippe Martin Date: Thu, 8 Jul 2021 18:11:32 +0200 Subject: [PATCH 57/79] Add `api-reference` shortcode --- layouts/shortcodes/api-reference.html | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 layouts/shortcodes/api-reference.html diff --git a/layouts/shortcodes/api-reference.html b/layouts/shortcodes/api-reference.html new file mode 100644 index 0000000000..6fdceef838 --- /dev/null +++ b/layouts/shortcodes/api-reference.html @@ -0,0 +1,7 @@ +{{ $base := "docs/reference/kubernetes-api" }} +{{ $pageArg := .Get "page" }} +{{ $anchorArg := .Get "anchor" }} +{{ $textArg := .Get "text" }} +{{ $page := site.GetPage "page" (printf "%s/%s" $base $pageArg) }} +{{ $metadata := $page.Params.api_metadata }} +{{if $textArg}}{{ $textArg }}{{else if $anchorArg}}{{ $anchorArg }}{{else}}{{ $metadata.kind }}{{end}} \ No newline at end of file From 216b34a3d10ad82c1b76eb75db29aa9399da5322 Mon Sep 17 00:00:00 2001 From: Philippe Martin Date: Thu, 8 Jul 2021 18:11:57 +0200 Subject: [PATCH 58/79] Update script to check api-reference links --- scripts/linkchecker.py | 64 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/scripts/linkchecker.py b/scripts/linkchecker.py index 6a5ea7d089..5bc63e1d7f 100755 --- a/scripts/linkchecker.py +++ b/scripts/linkchecker.py @@ -35,6 +35,8 @@ # + /docs/bar : is a redirect entry, or # + /docs/bar : is something we don't understand # +# + {{ < api-reference page="" anchor="" ... > }} +# + {{ < api-reference page="" > }} import argparse import glob @@ -72,7 +74,8 @@ ARGS = None RESULT = {} # Cached redirect entries REDIRECTS = {} - +# Cached anchors in target pages +ANCHORS = {} def new_record(level, message, target): """Create new checking record. @@ -330,6 +333,44 @@ def check_target(page, anchor, target): msg = "Link may be wrong for the anchor [%s]" % anchor return new_record("WARNING", msg, target) +def check_anchor(target_page, anchor): + """Check if an anchor is defined in the target page + + :param target_page: The target page to check + :param anchor: Anchor string to find in the target page + """ + if target_page not in ANCHORS: + try: + with open(target_page, "r") as f: + data = f.readlines() + except Exception as ex: + print("[Error] failed in reading markdown file: " + str(ex)) + return + content = "\n".join(strip_comments(data)) + anchor_pattern1 = r" Date: Sat, 11 Sep 2021 11:09:10 +0530 Subject: [PATCH 59/79] Update OWNERS_ALIASES Update OWNERS_ALIASES Update OWNERS_ALIASES --- OWNERS_ALIASES | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 462728069d..ce45f0e787 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -72,12 +72,12 @@ aliases: - anthonydahanne - feloy sig-docs-hi-owners: # Admins for Hindi content - - avidLearnerInProgress - - daminisatya + - anubha-v-ardhan + - divya-mohan0209 - mittalyashu sig-docs-hi-reviews: # PR reviews for Hindi content - - avidLearnerInProgress - - daminisatya + - anubha-v-ardhan + - divya-mohan0209 - mittalyashu sig-docs-id-owners: # Admins for Indonesian content - ariscahyadi From 68549e4d5db23d48c08b8d59038b937fcd0e041a Mon Sep 17 00:00:00 2001 From: Arhell Date: Sun, 12 Sep 2021 03:33:32 +0300 Subject: [PATCH 60/79] [id] Improvement: Runtime Class --- content/id/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md index 539fbb7038..49b1c6f1fa 100644 --- a/content/id/docs/concepts/containers/runtime-class.md +++ b/content/id/docs/concepts/containers/runtime-class.md @@ -111,7 +111,7 @@ _Handler runtime_ diatur melalui konfigurasi containerd pada `/etc/containerd/co _Handler_ yang valid dapat dikonfigurasi pada bagian _runtime_: ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` Lihat dokumentasi konfigurasi containerd untuk lebih detail: From a225c841f0fe134c9e3f86c99be70dcaa9844903 Mon Sep 17 00:00:00 2001 From: Victuos <1408582+victuos@users.noreply.github.com> Date: Sun, 12 Sep 2021 19:24:09 +0200 Subject: [PATCH 61/79] Adjust broken link in service.md --- content/en/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index dff13690ba..ceb2c955c2 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -428,7 +428,7 @@ variables and DNS. When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. It supports both [Docker links -compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/envvars/envvars.go#L72)) +compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. From a99b008fc55849ea4f19dbf72254c206789feb83 Mon Sep 17 00:00:00 2001 From: Arhell Date: Mon, 13 Sep 2021 00:29:23 +0300 Subject: [PATCH 62/79] [es] Improvement: Runtime Class --- content/es/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/containers/runtime-class.md b/content/es/docs/concepts/containers/runtime-class.md index 8c53cde87d..fa27366b35 100644 --- a/content/es/docs/concepts/containers/runtime-class.md +++ b/content/es/docs/concepts/containers/runtime-class.md @@ -134,7 +134,7 @@ de containerd en `/etc/containerd/config.toml`. Los `handlers` válidos se configuran en la sección de motores de ejecución: ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` Véase la configuración de containerd para más detalles: From e6f83df546658c710ff1243541e122d309542adc Mon Sep 17 00:00:00 2001 From: ixodie Date: Mon, 13 Sep 2021 12:40:56 -0400 Subject: [PATCH 63/79] Removed Big Switch Fabric None of the links for this entry actually work. --- .../docs/concepts/cluster-administration/networking.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index c517b13175..3a9873242f 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -116,15 +116,6 @@ Additionally, the CNI can be run alongside [Calico for network policy enforcemen Azure CNI is available natively in the [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni). - -### Big Cloud Fabric from Big Switch Networks - -[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premises environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring. - -With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. - -BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). - ### Calico [Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement. From f1751b1e24e602142ae0099ad4acc90558d2a3cc Mon Sep 17 00:00:00 2001 From: ixodie Date: Mon, 13 Sep 2021 16:34:52 -0400 Subject: [PATCH 64/79] Removed Apstra AOS Apstra AOS (now owned by Juniper) has no direct integration with Kubernetes. No CNI, no operator, no CRDs, nothing. Kubernetes is not natively supported in the product, there is no mention of any k8s construct in the product. This entry should be removed because it does not follow https://github.com/kubernetes/website/issues/20232 --- .../concepts/cluster-administration/networking.md | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index c517b13175..958f2d5ed4 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -91,18 +91,6 @@ imply any preferential status. Project [Antrea](https://github.com/vmware-tanzu/antrea) is an opensource Kubernetes networking solution intended to be Kubernetes native. It leverages Open vSwitch as the networking data plane. Open vSwitch is a high-performance programmable virtual switch that supports both Linux and Windows. Open vSwitch enables Antrea to implement Kubernetes Network Policies in a high-performance and efficient manner. Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to implement an extensive set of networking and security features and services on top of Open vSwitch. -### AOS from Apstra - -[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. - -The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems. These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs). AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment. - -AOS has a rich set of REST API endpoints that enable Kubernetes to quickly change the network policy based on application requirements. Further enhancements will integrate the AOS Graph model used for the network design with the workload provisioning, enabling an end to end management system for both private and public clouds. - -AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux. - -Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/ - ### AWS VPC CNI for Kubernetes The [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) offers integrated AWS Virtual Private Cloud (VPC) networking for Kubernetes clusters. This CNI plugin offers high throughput and availability, low latency, and minimal network jitter. Additionally, users can apply existing AWS VPC networking and security best practices for building Kubernetes clusters. This includes the ability to use VPC flow logs, VPC routing policies, and security groups for network traffic isolation. From a2f89a24923de1def6ccdf9f924c2ca12f7f5515 Mon Sep 17 00:00:00 2001 From: Arhell Date: Tue, 14 Sep 2021 01:03:29 +0300 Subject: [PATCH 65/79] [pt-br] Improvement: Runtime Class --- content/pt-br/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/containers/runtime-class.md b/content/pt-br/docs/concepts/containers/runtime-class.md index 70e42a78f0..8f6e33aeee 100644 --- a/content/pt-br/docs/concepts/containers/runtime-class.md +++ b/content/pt-br/docs/concepts/containers/runtime-class.md @@ -112,7 +112,7 @@ Agentes de execução são configurados através da configuração do containerd `/etc/containerd/config.toml`. Agentes válidos são configurados sob a seção de `runtimes`: ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` Veja a documentação de configuração do containerd para maiores detalhes: From c1c2f086622bf80d65f5095fc2482ff88a42de59 Mon Sep 17 00:00:00 2001 From: Metal <2466052+tedhexaflow@users.noreply.github.com> Date: Tue, 14 Sep 2021 09:05:42 +0700 Subject: [PATCH 66/79] Fix spelling --- content/en/docs/concepts/workloads/controllers/statefulset.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 289722fb07..3f89da5989 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -173,7 +173,7 @@ Cluster Domain will be set to `cluster.local` unless ### Stable Storage -For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one PersistentVolumeClaim. In the nginx example above, each Podreceives a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass +For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one PersistentVolumeClaim. In the nginx example above, each Pod receives a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass is specified, then the default StorageClass will be used. When a Pod is (re)scheduled onto a node, its `volumeMounts` mount the PersistentVolumes associated with its PersistentVolume Claims. Note that, the PersistentVolumes associated with the @@ -301,4 +301,3 @@ Please note that this field only works if you enable the `StatefulSetMinReadySec * Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/). * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/). * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/). - From bc0a2487f8684728ab5a2639ea8d0e743fe2393b Mon Sep 17 00:00:00 2001 From: Akihiro Suda Date: Mon, 13 Sep 2021 15:01:26 +0900 Subject: [PATCH 67/79] kubelet-in-userns.md: update for minikube minikube now supports Rootless Docker driver. minikube internally sets the KubeletInUserNamespace feature gate automatically for supporting Rootless Docker driver. https://minikube.sigs.k8s.io/docs/drivers/docker/ Signed-off-by: Akihiro Suda --- .../administer-cluster/kubelet-in-userns.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md b/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md index 7b90c5cfd1..bed842b6a4 100644 --- a/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md +++ b/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md @@ -34,14 +34,21 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo ## Running Kubernetes inside Rootless Docker/Podman -[kind](https://kind.sigs.k8s.io/) supports running Kubernetes inside a Rootless Docker or Rootless Podman. +### kind + +[kind](https://kind.sigs.k8s.io/) supports running Kubernetes inside Rootless Docker or Rootless Podman. See [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootless/). - +### minikube + +[minikube](https://minikube.sigs.k8s.io/) also supports running Kubernetes inside Rootless Docker. + +See the page about the [docker](https://minikube.sigs.k8s.io/docs/drivers/docker/) driver in the Minikube documentation. + +Rootless Podman is not supported. + + ## Running Rootless Kubernetes directly on a host From 2a6272ddf83f22c04f2a8180531ae00c3e24e85c Mon Sep 17 00:00:00 2001 From: Shubham Kuchhal Date: Tue, 14 Sep 2021 18:18:31 +0530 Subject: [PATCH 68/79] Fixed the link for Exemptions. --- .../enforce-standards-admission-controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md b/content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md index c3dcb0e995..ef8206b1b6 100644 --- a/content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md +++ b/content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md @@ -9,7 +9,7 @@ min-kubernetes-server-version: v1.22 As of v1.22, Kubernetes provides a built-in [admission controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards). -You can configure this admission controller to set cluster-wide defaults and [exemptions](#exemptions). +You can configure this admission controller to set cluster-wide defaults and [exemptions](/docs/concepts/security/pod-security-admission/#exemptions). ## {{% heading "prerequisites" %}} From 7d0e235a995054503082829d2e66a3699426b2c3 Mon Sep 17 00:00:00 2001 From: Philippe Martin Date: Tue, 14 Sep 2021 15:51:58 +0200 Subject: [PATCH 69/79] Add shortcode doc --- .../contribute/style/hugo-shortcodes/index.md | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index 2a836ffb91..fa3932f17d 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -83,6 +83,33 @@ You can also include a full definition: which renders as: {{< glossary_definition term_id="cluster" length="all" >}} +## Links to API Reference + +You can link to a page of the Kubernetes API reference using the `api-reference` shortcode, for example to the {{< api-reference page="workload-resources/pod-v1" >}} reference: + +``` +{{}} +``` + +The content of the `page` parameter is the suffix of the URL of the API reference page. + + +You can link to a specific place into a page by specifying an `anchor` parameter, for example to the {{< api-reference page="workload-resources/pod-v1" anchor="PodSpec" >}} reference or the {{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" >}} section of the page: + +``` +{{}} +{{}} +``` + + +You can change the text of the link by specifying a `text` parameter, for example by linking to the {{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="Environment Variables">}} section of the page: + +``` +{{}} +``` + + + ## Table captions You can make tables more accessible to screen readers by adding a table caption. To add a [caption](https://www.w3schools.com/tags/tag_caption.asp) to a table, enclose the table with a `table` shortcode and specify the caption with the `caption` parameter. From 7655d8d778d3051dfe59381350a3e3a9e8a9e494 Mon Sep 17 00:00:00 2001 From: Pushkar Joglekar Date: Mon, 13 Sep 2021 16:37:13 -0700 Subject: [PATCH 70/79] Add a ports and protocols reference page - Refactored ports and protocols info under docs/reference - Updated the ports for kube-scheduler and kube-controller based on current state Co-authored-by: Tim Bannister --- content/en/docs/reference/_index.md | 2 + .../en/docs/reference/ports-and-protocols.md | 40 +++++++++++++++++++ .../tools/kubeadm/install-kubeadm.md | 28 ++----------- 3 files changed, 45 insertions(+), 25 deletions(-) create mode 100644 content/en/docs/reference/ports-and-protocols.md diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index c22e0ca836..5d1826f461 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -64,6 +64,8 @@ client libraries: * [Scheduler Policies](/docs/reference/scheduling/policies) * [Scheduler Profiles](/docs/reference/scheduling/config#profiles) +* List of [ports and protocols](/docs/reference/ports-and-protocols/) that + should be open on control plane and worker nodes ## Config APIs This section hosts the documentation for "unpublished" APIs which are used to diff --git a/content/en/docs/reference/ports-and-protocols.md b/content/en/docs/reference/ports-and-protocols.md new file mode 100644 index 0000000000..91d6cba8e7 --- /dev/null +++ b/content/en/docs/reference/ports-and-protocols.md @@ -0,0 +1,40 @@ +--- +title: Ports and Protocols +content_type: reference +weight: 50 +--- + +When running Kubernetes in an environment with strict network boundaries, such +as on-premises datacenter with physical network firewalls or Virtual +Networks in Public Cloud, it is useful to be aware of the ports and protocols +used by Kubernetes components + +## Control plane + +| Protocol | Direction | Port Range | Purpose | Used By | +|----------|-----------|------------|-------------------------|---------------------------| +| TCP | Inbound | 6443 | Kubernetes API server | All | +| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | +| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | +| TCP | Inbound | 10259 | kube-scheduler | Self | +| TCP | Inbound | 10257 | kube-controller-manager | Self | + +Although etcd ports are included in control plane section, you can also host your own +etcd cluster externally or on custom ports. + +## Worker node(s) {#node} + +| Protocol | Direction | Port Range | Purpose | Used By | +|----------|-----------|-------------|-----------------------|-------------------------| +| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | +| TCP | Inbound | 30000-32767 | NodePort Services† | All | + +† Default port range for [NodePort Services](/docs/concepts/services-networking/service/). + +All default port numbers can be overridden. When custom ports are used those +ports need to be open instead of defaults mentioned here. + +One common example is API server port that is sometimes switched +to 443. Alternatively, the default port is kept as is and API server is put +behind a load balancer that listens on 443 and routes the requests to API server +on the default port. diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 5be28cf377..7c6a9dd8bf 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -67,31 +67,9 @@ sudo sysctl --system For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. ## Check required ports - -### Control-plane node(s) - -| Protocol | Direction | Port Range | Purpose | Used By | -|----------|-----------|------------|-------------------------|---------------------------| -| TCP | Inbound | 6443\* | Kubernetes API server | All | -| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | -| TCP | Inbound | 10250 | kubelet API | Self, Control plane | -| TCP | Inbound | 10251 | kube-scheduler | Self | -| TCP | Inbound | 10252 | kube-controller-manager | Self | - -### Worker node(s) - -| Protocol | Direction | Port Range | Purpose | Used By | -|----------|-----------|-------------|-----------------------|-------------------------| -| TCP | Inbound | 10250 | kubelet API | Self, Control plane | -| TCP | Inbound | 30000-32767 | NodePort Services† | All | - -† Default port range for [NodePort Services](/docs/concepts/services-networking/service/). - -Any port numbers marked with * are overridable, so you will need to ensure any -custom ports you provide are also open. - -Although etcd ports are included in control-plane nodes, you can also host your own -etcd cluster externally or on custom ports. +These +[required ports](/docs/reference/ports-and-protocols/) +need to be open in order for Kubernetes components to communicate with each other. The pod network plugin you use (see below) may also require certain ports to be open. Since this differs with each pod network plugin, please see the From a978aa3a3bd886d5855cdac513cc1f4d5a8fd0f6 Mon Sep 17 00:00:00 2001 From: fakedoom Date: Sat, 18 Sep 2021 10:56:20 +0800 Subject: [PATCH 71/79] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E9=94=99=E8=AF=AF?= =?UTF-8?q?=E6=96=87=E5=AD=97?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 修改错误文字 --- .../docs/tutorials/kubernetes-basics/expose/expose-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html index cf21b08728..7b3654ae74 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -41,7 +41,7 @@ weight: 10

Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。

-

尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露

+

尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在集群外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露

    From 160d68bd43fe3b213ea4867e53ad8b0cfcb894f8 Mon Sep 17 00:00:00 2001 From: silenceshell Date: Mon, 19 Jul 2021 16:08:15 +0800 Subject: [PATCH 72/79] kubeadm-upgrade should upgrade to current branch version other than the latest version --- .../kubeadm/kubeadm-upgrade.md | 66 +++++++++---------- layouts/shortcodes/skew.html | 25 +++++++ 2 files changed, 58 insertions(+), 33 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index da07ed672e..cc759d8674 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -9,17 +9,17 @@ weight: 20 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version -{{< skew latestVersionAddMinor -1 >}}.x to version {{< skew latestVersion >}}.x, and from version -{{< skew latestVersion >}}.x to {{< skew latestVersion >}}.y (where `y > x`). Skipping MINOR versions +{{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version +{{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions when upgrading is unsupported. To see information about upgrading clusters created using older versions of kubeadm, please refer to following pages instead: -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -2 >}} to {{< skew latestVersionAddMinor -1 >}}](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -3 >}} to {{< skew latestVersionAddMinor -2 >}}](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -4 >}} to {{< skew latestVersionAddMinor -3 >}}](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -5 >}} to {{< skew latestVersionAddMinor -4 >}}](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -2 >}} to {{< skew currentVersionAddMinor -1 >}}](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -3 >}} to {{< skew currentVersionAddMinor -2 >}}](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -4 >}} to {{< skew currentVersionAddMinor -3 >}}](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -5 >}} to {{< skew currentVersionAddMinor -4 >}}](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) The upgrade workflow at high level is the following: @@ -45,19 +45,19 @@ The upgrade workflow at high level is the following: ## Determine which version to upgrade to -Find the latest stable {{< skew latestVersion >}} version using the OS package manager: +Find the latest stable {{< skew currentVersion >}} version using the OS package manager: {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache madison kubeadm - # find the latest {{< skew latestVersion >}} version in the list - # it should look like {{< skew latestVersion >}}.x-00, where x is the latest patch + # find the latest {{< skew currentVersion >}} version in the list + # it should look like {{< skew currentVersion >}}.x-00, where x is the latest patch {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes - # find the latest {{< skew latestVersion >}} version in the list - # it should look like {{< skew latestVersion >}}.x-0, where x is the latest patch + # find the latest {{< skew currentVersion >}} version in the list + # it should look like {{< skew currentVersion >}}.x-0, where x is the latest patch {{% /tab %}} {{< /tabs >}} @@ -74,18 +74,18 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc {{< tabs name="k8s_install_kubeadm_first_cp" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - # since apt-get version 1.1 you can also use the following method apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version - yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -120,13 +120,13 @@ Failing to do so will cause `kubeadm upgrade apply` to exit with an error and no ```shell # replace x with the patch version you picked for this upgrade - sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x + sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x ``` Once the command finishes you should see: ``` - [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy! + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ``` @@ -171,20 +171,20 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no {{< tabs name="k8s_install_kubelet" >}} {{< tab name="Ubuntu, Debian or HypriotOS" >}} 
    -    # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version
+    # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
     apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
     apt-mark hold kubelet kubectl
     -
     # since apt-get version 1.1 you can also use the following method
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
    {{< /tab >}} {{< tab name="CentOS, RHEL or Fedora" >}} 
    -    # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version
-    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
+    yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
    {{< /tab >}} {{< /tabs >}} @@ -216,18 +216,18 @@ without compromising the minimum required capacity for running your workloads. {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - # since apt-get version 1.1 you can also use the following method apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version - yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -254,18 +254,18 @@ without compromising the minimum required capacity for running your workloads. {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - # since apt-get version 1.1 you can also use the following method apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version - yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} diff --git a/layouts/shortcodes/skew.html b/layouts/shortcodes/skew.html index 13f44091b9..901a745ee1 100644 --- a/layouts/shortcodes/skew.html +++ b/layouts/shortcodes/skew.html @@ -54,11 +54,36 @@ {{- $latestVersionAddMinor = printf "%s%s%d" (index $versionArray 0) $seperator $latestVersionAddMinor -}} {{- $latestVersionAddMinor -}} {{- end -}} + +{{- $currentVersion := site.Params.version -}} +{{- $currentVersion := (replace $currentVersion "v" "") -}} +{{- $currentVersionArray := split $currentVersion "." -}} +{{- $currentMinorVersion := int (index $currentVersionArray 1) -}} + + +{{- if eq $version "currentVersion" -}} + {{- $currentVersion -}} +{{- end -}} + + +{{- if eq $version "currentVersionAddMinor" -}} + {{- $seperator := .Get 2 -}} + {{- if eq $seperator "" -}} + {{- $seperator = "." -}} + {{- end -}} + {{- $currentVersionAddMinor := int (.Get 1) -}} + {{- $currentVersionAddMinor = add $currentMinorVersion $currentVersionAddMinor -}} + {{- $currentVersionAddMinor = printf "%s%s%d" (index $versionArray 0) $seperator $currentVersionAddMinor -}} + {{- $currentVersionAddMinor -}} +{{- end -}} + \ No newline at end of file From 0abc481f3b05d64939d83d52a9483bc35d37e419 Mon Sep 17 00:00:00 2001 From: Rael Garcia Date: Mon, 20 Sep 2021 10:32:00 +0200 Subject: [PATCH 73/79] clean: remove 3rd party links Signed-off-by: Rael Garcia --- .../workloads/controllers/daemonset.md | 75 ++++++++----------- 1 file changed, 32 insertions(+), 43 deletions(-) diff --git a/content/es/docs/concepts/workloads/controllers/daemonset.md b/content/es/docs/concepts/workloads/controllers/daemonset.md index d52a5d7010..246f3dd090 100644 --- a/content/es/docs/concepts/workloads/controllers/daemonset.md +++ b/content/es/docs/concepts/workloads/controllers/daemonset.md @@ -12,23 +12,14 @@ Al eliminar un DaemonSet se limpian todos los Pods que han sido creados. Algunos casos de uso típicos de un DaemonSet son: -- ejecutar un proceso de almacenamiento en el clúster, como `glusterd`, `ceph`, en cada nodo. -- ejecutar un proceso de recolección de logs en cada nodo, como `fluentd` o `logstash`. -- ejecutar un proceso de monitorización de nodos en cada nodo, como [Prometheus Node Exporter]( - https://github.com/prometheus/node_exporter), [Sysdig Agent] (https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`, - [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), - [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), - [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), - [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), - Ganglia `gmond` o un agente de Instana. +- Ejecutar un proceso de almacenamiento en el clúster. +- Ejecutar un proceso de recolección de logs en cada nodo. +- Ejecutar un proceso de monitorización de nodos en cada nodo. De forma básica, se debería usar un DaemonSet, cubriendo todos los nodos, por cada tipo de proceso. -En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso, +En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso, pero con diferentes parámetros y/o diferentes peticiones de CPU y memoria según el tipo de hardware. - - - ## Escribir una especificación de DaemonSet @@ -46,7 +37,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### Campos requeridos -Como con cualquier otra configuración de Kubernetes, un DaemonSet requiere los campos `apiVersion`, `kind`, y `metadata`. +Como con cualquier otra configuración de Kubernetes, un DaemonSet requiere los campos `apiVersion`, `kind`, y `metadata`. Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos [desplegar aplicaciones](/docs/user-guide/deploying-applications/), [configurar contenedores](/docs/tasks/), y [gestión de objetos usando kubectl](/docs/concepts/overview/object-management-kubectl/overview/). @@ -56,10 +47,10 @@ Un DaemonSet también necesita un sección [`.spec`](https://git.k8s.io/communit El campo `.spec.template` es uno de los campos obligatorios de la sección `.spec`. -El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), excepto por el hecho de que está anidado y no tiene los campos `apiVersion` o `kind`. -Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar +Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar las etiquetas apropiadas (ver [selector de pod](#pod-selector)). Una plantilla Pod para un DaemonSet debe tener una [`RestartPolicy`](/docs/user-guide/pod-states) @@ -67,7 +58,7 @@ Una plantilla Pod para un DaemonSet debe tener una [`RestartPolicy`](/docs/user- ### Selector de Pod -El campo `.spec.selector` es un selector de pod. Funciona igual que el campo `.spec.selector` +El campo `.spec.selector` es un selector de pod. Funciona igual que el campo `.spec.selector` de un [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). A partir de Kubernetes 1.8, se debe configurar un selector de pod que coincida con las @@ -86,15 +77,15 @@ Cuando se configura ambos campos, el resultado es conjuntivo (AND). Si se especifica el campo `.spec.selector`, entonces debe coincidir con el campo `.spec.template.metadata.labels`. Aquellas configuraciones que no coinciden, son rechazadas por la API. -Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro +Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro DaemonSet, o via otro controlador como un ReplicaSet. De ser así, el controlador del DaemonSet -pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta +pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta operación. Un caso donde puede que necesites hacer esto es cuando quieres crear manualmente un Pod con un valor diferente en un nodo para pruebas. ### Ejecutar Pods sólo en algunos Nodos Si se configura un `.spec.template.spec.nodeSelector`, entonces el controlador del DaemonSet - creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado. + creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado. De forma similar, si se configura una `.spec.template.spec.affinity`, entonces el controlador del DaemonSet creará los Pods en aquellos nodos que coincidan con la [afinidad de nodo](/docs/concepts/configuration/assign-pod-node/) indicada. Si no se configura ninguno de los dos, entonces el controlador del DaemonSet creará los Pods en todos los nodos. @@ -115,13 +106,13 @@ se indica el campo `.spec.nodeName`, y por ello el planificador los ignora). Por {{< feature-state state="beta" for-kubernetes-version="1.12" >}} -Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod. +Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod. Normalmente, es el planificador de Kubernetes quien determina el nodo donde se ejecuta un Pod. Sin embargo, los pods del DaemonSet son creados y planificados por el mismo controlador del DaemonSet. Esto introduce los siguientes inconvenientes: * Comportamiento inconsistente de los Pods: Los Pods normales que están esperando - a ser creados, se encuentran en estado `Pending`, pero los pods del DaemonSet no pasan por el estado `Pending`. + a ser creados, se encuentran en estado `Pending`, pero los pods del DaemonSet no pasan por el estado `Pending`. Esto confunde a los usuarios. * La [prioridad y el comportamiento de apropiación de Pods](/docs/concepts/configuration/pod-priority-preemption/) se maneja por el planificador por defecto. Cuando se habilita la contaminación, el controlador del DaemonSet @@ -130,7 +121,7 @@ Esto introduce los siguientes inconvenientes: `ScheduleDaemonSetPods` permite planificar DaemonSets usando el planificador por defecto en vez del controlador del DaemonSet, añadiendo la condición `NodeAffinity` a los pods del DaemonSet, en vez de la condición `.spec.nodeName`. El planificador por defecto -se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del +se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del pod del DaemonSet ya existe, se sustituye. El controlador del DaemonSet sólo realiza estas operaciones cuando crea o modifica los pods del DaemonSet, y no se realizan cambios al `spec.template` del DaemonSet. @@ -146,7 +137,7 @@ nodeAffinity: - target-host-name ``` -Adicionalmente, se añade de forma automática la tolerancia `node.kubernetes.io/unschedulable:NoSchedule` +Adicionalmente, se añade de forma automática la tolerancia `node.kubernetes.io/unschedulable:NoSchedule` a los Pods del DaemonSet. Así, el planificador por defecto ignora los nodos `unschedulable` cuando planifica los Pods del DaemonSet. @@ -158,23 +149,23 @@ A pesar de que los Pods de proceso respetan las la siguientes tolerancias son añadidas a los Pods del DaemonSet de forma automática según las siguientes características: -| Clave de tolerancia | Efecto | Versión | Descripción | -| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco. | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria. | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto. | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto. | +| Clave de tolerancia | Efecto | Versión | Descripción | +| ---------------------------------------- | ---------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco. | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria. | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto. | ## Comunicarse con los Pods de los DaemonSets Algunos patrones posibles para la comunicación con los Pods de un DaemonSet son: -- **Push**: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio, +- **Push**: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio, como una base de datos de estadísticas. No tienen clientes. -- **NodeIP y Known Port**: Los Pods del DaemonSet pueden usar un `hostPort`, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo, +- **NodeIP y Known Port**: Los Pods del DaemonSet pueden usar un `hostPort`, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo, y conocen el puerto acordado. - **DNS**: Se crea un [servicio headless](/docs/concepts/services-networking/service/#headless-services) con el mismo selector de pod, y entonces se descubre a los DaemonSets usando los recursos `endpoints` o mediante múltiples registros de tipo A en el DNS. @@ -185,10 +176,10 @@ y conocen el puerto acordado. Si se cambian las etiquetas de nodo, el DaemonSet comenzará de forma inmediata a añadir Pods a los nuevos nodos que coincidan y a eliminar los Pods de aquellos nuevos nodos donde no coincidan. -Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods. +Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods. Además, el controlador del DaemonSet utilizará la plantilla original la próxima vez que se cree un nodo (incluso con el mismo nombre). -Puedes eliminar un DaemonSet. Si indicas el parámetro `--cascade=false` al usar `kubectl`, +Puedes eliminar un DaemonSet. Si indicas el parámetro `--cascade=false` al usar `kubectl`, entonces los Pods continuarán ejecutándose en los nodos. Así, puedes crear entonces un nuevo DaemonSet con una plantilla diferente. El nuevo DaemonSet con la plantilla diferente reconocerá a todos los Pods existentes que tengan etiquetas coincidentes y no modificará o eliminará ningún Pod aunque la plantilla no coincida con los Pods desplegados. @@ -198,14 +189,14 @@ A partir de las versión 1.6 de Kubernetes, puedes [llevar a cabo una actualizac ## Alternativas al DaemonSet -### Secuencias de comandos de inicialización +### Secuencias de comandos de inicialización Aunque es perfectamente posible ejecutar procesos arrancándolos directamente en un nodo (ej. usando `init`, `upstartd`, o `systemd`), existen numerosas ventajas si se realiza via un DaemonSet: - Capacidad de monitorizar y gestionar los logs de los procesos del mismo modo que para las aplicaciones. - Mismo lenguaje y herramientas de configuración (ej. plantillas de Pod, `kubectl`) tanto para los procesos como para las aplicaciones. -- Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones. +- Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones. Sin embargo, esto también se podría conseguir ejecutando los procesos en un contenedor en vez de un Pod (ej. arrancarlos directamente via Docker). @@ -231,8 +222,6 @@ ambos crean Pods, y que dichos Pods tienen procesos que no se espera que termine servidores de almacenamiento). Utiliza un Deployment para definir servicios sin estado, como las interfaces de usuario, donde el escalado vertical y horizontal -del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod. -Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos, -y cuando se necesite que arranque antes que el resto de Pods. - - +del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod. +Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos, +y cuando se necesite que arranque antes que el resto de Pods. \ No newline at end of file From 1fbed1d920173ad263bf387a361a9b5272bfcf89 Mon Sep 17 00:00:00 2001 From: Rael Garcia Date: Mon, 20 Sep 2021 21:45:09 +0200 Subject: [PATCH 74/79] fix: reword phrase Co-authored-by: Victor Morales --- content/es/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/workloads/controllers/daemonset.md b/content/es/docs/concepts/workloads/controllers/daemonset.md index 246f3dd090..686cf2f21f 100644 --- a/content/es/docs/concepts/workloads/controllers/daemonset.md +++ b/content/es/docs/concepts/workloads/controllers/daemonset.md @@ -82,7 +82,7 @@ DaemonSet, o via otro controlador como un ReplicaSet. De ser así, el controlad pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta operación. Un caso donde puede que necesites hacer esto es cuando quieres crear manualmente un Pod con un valor diferente en un nodo para pruebas. -### Ejecutar Pods sólo en algunos Nodos +### Ejecutar Pods sólo en Nodos seleccionados Si se configura un `.spec.template.spec.nodeSelector`, entonces el controlador del DaemonSet creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado. From d9d4daa184f7043b5182863d03b95a3a4da5542e Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Mon, 20 Sep 2021 17:30:28 -0400 Subject: [PATCH 75/79] releng: Update Release Managers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Promote Verónica López to Release Manager - Dan Mangum to Emeritus (TL + Release Manager) Signed-off-by: Stephen Augustus --- content/en/releases/release-managers.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index 0b68ca0b87..03910c7d4f 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -88,10 +88,10 @@ GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kuber - Adolfo García Veytia ([@puerco](https://github.com/puerco)) - Carlos Panato ([@cpanato](https://github.com/cpanato)) -- Daniel Mangum ([@hasheddan](https://github.com/hasheddan)) - Marko Mudrinić ([@xmudrii](https://github.com/xmudrii)) - Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) - Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) +- Verónica López ([@verolop](https://github.com/verolop)) ### Becoming a Release Manager @@ -138,7 +138,6 @@ GitHub Mentions: @kubernetes/release-engineering - Nabarun Pal ([@palnabarun](https://github.com/palnabarun)) - Seth McCombs ([@sethmccombs](https://github.com/sethmccombs)) - Taylor Dolezal ([@onlydole](https://github.com/onlydole)) -- Verónica López ([@verolop](https://github.com/verolop)) - Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin)) ### Becoming a Release Manager Associate @@ -199,7 +198,6 @@ GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/ - Adolfo García Veytia ([@puerco](https://github.com/puerco)) - Carlos Panato ([@cpanato](https://github.com/cpanato)) -- Daniel Mangum ([@hasheddan](https://github.com/hasheddan)) - Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) --- From ece10cd2af4fd6b32bfcbc2ff0aa1b49c2e92c8f Mon Sep 17 00:00:00 2001 From: Arhell Date: Tue, 21 Sep 2021 00:32:18 +0300 Subject: [PATCH 76/79] [de] Add seccomp tutorial to index --- content/de/docs/tutorials/_index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/de/docs/tutorials/_index.md b/content/de/docs/tutorials/_index.md index e00382c893..3ab69b6073 100644 --- a/content/de/docs/tutorials/_index.md +++ b/content/de/docs/tutorials/_index.md @@ -50,6 +50,8 @@ Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise e * [AppArmor](/docs/tutorials/clusters/apparmor/) +* [seccomp](/docs/tutorials/clusters/seccomp/) + ## Services * [Source IP verwenden](/docs/tutorials/services/source-ip/) From 064d6676d1be934282e6a7e61b537baede8a27af Mon Sep 17 00:00:00 2001 From: silenceshell Date: Tue, 21 Sep 2021 10:16:35 +0800 Subject: [PATCH 77/79] kubeadm upgrade to latest patch release, not latest stable --- .../en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index cc759d8674..8f259ddd45 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -45,7 +45,7 @@ The upgrade workflow at high level is the following: ## Determine which version to upgrade to -Find the latest stable {{< skew currentVersion >}} version using the OS package manager: +Find the latest patch release for Kubernetes {{< skew currentVersion >}} using the OS package manager: {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} From 0ad09c36d6d5e660c27f5d30076d2f34270a815e Mon Sep 17 00:00:00 2001 From: Sergiusz Urbaniak Date: Tue, 21 Sep 2021 08:20:24 +0200 Subject: [PATCH 78/79] fix expiration of bound SA tokens Signed-off-by: Sergiusz Urbaniak --- .../docs/reference/access-authn-authz/service-accounts-admin.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index f40cc7d00c..820b9b6cca 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -72,7 +72,7 @@ The ServiceAccount admission controller will add the following projected volume defaultMode: 420 # 0644 sources: - serviceAccountToken: - expirationSeconds: 3600 + expirationSeconds: 3607 path: token - configMap: items: From c1d3db08c9ceadc928121ecec1bc579ed5c4f405 Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 22 Sep 2021 03:43:43 +0300 Subject: [PATCH 79/79] [zh] using-api/health-checks.md: use consistent casing --- content/zh/docs/reference/using-api/health-checks.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/zh/docs/reference/using-api/health-checks.md b/content/zh/docs/reference/using-api/health-checks.md index 4def388ccc..d22c88e43d 100644 --- a/content/zh/docs/reference/using-api/health-checks.md +++ b/content/zh/docs/reference/using-api/health-checks.md @@ -29,7 +29,7 @@ The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `read The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead. The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration. For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint. -Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code. +Machines that check the `healthz`/`livez`/`readyz` of the API server should rely on the HTTP status code. A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint. The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server. --> @@ -37,7 +37,7 @@ Kubernetes API 服务器提供 3 个 API 端点（`healthz`、`livez` 和 `ready `healthz` 端点已被弃用（自 Kubernetes v1.16 起），你应该使用更为明确的 `livez` 和 `readyz` 端点。 `livez` 端点可与 `--livez-grace-period` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)一起使用，来指定启动持续时间。 为了正常关机，你可以使用 `/readyz` 端点并指定 `--shutdown-delay-duration` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)。 -检查 API 服务器的 `health`/`livez`/`readyz` 端点的机器应依赖于 HTTP 状态代码。 +检查 API 服务器的 `healthz`/`livez`/`readyz` 端点的机器应依赖于 HTTP 状态代码。 状态码 `200` 表示 API 服务器是 `healthy`、`live` 还是 `ready`，具体取决于所调用的端点。 以下更详细的选项供操作人员使用，用来调试其集群或专门调试 API 服务器的状态。 @@ -46,7 +46,7 @@ Kubernetes API 服务器提供 3 个 API 端点（`healthz`、`livez` 和 `ready 对于所有端点，都可以使用 `verbose` 参数来打印检查项以及检查状态。 这对于操作人员调试 API 服务器的当前状态很有用，这些不打算给机器使用： @@ -130,12 +130,12 @@ healthz check passed {{< feature-state state="alpha" >}} -每个单独的健康检查都会公开一个 http 端点，并且可以单独检查。 +每个单独的健康检查都会公开一个 HTTP 端点，并且可以单独检查。 单个运行状况检查的模式为 `/livez/`，其中 `livez` 和 `readyz` 表明你要检查的是 API 服务器是否存活或就绪。 `` 的路径可以通过上面的 `verbose` 参数发现 ，并采用 `[+]` 和 `ok` 之间的路径。 这些单独的健康检查不应由机器使用，但对于操作人员调试系统而言，是有帮助的：