From 491365356f550cd96bc48165b257474941e0453a Mon Sep 17 00:00:00 2001 From: Edith Date: Sat, 2 Oct 2021 18:39:58 -0500 Subject: [PATCH 001/254] [es] Add concepts/storage/storage-capacity.md --- .../docs/concepts/storage/storage-capacity.md | 76 +++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 content/es/docs/concepts/storage/storage-capacity.md diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md new file mode 100644 index 0000000000..a29f4810df --- /dev/null +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -0,0 +1,76 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Capacidad de Almacenamiento +content_type: concept +weight: 45 +--- + + + +La capacidad de almacenamiento es limitada y puede variar según el nodo en el que un Pod se ejecuta: es posible que no todos los nodos puedan acceder al almacenamiento conectado a la red o que, para empezar, el almacenamiento sea local en un nodo. + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el programador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. + +El seguimiento de la capacidad de almacenamiento es compatible con los controladores de la {{< glossary_tooltip +text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y +[necesita estar habilitado](#enabling-storage-capacity-tracking) al instalar un controlador CSI. + + + +## API + +Hay dos extensiones de API para esta función: + +- Los objetos CSIStorageCapacity: + son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. +- [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): + cuando se establece en `true`, el scheduler de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. + +## Planificación + +El scheduler de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: + +- la puerta de la característica `CSIStorageCapacity` es `true`, +- un Pod usa un volumen que aún no se ha creado, +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding + mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), + y +- el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. + +En ese caso, el scheduler sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. + +Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador de almacenamiento decide dónde crear el volumen, independientemente de los pods que usarán el volumen. +Luego, el scheduler programa los pods en los nodos donde el volumen está disponible después de que se haya creado. + +Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), +la programación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. + +## Reprogramar + +Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. + +Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el scheduler de Kubernetes intenta nuevamente encontrar un nodo para el Pod. + +## Limitationes + +El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. + +Una situación en la que la programación puede fallar de forma permanente es cuando un pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ +Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. + +## Habilitación del seguimiento de la capacidad de almacenamiento + +El seguimiento de la capacidad de almacenamiento es una función beta y está habilitada de forma predeterminada en un clúster de Kubernetes desde Kubernetes 1.21. Además de tener la función habilitada en el clúster, un controlador CSI también tiene que admitirlo. Consulte la documentación del controlador para obtener más detalles. + +## {{% heading "whatsnext" %}} + +- Para obtener más información sobre el diseño, consulte las + [Restricciones de Capacidad de Almacenamiento para la Programación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). +- Para obtener más información sobre un mayor desarrollo de esta función, consulte [problema de seguimiento de mejoras #1472](https://github.com/kubernetes/enhancements/issues/1472). +- Aprender sobre [Scheduler de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) From eb34864d3eee3787808a707d60dc84d0155d7755 Mon Sep 17 00:00:00 2001 From: Edith Date: Sat, 2 Oct 2021 19:34:02 -0500 Subject: [PATCH 002/254] [es] Add concepts/storage/volume-pvc-datasource.md --- .../concepts/storage/volume-pvc-datasource.md | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 content/es/docs/concepts/storage/volume-pvc-datasource.md diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md new file mode 100644 index 0000000000..29de717f0e --- /dev/null +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -0,0 +1,66 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Clonación de volumen CSI +content_type: concept +weight: 30 +--- + + + +Este documento describe el concepto para clonar volúmenes CSI existentes en Kubernetes. Se sugiere estar familiarizado con [Volúmenes](/docs/concepts/storage/volumes). + + + +## Introduction + +La función de clonación de volumen {{< glossary_tooltip text="CSI" term_id="csi" >}} agrega soporte para especificar {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s existentes en el campo `dataSource` para indicar que un usuario desea clonar un {{< glossary_tooltip term_id="volume" >}}. + +Un Clon se define como un duplicado de un volumen de Kubernetes existente que se puede consumir como lo sería cualquier volumen estándar. La única diferencia es que al aprovisionar, en lugar de crear un "nuevo" Volumen vacío, el dispositivo de backend crea un duplicado exacto del Volumen especificado. + +La implementación de la clonación, desde la perspectiva de la API de Kubernetes, agrega la capacidad de especificar un PVC existente como dataSource durante la creación de un nuevo PVC. El PVC de origen debe estar vinculado y disponible (no en uso). + +Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: + +- El soporte de clonación (`VolumePVCDataSource`) sólo está disponible para controladores CSI. +- El soporte de clonación sólo está disponible para aprovisionadores dinámicos. +- Los controladores CSI pueden haber implementado o no la funcionalidad de clonación de volúmenes. +- Sólo puede clonar un PVC cuando existe en el mismo espacio de nombres que el PVC de destino (el origen y el destino deben estar en el mismo espacio de nombres). +- La clonación sólo se admite dentro de la misma Clase de Almacenamiento. + - El volumen de destino debe ser de la misma clase de almacenamiento que el origen + - Se puede utilizar la clase de almacenamiento predeterminada y se puede omitir storageClassName en la especificación +- La clonación sólo se puede realizar entre dos volúmenes que usan la misma configuración de VolumeMode (si solicita un volumen en modo de bloqueo, la fuente DEBE también ser en modo de bloqueo) + +## Aprovisionamiento + +Los clones se aprovisionan como cualquier otro PVC con la excepción de agregar un origen de datos que hace referencia a un PVC existente en el mismo espacio de nombres. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: clone-of-pvc-1 + namespace: myns +spec: + accessModes: + - ReadWriteOnce + storageClassName: cloning + resources: + requests: + storage: 5Gi + dataSource: + kind: PersistentVolumeClaim + name: pvc-1 +``` + +{{< note >}} +Debe especificar un valor de capacidad para `spec.resources.requests.storage` y el valor que especifique debe ser igual o mayor que la capacidad del volumen de origen. +{{< /note >}} + +El resultado es un nuevo PVC con el nombre `clone-of-pvc-1` que tiene exactamente el mismo contenido que la fuente especificada `pvc-1`. + +## Uso + +Una vez disponible el nuevo PVC, el PVC clonado se consume igual que el resto de PVC. También se espera en este punto que el PVC recién creado sea un objeto independiente. Se puede consumir, clonar, tomar snapshots, o eliminar de forma independiente y sin tener en cuenta sus datos originales. Esto también implica que la fuente no está vinculada de ninguna manera al clon recién creado, también puede modificarse o eliminarse sin afectar al clon recién creado. From 1788adc35fad244dcbe3ab6935b5c28f04fe968a Mon Sep 17 00:00:00 2001 From: Edith Date: Sat, 2 Oct 2021 20:27:17 -0500 Subject: [PATCH 003/254] [es] Add concepts/storage/dynamic-provisioning.md --- .../concepts/storage/dynamic-provisioning.md | 102 ++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 content/es/docs/concepts/storage/dynamic-provisioning.md diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md new file mode 100644 index 0000000000..e0a8f83960 --- /dev/null +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -0,0 +1,102 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Aprovisionamiento Dinámico de volumen +content_type: concept +weight: 40 +--- + + + +El aprovisionamiento dinámico de volúmenes permite crear volúmenes de almacenamiento bajo demanda. Sin el aprovisionamiento dinámico, los administradores de clústeres tienen que realizar llamadas manualmente a su proveedor de almacenamiento o nube para crear nuevos volúmenes de almacenamiento y luego crear [objetos de `PersistentVolume`](/docs/concepts/storage/persistent-volumes/) +para representarlos en Kubernetes. La función de aprovisionamiento dinámico elimina la necesidad de que los administradores del clúster aprovisionen previamente el almacenamiento. En cambio cuando lo solicitan los usuarios aprovisionan el almacenamiento es automático. + + + +## Antecedentes + +La implementación del aprovisionamiento dinámico de volúmenes se basa en el objeto API `StorageClass` +del grupo API `storage.k8s.io`. Un administrador de clúster puede definir tantos objetos +`StorageClass` como sea necesario, cada uno especificando un _volume plugin_ (aka +_provisioner_) que aprovisiona un volumen y el conjunto de parámetros para pasar a ese aprovisionador. Un administrador de clúster puede definir y exponer varios tipos de almacenamiento (del mismo o de diferentes sistemas de almacenamiento) dentro de un clúster, cada uno con un conjunto personalizado de parámetros. Este diseño también garantiza que los usuarios finales no tengan que preocuparse por la complejidad y los matices de cómo se aprovisiona el almacenamiento, pero que aún tengan la capacidad de seleccionar entre múltiples opciones de almacenamiento. + +Puede encontrar más información sobre las clases de almacenamiento +[aqui](/docs/concepts/storage/storage-classes/). + +## Habilitación del aprovisionamiento dinámico + +Para habilitar el aprovisionamiento dinámico, un administrador de clúster debe crear previamente uno o más objetos StorageClass para los usuarios. Los objetos StorageClass definen qué aprovisionador se debe usar y qué parámetros se deben pasar a ese aprovisionador cuando se invoca el aprovisionamiento dinámico. +El nombre de un objeto StorageClass debe ser un +[nombre de subdominio de DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +El siguiente manifiesto crea una clase de almacenamiento "lenta" que aprovisiona discos persistentes estándar similares a discos. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +``` + +El siguiente manifiesto crea una clase de almacenamiento "rápida" que aprovisiona discos persistentes similares a SSD. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: fast +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-ssd +``` + +## Usar Aprovisionamiento Dinámico + +Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la annotation +`volume.beta.kubernetes.io/storage-class`. Sin embargo, esta anotación está obsoleta desde v1.9. Los usuarios ahora pueden y deben usar el campo +`storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador +(ver [below](#habilitación-del-aprovisionamiento-dinámico)). + +Para seleccionar la clase de almacenamiento "rápido", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: claim1 +spec: + accessModes: + - ReadWriteOnce + storageClassName: fast + resources: + requests: + storage: 30Gi +``` + +Esta afirmación da como resultado que se aprovisione automáticamente un disco persistente similar a SSD. Cuando se elimina la reclamación, se destruye el volumen. + +## Comportamiento Predeterminado + +El aprovisionamiento dinámico se puede habilitar en un clúster de modo que todos los reclamos se aprovisionen dinámicamente si no se especifica una clase de almacenamiento. Un administrador de clúster puede habilitar este comportamiento al: + +- Marcar un objeto `StorageClass` como _default_; +- Asegúrese de que el [controlador de admisión `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) esté habilitado en el servidor de API. + +Un administrador puede marcar un `StorageClass` específico como predeterminada agregando la anotación +`storageclass.kubernetes.io/is-default-class`. +Cuando existe un `StorageClass` predeterminado en un clúster y un usuario crea un +`PersistentVolumeClaim` con `storageClassName` sin especificar, el controlador de admisión +`DefaultStorageClass` agrega automáticamente el campo +`storageClassName` que apunta a la clase de almacenamiento predeterminada. + +Tenga en cuenta que puede haber como máximo una clase de almacenamiento _default_, o un `PersistentVolumeClaim` sin `storageClassName` especificado explícitamente. + +## Conocimiento de la Topología + +En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los pods. Esto se puede lograr configurando el [Volume Binding +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From a03d2ea8e19f776b68dd679f870fc3add54422c9 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:11:33 -0500 Subject: [PATCH 004/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md thanks for this Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index e0a8f83960..3883f9c323 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -11,7 +11,7 @@ weight: 40 El aprovisionamiento dinámico de volúmenes permite crear volúmenes de almacenamiento bajo demanda. Sin el aprovisionamiento dinámico, los administradores de clústeres tienen que realizar llamadas manualmente a su proveedor de almacenamiento o nube para crear nuevos volúmenes de almacenamiento y luego crear [objetos de `PersistentVolume`](/docs/concepts/storage/persistent-volumes/) -para representarlos en Kubernetes. La función de aprovisionamiento dinámico elimina la necesidad de que los administradores del clúster aprovisionen previamente el almacenamiento. En cambio cuando lo solicitan los usuarios aprovisionan el almacenamiento es automático. +para representarlos en Kubernetes. La función de aprovisionamiento dinámico elimina la necesidad de que los administradores del clúster aprovisionen previamente el almacenamiento. En cambio, el aprovisionamiento ocurre automáticamente cuando los usuarios lo solicitan. From b63b180d2d948ee6c2b21e84faee4d83e72910c8 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:16:59 -0500 Subject: [PATCH 005/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md Great! :) Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 3883f9c323..0bf6403e0b 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -31,7 +31,7 @@ Para habilitar el aprovisionamiento dinámico, un administrador de clúster debe El nombre de un objeto StorageClass debe ser un [nombre de subdominio de DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. -El siguiente manifiesto crea una clase de almacenamiento "lenta" que aprovisiona discos persistentes estándar similares a discos. +El siguiente manifiesto crea una clase de almacenamiento llamada "slow" que aprovisiona discos persistentes estándar similares a discos. ```yaml apiVersion: storage.k8s.io/v1 From 4d126eb89bdbc82248c7cf1b404d467ef2bc5087 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:17:40 -0500 Subject: [PATCH 006/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 0bf6403e0b..cf3708accd 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -43,7 +43,7 @@ parameters: type: pd-standard ``` -El siguiente manifiesto crea una clase de almacenamiento "rápida" que aprovisiona discos persistentes similares a SSD. +El siguiente manifiesto crea una clase de almacenamiento llamada "fast" que aprovisiona discos persistentes similares a SSD. ```yaml apiVersion: storage.k8s.io/v1 From 47fd2b3de5658b3b40cc7052241ccc493e8d89c2 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:18:45 -0500 Subject: [PATCH 007/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index cf3708accd..b0e5216cce 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -57,7 +57,7 @@ parameters: ## Usar Aprovisionamiento Dinámico -Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la annotation +Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la anotación `volume.beta.kubernetes.io/storage-class`. Sin embargo, esta anotación está obsoleta desde v1.9. Los usuarios ahora pueden y deben usar el campo `storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador (ver [below](#habilitación-del-aprovisionamiento-dinámico)). From 926be5786e1050a6a2a951131faff47a81e1af64 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:21:26 -0500 Subject: [PATCH 008/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index b0e5216cce..25aeca28e2 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -62,7 +62,7 @@ Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir un `storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador (ver [below](#habilitación-del-aprovisionamiento-dinámico)). -Para seleccionar la clase de almacenamiento "rápido", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: +Para seleccionar la clase de almacenamiento llamada "fast", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: ```yaml apiVersion: v1 From dde74945b9c61177bb193945d1f0de340773cce6 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:22:15 -0500 Subject: [PATCH 009/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 25aeca28e2..77e4bd66d9 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -78,7 +78,7 @@ spec: storage: 30Gi ``` -Esta afirmación da como resultado que se aprovisione automáticamente un disco persistente similar a SSD. Cuando se elimina la reclamación, se destruye el volumen. +Esta afirmación da como resultado que se aprovisione automáticamente un disco persistente similar a SSD. Cuando se elimina la petición, se destruye el volumen. ## Comportamiento Predeterminado From 907020f85f634c5294f6d0aff36cdac15ebe7f6d Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:22:54 -0500 Subject: [PATCH 010/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 77e4bd66d9..0e227627a2 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -82,7 +82,7 @@ Esta afirmación da como resultado que se aprovisione automáticamente un disco ## Comportamiento Predeterminado -El aprovisionamiento dinámico se puede habilitar en un clúster de modo que todos los reclamos se aprovisionen dinámicamente si no se especifica una clase de almacenamiento. Un administrador de clúster puede habilitar este comportamiento al: +El aprovisionamiento dinámico se puede habilitar en un clúster de modo que todas las peticiones se aprovisionen dinámicamente si no se especifica una clase de almacenamiento. Un administrador de clúster puede habilitar este comportamiento al: - Marcar un objeto `StorageClass` como _default_; - Asegúrese de que el [controlador de admisión `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) esté habilitado en el servidor de API. From 838df6cfccce890dc6b0a0c74848851baba24ab4 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:23:35 -0500 Subject: [PATCH 011/254] Update content/es/docs/concepts/storage/dynamic-provisioning.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 0e227627a2..cdff9b48e1 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -98,5 +98,5 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología -En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los pods. Esto se puede lograr configurando el [Volume Binding +En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From 50f945de77bdb114553c01013a45fe149dc0c939 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:23:59 -0500 Subject: [PATCH 012/254] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index a29f4810df..24616f1aba 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -28,7 +28,7 @@ text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: - son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. + son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): cuando se establece en `true`, el scheduler de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. From f206df1b2e7b1ae06501036520df9a557591c20c Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:24:15 -0500 Subject: [PATCH 013/254] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 24616f1aba..0e95978c2d 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -61,7 +61,7 @@ Debido a que Kubernetes pudo haber elegido un nodo basándose en información de El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. -Una situación en la que la programación puede fallar de forma permanente es cuando un pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ +Una situación en la que la programación puede fallar de forma permanente es cuando un Pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. ## Habilitación del seguimiento de la capacidad de almacenamiento From 2a2f973907c6704d5a17dd2722a3990b37f4d159 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:27:00 -0500 Subject: [PATCH 014/254] Update content/es/docs/concepts/storage/volume-pvc-datasource.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-pvc-datasource.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md index 29de717f0e..80608ef2bb 100644 --- a/content/es/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -14,7 +14,7 @@ Este documento describe el concepto para clonar volúmenes CSI existentes en Kub -## Introduction +## Introducción La función de clonación de volumen {{< glossary_tooltip text="CSI" term_id="csi" >}} agrega soporte para especificar {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s existentes en el campo `dataSource` para indicar que un usuario desea clonar un {{< glossary_tooltip term_id="volume" >}}. From 202b2ad646fd8c471a6ff9be52112089fcf5be91 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:27:28 -0500 Subject: [PATCH 015/254] Update content/es/docs/concepts/storage/volume-pvc-datasource.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-pvc-datasource.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md index 80608ef2bb..2cc1252581 100644 --- a/content/es/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -27,7 +27,7 @@ Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: - El soporte de clonación (`VolumePVCDataSource`) sólo está disponible para controladores CSI. - El soporte de clonación sólo está disponible para aprovisionadores dinámicos. - Los controladores CSI pueden haber implementado o no la funcionalidad de clonación de volúmenes. -- Sólo puede clonar un PVC cuando existe en el mismo espacio de nombres que el PVC de destino (el origen y el destino deben estar en el mismo espacio de nombres). +- Sólo puede clonar un PVC cuando existe en el mismo Namespace que el PVC de destino (el origen y el destino deben estar en el mismo Namespace). - La clonación sólo se admite dentro de la misma Clase de Almacenamiento. - El volumen de destino debe ser de la misma clase de almacenamiento que el origen - Se puede utilizar la clase de almacenamiento predeterminada y se puede omitir storageClassName en la especificación From 31581e5884b343988da5e988710af61c531e6f5b Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 10 Oct 2021 10:27:37 -0500 Subject: [PATCH 016/254] Update content/es/docs/concepts/storage/volume-pvc-datasource.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/volume-pvc-datasource.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md index 2cc1252581..dcb2690d0e 100644 --- a/content/es/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -35,7 +35,7 @@ Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: ## Aprovisionamiento -Los clones se aprovisionan como cualquier otro PVC con la excepción de agregar un origen de datos que hace referencia a un PVC existente en el mismo espacio de nombres. +Los clones se aprovisionan como cualquier otro PVC con la excepción de agregar un origen de datos que hace referencia a un PVC existente en el mismo Namespace. ```yaml apiVersion: v1 From 7f4fdd57e35db256c22e2c527d1c2ea889902d76 Mon Sep 17 00:00:00 2001 From: edithturn Date: Sun, 24 Oct 2021 21:30:53 -0500 Subject: [PATCH 017/254] fixing word in link --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index cdff9b48e1..2a8b40461a 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -60,7 +60,7 @@ parameters: Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la anotación `volume.beta.kubernetes.io/storage-class`. Sin embargo, esta anotación está obsoleta desde v1.9. Los usuarios ahora pueden y deben usar el campo `storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador -(ver [below](#habilitación-del-aprovisionamiento-dinámico)). +(ver [documentación](#habilitación-del-aprovisionamiento-dinámico)). Para seleccionar la clase de almacenamiento llamada "fast", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: From 02b3b8e4cb407e26c6e949278d927080f65a9e3d Mon Sep 17 00:00:00 2001 From: Edith Puclla Date: Tue, 26 Oct 2021 10:13:09 -0500 Subject: [PATCH 018/254] test --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 2a8b40461a..3aa777a305 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) From 7336477aeddf031410e1d89c9a56b06f3b728a8f Mon Sep 17 00:00:00 2001 From: Edith Puclla Date: Tue, 26 Oct 2021 10:25:58 -0500 Subject: [PATCH 019/254] adding point at the end --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 3aa777a305..2a8b40461a 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From 141bce454fdb05575e9aedb7074aad355136f958 Mon Sep 17 00:00:00 2001 From: edithturn Date: Fri, 29 Oct 2021 14:55:31 -0500 Subject: [PATCH 020/254] test cla --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 2a8b40461a..3aa777a305 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) From eb6efadf1a14cdb66aec14c72b8e1d3813e89ede Mon Sep 17 00:00:00 2001 From: edithturn Date: Fri, 29 Oct 2021 14:56:01 -0500 Subject: [PATCH 021/254] test cla --- content/es/docs/concepts/storage/dynamic-provisioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md index 3aa777a305..2a8b40461a 100644 --- a/content/es/docs/concepts/storage/dynamic-provisioning.md +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -99,4 +99,4 @@ Tenga en cuenta que puede haber como máximo una clase de almacenamiento _defaul ## Conocimiento de la Topología En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode) +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). From f7add99775c21702e065e5fd80202adc48e3849e Mon Sep 17 00:00:00 2001 From: edithturn Date: Tue, 16 Nov 2021 12:43:18 -0500 Subject: [PATCH 022/254] change scheduler with planificador --- content/es/docs/concepts/storage/storage-capacity.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 0e95978c2d..e210b058a7 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -30,11 +30,11 @@ Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): - cuando se establece en `true`, el scheduler de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. + cuando se establece en `true`, el Planificador de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. ## Planificación -El scheduler de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: +El Planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: - la puerta de la característica `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, @@ -43,10 +43,10 @@ El scheduler de Kubernetes utiliza la información sobre la capacidad de almacen y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. -En ese caso, el scheduler sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. +En ese caso, el Planificador sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador de almacenamiento decide dónde crear el volumen, independientemente de los pods que usarán el volumen. -Luego, el scheduler programa los pods en los nodos donde el volumen está disponible después de que se haya creado. +Luego, el Planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), la programación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. @@ -55,7 +55,7 @@ la programación siempre ocurre sin considerar la capacidad de almacenamiento. E Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. -Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el scheduler de Kubernetes intenta nuevamente encontrar un nodo para el Pod. +Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el Planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. ## Limitationes @@ -73,4 +73,4 @@ El seguimiento de la capacidad de almacenamiento es una función beta y está ha - Para obtener más información sobre el diseño, consulte las [Restricciones de Capacidad de Almacenamiento para la Programación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). - Para obtener más información sobre un mayor desarrollo de esta función, consulte [problema de seguimiento de mejoras #1472](https://github.com/kubernetes/enhancements/issues/1472). -- Aprender sobre [Scheduler de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) +- Aprender sobre [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) From 3fe43ea98af1917a7a57c8a2524d18ecdca7fe7c Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:54:17 -0500 Subject: [PATCH 023/254] Update content/es/docs/concepts/storage/storage-capacity.md thank you! Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index e210b058a7..b1e0c089aa 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -36,7 +36,7 @@ Hay dos extensiones de API para esta función: El Planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: -- la puerta de la característica `CSIStorageCapacity` es `true`, +- la Feature Gate de `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, - ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), From a6b8f76520613ae237f28231aa66126b341b918c Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:55:18 -0500 Subject: [PATCH 024/254] Update content/es/docs/concepts/storage/storage-capacity.md Thanks! Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index b1e0c089aa..686be63120 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -38,8 +38,7 @@ El Planificador de Kubernetes utiliza la información sobre la capacidad de alma - la Feature Gate de `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, -- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding - mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el [modo de enlace de volumen](/docs/concepts/storage/storage-classes/#volume-binding-mode) `WaitForFirstConsumer` , y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. From 1b1a5b30b4be7baf327dc9af3fdd25d2b76e666a Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:55:56 -0500 Subject: [PATCH 025/254] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 686be63120..fb24479eb7 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -56,7 +56,7 @@ Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el Planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. -## Limitationes +## Limitaciones El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. From c7a7a60a0ddb9b099fdea4de6a36b730459ec29f Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 16:56:06 -0500 Subject: [PATCH 026/254] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index fb24479eb7..bdadd7d541 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -58,7 +58,7 @@ Debido a que Kubernetes pudo haber elegido un nodo basándose en información de ## Limitaciones -El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el programador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. +El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. Una situación en la que la programación puede fallar de forma permanente es cuando un Pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. From 951f21f79239baee9785ff858a56863e6cb7ffe2 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Tue, 30 Nov 2021 17:07:59 -0500 Subject: [PATCH 027/254] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Victor Morales --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index bdadd7d541..d28a6ca149 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -15,7 +15,7 @@ La capacidad de almacenamiento es limitada y puede variar según el nodo en el q {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} -Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el programador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. +Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el planificador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. El seguimiento de la capacidad de almacenamiento es compatible con los controladores de la {{< glossary_tooltip text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y From 392db486a363100717d76064e758b1d8043a9bae Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Thu, 2 Dec 2021 14:53:32 +0900 Subject: [PATCH 028/254] Create 2020-12-02-dont-panic-kubernetes-and-docker.md --- ...-12-02-dont-panic-kubernetes-and-docker.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md new file mode 100644 index 0000000000..17c9003c28 --- /dev/null +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -0,0 +1,46 @@ +--- +layout: blog +title: "Don't Panic: Kubernetes and Docker" +date: 2020-12-02 +slug: dont-panic-kubernetes-and-docker +--- + +**著者:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas + +Kubernetesはv1.20より新しいバージョンで、コンテナランタイムとして[Dockerをサポートしません](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)。 + +**パニックを起こす必要はありません。これはそれほど抜本的なものではないのです。** + +概要: RuntimeとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているRuntimeを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたImageはこれからも、今までもそうだったように、みなさんのClusterで使用可能です。 + +もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたImageはKubernetesクラスタ上でこれからも動作可能なのです。 + +もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、Workerノードがサポート対象のRuntimeを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 +もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダと確認し、アップグレードのための適切なテストと計画を立ててください。 + +もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。（Loggingなど） + +## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 ## +ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスタの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります（他にはcontainerdやCRI-Oが挙げられます）が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 + +お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。 +このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。 +ここで、containerdがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われる方もいるでしょう。 + +DockerはCRI（[Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)）に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。 +しかし、これは世界の終わりでありません、心配しないでください。みなさんはContainer runtimeをDockerから他のサポート対象であるContainer runtimeに切り替えるだけでよいのです。 + +1つ注意すべきことは、クラスタで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。 + +## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。 ## + +この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。 +みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスタの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。 +これがコンテナの仕様について、共通の仕様を策定している理由なのです。 + +さて、この変更は決定しています。いくつかの問題は発生するかもしてませんが、決して壊滅的なものではなく、ほとんどの場合は良い変化となるでしょう。Kubernetesをどのように使用しているかによりますが、この変更が特に何の影響も及ぼさない人もいるでしょうし、影響がとても少ない場合もあります。長期的に見れば、物事を簡単にするのに役立つものです。 +もし、この問題がまだわかりにくいとしても、心配しないでください。Kubernetesでは多くのものが変化しており、その全てに完璧に精通している人など存在しません。 +経験の多寡や難易度にかかわらず、どんなことでも質問してください。我々の目標は、全ての人が将来の変化について、可能な限りの知識と理解を得られることです。 +このブログが多くの質問の答えとなり、不安を和らげることができればと願っています。 + +別の情報をお探してあれば、こちらを参照してください。 [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). From f8ef8197012f78098236d4d99a64c6c8e09f4ead Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:02:46 +0900 Subject: [PATCH 029/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 17c9003c28..e476815eaf 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -11,7 +11,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ **パニックを起こす必要はありません。これはそれほど抜本的なものではないのです。** -概要: RuntimeとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているRuntimeを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたImageはこれからも、今までもそうだったように、みなさんのClusterで使用可能です。 +概要: ランタイムとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているランタイムを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたイメージはこれからも、今までもそうだったように、みなさんのクラスターで使用可能です。 もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたImageはKubernetesクラスタ上でこれからも動作可能なのです。 From 629b319f7e082792dc430bdbf73a9a1943182fd6 Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:02:50 +0900 Subject: [PATCH 030/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index e476815eaf..bb1be786d0 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -18,7 +18,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、Workerノードがサポート対象のRuntimeを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダと確認し、アップグレードのための適切なテストと計画を立ててください。 -もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。（Loggingなど） +もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど) ## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 ## ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスタの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります（他にはcontainerdやCRI-Oが挙げられます）が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 From 12bbb688cd62fe469ef41f25b63db48b4d0643b5 Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:02:55 +0900 Subject: [PATCH 031/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index bb1be786d0..416ea57b9c 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -21,7 +21,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど) ## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 ## -ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスタの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります（他にはcontainerdやCRI-Oが挙げられます）が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 +ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。 このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。 From f41a5c99e3c6fb66b8726b2e76364c8923d98fb2 Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:03:06 +0900 Subject: [PATCH 032/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 416ea57b9c..76787a27e3 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -27,7 +27,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。 ここで、containerdがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われる方もいるでしょう。 -DockerはCRI（[Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)）に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。 +DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/))に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。 しかし、これは世界の終わりでありません、心配しないでください。みなさんはContainer runtimeをDockerから他のサポート対象であるContainer runtimeに切り替えるだけでよいのです。 1つ注意すべきことは、クラスタで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。 From c91f9a7fe4820a524aec39643b4cc4fa8994b8fe Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:03:11 +0900 Subject: [PATCH 033/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 76787a27e3..7e6eb2baeb 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -30,7 +30,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/))に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。 しかし、これは世界の終わりでありません、心配しないでください。みなさんはContainer runtimeをDockerから他のサポート対象であるContainer runtimeに切り替えるだけでよいのです。 -1つ注意すべきことは、クラスタで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。 +1つ注意すべきことは、クラスターで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。 ## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。 ## From 4a6f5efcf433e21dcd844622e0b4abdde69f2bd4 Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:03:15 +0900 Subject: [PATCH 034/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 7e6eb2baeb..6d73c2cab5 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -43,4 +43,4 @@ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/co 経験の多寡や難易度にかかわらず、どんなことでも質問してください。我々の目標は、全ての人が将来の変化について、可能な限りの知識と理解を得られることです。 このブログが多くの質問の答えとなり、不安を和らげることができればと願っています。 -別の情報をお探してあれば、こちらを参照してください。 [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). +別の情報をお探してあれば、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)を参照してください。 From 8ae8a16ffcafe882c0d81a232d7257ad5876658c Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:03:22 +0900 Subject: [PATCH 035/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 6d73c2cab5..5a6e102cb7 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -20,7 +20,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど) -## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 ## +## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。 From 436d1d8d13f2b58a2ce2cd97e09a766b8109b3ab Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:03:28 +0900 Subject: [PATCH 036/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 5a6e102cb7..5cbfbef226 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -16,7 +16,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたImageはKubernetesクラスタ上でこれからも動作可能なのです。 もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、Workerノードがサポート対象のRuntimeを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 -もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダと確認し、アップグレードのための適切なテストと計画を立ててください。 +もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。 もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど) From 61899b0e8642fcf5a951860a2e9d121cd996876d Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:03:32 +0900 Subject: [PATCH 037/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 5cbfbef226..fdb197a31d 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -32,7 +32,7 @@ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/co 1つ注意すべきことは、クラスターで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。 -## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。 ## +## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。 この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。 みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスタの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。 From b7761afb7df67eac33c9d241bdb77c571e79ad3a Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 17:26:56 +0900 Subject: [PATCH 038/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index fdb197a31d..679e0f53b7 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -13,7 +13,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ 概要: ランタイムとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているランタイムを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたイメージはこれからも、今までもそうだったように、みなさんのクラスターで使用可能です。 -もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたImageはKubernetesクラスタ上でこれからも動作可能なのです。 +もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスタ上でこれからも動作可能なのです。 もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、Workerノードがサポート対象のRuntimeを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。 From e328d0b731ede209af2fdd3999161510cc862337 Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 17:27:06 +0900 Subject: [PATCH 039/254] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 679e0f53b7..09e2a5592e 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -15,7 +15,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスタ上でこれからも動作可能なのです。 -もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、Workerノードがサポート対象のRuntimeを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 +もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、ワーカーノードがサポート対象のランタイムを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。 もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど) From 5ab064ceea06ab56c85cfc19a395fd679643a659 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Tue, 12 Oct 2021 23:21:17 +0100 Subject: [PATCH 040/254] Tidy resource management task pages MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Revise tasks within “Manage Memory, CPU, and API Resources”: - reword to avoid implying that API clients can create a container (you can, but its done by creating a Pod) - call a manifest a manifest - use tooltips where relevant - link to new API reference not the old one - other improvements --- .../cpu-constraint-namespace.md | 64 +++++++------- .../manage-resources/cpu-default-namespace.md | 83 ++++++++++++------- .../memory-constraint-namespace.md | 80 +++++++++--------- .../memory-default-namespace.md | 73 ++++++++++------ .../quota-memory-cpu-namespace.md | 53 +++++++----- .../manage-resources/quota-pod-namespace.md | 27 +++--- 6 files changed, 225 insertions(+), 155 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index e3758e05c9..d640195efc 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -7,9 +7,10 @@ weight: 40 -This page shows how to set minimum and maximum values for the CPU resources used by Containers -and Pods in a namespace. You specify minimum and maximum CPU values in a -[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) +This page shows how to set minimum and maximum values for the CPU resources used by containers +and Pods in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. You specify minimum +and maximum CPU values in a +[LimitRange](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created in the namespace. @@ -19,11 +20,13 @@ in the namespace. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -Your cluster must have at least 1 CPU available for use to run the task examples. +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. +Your cluster must have at least 1.0 CPU available for use to run the task examples. +See [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu) +to learn what Kubernetes means by “1 CPU”. @@ -39,7 +42,7 @@ kubectl create namespace constraints-cpu-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange: +Here's an example manifest for a LimitRange: {{< codenew file="admin/resource/cpu-constraints.yaml" >}} @@ -72,15 +75,15 @@ limits: type: Container ``` -Now whenever a Container is created in the constraints-cpu-example namespace, Kubernetes -performs these steps: +Now whenever you create a Pod in the constraints-cpu-example namespace (or some other client +of the Kubernetes API creates an equivalent Pod), Kubernetes performs these steps: -* If the Container does not specify its own CPU request and limit, assign the default -CPU request and limit to the Container. +* If any container in that Pod does not specify its own CPU request and limit, the control plane + assigns the default CPU request and limit to that container. -* Verify that the Container specifies a CPU request that is greater than or equal to 200 millicpu. +* Verify that every container in that Pod specifies a CPU request that is greater than or equal to 200 millicpu. -* Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu. +* Verify that every container in that Pod specifies a CPU limit that is less than or equal to 800 millicpu. {{< note >}} When creating a `LimitRange` object, you can specify limits on huge-pages @@ -88,7 +91,7 @@ or GPUs as well. However, when both `default` and `defaultRequest` are specified on these resources, the two values must be the same. {{< /note >}} -Here's the configuration file for a Pod that has one Container. The Container manifest +Here's a manifest for a Pod that has one container. The container manifest specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the minimum and maximum CPU constraints imposed by the LimitRange. @@ -100,7 +103,7 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example ``` -Verify that the Pod's Container is running: +Verify that the Pod is running and that its container is healthy: ```shell kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example @@ -112,7 +115,7 @@ View detailed information about the Pod: kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-example ``` -The output shows that the Container has a CPU request of 500 millicpu and CPU limit +The output shows that the Pod's only container has a CPU request of 500 millicpu and CPU limit of 800 millicpu. These satisfy the constraints imposed by the LimitRange. ```yaml @@ -131,7 +134,7 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example ## Attempt to create a Pod that exceeds the maximum CPU constraint -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. The container specifies a CPU request of 500 millicpu and a cpu limit of 1.5 cpu. {{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}} @@ -142,8 +145,8 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example ``` -The output shows that the Pod does not get created, because the Container specifies a CPU limit that is -too large: +The output shows that the Pod does not get created, because it defines an unacceptable container. +That container is not acceptable because it specifies a CPU limit that is too large: ``` Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml": @@ -152,7 +155,7 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8 ## Attempt to create a Pod that does not meet the minimum CPU request -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. The container specifies a CPU request of 100 millicpu and a CPU limit of 800 millicpu. {{< codenew file="admin/resource/cpu-constraints-pod-3.yaml" >}} @@ -163,8 +166,9 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example ``` -The output shows that the Pod does not get created, because the Container specifies a CPU -request that is too small: +The output shows that the Pod does not get created, because it defines an unacceptable container. +That container is not acceptable because it specifies a CPU limit that is lower than the +enforced minimum: ``` Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml": @@ -173,8 +177,8 @@ pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 2 ## Create a Pod that does not specify any CPU request or limit -Here's the configuration file for a Pod that has one Container. The Container does not -specify a CPU request, and it does not specify a CPU limit. +Here's a manifest for a Pod that has one container. The container does not +specify a CPU request, nor does it specify a CPU limit. {{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}} @@ -190,8 +194,9 @@ View detailed information about the Pod: kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml ``` -The output shows that the Pod's Container has a CPU request of 800 millicpu and a CPU limit of 800 millicpu. -How did the Container get those values? +The output shows that the Pod's single container has a CPU request of 800 millicpu and a +CPU limit of 800 millicpu. +How did that container get those values? ```yaml resources: @@ -201,11 +206,12 @@ resources: cpu: 800m ``` -Because your Container did not specify its own CPU request and limit, it was given the +Because that container did not specify its own CPU request and limit, the control plane +applied the [default CPU request and limit](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -from the LimitRange. +from the LimitRange for this namespace. -At this point, your Container might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. +At this point, your Pod might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. Delete your Pod: diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index 0156d67e4d..d58baca108 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -6,19 +6,29 @@ weight: 20 -This page shows how to configure default CPU requests and limits for a namespace. -A Kubernetes cluster can be divided into namespaces. If a Container is created in a namespace -that has a default CPU limit, and the Container does not specify its own CPU limit, then -the Container is assigned the default CPU limit. Kubernetes assigns a default CPU request -under certain conditions that are explained later in this topic. +This page shows how to configure default CPU requests and limits for a +{{< glossary_tooltip text="namespace" term_id="namespace" >}}. +A Kubernetes cluster can be divided into namespaces. If you create a Pod within a +namespace that has a default CPU +[limit](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits), and any container in that Pod does not specify +its own CPU limit, then the +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} assigns the default +CPU limit to that container. +Kubernetes assigns a default CPU +[request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits), +but only under certain conditions that are explained later in this page. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. + +If you're not already familiar with what Kubernetes means by 1.0 CPU, +read [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu). @@ -33,8 +43,8 @@ kubectl create namespace default-cpu-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange object. The configuration specifies -a default CPU request and a default CPU limit. +Here's a manifest for an example {{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}. +The manifest specifies a default CPU request and a default CPU limit. {{< codenew file="admin/resource/cpu-defaults.yaml" >}} @@ -44,12 +54,12 @@ Create the LimitRange in the default-cpu-example namespace: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example ``` -Now if a Container is created in the default-cpu-example namespace, and the -Container does not specify its own values for CPU request and CPU limit, -the Container is given a default CPU request of 0.5 and a default +Now if you create a Pod in the default-cpu-example namespace, and any container +in that Pod does not specify its own values for CPU request and CPU limit, +then the control plane applies default values: a CPU request of 0.5 and a default CPU limit of 1. -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container does not specify a CPU request and limit. {{< codenew file="admin/resource/cpu-defaults-pod.yaml" >}} @@ -66,8 +76,9 @@ View the Pod's specification: kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example ``` -The output shows that the Pod's Container has a CPU request of 500 millicpus and -a CPU limit of 1 cpu. These are the default values specified by the LimitRange. +The output shows that the Pod's only container has a CPU request of 500m `cpu` +(which you can read as “500 millicpu”), and a CPU limit of 1 `cpu`. +These are the default values specified by the LimitRange. ```shell containers: @@ -81,9 +92,9 @@ containers: cpu: 500m ``` -## What if you specify a Container's limit, but not its request? +## What if you specify a container's limit, but not its request? -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container specifies a CPU limit, but not a request: {{< codenew file="admin/resource/cpu-defaults-pod-2.yaml" >}} @@ -95,14 +106,15 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example ``` -View the Pod specification: +View the [specification](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status) +of the Pod that you created: ``` kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example ``` -The output shows that the Container's CPU request is set to match its CPU limit. -Notice that the Container was not assigned the default CPU request value of 0.5 cpu. +The output shows that the container's CPU request is set to match its CPU limit. +Notice that the container was not assigned the default CPU request value of 0.5 `cpu`: ``` resources: @@ -112,9 +124,9 @@ resources: cpu: "1" ``` -## What if you specify a Container's request, but not its limit? +## What if you specify a container's request, but not its limit? -Here's the configuration file for a Pod that has one Container. The Container +Here's an example manifest for a Pod that has one container. The container specifies a CPU request, but not a limit: {{< codenew file="admin/resource/cpu-defaults-pod-3.yaml" >}} @@ -125,15 +137,16 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example ``` -View the Pod specification: +View the specification of the Pod that you created: ``` kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example ``` -The output shows that the Container's CPU request is set to the value specified in the -Container's configuration file. The Container's CPU limit is set to 1 cpu, which is the -default CPU limit for the namespace. +The output shows that the container's CPU request is set to the value you specified at +the time you created the Pod (in other words: it matches the manifest). +However, the same container's CPU limit is set to 1 `cpu`, which is the default CPU limit +for that namespace. ``` resources: @@ -145,16 +158,22 @@ resources: ## Motivation for default CPU limits and requests -If your namespace has a -[resource quota](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/), +If your namespace has a CPU {{< glossary_tooltip text="resource quota" term_id="resource-quota" >}} +configured, it is helpful to have a default value in place for CPU limit. -Here are two of the restrictions that a resource quota imposes on a namespace: +Here are two of the restrictions that a CPU resource quota imposes on a namespace: -* Every Container that runs in the namespace must have its own CPU limit. -* The total amount of CPU used by all Containers in the namespace must not exceed a specified limit. +* For every Pod that runs in the namespace, each of its containers must have a CPU limit. +* CPU limits apply a resource reservation on the node where the Pod in question is scheduled. + The total amount of CPU that is reserved for use by all Pods in the namespace must not + exceed a specified limit. + +When you add a LimitRange: + +If any Pod in that namespace that includes a container does not specify its own CPU limit, +the control plane applies the default CPU limit to that container, and the Pod can be +allowed to run in a namespace that is restricted by a CPU ResourceQuota. -If a Container does not specify its own CPU limit, it is given the default limit, and then -it can be allowed to run in a namespace that is restricted by a quota. ## Clean up diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index de80b80ce3..8db50fb4d1 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -7,7 +7,7 @@ weight: 30 -This page shows how to set minimum and maximum values for memory used by Containers +This page shows how to set minimum and maximum values for memory used by containers running in a namespace. You specify minimum and maximum memory values in a [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) object. If a Pod does not meet the constraints imposed by the LimitRange, @@ -15,16 +15,14 @@ it cannot be created in the namespace. - ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -Each node in your cluster must have at least 1 GiB of memory. - +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. +Each node in your cluster must have at least 1 GiB of memory available for Pods. @@ -39,7 +37,7 @@ kubectl create namespace constraints-mem-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange: +Here's an example manifest for a LimitRange: {{< codenew file="admin/resource/memory-constraints.yaml" >}} @@ -72,18 +70,19 @@ file for the LimitRange, they were created automatically. type: Container ``` -Now whenever a Container is created in the constraints-mem-example namespace, Kubernetes +Now whenever you define a Pod within the constraints-mem-example namespace, Kubernetes performs these steps: -* If the Container does not specify its own memory request and limit, assign the default -memory request and limit to the Container. +* If any container in that Pod does not specify its own memory request and limit, assign +the default memory request and limit to that container. -* Verify that the Container has a memory request that is greater than or equal to 500 MiB. +* Verify that every container in that Pod requests at least 500 MiB of memory. -* Verify that the Container has a memory limit that is less than or equal to 1 GiB. +* Verify that every container in that Pod requests no more than 1024 MiB (1 GiB) + of memory. -Here's the configuration file for a Pod that has one Container. The Container manifest -specifies a memory request of 600 MiB and a memory limit of 800 MiB. These satisfy the +Here's a manifest for a Pod that has one container. Within the Pod spec, the sole +container specifies a memory request of 600 MiB and a memory limit of 800 MiB. These satisfy the minimum and maximum memory constraints imposed by the LimitRange. {{< codenew file="admin/resource/memory-constraints-pod.yaml" >}} @@ -94,7 +93,7 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example ``` -Verify that the Pod's Container is running: +Verify that the Pod is running and that its container is healthy: ```shell kubectl get pod constraints-mem-demo --namespace=constraints-mem-example @@ -106,8 +105,9 @@ View detailed information about the Pod: kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example ``` -The output shows that the Container has a memory request of 600 MiB and a memory limit -of 800 MiB. These satisfy the constraints imposed by the LimitRange. +The output shows that the container within that Pod has a memory request of 600 MiB and +a memory limit of 800 MiB. These satisfy the constraints imposed by the LimitRange for +this namespace: ```yaml resources: @@ -125,7 +125,7 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example ## Attempt to create a Pod that exceeds the maximum memory constraint -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. The container specifies a memory request of 800 MiB and a memory limit of 1.5 GiB. {{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}} @@ -136,8 +136,8 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example ``` -The output shows that the Pod does not get created, because the Container specifies a memory limit that is -too large: +The output shows that the Pod does not get created, because it defines a container that +requests more memory than is allowed: ``` Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml": @@ -146,7 +146,7 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i ## Attempt to create a Pod that does not meet the minimum memory request -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. That container specifies a memory request of 100 MiB and a memory limit of 800 MiB. {{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}} @@ -157,8 +157,8 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example ``` -The output shows that the Pod does not get created, because the Container specifies a memory -request that is too small: +The output shows that the Pod does not get created, because it defines a container +that requests less memory than the enforced minimum: ``` Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml": @@ -167,9 +167,7 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i ## Create a Pod that does not specify any memory request or limit - - -Here's the configuration file for a Pod that has one Container. The Container does not +Here's a manifest for a Pod that has one container. The container does not specify a memory request, and it does not specify a memory limit. {{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}} @@ -182,12 +180,12 @@ kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4 View detailed information about the Pod: -``` +```shell kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml ``` -The output shows that the Pod's Container has a memory request of 1 GiB and a memory limit of 1 GiB. -How did the Container get those values? +The output shows that the Pod's only container has a memory request of 1 GiB and a memory limit of 1 GiB. +How did that container get those values? ``` resources: @@ -197,11 +195,20 @@ resources: memory: 1Gi ``` -Because your Container did not specify its own memory request and limit, it was given the +Because your Pod did not define any memory request and limit for that container, the cluster +applied a [default memory request and limit](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) from the LimitRange. -At this point, your Container might be running or it might not be running. Recall that a prerequisite +This means that the definition of that Pod shows those values. You can check it using +`kubectl describe`: + +```shell +# Look for the "Requests:" section of the output +kubectl describe pod constraints-mem-demo-4 --namespace=constraints-mem-example +``` + +At this point, your Pod might be running or it might not be running. Recall that a prerequisite for this task is that your Nodes have at least 1 GiB of memory. If each of your Nodes has only 1 GiB of memory, then there is not enough allocatable memory on any Node to accommodate a memory request of 1 GiB. If you happen to be using Nodes with 2 GiB of memory, then you probably have @@ -209,7 +216,7 @@ enough space to accommodate the 1 GiB request. Delete your Pod: -``` +```shell kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example ``` @@ -224,12 +231,12 @@ Pods that were created previously. As a cluster administrator, you might want to impose restrictions on the amount of memory that Pods can use. For example: -* Each Node in a cluster has 2 GB of memory. You do not want to accept any Pod that requests -more than 2 GB of memory, because no Node in the cluster can support the request. +* Each Node in a cluster has 2 GiB of memory. You do not want to accept any Pod that requests +more than 2 GiB of memory, because no Node in the cluster can support the request. * A cluster is shared by your production and development departments. -You want to allow production workloads to consume up to 8 GB of memory, but -you want development workloads to be limited to 512 MB. You create separate namespaces +You want to allow production workloads to consume up to 8 GiB of memory, but +you want development workloads to be limited to 512 MiB. You create separate namespaces for production and development, and you apply memory constraints to each namespace. ## Clean up @@ -241,7 +248,6 @@ kubectl delete namespace constraints-mem-example ``` - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index d2f4790abc..1d0fb3eb05 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -6,17 +6,28 @@ weight: 10 -This page shows how to configure default memory requests and limits for a namespace. -If a Container is created in a namespace that has a default memory limit, and the Container -does not specify its own memory limit, then the Container is assigned the default memory limit. +This page shows how to configure default memory requests and limits for a +{{< glossary_tooltip text="namespace" term_id="namespace" >}}. + +A Kubernetes cluster can be divided into namespaces. Once you have a namespace that +that has a default memory +[limit](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits), +and you then try to create a Pod with a container that does not specify its own memory +limit its own memory limit, then the +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} assigns the default +memory limit to that container. + Kubernetes assigns a default memory request under certain conditions that are explained later in this topic. + ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + +You must have access to create namespaces in your cluster. Each node in your cluster must have at least 2 GiB of memory. @@ -35,8 +46,9 @@ kubectl create namespace default-mem-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange object. The configuration specifies -a default memory request and a default memory limit. +Here's a manifest for an example {{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}. +The manifest specifies a default memory +request and a default memory limit. {{< codenew file="admin/resource/memory-defaults.yaml" >}} @@ -46,12 +58,13 @@ Create the LimitRange in the default-mem-example namespace: kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example ``` -Now if a Container is created in the default-mem-example namespace, and the -Container does not specify its own values for memory request and memory limit, -the Container is given a default memory request of 256 MiB and a default -memory limit of 512 MiB. +Now if you create a Pod in the default-mem-example namespace, and any container +within that Pod does not specify its own values for memory request and memory limit, +then the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} +applies default values: a memory request of 256MiB and a memory limit of 512MiB. -Here's the configuration file for a Pod that has one Container. The Container + +Here's an example manifest for a Pod that has one container. The container does not specify a memory request and limit. {{< codenew file="admin/resource/memory-defaults-pod.yaml" >}} @@ -68,7 +81,7 @@ View detailed information about the Pod: kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example ``` -The output shows that the Pod's Container has a memory request of 256 MiB and +The output shows that the Pod's container has a memory request of 256 MiB and a memory limit of 512 MiB. These are the default values specified by the LimitRange. ```shell @@ -89,9 +102,9 @@ Delete your Pod: kubectl delete pod default-mem-demo --namespace=default-mem-example ``` -## What if you specify a Container's limit, but not its request? +## What if you specify a container's limit, but not its request? -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container specifies a memory limit, but not a request: {{< codenew file="admin/resource/memory-defaults-pod-2.yaml" >}} @@ -109,8 +122,8 @@ View detailed information about the Pod: kubectl get pod default-mem-demo-2 --output=yaml --namespace=default-mem-example ``` -The output shows that the Container's memory request is set to match its memory limit. -Notice that the Container was not assigned the default memory request value of 256Mi. +The output shows that the container's memory request is set to match its memory limit. +Notice that the container was not assigned the default memory request value of 256Mi. ``` resources: @@ -120,9 +133,9 @@ resources: memory: 1Gi ``` -## What if you specify a Container's request, but not its limit? +## What if you specify a container's request, but not its limit? -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container specifies a memory request, but not a limit: {{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}} @@ -139,9 +152,9 @@ View the Pod's specification: kubectl get pod default-mem-demo-3 --output=yaml --namespace=default-mem-example ``` -The output shows that the Container's memory request is set to the value specified in the -Container's configuration file. The Container's memory limit is set to 512Mi, which is the -default memory limit for the namespace. +The output shows that the container's memory request is set to the value specified in the +container's manifest. The container is limited to use no more than 512MiB of +memory, which matches the default memory limit for the namespace. ``` resources: @@ -153,15 +166,23 @@ resources: ## Motivation for default memory limits and requests -If your namespace has a resource quota, +If your namespace has a memory {{< glossary_tooltip text="resource quota" term_id="resource-quota" >}} +configured, it is helpful to have a default value in place for memory limit. Here are two of the restrictions that a resource quota imposes on a namespace: -* Every Container that runs in the namespace must have its own memory limit. -* The total amount of memory used by all Containers in the namespace must not exceed a specified limit. +* For every Pod that runs in the namespace, the Pod and each of its containers must have a memory limit. + (If you specify a memory limit for every container in a Pod, Kubernetes can infer the Pod-level memory + limit by adding up the limits for its containers). +* CPU limits apply a resource reservation on the node where the Pod in question is scheduled. + The total amount of memory reserved for all Pods in the namespace must not exceed a specified limit. +* The total amount of memory actually used by all Pods in the namespace must also not exceed a specified limit. -If a Container does not specify its own memory limit, it is given the default limit, and then -it can be allowed to run in a namespace that is restricted by a quota. +When you add a LimitRange: + +If any Pod in that namespace that includes a container does not specify its own memory limit, +the control plane applies the default memory limit to that container, and the Pod can be +allowed to run in a namespace that is restricted by a memory ResourceQuota. ## Clean up diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index 4869c35e06..290cac909f 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -8,8 +8,9 @@ weight: 50 This page shows how to set quotas for the total amount memory and CPU that -can be used by all Containers running in a namespace. You specify quotas in a -[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) +can be used by all Pods running in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +You specify quotas in a +[ResourceQuota](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) object. @@ -17,14 +18,13 @@ object. ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +You must have access to create namespaces in your cluster. Each node in your cluster must have at least 1 GiB of memory. - - ## Create a namespace @@ -38,7 +38,7 @@ kubectl create namespace quota-mem-cpu-example ## Create a ResourceQuota -Here is the configuration file for a ResourceQuota object: +Here is a manifest for an example ResourceQuota: {{< codenew file="admin/resource/quota-mem-cpu.yaml" >}} @@ -56,15 +56,18 @@ kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --outpu The ResourceQuota places these requirements on the quota-mem-cpu-example namespace: -* Every Container must have a memory request, memory limit, cpu request, and cpu limit. -* The memory request total for all Containers must not exceed 1 GiB. -* The memory limit total for all Containers must not exceed 2 GiB. -* The CPU request total for all Containers must not exceed 1 cpu. -* The CPU limit total for all Containers must not exceed 2 cpu. +* For every Pod in the namespace, each container must have a memory request, memory limit, cpu request, and cpu limit. +* The memory request total for all Pods in that namespace must not exceed 1 GiB. +* The memory limit total for all Pods in that namespace must not exceed 2 GiB. +* The CPU request total for all Pods in that namespace must not exceed 1 cpu. +* The CPU limit total for all Pods in that namespace must not exceed 2 cpu. + +See [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu) +to learn what Kubernetes means by “1 CPU”. ## Create a Pod -Here is the configuration file for a Pod: +Here is a manifest for an example Pod: {{< codenew file="admin/resource/quota-mem-cpu-pod.yaml" >}} @@ -75,15 +78,15 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example ``` -Verify that the Pod's Container is running: +Verify that the Pod is running and that its (only) container is healthy: -``` +```shell kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example ``` Once again, view detailed information about the ResourceQuota: -``` +```shell kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml ``` @@ -105,15 +108,22 @@ status: requests.memory: 600Mi ``` +If you have the `jq` tool, you can also query (using [JSONPath](/docs/reference/kubectl/jsonpath/)) +for just the `used` values, **and** pretty-print that that of the output. For example: + +```shell +kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example -o jsonpath='{ .status.used }' | jq . +``` + ## Attempt to create a second Pod -Here is the configuration file for a second Pod: +Here is a manifest for a second Pod: {{< codenew file="admin/resource/quota-mem-cpu-pod-2.yaml" >}} -In the configuration file, you can see that the Pod has a memory request of 700 MiB. +In the manifest, you can see that the Pod has a memory request of 700 MiB. Notice that the sum of the used memory request and this new memory -request exceeds the memory request quota. 600 MiB + 700 MiB > 1 GiB. +request exceeds the memory request quota: 600 MiB + 700 MiB > 1 GiB. Attempt to create the Pod: @@ -133,11 +143,12 @@ requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests. ## Discussion As you have seen in this exercise, you can use a ResourceQuota to restrict -the memory request total for all Containers running in a namespace. +the memory request total for all Pods running in a namespace. You can also restrict the totals for memory limit, cpu request, and cpu limit. -If you want to restrict individual Containers, instead of totals for all Containers, use a -[LimitRange](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). +Instead of managing total resource use within a namespace, you might want to restrict +individual Pods, or the containers in those Pods. To achieve that kind of limiting, use a +[LimitRange](/docs/concepts/policy/limit-range/). ## Clean up diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index b0485f2b45..5db78858d5 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -8,8 +8,8 @@ weight: 60 This page shows how to set a quota for the total number of Pods that can run -in a namespace. You specify quotas in a -[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) +in a {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. You specify quotas in a +[ResourceQuota](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) object. @@ -18,10 +18,9 @@ object. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. @@ -36,7 +35,7 @@ kubectl create namespace quota-pod-example ## Create a ResourceQuota -Here is the configuration file for a ResourceQuota object: +Here is an example manifest for a ResourceQuota: {{< codenew file="admin/resource/quota-pod.yaml" >}} @@ -66,11 +65,12 @@ status: pods: "0" ``` -Here is the configuration file for a Deployment: +Here is an example manifest for a {{< glossary_tooltip term_id="deployment" >}}: {{< codenew file="admin/resource/quota-pod-deployment.yaml" >}} -In the configuration file, `replicas: 3` tells Kubernetes to attempt to create three Pods, all running the same application. +In that manifest, `replicas: 3` tells Kubernetes to attempt to create three new Pods, all +running the same application. Create the Deployment: @@ -85,7 +85,7 @@ kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yam ``` The output shows that even though the Deployment specifies three replicas, only two -Pods were created because of the quota. +Pods were created because of the quota you defined earlier: ```yaml spec: @@ -95,11 +95,18 @@ spec: status: availableReplicas: 2 ... -lastUpdateTime: 2017-07-07T20:57:05Z +lastUpdateTime: 2021-04-02T20:57:05Z message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden: exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2' ``` +### Choice of resource + +In this task you have defined a ResourceQuota that limited the total number of Pods, but +you could also limit the total number of other kinds of object. For example, you +might decide to limit how many {{< glossary_tooltip text="CronJobs" term_id="cronjob" >}} +that can live in a single namespace. + ## Clean up Delete your namespace: From 3dd1eb11213f7224d3ee1db68e3e0fb6e244169f Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Tue, 12 Oct 2021 23:35:07 +0100 Subject: [PATCH 041/254] Add descriptions to tasks --- .../manage-resources/cpu-constraint-namespace.md | 3 +++ .../manage-resources/cpu-default-namespace.md | 3 +++ .../manage-resources/memory-constraint-namespace.md | 3 +++ .../manage-resources/memory-default-namespace.md | 3 +++ .../manage-resources/quota-memory-cpu-namespace.md | 2 ++ .../administer-cluster/manage-resources/quota-pod-namespace.md | 2 ++ 6 files changed, 16 insertions(+) diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index d640195efc..bb472ed647 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -2,6 +2,9 @@ title: Configure Minimum and Maximum CPU Constraints for a Namespace content_type: task weight: 40 +description: >- + Define a range of valid CPU resource limits for a namespace, so that every new Pod + in that namespace falls within the range you configure. --- diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index d58baca108..14d50aa4d7 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -2,6 +2,9 @@ title: Configure Default CPU Requests and Limits for a Namespace content_type: task weight: 20 +description: >- + Define a default CPU resource limits for a namespace, so that every new Pod + in that namespace has a CPU resource limit configured. --- diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index 8db50fb4d1..3efd899075 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -2,6 +2,9 @@ title: Configure Minimum and Maximum Memory Constraints for a Namespace content_type: task weight: 30 +description: >- + Define a range of valid memory resource limits for a namespace, so that every new Pod + in that namespace falls within the range you configure. --- diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index 1d0fb3eb05..ff2a4082c2 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -2,6 +2,9 @@ title: Configure Default Memory Requests and Limits for a Namespace content_type: task weight: 10 +description: >- + Define a default memory resource limit for a namespace, so that every new Pod + in that namespace has a memory resource limit configured. --- diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index 290cac909f..161c3a12a9 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -2,6 +2,8 @@ title: Configure Memory and CPU Quotas for a Namespace content_type: task weight: 50 +description: >- + Define overall memory and CPU resource limits for a namespace. --- diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index 5db78858d5..3cdb1a9f24 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -2,6 +2,8 @@ title: Configure a Pod Quota for a Namespace content_type: task weight: 60 +description: >- + Restrict how many Pods you can create within a namespace. --- From 1fb9324fc3ff2d6740bca85ec936efc2ab547bed Mon Sep 17 00:00:00 2001 From: ystkfujii Date: Wed, 15 Dec 2021 14:32:10 +0900 Subject: [PATCH 042/254] remove the section on dockershim --- content/en/docs/concepts/containers/runtime-class.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index 96858d32af..9e7efa0a46 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -107,11 +107,6 @@ to the behavior when the RuntimeClass feature is disabled. For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/production-environment/container-runtimes/). -#### dockershim - -RuntimeClasses with dockershim must set the runtime handler to `docker`. Dockershim does not support -custom configurable runtime handlers. - #### {{< glossary_tooltip term_id="containerd" >}} Runtime handlers are configured through containerd's configuration at From 19928a83fa5515a7e8188e4c7c65420b8715127f Mon Sep 17 00:00:00 2001 From: ystkfujii Date: Wed, 15 Dec 2021 21:51:06 +0900 Subject: [PATCH 043/254] Change the dockershim state to deprecation --- content/en/docs/concepts/containers/runtime-class.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index 9e7efa0a46..849cd98782 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -107,6 +107,16 @@ to the behavior when the RuntimeClass feature is disabled. For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/production-environment/container-runtimes/). +#### dockershim + +{{< feature-state for_k8s_version="v1.20" state="deprecated" >}} + +Dockershim is deprecated as of Kubernetes v1.20, and will be removed in v1.24. For more information on the deprecation, +see [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) + +RuntimeClasses with dockershim must set the runtime handler to `docker`. Dockershim does not support +custom configurable runtime handlers. + #### {{< glossary_tooltip term_id="containerd" >}} Runtime handlers are configured through containerd's configuration at From e275149785c9f08dfa0832bf18ddc2c4c778a541 Mon Sep 17 00:00:00 2001 From: KimDoubleB Date: Wed, 15 Dec 2021 23:48:47 +0900 Subject: [PATCH 044/254] Update cascade default - background --- .../_posts/2021-05-14-using-finalizers-to-control-deletion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 19d79d3f44..58533a9b80 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,7 +190,7 @@ 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=orphan 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 `background`, 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=orphan, the parent is deleted but the child still exists: From fdde76a4ce75bf13afac24a9b9c42c445c7033fc Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 20 Dec 2021 16:02:29 +0900 Subject: [PATCH 045/254] [ko] Update outdated files in dev-1.23-ko.1 M62-70 --- .../container-runtimes.md | 2 +- .../tools/kubeadm/install-kubeadm.md | 2 +- .../production-environment/tools/kubespray.md | 4 +- .../windows/user-guide-windows-containers.md | 19 +++ .../access-cluster.md | 112 +----------------- .../list-all-running-container-images.md | 4 +- .../access-cluster-services.md | 12 +- 7 files changed, 38 insertions(+), 117 deletions(-) diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 18c8a9cbb1..97be57a3c4 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -79,7 +79,7 @@ systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명 # dnf install -y grubby && \ sudo grubby \ --update-kernel=ALL \ - --args=”systemd.unified_cgroup_hierarchy=1" + --args="systemd.unified_cgroup_hierarchy=1" ``` 구성을 적용하려면 노드를 재부팅해야 한다. diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 999bfd192e..a1f9ea18ab 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -243,7 +243,7 @@ sudo mkdir -p $DOWNLOAD_DIR crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요) ```bash -CRICTL_VERSION="v1.17.0" +CRICTL_VERSION="v1.22.0" ARCH="amd64" curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md index 6e7d9c8185..598ad32609 100644 --- a/content/ko/docs/setup/production-environment/tools/kubespray.md +++ b/content/ko/docs/setup/production-environment/tools/kubespray.md @@ -38,8 +38,8 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h * 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다 * **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다 -* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다 -* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 +* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다 +* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다: diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index aaa96a4fcf..7e0ac5763b 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -1,4 +1,9 @@ --- + + + + + title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드 content_type: concept weight: 75 @@ -155,7 +160,21 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 노드셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. + {{< note >}} +`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면, +파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). +리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다. +윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을 +`windows`로 설정한다. +스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다. +컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면, +[파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는 +일반적인 쿠버네티스 메카니즘을 사용해야 한다. +`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에, +윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트, +톨러레이션 및 노드 셀렉터가 여전히 필요하다. + {{< /note >}} ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다. diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 9e7c9b4fc7..810259621a 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -214,117 +214,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ## 클러스터에서 실행되는 서비스로 접근 -이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 -쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. +이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다. -쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), -[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 -고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 -클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을 -할 수 없을 것이다. - -### 통신을 위한 방식들 - -클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다. - - - 공인 IP를 통해 서비스에 접근. - - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 - 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 - [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며, - 인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. - 해당 서비스는 자체적으로 인증을 수행하는가? - - 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 - 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다. - - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 - 접근할 필요는 없다. - - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근. - - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에 - 접근을 하려고 하거나 debugging을 하려면 이를 사용한다. - - 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다. - - HTTP/HTTPS에서만 동작한다. - - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - - 클러스터 내 노드 또는 파드에서 접근. - - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. - 해당 셸에서 다른 노드, 파드, 서비스에 연결한다. - - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 - 클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 - 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. - -### 빌트인 서비스 검색 - -일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. -`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다. - -```shell -kubectl cluster-info -``` - -결괏값은 다음과 같을 것이다. - -``` -Kubernetes master is running at https://104.197.5.247 -elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy -kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy -kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy -grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy -heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy -``` - -이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다. -예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로 -`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다. -(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) - -#### 수작업으로 apiserver proxy URL을 구축 - -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. - -당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다. - -기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` - -URL의 네임 부분에 지원되는 양식은 다음과 같다. - -* `` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. -* `:` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. -* `https::` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의) -* `https::` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. - -##### 예제들 - - * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. - * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. - -```json -{ - "cluster_name" : "kubernetes_logging", - "status" : "yellow", - "timed_out" : false, - "number_of_nodes" : 1, - "number_of_data_nodes" : 1, - "active_primary_shards" : 5, - "active_shards" : 5, - "relocating_shards" : 0, - "initializing_shards" : 0, - "unassigned_shards" : 5 -} -``` - -### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근 - -브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만 - - - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, - 당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다. - - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 - 구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다. - -## 요청 redirect +## redirect 요청하기 redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다. diff --git a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md index f777d192cd..a6f4f086d2 100644 --- a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -70,7 +70,7 @@ jsonpath에서 `.items[*]` 부분은 생략해야 하는데, 이는 명령어가 반복하여 출력할 수 있다. ```shell -kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -80,7 +80,7 @@ sort 명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다. ```shell -kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md index 8019e46c25..ab083d3690 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -86,7 +86,17 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi 위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다. `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy` -포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. +포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. 또한, 이름이 지정된 포트와 지정되지 않은 포트 모두에 대해, *port_name* 자리에 포트 번호를 기재할 수도 있다. + +기본적으로, API 서버는 서비스로의 프록시를 HTTP로 제공한다. HTTPS를 사용하려면, 서비스 이름 앞에 `https:`를 추가한다. +`http://<쿠버네티스_컨트롤_플레인_주소>/api/v1/namespaces/<네임스페이스_이름>/services/<서비스_이름>/proxy` + +URL에서 `<서비스_이름>`이 지원하는 형식은 다음과 같다. + +* `<서비스_이름>` - 기본 포트 또는 이름이 지정되지 않은 포트로 http를 사용하여 프록시 +* `<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 http를 사용하여 프록시 +* `https:<서비스_이름>:` - 기본 포트 또는 이름이 지정되지 않은 포트로 https를 사용하여 프록시(맨 끝의 콜론에 유의) +* `https:<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 https를 사용하여 프록시 ##### 예제 From a50453f75315524b3de3d0cfe097c69f0fc9aa99 Mon Sep 17 00:00:00 2001 From: Bobae Kim Date: Wed, 22 Dec 2021 13:58:19 +0900 Subject: [PATCH 046/254] Added update log Co-authored-by: Rey Lejano --- .../_posts/2021-05-14-using-finalizers-to-control-deletion.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 58533a9b80..a361c4d0be 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,7 +190,8 @@ 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 `background`, however, you can use the --cascade=orphan 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. *Update: starting with kubectl v1.20, the default for cascade is `background`.* + 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: From 1dbece9860abfcc8ce49cc548d88e10943c7e753 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Thu, 23 Dec 2021 18:49:52 +0900 Subject: [PATCH 047/254] Translate service-traffic-policy into Japanese --- .../service-traffic-policy.md | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 content/ja/docs/concepts/services-networking/service-traffic-policy.md diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md new file mode 100644 index 0000000000..c2b6b5a22e --- /dev/null +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -0,0 +1,60 @@ +--- +reviewers: +- maplain +title: サービス内部トラフィックポリシー +content_type: concept +weight: 45 +--- + + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +_サービス内部トラフィックポリシー_ を使用すると、内部トラフィック制限により、トラフィックが発信されたノード内のエンドポイントにのみ内部トラフィックをルーティングできます。 +ここでの「内部」トラフィックとは、現在のクラスターのポッドから発信されたトラフィックを指します。これは、コストを削減し、パフォーマンスを向上させるのに役立ちます。 + + + +## サービス内部トラフィックポリシーの使用 + +`ServiceInternalTrafficPolicy` +[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定すると、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 +これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 + +{{< note >}} +特定のサービスのエンドポイントがないノード上のポッドの場合、サービスに他のノードにエンドポイントがある場合でも、サービスはエンドポイントがゼロであるかのように動作します（このノードのポッドの場合）。 +{{< /note >}} + +次の例は、`.spec.internalTrafficPolicy`を`Local`に設定した場合のサービスの様子を示しています： + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + internalTrafficPolicy: Local +``` + +## 使い方 + +kube-proxyは、`spec.internalTrafficPolicy`設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 +`Local`に設定されている場合、ノードのローカルエンドポイントのみが考慮されます。 `Cluster`であるか欠落している場合、すべてのエンドポイントが考慮されます。 +`ServiceInternalTrafficPolicy`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは"Cluster"です。 + +## 制約 + +* サービスで`externalTrafficPolicy`が`Local`に設定されている場合、サービス内部トラフィックポリシーは使用されません。 同じサービスではなく、異なるサービスの同じクラスターで両方の機能を使用することができます。 + +## {{% heading "whatsnext" %}} + +* [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints)を読む +* [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)を読む +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む From 13f3c2a6db14d88aa06e48e127ef7539cee528a7 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Fri, 24 Dec 2021 13:14:14 +0900 Subject: [PATCH 048/254] Remove unnecessary spaces --- .../services-networking/service-traffic-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index c2b6b5a22e..1e14d506c0 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -11,7 +11,7 @@ weight: 45 {{< feature-state for_k8s_version="v1.21" state="alpha" >}} -_サービス内部トラフィックポリシー_ を使用すると、内部トラフィック制限により、トラフィックが発信されたノード内のエンドポイントにのみ内部トラフィックをルーティングできます。 +*サービス内部トラフィックポリシー*を使用すると、内部トラフィック制限により、トラフィックが発信されたノード内のエンドポイントにのみ内部トラフィックをルーティングできます。 ここでの「内部」トラフィックとは、現在のクラスターのポッドから発信されたトラフィックを指します。これは、コストを削減し、パフォーマンスを向上させるのに役立ちます。 @@ -19,7 +19,7 @@ _サービス内部トラフィックポリシー_ を使用すると、内部 ## サービス内部トラフィックポリシーの使用 `ServiceInternalTrafficPolicy` -[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定すると、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 +[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 {{< note >}} @@ -46,12 +46,12 @@ spec: ## 使い方 kube-proxyは、`spec.internalTrafficPolicy`設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 -`Local`に設定されている場合、ノードのローカルエンドポイントのみが考慮されます。 `Cluster`であるか欠落している場合、すべてのエンドポイントが考慮されます。 +`Local`に設定されている場合、ノードのローカルエンドポイントのみが考慮されます。`Cluster`であるか欠落している場合、すべてのエンドポイントが考慮されます。 `ServiceInternalTrafficPolicy`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは"Cluster"です。 ## 制約 -* サービスで`externalTrafficPolicy`が`Local`に設定されている場合、サービス内部トラフィックポリシーは使用されません。 同じサービスではなく、異なるサービスの同じクラスターで両方の機能を使用することができます。 +* サービスで`externalTrafficPolicy`が`Local`に設定されている場合、サービス内部トラフィックポリシーは使用されません。同じサービスではなく、異なるサービスの同じクラスターで両方の機能を使用することができます。 ## {{% heading "whatsnext" %}} From 74586913dbd43e9dd3dd81d2abf8247a93ef8328 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Fri, 24 Dec 2021 13:37:00 +0900 Subject: [PATCH 049/254] fix translation --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 1e14d506c0..7a976054d9 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -23,7 +23,7 @@ weight: 45 これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 {{< note >}} -特定のサービスのエンドポイントがないノード上のポッドの場合、サービスに他のノードにエンドポイントがある場合でも、サービスはエンドポイントがゼロであるかのように動作します（このノードのポッドの場合）。 +特定のサービスのエンドポイントがないノード上のポッドの場合、サービスに他のノードのエンドポイントがある場合でも、サービスは（このノード上のポッドの）エンドポイントがゼロであるかのように動作します。 {{< /note >}} 次の例は、`.spec.internalTrafficPolicy`を`Local`に設定した場合のサービスの様子を示しています： From 2416f95686dc597e22b5154b3d2d444e1d915ad9 Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 24 Dec 2021 14:19:19 +0900 Subject: [PATCH 050/254] done --- .../debug-application.md | 145 ++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 content/ja/docs/tasks/debug-application-cluster/debug-application.md diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md new file mode 100644 index 0000000000..f863ec3c84 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -0,0 +1,145 @@ +--- +reviewers: +- ptux +title: アプリケーションのトラブルシューティング +content_type: concept +--- + + + +このガイドは、Kubernetesにデプロイされ、正しく動作しないアプリケーションをユーザーがデバッグするためのものです。 +これは、自分のクラスタをデバッグしたい人のためのガイドでは *ありません*。 +そのためには、[debug-cluster](/docs/tasks/debug-application-cluster/debug-cluster)を確認する必要があります。 + + + +## 問題の診断 + +トラブルシューティングの最初のステップは切り分けです。何が問題なのでしょうか？ +ポッドなのか、レプリケーション・コントローラなのか、それともサービスなのか？ + + * [Debugging Pods](#debugging-pods) + * [Debugging Replication Controllers](#debugging-replication-controllers) + * [Debugging Services](#debugging-services) + +### Podのデバッグ + +デバッグの第一歩は、Podを見てみることです。 +以下のコマンドで、Podの現在の状態や最近のイベントを確認します。 + +```shell +kubectl describe pods ${POD_NAME} +``` + +Pod内のコンテナの状態を見てください。 +すべて`Running`ですか？ 最近、再起動がありましたか？ +ポッドの状態に応じてデバッグを続けます。 + +#### PodがPendingのまま + +Podが`Pending` で止まっている場合、それはノードにスケジュールできないことを意味します。 +一般に、これはある種のリソースが不十分で、スケジューリングできないことが原因です。 +上の`kubectl describe ...`コマンドの出力を見てください。 + +なぜあなたのPodをスケジュールできないのか、スケジューラからのメッセージがあるはずです。 +理由は以下の通りです。 + +* **リソースが不足しています。** クラスタのCPUまたはメモリーを使い果たした可能性があります。Podを削除するか、リソース要求を調整するか、クラスタに新しいノードを追加する必要があります。詳しくは[Compute Resources document](/docs/concepts/configuration/manage-resources-containers/)を参照してください。 + +* **あなたが使用しているのは`hostPort`**です。Podを`hostPort`にバインドすると、そのPodがスケジュールできる場所が限定されます。ほとんどの場合、`hostPort`は不要なので、Serviceオブジェクトを使ってPodを公開するようにしてください。もし`hostPort` が必要な場合は、Kubernetes クラスタのノード数だけ Pod をスケジュールすることができます。 + + +#### Podがwaitingのまま + +Podが `Waiting` 状態で止まっている場合、ワーカーノードにスケジュールされていますが、そのマシン上で実行することはできません。この場合も、`kubectl describe ...` の情報が参考になるはずです。`Waiting`状態のポッドの最も一般的な原因は、イメージの取り出しに失敗することです。 + +確認すべきことは3つあります。 + +* イメージの名前が正しいかどうか確認してください。 +* イメージをリポジトリにプッシュしましたか？ +* あなたのマシンで手動で`docker pull `を実行し、イメージをプルできるかどうか確認してください。 + +#### Podがクラッシュするなどの不健全な状態 + +Podがスケジュールされると、[Debug Running Pods](/docs/tasks/debug-application-cluster/debug-running-pod/)で説明されているメソッドがデバッグに利用できるようになります。 + +#### Podが期待する通りに動きません + +Podが期待した動作をしない場合、ポッドの記述（ローカルマシンの `mypod.yaml` ファイルなど）に誤りがあり、ポッド作成時にその誤りが黙って無視された可能性があります。Pod記述のセクションのネストが正しくないか、キー名が間違って入力されていることがよくあり、そのため、そのキーは無視されます。たとえば、`command`のスペルを`commnd`と間違えた場合、Podは作成されますが、あなたが意図したコマンドラインは使用されません。 + +まずPodを削除して、`--validate` オプションを付けて再度作成してみてください。 +例えば、`kubectl apply --validate -f mypod.yaml`と実行します。 +command`のスペルを`commnd`に間違えると、以下のようなエラーになります。 + +```shell +I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd +I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842 +pods/mypod +``` + + + +次に確認することは、apiserver上のPodが、作成しようとしたPod（例えば、ローカルマシンのyamlファイル）と一致しているかどうかです。 +例えば、`kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml` を実行して、元のポッドの説明である`mypod.yaml`とapiserverから戻ってきた`mypod-on-apiserver.yaml`を手動で比較してみてください。 +通常、"apiserver" バージョンには、元のバージョンにはない行がいくつかあります。これは予想されることです。 +しかし、もし元のバージョンにある行がapiserverバージョンにない場合、これはあなたのPod specに問題があることを示している可能性があります。 + +### Debugging Replication Controllers + +Replication controllers are fairly straightforward. They can either create Pods or they can't. If they can't +create pods, then please refer to the [instructions above](#debugging-pods) to debug your pods. + +You can also use `kubectl describe rc ${CONTROLLER_NAME}` to introspect events related to the replication +controller. + +### サービスのデバッグ + +サービスは、ポッドのセット全体でロードバランシングを提供します。 +サービスが正しく動作しない原因には、いくつかの一般的な問題があります。 + +以下の手順は、サービスの問題をデバッグするのに役立つはずです。 + +まず、サービスのエンドポイントが存在することを確認します。 +全てのサービスオブジェクトに対して、apiserverは `endpoints` リソースを利用できるようにします。 +このリソースは次のようにして見ることができます。 + +```shell +kubectl get endpoints ${SERVICE_NAME} +``` + +エンドポイントがサービスのメンバーとして想定されるPod数と一致していることを確認してください。 +例えば、3つのレプリカを持つnginxコンテナ用のサービスであれば、サービスのエンドポイントには3つの異なるIPアドレスが表示されるはずです。 + +#### サービスにエンドポイントがありません + +エンドポイントが見つからない場合は、サービスが使用しているラベルを使用してポッドをリストアップしてみてください。 +ラベルがあるところにServiceがあると想像してください。 + +```yaml +... +spec: + - selector: + name: nginx + type: frontend +``` + +セレクタに一致するポッドを一覧表示するには、次のコマンドを使用します。 + +```shell +kubectl get pods --selector=name=nginx,type=frontend +``` + +リストがサービスを提供する予定のPodと一致することを確認します。 +Podの`containerPort`がサービスの`targetPort`と一致することを確認します。 + +#### ネットワークトラフィックが転送されません + +詳しくは[debugging service](/docs/tasks/debug-application-cluster/debug-service/)を参照してください。 + +## {{% heading "whatsnext" %}} + +上記のいずれの方法でも問題が解決しない場合は、以下の手順に従ってください。 +[Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)で、`Service` が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNS が機能していること、IPtables ルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。 + +トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)に詳細が記載されています。 + From 410ca700270eaf03a7e414f2041a9d3dc0d18147 Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 24 Dec 2021 14:21:31 +0900 Subject: [PATCH 051/254] fix --- .../debug-application-cluster/debug-application.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index f863ec3c84..5b1880638a 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -84,13 +84,12 @@ pods/mypod 通常、"apiserver" バージョンには、元のバージョンにはない行がいくつかあります。これは予想されることです。 しかし、もし元のバージョンにある行がapiserverバージョンにない場合、これはあなたのPod specに問題があることを示している可能性があります。 -### Debugging Replication Controllers +### レプリケーションコントローラのデバッグ -Replication controllers are fairly straightforward. They can either create Pods or they can't. If they can't -create pods, then please refer to the [instructions above](#debugging-pods) to debug your pods. - -You can also use `kubectl describe rc ${CONTROLLER_NAME}` to introspect events related to the replication -controller. +レプリケーションコントローラはかなり単純なものです。 +彼らはPodを作ることができるか、できないか、どちらかです。 +もしPodを作成できないのであれば、[instructions above](#debugging-pods)を参照して、Podをデバッグしてください。 +また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラに関連するイベントをイントロスペクトすることができます。 ### サービスのデバッグ From 77f9daaa7b3ed7b80baaeefe73dac0300b150ffd Mon Sep 17 00:00:00 2001 From: Shivam Singhal Date: Tue, 28 Dec 2021 14:46:29 +0200 Subject: [PATCH 052/254] [ja] Fix configuration overview example link --- content/ja/docs/concepts/configuration/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 74bc641df6..33adb3627c 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -18,7 +18,7 @@ weight: 10 - JSONではなくYAMLを使って設定ファイルを書いてください。これらのフォーマットはほとんどすべてのシナリオで互換的に使用できますが、YAMLはよりユーザーフレンドリーになる傾向があります。 -- 意味がある場合は常に、関連オブジェクトを単一ファイルにグループ化します。多くの場合、1つのファイルの方が管理が簡単です。例として[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml)ファイルを参照してください。 +- 意味がある場合は常に、関連オブジェクトを単一ファイルにグループ化します。多くの場合、1つのファイルの方が管理が簡単です。例として[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml)ファイルを参照してください。 - 多くの`kubectl`コマンドがディレクトリに対しても呼び出せることも覚えておきましょう。たとえば、設定ファイルのディレクトリで `kubectl apply`を呼び出すことができます。 From aa161ad833280433eeb09c875a00b25bd38a8cce Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 14 Dec 2021 19:47:42 +0900 Subject: [PATCH 053/254] [ko] Update outdated files in dev-1.23-ko.1 M1-M12 --- content/ko/_index.html | 6 +- content/ko/community/_index.html | 1 + .../concepts/architecture/cloud-controller.md | 4 +- .../ko/docs/concepts/architecture/nodes.md | 117 +++++++++++++++--- .../concepts/cluster-administration/addons.md | 7 +- .../cluster-administration/networking.md | 57 +-------- .../manage-resources-containers.md | 14 +-- .../ko/docs/concepts/configuration/secret.md | 2 +- content/ko/docs/concepts/containers/images.md | 85 ++++++++++++- 9 files changed, 205 insertions(+), 88 deletions(-) diff --git a/content/ko/_index.html b/content/ko/_index.html index c6350f1559..3e21fbde45 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -30,7 +30,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 {{% blocks/feature image="suitcase" %}} #### K8s를 어디서나 실행 -쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. +쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는 데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. {{% /blocks/feature %}} @@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준

- Attend KubeCon North America on October 11-15, 2021 + KubeCon Europe (2022년 5월 17~20일) 참가하기



- Attend KubeCon Europe on May 17-20, 2022 + KubeCon North America (2022년 10월 24~28일) 참가하기
diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 9666cd4a14..30ede236bc 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -19,6 +19,7 @@ cid: community
+기여자 커뮤니티      커뮤니티 가치      행동 강령       비디오      diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index e5e7d315c5..eccfe091ce 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -44,10 +44,10 @@ weight: 40 ### 노드 컨트롤러 노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}} -오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 +오브젝트를 업데이트하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다. -1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다. +1. 클라우드 공급자 API를 통해 획득한 해당 서버의 고유 ID를 노드 오브젝트에 업데이트한다. 2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를 사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다. 3. 노드의 호스트 이름과 네트워크 주소를 가져온다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index c71462d9b3..86a9856b47 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -385,7 +385,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. -## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown} +## 그레이스풀(Graceful) 노드 셧다운(shutdown) {#graceful-node-shutdown} {{< feature-state state="beta" for_k8s_version="v1.21" >}} @@ -402,7 +402,7 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 제어된다. 기본적으로, 아래 설명된 두 구성 옵션, -`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, +`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, 그레이스풀 노드 셧다운 기능이 활성화되지 않는다. 기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다. @@ -412,32 +412,116 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다. 그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다. -* `ShutdownGracePeriod`: +* `shutdownGracePeriod`: * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다. -* `ShutdownGracePeriodCriticalPods`: - * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다. +* `shutdownGracePeriodCriticalPods`: + * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다. -예를 들어, `ShutdownGracePeriod=30s`, -`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 +예를 들어, `shutdownGracePeriod=30s`, +`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의 유예 종료에 할당되고, 마지막 10초는 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다. {{< note >}} -그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다. -`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다. +그레이스풀 노드 셧다운 과정에서 축출된 파드는 셧다운(shutdown)된 것으로 표시된다. +`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Terminated`으로 표시된다. 그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다. ``` -Status: Failed -Reason: Shutdown -Message: Node is shutting, evicting pods +Reason: Terminated +Message: Pod was terminated in response to imminent node shutdown. ``` -실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다. -이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다. {{< /note >}} +### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown} + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +그레이스풀 노드 셧다운 시 파드 셧다운 순서에 더 많은 유연성을 제공할 수 있도록, +클러스터에 프라이어리티클래스(PriorityClass) 기능이 활성화되어 있으면 +그레이스풀 노드 셧다운 과정에서 파드의 프라이어리티클래스가 고려된다. +이 기능으로 그레이스풀 노드 셧다운 시 파드가 종료되는 순서를 클러스터 관리자가 +[프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스) +기반으로 명시적으로 정할 수 있다. + +위에서 기술된 것처럼, [그레이스풀 노드 셧다운](#graceful-node-shutdown) 기능은 파드를 +중요하지 않은(non-critical) 파드와 +중요한(critical) 파드 2단계(phase)로 구분하여 종료시킨다. +셧다운 시 파드가 종료되는 순서를 명시적으로 더 상세하게 정해야 한다면, +파드 우선순위 기반 그레이스풀 노드 셧다운을 사용할 수 있다. + +그레이스풀 노드 셧다운 과정에서 파드 우선순위가 고려되기 때문에, +그레이스풀 노드 셧다운이 여러 단계로 일어날 수 있으며, +각 단계에서 특정 프라이어리티 클래스의 파드를 종료시킨다. +정확한 단계와 단계별 셧다운 시간은 kubelet에 설정할 수 있다. + +다음과 같이 클러스터에 커스텀 파드 +[프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)가 있다고 +가정하자. + +|파드 프라이어리티 클래스 이름|파드 프라이어리티 클래스 값| +|-------------------------|------------------------| +|`custom-class-a` | 100000 | +|`custom-class-b` | 10000 | +|`custom-class-c` | 1000 | +|`regular/unset` | 0 | + +[kubelet 환경 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 안의 +`shutdownGracePeriodByPodPriority` 설정은 다음과 같을 수 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |10 seconds | +| 10000 |180 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +이를 나타내는 kubelet 환경 설정 YAML은 다음과 같다. + +```yaml +shutdownGracePeriodByPodPriority: + - priority: 100000 + shutdownGracePeriodSeconds: 10 + - priority: 10000 + shutdownGracePeriodSeconds: 180 + - priority: 1000 + shutdownGracePeriodSeconds: 120 + - priority: 0 + shutdownGracePeriodSeconds: 60 +``` + +위의 표에 의하면 우선순위 값이 100000 이상인 파드는 종료까지 10초만 주어지며, +10000 이상 ~ 100000 미만이면 180초, +1000 이상 ~ 10000 미만이면 120초가 주어진다. +마지막으로, 다른 모든 파드는 종료까지 60초가 주어질 것이다. + +모든 클래스에 대해 값을 명시할 필요는 없다. +예를 들어, 대신 다음과 같은 구성을 사용할 수도 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |300 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + + +위의 경우, custom-class-b에 속하는 파드와 custom-class-c에 속하는 파드는 +동일한 종료 대기 시간을 갖게 될 것이다. + +특정 범위에 해당되는 파드가 없으면, +kubelet은 해당 범위에 해당되는 파드를 위해 기다려 주지 않는다. +대신, kubelet은 즉시 다음 프라이어리티 클래스 값 범위로 넘어간다. + +기능이 활성화되어 있지만 환경 설정이 되어 있지 않으면, +순서 지정 동작이 수행되지 않을 것이다. + +이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority` 기능 게이트를 활성화해야 하고, +kubelet 환경 설정의 `ShutdownGracePeriodByPodPriority`를 +파드 프라이어리티 클래스 값과 +각 값에 대한 종료 대기 시간을 명시하여 지정해야 한다. + ## 스왑(swap) 메모리 관리 {#swap-memory} {{< feature-state state="alpha" for_k8s_version="v1.22" >}} @@ -451,6 +535,11 @@ kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 [구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가 false로 지정되어야 한다. +{{< warning >}} +메모리 스왑 기능이 활성화되면, 시크릿 오브젝트의 내용과 같은 +tmpfs에 기록되었던 쿠버네티스 데이터가 디스크에 스왑될 수 있다. +{{< /warning >}} + 사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면, diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 270063a737..fc605ae453 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -25,7 +25,7 @@ content_type: concept * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. -* [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. +* Multus는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. @@ -45,6 +45,11 @@ content_type: concept ## 인프라스트럭처 * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다. +* [node problem detector](https://github.com/kubernetes/node-problem-detector)는 + 리눅스 노드에서 실행되며, + 시스템 이슈를 + [이벤트](/docs/reference/kubernetes-api/cluster-resources/event-v1/) 또는 + [노드 컨디션](/docs/concepts/architecture/nodes/#condition) 형태로 보고한다. ## 레거시 애드온 diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 545c26f420..d916a09105 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -64,7 +64,7 @@ weight: 50 VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다. -이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. +이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다. `Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를 요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은 @@ -169,49 +169,6 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네 충족하는 매우 간단한 오버레이 네트워크이다. 많은 경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다. -### Google 컴퓨트 엔진(GCE) - -Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, [고급 -라우팅](https://cloud.google.com/vpc/docs/routes)을 사용하여 -각 VM에 서브넷을 할당한다(기본값은 `/24` - 254개 IP). 해당 서브넷에 바인딩된 -모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는 -아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본" -IP 주소에 추가된다. 리눅스 브릿지(`cbr0`)는 해당 서브넷에 존재하도록 -구성되며, 도커의 `--bridge` 플래그로 전달된다. - -도커는 다음의 설정으로 시작한다. - -```shell -DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" -``` - -이 브릿지는 노드의 `.spec.podCIDR`에 따라 Kubelet(`--network-plugin=kubenet` -플래그로 제어되는)에 의해 생성된다. - -도커는 이제 `cbr-cidr` 블록에서 IP를 할당한다. 컨테이너는 `cbr0` 브릿지를 -통해 서로 `Node` 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크 -내에서 라우팅할 수 있다. - -그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해 -IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여 -GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을 -마스커레이드(일명 SNAT - 마치 패킷이 `Node` 자체에서 온 것처럼 -보이게 함)한다. - -```shell -iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE -``` - -마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에 -대한 패킷을 처리한다. - -```shell -sysctl net.ipv4.ip_forward=1 -``` - -이 모든 것의 결과는 모든 `Pod` 가 서로에게 도달할 수 있고 인터넷으로 트래픽을 -송신할 수 있다는 것이다. - ### 재규어(Jaguar) [재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다. @@ -246,7 +203,7 @@ Lars Kellogg-Stedman이 제공하는 ### Multus(멀티 네트워크 플러그인) -[Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. +Multus는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다. @@ -260,12 +217,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https:// [NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만 -오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇 -"대형 벤더"에 의해 승인되었다. - ### OVN(오픈 버추얼 네트워킹) OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 @@ -274,10 +225,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 특정 쿠버네티스 플러그인 및 문서가 있다. -### 로마나 - -[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. - ### Weaveworks의 위브넷 [위브넷](https://www.weave.works/products/weave-net/)은 diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index fa7ec69fc9..78e7ecfba6 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -74,8 +74,7 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 수량이다. 이것은 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및 [서비스](/ko/docs/concepts/services-networking/service/)와 같은 API 리소스는 -쿠버네티스 API 서버를 통해 읽고 수정할 수 -있는 오브젝트이다. +쿠버네티스 API 서버를 통해 읽고 수정할 수 있는 오브젝트이다. ## 파드와 컨테이너의 리소스 요청 및 제한 @@ -100,9 +99,10 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다. 쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다. -분수의 요청이 허용된다. -`0.5` 의 `spec.containers[].resources.requests.cpu` 요청을 가진 -컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 +요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의 +`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은, +`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다. +CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. `0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, @@ -115,12 +115,12 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. ### 메모리의 의미 `memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다. -E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를 +E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. ```shell -128974848, 129e6, 129M, 123Mi +128974848, 129e6, 129M, 128974848000m, 123Mi ``` 다음은 예제이다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 73d48cd18b..d27faddc20 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -244,7 +244,7 @@ kubectl create secret docker-registry secret-tiger-docker \ `kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기 위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가 -다음의 두 키를 포함해야 한다. +다음의 두 키 중 하나를 포함해야 한다. - `username`: 인증을 위한 사용자 이름 - `password`: 인증을 위한 암호나 토큰 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 5ab09dd64a..d0c1d4bf7a 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -54,13 +54,15 @@ weight: 10 컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다. -다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다. +다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 +효과이다. `IfNotPresent` : 이미지가 로컬에 없는 경우에만 내려받는다. `Always` -: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의 +: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 + 이미지 레지스트리에 이름과 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다. 일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다. 이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서 @@ -78,7 +80,8 @@ weight: 10 {{< note >}} 프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데, -이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다. +이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 +제대로 롤백하기 어렵게 되기 때문이다. 대신, `v1.42.0`과 같이 의미있는 태그를 명기한다. {{< /note >}} @@ -90,7 +93,8 @@ weight: 10 이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다. -파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 +파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 +태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다. 이는 레지스트리에서 태그가 변경되는 일이 발생해도 구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다. @@ -104,7 +108,9 @@ weight: 10 `:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. - `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. -- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. +- `imagePullPolicy` 필드를 생략하고, + 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, + `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. {{< note >}} 컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상 @@ -127,6 +133,7 @@ weight: 10 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다. + ### 이미지풀백오프(ImagePullBackOff) kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, @@ -258,6 +265,73 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. +### config.json 파일 해석 {#config-json} + +`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. +도커에서는 `auths` 키에 특정 루트 URL만 기재할 수 있으나, +쿠버네티스에서는 glob URL과 접두사-매칭 경로도 기재할 수 있다. +이는 곧 다음과 같은 `config.json`도 유효하다는 뜻이다. + +```json +{ + "auths": { + "*my-registry.io/images": { + "auth": "…" + } + } +} +``` + +루트 URL(`*my-registry.io`)은 다음 문법을 사용하여 매치된다. + +``` +pattern: + { term } + +term: + '*' 구분자가 아닌 모든 문자와 매치됨 + '?' 구분자가 아닌 문자 1개와 매치됨 + '[' [ '^' ] { character-range } ']' + 문자 클래스 (비어 있으면 안 됨)) + c 문자 c에 매치됨 (c != '*', '?', '\\', '[') + '\\' c 문자 c에 매치됨 + +character-range: + c 문자 c에 매치됨 (c != '\\', '-', ']') + '\\' c 문자 c에 매치됨 + lo '-' hi lo <= c <= hi 인 문자 c에 매치됨 +``` + +이미지 풀 작업 시, 모든 유효한 패턴에 대해 크리덴셜을 CRI 컨테이너 런타임에 제공할 것이다. +예를 들어 다음과 같은 컨테이너 이미지 이름은 +성공적으로 매치될 것이다. + +- `my-registry.io/images` +- `my-registry.io/images/my-image` +- `my-registry.io/images/another-image` +- `sub.my-registry.io/images/my-image` +- `a.sub.my-registry.io/images/my-image` + +kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미지 풀을 수행한다. 즉, +`config.json`에 다음과 같이 여러 항목을 기재할 수도 있다. + +```json +{ + "auths": { + "my-registry.io/images": { + "auth": "…" + }, + "my-registry.io/images/subpath": { + "auth": "…" + } + } +} +``` + +이제 컨테이너가 `my-registry.io/images/subpath/my-image` +이미지를 풀 해야 한다고 명시하면, +kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다. + ### 미리 내려받은 이미지 {#pre-pulled-images} {{< note >}} @@ -383,3 +457,4 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config. * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기. * [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기. +* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry) From 1d1928e173e5734d9788e0f5cf622d6a5ab87251 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 15 Dec 2021 15:10:23 +0900 Subject: [PATCH 054/254] [ko] Update outdated files in dev-1.23-ko.1 M17-24 --- .../docs/concepts/overview/kubernetes-api.md | 74 +++++++++++-- .../scheduling-eviction/kube-scheduler.md | 2 +- .../scheduler-perf-tuning.md | 4 +- .../connect-applications-service.md | 6 +- .../services-networking/dns-pod-service.md | 2 +- .../services-networking/dual-stack.md | 16 +-- .../ingress-controllers.md | 1 + .../concepts/services-networking/ingress.md | 102 +++++++++++++++--- 8 files changed, 172 insertions(+), 35 deletions(-) diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 919d59b459..cc043139c4 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -1,4 +1,6 @@ --- + + title: 쿠버네티스 API content_type: concept weight: 30 @@ -35,36 +37,39 @@ card: 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. -다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다. +### OpenAPI V2 + +쿠버네티스 API 서버는 `/openapi/v2` 엔드포인트를 통해 +통합된(aggregated) OpenAPI v2 스펙을 제공한다. +요청 헤더에 다음과 같이 기재하여 응답 형식을 지정할 수 있다. - + - - - + + + - + - + - + - +
Valid request header values for OpenAPI v2 queries OpenAPI v2 질의에 사용할 수 있는 유효한 요청 헤더 값
HeaderPossible valuesNotes헤더사용할 수 있는 값참고
Accept-Encoding gzipnot supplying this header is also acceptable이 헤더를 제공하지 않는 것도 가능
Accept application/com.github.proto-openapi.spec.v2@v1.0+protobufmainly for intra-cluster use주로 클러스터 내부 용도로 사용
application/jsondefault기본값
*serves application/jsonJSON으로 응답
@@ -75,6 +80,55 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한 IDL(인터페이스 정의 언어) 파일을 참고한다. +### OpenAPI V3 + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다. +이는 알파 기능이며 기본적으로 비활성화되어 있다. +kube-apiserver 구성 요소에 +`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 +이 알파 기능을 활성화할 수 있다. + +이 기능이 활성화되면, 쿠버네티스 API 서버는 +통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로 +`/openapi/v3/apis//` 엔드포인트에 제공한다. +사용할 수 있는 요청 헤더는 아래의 표를 참고한다. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값
헤더사용할 수 있는 값참고
Accept-Encodinggzip이 헤더를 제공하지 않는 것도 가능
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobuf주로 클러스터 내부 용도로 사용
application/json기본값
*JSON으로 응답
+ +`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든 +그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다. + ## 지속성 쿠버네티스는 오브젝트의 직렬화된 상태를 diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 1c4424a047..0ab5b4b76f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 -* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기 +* [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index e2fb1cdcf9..5fd12dc521 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 마치 100을 설정한 것처럼 작동한다. 값을 변경하려면, -[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을 +[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta3/)을 편집한 다음 스케줄러를 재시작한다. 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다. @@ -161,4 +161,4 @@ percentageOfNodesToScore: 50 ## {{% heading "whatsnext" %}} -* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인 +* [kube-scheduler 구성 레퍼런스(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 확인 diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index bb7a9154c3..b7e5b26056 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -1,4 +1,8 @@ --- + + + + title: 서비스와 애플리케이션 연결하기 content_type: concept weight: 30 @@ -50,7 +54,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다. -만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다. +만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다. ## 서비스 생성하기 diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 3544d7e745..c23556172b 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -39,7 +39,7 @@ DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다 DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은 각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는 -`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은 +`data.test.svc.cluster.local` 로 확장된다. `search` 옵션의 값은 쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우, [`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 821ca34989..c77bba06c8 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -1,4 +1,9 @@ --- + + + + + title: IPv4/IPv6 이중 스택 feature: title: IPv4/IPv6 이중 스택 @@ -11,7 +16,7 @@ weight: 70 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. @@ -42,8 +47,6 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 ## IPv4/IPv6 이중 스택 구성 -IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.) - IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다. * kube-apiserver: @@ -60,9 +63,6 @@ IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도 IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.) -1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다. -필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에 -`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다. {{< /note >}} ## 서비스 @@ -76,7 +76,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `PreferDualStack`: - * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.) + * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다. * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. @@ -119,7 +119,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 #### 기존 서비스의 이중 스택 기본값 -이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.) +이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.) 1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index c66a9b6e84..a8b2cf1d5f 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -28,6 +28,7 @@ weight: 40 컨트롤러다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다. +* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다. * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index bafb216014..bb78469e83 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -51,7 +51,7 @@ graph LR; 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 -[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는 +[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는 [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. ## 전제 조건들 @@ -219,20 +219,98 @@ Events: {{< codenew file="service/networking/external-lb.yaml" >}} -IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한 -추가 구현 별 구성을 참조하는데 사용할 수 있다. +인그레스클래스의 `.spec.parameters` 필드를 사용하여 +해당 인그레스클래스와 연관있는 환경 설정을 제공하는 다른 리소스를 참조할 수 있다. -#### 네임스페이스 범위의 파라미터 +사용 가능한 파라미터의 상세한 타입은 +인그레스클래스의 `.spec.parameters` 필드에 명시한 인그레스 컨트롤러의 종류에 따라 다르다. -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +### 인그레스클래스 범위 -`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데 -사용할 수 있는 `scope` 및 `namespace` 필드가 있다. -`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의 -리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를 -설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다. +인그레스 컨트롤러의 종류에 따라, 클러스터 범위로 설정한 파라미터의 사용이 가능할 수도 있고, +또는 한 네임스페이스에서만 사용 가능할 수도 있다. -{{< codenew file="service/networking/namespaced-params.yaml" >}} +{{< tabs name="tabs_ingressclass_parameter_scope" >}} +{{% tab name="클러스터" %}} +인그레스클래스 파라미터의 기본 범위는 클러스터 범위이다. + +`.spec.parameters` 필드만 설정하고 `.spec.parameters.scope` 필드는 지정하지 않거나, +`.spec.parameters.scope` 필드를 `Cluster`로 지정하면, +인그레스클래스는 클러스터 범위의 리소스를 참조한다. +파라미터의 `kind`(+`apiGroup`)는 +클러스터 범위의 API (커스텀 리소스일 수도 있음) 를 참조하며, +파라미터의 `name`은 +해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다. + +예시는 다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-1 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는 + # ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다. + # 이 정의는 쿠버네티스가 + # 클러스터 범위의 파라미터 리소스를 검색하도록 한다. + scope: Cluster + apiGroup: k8s.example.net + kind: ClusterIngressParameter + name: external-config-1 +``` +{{% /tab %}} +{{% tab name="네임스페이스" %}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +`.spec.parameters` 필드를 설정하고 +`.spec.parameters.scope` 필드를 `Namespace`로 지정하면, +인그레스클래스는 네임스페이스 범위의 리소스를 참조한다. +사용하고자 하는 파라미터가 속한 네임스페이스를 +`.spec.parameters` 의 `namespace` 필드에 설정해야 한다. + +파라미터의 `kind`(+`apiGroup`)는 +네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며, +파라미터의 `name`은 +`namespace`에 명시한 네임스페이스의 특정 리소스를 가리킨다. + +네임스페이스 범위의 파라미터를 이용하여, +클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임할 수 있다. +클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당된다. + +- 다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다 + 클러스터 운영 팀이 매번 승인을 해야 한다. 또는, +- 애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는 + [RBAC](/docs/reference/access-authn-authz/rbac/) 롤, 바인딩 등의 특별 접근 제어를 + 클러스터 운영자가 정의해야 한다. + +인그레스클래스 API 자신은 항상 클러스터 범위이다. + +네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시가 +다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-2 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 + # "external-configuration" 환경 설정 네임스페이스에 있는 + # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다. + scope: Namespace + apiGroup: k8s.example.com + kind: IngressParameter + namespace: external-configuration + name: external-config +``` + +{{% /tab %}} +{{< /tabs >}} ### 사용중단(Deprecated) 어노테이션 @@ -565,6 +643,6 @@ Events: ## {{% heading "whatsnext" %}} -* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 +* [인그레스](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/) From 1badd802c3565ca0397e30e5586ca9bfc42b716e Mon Sep 17 00:00:00 2001 From: bang9211 Date: Fri, 17 Dec 2021 03:12:12 +0900 Subject: [PATCH 055/254] Translate tasks/run-application/scale-stateful-set.md in Korean --- .../run-application/scale-stateful-set.md | 100 ++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 content/ko/docs/tasks/run-application/scale-stateful-set.md diff --git a/content/ko/docs/tasks/run-application/scale-stateful-set.md b/content/ko/docs/tasks/run-application/scale-stateful-set.md new file mode 100644 index 0000000000..52fe7ac593 --- /dev/null +++ b/content/ko/docs/tasks/run-application/scale-stateful-set.md @@ -0,0 +1,100 @@ +--- + + + + + + + + +title: 스테이트풀셋(StatefulSet) 확장하기 +content_type: task +weight: 50 +--- + + +이 작업은 스테이트풀셋을 확장하는 방법을 보여준다. 스테이트풀셋 확장은 레플리카 수를 늘리거나 줄이는 것을 의미한다. + + +## {{% heading "prerequisites" %}} + + +* 스테이트풀셋은 쿠버네티스 버전 1.5 이상에서만 사용할 수 있다. + 쿠버네티스 버전을 확인하려면 `kubectl version`을 실행한다. + +* 모든 스테이트풀 애플리케이션이 제대로 확장되는 것은 아니다. 스테이트풀셋을 확장할지 여부가 확실하지 않은 경우에 자세한 내용은 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 또는 [스테이트풀셋 튜토리얼](/ko/docs/tutorials/stateful-application/basic-stateful-set/)을 참조한다. + +* 스테이트풀 애플리케이션 클러스터가 완전히 정상이라고 확신할 때만 + 확장을 수행해야 한다. + + + + + +## 스테이트풀셋 확장하기 + +### kubectl을 사용하여 스테이트풀셋 확장 + +먼저 확장하려는 스테이트풀셋을 찾는다. + +```shell +kubectl get statefulsets +``` + +스테이트풀셋의 레플리카 수를 변경한다. + +```shell +kubectl scale statefulsets --replicas= +``` + +### 스테이트풀셋 인플레이스(in-place) 업데이트 + +대안으로 스테이트풀셋에 [인플레이스 업데이트](/ko/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)를 수행할 수 있다. + +스테이트풀셋이 처음에 `kubectl apply`로 생성된 경우, +스테이트풀셋 매니페스트의 `.spec.replicas`를 업데이트한 다음 `kubectl apply`를 수행한다. + +```shell +kubectl apply -f +``` + +그렇지 않으면 `kubectl edit`로 해당 필드를 편집한다. + +```shell +kubectl edit statefulsets +``` + +또는 `kubectl patch`를 사용한다. + +```shell +kubectl patch statefulsets -p '{"spec":{"replicas":}}' +``` + +## 트러블슈팅 + +### 축소가 제대로 작동하지 않음 + +스테이트풀셋에서 관리하는 스테이트풀 파드가 비정상인 경우에는 스테이트풀셋을 축소할 수 없다. 축소는 +스테이트풀 파드가 실행되고 준비된 후에만 발생한다. + +spec.replicas > 1인 경우 쿠버네티스는 비정상 파드의 원인을 결정할 수 없다. 영구적인 오류 또는 일시적인 오류의 결과일 수 있다. 일시적인 오류는 업그레이드 또는 유지 관리에 필요한 재시작으로 인해 발생할 수 있다. + +영구적인 오류로 인해 파드가 비정상인 경우 +오류를 수정하지 않고 확장하면 스테이트풀셋 멤버십이 올바르게 작동하는 데 필요한 +특정 최소 레플리카 수 아래로 떨어지는 상태로 이어질 수 있다. +이로 인해 스테이트풀셋을 사용할 수 없게 될 수 있다. + +일시적인 오류로 인해 파드가 비정상 상태이고 파드를 다시 사용할 수 있게 되면 +일시적인 오류가 확장 또는 축소 작업을 방해할 수 있다. 일부 분산 +데이터베이스에는 노드가 동시에 가입 및 탈퇴할 때 문제가 있다. 이러한 경우 +애플리케이션 수준에서 확장 작업에 대해 추론하고 스테이트풀 애플리케이션 클러스터가 +완전히 정상이라고 확신할 때만 확장을 수행하는 것이 좋다. + + + +## {{% heading "whatsnext" %}} + + +* [스테이트풀셋 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)에 대해 더 배워보기 + + From 7c5c2692fcb7b42388d8027de8452624a1abdb3d Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:44:56 +0900 Subject: [PATCH 056/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 5b1880638a..ea18e50597 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -8,7 +8,7 @@ content_type: concept このガイドは、Kubernetesにデプロイされ、正しく動作しないアプリケーションをユーザーがデバッグするためのものです。 -これは、自分のクラスタをデバッグしたい人のためのガイドでは *ありません*。 +これは、自分のクラスターをデバッグしたい人のためのガイドでは *ありません*。 そのためには、[debug-cluster](/docs/tasks/debug-application-cluster/debug-cluster)を確認する必要があります。 From 46c808602053cec932eec47a1f5acf18afaac9ca Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:02 +0900 Subject: [PATCH 057/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index ea18e50597..1e4f5dc641 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -16,7 +16,7 @@ content_type: concept ## 問題の診断 トラブルシューティングの最初のステップは切り分けです。何が問題なのでしょうか？ -ポッドなのか、レプリケーション・コントローラなのか、それともサービスなのか？ +Podなのか、レプリケーションコントローラなのか、それともサービスなのか？ * [Debugging Pods](#debugging-pods) * [Debugging Replication Controllers](#debugging-replication-controllers) From 198e454ce964f6c7676324f264c3a814fc93902e Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:08 +0900 Subject: [PATCH 058/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 1e4f5dc641..2419943b6d 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -33,7 +33,7 @@ kubectl describe pods ${POD_NAME} Pod内のコンテナの状態を見てください。 すべて`Running`ですか？ 最近、再起動がありましたか？ -ポッドの状態に応じてデバッグを続けます。 +Podの状態に応じてデバッグを続けます。 #### PodがPendingのまま From a9c76ae35d51231141bf7c46694dbfddfc2133a8 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:16 +0900 Subject: [PATCH 059/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 2419943b6d..016d06704f 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -41,7 +41,7 @@ Podが`Pending` で止まっている場合、それはノードにスケジュ 一般に、これはある種のリソースが不十分で、スケジューリングできないことが原因です。 上の`kubectl describe ...`コマンドの出力を見てください。 -なぜあなたのPodをスケジュールできないのか、スケジューラからのメッセージがあるはずです。 +なぜあなたのPodをスケジュールできないのか、スケジューラーからのメッセージがあるはずです。 理由は以下の通りです。 * **リソースが不足しています。** クラスタのCPUまたはメモリーを使い果たした可能性があります。Podを削除するか、リソース要求を調整するか、クラスタに新しいノードを追加する必要があります。詳しくは[Compute Resources document](/docs/concepts/configuration/manage-resources-containers/)を参照してください。 From ab35736630bbca45e55907f4878e634f13034ecf Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:25 +0900 Subject: [PATCH 060/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 016d06704f..502cd27c19 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -122,7 +122,7 @@ spec: type: frontend ``` -セレクタに一致するポッドを一覧表示するには、次のコマンドを使用します。 +セレクタに一致するPodを一覧表示するには、次のコマンドを使用します。 ```shell kubectl get pods --selector=name=nginx,type=frontend From bb5631f383f72255eb142b3a78b061f1c976711f Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:30 +0900 Subject: [PATCH 061/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 502cd27c19..d64eedce45 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -128,7 +128,7 @@ spec: kubectl get pods --selector=name=nginx,type=frontend ``` -リストがサービスを提供する予定のPodと一致することを確認します。 +リストがServiceを提供する予定のPodと一致することを確認します。 Podの`containerPort`がサービスの`targetPort`と一致することを確認します。 #### ネットワークトラフィックが転送されません From 4403af79c86f5d90ba96fa692be693844455b2a0 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:36 +0900 Subject: [PATCH 062/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index d64eedce45..92abea17ab 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -129,7 +129,7 @@ kubectl get pods --selector=name=nginx,type=frontend ``` リストがServiceを提供する予定のPodと一致することを確認します。 -Podの`containerPort`がサービスの`targetPort`と一致することを確認します。 +Podの`containerPort`がServiceの`targetPort`と一致することを確認します。 #### ネットワークトラフィックが転送されません From 8c287b22bc6f31dea139cca352e889343240ac8b Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:46 +0900 Subject: [PATCH 063/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 92abea17ab..70b1c9f450 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -138,7 +138,7 @@ Podの`containerPort`がServiceの`targetPort`と一致することを確認し ## {{% heading "whatsnext" %}} 上記のいずれの方法でも問題が解決しない場合は、以下の手順に従ってください。 -[Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)で、`Service` が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNS が機能していること、IPtables ルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。 +[Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)で、`Service` が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNS が機能していること、IPtablesルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。 トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)に詳細が記載されています。 From 2e564cc51e9cff5625c8114515ac53de2dec979c Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:45:53 +0900 Subject: [PATCH 064/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 70b1c9f450..ac975d9cb2 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -140,5 +140,5 @@ Podの`containerPort`がServiceの`targetPort`と一致することを確認し 上記のいずれの方法でも問題が解決しない場合は、以下の手順に従ってください。 [Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)で、`Service` が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNS が機能していること、IPtablesルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。 -トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)に詳細が記載されています。 +[トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)に詳細が記載されています。 From 71002b2be7bc393f0d8437e6f2eb5e355edfa294 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:46:02 +0900 Subject: [PATCH 065/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index ac975d9cb2..da096320bb 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -37,7 +37,7 @@ Podの状態に応じてデバッグを続けます。 #### PodがPendingのまま -Podが`Pending` で止まっている場合、それはノードにスケジュールできないことを意味します。 +Podが`Pending`で止まっている場合、それはノードにスケジュールできないことを意味します。 一般に、これはある種のリソースが不十分で、スケジューリングできないことが原因です。 上の`kubectl describe ...`コマンドの出力を見てください。 From de39a491418b16a7337bf651d889d8c809da49b7 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:46:07 +0900 Subject: [PATCH 066/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index da096320bb..ac574f55d2 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -44,7 +44,7 @@ Podが`Pending`で止まっている場合、それはノードにスケジュ なぜあなたのPodをスケジュールできないのか、スケジューラーからのメッセージがあるはずです。 理由は以下の通りです。 -* **リソースが不足しています。** クラスタのCPUまたはメモリーを使い果たした可能性があります。Podを削除するか、リソース要求を調整するか、クラスタに新しいノードを追加する必要があります。詳しくは[Compute Resources document](/docs/concepts/configuration/manage-resources-containers/)を参照してください。 +* **リソースが不足しています。** クラスターのCPUまたはメモリーを使い果たしている可能性があります。Podを削除するか、リソースの要求値を調整するか、クラスターに新しいノードを追加する必要があります。詳しくは[Compute Resources document](/ja/docs/concepts/configuration/manage-resources-containers/)を参照してください。 * **あなたが使用しているのは`hostPort`**です。Podを`hostPort`にバインドすると、そのPodがスケジュールできる場所が限定されます。ほとんどの場合、`hostPort`は不要なので、Serviceオブジェクトを使ってPodを公開するようにしてください。もし`hostPort` が必要な場合は、Kubernetes クラスタのノード数だけ Pod をスケジュールすることができます。 From e42662ec14a2fc6c6847cf5737db54f38733cb3c Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:46:13 +0900 Subject: [PATCH 067/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index ac574f55d2..224edd92ac 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -51,7 +51,7 @@ Podが`Pending`で止まっている場合、それはノードにスケジュ #### Podがwaitingのまま -Podが `Waiting` 状態で止まっている場合、ワーカーノードにスケジュールされていますが、そのマシン上で実行することはできません。この場合も、`kubectl describe ...` の情報が参考になるはずです。`Waiting`状態のポッドの最も一般的な原因は、イメージの取り出しに失敗することです。 +Podが`Waiting`状態で止まっている場合、ワーカーノードにスケジュールされていますが、そのノード上で実行することができません。この場合も、`kubectl describe ...`の情報が参考になるはずです。`Waiting`状態のPodの最も一般的な原因は、コンテナイメージのプルに失敗することです。 確認すべきことは3つあります。 From f200c28158189e375c7f4b368358bd257d6ff403 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:47:42 +0900 Subject: [PATCH 068/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 224edd92ac..79e2dcccde 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -133,7 +133,7 @@ Podの`containerPort`がServiceの`targetPort`と一致することを確認し #### ネットワークトラフィックが転送されません -詳しくは[debugging service](/docs/tasks/debug-application-cluster/debug-service/)を参照してください。 +詳しくは[Serviceのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-service/)を参照してください。 ## {{% heading "whatsnext" %}} From 988d7ed9f1948c90d8bf9b7fbf9fd2222fad707e Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:50:13 +0900 Subject: [PATCH 069/254] Update debug-application.md --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 79e2dcccde..14c093fbb2 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -1,6 +1,4 @@ --- -reviewers: -- ptux title: アプリケーションのトラブルシューティング content_type: concept --- From 6b355af0ea7610fcf62984d08fe7e900429af144 Mon Sep 17 00:00:00 2001 From: ptux Date: Tue, 4 Jan 2022 08:16:10 +0900 Subject: [PATCH 070/254] fix glossary --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 14c093fbb2..d45e760a70 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -54,7 +54,7 @@ Podが`Waiting`状態で止まっている場合、ワーカーノードにス 確認すべきことは3つあります。 * イメージの名前が正しいかどうか確認してください。 -* イメージをリポジトリにプッシュしましたか？ +* イメージをレジストリにプッシュしましたか？ * あなたのマシンで手動で`docker pull `を実行し、イメージをプルできるかどうか確認してください。 #### Podがクラッシュするなどの不健全な状態 From 3e2b6c8655643b410bf009e0391cbe8fffb38efb Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:20:41 +0900 Subject: [PATCH 071/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index d45e760a70..ec29edba47 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -44,7 +44,7 @@ Podが`Pending`で止まっている場合、それはノードにスケジュ * **リソースが不足しています。** クラスターのCPUまたはメモリーを使い果たしている可能性があります。Podを削除するか、リソースの要求値を調整するか、クラスターに新しいノードを追加する必要があります。詳しくは[Compute Resources document](/ja/docs/concepts/configuration/manage-resources-containers/)を参照してください。 -* **あなたが使用しているのは`hostPort`**です。Podを`hostPort`にバインドすると、そのPodがスケジュールできる場所が限定されます。ほとんどの場合、`hostPort`は不要なので、Serviceオブジェクトを使ってPodを公開するようにしてください。もし`hostPort` が必要な場合は、Kubernetes クラスタのノード数だけ Pod をスケジュールすることができます。 +* **あなたが使用しているのは`hostPort`**です。Podを`hostPort`にバインドすると、そのPodがスケジュールできる場所が限定されます。ほとんどの場合、`hostPort`は不要なので、Serviceオブジェクトを使ってPodを公開するようにしてください。もし`hostPort` が必要な場合は、Kubernetesクラスターのノード数だけPodをスケジュールすることができます。 #### Podがwaitingのまま From f7961d7792782a32820af4ff3d76621098e87f9a Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:20:52 +0900 Subject: [PATCH 072/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index ec29edba47..b808053798 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -59,7 +59,7 @@ Podが`Waiting`状態で止まっている場合、ワーカーノードにス #### Podがクラッシュするなどの不健全な状態 -Podがスケジュールされると、[Debug Running Pods](/docs/tasks/debug-application-cluster/debug-running-pod/)で説明されているメソッドがデバッグに利用できるようになります。 +Podがスケジュールされると、[Debug Running Pods](/docs/tasks/debug-application-cluster/debug-running-pod/)で説明されている方法がデバッグに利用できるようになります。 #### Podが期待する通りに動きません From 0e89570bc47ca9c56fdce2177a6d1ff59d397631 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:00 +0900 Subject: [PATCH 073/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index b808053798..a35ea52bda 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -63,7 +63,7 @@ Podがスケジュールされると、[Debug Running Pods](/docs/tasks/debug-ap #### Podが期待する通りに動きません -Podが期待した動作をしない場合、ポッドの記述（ローカルマシンの `mypod.yaml` ファイルなど）に誤りがあり、ポッド作成時にその誤りが黙って無視された可能性があります。Pod記述のセクションのネストが正しくないか、キー名が間違って入力されていることがよくあり、そのため、そのキーは無視されます。たとえば、`command`のスペルを`commnd`と間違えた場合、Podは作成されますが、あなたが意図したコマンドラインは使用されません。 +Podが期待した動作をしない場合、ポッドの記述(ローカルマシンの `mypod.yaml` ファイルなど)に誤りがあり、Pod作成時にその誤りが黙って無視された可能性があります。Pod記述のセクションのネストが正しくないか、キー名が間違って入力されていることがよくあり、そのようなとき、そのキーは無視されます。たとえば、`command`のスペルを`commnd`と間違えた場合、Podは作成されますが、あなたが意図したコマンドラインは使用されません。 まずPodを削除して、`--validate` オプションを付けて再度作成してみてください。 例えば、`kubectl apply --validate -f mypod.yaml`と実行します。 From a87c55f8096057859842d2bb26d21c4c26d6003d Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:11 +0900 Subject: [PATCH 074/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index a35ea52bda..9008dac8ad 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -67,7 +67,7 @@ Podが期待した動作をしない場合、ポッドの記述(ローカルマ まずPodを削除して、`--validate` オプションを付けて再度作成してみてください。 例えば、`kubectl apply --validate -f mypod.yaml`と実行します。 -command`のスペルを`commnd`に間違えると、以下のようなエラーになります。 +`command`のスペルを`commnd`に間違えると、以下のようなエラーになります。 ```shell I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd From cadb23938da80948f86071c453850c0ecb80dee9 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:17 +0900 Subject: [PATCH 075/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 9008dac8ad..0f093b4ad3 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -77,7 +77,7 @@ pods/mypod -次に確認することは、apiserver上のPodが、作成しようとしたPod（例えば、ローカルマシンのyamlファイル）と一致しているかどうかです。 +次に確認することは、apiserver上のPodが、作成しようとしたPod(例えば、ローカルマシンのyamlファイル)と一致しているかどうかです。 例えば、`kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml` を実行して、元のポッドの説明である`mypod.yaml`とapiserverから戻ってきた`mypod-on-apiserver.yaml`を手動で比較してみてください。 通常、"apiserver" バージョンには、元のバージョンにはない行がいくつかあります。これは予想されることです。 しかし、もし元のバージョンにある行がapiserverバージョンにない場合、これはあなたのPod specに問題があることを示している可能性があります。 From 51fbb58590ac0268a830506528df8cc324087d3f Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:23 +0900 Subject: [PATCH 076/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 0f093b4ad3..38c252ddc4 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -82,7 +82,7 @@ pods/mypod 通常、"apiserver" バージョンには、元のバージョンにはない行がいくつかあります。これは予想されることです。 しかし、もし元のバージョンにある行がapiserverバージョンにない場合、これはあなたのPod specに問題があることを示している可能性があります。 -### レプリケーションコントローラのデバッグ +### レプリケーションコントローラーのデバッグ レプリケーションコントローラはかなり単純なものです。 彼らはPodを作ることができるか、できないか、どちらかです。 From 9e4294faed84f47923246f6d3eb214cff3f1575c Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:30 +0900 Subject: [PATCH 077/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 38c252ddc4..2268d45fb4 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -84,7 +84,7 @@ pods/mypod ### レプリケーションコントローラーのデバッグ -レプリケーションコントローラはかなり単純なものです。 +レプリケーションコントローラーはかなり単純なものです。 彼らはPodを作ることができるか、できないか、どちらかです。 もしPodを作成できないのであれば、[instructions above](#debugging-pods)を参照して、Podをデバッグしてください。 また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラに関連するイベントをイントロスペクトすることができます。 From 4e5ceafe6d880e647ccd4ae307e425730046b0eb Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:36 +0900 Subject: [PATCH 078/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 2268d45fb4..b9e85db103 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -86,7 +86,7 @@ pods/mypod レプリケーションコントローラーはかなり単純なものです。 彼らはPodを作ることができるか、できないか、どちらかです。 -もしPodを作成できないのであれば、[instructions above](#debugging-pods)を参照して、Podをデバッグしてください。 +もしPodを作成できないのであれば、[上記の説明](#debugging-pods)を参照して、Podをデバッグしてください。 また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラに関連するイベントをイントロスペクトすることができます。 ### サービスのデバッグ From d8890fa7128fc143e6a8a26a8a189f440e118052 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:42 +0900 Subject: [PATCH 079/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index b9e85db103..d560a93b22 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -87,7 +87,7 @@ pods/mypod レプリケーションコントローラーはかなり単純なものです。 彼らはPodを作ることができるか、できないか、どちらかです。 もしPodを作成できないのであれば、[上記の説明](#debugging-pods)を参照して、Podをデバッグしてください。 -また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラに関連するイベントをイントロスペクトすることができます。 +また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラーに関連するイベントを確認することができます。 ### サービスのデバッグ From c8e5a4e187ec68fd67cce8fe7dcaf8071853835c Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:47 +0900 Subject: [PATCH 080/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index d560a93b22..100f777758 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -89,7 +89,7 @@ pods/mypod もしPodを作成できないのであれば、[上記の説明](#debugging-pods)を参照して、Podをデバッグしてください。 また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラーに関連するイベントを確認することができます。 -### サービスのデバッグ +### Serviceのデバッグ サービスは、ポッドのセット全体でロードバランシングを提供します。 サービスが正しく動作しない原因には、いくつかの一般的な問題があります。 From 0258f297dd2ff9e7e89a111547ced1627ef7ce07 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:52 +0900 Subject: [PATCH 081/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 100f777758..505b01b3df 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -91,7 +91,7 @@ pods/mypod ### Serviceのデバッグ -サービスは、ポッドのセット全体でロードバランシングを提供します。 +Serviceは、Podの集合全体でロードバランシングを提供します。 サービスが正しく動作しない原因には、いくつかの一般的な問題があります。 以下の手順は、サービスの問題をデバッグするのに役立つはずです。 From 5860445100d6d592c5659b3cef0e2bbec5b74f7f Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:21:58 +0900 Subject: [PATCH 082/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 505b01b3df..7a2a860a69 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -92,7 +92,7 @@ pods/mypod ### Serviceのデバッグ Serviceは、Podの集合全体でロードバランシングを提供します。 -サービスが正しく動作しない原因には、いくつかの一般的な問題があります。 +Serviceが正しく動作しない原因には、いくつかの一般的な問題があります。 以下の手順は、サービスの問題をデバッグするのに役立つはずです。 From dc157188ee5b7dad4869fa1a576712c23ce8a8ae Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:22:04 +0900 Subject: [PATCH 083/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 7a2a860a69..f7ec86cbd9 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -94,7 +94,7 @@ pods/mypod Serviceは、Podの集合全体でロードバランシングを提供します。 Serviceが正しく動作しない原因には、いくつかの一般的な問題があります。 -以下の手順は、サービスの問題をデバッグするのに役立つはずです。 +以下の手順は、Serviceの問題をデバッグするのに役立つはずです。 まず、サービスのエンドポイントが存在することを確認します。 全てのサービスオブジェクトに対して、apiserverは `endpoints` リソースを利用できるようにします。 From 0d5bd1f3867d0e29f7293b753e03a9d899edeabc Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:22:09 +0900 Subject: [PATCH 084/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index f7ec86cbd9..42086c7e22 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -96,7 +96,7 @@ Serviceが正しく動作しない原因には、いくつかの一般的な問 以下の手順は、Serviceの問題をデバッグするのに役立つはずです。 -まず、サービスのエンドポイントが存在することを確認します。 +まず、Serviceに対応するEndpointが存在することを確認します。 全てのサービスオブジェクトに対して、apiserverは `endpoints` リソースを利用できるようにします。 このリソースは次のようにして見ることができます。 From 85a6b60e05b91b0f154a4341a9b5e68a33e454a5 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:22:14 +0900 Subject: [PATCH 085/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 42086c7e22..0f78f6cc35 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -97,7 +97,7 @@ Serviceが正しく動作しない原因には、いくつかの一般的な問 以下の手順は、Serviceの問題をデバッグするのに役立つはずです。 まず、Serviceに対応するEndpointが存在することを確認します。 -全てのサービスオブジェクトに対して、apiserverは `endpoints` リソースを利用できるようにします。 +全てのServiceオブジェクトに対して、apiserverは `endpoints` リソースを利用できるようにします。 このリソースは次のようにして見ることができます。 ```shell From 42df213b81e4b0637f4ff7346ddd67383727076f Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:22:20 +0900 Subject: [PATCH 086/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 0f78f6cc35..ca4bdce6bd 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -104,7 +104,7 @@ Serviceが正しく動作しない原因には、いくつかの一般的な問 kubectl get endpoints ${SERVICE_NAME} ``` -エンドポイントがサービスのメンバーとして想定されるPod数と一致していることを確認してください。 +EndpointがServiceのメンバーとして想定されるPod数と一致していることを確認してください。 例えば、3つのレプリカを持つnginxコンテナ用のサービスであれば、サービスのエンドポイントには3つの異なるIPアドレスが表示されるはずです。 #### サービスにエンドポイントがありません From d97de90faf22b2209a968255f11c296083432502 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:22:24 +0900 Subject: [PATCH 087/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index ca4bdce6bd..5f6dd3d8b6 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -105,7 +105,7 @@ kubectl get endpoints ${SERVICE_NAME} ``` EndpointがServiceのメンバーとして想定されるPod数と一致していることを確認してください。 -例えば、3つのレプリカを持つnginxコンテナ用のサービスであれば、サービスのエンドポイントには3つの異なるIPアドレスが表示されるはずです。 +例えば、3つのレプリカを持つnginxコンテナ用のServiceであれば、ServiceのEndpointには3つの異なるIPアドレスが表示されるはずです。 #### サービスにエンドポイントがありません From aace87316e259f1c6b922d28adc26ca99c5473c1 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:22:30 +0900 Subject: [PATCH 088/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 5f6dd3d8b6..761588a26e 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -107,7 +107,7 @@ kubectl get endpoints ${SERVICE_NAME} EndpointがServiceのメンバーとして想定されるPod数と一致していることを確認してください。 例えば、3つのレプリカを持つnginxコンテナ用のServiceであれば、ServiceのEndpointには3つの異なるIPアドレスが表示されるはずです。 -#### サービスにエンドポイントがありません +#### Serviceに対応するEndpointがありません エンドポイントが見つからない場合は、サービスが使用しているラベルを使用してポッドをリストアップしてみてください。 ラベルがあるところにServiceがあると想像してください。 From 87f2f38ee1a597fc7a313bdd3481567af125f464 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 4 Jan 2022 08:22:47 +0900 Subject: [PATCH 089/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 761588a26e..30a917d1e6 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -109,7 +109,7 @@ EndpointがServiceのメンバーとして想定されるPod数と一致して #### Serviceに対応するEndpointがありません -エンドポイントが見つからない場合は、サービスが使用しているラベルを使用してポッドをリストアップしてみてください。 +Endpointが見つからない場合は、Serviceが使用しているラベルを使用してPodをリストアップしてみてください。 ラベルがあるところにServiceがあると想像してください。 ```yaml From 2fa6918df060d889f352f7d63f550557f57b6a8f Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 10:39:52 +0900 Subject: [PATCH 090/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 7a976054d9..c76576f961 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -12,7 +12,7 @@ weight: 45 {{< feature-state for_k8s_version="v1.21" state="alpha" >}} *サービス内部トラフィックポリシー*を使用すると、内部トラフィック制限により、トラフィックが発信されたノード内のエンドポイントにのみ内部トラフィックをルーティングできます。 -ここでの「内部」トラフィックとは、現在のクラスターのポッドから発信されたトラフィックを指します。これは、コストを削減し、パフォーマンスを向上させるのに役立ちます。 +ここでの「内部」トラフィックとは、現在のクラスターのPodから発信されたトラフィックを指します。これは、コストを削減し、パフォーマンスを向上させるのに役立ちます。 From e558ee70e085eb005c66cbe9c4a0f4cbcf7cdee2 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 10:40:05 +0900 Subject: [PATCH 091/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index c76576f961..2d26476aa3 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -23,7 +23,7 @@ weight: 45 これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 {{< note >}} -特定のサービスのエンドポイントがないノード上のポッドの場合、サービスに他のノードのエンドポイントがある場合でも、サービスは（このノード上のポッドの）エンドポイントがゼロであるかのように動作します。 +特定のServiceのエンドポイントがないノード上のPodの場合、Serviceに他のノードのエンドポイントがある場合でも、Serviceは(このノード上のポッドの)エンドポイントがゼロであるかのように動作します。 {{< /note >}} 次の例は、`.spec.internalTrafficPolicy`を`Local`に設定した場合のサービスの様子を示しています： From 47010c1ff78e325bd0e072a681d76256364dfbe5 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 10:40:12 +0900 Subject: [PATCH 092/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 2d26476aa3..c8aacdd2ac 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -16,7 +16,7 @@ weight: 45 -## サービス内部トラフィックポリシーの使用 +## ServiceInternalTrafficPolicyの使用 `ServiceInternalTrafficPolicy` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 From 9de1412a98656300b72a27447dbb9aa74f62adf0 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 10:40:16 +0900 Subject: [PATCH 093/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index c8aacdd2ac..7abc15feb8 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -26,7 +26,7 @@ weight: 45 特定のServiceのエンドポイントがないノード上のPodの場合、Serviceに他のノードのエンドポイントがある場合でも、Serviceは(このノード上のポッドの)エンドポイントがゼロであるかのように動作します。 {{< /note >}} -次の例は、`.spec.internalTrafficPolicy`を`Local`に設定した場合のサービスの様子を示しています： +次の例は、`.spec.internalTrafficPolicy`を`Local`に設定した場合のServiceの様子を示しています： ```yaml apiVersion: v1 From 0af73e658d7237ce62bd435de81c820615a600eb Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 10:41:22 +0900 Subject: [PATCH 094/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 7abc15feb8..5f77e03f1b 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -51,7 +51,7 @@ kube-proxyは、`spec.internalTrafficPolicy`設定に基づいて、ルーティ ## 制約 -* サービスで`externalTrafficPolicy`が`Local`に設定されている場合、サービス内部トラフィックポリシーは使用されません。同じサービスではなく、異なるサービスの同じクラスターで両方の機能を使用することができます。 +* Serviceで`externalTrafficPolicy`が`Local`に設定されている場合、サービス内部トラフィックポリシーは使用されません。同じServiceだけではなく、同じクラスター内の異なるServiceで両方の機能を使用することができます。 ## {{% heading "whatsnext" %}} From fb59286f026844eb48245702c43fdc924b79bf13 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 10:41:39 +0900 Subject: [PATCH 095/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: nasa9084 --- .../concepts/services-networking/service-traffic-policy.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 5f77e03f1b..9c0c512633 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -18,8 +18,7 @@ weight: 45 ## ServiceInternalTrafficPolicyの使用 -`ServiceInternalTrafficPolicy` -[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 +`ServiceInternalTrafficPolicy` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 {{< note >}} From 95d4b8c9d73af1cbe1f5e012091e01068b4df71b Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 11:06:12 +0900 Subject: [PATCH 096/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 9c0c512633..82f85bb0de 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -44,7 +44,7 @@ spec: ## 使い方 -kube-proxyは、`spec.internalTrafficPolicy`設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 +kube-proxyは、`spec.internalTrafficPolicy`の設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 `Local`に設定されている場合、ノードのローカルエンドポイントのみが考慮されます。`Cluster`であるか欠落している場合、すべてのエンドポイントが考慮されます。 `ServiceInternalTrafficPolicy`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは"Cluster"です。 From f6b5958b034c355c879ea8882ab4f7926150b56d Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 11:07:19 +0900 Subject: [PATCH 097/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 82f85bb0de..5f6bb9d037 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -46,7 +46,7 @@ spec: kube-proxyは、`spec.internalTrafficPolicy`の設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 `Local`に設定されている場合、ノードのローカルエンドポイントのみが考慮されます。`Cluster`であるか欠落している場合、すべてのエンドポイントが考慮されます。 -`ServiceInternalTrafficPolicy`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは"Cluster"です。 +`ServiceInternalTrafficPolicy`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは`Cluster`です。 ## 制約 From 0068f7b226dc35e748d53d39ff7779cc3eaccc0e Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 11:07:56 +0900 Subject: [PATCH 098/254] Update content/ja/docs/concepts/services-networking/service-traffic-policy.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../docs/concepts/services-networking/service-traffic-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 5f6bb9d037..69337320dc 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -45,7 +45,7 @@ spec: ## 使い方 kube-proxyは、`spec.internalTrafficPolicy`の設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 -`Local`に設定されている場合、ノードのローカルエンドポイントのみが考慮されます。`Cluster`であるか欠落している場合、すべてのエンドポイントが考慮されます。 +`spec.internalTrafficPolicy`が`Local`であれば、ノードのローカルエンドポイントにのみルーティングできるようにします。`Cluster`または未設定であればすべてのエンドポイントにルーティングできるようにします。 `ServiceInternalTrafficPolicy`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは`Cluster`です。 ## 制約 From 8c4dcb2ee4456a8b0f70384a1671a31f2628048f Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 4 Jan 2022 13:26:04 +0900 Subject: [PATCH 099/254] Update service-traffic-policy.md --- .../concepts/services-networking/service-traffic-policy.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index 69337320dc..741c38c12a 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -1,6 +1,4 @@ --- -reviewers: -- maplain title: サービス内部トラフィックポリシー content_type: concept weight: 45 @@ -18,7 +16,7 @@ weight: 45 ## ServiceInternalTrafficPolicyの使用 -`ServiceInternalTrafficPolicy` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 +`ServiceInternalTrafficPolicy` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 {{< note >}} From 022bf26ab20831f902a05e00c4c2db9619cd5e35 Mon Sep 17 00:00:00 2001 From: bang9211 Date: Fri, 31 Dec 2021 15:24:06 +0900 Subject: [PATCH 100/254] Translate tasks/run-application/scale-stateful-set.md in Korean --- .../debug-cluster.md | 124 ++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 content/ko/docs/tasks/debug-application-cluster/debug-cluster.md diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md b/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md new file mode 100644 index 0000000000..7fdd2d7c37 --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md @@ -0,0 +1,124 @@ +--- + + +title: 클러스터 트러블슈팅 +content_type: concept +--- + + + +이 문서는 클러스터 트러블슈팅에 대해 설명한다. 사용자가 겪고 있는 문제의 근본 원인으로서 사용자의 애플리케이션을 +이미 배제했다고 가정한다. +애플리케이션 디버깅에 대한 팁은 [애플리케이션 트러블슈팅 가이드](/docs/tasks/debug-application-cluster/debug-application/)를 참조한다. +자세한 내용은 [트러블슈팅 문서](/docs/tasks/debug-application-cluster/troubleshooting/)를 참조한다. + + + +## 클러스터 나열하기 + +클러스터에서 가장 먼저 디버그해야 할 것은 노드가 모두 올바르게 등록되었는지 여부이다. + +다음을 실행한다. + +```shell +kubectl get nodes +``` + +그리고 보일 것으로 예상되는 모든 노드가 존재하고 모두 `Ready` 상태인지 확인한다. + +클러스터의 전반적인 상태에 대한 자세한 정보를 얻으려면 다음을 실행할 수 있다. + +```shell +kubectl cluster-info dump +``` +## 로그 보기 + +현재로서는 클러스터를 더 깊이 파고들려면 관련 머신에서 로그 확인이 필요하다. 관련 로그 파일 +위치는 다음과 같다. (systemd 기반 시스템에서는 `journalctl`을 대신 사용해야 할 수도 있다.) + +### 마스터 + + * `/var/log/kube-apiserver.log` - API 서버, API 제공을 담당 + * `/var/log/kube-scheduler.log` - 스케줄러, 스케줄 결정을 담당 + * `/var/log/kube-controller-manager.log` - 레플리케이션 컨트롤러를 담당하는 컨트롤러 + +### 워커 노드 + + * `/var/log/kubelet.log` - Kubelet, 노드에서 컨테이너 실행을 담당 + * `/var/log/kube-proxy.log` - Kube Proxy, 서비스 로드밸런싱을 담당 + +## 클러스터 장애 모드의 일반적인 개요 + +아래에 일부 오류 상황 예시 및 문제를 완화하기 위해 클러스터 설정을 조정하는 방법을 나열한다. + +### 근본 원인 + + - VM(들) 종료 + - 클러스터 내 또는 클러스터와 사용자 간의 네트워크 분할 + - 쿠버네티스 소프트웨어의 충돌 + - 데이터 손실 또는 퍼시스턴트 스토리지 사용 불가 (e.g. GCE PD 또는 AWS EBS 볼륨) + - 운영자 오류, 예를 들면 잘못 구성된 쿠버네티스 소프트웨어 또는 애플리케이션 소프트웨어 + +### 특정 시나리오 + + - API 서버 VM 종료 또는 API 서버 충돌 + - 다음의 현상을 유발함 + - 새로운 파드, 서비스, 레플리케이션 컨트롤러를 중지, 업데이트 또는 시작할 수 없다. + - 쿠버네티스 API에 의존하지 않는 기존 파드 및 서비스는 계속 정상적으로 작동할 것이다. + - API 서버 백업 스토리지 손실 + - 다음의 현상을 유발함 + - API 서버가 구동되지 않을 것이다. + - kubelet에 도달할 수 없게 되지만, kubelet이 여전히 동일한 파드를 계속 실행하고 동일한 서비스 프록시를 제공할 것이다. + - API 서버를 재시작하기 전에, 수동으로 복구하거나 API서버 상태를 재생성해야 한다. + - 지원 서비스 (노드 컨트롤러, 레플리케이션 컨트롤러 매니저, 스케쥴러 등) VM 종료 또는 충돌 + - 현재 그것들은 API 서버와 같은 위치에 있기 때문에 API 서버와 비슷한 상황을 겪을 것이다. + - 미래에는 이들도 복제본을 가질 것이며 API서버와 별도로 배치될 수도 있다. + - 지원 서비스들은 상태(persistent state)를 자체적으로 유지하지는 않는다. + - 개별 노드 (VM 또는 물리적 머신) 종료 + - 다음의 현상을 유발함 + - 해당 노드의 파드가 실행을 중지 + - 네트워크 분할 + - 다음의 현상을 유발함 + - 파티션 A는 파티션 B의 노드가 다운되었다고 생각한다. 파티션 B는 API 서버가 다운되었다고 생각한다. (마스터 VM이 파티션 A에 있다고 가정) + - Kubelet 소프트웨어 오류 + - 다음의 현상을 유발함 + - 충돌한 kubelet은 노드에서 새 파드를 시작할 수 없다. + - kubelet이 파드를 삭제할 수도 있고 삭제하지 않을 수도 있다. + - 노드는 비정상으로 표시된다. + - 레플리케이션 컨트롤러는 다른 곳에서 새 파드를 시작한다. + - 클러스터 운영자 오류 + - 다음의 현상을 유발함 + - 파드, 서비스 등의 손실 + - API 서버 백업 저장소 분실 + - API를 읽을 수 없는 사용자 + - 기타 + +### 완화 + +- 조치: IaaS VM을 위한 IaaS 공급자의 자동 VM 다시 시작 기능을 사용한다. + - 다음을 완화할 수 있음: API 서버 VM 종료 또는 API 서버 충돌 + - 다음을 완화할 수 있음: 지원 서비스 VM 종료 또는 충돌 + +- 조치: API 서버+etcd가 있는 VM에 IaaS 제공자의 안정적인 스토리지(예: GCE PD 또는 AWS EBS 볼륨)를 사용한다. + - 다음을 완화할 수 있음: API 서버 백업 스토리지 손실 + +- 조치: [고가용성](/docs/setup/production-environment/tools/kubeadm/high-availability/) 구성을 사용한다. + - 다음을 완화할 수 있음: 컨트롤 플레인 노드 종료 또는 컨트롤 플레인 구성 요소(스케줄러, API 서버, 컨트롤러 매니저) 충돌 + - 동시에 발생하는 하나 이상의 노드 또는 구성 요소 오류를 허용한다. + - 다음을 완화할 수 있음: API 서버 백업 스토리지(i.e., etcd의 데이터 디렉터리) 손실 + - 고가용성 etcd 구성을 사용하고 있다고 가정 + +- 조치: API 서버 PD/EBS 볼륨의 주기적인 스냅샷 + - 다음을 완화할 수 있음: API 서버 백업 스토리지 손실 + - 다음을 완화할 수 있음: 일부 운영자 오류 사례 + - 다음을 완화할 수 있음: 일부 쿠버네티스 소프트웨어 오류 사례 + +- 조치: 파드 앞에 레플리케이션 컨트롤러와 서비스 사용 + - 다음을 완화할 수 있음: 노드 종료 + - 다음을 완화할 수 있음: Kubelet 소프트웨어 오류 + +- 조치: 예기치 않은 재시작을 허용하도록 설계된 애플리케이션(컨테이너) + - 다음을 완화할 수 있음: 노드 종료 + - 다음을 완화할 수 있음: Kubelet 소프트웨어 오류 + + From 208e4ed66c1170433c1fc6a6f029c5a1b8cb1870 Mon Sep 17 00:00:00 2001 From: "Claudia J. Kang" Date: Mon, 20 Dec 2021 21:54:29 +0900 Subject: [PATCH 101/254] [ko] Translate docs/tasks/debug-application-cluster/troubleshooting.md --- .../troubleshooting.md | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 content/ko/docs/tasks/debug-application-cluster/troubleshooting.md diff --git a/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md b/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md new file mode 100644 index 0000000000..de0629690b --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md @@ -0,0 +1,107 @@ +--- + + + +content_type: concept +title: 트러블슈팅하기 +--- + + + +때때로 문제가 발생할 수 있다. 이 가이드는 이러한 상황을 해결하기 위해 작성되었다. 문제 해결에는 +다음 두 가지를 참고해 볼 수 있다. + +* [애플리케이션 트러블슈팅하기](/docs/tasks/debug-application-cluster/debug-application/) - 쿠버네티스에 + 코드를 배포하였지만 제대로 동작하지 않는 사용자들에게 유용한 가이드이다. +* [클러스터 트러블슈팅하기](/docs/tasks/debug-application-cluster/debug-cluster/) - 쿠버네티스 클러스터에 + 문제를 겪고 있는 클러스터 관리자 혹은 기분이 나쁜 사람들에게 유용한 가이드이다. + +여러분이 현재 사용중인 릴리스에 대한 알려진 이슈들을 다음의 [릴리스](https://github.com/kubernetes/kubernetes/releases) +페이지에서 확인해 볼 수도 있다. + + + +## 도움 받기 + +여러분의 문제가 위에 소개된 어떠한 가이드로도 해결할 수 없다면, +쿠버네티스 커뮤니티로부터 도움을 받을 수 있는 다양한 방법들을 시도해 볼 수 있다. + +### 질문 + +이 사이트의 문서들은 다양한 질문들에 대한 답변을 제공할 수 있도록 구성되어 있다. +[개념](/ko/docs/concepts/)은 쿠버네티스의 아키텍처와 각 컴포넌트들이 어떻게 동작하는지에 대해 설명하고, +[시작하기](/ko/docs/setup/)는 쿠버네티스를 시작하는 데 유용한 지침들을 제공한다. +[태스크](/ko/docs/tasks/)는 흔히 사용되는 작업들을 수행하는 방법에 대해 소개하고, +[튜토리얼](/ko/docs/tutorials/)은 실무, 산업 특화 혹은 종단간 개발에 특화된 시나리오를 통해 차근차근 설명한다. +[레퍼런스](/ko/docs/reference/) 섹션에서는 +[쿠버네티스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)와 +[`kubectl`](/ko/docs/reference/kubectl/overview/)과 같은 커맨드 라인 인터페이스(CLI)에 대한 +상세한 설명을 다룬다. + +## 도와주세요! 내 질문이 다뤄지지 않았어요! 도움이 필요해요! + +### 스택 오버플로우 + +여러분들이 겪고 있는 문제와 동일한 문제에 대한 도움을 위해 커뮤니티의 다른 사람들이 이미 +질문을 올렸을 수 있다. 쿠버네티스 팀은 +[쿠버네티스 태그가 등록된 글](https://stackoverflow.com/questions/tagged/kubernetes)들을 모니터링하고 있다. +발생한 문제와 도움이 되는 질문이 없다면, +[새로운 질문](https://stackoverflow.com/questions/ask?tags=kubernetes)을 올려라! + +### 슬랙 + +쿠버네티스 슬랙의 `#kubernetes-users` 채널을 통해 쿠버네티스 커뮤니티의 여러 사람들을 접할 수도 있다. +쿠버네티스 슬랙을 사용하기 위해서는 등록이 필요한데, 다음을 통해 [채널 초대 요청](https://slack.kubernetes.io)을 할 수 있다. +(누구나 가입할 수 있다). 슬랙 채널은 여러분이 어떠한 질문을 할 수 있도록 언제나 열려있다. +가입하고 나면 여러분의 웹 브라우저나 슬랙 앱을 통해 [쿠버네티스 슬랙](https://kubernetes.slack.com) +에 참여할 수 있다. + +쿠버네티스 슬랙에 참여하게 된다면, 다양한 주제의 흥미와 관련된 여러 채널들에 대해 +살펴본다. 가령, 쿠버네티스를 처음 접하는 사람이라면 +[`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice) 채널에 가입할 수 있다. 혹은, 만약 당신이 개발자라면 +[`#kubernetes-dev`](https://kubernetes.slack.com/messages/kubernetes-dev) 채널에 가입할 수 있다. + +또한 각 국가 및 사용 언어별 채널들이 여럿 존재한다. 사용하는 언어로 도움을 받거나 정보를 +얻기 위해서는 다음의 채널에 참가한다. + +{{< table caption="국가 / 언어별 슬랙 채널" >}} +국가 | 채널 +:---------|:------------ +China(중국) | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events) +Finland(핀란드) | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users) +France(프랑스) | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events) +Germany(독일) | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events) +India(인도) | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events) +Italy(이탈리아) | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events) +Japan(일본) | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events) +Korea(한국) | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users) +Netherlands(네덜란드) | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users) +Norway(노르웨이) | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users) +Poland(폴란드) | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users) +Russia(러시아) | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users) +Spain(스페인) | [`#es-users`](https://kubernetes.slack.com/messages/es-users) +Sweden(스웨덴) | [`#se-users`](https://kubernetes.slack.com/messages/se-users) +Turkey(터키) | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events) +{{< /table >}} + +### 포럼 + +공식 쿠버네티스 포럼에 참여하는 것도 추천되는 방법이다. [discuss.kubernetes.io](https://discuss.kubernetes.io). + +### 버그와 기능 추가 요청 + +만약 여러분이 버그처럼 보이는 것을 발견했거나, 기능 추가 요청을 하기 위해서는 +[GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 사용한다. + +이슈를 작성하기 전에는, 여러분의 이슈가 기존 이슈에서 이미 +다뤄졌는지 검색해 본다. + +버그를 보고하는 경우에는, 해당 문제를 어떻게 재현할 수 있는지에 관련된 상세한 정보를 포함한다. +포함되어야 하는 정보들은 다음과 같다. + +* 쿠버네티스 버전: `kubectl version` +* 클라우드 프로바이더, OS 배포판, 네트워크 구성, 및 도커 버전 +* 문제를 재현하기 위한 절차 + + + From afe43b34e1b2e263603044983345ec1c631acb13 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 3 Jan 2022 16:18:23 +0900 Subject: [PATCH 102/254] [ko] Update outdated files in dev-1.23-ko.1 M71-82 --- .../kubeadm/adding-windows-nodes.md | 5 + .../kubeadm/kubeadm-upgrade.md | 16 -- .../administer-cluster/sysctl-cluster.md | 25 ++- .../configure-persistent-volume-storage.md | 11 +- .../pull-image-private-registry.md | 33 ++-- .../debug-running-pod.md | 18 +- .../resource-metrics-pipeline.md | 12 ++ .../extend-kubernetes/setup-konnectivity.md | 19 +- .../job/parallel-processing-expansion.md | 10 +- .../docs/tasks/network/validate-dual-stack.md | 5 +- .../horizontal-pod-autoscale-walkthrough.md | 162 ++++++++++++------ .../examples/pods/storage/pv-duplicate.yaml | 20 +++ 12 files changed, 214 insertions(+), 122 deletions(-) create mode 100644 content/ko/examples/pods/storage/pv-duplicate.yaml diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index e7a1b8fb79..4ce00186a3 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -1,4 +1,9 @@ --- + + + + + title: 윈도우 노드 추가 min-kubernetes-server-version: 1.17 content_type: tutorial diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 0e76e46c93..440f9d5026 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -78,10 +78,6 @@ OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리 apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. @@ -175,10 +171,6 @@ sudo kubeadm upgrade apply apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 @@ -218,10 +210,6 @@ sudo systemctl restart kubelet apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 @@ -256,10 +244,6 @@ sudo systemctl restart kubelet apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 diff --git a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md index 8adf5c4564..33bc3de55d 100644 --- a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md @@ -10,8 +10,20 @@ content_type: task {{< feature-state for_k8s_version="v1.21" state="stable" >}} 이 문서는 쿠버네티스 클러스터에서 {{< glossary_tooltip term_id="sysctl" >}} 인터페이스를 사용하여 -커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다. +커널 파라미터를 어떻게 구성하고, 사용하는지를 +설명한다. +{{< note >}} +쿠버네티스 버전 1.23부터, kubelet은 `/` 또는 `.`를 +sysctl 이름의 구분자로 사용하는 것을 지원한다. +예를 들어, 동일한 sysctl 이름을 `kernel.shm_rmid_forced`와 같이 마침표를 구분자로 사용하여 나타내거나 +`kernel/shm_rmid_forced`와 같이 슬래시를 구분자로 사용하여 나타낼 수 있다. +sysctl 파라미터 변환에 대한 세부 사항은 +리눅스 맨페이지 프로젝트의 +[sysctl.d(5)](https://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다. +파드와 파드시큐리티폴리시(PodSecurityPolicy)에 대해 sysctl을 설정하는 기능에서는 +아직 슬래시 구분자를 지원하지 않는다. +{{< /note >}} ## {{% heading "prerequisites" %}} @@ -20,6 +32,7 @@ content_type: task 일부 단계에서는 실행 중인 클러스터의 kubelet에서 커맨드 라인 옵션을 재구성할 필요가 있다. + ## 모든 sysctl 파라미터 나열 @@ -52,12 +65,13 @@ sysctl은 _safe_ sysctl과 _unsafe_ sysctl로 구성되어 있다. _safe_ sysctl 허용하지 않아야 한다 아직까지 대부분 _네임스페이스된_ sysctl은 _safe_ sysctl로 고려되지 않았다. ->>> 다음 sysctl은 _safe_ 명령을 지원한다. +다음 sysctl은 _safe_ 명령을 지원한다. - `kernel.shm_rmid_forced`, - `net.ipv4.ip_local_port_range`, - `net.ipv4.tcp_syncookies`, -- `net.ipv4.ping_group_range` (Kubernetes 1.18 이후). +- `net.ipv4.ping_group_range` (쿠버네티스 1.18 이후), +- `net.ipv4.ip_unprivileged_port_start` (쿠버네티스 1.22 이후). {{< note >}} `net.ipv4.tcp_syncookies` 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다. @@ -112,10 +126,13 @@ _네임스페이스_ sysctl만 이 방법을 사용할 수 있다. 이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나 특권있는 컨테이너의 데몬셋을 사용하여야 한다. -네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다. +네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. +securityContext는 동일한 파드의 모든 컨테이너에 적용된다. 이 예시는 safe sysctl `kernel.shm_rmid_forced`와 두 개의 unsafe sysctl인 `net.core.somaxconn` 과 `kernel.msgmax` 를 설정하기 위해 파드 securityContext를 사용한다. +스펙에 따르면 _safe_ sysctl과 _unsafe_ sysctl 간 +차이는 없다. {{< warning >}} 파라미터의 영향을 파악한 후에만 운영체제가 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 3461c57061..a2bac74f99 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -96,11 +96,10 @@ hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다. 설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고 지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가 -읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 -지정한다. 여기서는 +읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 지정한다. 여기서는 퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을 `manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을 -이 퍼시스턴트볼륨에 바인딩하는데 사용한다. +이 퍼시스턴트볼륨에 바인딩하는 데 사용한다. 퍼시스턴트볼륨을 생성한다. @@ -237,8 +236,14 @@ sudo rmdir /mnt/data 이제 사용자 노드에서 셸을 종료해도 된다. +## 하나의 퍼시스턴트볼륨을 두 경로에 마운트하기 +{{< codenew file="pods/storage/pv-duplicate.yaml" >}} +하나의 퍼시스턴트볼륨을 nginx 컨테이너의 두 경로에 마운트할 수 있다. + +`/usr/share/nginx/html` - 정적 웹사이트 용 +`/etc/nginx/nginx.conf` - 기본 환경 설정 용 diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index bb14d1c0ac..3a33d7a5fc 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -6,29 +6,36 @@ weight: 100 -이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 +이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 +{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을 사용하는 파드를 생성하는 방법을 보여준다. +{{% thirdparty-content single="true" %}} + ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "task-tutorial-prereqs.md" >}} -* 이 실습을 수행하기 위해, -[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다. +* 이 실습을 수행하기 위해, `docker` 명령줄 도구와 +[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다. -## 도커 로그인 +## 도커 허브 로그인 노트북에 프라이빗 이미지를 받아오기 위하여 레지스트리 인증을 필수로 수행해야 한다. +`docker` 도구를 사용하여 도커 허브에 로그인한다. 자세한 정보는 +[도커 ID 계정](https://docs.docker.com/docker-id/#log-in)의 _로그 인_ 섹션을 참조한다. + ```shell docker login ``` -프롬프트가 나타나면, 도커 사용자 이름(username)과 비밀번호(password)를 입력하자. +프롬프트가 나타나면, 도커 ID를 입력한 다음, 사용하려는 자격증명(액세스 토큰, +또는 도커 ID의 비밀번호)을 입력한다. -로그인 프로세스는 권한 토큰 정보를 가지고 있는 `config.json` 파일을 생성하거나 업데이트 한다. +로그인 프로세스를 수행하면 권한 토큰 정보를 가지고 있는 `config.json` 파일이 생성되거나 업데이트된다. [쿠버네티스가 이 파일을 어떻게 해석하는지](/ko/docs/concepts/containers/images#config-json) 참고한다. `config.json` 파일을 확인하자. @@ -171,14 +178,14 @@ janedoe:xxxxxxxxxxx ## 시크릿을 사용하는 파드 생성하기 -다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 파드의 구성 파일이다. +다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 예제 파드의 매니페스트이다. {{< codenew file="pods/private-reg-pod.yaml" >}} -아래의 파일을 다운로드받는다. +위 파일을 컴퓨터에 다운로드한다. ```shell -wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml ``` `my-private-reg-pod.yaml` 파일 안에서, `` 값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다. @@ -200,9 +207,9 @@ kubectl get pod private-reg ## {{% heading "whatsnext" %}} -* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기. +* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기 + * 또는 {{< api-reference page="config-and-storage-resources/secret-v1" >}} API 레퍼런스 읽어보기 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기. * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기. * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기. -* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기. -* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기. +* 파드의 [컨테이너 정의](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)의 `imagePullSecrets` 필드에 대해 읽어보기 diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md index 1c2073a21b..cbd69454f5 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -73,24 +73,16 @@ kubectl exec -it cassandra -- sh ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container} -{{< feature-state state="alpha" for_k8s_version="v1.18" >}} +{{< feature-state state="beta" for_k8s_version="v1.23" >}} -컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 -컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 -`kubectl exec`가 충분하지 않을 경우에는 +컨테이너가 크래시 됐거나 +[distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 +컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 `kubectl exec`로는 충분하지 않은 경우에는 {{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이 -인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18` -버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의 -명령어가 있다. +인터랙티브한 트러블슈팅에 유용하다. ### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example} -{{< note >}} -이 섹션에서 소개하는 예시를 사용하기 위해서는 -여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다. -{{< /note >}} - `kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다. 먼저, 다음과 같이 파드를 추가한다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index e4bf6a1715..a4d64e016e 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -1,4 +1,7 @@ --- + + + title: 리소스 메트릭 파이프라인 content_type: concept --- @@ -62,3 +65,12 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다. [설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. + +### 요약(Summary) API 소스 +[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며, +소비자(consumer)가 읽을 수 있도록 이를 +[요약 API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)에 기록한다. + +1.23 이전에는 이러한 자원들은 기본적으로 [cAdvisor](https://github.com/google/cadvisor)에 의해 수집되었다. +그러나, 1.23에서 `PodAndContainerStatsFromCRI` 기능 게이트가 추가되면서, 컨테이너 및 파드 수준 통계를 CRI 구현에서 수집할 수 있게 되었다. +참고: 이를 위해서는 CRI 구현에서도 이 기능을 지원해야 한다(containerd >= 1.6.0, CRI-O >= 1.23.0). diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md index fdf671a52a..5bc131af19 100644 --- a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -11,7 +11,11 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} +쿠버네티스 클러스터가 있어야 하며, kubectl 명령줄 도구가 +클러스터와 통신하도록 설정되어 있어야 한다. 컨트롤 플레인 호스트가 아닌 +두 개 이상의 노드로 구성된 클러스터에서 이 튜토리얼을 수행하는 것을 권장한다. +클러스터가 없다면, [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)를 +이용하여 생성할 수 있다. @@ -24,16 +28,9 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T Konnectivity 서비스를 사용하고 네트워크 트래픽을 클러스터 노드로 보내도록 API 서버를 구성해야 한다. -1. `ServiceAccountTokenVolumeProjection` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있는지 -확인한다. kube-apiserver에 다음과 같은 플래그를 제공하여 -[서비스 어카운트 토큰 볼륨 보호](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)를 -활성화할 수 있다. - ``` - --service-account-issuer=api - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key - --api-audiences=system:konnectivity-server - ``` +1. [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) +기능이 활성화되어 있는지 확인한다. +쿠버네티스 v1.20부터는 기본적으로 활성화되어 있다. 1. `admin/konnectivity/egress-selector-configuration.yaml`과 같은 송신 구성 파일을 생성한다. 1. API 서버의 `--egress-selector-config-file` 플래그를 API 서버 송신 구성 파일의 경로로 설정한다. diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md index fbf105024d..5870b4b314 100644 --- a/content/ko/docs/tasks/job/parallel-processing-expansion.md +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -178,13 +178,13 @@ kubectl delete job -l jobgroup=jobexample ```liquid -{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, +{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, { "name": "banana", "url": "http://dbpedia.org/resource/Banana", }, { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }] %} -{%- for p in params %} -{%- set name = p["name"] %} -{%- set url = p["url"] %} +{% for p in params %} +{% set name = p["name"] %} +{% set url = p["url"] %} --- apiVersion: batch/v1 kind: Job @@ -204,7 +204,7 @@ spec: image: busybox command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] restartPolicy: Never -{%- endfor %} +{% endfor %} ``` 위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해 diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 97753165f1..6c14644db1 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -3,7 +3,7 @@ -min-kubernetes-server-version: v1.20 +min-kubernetes-server-version: v1.23 title: IPv4/IPv6 이중 스택 검증 content_type: task --- @@ -21,6 +21,9 @@ content_type: task {{< version-check >}} +{{< note >}} +v1.23 이전 버전에서도 검증을 수행할 수 있지만 GA 기능으로만 제공되며, v1.23부터 공식적으로 지원된다. +{{< /note >}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index a910dc5c48..d1e864476a 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -4,42 +4,59 @@ -title: Horizontal Pod Autoscaler 연습 +title: HorizontalPodAutoscaler 연습 content_type: task weight: 100 +min-kubernetes-server-version: 1.23 --- -Horizontal Pod Autoscaler는 -CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 -레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. +[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(약어: HPA)는 +워크로드 리소스(예: {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는 +{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 +자동으로 업데이트하며, +워크로드의 크기를 수요에 맞게 +자동으로 스케일링하는 것을 목표로 한다. -이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. -Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 -[Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. +수평 스케일링은 부하 증가에 대해 +{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다. +이는 _수직_ 스케일링(쿠버네티스에서는, +해당 워크로드를 위해 이미 실행 중인 파드에 +더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다. + +부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, +HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, +또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다. + +이 문서는 예제 웹 앱의 크기를 자동으로 조절하도록 +HorizontalPodAutoscaler를 설정하는 예시를 다룬다. +이 예시 워크로드는 PHP 코드를 실행하는 아파치 httpd이다. ## {{% heading "prerequisites" %}} -이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 -[메트릭 API](https://github.com/kubernetes/metrics)를 통해 메트릭을 제공해야 한다. -Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면, -[메트릭-서버 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다. +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 이전 버전의 +쿠버네티스를 사용하고 있다면, 해당 버전의 문서를 +참고한다([사용 가능한 문서의 버전](/ko/docs/home/supported-doc-versions/) 참고). -Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, -버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 -사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. -마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우, -버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 -메트릭 API와 통신이 가능해야 한다. -자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다. +이 예제를 실행하기 위해, 클러스터에 [Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme)가 +배포 및 구성되어 있어야 한다. 쿠버네티스 Metrics Server는 클러스터의 +{{}}으로부터 +리소스 메트릭을 수집하고, 수집한 메트릭을 +[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 통해 노출시키며, +메트릭 수치를 나타내는 새로운 종류의 리소스를 추가하기 위해 +[APIService](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용할 수 있다. + +Metrics Server를 실행하는 방법을 보려면 +[metrics-server 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다. ## php-apache 서버 구동 및 노출 -Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다. +HorizontalPodAutoscaler 예시에서, +먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다. +`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다. ```dockerfile FROM php:5-apache @@ -47,7 +64,8 @@ COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` -index.php는 CPU 과부하 연산을 수행한다. +아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며, +이를 이용해 클러스터에 부하를 시뮬레이트한다. ```php ``` -첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를 -시작하고 서비스로 노출시킨다. +컨테이너 이미지를 만들었다면, +방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를 +{{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다. {{< codenew file="application/php-apache.yaml" >}} -다음의 명령어를 실행한다. +이를 위해, 다음의 명령어를 실행한다. ```shell kubectl apply -f https://k8s.io/examples/application/php-apache.yaml @@ -75,16 +94,27 @@ deployment.apps/php-apache created service/php-apache created ``` -## Horizontal Pod Autoscaler 생성 +## HorizontalPodAutoscaler 생성 {#create-horizontal-pod-autoscaler} -이제 서비스가 동작중이므로, -[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 사용하여 오토스케일러를 생성한다. -다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 -1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다. -간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. -kubectl run으로 각 파드는 200 밀리코어를 요청하므로, -여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다. -이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다. +이제 서비스가 동작중이므로, +`kubectl`을 사용하여 오토스케일러를 생성한다. 이를 위해 +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 서브커맨드를 사용할 수 있다. + +아래에서는 첫 번째 단계에서 만든 php-apache +디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 +Horizontal Pod Autoscaler를 생성하는 명령어를 실행할 것이다. + +간단히 이야기하면, HPA {{}}는 +평균 CPU 사용량을 50%로 유지하기 위해 (디플로이먼트를 업데이트하여) 레플리카의 개수를 늘리고 줄인다. +그러면 디플로이먼트는 레플리카셋을 업데이트하며(이는 모든 쿠버네티스 디플로이먼트의 동작 방식 중 일부이다), +레플리카셋은 자신의 `.spec` 필드의 변경 사항에 따라 파드를 추가하거나 제거한다. + +`kubectl run`으로 각 파드는 200 밀리코어를 요청하므로, 평균 CPU 사용은 100 밀리코어이다. +알고리즘에 대한 세부 사항은 +[알고리즘 세부 정보](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고한다. + + +HorizontalPodAutoscaler를 생성한다. ```shell kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 @@ -94,47 +124,64 @@ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 horizontalpodautoscaler.autoscaling/php-apache autoscaled ``` -실행 중인 오토스케일러의 현재 상태를 확인해본다. +다음을 실행하여, 새로 만들어진 HorizontalPodAutoscaler의 현재 상태를 확인할 수 있다. ```shell +# "hpa" 또는 "horizontalpodautoscaler" 둘 다 사용 가능하다. kubectl get hpa ``` +출력은 다음과 같다. ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s ``` -아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다. -(``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다) +(HorizontalPodAutoscalers 이름이 다르다면, 이미 기존에 존재하고 있었다는 뜻이며, +보통은 문제가 되지 않는다.) -## 부하 증가 +아직 서버로 요청을 보내는 클라이언트가 없기 때문에, 현재 CPU 사용량이 0%임을 확인할 수 있다. +(``TARGET`` 열은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다) -이번에는 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다. 먼저 컨테이너를 하나 실행하고, php-apache 서비스에 무한루프의 쿼리를 전송한다(다른 터미널을 열어 수행하기 바란다). +## 부하 증가시키기 {#increase-load} +다음으로, 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다. +이를 위해, 클라이언트 역할을 하는 다른 파드를 실행할 것이다. +클라이언트 파드 안의 컨테이너가 php-apache 서비스에 쿼리를 보내는 무한 루프를 실행한다. ```shell +# 부하 생성을 유지하면서 나머지 스텝을 수행할 수 있도록, +# 다음의 명령을 별도의 터미널에서 실행한다. kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done" ``` -실행 후, 약 1분 정도 후에 CPU 부하가 올라가는 것을 볼 수 있다. - +이제 아래 명령을 실행한다. ```shell +# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다. kubectl get hpa ``` +1분 쯤 지나면, 다음과 같이 CPU 부하가 올라간 것을 볼 수 있다. + ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m ``` -CPU 소비가 305%까지 증가하였다. -결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다. +그리고 다음과 같이 레플리카의 수가 증가한 것도 볼 수 있다. +``` +NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE +php-apache Deployment/php-apache/scale 305% / 50% 1 10 7 3m +``` + +CPU 사용률이 305%까지 증가하였다. +결과적으로, 디플로이먼트의 레플리카 개수가 7개까지 증가하였다. ```shell kubectl get deployment php-apache ``` +HorizontalPodAutoscaler를 조회했을 때와 동일한 레플리카 수를 확인할 수 있다. ``` NAME READY UP-TO-DATE AVAILABLE AGE php-apache 7/7 7 7 19m @@ -146,24 +193,27 @@ php-apache 7/7 7 7 19m 최종 레플리카의 개수는 본 예제와 다를 수 있다. {{< /note >}} -## 부하 중지 +## 부하 발생 중지하기 {#stop-load} 본 예제를 마무리하기 위해 부하를 중단시킨다. -`busybox` 컨테이너를 띄운 터미널에서, +`busybox` 파드를 띄운 터미널에서, ` + C`로 부하 발생을 중단시킨다. 그런 다음 (몇 분 후에) 결과를 확인한다. ```shell -kubectl get hpa +# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다. +kubectl get hpa php-apache --watch ``` +출력은 다음과 같다. ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m ``` +디플로이먼트도 스케일 다운 했음을 볼 수 있다. ```shell kubectl get deployment php-apache ``` @@ -173,7 +223,7 @@ NAME READY UP-TO-DATE AVAILABLE AGE php-apache 1/1 1 1 27m ``` -CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮췄다. +CPU 사용량이 0으로 떨어져서, HPA가 자동으로 레플리카의 개수를 1로 줄였다. {{< note >}} 레플리카 오토스케일링은 몇 분 정도 소요된다. @@ -184,9 +234,9 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 ## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링 `php-apache` 디플로이먼트를 오토스케일링할 때, -`autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. +`autoscaling/v2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. -첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. +첫 번째로, `autoscaling/v2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. ```shell kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml @@ -195,7 +245,7 @@ kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml 에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다. ```yaml -apiVersion: autoscaling/v2beta2 +apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache @@ -287,7 +337,7 @@ HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수 `kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다. ```yaml -apiVersion: autoscaling/v2beta2 +apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache @@ -411,7 +461,7 @@ object: ## 부록: Horizontal Pod Autoscaler 상태 조건 -HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면, +HorizontalPodAutoscaler의 `autoscaling/v2` 형식을 사용하면, HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다. 이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지, 어떤 방식으로든 제한되어 있는지 여부를 나타낸다. @@ -449,12 +499,12 @@ Events: 백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다. 두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지), 원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우, -일반적으로 메트릭을 가져오는데 문제가 있다. +일반적으로 메트릭을 가져오는 데 문제가 있다. 마지막으로, 마지막 조건인 `ScalingLimited`는 원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다. 이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다. -## 부록: 수량 +## 수량 HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 쿠버네티스에서 사용하는 @@ -464,16 +514,16 @@ HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 일반적으로 수량을 밀리단위로 반환한다. 10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다. -## 부록: 다른 가능한 시나리오 +## 다른 가능한 시나리오 ### 명시적으로 오토스케일러 만들기 HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고, -명시적으로 다음 파일을 사용하여 만들 수 있다. +명시적으로 다음 매니페스트를 사용하여 만들 수 있다. {{< codenew file="application/hpa/php-apache.yaml" >}} -다음 명령어를 실행하여 오토스케일러를 생성할 것이다. +다음으로, 아래의 명령어를 실행하여 오토스케일러를 생성한다. ```shell kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml diff --git a/content/ko/examples/pods/storage/pv-duplicate.yaml b/content/ko/examples/pods/storage/pv-duplicate.yaml new file mode 100644 index 0000000000..15a48acbed --- /dev/null +++ b/content/ko/examples/pods/storage/pv-duplicate.yaml @@ -0,0 +1,20 @@ + +apiVersion: v1 +kind: Pod +metadata: + name: test +spec: + containers: + - name: test + image: nginx + volumeMounts: + - name: site-data + mountPath: /usr/share/nginx/html + subPath: html + - name: config + mountPath: /etc/nginx/nginx.conf + subPath: nginx.conf + volumes: + - name: config + persistentVolumeClaim: + claimName: test-nfs-claim \ No newline at end of file From 0c61c48529340d717b5e090e45fe2a15def0aece Mon Sep 17 00:00:00 2001 From: Arhell Date: Sat, 8 Jan 2022 01:34:01 +0200 Subject: [PATCH 103/254] [en] fix meetup link --- content/en/_index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/_index.html b/content/en/_index.html index 4615b5db0e..7557fe8f99 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -48,7 +48,7 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise


- Attend KubeCon North America on October 24-28, 2022 + Attend KubeCon North America on October 24-28, 2022
From 131258881d91d7f548dddb2ec77c286dce024429 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 9 Jan 2022 00:25:04 -0500 Subject: [PATCH 104/254] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Emilano Vazquez --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index d28a6ca149..912ae39a53 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -48,7 +48,7 @@ Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador Luego, el Planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), -la programación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. +la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes ## Reprogramar From e1080031f58c8ca0120a97ade9410101047c6b99 Mon Sep 17 00:00:00 2001 From: Edith Puclla <58795858+edithturn@users.noreply.github.com> Date: Sun, 9 Jan 2022 00:25:15 -0500 Subject: [PATCH 105/254] Update content/es/docs/concepts/storage/storage-capacity.md Co-authored-by: Emilano Vazquez --- content/es/docs/concepts/storage/storage-capacity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 912ae39a53..75b197d2dd 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -50,7 +50,7 @@ Luego, el Planificador programa los pods en los nodos donde el volumen está dis Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes -## Reprogramar +## Replanificar Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. From 5d255db39e70e0860e08e04ea4d239f22a2e705e Mon Sep 17 00:00:00 2001 From: edithturn Date: Sun, 9 Jan 2022 00:34:11 -0500 Subject: [PATCH 106/254] removing version v1.19 --- .../docs/concepts/storage/storage-capacity.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 75b197d2dd..43996dc3e3 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -12,10 +12,9 @@ weight: 45 La capacidad de almacenamiento es limitada y puede variar según el nodo en el que un Pod se ejecuta: es posible que no todos los nodos puedan acceder al almacenamiento conectado a la red o que, para empezar, el almacenamiento sea local en un nodo. -{{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} -Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el planificador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el programador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de programación. +Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el planificador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el planificador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de planificación. El seguimiento de la capacidad de almacenamiento es compatible con los controladores de la {{< glossary_tooltip text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y @@ -28,39 +27,40 @@ text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: - son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. + son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): - cuando se establece en `true`, el Planificador de Kubernetes considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. + cuando se establece en `true`, el [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. ## Planificación -El Planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: +El planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: -- la Feature Gate de `CSIStorageCapacity` es `true`, +- la puerta de la característica `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, -- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el [modo de enlace de volumen](/docs/concepts/storage/storage-classes/#volume-binding-mode) `WaitForFirstConsumer` , +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding + mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. -En ese caso, el Planificador sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. +En ese caso, el planificador sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador de almacenamiento decide dónde crear el volumen, independientemente de los pods que usarán el volumen. -Luego, el Planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. +Luego, el planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), -la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes +la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. -## Replanificar +## Replanificación Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. -Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el Planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. +Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. -## Limitaciones +## Limitationes -El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la programación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la programación sin información de capacidad de almacenamiento es manejado por los errores de programación. +El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la planificación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la planificación sin información de capacidad de almacenamiento es manejado por los errores de planificación. -Una situación en la que la programación puede fallar de forma permanente es cuando un Pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ +Una situación en la que la planificación puede fallar de forma permanente es cuando un pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. ## Habilitación del seguimiento de la capacidad de almacenamiento @@ -70,6 +70,6 @@ El seguimiento de la capacidad de almacenamiento es una función beta y está ha ## {{% heading "whatsnext" %}} - Para obtener más información sobre el diseño, consulte las - [Restricciones de Capacidad de Almacenamiento para la Programación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). + [Restricciones de Capacidad de Almacenamiento para la Planificación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). - Para obtener más información sobre un mayor desarrollo de esta función, consulte [problema de seguimiento de mejoras #1472](https://github.com/kubernetes/enhancements/issues/1472). - Aprender sobre [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) From 8f8d2bb0399c5fd20a741b975332d21c2d632265 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Filip=20K=C5=99epinsk=C3=BD?= Date: Thu, 6 Jan 2022 17:39:10 +0100 Subject: [PATCH 107/254] make deployment status behaviour more descriptive --- .../workloads/controllers/deployment.md | 43 ++++++++++++++----- 1 file changed, 32 insertions(+), 11 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index f80224e2e6..ad3170b1d2 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -842,6 +842,13 @@ Kubernetes marks a Deployment as _progressing_ when one of the following tasks i * The Deployment is scaling down its older ReplicaSet(s). * New Pods become ready or available (ready for at least [MinReadySeconds](#min-ready-seconds)). +When the rollout becomes “progressing”, the Deployment controller adds a condition with the following +attributes to the Deployment's `.status.conditions`: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated` + You can monitor the progress for a Deployment by using `kubectl rollout status`. ### Complete Deployment @@ -853,6 +860,17 @@ updates you've requested have been completed. * All of the replicas associated with the Deployment are available. * No old replicas for the Deployment are running. +When the rollout becomes “complete”, the Deployment controller sets a condition with the following +attributes to the Deployment's `.status.conditions`: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetAvailable` + +This `Progressing` condition will retain a status value of `"True"` until a new rollout +is initiated. The condition holds even when availability of replicas changes (which +does instead affect the `Available` condition). + You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code. @@ -890,7 +908,7 @@ number of seconds the Deployment controller waits before indicating (in the Depl Deployment progress has stalled. The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report -lack of progress for a Deployment after 10 minutes: +lack of progress of a rollout for a Deployment after 10 minutes: ```shell kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' @@ -902,15 +920,18 @@ deployment.apps/nginx-deployment patched Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following attributes to the Deployment's `.status.conditions`: -* Type=Progressing -* Status=False -* Reason=ProgressDeadlineExceeded +* `type: Progressing` +* `status: "False"` +* `reason: ProgressDeadlineExceeded` + +This condition can also fail early and is then set to status value of `"False"` due to reasons as `ReplicaSetCreateError`. +Also, the deadline is not taken into account anymore once the Deployment rollout completes. See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for more information on status conditions. {{< note >}} Kubernetes takes no action on a stalled Deployment other than to report a status condition with -`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for +`reason: ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for example, rollback the Deployment to its previous version. {{< /note >}} @@ -984,7 +1005,7 @@ Conditions: You can address an issue of insufficient quota by scaling down your Deployment, by scaling down other controllers you may be running, or by increasing quota in your namespace. If you satisfy the quota conditions and the Deployment controller then completes the Deployment rollout, you'll see the -Deployment's status update with a successful condition (`Status=True` and `Reason=NewReplicaSetAvailable`). +Deployment's status update with a successful condition (`status: "True"` and `reason: NewReplicaSetAvailable`). ``` Conditions: @@ -994,11 +1015,11 @@ Conditions: Progressing True NewReplicaSetAvailable ``` -`Type=Available` with `Status=True` means that your Deployment has minimum availability. Minimum availability is dictated -by the parameters specified in the deployment strategy. `Type=Progressing` with `Status=True` means that your Deployment +`type: Available` with `status: "True"` means that your Deployment has minimum availability. Minimum availability is dictated +by the parameters specified in the deployment strategy. `type: Progressing` with `status: "True"` means that your Deployment is either in the middle of a rollout and it is progressing or that it has successfully completed its progress and the minimum required new replicas are available (see the Reason of the condition for the particulars - in our case -`Reason=NewReplicaSetAvailable` means that the Deployment is complete). +`reason: NewReplicaSetAvailable` means that the Deployment is complete). You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status` returns a non-zero exit code if the Deployment has exceeded the progression deadline. @@ -1155,8 +1176,8 @@ total number of Pods running at any time during the update is at most 130% of de `.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want to wait for your Deployment to progress before the system reports back that the Deployment has -[failed progressing](#failed-deployment) - surfaced as a condition with `Type=Progressing`, `Status=False`. -and `Reason=ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep +[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: "False"`. +and `reason: ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep retrying the Deployment. This defaults to 600. In the future, once automatic rollback will be implemented, the Deployment controller will roll back a Deployment as soon as it observes such a condition. From e9fe604ce154f0349bb50f1bfe62f08cb6c333dd Mon Sep 17 00:00:00 2001 From: Jaeyeon Kim Date: Thu, 6 Jan 2022 11:31:56 +0900 Subject: [PATCH 108/254] [ko] Translate content/ko/docs/concepts/architecture/cri.md Signed-off-by: Jaeyeon Kim Co-authored-by: Jesang Myung Co-authored-by: Seokho Son --- content/ko/docs/concepts/architecture/cri.md | 50 +++++++++++++++++++ .../glossary/container-runtime-interface.md | 22 ++++++++ 2 files changed, 72 insertions(+) create mode 100644 content/ko/docs/concepts/architecture/cri.md create mode 100644 content/ko/docs/reference/glossary/container-runtime-interface.md diff --git a/content/ko/docs/concepts/architecture/cri.md b/content/ko/docs/concepts/architecture/cri.md new file mode 100644 index 0000000000..69175432d1 --- /dev/null +++ b/content/ko/docs/concepts/architecture/cri.md @@ -0,0 +1,50 @@ +--- +title: 컨테이너 런타임 인터페이스(CRI) +content_type: concept +weight: 50 +--- + + + +컨테이너 런타임 인터페이스(CRI)는 클러스터 컴포넌트를 다시 컴파일하지 않아도 Kubelet이 다양한 +컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스다. + +클러스터의 모든 노드에 동작 중인 +{{}}이 존재해야, +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 +{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을 +구동할 수 있다. + +{{< glossary_definition term_id="container-runtime-interface" length="all" >}} + + + +## API {#api} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Kubelet은 gRPC를 통해 컨테이너 런타임과 연결할 때 클라이언트의 역할을 수행한다. +런타임과 이미지 서비스 엔드포인트는 컨테이너 런타임 내에서 사용 가능해야 하며, +이는 각각 Kubelet 내에서 `--image-service-endpoint`와 `--container-runtime-endpoint` +[커맨드라인 플래그](/docs/reference/command-line-tools-reference/kubelet) +를 통해 설정할 수 있다. + +쿠버네티스 v{{< skew currentVersion >}}에서는, Kubelet은 CRI `v1`을 사용하는 것을 권장한다. +컨테이너 런타임이 CRI `v1` 버전을 지원하지 않는다면, +Kubelet은 지원 가능한 이전 지원 버전으로 협상을 시도한다. +또한 v{{< skew currentVersion >}} Kubelet은 CRI `v1alpha2`버전도 협상할 수 있지만, +해당 버전은 사용 중단(deprecated)으로 간주한다. +Kubelet이 지원되는 CRI 버전을 협상할 수 없는 경우, +Kubelet은 협상을 포기하고 노드로 등록하지 않는다. + +## 업그레이드 + +쿠버네티스를 업그레이드할 때, Kubelet은 컴포넌트의 재시작 시점에서 최신 CRI 버전을 자동으로 선택하려고 시도한다. +이 과정이 실패하면 위에서 언급한 대로 이전 버전을 선택하는 과정을 거친다. +컨테이너 런타임이 업그레이드되어 gRPC 재다이얼이 필요하다면, +컨테이너 런타임도 처음에 선택된 버전을 지원해야 하며, +그렇지 못한 경우 재다이얼은 실패하게 될 것이다. 이 과정은 Kubelet의 재시작이 필요하다. + +## {{% heading "whatsnext" %}} + +- CRI [프로토콜 정의](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)를 자세히 알아보자. diff --git a/content/ko/docs/reference/glossary/container-runtime-interface.md b/content/ko/docs/reference/glossary/container-runtime-interface.md new file mode 100644 index 0000000000..c0d6155a4a --- /dev/null +++ b/content/ko/docs/reference/glossary/container-runtime-interface.md @@ -0,0 +1,22 @@ +--- +title: 컨테이너 런타임 인터페이스(Container Runtime Interface) +id: container-runtime-interface +date: 2022-01-10 +full_link: /ko/docs/concepts/architecture/cri/ +short_description: > + Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다. + +aka: +tags: + - cri +--- + +Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다. + + + +쿠버네티스 컨테이너 런타임 인터페이스(CRI)는 +[클러스터 컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트) +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}과 +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} 사이의 +통신을 위한 주요 [gRPC](https://grpc.io) 프로토콜을 정의한다. From 46e0d1b69b94badccab78a1f9e92b353e4a0d59f Mon Sep 17 00:00:00 2001 From: edithturn Date: Tue, 11 Jan 2022 17:19:47 -0500 Subject: [PATCH 109/254] solved Victor's feedback --- content/es/docs/concepts/storage/storage-capacity.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md index 43996dc3e3..e729232844 100644 --- a/content/es/docs/concepts/storage/storage-capacity.md +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -27,7 +27,7 @@ text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y Hay dos extensiones de API para esta función: - Los objetos CSIStorageCapacity: - son producidos por un controlador CSI en el namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. + son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. - [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): cuando se establece en `true`, el [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. @@ -35,10 +35,9 @@ Hay dos extensiones de API para esta función: El planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: -- la puerta de la característica `CSIStorageCapacity` es `true`, +- la Feature gate de `CSIStorageCapacity` es `true`, - un Pod usa un volumen que aún no se ha creado, -- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el modo de enlace de volumen `WaitForFirstConsumer` [volume binding - mode](/docs/concepts/storage/storage-classes/#volume-binding-mode), +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el [modo de enlace de volumen] (/docs/concepts/storage/storage-classes/#volume-binding-mode)`WaitForFirstConsumer`, y - el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. @@ -56,7 +55,7 @@ Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. -## Limitationes +## Limitaciones El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la planificación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la planificación sin información de capacidad de almacenamiento es manejado por los errores de planificación. From ce37f1b293a792cf497e99b3689a65e5e69a8d02 Mon Sep 17 00:00:00 2001 From: JNat Date: Wed, 12 Jan 2022 13:29:30 +0000 Subject: [PATCH 110/254] added Stack Overflow guidance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Added extra links to the guidance pertaining asking questions on Stack Overflow, to ensure users first read through guidance to ensure questions are both on-topic and well-written — both of which will improve these users' experience on Stack Overflow, and avoid having off-topic questions asked there. --- .../docs/tasks/debug-application-cluster/troubleshooting.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md index a5385b25fc..6c6641f382 100644 --- a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md +++ b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md @@ -45,8 +45,9 @@ and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/ Someone else from the community may have already asked a similar question or may be able to help with your problem. The Kubernetes team will also monitor [posts tagged Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes). -If there aren't any existing questions that help, please -[ask a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)! +If there aren't any existing questions that help, **please [ensure that your question is on-topic on Stack Overflow](https://stackoverflow.com/help/on-topic) +and that you read through the guidance on [how to ask a new question](https://stackoverflow.com/help/how-to-ask)**, +before [asking a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)! ### Slack From 1c4ea6d5af1cc65872547858eb2bdc2c2deafa27 Mon Sep 17 00:00:00 2001 From: Meysam Azad Date: Wed, 12 Jan 2022 19:25:27 +0300 Subject: [PATCH 111/254] =?UTF-8?q?docs:=20place=20annotation=20between=20?= =?UTF-8?q?backticks=20=E2=9C=8F=EF=B8=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/en/docs/concepts/workloads/controllers/replicaset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 70967853e8..1daf567c66 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -313,7 +313,7 @@ ensures that a desired number of Pods with a matching label selector are availab When scaling down, the ReplicaSet controller chooses which pods to delete by sorting the available pods to prioritize scaling down pods based on the following general algorithm: 1. Pending (and unschedulable) pods are scaled down first - 2. If controller.kubernetes.io/pod-deletion-cost annotation is set, then + 2. If `controller.kubernetes.io/pod-deletion-cost` annotation is set, then the pod with the lower value will come first. 3. Pods on nodes with more replicas come before pods on nodes with fewer replicas. 4. If the pods' creation times differ, the pod that was created more recently From 6f9f8e0dcc735b79a7d9929a72d2b98d231125fe Mon Sep 17 00:00:00 2001 From: Wang Date: Thu, 13 Jan 2022 04:09:08 +0900 Subject: [PATCH 112/254] Update content/ja/docs/tasks/debug-application-cluster/debug-application.md Co-authored-by: nasa9084 --- .../docs/tasks/debug-application-cluster/debug-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md index 30a917d1e6..b9be05c3f7 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -14,7 +14,7 @@ content_type: concept ## 問題の診断 トラブルシューティングの最初のステップは切り分けです。何が問題なのでしょうか？ -Podなのか、レプリケーションコントローラなのか、それともサービスなのか？ +Podなのか、レプリケーションコントローラーなのか、それともサービスなのか？ * [Debugging Pods](#debugging-pods) * [Debugging Replication Controllers](#debugging-replication-controllers) From 42e88a361cf145f1e9d23fec8af7a438fa987af4 Mon Sep 17 00:00:00 2001 From: d3vus <96516301+utkarsh-singh1@users.noreply.github.com> Date: Thu, 13 Jan 2022 13:05:17 +0530 Subject: [PATCH 113/254] Updated managed-resource-containers.md --- .../concepts/configuration/manage-resources-containers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 6d90ed5fff..181dd4c6cb 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -709,13 +709,13 @@ Allocated resources: 680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%) ``` -In the preceding output, you can see that if a Pod requests more than 1.120 CPUs, +In the preceding output, you can see that if a Pod requests more than 1.120 CPUs or more than 6.23Gi of memory, that Pod will not fit on the node. By looking at the “Pods” section, you can see which Pods are taking up space on the node. -The amount of resources available to Pods is less than the node capacity, because +The amount of resources available to Pods is less than the node capacity because system daemons use a portion of the available resources. Within the Kubernetes API, each Node has a `.status.allocatable` field (see [NodeStatus](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeStatus) @@ -736,7 +736,7 @@ prevent one team from using so much of any resource that this over-use affects o You should also consider what access you grant to that namespace: **full** write access to a namespace allows someone with that access to remove any -resource, include a configured ResourceQuota. +resource, including a configured ResourceQuota. ### My container is terminated From 6c6288e41d2be6c5bf2e17572b7fe558b383bc8a Mon Sep 17 00:00:00 2001 From: Ray Wang Date: Thu, 13 Jan 2022 18:02:24 +0800 Subject: [PATCH 114/254] Add help docs for module-check and module-init Now command `make` will show help docs for `module-check` and `module-init` targets also. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index a103f4e58e..85c934e050 100644 --- a/Makefile +++ b/Makefile @@ -19,10 +19,10 @@ CCEND=\033[0m help: ## Show this help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) -module-check: +module-check: ## Check if all of the required submodules are correctly initialized. @git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2 -module-init: +module-init: ## Initialize required submodules. @echo "Initializing submodules..." 1>&2 @git submodule update --init --recursive --depth 1 From ef6d83b5ddd73fd91e75e0c6b8aed79b69e75da2 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 13 Jan 2022 17:43:34 +0000 Subject: [PATCH 115/254] Clarify example for setting Linux command line --- .../setup/production-environment/container-runtimes.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index fbb6d9bc84..b481c6578c 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -76,13 +76,17 @@ If systemd doesn't use cgroup v2 by default, you can configure the system to use `systemd.unified_cgroup_hierarchy=1` to the kernel command line. ```shell -# dnf install -y grubby && \ +# This example is for a Linux OS that uses the DNF package manager +# Your system might use a different method for setting the command line +# that the Linux kernel uses. +sudo dnf install -y grubby && \ sudo grubby \ --update-kernel=ALL \ --args="systemd.unified_cgroup_hierarchy=1" ``` -To apply the configuration, it is necessary to reboot the node. +If you change the command line for the kernel, you must reboot the node before your +change takes effect. There should not be any noticeable difference in the user experience when switching to cgroup v2, unless users are accessing the cgroup file system directly, either on the node or from within the containers. From a18a34c4825a4589e50c85bf96ddac79c2e4f8b0 Mon Sep 17 00:00:00 2001 From: Yashodhan Mohan Bhatnagar Date: Fri, 14 Jan 2022 02:39:33 +0530 Subject: [PATCH 116/254] Clean up docker references from Service documentations 1. Remove examples contrasting k8s networking with Docker networking from concept document explaining connecting applications using services 2. Remove reference to dockerlinks in favor of English description of the env vars autocreated for every Service. --- .../services-networking/connect-applications-service.md | 8 +++----- content/en/docs/concepts/services-networking/service.md | 5 ++--- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md index 07bab7965b..f09f9b611c 100644 --- a/content/en/docs/concepts/services-networking/connect-applications-service.md +++ b/content/en/docs/concepts/services-networking/connect-applications-service.md @@ -13,11 +13,9 @@ weight: 30 ## The Kubernetes model for connecting containers -Now that you have a continuously running, replicated application you can expose it on a network. Before discussing the Kubernetes approach to networking, it is worthwhile to contrast it with the "normal" way networking works with Docker. +Now that you have a continuously running, replicated application you can expose it on a network. -By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, there must be allocated ports on the machine's own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or ports must be allocated dynamically. - -Coordinating port allocations across multiple developers or teams that provide containers is very difficult to do at scale, and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model. +Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model. This guide uses a simple nginx server to demonstrate proof of concept. @@ -52,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP podIP: 10.244.2.5 ``` -You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interfaces, but the need for this is radically diminished because of the networking model. +You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Ports can still be published to the host node's interfaces, but the need for this is radically diminished because of the networking model. You can read more about the [Kubernetes Networking Model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) if you're curious. diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 81e25d17ef..909dd16da8 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -450,9 +450,8 @@ variables and DNS. ### Environment variables 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/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) -and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, +for each active Service. It supports both granular variables like `{SVCNAME}_PORT_{SVCPORT}_PROTO` and more (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) +as well as simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. For example, the Service `redis-master` which exposes TCP port 6379 and has been From d311fcecad73cc533834749755d92e0d7fb5cf83 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 15 Dec 2021 15:14:32 +0900 Subject: [PATCH 117/254] [ko] Update outdated files in dev-1.23-ko.1 M25-33 --- .../service-traffic-policy.md | 2 +- .../concepts/storage/persistent-volumes.md | 58 +++-- .../docs/concepts/storage/storage-capacity.md | 3 +- .../docs/concepts/storage/storage-classes.md | 4 +- .../concepts/storage/volume-pvc-datasource.md | 7 +- .../storage/volume-snapshot-classes.md | 2 +- .../docs/concepts/storage/volume-snapshots.md | 9 +- content/ko/docs/concepts/storage/volumes.md | 221 ++++++------------ 8 files changed, 136 insertions(+), 170 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index f658cd6cfa..8088d05366 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되 ## {{% heading "whatsnext" %}} -* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기 +* [토폴로지 인식 힌트](/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 4bc8926e3b..31f576daa5 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -10,14 +10,13 @@ feature: title: 스토리지 오케스트레이션 description: > 로컬 스토리지, GCP나 AWS와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. - content_type: concept weight: 20 --- -이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. +이 페이지에서는 쿠버네티스의 _퍼시스턴트 볼륨_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. @@ -221,19 +220,19 @@ spec: {{< feature-state for_k8s_version="v1.11" state="beta" >}} -이제 퍼시스턴트볼륨클레임(PVC) 확장 지원이 기본적으로 활성화되어 있다. 다음 유형의 +퍼시스턴트볼륨클레임(PVC) 확장 지원은 기본적으로 활성화되어 있다. 다음 유형의 볼륨을 확장할 수 있다. -* gcePersistentDisk +* azureDisk +* azureFile * awsElasticBlockStore -* Cinder +* cinder (deprecated) +* {{< glossary_tooltip text="csi" term_id="csi" >}} +* flexVolume (deprecated) +* gcePersistentDisk * glusterfs * rbd -* Azure File -* Azure Disk -* Portworx -* FlexVolumes -* {{< glossary_tooltip text="CSI" term_id="csi" >}} +* portworxVolume 스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다. @@ -270,7 +269,7 @@ CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확 경우에만 파일시스템의 크기가 조정된다. 파일시스템 확장은 파드가 시작되거나 파드가 실행 중이고 기본 파일시스템이 온라인 확장을 지원할 때 수행된다. -FlexVolumes는 `RequiresFSResize` 기능으로 드라이버가 `true`로 설정된 경우 크기 조정을 허용한다. +FlexVolumes(쿠버네티스 v1.23부터 사용 중단됨)는 드라이버의 `RequiresFSResize` 기능이 `true`로 설정된 경우 크기 조정을 허용한다. FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. #### 사용 중인 퍼시스턴트볼륨클레임 크기 조정 @@ -299,6 +298,11 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 #### 볼륨 확장 시 오류 복구 +사용자가 기반 스토리지 시스템이 제공할 수 있는 것보다 더 큰 사이즈를 지정하면, 사용자 또는 클러스터 관리자가 조치를 취하기 전까지 PVC 확장을 계속 시도한다. 이는 바람직하지 않으며 따라서 쿠버네티스는 이러한 오류 상황에서 벗어나기 위해 다음과 같은 방법을 제공한다. + +{{< tabs name="recovery_methods" >}} +{{% tab name="클러스터 관리자 접근 권한을 이용하여 수동으로" %}} + 기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다. 1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다. @@ -307,6 +311,30 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다. 5. PV의 반환 정책을 복원하는 것을 잊지 않는다. +{{% /tab %}} +{{% tab name="더 작은 크기로의 확장을 요청하여" %}} +{{% feature-state for_k8s_version="v1.23" state="alpha" %}} + +{{< note >}} +PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다. +{{< /note >}} + +클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure` +기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면 +이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다. +더 작은 크기를 지정하여 확장 시도를 요청하려면, +이전에 요청했던 값보다 작은 크기로 PVC의 `.spec.resources` 값을 수정한다. +이는 총 용량 제한(capacity constraint)으로 인해 큰 값으로의 확장이 실패한 경우에 유용하다. +만약 확장이 실패했다면, 또는 실패한 것 같다면, 기반 스토리지 공급자의 용량 제한보다 작은 값으로 확장을 재시도할 수 있다. +`.status.resizeStatus`와 PVC의 이벤트를 감시하여 리사이즈 작업의 상태를 모니터할 수 있다. + +참고: +이전에 요청했던 값보다 작은 크기를 요청했더라도, +새로운 값이 여전히 `.status.capacity`보다 클 수 있다. +쿠버네티스는 PVC를 현재 크기보다 더 작게 축소하는 것은 지원하지 않는다. +{{% /tab %}} +{{% /tabs %}} + ## 퍼시스턴트 볼륨의 유형 @@ -318,7 +346,6 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨 * [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI) * [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지 -* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk * [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 * [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨 @@ -336,6 +363,8 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지) (v1.18에서 **사용 중단**) +* [`flexVolume`](/docs/concepts/storage/volumes/#flexvolume) - FlexVolume + (v1.23에서 **사용 중단**) * [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지 (v1.22에서 **사용 중단**) * [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨 @@ -417,9 +446,12 @@ spec: `ReadWriteOnce` : 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다. -`ReadWriteMany` +`ReadOnlyMany` : 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다. +`ReadWriteMany` +: 볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다. + `ReadWriteOncePod` : 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다. diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index 4aeb1ba8c1..86c95ae13a 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -7,7 +7,7 @@ title: 스토리지 용량 content_type: concept -weight: 45 +weight: 70 --- @@ -16,7 +16,6 @@ weight: 45 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며, 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다. -{{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index c915b65fad..c47f053a31 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -470,14 +470,14 @@ parameters: vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다. -- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com` +- [CSI 프로비저닝 도구](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` - [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume` 인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다. #### CSI 프로비저닝 도구 {#vsphere-provisioner-csi} -vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다. +vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml)를 참조한다. #### vCP 프로비저닝 도구 diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index e9857885d7..365f780230 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -1,7 +1,12 @@ --- + + + + + title: CSI 볼륨 복제하기 content_type: concept -weight: 30 +weight: 60 --- diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 862c900fee..594d100772 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -8,7 +8,7 @@ title: 볼륨 스냅샷 클래스 content_type: concept -weight: 30 +weight: 41 # just after volume snapshots --- diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index b01a8affa4..d54ed5c45c 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -1,7 +1,14 @@ --- + + + + + + + title: 볼륨 스냅샷 content_type: concept -weight: 20 +weight: 40 --- diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 5983c37647..a4245a7daa 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -44,12 +44,21 @@ weight: 10 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다. -컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 -뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는 -파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에 -마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 -가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로 -지정해야 한다. +컨테이너의 프로세스는 +{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}의 최초 내용물과 +컨테이너 안에 마운트된 볼륨(정의된 경우에 한함)으로 구성된 파일시스템을 보게 된다. +프로세스는 컨테이너 이미지의 최초 내용물에 해당되는 루트 파일시스템을 +보게 된다. +쓰기가 허용된 경우, 해당 파일시스템에 쓰기 작업을 하면 +추후 파일시스템에 접근할 때 변경된 내용을 보게 될 것이다. +볼륨은 이미지의 [특정 경로](#using-subpath)에 +마운트된다. +파드에 정의된 각 컨테이너에 대해, +컨테이너가 사용할 각 볼륨을 어디에 마운트할지 명시해야 한다. + +볼륨은 다른 볼륨 안에 마운트될 수 없다 +(하지만, [서브패스 사용](#using-subpath)에서 관련 메커니즘을 확인한다). +또한, 볼륨은 다른 볼륨에 있는 내용물을 가리키는 하드 링크를 포함할 수 없다. ## 볼륨 유형들 {#volume-types} @@ -802,142 +811,7 @@ spec: ### projected `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. - -현재, 다음 유형의 볼륨 소스를 프로젝티드한다. - -* [`secret`](#secret) -* [`downwardAPI`](#downwardapi) -* [`configMap`](#configmap) -* `serviceAccountToken` - -모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 -[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다. - -#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#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 -``` - -#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#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 -``` - -각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. -파라미터는 두 가지 예외를 제외하고 거의 동일하다. - -* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록 - `name` 으로 변경되었다. -* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 - 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` - 를 명시적으로 설정할 수 있다. - -`TokenRequestProjection` 기능이 활성화 되면, 현재 -[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 -대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다. - -```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 -``` - -예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 -있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데 -사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 -포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, -그렇지 않으면 토큰을 거부해야 한다. 이 필드는 -선택 사항이며 기본값은 API 서버의 식별자이다. - -`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효 -기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는 -API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서 -최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한 -상대 경로를 지정한다. - -{{< note >}} -projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 -해당 볼륨 소스의 업데이트를 수신하지 않는다. -{{< /note >}} +더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다. ### quobyte (사용 중단됨) {#quobyte} @@ -975,6 +849,38 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를 참고한다. +#### RBD CSI 마이그레이션 {#rbd-csi-migration} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +`RBD`를 위한 `CSIMigration` 기능이 활성화되어 있으면, +사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`rbd.csi.ceph.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} +드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 +[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고 +`CSIMigration`, `CSIMigrationRBD` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. + +{{< note >}} + +스토리지를 관리하는 쿠버네티스 클러스터 관리자는, +RBD CSI 드라이버로의 마이그레이션을 시도하기 전에 +다음의 선행 사항을 완료해야 한다. + +* 쿠버네티스 클러스터에 Ceph CSI 드라이버 (`rbd.csi.ceph.com`) v3.5.0 + 이상을 설치해야 한다. +* CSI 드라이버가 동작하기 위해 `clusterID` 필드가 필수이지만 + 트리 내(in-tree) 스토리지클래스는 `monitors` 필드가 필수임을 감안하여, + 쿠버네티스 저장소 관리자는 monitors 값의 + 해시(예: `#echo -n '' | md5sum`) + 기반으로 clusterID를 CSI 컨피그맵 내에 만들고 + 이 clusterID 환경 설정 아래에 monitors 필드를 유지해야 한다. +* 또한, 트리 내(in-tree) 스토리지클래스의 + `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 + `adminSecretName` 값이 `adminId` 파라미터 값의 + base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. + ### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 @@ -1144,6 +1050,16 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 `vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다. +#### Portworx CSI 마이그레이션 +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +Portworx를 위한 `CSIMigration` 기능이 쿠버네티스 1.23에 추가되었지만 +알파 상태이기 때문에 기본적으로는 비활성화되어 있다. +이 기능은 사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`pxd.portworx.com` CSI 드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 [Portworx CSI 드라이버](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)가 +설치되어 있고, kube-controller-manager와 kubelet에 `CSIMigrationPortworx=true`로 설정해야 한다. + ## subPath 사용하기 {#using-subpath} 때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. @@ -1239,8 +1155,7 @@ spec: ## 아웃-오브-트리(out-of-tree) 볼륨 플러그인 아웃-오브-트리 볼륨 플러그인에는 -{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 -FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 +{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 FlexVolume(사용 중단됨)이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. 이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와 @@ -1373,13 +1288,21 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 ### flexVolume -FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는 -아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 -접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의 -미리 정의된 볼륨 플러그인 경로에 설치해야 한다. +{{< feature-state for_k8s_version="v1.23" state="deprecated" >}} + +FlexVolume은 스토리지 드라이버와 인터페이싱하기 위해 exec 기반 모델을 사용하는 아웃-오브-트리 플러그인 인터페이스이다. +FlexVolume 드라이버 바이너리 파일은 각 노드의 미리 정의된 볼륨 플러그인 경로에 설치되어야 하며, +일부 경우에는 컨트롤 플레인 노드에도 설치되어야 한다. 파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다. -더 자세한 내용은 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 예제를 참고한다. +더 자세한 내용은 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 문서를 참고한다. + +{{< note >}} +FlexVolume은 사용 중단되었다. 쿠버네티스에 외부 스토리지를 연결하려면 아웃-오브-트리 CSI 드라이버를 사용하는 것을 권장한다. + +FlexVolume 드라이버 메인테이너는 CSI 드라이버를 구현하고 사용자들이 FlexVolume 드라이버에서 CSI로 마이그레이트할 수 있도록 지원해야 한다. +FlexVolume 사용자는 워크로드가 동등한 CSI 드라이버를 사용하도록 이전해야 한다. +{{< /note >}} ## 마운트 전파(propagation) From b928e5c8de3f3fc3b668373577edc469737b8d64 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 16 Dec 2021 08:47:02 +0900 Subject: [PATCH 118/254] [ko] Update outdated files in dev-1.23-ko.1 M34-37 --- .../workloads/controllers/cron-jobs.md | 37 +++-- .../workloads/controllers/deployment.md | 39 +++-- .../concepts/workloads/controllers/job.md | 64 +++++++- .../workloads/controllers/statefulset.md | 144 +++++++++++++++--- 4 files changed, 228 insertions(+), 56 deletions(-) diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 3ae5659806..34ac547b73 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text=" 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. -추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=