From 491365356f550cd96bc48165b257474941e0453a Mon Sep 17 00:00:00 2001 From: Edith Date: Sat, 2 Oct 2021 18:39:58 -0500 Subject: [PATCH 001/167] [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 0000000000000..a29f4810df59f --- /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/167] [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 0000000000000..29de717f0e6d4 --- /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/167] [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 0000000000000..e0a8f839602f6 --- /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/167] 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 e0a8f839602f6..3883f9c323819 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/167] 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 3883f9c323819..0bf6403e0b623 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/167] 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 0bf6403e0b623..cf3708accde13 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/167] 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 cf3708accde13..b0e5216ccecab 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/167] 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 b0e5216ccecab..25aeca28e2a82 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/167] 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 25aeca28e2a82..77e4bd66d926b 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/167] 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 77e4bd66d926b..0e227627a27b0 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/167] 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 0e227627a27b0..cdff9b48e15d9 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/167] 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 a29f4810df59f..24616f1abaf4c 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/167] 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 24616f1abaf4c..0e95978c2d98a 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/167] 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 29de717f0e6d4..80608ef2bb4d5 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/167] 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 80608ef2bb4d5..2cc1252581004 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/167] 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 2cc1252581004..dcb2690d0e9eb 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/167] 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 cdff9b48e15d9..2a8b40461ac64 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/167] 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 2a8b40461ac64..3aa777a30549a 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/167] 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 3aa777a30549a..2a8b40461ac64 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/167] 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 2a8b40461ac64..3aa777a30549a 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/167] 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 3aa777a30549a..2a8b40461ac64 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/167] 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 0e95978c2d98a..e210b058a720b 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/167] 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 e210b058a720b..b1e0c089aa03b 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/167] 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 b1e0c089aa03b..686be6312006b 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/167] 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 686be6312006b..fb24479eb7cfe 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/167] 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 fb24479eb7cfe..bdadd7d5415a6 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/167] 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 bdadd7d5415a6..d28a6ca1493f5 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/167] 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 0000000000000..17c9003c2899d --- /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/167] 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 17c9003c2899d..e476815eaf06c 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/167] 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 e476815eaf06c..bb1be786d0ee9 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/167] 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 bb1be786d0ee9..416ea57b9c0ff 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/167] 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 416ea57b9c0ff..76787a27e34a0 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/167] 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 76787a27e34a0..7e6eb2baebd2b 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/167] 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 7e6eb2baebd2b..6d73c2cab53f6 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/167] 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 6d73c2cab53f6..5a6e102cb7585 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/167] 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 5a6e102cb7585..5cbfbef226d5d 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/167] 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 5cbfbef226d5d..fdb197a31d059 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/167] 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 fdb197a31d059..679e0f53b701e 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/167] 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 679e0f53b701e..09e2a5592e4a6 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/167] 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 e3758e05c9772..d640195efcbbc 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 0156d67e4d666..d58baca108bd1 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: + +* 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: -* 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. +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 de80b80ce39c1..8db50fb4d19ff 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 d2f4790abc3b6..1d0fb3eb05ee6 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. + +When you add a LimitRange: -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. +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 4869c35e06175..290cac909f909 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 b0485f2b45a09..5db78858d598f 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/167] 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 d640195efcbbc..bb472ed647d0e 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 d58baca108bd1..14d50aa4d7b0d 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 8db50fb4d19ff..3efd899075bbd 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 1d0fb3eb05ee6..ff2a4082c206e 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 290cac909f909..161c3a12a9ed4 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 5db78858d598f..3cdb1a9f24287 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 efe4541e5a6b4e868e252f745c045471534a8bc5 Mon Sep 17 00:00:00 2001 From: Avinesh Tripathi <73980067+AvineshTripathi@users.noreply.github.com> Date: Thu, 9 Dec 2021 22:41:06 +0530 Subject: [PATCH 042/167] Update default-storage-class-prereqs.md --- content/en/includes/default-storage-class-prereqs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/includes/default-storage-class-prereqs.md b/content/en/includes/default-storage-class-prereqs.md index ef4823318dcab..93f494b38c94a 100644 --- a/content/en/includes/default-storage-class-prereqs.md +++ b/content/en/includes/default-storage-class-prereqs.md @@ -1,4 +1,4 @@ -You need to either have a dynamic PersistentVolume provisioner with a default +You need to either have a [dynamic PersistentVolume provisioning](docs/concepts/storage/dynamic-provisioning/) with a default [StorageClass](/docs/concepts/storage/storage-classes/), or [statically provision PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning) yourself to satisfy the [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) From 1fb9324fc3ff2d6740bca85ec936efc2ab547bed Mon Sep 17 00:00:00 2001 From: ystkfujii Date: Wed, 15 Dec 2021 14:32:10 +0900 Subject: [PATCH 043/167] 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 96858d32afb80..9e7efa0a46df5 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 044/167] 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 9e7efa0a46df5..849cd98782e3b 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 045/167] 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 19d79d3f4455f..58533a9b80298 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 f7d717d2fe1e2f7b708495b6415474deaded4cef Mon Sep 17 00:00:00 2001 From: Mike Monteith Date: Fri, 17 Dec 2021 15:00:35 +0000 Subject: [PATCH 046/167] Use --patch-file in documentation --patch-file is designed for file input, using a subshell `--patch $(cat filename.yaml)` is unecessary --- .../update-api-object-kubectl-patch.md | 41 ++++++------------- 1 file changed, 13 insertions(+), 28 deletions(-) diff --git a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md index 759eaf76cd269..e6e33efe753ef 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md @@ -70,14 +70,9 @@ spec: Patch your Deployment: -{{< tabs name="kubectl_patch_example" >}} -{{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" -{{< /tab >}} -{{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment patch-demo --patch $(Get-Content patch-file.yaml -Raw) -{{< /tab >}}} -{{< /tabs >}} +```shell +kubectl patch deployment patch-demo --patch-file patch-file.yaml +``` View the patched Deployment: @@ -183,7 +178,7 @@ spec: Patch your Deployment: ```shell -kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)" +kubectl patch deployment patch-demo --patch-file patch-file-tolerations.yaml ``` View the patched Deployment: @@ -249,7 +244,7 @@ spec: In your patch command, set `type` to `merge`: ```shell -kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yaml)" +kubectl patch deployment patch-demo --type merge --patch-file patch-file-2.yaml ``` View the patched Deployment: @@ -308,14 +303,9 @@ spec: Patch your Deployment: -{{< tabs name="kubectl_retainkeys_example" >}} -{{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)" -{{< /tab >}} -{{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) -{{< /tab >}}} -{{< /tabs >}} +```shell +kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no-retainkeys.yaml +``` In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`: @@ -339,14 +329,9 @@ With this patch, we indicate that we want to retain only the `type` key of the ` Patch your Deployment again with this new patch: -{{< tabs name="kubectl_retainkeys2_example" >}} -{{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)" -{{< /tab >}} -{{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw) -{{< /tab >}}} -{{< /tabs >}} +```shell +kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-retainkeys.yaml +``` Examine the content of the Deployment: @@ -425,10 +410,10 @@ The following commands are equivalent: ```shell -kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" +kubectl patch deployment patch-demo --patch-file patch-file.yaml kubectl patch deployment patch-demo --patch 'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis' -kubectl patch deployment patch-demo --patch "$(cat patch-file.json)" +kubectl patch deployment patch-demo --patch-file patch-file.json kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}' ``` From a50453f75315524b3de3d0cfe097c69f0fc9aa99 Mon Sep 17 00:00:00 2001 From: Bobae Kim Date: Wed, 22 Dec 2021 13:58:19 +0900 Subject: [PATCH 047/167] 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 58533a9b80298..a361c4d0bea28 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 048/167] 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 0000000000000..c2b6b5a22e609 --- /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 049/167] 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 c2b6b5a22e609..1e14d506c0da7 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 050/167] 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 1e14d506c0da7..7a976054d9737 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 051/167] 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 0000000000000..f863ec3c84961 --- /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 052/167] 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 f863ec3c84961..5b1880638a6a9 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 053/167] [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 74bc641df66b9..33adb3627cd65 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 7c5c2692fcb7b42388d8027de8452624a1abdb3d Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:44:56 +0900 Subject: [PATCH 054/167] 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 5b1880638a6a9..ea18e505971e7 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 055/167] 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 ea18e505971e7..1e4f5dc64127e 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 056/167] 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 1e4f5dc64127e..2419943b6d01d 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 057/167] 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 2419943b6d01d..016d06704fc12 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 058/167] 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 016d06704fc12..502cd27c191bb 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 059/167] 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 502cd27c191bb..d64eedce45709 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 060/167] 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 d64eedce45709..92abea17ab997 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 061/167] 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 92abea17ab997..70b1c9f450f0a 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 062/167] 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 70b1c9f450f0a..ac975d9cb2d3f 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 063/167] 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 ac975d9cb2d3f..da096320bb5d0 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 064/167] 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 da096320bb5d0..ac574f55d21b4 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 065/167] 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 ac574f55d21b4..224edd92ac629 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 066/167] 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 224edd92ac629..79e2dcccde547 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 067/167] 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 79e2dcccde547..14c093fbb2b58 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 068/167] 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 14c093fbb2b58..d45e760a7050d 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 069/167] 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 d45e760a7050d..ec29edba474e7 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 070/167] 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 ec29edba474e7..b8080537984ed 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 071/167] 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 b8080537984ed..a35ea52bda5f1 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 072/167] 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 a35ea52bda5f1..9008dac8addf3 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 073/167] 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 9008dac8addf3..0f093b4ad3aa5 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 074/167] 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 0f093b4ad3aa5..38c252ddc4666 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 075/167] 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 38c252ddc4666..2268d45fb46a8 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 076/167] 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 2268d45fb46a8..b9e85db103d69 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 077/167] 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 b9e85db103d69..d560a93b22ffd 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 078/167] 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 d560a93b22ffd..100f777758d01 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 079/167] 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 100f777758d01..505b01b3df894 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 080/167] 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 505b01b3df894..7a2a860a6924a 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 081/167] 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 7a2a860a6924a..f7ec86cbd9cd2 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 082/167] 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 f7ec86cbd9cd2..42086c7e22a6c 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 083/167] 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 42086c7e22a6c..0f78f6cc3527f 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 084/167] 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 0f78f6cc3527f..ca4bdce6bdc4e 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 085/167] 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 ca4bdce6bdc4e..5f6dd3d8b6f57 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 086/167] 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 5f6dd3d8b6f57..761588a26e976 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 087/167] 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 761588a26e976..30a917d1e6dc7 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 088/167] 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 7a976054d9737..c76576f96152c 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 089/167] 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 c76576f96152c..2d26476aa377f 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 090/167] 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 2d26476aa377f..c8aacdd2ac25c 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 091/167] 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 c8aacdd2ac25c..7abc15feb8498 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 092/167] 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 7abc15feb8498..5f77e03f1b79e 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 093/167] 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 5f77e03f1b79e..9c0c512633d27 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 094/167] 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 9c0c512633d27..82f85bb0de7e6 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 095/167] 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 82f85bb0de7e6..5f6bb9d0379ca 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 096/167] 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 5f6bb9d0379ca..69337320dc006 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 097/167] 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 69337320dc006..741c38c12a535 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 34273a687468302499adf50f19505553202f5af9 Mon Sep 17 00:00:00 2001 From: Avinesh Tripathi <73980067+AvineshTripathi@users.noreply.github.com> Date: Fri, 7 Jan 2022 22:46:02 +0530 Subject: [PATCH 098/167] Update content/en/includes/default-storage-class-prereqs.md Co-authored-by: Arsh Sharma <56963264+RinkiyaKeDad@users.noreply.github.com> --- content/en/includes/default-storage-class-prereqs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/includes/default-storage-class-prereqs.md b/content/en/includes/default-storage-class-prereqs.md index 93f494b38c94a..57758ef66e26c 100644 --- a/content/en/includes/default-storage-class-prereqs.md +++ b/content/en/includes/default-storage-class-prereqs.md @@ -1,4 +1,4 @@ -You need to either have a [dynamic PersistentVolume provisioning](docs/concepts/storage/dynamic-provisioning/) with a default +You need to either have a [dynamic PersistentVolume provisioner](/docs/concepts/storage/dynamic-provisioning/) with a default [StorageClass](/docs/concepts/storage/storage-classes/), or [statically provision PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning) yourself to satisfy the [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) From e21f0563f3d00c47b86c6e43619aaeeeb1c4cf25 Mon Sep 17 00:00:00 2001 From: Michelle Fernandez Bieber <37021266+mfbieber@users.noreply.github.com> Date: Sun, 5 Dec 2021 01:55:29 +0100 Subject: [PATCH 099/167] Added ingressClassName: nginx to Ingress example, mentioned to the necessity of it and referenced to the section describing that further --- .../concepts/services-networking/ingress.md | 17 +++++++++++++++++ .../networking/default-ingressclass.yaml | 10 ++++++++++ .../service/networking/minimal-ingress.yaml | 1 + 3 files changed, 28 insertions(+) create mode 100644 content/en/examples/service/networking/default-ingressclass.yaml diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 3e2aeb67732a6..882108fc8b86c 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -88,6 +88,15 @@ has all the information needed to configure a load balancer or proxy server. Mos contains a list of rules matched against all incoming requests. Ingress resource only supports rules for directing HTTP(S) traffic. +If the `ingressClassName` is omitted, a [default Ingress class](#default-ingress-class) +should be defined. + +There are some ingress controllers, that work without the definition of a +default `IngressClass`. For example, the Ingress-NGINX controller can be +configured with a [flag](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class) +`--watch-ingress-without-class`. It is [recommended](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) though, to specify the +default `IngressClass` as shown [below](#default-ingress-class). + ### Ingress rules Each HTTP rule contains the following information: @@ -266,6 +275,14 @@ an `ingressClassName` specified. You can resolve this by ensuring that at most 1 IngressClass is marked as default in your cluster. {{< /caution >}} +There are some ingress controllers, that work without the definition of a +default `IngressClass`. For example, the Ingress-NGINX controller can be +configured with a [flag](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class) +`--watch-ingress-without-class`. It is [recommended](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) though, to specify the +default `IngressClass`: + +{{< codenew file="service/networking/default-ingressclass.yaml" >}} + ## Types of Ingress ### Ingress backed by a single Service {#single-service-ingress} diff --git a/content/en/examples/service/networking/default-ingressclass.yaml b/content/en/examples/service/networking/default-ingressclass.yaml new file mode 100644 index 0000000000000..0602ad8c9d16d --- /dev/null +++ b/content/en/examples/service/networking/default-ingressclass.yaml @@ -0,0 +1,10 @@ +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + labels: + app.kubernetes.io/component: controller + name: nginx-example + annotations: + ingressclass.kubernetes.io/is-default-class: "true" +spec: + controller: k8s.io/ingress-nginx diff --git a/content/en/examples/service/networking/minimal-ingress.yaml b/content/en/examples/service/networking/minimal-ingress.yaml index 76640b9447fbd..55a5837510af1 100644 --- a/content/en/examples/service/networking/minimal-ingress.yaml +++ b/content/en/examples/service/networking/minimal-ingress.yaml @@ -5,6 +5,7 @@ metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: + ingressClassName: nginx-example rules: - http: paths: 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 100/167] 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 d28a6ca1493f5..912ae39a53610 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 101/167] 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 912ae39a53610..75b197d2ddab1 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 102/167] 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 75b197d2ddab1..43996dc3e3e81 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 103/167] 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 f80224e2e6341..ad3170b1d2ab1 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 46e0d1b69b94badccab78a1f9e92b353e4a0d59f Mon Sep 17 00:00:00 2001 From: edithturn Date: Tue, 11 Jan 2022 17:19:47 -0500 Subject: [PATCH 104/167] 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 43996dc3e3e81..e7292328446fb 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 1c4ea6d5af1cc65872547858eb2bdc2c2deafa27 Mon Sep 17 00:00:00 2001 From: Meysam Azad Date: Wed, 12 Jan 2022 19:25:27 +0300 Subject: [PATCH 105/167] =?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 70967853e8b13..1daf567c66010 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 106/167] 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 30a917d1e6dc7..b9be05c3f762c 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 9117178a97aac7f2e95f38b5287dfa44a577158f Mon Sep 17 00:00:00 2001 From: Adrian Ludwin Date: Thu, 13 Jan 2022 12:10:06 -0500 Subject: [PATCH 107/167] Namespace names must be RFC 1123 DNS labels The how-to docs to create a new namespace already specify this, but I think it's worth mentioning in the overview doc that a namespace name must be an RFC 1123 label, as I didn't initially think to look in the how-to doc for limitations. --- .../docs/concepts/overview/working-with-objects/namespaces.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 3a8d8da168d39..234327094ea57 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -98,6 +98,9 @@ is local to a namespace. This is useful for using the same configuration across multiple namespaces such as Development, Staging and Production. If you want to reach across namespaces, you need to use the fully qualified domain name (FQDN). +As a result, all namespace names must be valid +[RFC 1123 DNS labels](/docs/concepts/overview/working-with-objects/names/#dns-label-names). + ## Not All Objects are in a Namespace Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are From 91df90d68d376a3933078ccd6f444e564d57f8c5 Mon Sep 17 00:00:00 2001 From: Patrice Chalin Date: Fri, 14 Jan 2022 09:55:56 -0500 Subject: [PATCH 108/167] README: copyedits to API ref building instructions --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index d7691e7f0d8e9..87dd03e7ebd1e 100644 --- a/README.md +++ b/README.md @@ -65,9 +65,9 @@ This will start the local Hugo server on port 1313. Open up your browser to . -To update the reference pages for a new Kubernetes release (replace v1.20 in the following examples with the release to update to): +To update the reference pages for a new Kubernetes release follow these steps: -1. Pull the `kubernetes-resources-reference` submodule: +1. Pull in the `api-ref-generator` submodule: ```bash git submodule update --init --recursive --depth 1 @@ -75,9 +75,9 @@ To update the reference pages for a new Kubernetes release (replace v1.20 in the 2. Update the Swagger specification: -``` -curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json -``` + ```bash + curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json + ``` 3. In `api-ref-assets/config/`, adapt the files `toc.yaml` and `fields.yaml` to reflect the changes of the new release. From d8f4cefa5902f62ecf2820ed65a48e6275147dcd Mon Sep 17 00:00:00 2001 From: Vitthal Sai Date: Sat, 15 Jan 2022 22:14:53 +0530 Subject: [PATCH 109/167] Mention the kubectl binary folder as PATH environment variable --- content/en/docs/tasks/tools/install-kubectl-linux.md | 2 +- content/en/docs/tasks/tools/install-kubectl-windows.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index dcb6e2d6c9376..974dc58922310 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -85,7 +85,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type: chmod +x kubectl mkdir -p ~/.local/bin/kubectl mv ./kubectl ~/.local/bin/kubectl - # and then add ~/.local/bin/kubectl to $PATH + # and then add ~/.local/bin to $PATH ``` {{< /note >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-windows.md b/content/en/docs/tasks/tools/install-kubectl-windows.md index 43bb4e0bfafaf..a591c6e6cfcb5 100644 --- a/content/en/docs/tasks/tools/install-kubectl-windows.md +++ b/content/en/docs/tasks/tools/install-kubectl-windows.md @@ -59,7 +59,7 @@ The following methods exist for installing kubectl on Windows: $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) ``` -1. Add the binary in to your `PATH`. +1. Add the binary's folder to your `PATH`. 1. Test to ensure the version of `kubectl` is the same as downloaded: @@ -172,7 +172,7 @@ Below are the procedures to set up autocompletion for PowerShell. $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) ``` -1. Add the binary in to your `PATH`. +1. Add the binary's folder to your `PATH`. 1. Verify plugin is successfully installed From be56556f8f130bfa916672beabcfe6962bbcfd25 Mon Sep 17 00:00:00 2001 From: Vitthal Sai Date: Sun, 16 Jan 2022 16:45:22 +0530 Subject: [PATCH 110/167] Incorporates the feedback changes --- content/en/docs/tasks/tools/install-kubectl-linux.md | 2 +- content/en/docs/tasks/tools/install-kubectl-windows.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index 974dc58922310..ec3cb7b6273fc 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -85,7 +85,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type: chmod +x kubectl mkdir -p ~/.local/bin/kubectl mv ./kubectl ~/.local/bin/kubectl - # and then add ~/.local/bin to $PATH + # and then append (or prepend) ~/.local/bin to $PATH ``` {{< /note >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-windows.md b/content/en/docs/tasks/tools/install-kubectl-windows.md index a591c6e6cfcb5..707217df2d869 100644 --- a/content/en/docs/tasks/tools/install-kubectl-windows.md +++ b/content/en/docs/tasks/tools/install-kubectl-windows.md @@ -59,7 +59,7 @@ The following methods exist for installing kubectl on Windows: $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) ``` -1. Add the binary's folder to your `PATH`. +1. Append or prepend the kubectl binary folder to your `PATH` environment variable. 1. Test to ensure the version of `kubectl` is the same as downloaded: @@ -172,7 +172,7 @@ Below are the procedures to set up autocompletion for PowerShell. $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) ``` -1. Add the binary's folder to your `PATH`. +1. Append or prepend the kubectl binary folder to your `PATH` environment variable. 1. Verify plugin is successfully installed From 3a6fa8fea2322cf59a562527b091f3d341a90540 Mon Sep 17 00:00:00 2001 From: Yashodhan Mohan Bhatnagar Date: Mon, 17 Jan 2022 01:39:01 +0530 Subject: [PATCH 111/167] Correcting DNS record for pods exposed by a Service For pods, DNS record incorrectly specifies deployment name instead of service name. This commit corrects that. --- .../en/docs/concepts/services-networking/dns-pod-service.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index aea058c7e1c0c..4e55d8a3f401f 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -106,10 +106,9 @@ and the domain name for your cluster is `cluster.local`, then the Pod has a DNS `172-17-0-3.default.pod.cluster.local`. -Any pods created by a Deployment or DaemonSet exposed by a Service have the -following DNS resolution available: +Any pods exposed by a Service have the following DNS resolution available: -`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`. +`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`. ### Pod's hostname and subdomain fields From 34ded72a7fc41688901e2f5ebe6f449fca349869 Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Sun, 16 Jan 2022 11:45:36 +0530 Subject: [PATCH 112/167] Update event.md Update content/en/docs/reference/glossary/event.md Create event.md Create event.md Update event.md Add full link Update content/en/docs/reference/glossary/event.md Update content/en/docs/reference/glossary/event.md Update content/en/docs/reference/glossary/event.md Update event.md Update event.md Co-Authored-By: Tim Bannister --- content/en/docs/reference/glossary/event.md | 25 +++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 content/en/docs/reference/glossary/event.md diff --git a/content/en/docs/reference/glossary/event.md b/content/en/docs/reference/glossary/event.md new file mode 100644 index 0000000000000..e534a9152728e --- /dev/null +++ b/content/en/docs/reference/glossary/event.md @@ -0,0 +1,25 @@ +--- +title: Event +id: event +date: 2022-01-16 +full_link: /docs/reference/kubernetes-api/cluster-resources/event-v1/ +short_description: > + A report of an event somewhere in the cluster. It generally denotes some state change in the system. +aka: +tags: +- core-object +- fundamental +--- +Each Event is a report of an event somewhere in the {{< glossary_tooltip text="cluster" term_id="cluster" >}}. +It generally denotes some state change in the system. + + +Events have a limited retention time and triggers and messages may evolve with time. +Event consumers should not rely on the timing of an event with a given reason reflecting a consistent underlying trigger, +or the continued existence of events with that reason. + + +Events should be treated as informative, best-effort, supplemental data. + +In Kubernetes, [auditing](/docs/tasks/debug-application-cluster/audit/) generates a different kind of +Event record (API group `audit.k8s.io`). From 3dfffd39c8bdb3cec2879d8160cab75451e268fb Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Tue, 18 Jan 2022 10:12:19 -0500 Subject: [PATCH 113/167] Clarify deprecation rule 3 --- content/en/docs/reference/using-api/deprecation-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index 6bbd9be9e1771..ae10c4dae5681 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -73,11 +73,11 @@ knows how to convert between them in both directions. Additionally, any new field added in v2 must be able to round-trip to v1 and back, which means v1 might have to add an equivalent field or represent it as an annotation. -**Rule #3: An API version in a given track may not be deprecated until a new -API version at least as stable is released.** +**Rule #3: An API version in a given track may not be deprecated in favor of a less stable API version.** -GA API versions can replace GA API versions as well as beta and alpha API -versions. Beta API versions *may not* replace GA API versions. + * GA API versions can replace beta and alpha API versions. + * Beta API versions can replace earlier beta and alpha API versions, but *may not* replace GA API versions. + * Alpha API versions can replace earlier alpha API versions, but *may not* replace GA or beta API versions. **Rule #4a: Other than the most recent API versions in each track, older API versions must be supported after their announced deprecation for a duration of From 04d22725726e59274927e2e48a2fc36e2bac3d59 Mon Sep 17 00:00:00 2001 From: Sakshi <85516345+krsakshi@users.noreply.github.com> Date: Wed, 19 Jan 2022 13:30:49 +0530 Subject: [PATCH 114/167] Update _index.html --- content/ja/_index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/_index.html b/content/ja/_index.html index b0a10050727f3..fed9dd229c850 100644 --- a/content/ja/_index.html +++ b/content/ja/_index.html @@ -41,12 +41,12 @@

150以上のマイクロサービスアプリケーションをKubernetes上

- 2020年11月17日-20日のKubeCon NAバーチャルに参加する + 2022年10月24日から28日までミシガン州のKubeConデトロイトに参加する



- 2021年5月4日-7日のKubeCon EUバーチャルに参加する + スペインのKubeConバレンシアに参加+バーチャル、2022年5月16〜20日
From 2c30b68c772790d8d99e891a4d23f2ea8f9b7935 Mon Sep 17 00:00:00 2001 From: Md Sahil <85174511+MdSahil-oss@users.noreply.github.com> Date: Wed, 19 Jan 2022 21:16:15 +0530 Subject: [PATCH 115/167] Update update-daemon-set.md

What type of PR is this ?

Improve documentation.

Which type of issue this PR fixes

fixes 31311(issue). --- content/en/docs/tasks/manage-daemon/update-daemon-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index e58b313acb42e..5640f1a946bb4 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -39,7 +39,7 @@ You may want to set (default to 1), [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) and -[`.spec.maxSurge`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge) +[`.spec.updateStrategy.rollingUpdate.maxSurge`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (a beta feature and defaults to 0) as well. ### Creating a DaemonSet with `RollingUpdate` update strategy From 40afa49efacb9a0225f85b690ea68eaf10d54694 Mon Sep 17 00:00:00 2001 From: Chris Short Date: Wed, 19 Jan 2022 14:16:57 -0500 Subject: [PATCH 116/167] Update static-pod.md Fixes Issue #31394 --- .../docs/tasks/configure-pod-container/static-pod.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index c889570dc7473..964770d714f0c 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -42,7 +42,7 @@ The `spec` of a static Pod cannot refer to other API objects {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods, +This page assumes you're using {{< glossary_tooltip term_id="containerd" >}} to run Pods, and that your nodes are running the Fedora operating system. Instructions for other distributions or Kubernetes installations may vary. @@ -156,7 +156,7 @@ already be running. You can view running containers (including static Pods) by running (on the node): ```shell # Run this command on the node where the kubelet is running -docker ps +crictl ps ``` The output might be something like: @@ -213,7 +213,7 @@ automatically: # Run these commands on the node where the kubelet is running docker stop f6d05272b57e # replace with the ID of your container sleep 20 -docker ps +crictl ps ``` ``` CONTAINER ID IMAGE COMMAND CREATED ... @@ -230,11 +230,11 @@ The running kubelet periodically scans the configured directory (`/etc/kubelet.d # mv /etc/kubelet.d/static-web.yaml /tmp sleep 20 -docker ps +crictl ps # You see that no nginx container is running mv /tmp/static-web.yaml /etc/kubelet.d/ sleep 20 -docker ps +crictl ps ``` ``` CONTAINER ID IMAGE COMMAND CREATED ... From d158cdf028b70405eb5858b5676babdd95fa5a7e Mon Sep 17 00:00:00 2001 From: Chris Short Date: Wed, 19 Jan 2022 15:10:45 -0500 Subject: [PATCH 117/167] Removing additional Docker mentions --- content/en/docs/tasks/configure-pod-container/static-pod.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 964770d714f0c..543eaae167c75 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -204,14 +204,13 @@ NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 12s ``` -Back on your node where the kubelet is running, you can try to stop the Docker -container manually. +Back on your node where the kubelet is running, you can try to stop the container manually. You'll see that, after a time, the kubelet will notice and will restart the Pod automatically: ```shell # Run these commands on the node where the kubelet is running -docker stop f6d05272b57e # replace with the ID of your container +crictl stop f6d05272b57e # replace with the ID of your container sleep 20 crictl ps ``` From f0a1484a70d087a5f9b01403ce956b41d02a04bb Mon Sep 17 00:00:00 2001 From: Md Sahil <85174511+MdSahil-oss@users.noreply.github.com> Date: Thu, 20 Jan 2022 15:44:48 +0530 Subject: [PATCH 118/167] Update update-daemon-set.md --- content/en/docs/tasks/manage-daemon/update-daemon-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index 5640f1a946bb4..d36f487794701 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -39,7 +39,7 @@ You may want to set (default to 1), [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) and -[`.spec.updateStrategy.rollingUpdate.maxSurge`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) +[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (a beta feature and defaults to 0) as well. ### Creating a DaemonSet with `RollingUpdate` update strategy From cde8c64ded4a80d5988a709611c11d0f60b13a9d Mon Sep 17 00:00:00 2001 From: Benjamin Elder Date: Thu, 20 Jan 2022 21:27:56 -0800 Subject: [PATCH 119/167] update build admins, add Juan Escobar, remove Amit Watve --- content/en/releases/release-managers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index e45c2858d6a3a..b3a562c9e3a28 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -169,9 +169,9 @@ of each minor (1.Y) and patch (1.Y.Z) release GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins) - Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)) -- Amit Watve ([@amwat](https://github.com/amwat)) - Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder)) - Grant McCloskey ([@MushuEE](https://github.com/MushuEE)) +- Juan Escobar ([@juanfescobar](https://github.com/juanfescobar)) ## SIG Release Leads From 2ba08d6cb895f145caa2353ec9cc117f35ad9998 Mon Sep 17 00:00:00 2001 From: gaoliang Date: Sat, 22 Jan 2022 02:36:08 +0800 Subject: [PATCH 120/167] Make TOC sticky --- assets/scss/_custom.scss | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 71f61c6ada170..0d8a98eb42024 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -305,6 +305,12 @@ footer { padding-top: 1.5rem !important; top: 5rem !important; + @supports (position: sticky) { + position: sticky !important; + height: calc(100vh - 10rem); + overflow-y: auto; + } + #TableOfContents { padding-top: 1rem; } From 54faa2dda1d369d6bfbec03aaac16d20947acb9c Mon Sep 17 00:00:00 2001 From: Sakshi <85516345+krsakshi@users.noreply.github.com> Date: Sat, 22 Jan 2022 11:43:40 +0530 Subject: [PATCH 121/167] Update _index.html --- content/ja/_index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/_index.html b/content/ja/_index.html index fed9dd229c850..203711cdfda1b 100644 --- a/content/ja/_index.html +++ b/content/ja/_index.html @@ -41,12 +41,12 @@

150以上のマイクロサービスアプリケーションをKubernetes上

- 2022年10月24日から28日までミシガン州のKubeConデトロイトに参加する + 2022年5月16日〜20日のKubeCon EUバーチャルに参加する



- スペインのKubeConバレンシアに参加+バーチャル、2022年5月16〜20日 + 2022年10月24日-28日のKubeCon NAバーチャルに参加する

From e0eb75215bc737a2c8e8407bb0d48d90b187df84 Mon Sep 17 00:00:00 2001 From: AugustasV Date: Sat, 22 Jan 2022 22:42:49 +0100 Subject: [PATCH 122/167] why_telemetery_agents_talk Signed-off-by: AugustasV --- ...migrating-telemetry-and-security-agents.md | 27 ++++++------------- 1 file changed, 8 insertions(+), 19 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index da3bdc1148ece..7720a502672b3 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -8,31 +8,20 @@ weight: 70 -With Kubernetes 1.20 dockershim was deprecated. From the -[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) -you might already know that most apps do not have a direct dependency on runtime hosting -containers. However, there are still a lot of telemetry and security agents -that has a dependency on docker to collect containers metadata, logs and -metrics. This document aggregates information on how to detect these -dependencies and links on how to migrate these agents to use generic tools or -alternative runtimes. +Docker is being deprecated. You can find a deprecation FAQ at [Don't Panic: Kubernetes and Docker](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Most apps do not have a direct dependency on runtime hosting containers. However, there are still a lot of telemetry and monitoring agents that has a dependency on docker to collect containers metadata, logs and metrics. This document aggregates information on how to detect these dependencies and links on how to migrate these agents to use generic tools or alternative runtimes. ## Telemetry and security agents -There are a few ways agents may run on Kubernetes cluster. Agents may run on -nodes directly or as DaemonSets. +There are a few ways agents may be run on kubernetes cluster. Agents have a direct +dependency on Docker when they run on nodes or as daemonsets. Some telemetry and +security agents may rely on certain logs or metrics specific for Docker that would not +be available any longer. This document does not cover these cases. -### Why do telemetry agents rely on Docker? +### Why do telemetry agents talk to Docker? -Historically, Kubernetes was built on top of Docker. Kubernetes is managing -networking and scheduling, Docker was placing and operating containers on a -node. So you can get scheduling-related metadata like a pod name from Kubernetes -and containers state information from Docker. Over time more runtimes were -created to manage containers. Also there are projects and Kubernetes features -that generalize container status information extraction across many runtimes. +Historically, Kubernetes was built on top of Docker. Kubernetes is managing networking and scheduling, Docker was placing and operating containers on a node. So you can get scheduling-related metadata like a pod name from Kubernetes and containers state information from Docker. Over time more runtimes were created to manage containers. Also there are projects and kubernetes features that generalize container status information extraction across many runtimes. -Some agents are tied specifically to the Docker tool. The agents may run -commands like [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) +But some agents are still Docker-dependent. They may run commands like [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) or [`docker top`](https://docs.docker.com/engine/reference/commandline/top/) to list containers and processes or [docker logs](https://docs.docker.com/engine/reference/commandline/logs/) to subscribe on docker logs. With the deprecating of Docker as a container runtime, From ecef64acbd11ebcb32a28813556937df83d64347 Mon Sep 17 00:00:00 2001 From: Vaibhaw Date: Mon, 24 Jan 2022 13:58:44 +0530 Subject: [PATCH 123/167] Update _index.html to sync with EN version ko : Updated KubeCon dates --- content/ko/_index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/_index.html b/content/ko/_index.html index 34cdfe5740915..e5c54b6a8a451 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -43,12 +43,12 @@

150+ 마이크로서비스를 쿠버네티스로 마이그레이션하는

- Attend KubeCon North America on October 11-15, 2021 + Attend KubeCon Europe on May 17-20, 2022



- Attend KubeCon Europe on May 17-20, 2022 + Attend KubeCon North America on October 24-28, 2022

From 8917b26250798ac6bfc786567066734425f00e84 Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Mon, 24 Jan 2022 10:09:00 -0500 Subject: [PATCH 124/167] PodSecurity: switch restricted volume check to positive check --- .../security/pod-security-standards.md | 36 +++++++------------ 1 file changed, 12 insertions(+), 24 deletions(-) diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index 205d4ddc8e083..014b64ab965be 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -305,34 +305,22 @@ fail validation. Volume Types -

In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.

+

The restricted policy only permits the following volume types.

Restricted Fields

    -
  • spec.volumes[*].hostPath
    • -
  • spec.volumes[*].gcePersistentDisk
    • -
  • spec.volumes[*].awsElasticBlockStore
    • -
  • spec.volumes[*].gitRepo
    • -
  • spec.volumes[*].nfs
    • -
  • spec.volumes[*].iscsi
    • -
  • spec.volumes[*].glusterfs
    • -
  • spec.volumes[*].rbd
    • -
  • spec.volumes[*].flexVolume
    • -
  • spec.volumes[*].cinder
    • -
  • spec.volumes[*].cephfs
    • -
  • spec.volumes[*].flocker
    • -
  • spec.volumes[*].fc
    • -
  • spec.volumes[*].azureFile
    • -
  • spec.volumes[*].vsphereVolume
    • -
  • spec.volumes[*].quobyte
    • -
  • spec.volumes[*].azureDisk
    • -
  • spec.volumes[*].portworxVolume
    • -
  • spec.volumes[*].scaleIO
    • -
  • spec.volumes[*].storageos
    • -
  • spec.volumes[*].photonPersistentDisk
    • +
  • spec.volumes[*]

Allowed Values

-
    -
  • Undefined/nil
    • + Every item in the spec.volumes[*] list must set one of the following fields to a non-null value: +
      +
    • spec.volumes[*].configMap
      • +
    • spec.volumes[*].csi
      • +
    • spec.volumes[*].downwardAPI
      • +
    • spec.volumes[*].emptyDir
      • +
    • spec.volumes[*].ephemeral
      • +
    • spec.volumes[*].persistentVolumeClaim
      • +
    • spec.volumes[*].projected
      • +
    • spec.volumes[*].secret
    From 4ca5ff6b3c0f3ee2fc99ca31653459d01dea2f3b Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Mon, 24 Jan 2022 10:10:12 -0500 Subject: [PATCH 125/167] PodSecurity: remove optional non-root group check --- .../security/pod-security-standards.md | 20 ------------------- 1 file changed, 20 deletions(-) diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index 014b64ab965be..73341e4c712e1 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -379,26 +379,6 @@ fail validation.
- - Non-root groups (optional) - -

Containers should be forbidden from running with a root primary or supplementary GID.

-

Restricted Fields

-
    -
  • spec.securityContext.runAsGroup
    • -
  • spec.securityContext.supplementalGroups[*]
    • -
  • spec.securityContext.fsGroup
    • -
  • spec.containers[*].securityContext.runAsGroup
    • -
  • spec.initContainers[*].securityContext.runAsGroup
    • -
  • spec.ephemeralContainers[*].securityContext.runAsGroup
    • -
-

Allowed Values

-
    -
  • Undefined/nil (except for *.runAsGroup)
    • -
  • Non-zero
    • -
- - Seccomp (v1.19+) From 6b672ac2b8751b17c3d32d2caea78b36c661cd26 Mon Sep 17 00:00:00 2001 From: Vitthal Sai Date: Mon, 24 Jan 2022 21:26:04 +0530 Subject: [PATCH 126/167] Update some Case Studies mentioning Docker --- content/en/case-studies/peardeck/index.html | 4 ++-- content/en/case-studies/prowise/index.html | 2 +- content/en/case-studies/squarespace/index.html | 2 +- content/en/case-studies/wink/index.html | 6 +++--- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/content/en/case-studies/peardeck/index.html b/content/en/case-studies/peardeck/index.html index 43982776778fc..77d94873fd50d 100644 --- a/content/en/case-studies/peardeck/index.html +++ b/content/en/case-studies/peardeck/index.html @@ -20,7 +20,7 @@

Challenge

Solution

-

In 2016, the company began moving their code from Heroku to Docker containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

+

In 2016, the company began moving their code from Heroku to containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

Impact

@@ -42,7 +42,7 @@

Impact

On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.

-

The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to Docker containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

+

The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

{{< case-studies/quote image="/images/case-studies/peardeck/banner1.jpg" >}} "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html index b8b584aa419fa..8e2a89c3851c5 100644 --- a/content/en/case-studies/prowise/index.html +++ b/content/en/case-studies/prowise/index.html @@ -70,7 +70,7 @@

Impact

Recently, the team launched a new single sign-on solution for use in an internal application. "Due to the resource based architecture of the Kubernetes platform, we were able to bring that application into an entirely new production environment in less than a day, most of that time used for testing after applying the already well-known resource definitions from staging to the new environment," says van den Bosch. "On a traditional VM this would have likely cost a day or two, and then probably a few weeks to iron out the kinks in our provisioning scripts as we apply updates."

-

Legacy applications are also being moved to Kubernetes. Not long ago, the team needed to set up a Java-based application for compiling and running a frontend. "On a traditional VM, it would have taken quite a bit of time to set it up and keep it up to date, not to mention maintenance for that setup down the line," says van den Bosch. Instead, it took less than half a day to Dockerize it and get it running on Kubernetes. "It was much easier, and we were able to save costs too because we didn't have to spin up new VMs specially for it."

+

Legacy applications are also being moved to Kubernetes. Not long ago, the team needed to set up a Java-based application for compiling and running a frontend. "On a traditional VM, it would have taken quite a bit of time to set it up and keep it up to date, not to mention maintenance for that setup down the line," says van den Bosch. Instead, it took less than half a day to containerize it and get it running on Kubernetes. "It was much easier, and we were able to save costs too because we didn't have to spin up new VMs specially for it."

{{< case-studies/quote author="VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE" >}} "We're really trying to deliver integrated solutions with our hardware and software and making it as easy as possible for users to use and collaborate from different places," says van den Bosch. And, says Haalstra, "We cannot do it without Kubernetes." diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html index 461e466d8c200..d39ce0b6f696a 100644 --- a/content/en/case-studies/squarespace/index.html +++ b/content/en/case-studies/squarespace/index.html @@ -46,7 +46,7 @@

Impact

After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." {{< /case-studies/quote >}} -

Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects Prometheus and fluentd to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."

+

Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects Prometheus and fluentd to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Dockerfile, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."

And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. "From end to end that probably took half an hour, and that's not accounting for the fact that an infrastructure engineer would be responsible for doing that, so there's some business delay in there as well."

diff --git a/content/en/case-studies/wink/index.html b/content/en/case-studies/wink/index.html index 1f8ea4c89da25..7b5a3f854124a 100644 --- a/content/en/case-studies/wink/index.html +++ b/content/en/case-studies/wink/index.html @@ -58,9 +58,9 @@

Impact

In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service," says Klein. "We've always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker."

-

At the time – just over two years ago – Docker wasn't yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn't really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads."

+

In 2015, Docker wasn't yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn't really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads."

-

Once Wink's backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."

+

Once Wink's backend engineering team decided on a containerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."

{{< case-studies/quote image="/images/case-studies/wink/banner4.jpg" >}} "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure." @@ -68,7 +68,7 @@

Impact

Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed," he says. "We didn't have to futz around with trying to take something like a Linux distro and install everything. It's got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It's not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed."

-

Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.

+

Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the containerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.

Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn't take care of routing, sharing configurations, secrets, et cetera, among instances of a service," Klein says. "All of those layers of functionality can be implemented, of course, but if you don't want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did."

From b828365a0e24275c3295ba94b716b8b1c441b0a3 Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Tue, 18 Jan 2022 10:13:13 -0500 Subject: [PATCH 127/167] Change deprecation rule 4a to make stable APIs permanent within a major version --- .../reference/using-api/deprecation-policy.md | 34 ++++++------------- 1 file changed, 10 insertions(+), 24 deletions(-) diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index ae10c4dae5681..e1c378c4ac3aa 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -79,15 +79,17 @@ might have to add an equivalent field or represent it as an annotation. * Beta API versions can replace earlier beta and alpha API versions, but *may not* replace GA API versions. * Alpha API versions can replace earlier alpha API versions, but *may not* replace GA or beta API versions. -**Rule #4a: Other than the most recent API versions in each track, older API -versions must be supported after their announced deprecation for a duration of -no less than:** +**Rule #4a: minimum API lifetime is determined by the API stability level** - * **GA: 12 months or 3 releases (whichever is longer)** - * **Beta: 9 months or 3 releases (whichever is longer)** - * **Alpha: 0 releases** + * **GA API versions may be marked as deprecated, but must not be removed within a major version of Kubernetes** + * **Beta API versions must be supported for 9 months or 3 releases (whichever is longer) after deprecation** + * **Alpha API versions may be removed in any release without prior deprecation notice** -This covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/). +This ensures beta API support covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/). + +{{< note >}} +There are no current plans for a major version revision of Kubernetes that removes GA APIs. +{{< /note >}} {{< note >}} Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is @@ -237,7 +239,7 @@ API versions are supported in a series of subsequent releases.
  • v2beta2 is deprecated, "action required" relnote
    • -
  • v1 is deprecated, "action required" relnote
    • +
  • v1 is deprecated in favor of v2, but will not be removed
@@ -267,22 +269,6 @@ API versions are supported in a series of subsequent releases. - - X+16 - v2, v1 (deprecated) - v2 - - - - X+17 - v2 - v2 - -
    -
  • v1 is removed, "action required" relnote
    • -
- - From 7023b926a6a26daa3c80d231dc65b5f392640893 Mon Sep 17 00:00:00 2001 From: Akpobome Oke Kelvin Date: Mon, 24 Jan 2022 19:55:33 +0100 Subject: [PATCH 128/167] [en] Updated the page to be more docker specific (#31421) * Update: Updated to be more docker specific * Update content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md Co-authored-by: Tim Bannister * Update content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md Co-authored-by: Tim Bannister * Update pull-image-private-registry.md * Update pull-image-private-registry.md * Update: fixes issue #31422 Co-authored-by: Tim Bannister --- .../assign-memory-resource.md | 2 +- .../pull-image-private-registry.md | 16 ++++++++++------ 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md index 7afb3cb249ca7..94c20297cf8b9 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -174,7 +174,7 @@ The output shows that the Container was killed because it is out of memory (OOM) ```shell lastState: terminated: - containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f + containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f exitCode: 137 finishedAt: 2017-06-20T20:52:19Z reason: OOMKilled diff --git a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md index 18f840d1e2c89..6849f22ec03f9 100644 --- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -7,8 +7,10 @@ weight: 100 This page shows how to create a Pod that uses a -{{< glossary_tooltip text="Secret" term_id="secret" >}} to pull an image from a -private container image registry or repository. +{{< glossary_tooltip text="Secret" term_id="secret" >}} to pull an image +from a private container image registry or repository. There are many private +registries in use. This task uses [Docker Hub](https://www.docker.com/products/docker-hub) +as an example registry. {{% thirdparty-content single="true" %}} @@ -18,6 +20,8 @@ private container image registry or repository. * To do this exercise, you need the `docker` command line tool, and a [Docker ID](https://docs.docker.com/docker-id/) for which you know the password. +* If you are using a different private container registry, you need the command + line tool for that registry and any login information for the registry. @@ -59,12 +63,13 @@ The output contains a section similar to this: If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value. {{< /note >}} -## Create a Secret based on existing Docker credentials {#registry-secret-existing-credentials} +## Create a Secret based on existing credentials {#registry-secret-existing-credentials} A Kubernetes cluster uses the Secret of `kubernetes.io/dockerconfigjson` type to authenticate with a container registry to pull a private image. -If you already ran `docker login`, you can copy that credential into Kubernetes: +If you already ran `docker login`, you can copy +that credential into Kubernetes: ```shell kubectl create secret generic regcred \ @@ -77,7 +82,7 @@ secret) then you can customise the Secret before storing it. Be sure to: - set the name of the data item to `.dockerconfigjson` -- base64 encode the docker file and paste that string, unbroken +- base64 encode the Docker configuration file and then paste that string, unbroken as the value for field `data[".dockerconfigjson"]` - set `type` to `kubernetes.io/dockerconfigjson` @@ -213,4 +218,3 @@ kubectl get pod private-reg * Learn more about [adding image pull secrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). * See [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-). * See the `imagePullSecrets` field within the [container definitions](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers) of a Pod - From a819c51c22f1c9856030f327037f2828ff8cb21f Mon Sep 17 00:00:00 2001 From: Chris Short Date: Mon, 24 Jan 2022 14:40:52 -0500 Subject: [PATCH 129/167] Update static-pod.md - Fixed brain flatuence around which runtime I was testing - Outputs changed - Noted added about crictl ps's default behavior of outputting sha256sum in image name - Image name in outputs have been shortened per Slack convo https://kubernetes.slack.com/archives/C02PZMA3R6E/p1643026840047600 --- .../configure-pod-container/static-pod.md | 31 ++++++++++--------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 543eaae167c75..1ad0151e235ef 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -42,7 +42,7 @@ The `spec` of a static Pod cannot refer to other API objects {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -This page assumes you're using {{< glossary_tooltip term_id="containerd" >}} to run Pods, +This page assumes you're using {{< glossary_tooltip term_id="cri-o" >}} to run Pods, and that your nodes are running the Fedora operating system. Instructions for other distributions or Kubernetes installations may vary. @@ -162,18 +162,20 @@ crictl ps The output might be something like: ``` -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106 ``` +Note: `crictl` outputs the image URI and SHA-256 checksum. `NAME` will look more like: `docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`. + You can see the mirror Pod on the API server: ```shell kubectl get pods ``` ``` -NAME READY STATUS RESTARTS AGE -static-web-my-node1 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +static-web 1/1 Running 0 2m ``` {{< note >}} @@ -190,18 +192,18 @@ If you try to use `kubectl` to delete the mirror Pod from the API server, the kubelet _doesn't_ remove the static Pod: ```shell -kubectl delete pod static-web-my-node1 +kubectl delete pod static-web ``` ``` -pod "static-web-my-node1" deleted +pod "static-web" deleted ``` You can see that the Pod is still running: ```shell kubectl get pods ``` ``` -NAME READY STATUS RESTARTS AGE -static-web-my-node1 1/1 Running 0 12s +NAME READY STATUS RESTARTS AGE +static-web 1/1 Running 0 4s ``` Back on your node where the kubelet is running, you can try to stop the container manually. @@ -210,13 +212,13 @@ automatically: ```shell # Run these commands on the node where the kubelet is running -crictl stop f6d05272b57e # replace with the ID of your container +crictl stop 129fd7d382018 # replace with the ID of your container sleep 20 crictl ps ``` ``` -CONTAINER ID IMAGE COMMAND CREATED ... -5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` ## Dynamic addition and removal of static pods @@ -236,7 +238,6 @@ sleep 20 crictl ps ``` ``` -CONTAINER ID IMAGE COMMAND CREATED ... -e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` - From 4a2fb111bdb73bc0558e7383e1a5dcb1f207195b Mon Sep 17 00:00:00 2001 From: Arhell Date: Tue, 25 Jan 2022 00:34:36 +0200 Subject: [PATCH 130/167] [id] fixed the list container images by pod section --- .../list-all-running-container-images.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md index 86a6b267e2510..a5e368b4a2712 100644 --- a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -76,7 +76,7 @@ Format dapat dikontrol lebih lanjut dengan menggunakan operasi `range` untuk melakukan iterasi untuk setiap elemen secara individual. ```sh -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 ``` @@ -86,7 +86,7 @@ Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`. ```sh -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 ``` ## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod From 669213a6f1c52e648bfe6e5104f74577b7415b3b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Adolfo=20Garc=C3=ADa=20Veytia=20=28Puerco=29?= Date: Mon, 24 Jan 2022 21:01:27 -0600 Subject: [PATCH 131/167] Add emergency release 1.23.3 to schedule.yaml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Adolfo García Veytia (Puerco) --- data/releases/schedule.yaml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index ddf00d690dd00..8e4547f02ab35 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -1,11 +1,14 @@ schedules: - release: 1.23 releaseDate: 2021-12-07 - next: 1.23.2 - cherryPickDeadline: 2022-01-14 - targetDate: 2022-01-19 + next: 1.23.3 + cherryPickDeadline: 2022-01-24 + targetDate: 2022-01-25 endOfLifeDate: 2023-02-28 previousPatches: + - release: 1.23.2 + cherryPickDeadline: 2022-01-14 + targetDate: 2022-01-19 - release: 1.23.1 cherryPickDeadline: 2021-12-14 targetDate: 2021-12-16 From 29fb92a20debd973e8aaf42818db82504a896e8c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Adolfo=20Garc=C3=ADa=20Veytia=20=28Puerco=29?= Date: Mon, 24 Jan 2022 21:02:15 -0600 Subject: [PATCH 132/167] Add release 1.23.3 to schedulke markdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Adolfo García Veytia (Puerco) --- content/en/releases/patch-releases.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index f241692009c89..bcc1e8c1b7a5f 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -92,6 +92,7 @@ End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.23.2 | 2022-01-14 | 2022-01-19 | [Out-of-Band Release](https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) | | 1.23.2 | 2022-01-14 | 2022-01-19 | | | 1.23.1 | 2021-12-14 | 2021-12-16 | | From 4d793a9a34fca9fcbbcb745cdf4e0233f8665725 Mon Sep 17 00:00:00 2001 From: yangxianzhao Date: Tue, 25 Jan 2022 11:17:27 +0800 Subject: [PATCH 133/167] Fix translate problem in Chinese doc --- content/zh/includes/user-guide-content-moved.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/includes/user-guide-content-moved.md b/content/zh/includes/user-guide-content-moved.md index 18b4b00073522..ed33f2ac583a7 100644 --- a/content/zh/includes/user-guide-content-moved.md +++ b/content/zh/includes/user-guide-content-moved.md @@ -3,6 +3,6 @@ The topics in the [User Guide](/docs/user-guide/) section of the Kubernetes docs are being moved to the [Tasks](/docs/tasks/), [Tutorials](/docs/tutorials/), and [Concepts](/docs/concepts) sections. The content in this topic has moved to: --> -Kubernetes文档中[使用手册](/zh/docs/user-guide/)部分中的主题被移动到 +Kubernetes文档中[用户指南](/zh/docs/user-guide/)部分中的主题被移动到 [任务](/zh/docs/tasks/)、[教程](/zh/docs/tutorials/)和[概念](/zh/docs/concepts)节。 本主题内容已移至: From 003b5dad5c4231b6c53f886f6d6f7f4ab5d7c66d Mon Sep 17 00:00:00 2001 From: Puerco Date: Mon, 24 Jan 2022 22:56:07 -0600 Subject: [PATCH 134/167] Fix dates in 1.23.3 patch release date Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> --- content/en/releases/patch-releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index bcc1e8c1b7a5f..ff1b75de9dea0 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -92,7 +92,7 @@ End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| -| 1.23.2 | 2022-01-14 | 2022-01-19 | [Out-of-Band Release](https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) | +| 1.23.3 | 2022-01-24 | 2022-01-25 | [Out-of-Band Release](https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) | | 1.23.2 | 2022-01-14 | 2022-01-19 | | | 1.23.1 | 2021-12-14 | 2021-12-16 | | From e08d312a6d91fb5132d755bf7e6b92892b8a7464 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 25 Jan 2022 17:46:30 +0900 Subject: [PATCH 135/167] Update projected-volumes.md --- content/en/docs/concepts/storage/projected-volumes.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index a3dfdb9ce5df3..d14d024f35d0a 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -26,7 +26,7 @@ Currently, the following types of volume sources can be projected: * `serviceAccountToken` All sources are required to be in the same namespace as the Pod. For more details, -see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md). +see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md)design document. ### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap} @@ -71,9 +71,7 @@ volume mount will not receive updates for those volume sources. ## SecurityContext interactions -The [proposal for file permission handling in projected service account volume](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#token-volume-projection) -enhancement introduced the projected files having the the correct owner -permissions set. +The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set. ### Linux From 88fbaa1160e6a746729815d98d10062ca28a79bf Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 25 Jan 2022 18:47:48 +0900 Subject: [PATCH 136/167] Update projected-volumes.md --- content/en/docs/concepts/storage/projected-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index d14d024f35d0a..3b98810f61c23 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -26,7 +26,7 @@ Currently, the following types of volume sources can be projected: * `serviceAccountToken` All sources are required to be in the same namespace as the Pod. For more details, -see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md)design document. +see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md) design document. ### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap} From 345ff4fcc1d5bf7dc9b4cba30a639fc5899556e7 Mon Sep 17 00:00:00 2001 From: Vitthal Sai Date: Tue, 25 Jan 2022 20:51:33 +0530 Subject: [PATCH 137/167] Updates Releases page to mention v1.23.3 --- data/releases/schedule.yaml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index 8e4547f02ab35..1a6cbe442b92e 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -1,11 +1,15 @@ schedules: - release: 1.23 releaseDate: 2021-12-07 - next: 1.23.3 - cherryPickDeadline: 2022-01-24 - targetDate: 2022-01-25 + next: 1.23.4 + cherryPickDeadline: 2022-02-11 + targetDate: 2022-02-16 endOfLifeDate: 2023-02-28 previousPatches: + - release: 1.23.3 + cherryPickDeadLine: 2022-01-24 + targetDate: 2022-01-25 + note: "Out-of-Bound Release https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY" - release: 1.23.2 cherryPickDeadline: 2022-01-14 targetDate: 2022-01-19 From cdfe3fa6bc1cee2472f1452c3e78a7fce1e75382 Mon Sep 17 00:00:00 2001 From: Subhasmita Swain <57298668+SubhasmitaSw@users.noreply.github.com> Date: Wed, 26 Jan 2022 05:54:26 +0530 Subject: [PATCH 138/167] removal of docker runtime mentions in feature gates page (#31498) * removal of docker runtime mentions in feature gates page * Update content/en/docs/reference/command-line-tools-reference/feature-gates.md Co-authored-by: Tim Bannister * Update content/en/docs/reference/command-line-tools-reference/feature-gates.md Co-authored-by: Tim Bannister Co-authored-by: Tim Bannister --- .../command-line-tools-reference/feature-gates.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 92ac9529cdcdb..323536157494f 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -562,7 +562,10 @@ Each feature gate is designed for enabling/disabling a specific feature: - `APIResponseCompression`: Compress the API responses for `LIST` or `GET` requests. - `APIServerIdentity`: Assign each API server an ID in a cluster. - `APIServerTracing`: Add support for distributed tracing in the API server. -- `Accelerators`: Enable Nvidia GPU support when using Docker +- `Accelerators`: Provided an early form of plugin to enable Nvidia GPU support when using + Docker Engine; no longer available. See + [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for + an alternative. - `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit) - `AffinityInAnnotations`: Enable setting [Pod affinity or anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity). @@ -571,7 +574,7 @@ Each feature gate is designed for enabling/disabling a specific feature: kubelets on Pod log requests. - `AnyVolumeDataSource`: Enable use of any custom resource as the `DataSource` of a {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}. -- `AppArmor`: Enable AppArmor based mandatory access control on Linux nodes when using Docker. +- `AppArmor`: Enable use of AppArmor mandatory access control for Pods running on Linux nodes. See [AppArmor Tutorial](/docs/tutorials/clusters/apparmor/) for more details. - `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes that can be attached to a node. From 20ee91f0daca2f7b37b572e284153dc119686167 Mon Sep 17 00:00:00 2001 From: William Denniss Date: Tue, 25 Jan 2022 16:28:26 -0800 Subject: [PATCH 139/167] Include link to Pod Security Admission in the PodSecurityPolicy deprecation notice (#31475) * Include link to Pod Security Admission in the PodSecurityPolicy deprecation notice Add a link to the Pod Security Admission feature, which replaces PodSecurityPolicy. Currently users who read this page may not realize what the replacement is. The linked blog post talks about the KEP that created Pod Security Admission, but with no direct link. * Remove link prefix Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> --- content/en/docs/concepts/policy/pod-security-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index 36172faba5adb..34ea1ecf3faa5 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -11,7 +11,8 @@ weight: 30 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}} -PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. For more information on the deprecation, +PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. It has been replaced by +[Pod Security Admission](/docs/concepts/security/pod-security-admission/). For more information on the deprecation, see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Pod Security Policies enable fine-grained authorization of pod creation and From 4e2f9b67a7ac940e2de0548bf04ac75791176c5a Mon Sep 17 00:00:00 2001 From: whitebear009 <98402152+whitebear009@users.noreply.github.com> Date: Wed, 26 Jan 2022 16:19:19 +0800 Subject: [PATCH 140/167] Update "kubeclt" to "kubectl" --- content/zh/docs/contribute/generate-ref-docs/quickstart.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/contribute/generate-ref-docs/quickstart.md b/content/zh/docs/contribute/generate-ref-docs/quickstart.md index cff372a2b473f..521b834153e17 100644 --- a/content/zh/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/zh/docs/contribute/generate-ref-docs/quickstart.md @@ -400,6 +400,6 @@ running the build targets, see the following guides: 要手动设置所需的构造仓库，执行构建目标，以生成各个参考文档，可参考下面的指南： * [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [为 kubeclt 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) +* [为 kubectl 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) * [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) From 2e812faacf29202436c95a6b06d70f67bc61acab Mon Sep 17 00:00:00 2001 From: Chris Short Date: Wed, 26 Jan 2022 07:14:31 -0500 Subject: [PATCH 141/167] Update static-pod.md Adding console to crictl ps output lines as suggested: https://github.com/kubernetes/website/pull/31410#discussion_r791186773 --- content/en/docs/tasks/configure-pod-container/static-pod.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 1ad0151e235ef..190326065ba7d 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -161,7 +161,7 @@ crictl ps The output might be something like: -``` +```console CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID 129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106 ``` @@ -216,7 +216,7 @@ crictl stop 129fd7d382018 # replace with the ID of your container sleep 20 crictl ps ``` -``` +```console CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID 89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` @@ -237,7 +237,7 @@ mv /tmp/static-web.yaml /etc/kubelet.d/ sleep 20 crictl ps ``` -``` +```console CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` From 9911912709adfea4d606edb7a7544f859504e38e Mon Sep 17 00:00:00 2001 From: SpecialYang <940129520@qq.com> Date: Wed, 26 Jan 2022 22:33:33 +0800 Subject: [PATCH 142/167] Fix imprecise statements for virtual hosting example --- content/en/docs/concepts/services-networking/ingress.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index a543ce1e0c37d..fa07048b5210f 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -485,9 +485,7 @@ web traffic to the IP address of your Ingress controller can be matched without virtual host being required. For example, the following Ingress routes traffic -requested for `first.bar.com` to `service1`, `second.bar.com` to `service2`, and any traffic -to the IP address without a hostname defined in request (that is, without a request header being -presented) to `service3`. +requested for `first.bar.com` to `service1`, `second.bar.com` to `service2`, and any traffic whose request host header doesn't match `first.bar.com` and `second.bar.com` to `service3`. {{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}} From 2e870ee7617e3b88b5ad1cdaa82aa0d72560ceeb Mon Sep 17 00:00:00 2001 From: Chris Short Date: Wed, 26 Jan 2022 10:20:32 -0500 Subject: [PATCH 143/167] console no worky; shortening lines --- .../configure-pod-container/static-pod.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 190326065ba7d..fcaa0d9db438c 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -162,11 +162,14 @@ crictl ps The output might be something like: ```console -CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID -129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106 +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106 ``` -Note: `crictl` outputs the image URI and SHA-256 checksum. `NAME` will look more like: `docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`. +{{< note >}} +`crictl` outputs the image URI and SHA-256 checksum. `NAME` will look more like: +`docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`. +{{< /note >}} You can see the mirror Pod on the API server: @@ -183,7 +186,6 @@ Make sure the kubelet has permission to create the mirror Pod in the API server. [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/). {{< /note >}} - {{< glossary_tooltip term_id="label" text="Labels" >}} from the static Pod are propagated into the mirror Pod. You can use those labels as normal via {{< glossary_tooltip term_id="selector" text="selectors" >}}, etc. @@ -217,8 +219,8 @@ sleep 20 crictl ps ``` ```console -CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID -89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` ## Dynamic addition and removal of static pods @@ -238,6 +240,6 @@ sleep 20 crictl ps ``` ```console -CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID -f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` From eee745066d05e6fdb14dda58c45ae5f108efe0b6 Mon Sep 17 00:00:00 2001 From: Prasad Katti Date: Wed, 26 Jan 2022 22:20:54 -0800 Subject: [PATCH 144/167] Move command to a code-block Put the command in a separate code block to keep things consistent --- content/en/docs/tasks/run-application/configure-pdb.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/en/docs/tasks/run-application/configure-pdb.md b/content/en/docs/tasks/run-application/configure-pdb.md index 3110c2f807dff..b4c735a330f38 100644 --- a/content/en/docs/tasks/run-application/configure-pdb.md +++ b/content/en/docs/tasks/run-application/configure-pdb.md @@ -173,7 +173,10 @@ automatically responds to changes in the number of replicas of the corresponding ## Create the PDB object -You can create or update the PDB object with a command like `kubectl apply -f mypdb.yaml`. +You can create or update the PDB object using kubectl. +```shell +kubectl apply -f mypdb.yaml +``` ## Check the status of the PDB From 4074c2e7c316d3347342e26c8c81e2b31f2a85d1 Mon Sep 17 00:00:00 2001 From: Sascha Grunert Date: Thu, 27 Jan 2022 09:41:56 +0100 Subject: [PATCH 145/167] Improve SeccompDefault documentation - Highlight that we do not change the Kubernetes API and how to verify the used seccomp profile - Fix the kind configuration and enhance the example with a custom workload. Signed-off-by: Sascha Grunert --- content/en/docs/tutorials/security/seccomp.md | 54 +++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/content/en/docs/tutorials/security/seccomp.md b/content/en/docs/tutorials/security/seccomp.md index 465dd1b1a0f19..5a3fa4a641b17 100644 --- a/content/en/docs/tutorials/security/seccomp.md +++ b/content/en/docs/tutorials/security/seccomp.md @@ -174,6 +174,15 @@ of security defaults while preserving the functionality of the workload. It is possible that the default profiles differ between container runtimes and their release versions, for example when comparing those from CRI-O and containerd. +{{< note >}} +Enabling the feature will neither change the Kubernetes +`securityContext.seccompProfile` API field nor add the deprecated annotations of +the workload. This provides users the possibility to rollback anytime without +actually changing the workload configuration. Tools like +[`crictl inspect`](https://github.com/kubernetes-sigs/cri-tools) can be used to +verify which seccomp profile is being used by a container. +{{< /note >}} + Some workloads may require a lower amount of syscall restrictions than others. This means that they can fail during runtime even with the `RuntimeDefault` profile. To mitigate such a failure, you can: @@ -203,6 +212,51 @@ kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 featureGates: SeccompDefault: true +nodes: + - role: control-plane + image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac + kubeadmConfigPatches: + - | + kind: JoinConfiguration + nodeRegistration: + kubeletExtraArgs: + seccomp-default: "true" + - role: worker + image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac + kubeadmConfigPatches: + - | + kind: JoinConfiguration + nodeRegistration: + kubeletExtraArgs: + feature-gates: SeccompDefault=true + seccomp-default: "true" +``` + +If the cluster is ready, then running a pod: + +```shell +kubectl run --rm -it --restart=Never --image=alpine alpine -- sh +``` + +Should now have the default seccomp profile attached. This can be verified by +using `docker exec` to run `crictl inspect` for the container on the kind +worker: + +```shell +docker exec -it kind-worker bash -c \ + 'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp' +``` + +```json +{ + "defaultAction": "SCMP_ACT_ERRNO", + "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"], + "syscalls": [ + { + "names": ["..."] + } + ] +} ``` ## Create a Pod with a seccomp profile for syscall auditing From 61174c49ba8357b6646da3e5359b1bd0b389b26b Mon Sep 17 00:00:00 2001 From: mtardy Date: Wed, 26 Jan 2022 12:23:45 +0100 Subject: [PATCH 146/167] Add warning for creating namespaces with the same name as public TLDs Uppercase Service API object following documentation style guide Co-authored-by: Tim Bannister Add mitigation propositions Add RFC reference for the trailing dot in an absolute DNS name Co-authored-by: Shannon Kularathna --- .../overview/working-with-objects/namespaces.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 234327094ea57..77998a74c492a 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -101,6 +101,21 @@ across namespaces, you need to use the fully qualified domain name (FQDN). As a result, all namespace names must be valid [RFC 1123 DNS labels](/docs/concepts/overview/working-with-objects/names/#dns-label-names). +{{< warning >}} +By creating namespaces with the same name as [public top-level +domains](https://data.iana.org/TLD/tlds-alpha-by-domain.txt), Services in these +namespaces can have short DNS names that overlap with public DNS records. +Workloads from any namespace performing a DNS lookup without a [trailing dot](https://datatracker.ietf.org/doc/html/rfc1034#page-8) will +be redirected to those services, taking precedence over public DNS. + +To mitigate this, limit privileges for creating namespaces to trusted users. If +required, you could additionally configure third-party security controls, such +as [admission +webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/), +to block creating any namespace with the name of [public +TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt). +{{< /warning >}} + ## Not All Objects are in a Namespace Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are From 8ea2fb38edfe4499bc77efe684cee476dbed67d8 Mon Sep 17 00:00:00 2001 From: Michel Bongard <32648275+mbongard@users.noreply.github.com> Date: Thu, 27 Jan 2022 12:37:35 +0100 Subject: [PATCH 147/167] Update logging.md --- content/en/docs/concepts/cluster-administration/logging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index 1bf057f23e490..e0e6ef8d7d8a5 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -12,7 +12,7 @@ weight: 60 Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism. Likewise, container engines are designed to support logging. The easiest and most adopted logging method for containerized applications is writing to standard output and standard error streams. However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. -For example, you may want access your application's logs if a container crashes; a pod gets evicted; or a node dies. +For example, you may want to access your application's logs if a container crashes, a pod gets evicted, or a node dies. In a cluster, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level logging_. From 84c3c3b1a667e05106ce96050305b1767fc51094 Mon Sep 17 00:00:00 2001 From: Praveen Rewar <8457124+praveenrewar@users.noreply.github.com> Date: Thu, 27 Jan 2022 17:31:05 +0530 Subject: [PATCH 148/167] Fix broken link in docs/concepts/services-networking/ingress/ --- content/fr/docs/concepts/services-networking/ingress.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/concepts/services-networking/ingress.md b/content/fr/docs/concepts/services-networking/ingress.md index 5a611a6ad776a..2699864484c01 100644 --- a/content/fr/docs/concepts/services-networking/ingress.md +++ b/content/fr/docs/concepts/services-networking/ingress.md @@ -97,7 +97,7 @@ Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a b  est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).  Différents [Ingress controller](/docs/concepts/services-networking/ingress-controllers) prennent en charge différentes annotations. Consultez la documentation du contrôleur Ingress de votre choix pour savoir quelles annotations sont prises en charge. -La [spécification de la ressource Ingress](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il +La [spécification de la ressource Ingress](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il contient une liste de règles d'appariement de toutes les demandes entrantes. La ressource Ingress ne supporte que les règles pour diriger le trafic HTTP. From 976004b957439c8e6c632cd2f6e23933d0c3d958 Mon Sep 17 00:00:00 2001 From: Christopher Negus Date: Thu, 27 Jan 2022 22:05:02 +0000 Subject: [PATCH 149/167] Change docker cgroup driver example to containerd --- .../docs/tasks/administer-cluster/reserve-compute-resources.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md index d4cce14870c3c..06e49586979d8 100644 --- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -67,7 +67,7 @@ transient slices for resources that are supported by that init system. Depending on the configuration of the associated container runtime, operators may have to choose a particular cgroup driver to ensure proper system behavior. For example, if operators use the `systemd` -cgroup driver provided by the `docker` runtime, the `kubelet` must +cgroup driver provided by the `containerd` runtime, the `kubelet` must be configured to use the `systemd` cgroup driver. ### Kube Reserved From 9c3e655989a1726526eeeddb8438f82e79d2edb8 Mon Sep 17 00:00:00 2001 From: Guangwen Feng Date: Mon, 6 Dec 2021 13:52:05 +0800 Subject: [PATCH 150/167] [zh] Update persistent-volumes.md Signed-off-by: Guangwen Feng --- .../concepts/storage/persistent-volumes.md | 110 +++++++++++++++--- 1 file changed, 92 insertions(+), 18 deletions(-) diff --git a/content/zh/docs/concepts/storage/persistent-volumes.md b/content/zh/docs/concepts/storage/persistent-volumes.md index c1862025480b0..34341afd97f93 100644 --- a/content/zh/docs/concepts/storage/persistent-volumes.md +++ b/content/zh/docs/concepts/storage/persistent-volumes.md @@ -7,7 +7,6 @@ feature: 或 AWS 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder 或 Flocker 这类网络存储系统。 - content_type: concept weight: 20 --- @@ -23,7 +22,6 @@ feature: title: Storage orchestration description: > Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as GCP or AWS, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker. - content_type: concept weight: 20 --> @@ -31,9 +29,9 @@ weight: 20 -本文描述 Kubernetes 中 _持久卷（Persistent Volume）_ 的当前状态。 +本文描述 Kubernetes 中的 _持久卷（Persistent Volume）_ 。 建议先熟悉[卷（Volume）](/zh/docs/concepts/storage/volumes/)的概念。 @@ -446,21 +444,21 @@ to `Retain`, including cases where you are reusing an existing PV. {{< feature-state for_k8s_version="v1.11" state="beta" >}} 现在，对扩充 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 +{{< warning >}} +直接编辑 PersistentVolume 的大小可以阻止该卷自动调整大小。 +如果对 PersistentVolume 的容量进行编辑，然后又将其所对应的 +PersistentVolumeClaim 的 `.spec` 进行编辑，使该 PersistentVolumeClaim +的大小匹配 PersistentVolume 的话，则不会发生存储大小的调整。 +Kubernetes 控制平面将看到两个资源的所需状态匹配，并认为其后备卷的大小 +已被手动增加，无需调整。 +{{< /warning >}} + @@ -518,8 +534,8 @@ When a volume contains a file system, the file system is only resized when a new the PersistentVolumeClaim in `ReadWrite` mode. File system expansion is either done when a Pod is starting up or when a Pod is running and the underlying file system supports online expansion. -FlexVolumes allow resize if the driver is set with the `RequiresFSResize` capability to `true`. -The FlexVolume can be resized on Pod restart. +FlexVolumes (deprecated since Kubernetes v1.23) allow resize if the driver is configured with the +`RequiresFSResize` capability to `true`. The FlexVolume can be resized on Pod restart. --> 当卷中包含文件系统时，只有在 Pod 使用 `ReadWrite` 模式来使用 PVC 申领的 情况下才能重设其文件系统的大小。 @@ -527,7 +543,7 @@ The FlexVolume can be resized on Pod restart. 扩充的前提下在 Pod 运行期间完成。 如果 FlexVolumes 的驱动将 `RequiresFSResize` 能力设置为 `true`，则该 -FlexVolume 卷可以在 Pod 重启期间调整大小。 +FlexVolume 卷（于 Kubernetes v1.23 弃用）可以在 Pod 重启期间调整大小。 #### 处理扩充卷过程中的失败 {#recovering-from-failure-when-expanding-volumes} +如果用户指定的新大小过大，底层存储系统无法满足，PVC 的扩展将不断重试， +直到用户或集群管理员采取一些措施。这种情况是不希望发生的，因此 Kubernetes +提供了以下从此类故障中恢复的方法。 + +{{< tabs name="recovery_methods" >}} +{{% tab name="集群管理员手动处理" %}} + + 如果扩充下层存储的操作失败，集群管理员可以手动地恢复 PVC 申领的状态并 取消重设大小的请求。否则，在没有管理员干预的情况下，控制器会反复重试 重设大小的操作。 @@ -605,6 +631,53 @@ If expanding underlying storage fails, the cluster administrator can manually re 这一操作将把新的 PVC 对象绑定到现有的 PV 卷。 5. 不要忘记恢复 PV 卷上设置的回收策略。 +{{% /tab %}} +{{% tab name="通过请求扩展为更小尺寸" %}} +{{% feature-state for_k8s_version="v1.23" state="alpha" %}} + + +{{< note >}} +Kubernetes 从 1.23 版本开始将允许用户恢复失败的 PVC 扩展这一能力作为 +alpha 特性支持。 `RecoverVolumeExpansionFailure` 必须被启用以允许使用此功能。 +可参考[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +文档了解更多信息。 +{{< /note >}} + + +如果集群中的特性门控 `ExpandPersistentVolumes` 和 `RecoverVolumeExpansionFailure` +都已启用，在 PVC 的扩展发生失败时，你可以使用比先前请求的值更小的尺寸来重试扩展。 +要使用一个更小的尺寸尝试请求新的扩展，请编辑该 PVC 的 `.spec.resources` 并选择 +一个比你之前所尝试的值更小的值。 +如果由于容量限制而无法成功扩展至更高的值，这将很有用。 +如果发生了这种情况，或者你怀疑可能发生了这种情况，你可以通过指定一个在底层存储供应容量 +限制内的尺寸来重试扩展。你可以通过查看 `.status.resizeStatus` 以及 PVC 上的事件 +来监控调整大小操作的状态。 + + +请注意， +尽管你可以指定比之前的请求更低的存储量，新值必须仍然高于 `.status.capacity`。 +Kubernetes 不支持将 PVC 缩小到小于其当前的尺寸。 + +{{% /tab %}} +{{% /tabs %}} + + -Kubernetes zaprasza do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych! +*Kubernetes zaprasza do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych!* {{< note >}} Aby dowiedzieć się więcej ogólnych informacji o współpracy przy tworzeniu Kubernetesa, zajrzyj @@ -43,17 +43,94 @@ wymagana jest pewna biegłość w korzystaniu z Aby zaangażować się w prace nad dokumentacją należy: 1. Podpisać [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md) CNCF. -1. Zapoznać się z [repozytorium dokumentacji](https://github.com/kubernetes/website) +2. Zapoznać się z [repozytorium dokumentacji](https://github.com/kubernetes/website) i z [generatorem statycznej strony](https://gohugo.io) www. -1. Zrozumieć podstawowe procesy [otwierania *pull request*](/docs/contribute/new-content/new-content/) oraz +3. Zrozumieć podstawowe procesy [otwierania *pull request*](/docs/contribute/new-content/new-content/) oraz [recenzowania zmian](/docs/contribute/review/reviewing-prs/). + + + +{{< mermaid >}} +flowchart TB +subgraph third[Otwórz PR] +direction TB +U[ ] -.- +Q[Ulepsz zawartość] --- N[Dodaj nową] +N --- O[Przetłumacz dokumentację] +O --- P[Zarządzaj dokumentacją
przy kolejnych
wydaniach K8s] + +end + +subgraph second[Recenzuj] +direction TB + T[ ] -.- + D[Przejrzyj
repozytorium
K8s/website] --- E[Pobierz generator
stron statycznych
Hugo] + E --- F[Zrozum podstawowe
polecenia GitHub-a] + F --- G[Zrecenzuj otwarty PR
i zmień procesy
recenzji] +end + +subgraph first[Zapisz się] + direction TB + S[ ] -.- + B[Podpisz CNCF
Contributor
License Agreement] --- C[Dołącz do Slack-a
sig-docs] + C --- V[Zapisz się na listę
kubernetes-sig-docs] + V --- M[Weź udział w cotygodniowych
spotkaniach sig-docs] +end + +A([fa:fa-user Nowy
uczestnik]) --> first +A --> second +A --> third +A --> H[Zapytaj!!!] + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey +class S,T,U spacewhite +class first,second,third white +{{}} +***Schemat - Jak zacząć współpracę*** + +To jest schemat postępowania dla osób, które chcą zacząć współtworzyć Kubernetesa. Przejdź część lub wszystkie kroki opisane w częściach `Zapisz się` i `Recenzuj`. Teraz już możesz tworzyć nowe PR, zgodnie z sugestiami w `Otwórz PR`. I jak zawsze, pytania mile widziane! + Do realizacji niektórych zadań potrzeba wyższego poziomu zaufania i odpowiednich uprawnień w organizacji Kubernetes. Zajrzyj do [Participating in SIG Docs](/docs/contribute/participate/) po więcej szczegółów dotyczących ról i uprawnień. ## Pierwsze kroki +Zapoznaj się z krokami opisanymi poniżej, aby się lepiej przygotować. + + + + +{{< mermaid >}} +flowchart LR + subgraph second[Pierwszy wkład] + direction TB + S[ ] -.- + G[Obejrzyj PRy
innych uczestników K8s] --> + A[Przejrzyj listę zgłoszonych spraw
na K8s/website
po pomysł na nowy PR] --> B[Otwórz PR!!] + end + subgraph first[Sugerowane przygotowanie] + direction TB + T[ ] -.- + D[Przeczytaj wprowadzenie
dla współtwórców] -->E[Przeczytaj K8s content
and style guides] + E --> F[Poczytaj o typach zawartości
stron i skrótach Hugo] + end + + first ----> second + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,D,E,F,G grey +class S,T spacewhite +class first,second white +{{}} +***Schemat - Jak się przygotować*** + - Przeczytaj [Contribution overview](/docs/contribute/new-content/overview/), aby dowiedzieć się o różnych sposobach współpracy. - Zajrzyj do [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute), @@ -89,10 +166,12 @@ Aby włączyć się w komunikację w ramach SIG Docs, możesz: się przedstawić! - [Zapisać się na listę `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), na której prowadzone są dyskusje o szerszym zasięgu i zapisywane oficjalne decyzje. -- Dołączyć do [cotygodniowego spotkania wideo SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs). Spotkania są zawsze zapowiadane na `#sig-docs` i dodawane do [kalendarza spotkań społeczności Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). Będziesz potrzebował komunikatora [Zoom](https://zoom.us/download) lub telefonu, aby się wdzwonić. +- Dołączyć do [spotkania wideo SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) odbywającego się co dwa tygodnie. Spotkania są zawsze zapowiadane na `#sig-docs` i dodawane do [kalendarza spotkań społeczności Kubernetesa](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=Europe/Warsaw). Będziesz potrzebował komunikatora [Zoom](https://zoom.us/download) lub telefonu, aby się wdzwonić. +- Dołączyć do spotkania SIG Docs na Slacku organizowanego w tych tygodniach, kiedy nie ma spotkania na Zoomie. Informacja o spotkaniu zawsze ogłaszana jest na `#sig-docs`. W rozmowach prowadzonych w różnych wątkach na tym kanale można brać udział do 24 godzin od chwili ogłoszenia. ## Inne sposoby współpracy -- Odwiedź [stronę społeczności Kubernetes](/community/). Korzystaj z Twittera i Stack Overflow, dowiedz się o spotkaniach lokalnych grup Kubernetes, różnych wydarzeniach i nie tylko. -- Przeczytaj [ściągawkę dla współtwórców](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet), aby zaangażować się w dalszy rozwój Kubernetesa. +- Odwiedź [stronę społeczności Kubernetesa](/community/). Korzystaj z Twittera i Stack Overflow, dowiedz się o spotkaniach lokalnych grup Kubernetesa, różnych wydarzeniach i nie tylko. +- Przeczytaj [ściągawkę dla współtwórców](https://www.kubernetes.dev/docs/contributor-cheatsheet/contributor-cheatsheet/), aby zaangażować się w dalszy rozwój Kubernetesa. +- Odwiedź stronę [Kubernetes Contributors](https://www.kubernetes.dev/) i zajrzyj do [dodatkowych zasobów](https://www.kubernetes.dev/resources/). - Przygotuj [wpis na blogu lub *case study*](/docs/contribute/new-content/blogs-case-studies/). diff --git a/content/pl/docs/reference/_index.md b/content/pl/docs/reference/_index.md index 3d35c69263eb6..92dc512a58a95 100644 --- a/content/pl/docs/reference/_index.md +++ b/content/pl/docs/reference/_index.md @@ -56,7 +56,7 @@ biblioteki to: * [Scheduler Profiles](/docs/reference/scheduling/config#profiles) * Spis [portów i protokołów](/docs/reference/ports-and-protocols/), które - muszą być otwarte dla warstwy sterowania i na węzłach roboczych + muszą być otwarte dla warstwy sterowania i na węzłach roboczych. ## API konfiguracji @@ -65,14 +65,15 @@ Kubernetesa lub innych narzędzi. Choć większość tych API nie jest udostępn serwer API w trybie RESTful, są one niezbędne dla użytkowników i administratorów w korzystaniu i zarządzaniu klastrem. -* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) -* [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) -* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) -* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) -* [kube-scheduler policy reference (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) +* [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/) +* [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) i + [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) +* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) i + [kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) * [kube-proxy configuration (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) * [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/) -* [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) +* [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) i + [Client authentication API (v1)](/docs/reference/config-api/client-authentication.v1/) * [WebhookAdmission configuration (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) ## API konfiguracji dla kubeadm diff --git a/content/pl/docs/reference/glossary/container-runtime.md b/content/pl/docs/reference/glossary/container-runtime.md index f86c1c1d2c170..58dc243e87565 100644 --- a/content/pl/docs/reference/glossary/container-runtime.md +++ b/content/pl/docs/reference/glossary/container-runtime.md @@ -15,7 +15,7 @@ tags: -Kubernetes obsługuje różne *container runtimes*: {{< glossary_tooltip term_id="docker">}}, +Kubernetes obsługuje różne *container runtimes*: {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}} oraz każdą implementację zgodną z [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). From d6ee6da7bc7e8cd3c55d5b2dd685cf4f244d87c4 Mon Sep 17 00:00:00 2001 From: Wang Date: Sat, 29 Jan 2022 18:48:02 +0900 Subject: [PATCH 156/167] [ja] Translate reference/using-api into Japanese (#30703) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * done * fix typo * 英単語と日本語の間に半角スペースは不要 * fix feedback and minor change * delete unneeded blank line * Update content/ja/docs/reference/using-api/_index.md Co-authored-by: nasa9084 Co-authored-by: nasa9084 --- content/ja/docs/reference/using-api/_index.md | 114 ++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 content/ja/docs/reference/using-api/_index.md diff --git a/content/ja/docs/reference/using-api/_index.md b/content/ja/docs/reference/using-api/_index.md new file mode 100644 index 0000000000000..2dff67b71fcdc --- /dev/null +++ b/content/ja/docs/reference/using-api/_index.md @@ -0,0 +1,114 @@ +--- +title: API概要 +content_type: concept +weight: 10 +no_list: true +card: + name: reference + weight: 50 + title: API概要 +--- + + + +このセクションでは、Kubernetes APIのリファレンス情報を提供します。 + +REST APIはKubernetesの基本的な構造です。 +すべての操作とコンポーネント間のと通信、および外部ユーザーのコマンドは、REST API呼び出しでありAPIサーバーが処理します。 + +その結果、Kubernetesプラットフォーム内のすべてのものは、APIオブジェクトとして扱われ、[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)に対応するエントリーがあります。 + +[Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)は、Kubernetesバージョン{{< param "version" >}}のAPI一覧を提供します。 + +一般的な背景情報を知るには、[The Kubernetes API](/docs/concepts/overview/kubernetes-api/)、 +[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/)を読んでください。 +それらはKubernetes APIサーバーがクライアントを認証する方法とリクエストを認可する方法を説明します。 + +## APIバージョニング + +JSONとProtobufなどのシリアル化スキーマの変更については同じガイドラインに従います。 +以下の説明は、両方のフォーマットをカバーしています。 + +APIのバージョニングとソフトウェアのバージョニングは間接的に関係しています。 +[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)は、APIバージョニングとソフトウェアバージョニングの関係を説明しています。 + +APIのバージョンが異なると、安定性やサポートのレベルも異なります。 +各レベルの基準については、[API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)で詳しく説明しています。 + +各レベルの概要は以下の通りです: + +- Alpha: + - バージョン名に「alpha」が含まれています（例：「v1alpha1」）。 + - バグが含まれている可能性があります。 + 機能を有効にするとバグが露呈する可能性があります。 + 機能がデフォルトで無効になっている可能性があります。 + - ある機能のサポートは、予告なしにいつでも中止される可能性があります。 + - 後にリリースされるソフトウェアで、互換性のない方法で予告なく変更される可能性があります。 + - バグのリスクが高く、長期的なサポートが得られないため、短期間のテストクラスターのみでの使用を推奨します。 + +- Beta: + - バージョン名には `beta` が含まれています(例：`v2beta3`)。 + - ソフトウェアは十分にテストされています。 + 機能を有効にすることは安全であると考えられています。 + 機能はデフォルトで有効になっています。 + - 機能のサポートが打ち切られることはありませんが、詳細は変更される可能性があります。 + + - オブジェクトのスキーマやセマンティクスは、その後のベータ版や安定版のリリースで互換性のない方法で変更される可能性があります。 + このような場合には、移行手順が提供されます。 + スキーマの変更に伴い、APIオブジェクトの削除、編集、再作成が必要になる場合があります。 + 編集作業は単純ではないかもしれません。 + 移行に伴い、その機能に依存しているアプリケーションのダウンタイムが必要になる場合があります。 + + - 本番環境での使用は推奨しません。 + 後続のリリース は、互換性のない変更を導入する可能性があります。 + 独立してアップグレード可能な複数のクラスターがある場合、この制限を緩和できる可能性があります。 + + {{< note >}} +ベータ版の機能をお試しいただき、ご意見をお寄せください。 +ベータ版の機能が終了した後はこれ以上の変更ができない場合があります。 + {{< /note >}} + +- Stable: + - バージョン名は `vX` であり、`X` は整数である。 + - 安定版の機能は、リリースされたソフトウェアの中で、その後の多くのバージョンに登場します。 + +## APIグループ + +[API groups](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)で、KubernetesのAPIを簡単に拡張することができます。 +APIグループは、RESTパスとシリアル化されたオブジェクトの`apiVersion`フィールドで指定されます。 + +KubernetesにはいくつかのAPIグループがあります: + +* *core*(*legacy*とも呼ばれる)グループは、RESTパス `/api/v1` にあります。 + コアグループは `apiVersion` フィールドの一部としては指定されません。 + 例えば、`apiVersion: v1` のように。 +* 名前付きのグループは、RESTパス `/apis/$GROUP_NAME/$VERSION` にあり、以下のように使用します。 + `apiVersion: $GROUP_NAME/$VERSION`を使用します(例：`apiVersion: batch/v1`)。 + サポートされているAPIグループの完全なリストは以下にあります。 + [Kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#strong-api-groups-strong-)。 + +## APIグループの有効化と無効化 {#enabling-or-disabling} + +一部のリソースやAPIグループはデフォルトで有効になっています。 +APIサーバー上で`--runtime-config`を設定することで、有効にしたり無効にしたりすることができます。 +また`runtime-config`フラグには、APIサーバーのランタイム構成を記述したコンマ区切りの`[=]`ペアを指定します。 +もし`=`の部分が省略された場合には、`=true`が指定されたものとして扱われます。 + +例えば: + + - `batch/v1`を無効するには、`--runtime-config=batch/v1=false`を設定する + - `batch/v2alpha1`を有効するには、`--runtime-config=batch/v2alpha1`を設定する + +{{< note >}} +グループやリソースを有効または無効にした場合、 +APIサーバーとコントローラマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。 +{{< /note >}} + +## 永続化 + +Kubernetesはシリアライズされた状態を、APIリソースとして{{< glossary_tooltip term_id="etcd" >}}に書き込んで保存します。 + +## {{% heading "whatsnext" %}} + +- [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)をもっと知る +- [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)の設計ドキュメントを読む From 8c7c94d578aa8d1bd8813bcd4f9fe0ddaeb9fb6e Mon Sep 17 00:00:00 2001 From: Ameya Sathe Date: Sun, 30 Jan 2022 16:16:58 +0530 Subject: [PATCH 157/167] Updates url to point to the glossary Substitutes the existing url to archived documentation of "Kubernetes Resource" with URL pointing to glossary . Fixes the https://github.com/kubernetes/website/issues/31396 --- content/en/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 41dab6b043046..8dd8cc4e98978 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -422,7 +422,7 @@ Helper programs relating to the volume type may be required for consumption of a ### Capacity -Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) to understand the units expected by `capacity`. +Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. Read the glossary term [Quantity](https://kubernetes.io/docs/reference/glossary/?all=true#term-quantity) to understand the units expected by `capacity`. Currently, storage size is the only resource that can be set or requested. Future attributes may include IOPS, throughput, etc. From 16c4d4555a2235215d94bf416cf869204d0cb6aa Mon Sep 17 00:00:00 2001 From: Wang Date: Sun, 30 Jan 2022 22:48:23 +0900 Subject: [PATCH 158/167] [ja] Translate reference/kubectl/conventions into Japanese (#30785) * add the target * done * Update conventions.md * Update content/ja/docs/reference/kubectl/conventions.md Co-authored-by: nasa9084 * Update content/ja/docs/reference/kubectl/conventions.md Co-authored-by: nasa9084 * Update content/ja/docs/reference/kubectl/conventions.md Co-authored-by: nasa9084 * Update content/ja/docs/reference/kubectl/conventions.md Co-authored-by: nasa9084 Co-authored-by: nasa9084 --- .../ja/docs/reference/kubectl/conventions.md | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 content/ja/docs/reference/kubectl/conventions.md diff --git a/content/ja/docs/reference/kubectl/conventions.md b/content/ja/docs/reference/kubectl/conventions.md new file mode 100644 index 0000000000000..338c97152adac --- /dev/null +++ b/content/ja/docs/reference/kubectl/conventions.md @@ -0,0 +1,58 @@ +--- +title: kubectlの使用規則 +content_type: concept +--- + + +`kubectl`の推奨される使用規則です。 + + + +## 再利用可能なスクリプトでの`kubectl`の使用 + +スクリプトでの安定した出力のために: + +* `-o name`, `-o json`, `-o yaml`, `-o go-template`, `-o jsonpath` などの機械指向の出力形式のいずれかを必要します。 +* バージョンを完全に指定します。例えば、`jobs.v1.batch/myjob`のようにします。これにより、kubectlが時間とともに変化する可能性のあるデフォルトのバージョンを使用しないようにします。 +* コンテキストや設定、その他の暗黙的な状態に頼ってはいけません。 + +## ベストプラクティス + +### `kubectl run` + +`kubectl run`がインフラのコード化を満たすために: + +* イメージにバージョン固有のタグを付けて、そのタグを新しいバージョンに移さない。例えば、`:latest`ではなく、`:v1234`、`v1.2.3`、`r03062016-1-4`を使用してください(詳細は、[Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images)を参照してください)。 +* パラメーターが多用されているイメージをスクリプトでチェックします。 +* `kubectl run` フラグでは表現できない機能を、ソースコントロールでチェックした設定ファイルに切り替えます。 + +`dry-run=client` フラグを使用すると、実際に送信することなく、クラスターに送信されるオブジェクトを確認することができます。 + +{{< note >}} +すべての`kubectl run`ジェネレーターは非推奨です。ジェネレーターの[リスト](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators)とその使用方法については、Kubernetes v1.17のドキュメントを参照してください。 +{{< /note >}} + +#### Generators +`kubectl create --dry-run=client -o yaml`というkubectlコマンドで以下のリソースを生成することができます。 + +* `clusterrole`: ClusterRoleを作成します。 +* `clusterrolebinding`: 特定のClusterRoleに対するClusterRoleBindingを作成します。 +* `configmap`: ローカルファイル、ディレクトリ、またはリテラル値からConfigMapを作成します。 +* `cronjob`: 指定された名前のCronJobを作成します。 +* `deployment`: 指定された名前でDeploymentを作成します。 +* `job`: 指定された名前でJobを作成します。 +* `namespace`: 指定された名前でNamespaceを作成します。 +* `poddisruptionbudget`: 指定された名前でPodDisruptionBudgetを作成します。 +* `priorityclass`: 指定された名前でPriorityClassを作成します。 +* `quota`: 指定された名前でQuotaを作成します。 +* `role`: 1つのルールでRoleを作成します。 +* `rolebinding`: 特定のロールやClusterRoleに対するRoleBindingを作成します。 +* `secret`: 指定されたサブコマンドを使用してSecretを作成します。 +* `service`: 指定されたサブコマンドを使用してServiceを作成します。 +* `ServiceAccount`: 指定された名前でServiceAccountを作成します。 + +### `kubectl apply` + +* リソースの作成や更新には `kubectl apply` を使用できます。kubectl applyを使ったリソースの更新については、[Kubectl Book](https://kubectl.docs.kubernetes.io)を参照してください。 + + From c4aae8801199d8f2733cecc1971af3a3ef0947be Mon Sep 17 00:00:00 2001 From: Wang Date: Sun, 30 Jan 2022 22:50:23 +0900 Subject: [PATCH 159/167] [ja] Translate tasks/debug-application-cluster/debug-application-introspection into Japanese (#30868) * done * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md Co-authored-by: nasa9084 Co-authored-by: nasa9084 --- .../debug-application-introspection.md | 399 ++++++++++++++++++ 1 file changed, 399 insertions(+) create mode 100644 content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md new file mode 100644 index 0000000000000..ce0e0542251ee --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -0,0 +1,399 @@ +--- +content_type: concept +title: アプリケーションの自己観察とデバッグ +--- + + + +アプリケーションが稼働すると、必然的にその問題をデバッグする必要が出てきます。 +先に、`kubectl get pods`を使って、Podの簡単なステータス情報を取得する方法を説明しました。 +しかし、アプリケーションに関するより多くの情報を取得する方法がいくつかあります。 + + + +## `kubectl describe pod`を使ってpodの詳細を取得 + +この例では、先ほどの例と同様に、Deploymentを使用して2つのpodを作成します。 + +{{< codenew file="application/nginx-with-request.yaml" >}} + +以下のコマンドを実行して、Deploymentを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml +``` + +```none +deployment.apps/nginx-deployment created +``` + +以下のコマンドでPodの状態を確認します: + +```shell +kubectl get pods +``` + +```none +NAME READY STATUS RESTARTS AGE +nginx-deployment-1006230814-6winp 1/1 Running 0 11s +nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s +``` + +`kubectl describe pod`を使うと、これらのPodについてより多くの情報を得ることができます。 +例えば: + +```shell +kubectl describe pod nginx-deployment-1006230814-6winp +``` + +```none +Name: nginx-deployment-1006230814-6winp +Namespace: default +Node: kubernetes-node-wul5/10.240.0.9 +Start Time: Thu, 24 Mar 2016 01:39:49 +0000 +Labels: app=nginx,pod-template-hash=1006230814 +Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1956810328","uid":"14e607e7-8ba1-11e7-b5cb-fa16" ... +Status: Running +IP: 10.244.0.6 +Controllers: ReplicaSet/nginx-deployment-1006230814 +Containers: + nginx: + Container ID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149 + Image: nginx + Image ID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707 + Port: 80/TCP + QoS Tier: + cpu: Guaranteed + memory: Guaranteed + Limits: + cpu: 500m + memory: 128Mi + Requests: + memory: 128Mi + cpu: 500m + State: Running + Started: Thu, 24 Mar 2016 01:39:51 +0000 + Ready: True + Restart Count: 0 + Environment: + Mounts: + /var/run/secrets/kubernetes.io/serviceaccount from default-token-5kdvl (ro) +Conditions: + Type Status + Initialized True + Ready True + PodScheduled True +Volumes: + default-token-4bcbi: + Type: Secret (a volume populated by a Secret) + SecretName: default-token-4bcbi + Optional: false +QoS Class: Guaranteed +Node-Selectors: +Tolerations: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 54s 54s 1 {default-scheduler } Normal Scheduled Successfully assigned nginx-deployment-1006230814-6winp to kubernetes-node-wul5 + 54s 54s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulling pulling image "nginx" + 53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulled Successfully pulled image "nginx" + 53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Created Created container with docker id 90315cc9f513 + 53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Started Started container with docker id 90315cc9f513 +``` + +ここでは、コンテナ(複数可)とPodに関する構成情報(ラベル、リソース要件など)や、コンテナ(複数可)とPodに関するステータス情報(状態、準備状況、再起動回数、イベントなど)を確認できます。 + +コンテナの状態は、Waiting(待機中)、Running(実行中)、Terminated(終了)のいずれかです。状態に応じて、追加の情報が提供されます。ここでは、Running状態のコンテナについて、コンテナがいつ開始されたかが表示されています。 + +Readyは、コンテナが最後のReadiness Probeに合格したかどうかを示す。(この場合、コンテナにはReadiness Probeが設定されていません。Readiness Probeが設定されていない場合、コンテナは準備が完了した状態であるとみなされます)。 + +Restart Countは、コンテナが何回再起動されたかを示します。この情報は、再起動ポリシーが「always」に設定されているコンテナのクラッシュループを検出するのに役立ちます。 + +現在、Podに関連する条件は、二値のReady条件のみです。これは、Podがリクエストに対応可能であり、マッチングするすべてのサービスのロードバランシングプールに追加されるべきであることを示します。 + +最後に、Podに関連する最近のイベントのログが表示されます。このシステムでは、複数の同一イベントを圧縮して、最初に見られた時刻と最後に見られた時刻、そして見られた回数を示します。"From"はイベントを記録しているコンポーネントを示し、"SubobjectPath"はどのオブジェクト(例: Pod内のコンテナ)が参照されているかを示し、"Reason"と "Message"は何が起こったかを示しています。 + +## 例: Pending Podsのデバッグ + +イベントを使って検出できる一般的なシナリオは、どのノードにも収まらないPodを作成した場合です。例えば、Podがどのノードでも空いている以上のリソースを要求したり、どのノードにもマッチしないラベルセレクターを指定したりする場合です。例えば、各(仮想)マシンが1つのCPUを持つ4ノードのクラスター上で、(2つではなく)5つのレプリカを持ち、500ではなく600ミリコアを要求する前のDeploymentを作成したとします。この場合、Podの1つがスケジュールできなくなります。(なお、各ノードではfluentdやskydnsなどのクラスターアドオンPodが動作しているため、もし1000ミリコアを要求した場合、どのPodもスケジュールできなくなります) + +```shell +kubectl get pods +``` + +```none +NAME READY STATUS RESTARTS AGE +nginx-deployment-1006230814-6winp 1/1 Running 0 7m +nginx-deployment-1006230814-fmgu3 1/1 Running 0 7m +nginx-deployment-1370807587-6ekbw 1/1 Running 0 1m +nginx-deployment-1370807587-fg172 0/1 Pending 0 1m +nginx-deployment-1370807587-fz9sd 0/1 Pending 0 1m +``` + +nginx-deployment-1370807587-fz9sdのPodが実行されていない理由を調べるには、保留中のPodに対して`kubectl describe pod`を使用し、そのイベントを見てみましょう + +```shell +kubectl describe pod nginx-deployment-1370807587-fz9sd +``` + +```none + Name: nginx-deployment-1370807587-fz9sd + Namespace: default + Node: / + Labels: app=nginx,pod-template-hash=1370807587 + Status: Pending + IP: + Controllers: ReplicaSet/nginx-deployment-1370807587 + Containers: + nginx: + Image: nginx + Port: 80/TCP + QoS Tier: + memory: Guaranteed + cpu: Guaranteed + Limits: + cpu: 1 + memory: 128Mi + Requests: + cpu: 1 + memory: 128Mi + Environment Variables: + Volumes: + default-token-4bcbi: + Type: Secret (a volume populated by a Secret) + SecretName: default-token-4bcbi + Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 48s 7 {default-scheduler } Warning FailedScheduling pod (nginx-deployment-1370807587-fz9sd) failed to fit in any node + fit failure on node (kubernetes-node-6ta5): Node didn't have enough resource: CPU, requested: 1000, used: 1420, capacity: 2000 + fit failure on node (kubernetes-node-wul5): Node didn't have enough resource: CPU, requested: 1000, used: 1100, capacity: 2000 +``` + +ここでは、理由 `FailedScheduling` (およびその他の理由)でPodのスケジュールに失敗したという、スケジューラーによって生成されたイベントを見ることができます。このメッセージは、どのノードでもPodに十分なリソースがなかったことを示しています。 + +この状況を修正するには、`kubectl scale`を使用して、4つ以下のレプリカを指定するようにDeploymentを更新します。(あるいは、1つのPodを保留にしたままにしておいても害はありません。) + +`kubectl describe pod`の最後に出てきたようなイベントは、etcdに永続化され、クラスターで何が起こっているかについての高レベルの情報を提供します。 + +すべてのイベントをリストアップするには、次のようにします: + + +```shell +kubectl get events +``` + +しかし、イベントは名前空間に所属することを忘れてはいけません。つまり、名前空間で管理されているオブジェクトのイベントに興味がある場合(例: 名前空間 `my-namespace`のPods で何が起こったか)、コマンドに名前空間を明示的に指定する必要があります。 + +```shell +kubectl get events --namespace=my-namespace +``` + +すべての名前空間からのイベントを見るには、`--all-namespaces` 引数を使用できます。 + +`kubectl describe pod`に加えて、(`kubectl get pod` で提供される以上の)Podに関する追加情報を得るためのもう一つの方法は、`-o yaml`出力形式フラグを `kubectl get pod`に渡すことです。これにより、`kubectl describe pod`よりもさらに多くの情報、つまりシステムが持っているPodに関するすべての情報をYAML形式で得ることができます。ここでは、アノテーション(Kubernetesのシステムコンポーネントが内部的に使用している、ラベル制限のないキーバリューのメタデータ)、再起動ポリシー、ポート、ボリュームなどが表示されます。 + +```shell +kubectl get pod nginx-deployment-1006230814-6winp -o yaml +``` + +```yaml +apiVersion: v1 +kind: Pod +metadata: + annotations: + kubernetes.io/created-by: | + {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1006230814","uid":"4c84c175-f161-11e5-9a78-42010af00005","apiVersion":"extensions","resourceVersion":"133434"}} + creationTimestamp: 2016-03-24T01:39:50Z + generateName: nginx-deployment-1006230814- + labels: + app: nginx + pod-template-hash: "1006230814" + name: nginx-deployment-1006230814-6winp + namespace: default + resourceVersion: "133447" + uid: 4c879808-f161-11e5-9a78-42010af00005 +spec: + containers: + - image: nginx + imagePullPolicy: Always + name: nginx + ports: + - containerPort: 80 + protocol: TCP + resources: + limits: + cpu: 500m + memory: 128Mi + requests: + cpu: 500m + memory: 128Mi + terminationMessagePath: /dev/termination-log + volumeMounts: + - mountPath: /var/run/secrets/kubernetes.io/serviceaccount + name: default-token-4bcbi + readOnly: true + dnsPolicy: ClusterFirst + nodeName: kubernetes-node-wul5 + restartPolicy: Always + securityContext: {} + serviceAccount: default + serviceAccountName: default + terminationGracePeriodSeconds: 30 + volumes: + - name: default-token-4bcbi + secret: + secretName: default-token-4bcbi +status: + conditions: + - lastProbeTime: null + lastTransitionTime: 2016-03-24T01:39:51Z + status: "True" + type: Ready + containerStatuses: + - containerID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149 + image: nginx + imageID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707 + lastState: {} + name: nginx + ready: true + restartCount: 0 + state: + running: + startedAt: 2016-03-24T01:39:51Z + hostIP: 10.240.0.9 + phase: Running + podIP: 10.244.0.6 + startTime: 2016-03-24T01:39:49Z +``` + +## 例: ダウン/到達不可能なノードのデバッグ + +例えば、ノード上で動作しているPodのおかしな挙動に気付いたり、Podがノード上でスケジュールされない原因を探ったりと、デバッグ時にノードのステータスを見ることが有用な場合があります。Podと同様に、`kubectl describe node`や`kubectl get node -o yaml`を使ってノードの詳細情報を取得することができます。例えば、ノードがダウンした場合(ネットワークから切断された、またはkubeletが死んで再起動しないなど)に表示される内容は以下の通りです。ノードがNotReadyであることを示すイベントに注目してください。また、Podが実行されなくなっていることにも注目してください(NotReady状態が5分続くと、Podは退避されます)。 + +```shell +kubectl get nodes +``` + +```none +NAME STATUS ROLES AGE VERSION +kubernetes-node-861h NotReady 1h v1.13.0 +kubernetes-node-bols Ready 1h v1.13.0 +kubernetes-node-st6x Ready 1h v1.13.0 +kubernetes-node-unaj Ready 1h v1.13.0 +``` + +```shell +kubectl describe node kubernetes-node-861h +``` + +```none +Name: kubernetes-node-861h +Role +Labels: kubernetes.io/arch=amd64 + kubernetes.io/os=linux + kubernetes.io/hostname=kubernetes-node-861h +Annotations: node.alpha.kubernetes.io/ttl=0 + volumes.kubernetes.io/controller-managed-attach-detach=true +Taints: +CreationTimestamp: Mon, 04 Sep 2017 17:13:23 +0800 +Phase: +Conditions: + Type Status LastHeartbeatTime LastTransitionTime Reason Message + ---- ------ ----------------- ------------------ ------ ------- + OutOfDisk Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + MemoryPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + DiskPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + Ready Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. +Addresses: 10.240.115.55,104.197.0.26 +Capacity: + cpu: 2 + hugePages: 0 + memory: 4046788Ki + pods: 110 +Allocatable: + cpu: 1500m + hugePages: 0 + memory: 1479263Ki + pods: 110 +System Info: + Machine ID: 8e025a21a4254e11b028584d9d8b12c4 + System UUID: 349075D1-D169-4F25-9F2A-E886850C47E3 + Boot ID: 5cd18b37-c5bd-4658-94e0-e436d3f110e0 + Kernel Version: 4.4.0-31-generic + OS Image: Debian GNU/Linux 8 (jessie) + Operating System: linux + Architecture: amd64 + Container Runtime Version: docker://1.12.5 + Kubelet Version: v1.6.9+a3d1dfa6f4335 + Kube-Proxy Version: v1.6.9+a3d1dfa6f4335 +ExternalID: 15233045891481496305 +Non-terminated Pods: (9 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- +...... +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 900m (60%) 2200m (146%) 1009286400 (66%) 5681286400 (375%) +Events: +``` + +```shell +kubectl get node kubernetes-node-861h -o yaml +``` + +```yaml +apiVersion: v1 +kind: Node +metadata: + creationTimestamp: 2015-07-10T21:32:29Z + labels: + kubernetes.io/hostname: kubernetes-node-861h + name: kubernetes-node-861h + resourceVersion: "757" + uid: 2a69374e-274b-11e5-a234-42010af0d969 +spec: + externalID: "15233045891481496305" + podCIDR: 10.244.0.0/24 + providerID: gce://striped-torus-760/us-central1-b/kubernetes-node-861h +status: + addresses: + - address: 10.240.115.55 + type: InternalIP + - address: 104.197.0.26 + type: ExternalIP + capacity: + cpu: "1" + memory: 3800808Ki + pods: "100" + conditions: + - lastHeartbeatTime: 2015-07-10T21:34:32Z + lastTransitionTime: 2015-07-10T21:35:15Z + reason: Kubelet stopped posting node status. + status: Unknown + type: Ready + nodeInfo: + bootID: 4e316776-b40d-4f78-a4ea-ab0d73390897 + containerRuntimeVersion: docker://Unknown + kernelVersion: 3.16.0-0.bpo.4-amd64 + kubeProxyVersion: v0.21.1-185-gffc5a86098dc01 + kubeletVersion: v0.21.1-185-gffc5a86098dc01 + machineID: "" + osImage: Debian GNU/Linux 7 (wheezy) + systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E +``` + + + +## {{% heading "whatsnext" %}} + +以下のような追加のデバッグツールについて学びます: + +* [Logging](/docs/concepts/cluster-administration/logging/) +* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) +* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/) +* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/) +* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) +* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/) From 720d92a34fb3a564ff6f10a602dce883530c7044 Mon Sep 17 00:00:00 2001 From: Wang Date: Sun, 30 Jan 2022 22:52:23 +0900 Subject: [PATCH 160/167] [ja] Translate tasks/debug-application-cluster/resource-usage-monitoring into Japanese (#31054) * done * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update resource-usage-monitoring.md * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md Co-authored-by: nasa9084 Co-authored-by: nasa9084 --- .../resource-usage-monitoring.md | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md diff --git a/content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md new file mode 100644 index 0000000000000..68c0841038b73 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -0,0 +1,41 @@ +--- +content_type: concept +title: リソース監視のためのツール +--- + + + +アプリケーションを拡張し、信頼性の高いサービスを提供するために、デプロイ時にアプリケーションがどのように動作するかを理解する必要があります。 +コンテナ、[Pod](/docs/concepts/workloads/pods/)、[Service](/docs/concepts/services-networking/service/)、クラスター全体の特性を調べることにより、Kubernetesクラスターのアプリケーションパフォーマンスを調査することができます。 +Kubernetesは、これらの各レベルでアプリケーションのリソース使用に関する詳細な情報を提供します。 +この情報により、アプリケーションのパフォーマンスを評価し、ボトルネックを取り除くことで全体のパフォーマンスを向上させることができます。 + + + +Kubernetesでは、アプリケーションの監視は1つの監視ソリューションに依存することはありません。 +新しいクラスターでは、[リソースメトリクス](#resource-metrics-pipeline)または[フルメトリクス](#full-metrics-pipeline)パイプラインを使用してモニタリング統計を収集することができます。 + +## リソースメトリクスパイプライン + +リソースメトリックパイプラインは、[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)コントローラーなどのクラスターコンポーネントや、`kubectl top`ユーティリティに関連する限定的なメトリックセットを提供します。 + +これらのメトリクスは軽量、短期、インメモリーの[metrics-server](https://github.com/kubernetes-sigs/metrics-server)によって収集され、`metrics.k8s.io` APIを通じて公開されます。 + +metrics-serverはクラスター上のすべてのノードを検出し +各ノードの[kubelet](/docs/reference/command-line-tools-reference/kubelet/)にCPUとメモリーの使用量を問い合わせます。 + +kubeletはKubernetesマスターとノードの橋渡し役として、マシン上で動作するPodやコンテナを管理する。 +kubeletは各Podを構成するコンテナに変換し、コンテナランタイムインターフェースを介してコンテナランタイムから個々のコンテナ使用統計情報を取得します。この情報は、レガシーDocker統合のための統合cAdvisorから取得されます。 + +そして、集約されたPodリソース使用統計情報を、metrics-server Resource Metrics APIを通じて公開します。 +このAPIは、kubeletの認証済みおよび読み取り専用ポート上の `/metrics/resource/v1beta1` で提供されます。 + +## フルメトリクスパイプライン + +フルメトリクスパイプラインは、より豊富なメトリクスにアクセスすることができます。 +Kubernetesは、Horizontal Pod Autoscalerなどのメカニズムを使用して、現在の状態に基づいてクラスターを自動的にスケールまたは適応させることによって、これらのメトリクスに対応することができます。 +モニタリングパイプラインは、kubeletからメトリクスを取得し、`custom.metrics.k8s.io` または `external.metrics.k8s.io` APIを実装してアダプタ経由でKubernetesにそれらを公開します。 +CNCFプロジェクトの[Prometheus](https://prometheus.io)は、Kubernetes、ノード、Prometheus自身をネイティブに監視することができます。 +CNCFに属さない完全なメトリクスパイプラインのプロジェクトは、Kubernetesのドキュメントの範囲外です。 + + From ce1e6211d002904329add21ecc2f3405346d90f3 Mon Sep 17 00:00:00 2001 From: Wang Date: Sun, 30 Jan 2022 22:54:23 +0900 Subject: [PATCH 161/167] [ja] Translate tasks/debug-application-cluster/resource-metrics-pipeline into Japanese (#31093) * done * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update resource-metrics-pipeline.md * Update resource-metrics-pipeline.md * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: atoato88 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: nasa9084 * Update resource-metrics-pipeline.md * Update content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md Co-authored-by: inductor(Kohei) * fix * fix link Co-authored-by: nasa9084 Co-authored-by: atoato88 Co-authored-by: inductor(Kohei) --- .../resource-metrics-pipeline.md | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md diff --git a/content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md new file mode 100644 index 0000000000000..006dfcd1d850a --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -0,0 +1,62 @@ +--- +title: リソースメトリクスパイプライン +content_type: concept +--- + + + +Kubernetesでは、コンテナのCPU使用率やメモリ使用率といったリソース使用量のメトリクスが、メトリクスAPIを通じて提供されています。これらのメトリクスは、ユーザーが`kubectl top`コマンドで直接アクセスするか、クラスター内のコントローラー(例えばHorizontal Pod Autoscaler)が判断するためにアクセスすることができます。 + + + +## メトリクスAPI + +メトリクスAPIを使用すると、指定したノードやPodが現在使用しているリソース量を取得することができます。 +このAPIはメトリックの値を保存しないので、例えば10分前に指定されたノードが使用したリソース量を取得することはできません。 + +メトリクスAPIは他のAPIと何ら変わりはありません。 + +- 他のKubernetes APIと同じエンドポイントを経由して、`/apis/metrics.k8s.io/`パスの下で発見できます。 +- 同じセキュリティ、スケーラビリティ、信頼性の保証を提供します。 + +メトリクスAPIは[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)リポジトリで定義されています。 +メトリクスAPIについての詳しい情報はそちらをご覧ください。 + +{{< note >}} +メトリクスAPIを使用するには、クラスター内にメトリクスサーバーが配置されている必要があります。そうでない場合は利用できません。 +{{< /note >}} + +## リソース使用量の測定 + +### CPU + +CPUは、一定期間の平均使用量を[CPU cores](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)という単位で報告されます。 +この値は、カーネルが提供する累積CPUカウンターの比率を取得することで得られます(LinuxとWindowsの両カーネルで)。 +kubeletは、比率計算のためのウィンドウを選択します。 + +### メモリ + +メモリは、測定値が収集された時点のワーキングセットとして、バイト単位で報告されます。 +理想的な世界では、「ワーキングセット」は、メモリ不足で解放できない使用中のメモリ量です。 +しかし、ワーキングセットの計算はホストOSによって異なり、一般に推定値を生成するために経験則を多用しています。 +Kubernetesはスワップをサポートしていないため、すべての匿名(非ファイルバックアップ)メモリが含まれます。 +ホストOSは常にそのようなページを再請求することができないため、メトリックには通常、一部のキャッシュされた(ファイルバックされた)メモリも含まれます。 + +## メトリクスサーバー + +[メトリクスサーバー](https://github.com/kubernetes-sigs/metrics-server)は、クラスター全体のリソース使用量データのアグリゲーターです。 +デフォルトでは、`kube-up.sh`スクリプトで作成されたクラスターにDeploymentオブジェクトとしてデプロイされます。 +別のKubernetesセットアップ機構を使用する場合は、提供される[deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases)ファイルを使用してデプロイすることができます。 +メトリクスサーバーは、Summary APIからメトリクスを収集します。 +各ノードの[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)から[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)経由でメインAPIサーバーに登録されるようになっています。 + +メトリクスサーバーについては、[Design proposals](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/metrics-server.md)で詳しく解説しています。 + + +### Summary APIソース + +[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)は、ノード、ボリューム、Pod、コンテナレベルの統計情報を収集し、[Summary 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`フィーチャーゲートの導入により、コンテナとPodレベルの統計情報をCRI実装で収集することができます。 + +注意: これはCRI実装によるサポートも必要です(containerd >= 1.6.0, CRI-O >= 1.23.0)。 From b19b9da1b6507ddedce86248be0bc476c5a83727 Mon Sep 17 00:00:00 2001 From: Ameya Sathe Date: Sun, 30 Jan 2022 22:14:41 +0530 Subject: [PATCH 162/167] Replaces with relative uri Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> --- content/en/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 8dd8cc4e98978..4aa1ba8d7ae1c 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -422,7 +422,7 @@ Helper programs relating to the volume type may be required for consumption of a ### Capacity -Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. Read the glossary term [Quantity](https://kubernetes.io/docs/reference/glossary/?all=true#term-quantity) to understand the units expected by `capacity`. +Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. Read the glossary term [Quantity](/docs/reference/glossary/?all=true#term-quantity) to understand the units expected by `capacity`. Currently, storage size is the only resource that can be set or requested. Future attributes may include IOPS, throughput, etc. From 3bdfba74ed21be6952ffbbe54a409e5a8d4aa3e4 Mon Sep 17 00:00:00 2001 From: Augustas Date: Sun, 30 Jan 2022 21:37:06 +0100 Subject: [PATCH 163/167] Apply suggestions from code review Thank you sftim for recommended changes. Co-authored-by: Tim Bannister --- ...migrating-telemetry-and-security-agents.md | 33 ++++++++++++------- 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index 7720a502672b3..91ce496c6eff5 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -12,19 +12,28 @@ Docker is being deprecated. You can find a deprecation FAQ at [Don't Panic: Kube ## Telemetry and security agents -There are a few ways agents may be run on kubernetes cluster. Agents have a direct -dependency on Docker when they run on nodes or as daemonsets. Some telemetry and -security agents may rely on certain logs or metrics specific for Docker that would not -be available any longer. This document does not cover these cases. - -### Why do telemetry agents talk to Docker? - -Historically, Kubernetes was built on top of Docker. Kubernetes is managing networking and scheduling, Docker was placing and operating containers on a node. So you can get scheduling-related metadata like a pod name from Kubernetes and containers state information from Docker. Over time more runtimes were created to manage containers. Also there are projects and kubernetes features that generalize container status information extraction across many runtimes. - -But some agents are still Docker-dependent. They may run commands like [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) +Within a Kubernetes cluster there are a few different ways to run telemetry or security agents. +Some agents have a direct dependency on Docker Engine when they as DaemonSets or +directly on nodes. + +### Why do some telemetry agents communicate with Docker Engine? + +Historically, Kubernetes was written to work specifically with Docker Engine. +Kubernetes took care of networking and scheduling, relying on Docker Engine for launching +and running containers (within Pods) on a node. Some information that is relevant to telemetry, +such as a pod name, is only available from Kubernetes components. Other data, such as container +metrics, is not the responsibility of the container runtime. Early yelemetry agents needed to query the +container runtime **and** Kubernetes to report an accurate picture. Over time, Kubernetes gained +the ability to support multiple runtimes, and now supports any runtime that is compatible with +the container runtime interface. + +Some telemetry agents rely specifically on Docker Engine tooling. For example, an agent +might run a command such as +[`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) or [`docker top`](https://docs.docker.com/engine/reference/commandline/top/) to list -containers and processes or [docker logs](https://docs.docker.com/engine/reference/commandline/logs/) -to subscribe on docker logs. With the deprecating of Docker as a container runtime, +containers and processes or [`docker logs`](https://docs.docker.com/engine/reference/commandline/logs/) +to receive streamed logs. If nodes in your existing cluster use +Docker Engine, and you switch to a different container runtime, these commands will not work any longer. ### Identify DaemonSets that depend on Docker {#identify-docker-dependency} From 80f4c27c669bf690dd0aec171a12f4deddb3608b Mon Sep 17 00:00:00 2001 From: AugustasV Date: Sun, 30 Jan 2022 21:49:09 +0100 Subject: [PATCH 164/167] correction Signed-off-by: AugustasV --- .../migrating-telemetry-and-security-agents.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index 91ce496c6eff5..87ab93b1fce82 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -8,7 +8,7 @@ weight: 70 -Docker is being deprecated. You can find a deprecation FAQ at [Don't Panic: Kubernetes and Docker](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Most apps do not have a direct dependency on runtime hosting containers. However, there are still a lot of telemetry and monitoring agents that has a dependency on docker to collect containers metadata, logs and metrics. This document aggregates information on how to detect these dependencies and links on how to migrate these agents to use generic tools or alternative runtimes. +Kubernetes' support for direct integration with Docker Engine is deprecated, and will be removed. Most apps do not have a direct dependency on runtime hosting containers. However, there are still a lot of telemetry and monitoring agents that has a dependency on docker to collect containers metadata, logs and metrics. This document aggregates information on how to detect these dependencies and links on how to migrate these agents to use generic tools or alternative runtimes. ## Telemetry and security agents @@ -36,7 +36,7 @@ to receive streamed logs. If nodes in your existing cluster use Docker Engine, and you switch to a different container runtime, these commands will not work any longer. -### Identify DaemonSets that depend on Docker {#identify-docker-dependency} +### Identify DaemonSets that depend on Docker Engine {#identify-docker-dependency} If a pod wants to make calls to the `dockerd` running on the node, the pod must either: From 859c15563992151abee2d7e30d22894e2a1b240f Mon Sep 17 00:00:00 2001 From: Arhell Date: Mon, 31 Jan 2022 11:07:37 +0200 Subject: [PATCH 165/167] [fr] fixed the list container images by pod section --- .../list-all-running-container-images.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md index 114bcc784b7eb..1c90abcc91bbe 100644 --- a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -59,7 +59,7 @@ Lors de la récupération d'un seul pod par son nom, par exemple `kubectl get po Le formatage peut être contrôlé davantage en utilisant l'opération `range` pour parcourir les éléments individuellement. ```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 ``` @@ -69,7 +69,7 @@ Pour cibler uniquement les pods correspondant à un label spécifique, utilisez Les éléments suivants correspondent uniquement aux pods avec les labels `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 ``` ## Filtrage des images de conteneur de liste par namespace de pod From f7b0122955d7a1237145a6fded230dbe5903fee1 Mon Sep 17 00:00:00 2001 From: fabriziopandini Date: Mon, 31 Jan 2022 11:58:23 +0100 Subject: [PATCH 166/167] Fix broken link in the ClusterClass blog --- .../_posts/2021-10-08-clusterclass-and-managed-topologies.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md index cd65d69f8b35f..8b470f1dcf3b6 100644 --- a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md +++ b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md @@ -138,4 +138,5 @@ Stay tuned for what comes next, and if you have any questions, comments or sugge * Chat with us on the Kubernetes [Slack](http://slack.k8s.io/):[#cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) * Join the SIG Cluster Lifecycle [Google Group](https://groups.google.com/g/kubernetes-sig-cluster-lifecycle) to receive calendar invites and gain access to documents * Join our [Zoom meeting](https://zoom.us/j/861487554), every Wednesday at 10:00 Pacific Time -* Check out the [ClusterClass tutorial](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-classes.html) in the Cluster API book. \ No newline at end of file +* Check out the [ClusterClass quick-start](https://cluster-api.sigs.k8s.io/user/quick-start.html) for the Docker provider (CAPD) in the Cluster API book. + From f0b7f2beceacad8158f3176f0585454b91097b40 Mon Sep 17 00:00:00 2001 From: fabriziopandini Date: Mon, 31 Jan 2022 11:59:08 +0100 Subject: [PATCH 167/167] Add link to newly available documentation for the ClusterClass blog --- .../_posts/2021-10-08-clusterclass-and-managed-topologies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md index 8b470f1dcf3b6..624075fb4ec37 100644 --- a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md +++ b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md @@ -139,4 +139,4 @@ Stay tuned for what comes next, and if you have any questions, comments or sugge * Join the SIG Cluster Lifecycle [Google Group](https://groups.google.com/g/kubernetes-sig-cluster-lifecycle) to receive calendar invites and gain access to documents * Join our [Zoom meeting](https://zoom.us/j/861487554), every Wednesday at 10:00 Pacific Time * Check out the [ClusterClass quick-start](https://cluster-api.sigs.k8s.io/user/quick-start.html) for the Docker provider (CAPD) in the Cluster API book. - +* _UPDATE_: Check out the [ClusterClass experimental feature](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/index.html) documentation in the Cluster API book.