From 020daedd05d14c66b7b6cf3aed8f41a88b1b9eb7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Sun, 14 Jun 2020 14:11:38 -0300 Subject: [PATCH 001/119] Fix wrong translations in Spanish language Some words in spanish weren't translated correctly. --- content/es/docs/concepts/architecture/cloud-controller.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/es/docs/concepts/architecture/cloud-controller.md b/content/es/docs/concepts/architecture/cloud-controller.md index 4de5b4418a..744a3ee046 100644 --- a/content/es/docs/concepts/architecture/cloud-controller.md +++ b/content/es/docs/concepts/architecture/cloud-controller.md @@ -6,13 +6,13 @@ weight: 30 -El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionasen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes. +El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes. -El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en incorporar nuevos proveedores de servicios y para migrar los existentes del viejo modelo al nuevo CCM. +El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en implementar nuevos proveedores de servicios y para migrar los existentes del antiguo modelo al nuevo CCM. -Este documento describe los conceptos tras el Cloud Controller Manager y da detalles sobre sus funciones asociadas. +Este documento describe los conceptos tras el Cloud Controller Manager e informar detalles sobre sus funciones asociadas. -En la siguiente imagen, se puede ver la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: +En la siguiente imagen, se puede visualizar la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: ![Arquitectura previa a CCM](/images/docs/pre-ccm-arch.png) From 24ff96eb8f0154f303e6a5ee3d9e1aab99a5bf91 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Sun, 14 Jun 2020 14:35:12 -0300 Subject: [PATCH 002/119] Fix Spanish typos --- content/es/docs/concepts/architecture/nodes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/es/docs/concepts/architecture/nodes.md b/content/es/docs/concepts/architecture/nodes.md index 34b0303082..d2313849ef 100644 --- a/content/es/docs/concepts/architecture/nodes.md +++ b/content/es/docs/concepts/architecture/nodes.md @@ -111,7 +111,7 @@ El controlador juega múltiples papeles en la vida de un nodo. El primero es asi El segundo es mantener actualizada la lista interna del controlador con la lista de máquinas disponibles a través del proveedor de servicios en la nube. Cuando Kubernetes se ejecuta en la nube, si un nodo deja de responder, el controlador del nodo preguntará al proveedor si la máquina virtual de dicho nodo continúa estando disponible. Si no lo está, el controlador borrará dicho nodo de su lista interna. -El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue re-intentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. +El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue reintentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. En versiones de Kubernetes previas a 1.13, `NodeStatus` es el `heartbeat` del nodo. Empezando con 1.13 la funcionalidad de `node lease` se introduce como alfa (`NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento. @@ -123,7 +123,7 @@ En la mayoría de los casos, el controlador de nodos limita el ritmo de desalojo El comportamiento de desalojo de nodos cambia cuando un nodo en una zona de disponibilidad tiene problemas. El controlador de nodos comprobará qué porcentaje de nodos en la zona no se encuentran en buen estado (es decir, que su condición `NodeReady` tiene un valor `ConditionUnknown` o `ConditionFalse`) al mismo tiempo. Si la fracción de nodos con problemas es de al menos `--unhealthy-zone-threshold` (0.55 por defecto) entonces se reduce el ratio de desalojos: si el clúster es pequeño (por ejemplo, tiene menos o los mismos nodos que `--large-cluster-size-threshold` - 50 por defecto) entonces los desalojos se paran. Sino, el ratio se reduce a `--secondary-node-eviction-rate` (0.01 por defecto) por segundo. La razón por la que estas políticas se implementan por zonas de disponibilidad es debido a que una zona puede quedarse aislada del nodo máster mientras que las demás continúan conectadas. Si un clúster no comprende más de una zona, todo el clúster se considera una única zona. La razón principal por la que se distribuyen nodos entre varias zonas de disponibilidad es para que el volumen de trabajo se transfiera a aquellas zonas que se encuentren en buen estado cuando una de las zonas se caiga. -Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se re-establece la conectividad. +Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se restablezca la conectividad. Desde la versión 1.6 de Kubernetes el controlador de nodos también es el responsable de desalojar pods que están ejecutándose en nodos con `NoExecute` taints, cuando los pods no permiten dichos taints. De forma adicional, como una funcionalidad alfa que permanece deshabilitada por defecto, el `NodeController` es responsable de añadir taints que se corresponden con problemas en los nodos del tipo nodo inalcanzable o nodo no preparado. En [esta sección de la documentación](/docs/concepts/configuration/taint-and-toleration/) hay más detalles acerca de los taints `NoExecute` y de la funcionalidad alfa. From bdc173ce13ed9572b82325af6548cc959f9d566a Mon Sep 17 00:00:00 2001 From: Roy Lenferink Date: Mon, 15 Jun 2020 12:28:23 +0200 Subject: [PATCH 003/119] Update docs for new container- Makefile targets --- .../docs/contribute/new-content/open-a-pr.md | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 05a576a74b..5b2642dd39 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -217,21 +217,37 @@ When you are ready to submit a pull request, commit your changes. It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems. -You can either build the website's docker image or run Hugo locally. Building the docker image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. +You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo in a container" %}} +{{< note >}} +The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour. +{{< /note >}} + 1. Build the image locally: ```bash - make docker-image + # Use docker (default) + make container-image + + ### OR ### + + # Use podman + CONTAINER_ENGINE=podman make container-image ``` 2. After building the `kubernetes-hugo` image locally, build and serve the site: ```bash - make docker-serve + # Use docker (default) + make container-serve + + ### OR ### + + # Use podman + CONTAINER_ENGINE=podman make container-serve ``` 3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the From 646c50ea8d7d4abd3dcc19c8dcd19f200e7f3b37 Mon Sep 17 00:00:00 2001 From: ZhiFeng1993 Date: Mon, 15 Jun 2020 17:16:34 -0700 Subject: [PATCH 004/119] Fix typo in the images.md page --- content/en/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index 47f395841a..b271c36d02 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -63,7 +63,7 @@ you can do one of the following: ## Multi-architecture Images with Manifests -As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecturew-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using. +As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using. Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes. From 80a8d9f134b426d47d54b4591b70f1e68087d143 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Tue, 16 Jun 2020 22:52:42 +0900 Subject: [PATCH 005/119] Add git submodule update for running hugo locally --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index d3ee35693b..8c0de5b813 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,7 @@ To run the website locally when you have Hugo installed: ```bash git clone https://github.com/kubernetes/website.git cd website +git submodule update --init --recursive hugo server --buildFuture ``` @@ -62,4 +63,4 @@ Participation in the Kubernetes community is governed by the [CNCF Code of Condu ## Thank you! -Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation! \ No newline at end of file +Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation! From 774b756433318bbcb13a91a59c4a56ba965bdfe7 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Tue, 16 Jun 2020 22:59:17 +0900 Subject: [PATCH 006/119] remove newline at eof --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 8c0de5b813..7ef8f8d2dd 100644 --- a/README.md +++ b/README.md @@ -63,4 +63,4 @@ Participation in the Kubernetes community is governed by the [CNCF Code of Condu ## Thank you! -Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation! +Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation! \ No newline at end of file From ff9b3e10e9baaa9ecb4992a4933ceb8de4a2da13 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Martins?= Date: Tue, 16 Jun 2020 16:16:39 +0200 Subject: [PATCH 007/119] update kubeadm Cilium related docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: André Martins --- .../network-policy-provider/cilium-network-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 95912f4f88..83989b1f58 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -51,7 +51,7 @@ For minikube you can deploy this simple ''all-in-one'' YAML file that includes DaemonSet configurations for Cilium as well as appropriate RBAC settings: ```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml +kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml ``` ``` configmap/cilium-config created From addbb8cec4912d932d670a7fa3e3899f367ded48 Mon Sep 17 00:00:00 2001 From: Yoon Date: Wed, 17 Jun 2020 00:32:07 +0900 Subject: [PATCH 008/119] fix typo: taint-and-toleration.md fix typo: en/docs/concepts/scheduling-eviction/taint-and-toleration.md --- .../docs/concepts/scheduling-eviction/taint-and-toleration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index 89a7eca7b1..97a190a280 100644 --- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -250,7 +250,7 @@ tolerations: Kubernetes automatically adds a toleration for `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` with `tolerationSeconds=300`, -unless you, or a controller, set those tolerations explictly. +unless you, or a controller, set those tolerations explicitly. These automatically-added tolerations mean that Pods remain bound to Nodes for 5 minutes after one of these problems is detected. From cd37817af8774d0f6c435634ade3db188fadea07 Mon Sep 17 00:00:00 2001 From: divya bhushan Date: Tue, 16 Jun 2020 20:27:20 +0200 Subject: [PATCH 009/119] Add Kubernetes download button --- content/en/docs/home/_index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index b4f9a2ee66..8864e4781a 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -59,6 +59,8 @@ cards: - name: release-notes title: Release Notes description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. + button: "Download Kubernetes" + button_path: "/docs/setup/release/notes" - name: about title: About the documentation description: This website contains documentation for the current and previous 4 versions of Kubernetes. From 6f54e80d123f8e2ce72dde7f3a04a1c287ea234a Mon Sep 17 00:00:00 2001 From: Karen Bradshaw Date: Mon, 15 Jun 2020 17:24:20 -0400 Subject: [PATCH 010/119] add redirects for snapshot api refs --- static/_redirects | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/static/_redirects b/static/_redirects index bb2c0aeba1..242518f7ef 100644 --- a/static/_redirects +++ b/static/_redirects @@ -185,6 +185,12 @@ /docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 +/docs/reference/generated/kubernetes-api/v1.14/ https://v1-14.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/ 301 +/docs/reference/generated/kubernetes-api/v1.15/ https://v1-15.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/ 301 +/docs/reference/generated/kubernetes-api/v1.16/ https://v1-16.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/ 301 +/docs/reference/generated/kubernetes-api/v1.17/ https://v1-17.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/ 301 + + /docs/reporting-security-issues/ /security/ 301 /docs/roadmap/ https://github.com/kubernetes/kubernetes/milestones/ 301 From f8c1f91d97ad0907b55ace52db781ad835847036 Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 17 Jun 2020 01:12:13 +0300 Subject: [PATCH 011/119] update to right styling for VolumeSnapshotClass concept --- .../storage/volume-snapshot-classes.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index f50db19520..7f107b2059 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -13,7 +13,7 @@ weight: 30 -This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity +This document describes the concept of VolumeSnapshotClass in Kubernetes. Familiarity with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and [storage classes](/docs/concepts/storage/storage-classes) is suggested. @@ -24,22 +24,22 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and ## Introduction -Just like `StorageClass` provides a way for administrators to describe the "classes" -of storage they offer when provisioning a volume, `VolumeSnapshotClass` provides a +Just like StorageClass provides a way for administrators to describe the "classes" +of storage they offer when provisioning a volume, VolumeSnapshotClass provides a way to describe the "classes" of storage when provisioning a volume snapshot. ## The VolumeSnapshotClass Resource -Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`, -which are used when a `VolumeSnapshot` belonging to the class needs to be +Each VolumeSnapshotClass contains the fields `driver`, `deletionPolicy`, and `parameters`, +which are used when a VolumeSnapshot belonging to the class needs to be dynamically provisioned. -The name of a `VolumeSnapshotClass` object is significant, and is how users can +The name of a VolumeSnapshotClass object is significant, and is how users can request a particular class. Administrators set the name and other parameters -of a class when first creating `VolumeSnapshotClass` objects, and the objects cannot +of a class when first creating VolumeSnapshotClass objects, and the objects cannot be updated once they are created. -Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapshots +Administrators can specify a default VolumeSnapshotClass just for VolumeSnapshots that don't request any particular class to bind to. ```yaml @@ -47,7 +47,7 @@ apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass -driver: hostpath.csi.k8s.io +driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: ``` @@ -59,9 +59,9 @@ used for provisioning VolumeSnapshots. This field must be specified. ### DeletionPolicy -Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a `VolumeSnapshotContent` when the `VolumeSnapshot` object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified. +Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified. -If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the deletionPolicy is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain. +If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain. ## Parameters From 04dca60eb7b063cb0628b3a813fe5ccfe13cb126 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Tue, 16 Jun 2020 21:24:52 -0300 Subject: [PATCH 012/119] Typo Spanish Doc --- content/es/docs/concepts/overview/what-is-kubernetes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/es/docs/concepts/overview/what-is-kubernetes.md b/content/es/docs/concepts/overview/what-is-kubernetes.md index 0c53e120c3..4b2d829b1b 100644 --- a/content/es/docs/concepts/overview/what-is-kubernetes.md +++ b/content/es/docs/concepts/overview/what-is-kubernetes.md @@ -49,7 +49,7 @@ una plataforma: para poder construir un ecosistema de componentes y herramientas más fácil el desplegar, escalar y administrar aplicaciones. Las etiquetas, o [Labels](/es/docs/concepts/overview/working-with-objects/labels/), le -permiten a los usuarios organizar sus recursos como deseen. Las anotaciones , o [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/), les permiten asignar información arbitraria a un recurso para +permiten a los usuarios organizar sus recursos como deseen. Las anotaciones, o [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/), les permiten asignar información arbitraria a un recurso para facilitar sus flujos de trabajo y hacer más fácil a las herramientas administrativas inspeccionar el estado. Además, el [Plano de Control](/docs/concepts/overview/components/) de Kubernetes usa las mismas @@ -127,7 +127,7 @@ En resumen, los beneficios de usar contenedores incluyen: * **Ágil creación y despliegue de aplicaciones**: Mayor facilidad y eficiencia al crear imágenes de contenedor en vez de máquinas virtuales -* **Desarrollo, integración y despliegue continuos**: +* **Desarrollo, integración y despliegue continuo**: Permite que la imagen de contenedor se construya y despliegue de forma frecuente y confiable, facilitando los rollbacks pues la imagen es inmutable * **Separación de tareas entre Dev y Ops**: From 5286dbbce1d8d5c5a4bb814b606b24d78ca52234 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Wed, 17 Jun 2020 09:59:57 +0900 Subject: [PATCH 013/119] follow upstream README --- README-ja.md | 84 ++++++++++++++++++++++++---------------------------- 1 file changed, 38 insertions(+), 46 deletions(-) diff --git a/README-ja.md b/README-ja.md index 2c69491e2f..cc42a471a5 100644 --- a/README-ja.md +++ b/README-ja.md @@ -3,7 +3,31 @@ [![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) -ようこそ！このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ +このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ + +## Hugoを使ってローカル環境でWebサイトを動かす + +Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。 + +Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: + +```bash +git clone https://github.com/kubernetes/website.git +cd website +git submodule update --init --recursive +hugo server --buildFuture +``` + +これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 + +## SIG Docsに参加する + +[コミュニティのページ](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)をご覧になることで、SIG Docs Kubernetesコミュニティとの関わり方を学ぶことができます。 + +本プロジェクトのメンテナーには以下の方法で連絡することができます: + +- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja) +- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) ## ドキュメントに貢献する @@ -12,63 +36,31 @@ GitHubの画面右上にある**Fork**ボタンをクリックすると、お使 Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。 Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。** また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。 -さらに、特定のケースにおいては、レビュー担当者が[Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers)に対してレビューを依頼することもあります。 +さらに、特定のケースにおいては、レビュー担当者がKubernetesの技術的なレビュアーに対してレビューを依頼することもあります。 レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。 Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください: -* [貢献のはじめ方](https://kubernetes.io/docs/contribute/start/) -* [ドキュメントの変更をステージする](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) +* [Kubernetesのドキュメントへの貢献](https://kubernetes.io/docs/contribute/) * [ページテンプレートの使い方](http://kubernetes.io/docs/contribute/style/page-templates/) * [ドキュメントのスタイルガイド](http://kubernetes.io/docs/contribute/style/style-guide/) * [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/) -## Dockerを使ってローカル環境でWebサイトを動かす +## 翻訳された`README.md`一覧 -ローカル環境で本ページを動かすのに推奨される方法は、静的サイトジェネレータの[Hugo](https://gohugo.io)を動かすのに特化した[Docker](https://docker.com)イメージを使うことです。 - -> Windows上で環境を作る場合は[Chocolatey](https://chocolatey.org)を使ってインストール可能な追加のツールが必要になります。 `choco install make` - -> Dockerを使わずに環境を構築したい場合は、[Hugoをローカル環境で動かす](#hugoをローカル環境で動かす)をご覧ください。 - -既に[Dockerが動いている環境](https://www.docker.com/get-started)であれば、以下のコマンドを使って`kubernetes-hugo`イメージをローカルでビルドします: - -```bash -make docker-image -``` - -イメージが作成されたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: - -```bash -make docker-serve -``` - -お使いのブラウザにて http://localhost:1313 にアクセスすることでWebサイトが開きます。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 - -## Hugoをローカル環境で動かす - -Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L9)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。 - -Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: - -```bash -make serve -``` - -これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 - -## コミュニティ内での議論、貢献、サポートなどについて - -[コミュニティのページ](http://kubernetes.io/community/)をご覧になることで、Kubernetesコミュニティとの関わり方を学ぶことができます。 - -本プロジェクトのメンテナーには以下の方法で連絡することができます: - -- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja) -- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +| Language | Language | +|---|---| +|[中国語](README-zh.md)|[韓国語](README-ko.md)| +|[フランス語](README-fr.md)|[ポーランド語](README-pl.md)| +|[ドイツ語](README-de.md)|[ポルトガル語](README-pt.md)| +|[ヒンズー語](README-hi.md)|[ロシア語](README-ru.md)| +|[インドネシア語](README-id.md)|[スペイン語](README-es.md)| +|[イタリア語](README-it.md)|[ウクライナ語](README-uk.md)| +|[日本語](README-ja.md)|[ベトナム語](README-vi.md)| ### 行動規範 -Kubernetesコミュニティへの参加については、[Kubernetesの行動規範](code-of-conduct.md)によって管理されています。 +Kubernetesコミュニティへの参加については、[CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)によって管理されています。 ## ありがとうございます！ From 9a6e4c260db150692e8c5678ff5fb8adca7559bd Mon Sep 17 00:00:00 2001 From: Richard Mokua Date: Wed, 17 Jun 2020 07:45:19 +0200 Subject: [PATCH 014/119] Update configmap.md --- content/en/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index c6dd70ee19..f8e66ac1ed 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -131,7 +131,7 @@ spec: A ConfigMap doesn't differentiate between single line property values and multi-line file-like values. -What matters how Pods and other objects consume those values. +What matters is how Pods and other objects consume those values. For this example, defining a volume and mounting it inside the `demo` container as `/config` creates four files: From 69c280df026e07331a85bcaf0dabbc7404993725 Mon Sep 17 00:00:00 2001 From: Richard Mokua Date: Wed, 17 Jun 2020 07:53:27 +0200 Subject: [PATCH 015/119] Update configmap.md --- content/en/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index c6dd70ee19..324f2c3c43 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -168,7 +168,7 @@ ConfigMaps can hold data that other parts of the system should use for configura To consume a ConfigMap in a volume in a Pod: 1. Create a config map or use an existing one. Multiple Pods can reference the same config map. -1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configmap.localObjectReference` field set to reference your ConfigMap object. +1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configMap.name` field set to reference your ConfigMap object. 1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear. 1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`. From 92e9bf96b526c60757355baa70b39d982db00ef7 Mon Sep 17 00:00:00 2001 From: Timo Reimann Date: Mon, 15 Jun 2020 22:37:08 +0200 Subject: [PATCH 016/119] Document annotation to set default VolumeSnapshotClass --- .../concepts/storage/volume-snapshot-classes.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index 7f107b2059..f3b7025270 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -39,14 +39,27 @@ request a particular class. Administrators set the name and other parameters of a class when first creating VolumeSnapshotClass objects, and the objects cannot be updated once they are created. -Administrators can specify a default VolumeSnapshotClass just for VolumeSnapshots -that don't request any particular class to bind to. +```yaml +apiVersion: snapshot.storage.k8s.io/v1beta1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + +Administrators can specify a default VolumeSnapshotClass for VolumeSnapshots +that don't request any particular class to bind to by adding the +`snapshot.storage.kubernetes.io/is-default-class: "true"` annotation: ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass + annotations: + snapshot.storage.kubernetes.io/is-default-class: "true" driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: From 469df0a4c7bc6198b25cf97c41f6f8ec3158ac06 Mon Sep 17 00:00:00 2001 From: kunzhijia <757246444@qq.com> Date: Wed, 17 Jun 2020 17:22:07 +0800 Subject: [PATCH 017/119] =?UTF-8?q?=E5=BA=95=E9=83=A8=E9=93=BE=E6=8E=A5?= =?UTF-8?q?=E8=B7=B3=E8=BD=AC=E4=BF=AE=E5=A4=8D=EF=BC=8C=E4=BF=AE=E5=A4=8D?= =?UTF-8?q?=E4=B9=8B=E5=89=8D=E8=B7=B3=E8=BD=AC=E5=88=B0=E8=8B=B1=E6=96=87?= =?UTF-8?q?=E6=96=87=E6=A1=A3=EF=BC=8C=E4=BD=93=E9=AA=8C=E4=B8=8D=E6=98=AF?= =?UTF-8?q?=E5=BE=88=E5=A5=BD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/zh/docs/concepts/overview/what-is-kubernetes.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index a4e7f98e4a..d4c9bfc47b 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md @@ -213,6 +213,5 @@ Kubernetes： * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) * Ready to [Get Started](/docs/setup/)? --> -* 查阅 [Kubernetes 组件](/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/docs/setup/)? - +* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) +* 开始 [Kubernetes 入门](/zh/docs/setup/)? \ No newline at end of file From 2dfc94ef251b24ebd80550d52bcb977d6aa83f14 Mon Sep 17 00:00:00 2001 From: popozy <18868108662@163.com> Date: Wed, 17 Jun 2020 17:39:03 +0800 Subject: [PATCH 018/119] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E6=96=87=E6=A1=A3?= =?UTF-8?q?=E6=8F=8F=E8=BF=B0=E9=94=99=E8=AF=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 当前原文会导致如下文本 “ConfigMap 是 configMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。” --- content/zh/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/configuration/configmap.md b/content/zh/docs/concepts/configuration/configmap.md index 77f8ecf846..c907b508de 100644 --- a/content/zh/docs/concepts/configuration/configmap.md +++ b/content/zh/docs/concepts/configuration/configmap.md @@ -6,7 +6,7 @@ weight: 20 -{{< glossary_definition term_id="configmap" prepend="ConfigMap 是" length="all" >}} +{{< glossary_definition term_id="configmap" prepend="" length="all" >}} {{< caution >}} -{{< glossary_definition term_id="configmap" prepend="" length="all" >}} +{{< glossary_definition term_id="configmap" length="all" >}} {{< caution >}} ## Jak zacząć? @@ -49,7 +47,7 @@ ról i uprawnień. - [Otwórz *pull request* przy pomocy GitHub-a](/docs/contribute/new-content/new-content/#changes-using-github) dotyczący zmiany istniejącej dokumentacji i dowiedz się, jak otwierać zgłoszenia przy GitHub-ie. - [Zrecenzuj *pull requests*](/docs/contribute/review/reviewing-prs/) innego członka społeczności Kubernetes pod kątem dokładności i stylu. - Zapoznaj się z poradnikami Kubernetesa dotyczącymi [zawartości](/docs/contribute/style/content-guide/) i [stylu](/docs/contribute/style/style-guide/), aby twoje uwagi były zgodne z tymi wytycznymi. -- Dowiedz się, jak [używać szablonów stron](/docs/contribute/style/page-templates/) i [skrótów Hugo](/docs/contribute/style/hugo-shortcodes/), aby wprowadzać większe zmiany. +- Przeczytaj o [różnych typach zawartości na stronie](/docs/contribute/style/page-content-types/) i [skrótach Hugo](/docs/contribute/style/hugo-shortcodes/). ## Co dalej? diff --git a/content/pl/docs/home/_index.md b/content/pl/docs/home/_index.md index cae9bb4dc5..5c8facdbc5 100644 --- a/content/pl/docs/home/_index.md +++ b/content/pl/docs/home/_index.md @@ -13,7 +13,7 @@ menu: title: "Dokumentacja" weight: 20 post: > -

Naucz się, jak korzystać z Kubernetesa z pomocą dokumentacji, która opisuje pojęcia, zawiera samouczki i informacje źródłowe. Możesz także pomóc w jej tworzeniu!

+

Naucz się, jak korzystać z Kubernetesa z pomocą dokumentacji, która opisuje pojęcia, zawiera samouczki i informacje źródłowe. Możesz także pomóc w jej tworzeniu!

description: > Kubernetes to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. Gospodarzem tego projektu o otwartym kodzie źródłowym jest Cloud Native Computing Foundation. overview: > @@ -54,8 +54,8 @@ cards: description: Każdy może przyczynić się do tworzenia dokumentacji - zarówno nowicjusze, jak i starzy wyjadacze. button: Weź udział button_path: /docs/contribute -- name: download - title: Pobierz Kubernetesa +- name: release-notes + title: Informacje o wydaniu description: Jeśli instalujesz lub aktualizujesz Kubernetesa, zajrzyj do informacji o najnowszym wydaniu. - name: about title: O dokumentacji diff --git a/content/pl/docs/home/supported-doc-versions.md b/content/pl/docs/home/supported-doc-versions.md index 4744e68071..19e08be721 100644 --- a/content/pl/docs/home/supported-doc-versions.md +++ b/content/pl/docs/home/supported-doc-versions.md @@ -23,5 +23,3 @@ Bieżąca wersja to ## Poprzednie wersje {{< versions-other >}} - - diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md index cd00fb0e4f..2b014be8a4 100644 --- a/content/pl/docs/setup/_index.md +++ b/content/pl/docs/setup/_index.md @@ -24,8 +24,6 @@ Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w W dużym uproszczeniu, możesz zbudować klaster Kubernetes zarówno w środowisku szkoleniowym, jak i na potrzeby produkcyjne. - - ## Środowisko do nauki {#srodowisko-do-nauki} @@ -45,5 +43,3 @@ Aby uruchomić klaster Kubernetes do nauki na lokalnym komputerze, skorzystaj z Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora. Na stronie [Partnerzy Kubernetes](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes). - - diff --git a/content/pl/docs/setup/release/_index.md b/content/pl/docs/setup/release/_index.md new file mode 100755 index 0000000000..2783105198 --- /dev/null +++ b/content/pl/docs/setup/release/_index.md @@ -0,0 +1,4 @@ +--- +title: "Informacje o wydaniach i dozwolonych różnicach wersji" +weight: 10 +--- diff --git a/content/pl/docs/tasks/_index.md b/content/pl/docs/tasks/_index.md index 60f8f9808b..5a185543c3 100644 --- a/content/pl/docs/tasks/_index.md +++ b/content/pl/docs/tasks/_index.md @@ -5,80 +5,13 @@ weight: 50 content_type: concept --- -{{< toc >}} - W tej części dokumentacji Kubernetesa znajdują się opisy sposobu realizacji różnych zadań. Przedstawione są one zazwyczaj jako krótka sekwencja kilku kroków związanych z pojedynczym zadaniem. - - - - -## Graficzny interfejs użytkownika _(Dashboard)_ - -Instalacja i użycie graficznego interfejsu użytkownika z poziomu przeglądarki do zarządzania aplikacjami w kontenerach uruchomionymi na klastrze Kubernetes. - -## Jak używać polecenia kubectl - -Instalacja i konfiguracja polecenia `kubectl` do bezpośredniego zarządzania klastrami Kubernetes. - -## Konfigurowanie podów i kontenerów - -Najpopularniejsze czynności związane z konfiguracją podów i kontenerów. - -## Uruchamianie aplikacji - -Standardowe metody zarządzania aplikacjami, m. in. prowadzenie stopniowych aktualizacji _(rolling updates)_, przekazywanie konfiguracji oraz skalowanie horyzontalne podów. - -## Uruchamianie zadań - -Uruchamianie zadań w trybie równoległym. - -## Dostęp do aplikacji na klastrze - -Rozkładanie obciążenia i przekierowywanie ruchu sieciowego, konfigurowanie firewalla i usług DNS w celu zapewnienia dostępu do aplikacji w klastrze. - -## Monitoring, rejestracja i znajdowanie błędów - -Konfigurowanie monitoringu oraz rejestrowanie zdarzeń i komunikatów, pomagające rozwiązywać problemy związane z pracą klastra lub aplikacji uruchamianych w kontenerach. - -## Dostęp do API Kubernetes - -Różne metody bezpośredniego dostępu do API Kubernetes. - -## Używanie TLS - -Konfigurowanie aplikacji w taki sposób, aby korzystała i ufała łańcuchowi certyfikatów wydawanych przez Urząd Certyfikacji (CA) klastra. - -## Administracja klastrem - -Standardowe metody zarządzania klasterem. - -## Zarządzanie aplikacjami ze stanem (_Stateful_) - -Popularne zadania związane z zarządzaniem aplikacjami stanowymi _(Stateful)_, w tym: skalowanie, usuwanie i rozwiązywanie problemów dotyczących _StatefulSets_. - -## Procesy klastra typu _daemon_ - -Standardowe metody zarządzania _DaemonSet_, włączając sposoby prowadzenia stopniowej aktualizacji (_rolling update_). - -## Zarządzanie procesorami graficznymi (GPU) - -Konfiguracja i przydzielanie węzłom klastra procesorów GPU NVIDIA jako zasobów. - -## Zarządzanie HugePages - -Konfiguracja i dysponowanie _huge pages_ jako zasobu klastra. - - - ## {{% heading "whatsnext" %}} - Jeśli chciałbyś stworzyć nową stronę poświęconą jakiemuś zadaniu, przeczytaj [Jak przygotować propozycję zmian (PR)](/docs/home/contribute/create-pull-request/). - - From ab71197dcc5969950fb48743b8d3ae4023d573bf Mon Sep 17 00:00:00 2001 From: Kazuki Shikata Date: Thu, 18 Jun 2020 20:10:22 +0900 Subject: [PATCH 027/119] Fix a typo in service.md --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index a6d1d8f17d..e23ab9312f 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -894,7 +894,7 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -KubernetseはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 +KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。 From 04d6eda1187e7337c86202d5eb690105409d7f46 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Thu, 18 Jun 2020 10:07:37 -0300 Subject: [PATCH 028/119] Update content/es/docs/concepts/architecture/cloud-controller.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/architecture/cloud-controller.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/es/docs/concepts/architecture/cloud-controller.md b/content/es/docs/concepts/architecture/cloud-controller.md index 744a3ee046..b166ca0e80 100644 --- a/content/es/docs/concepts/architecture/cloud-controller.md +++ b/content/es/docs/concepts/architecture/cloud-controller.md @@ -10,7 +10,7 @@ El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en implementar nuevos proveedores de servicios y para migrar los existentes del antiguo modelo al nuevo CCM. -Este documento describe los conceptos tras el Cloud Controller Manager e informar detalles sobre sus funciones asociadas. +Este documento describe los conceptos tras el Cloud Controller Manager y detalla sus funciones asociadas. En la siguiente imagen, se puede visualizar la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: @@ -235,4 +235,3 @@ Los siguientes proveedores de servicios en la nube han implementado CCMs: Instrucciones para configurar y ejecutar el CCM pueden encontrarse [aquí](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). - From 57cf73d812a13c4f5d4a6df0883b6478563d198c Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 19 Jun 2020 17:25:05 +0900 Subject: [PATCH 029/119] Translate /docs/tasks/administer-cluster/coredns/ into Japanese --- .../docs/tasks/administer-cluster/coredns.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 content/ja/docs/tasks/administer-cluster/coredns.md diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md new file mode 100644 index 0000000000..6bbd01fbdf --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -0,0 +1,80 @@ +--- +title: サービスディスカバリーにCoreDNSを使用する +min-kubernetes-server-version: v1.9 +content_type: task +--- + + +このページでは、CoreDNSのアップグレードプロセスと、kube-dnsの代わりにCoreDNSをインストールする方法を説明します。 + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## CoreDNSについて {#about-coredns} + +[CoreDNS](https://coredns.io)は、KubernetesクラスターDNSとして機能できる柔軟で拡張可能なDNSサーバーです。Kubernetesと同様に、CoreDNSプロジェクトは{{< glossary_tooltip text="CNCF" term_id="cncf" >}}によってホストされています。 + +既存のデプロイでkube-dnsを置き換えるか、クラスターのデプロイとアップグレードを代行してくれるkubeadmのようなツールを使用することで、クラスターでkube-dnsの代わりにCoreDNSを使用することができます。 + + +## CoreDNSのインストール {#installing-coredns} + +kube-dnsの手動デプロイや置き換えについては、[CoreDNS GitHub project](https://github.com/coredns/deployment/tree/master/kubernetes)のドキュメントを参照してください。 + +## CoreDNSへの移行 {#migrating-to-coredns} + +### kubeadmを使用した既存のクラスターのアップグレード {#upgrading-an-existing-cluster-with-kubeadm} + +Kubernetesバージョン1.10以降では、`kube-dns`を使用しているクラスターを`kubeadm`を使用してアップグレードするときに、CoreDNSに移行することもできます。この場合、`kubeadm`は、`kube-dns` ConfigMapをベースにしてCoreDNS設定("Corefile")を生成し、フェデレーション、スタブドメイン、および上流のネームサーバーの設定を保持します。 + +kube-dnsからCoreDNSに移行する場合は、アップグレード時に必ず`CoreDNS`フィーチャーゲートを`true`に設定してください。たとえば、`v1.11.0`のアップグレードは次のようになります: +``` +kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true +``` + +Kubernetesバージョン1.13以降では、`CoreDNS`フィーチャーゲートが削除され、CoreDNSがデフォルトで使用されます。アップグレードしたクラスターでkube-dnsを使用する場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)のガイドに従ってください。 + +1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。**新しいConfigMapが稼働したら、カスタマイズを再適用できます。 + +Kubernetesバージョン1.11以降でCoreDNSを実行している場合、アップグレード中、既存のCorefileは保持されます。 + + +### kubeadmを使用してCoreDNSの代わりにkube-dnsをインストールする {#installing-kube-dns-instead-of-coredns-with-kubeadm} + +{{< note >}} +Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。 +{{< /note >}} + +1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します: + +``` +kubeadm init --feature-gates=CoreDNS=false +``` + +バージョン1.13以降の場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)に記載されているガイドに従ってください。 + +## CoreDNSのアップグレード {#upgrading-coredns} + +CoreDNSはv1.9以降のKubernetesで使用できます。Kubernetesに同梱されているCoreDNSのバージョンと、CoreDNSに加えられた変更は[こちら](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)で確認できます。 + +CoreDNSだけをアップグレードしたい場合や、独自のカスタムイメージを使用したい場合は、CoreDNSを手動でアップグレードすることができます。スムーズなアップグレードのために役立つ[ガイドラインとウォークスルー](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)が用意されています。 + +## CoreDNSのチューニング {#tuning-coredns} + +リソース使用率が問題になる場合は、CoreDNSの設定を調整すると役立つ場合があります。詳細は、[CoreDNSのスケーリングに関するドキュメント](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)を参照してください。 + + + +## {{% heading "whatsnext" %}} + + +[CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。 + + + + From 988984f477c66bc61b065822361a4640059a7e24 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 19 Jun 2020 17:59:02 +0900 Subject: [PATCH 030/119] Update content/ja/docs/tasks/administer-cluster/coredns.md Co-authored-by: makocchi --- content/ja/docs/tasks/administer-cluster/coredns.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md index 6bbd01fbdf..7122e3dc34 100644 --- a/content/ja/docs/tasks/administer-cluster/coredns.md +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -17,7 +17,7 @@ content_type: task ## CoreDNSについて {#about-coredns} -[CoreDNS](https://coredns.io)は、KubernetesクラスターDNSとして機能できる柔軟で拡張可能なDNSサーバーです。Kubernetesと同様に、CoreDNSプロジェクトは{{< glossary_tooltip text="CNCF" term_id="cncf" >}}によってホストされています。 +[CoreDNS](https://coredns.io)は、KubernetesクラスターDNSとして稼働させることができる柔軟で拡張可能なDNSサーバーです。Kubernetesと同様に、CoreDNSプロジェクトは{{< glossary_tooltip text="CNCF" term_id="cncf" >}}によってホストされています。 既存のデプロイでkube-dnsを置き換えるか、クラスターのデプロイとアップグレードを代行してくれるkubeadmのようなツールを使用することで、クラスターでkube-dnsの代わりにCoreDNSを使用することができます。 @@ -77,4 +77,3 @@ CoreDNSだけをアップグレードしたい場合や、独自のカスタム - From f6f2ee831015a3327715e84af677ae50c50d6e59 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Fri, 19 Jun 2020 19:33:58 +0900 Subject: [PATCH 031/119] Update components.md for v1.17 --- content/ja/docs/concepts/overview/components.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index a1e8d7f7dd..7b475c3a8f 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -9,7 +9,7 @@ card: {{% capture overview %}} Kubernetesをデプロイすると、クラスターが展開されます。 -{{< glossary_definition term_id="cluster" length="all" prepend="クラスターは、">}} +{{< glossary_definition term_id="cluster" length="all" prepend="Kubernetesクラスターは、">}} このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。 @@ -21,12 +21,11 @@ Kubernetesをデプロイすると、クラスターが展開されます。 {{% capture body %}} -## マスターコンポーネント +## コントロールプレーンコンポーネント -マスターコンポーネントは、クラスターのコントロールプレーンを提供します。 -マスターコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。 +コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。 -マスターコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのマスターコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 +コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのマスターコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 ### kube-apiserver From a3cbf7af011cc68f64678221f2ed272223930161 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Fri, 19 Jun 2020 19:44:15 +0900 Subject: [PATCH 032/119] Update custom-resources --- .../api-extension/custom-resources.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 41f96a20ce..bb238d2259 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -1,7 +1,7 @@ --- title: カスタムリソース content_type: concept -weight: 20 +weight: 10 --- @@ -24,7 +24,7 @@ weight: 20 カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供します。カスタムリソースを *カスタムコントローラー* と組み合わせることで、カスタムリソースは真の _宣言的API_ を提供します。 -[宣言的API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesオブジェクトを理解する)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。 +[宣言的API](/ja/docs/concepts/overview/kubernetes-api/)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。 コントローラーは、構造化データをユーザーが指定したあるべき状態と解釈し、その状態を管理し続けます。 稼働しているクラスターのライフサイクルとは無関係に、カスタムコントローラーをデプロイ、更新することが可能です。カスタムコントローラーはあらゆるリソースと連携できますが、カスタムリソースと組み合わせると特に効果を発揮します。[オペレーターパターン](https://coreos.com/blog/introducing-operators.html)は、カスタムリソースとカスタムコントローラーの組み合わせです。カスタムコントローラーにより、特定アプリケーションのドメイン知識を、Kubernetes APIの拡張に変換することができます。 @@ -108,6 +108,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## CustomResourceDefinition [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。 +CRDオブジェクトの名前は[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。 @@ -115,7 +116,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## APIサーバーアグリゲーション -通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、また[CRD](#customresourcedefinition)を通じて、同じ方法でカスタムリソースも管理できます。 +通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRDs](#customresourcedefinition)を通じて同じように管理することができます。 [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。 @@ -132,9 +133,9 @@ CRDは簡単に使えます。アグリゲートAPIはより柔軟です。ニ CRDは、アグリゲートAPIと比べ、簡単に作れます。 -| CRD | アグリゲートAPI | +| CRDs | アグリゲートAPI | | -------------------------- | --------------- | -| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要。ユーザーはCRDコントローラーとしてどの言語でも選択可能 | +| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 | | 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない | | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 | @@ -146,12 +147,12 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | 機能 | 詳細 | CRD | アグリゲートAPI | | ---- | ---- | --- | --------------- | | バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 | -| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.16でベータ)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9)を通じて可能 | はい | +| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (しかしこの方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい | | 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい | | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい | | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい | | サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい | -| サブリソースの状態 |
  • より詳細なアクセスコントロール: ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む
  • カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソースがspecと、statusでセクションが分離している必要がある)
| [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | +| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際により詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | | その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい | | strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい | | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい | @@ -174,7 +175,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック | | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 | | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 | -| 未設定 vs 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる | +| 未設定 対 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる | | クライアントライブラリーの生成 | Kubernetesは、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 | | ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 | From e591e0d0c5777caa682502f362fabd67e629f1a2 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Fri, 19 Jun 2020 21:15:06 +0900 Subject: [PATCH 033/119] update runtime-class.md --- .../docs/concepts/containers/runtime-class.md | 54 ++++++++++++++++--- 1 file changed, 46 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 6ea1f1e4e1..4c435e03e3 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -39,8 +39,8 @@ RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 {{< note >}} -RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 -設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/ja/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。 +RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 +設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。 {{< /note >}} RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。 @@ -60,6 +60,9 @@ metadata: handler: myconfiguration # 対応するCRI設定 ``` +RuntimeClassオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)に従う必要があります。 + + {{< note >}} RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター管理者のみに制限されることを推奨します。 これはたいていデフォルトで有効となっています。さらなる詳細に関しては[Authorization @@ -94,7 +97,7 @@ CRIランタイムのセットアップに関するさらなる詳細は、[CRI Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。 -#### [containerd](https://containerd.io/) +#### {{< glossary_tooltip term_id="containerd" >}} ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。 正しいハンドラーは、その`runtime`セクションで設定されます。 @@ -106,20 +109,49 @@ Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラ containerdの設定に関する詳細なドキュメントは下記を参照してください。 https://github.com/containerd/cri/blob/master/docs/config.md -#### [cri-o](https://cri-o.io/) +#### {{< glossary_tooltip term_id="cri-o" >}} -ランタイムハンドラーは、`/etc/crio/crio.conf`にあるcri-oの設定ファイルにより設定されます。 +ランタイムハンドラーは、`/etc/crio/crio.conf`にあるCRI-Oの設定ファイルにより設定されます。 正しいハンドラーは[crio.runtime -table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。 +table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。 ``` [crio.runtime.runtimes.${HANDLER_NAME}] runtime_path = "${PATH_TO_BINARY}" ``` -cri-oの設定に関する詳細なドキュメントは下記を参照してください。 -https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go +CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。 +[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md + +### スケジューリング {#scheduling} + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。 +このフィールドを使うことで、Podに設定されたRuntimeClassをサポートしているノードへPodがスケジュールされることを保証することができます。 +スケジューリングをサポートするためにはRuntimeClass [admission controller][]を有効にしなければなりません。（1.16ではデフォルトです） + +特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。 +RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。 +もし設定が衝突した場合は、Pod作成は拒否されるでしょう。 + +もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。 +`nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。 + +ノードの選択とtolerationsについての詳細は[Node上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。 + +[admission controller]: /docs/reference/access-authn-authz/admission-controllers/ + +### Podオーバーヘッド + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。 +`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。（デフォルトではoffです） + +PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。 +このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。 ### RutimeClassをα版からβ版にアップグレードする @@ -140,3 +172,9 @@ RuntimeClassのβ版の機能は、下記の変更点を含みます。 - `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。 +### 参考文献 + +- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) +- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) +- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む +- [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) From 701e71587bbf82a97110151ca8251d9ec8c1814f Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Fri, 19 Jun 2020 21:18:02 +0900 Subject: [PATCH 034/119] translate node --- content/ja/docs/concepts/containers/runtime-class.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 4c435e03e3..43ad3402c2 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -39,7 +39,7 @@ RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 {{< note >}} -RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 +RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのノードがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。 {{< /note >}} @@ -139,7 +139,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。 `nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。 -ノードの選択とtolerationsについての詳細は[Node上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。 +ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。 [admission controller]: /docs/reference/access-authn-authz/admission-controllers/ From f261c964382d6234c8fc5bceaf4dbebfa12ecbcf Mon Sep 17 00:00:00 2001 From: makocchi Date: Fri, 19 Jun 2020 21:24:07 +0900 Subject: [PATCH 035/119] Update content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md Co-authored-by: Naoki Oketani --- .../extend-kubernetes/api-extension/custom-resources.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index bb238d2259..f3d84a7800 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -108,7 +108,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## CustomResourceDefinition [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。 -CRDオブジェクトの名前は[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。 +CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。 @@ -222,4 +222,3 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ * [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ - From bcb107179db5e5cddd4a103413b271fc34acbae0 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Fri, 19 Jun 2020 21:28:10 +0900 Subject: [PATCH 036/119] CRDs to CRD --- .../extend-kubernetes/api-extension/custom-resources.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index f3d84a7800..066fbc483f 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -116,7 +116,7 @@ CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/ov ## APIサーバーアグリゲーション -通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRDs](#customresourcedefinition)を通じて同じように管理することができます。 +通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。 [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。 @@ -133,7 +133,7 @@ CRDは簡単に使えます。アグリゲートAPIはより柔軟です。ニ CRDは、アグリゲートAPIと比べ、簡単に作れます。 -| CRDs | アグリゲートAPI | +| CRD | アグリゲートAPI | | -------------------------- | --------------- | | プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 | | 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | From 75ee91ff685a56811459d4f9d50d804191c7662d Mon Sep 17 00:00:00 2001 From: arisgi Date: Fri, 19 Jun 2020 22:06:46 +0900 Subject: [PATCH 037/119] Fix notation --- .../ja/docs/concepts/containers/container-lifecycle-hooks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index 627c95b4c0..e3e44ba7e0 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -80,7 +80,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 ``` Events: - FirstSeen LastSeen Count From SubobjectPath Type Reason Message + FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" From e313cf575a3a69c7bb2fa961bf51e8aaece8457d Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Fri, 19 Jun 2020 22:55:44 +0900 Subject: [PATCH 038/119] update assign-pod-node.md --- .../concepts/configuration/assign-pod-node.md | 222 +++++++++--------- 1 file changed, 112 insertions(+), 110 deletions(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 7a6c27a1e5..05dd0bcb36 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -1,5 +1,5 @@ --- -title: Node上へのPodのスケジューリング +title: ノード上へのPodのスケジューリング content_type: concept weight: 30 --- @@ -7,10 +7,10 @@ weight: 30 -[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="ノード" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 -スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 -SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 +スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のノードへデプロイしたり、Podを配置する際にリソースが不十分なノードにはデプロイされないことが挙げられます)が、 +SSDが搭載されているノードにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じノードにデプロイする等、柔軟な制御が必要なこともあります。 @@ -18,7 +18,7 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ ## nodeSelector -`nodeSelector`は、Nodeを選択するための、最も簡単で推奨されている手法です。 +`nodeSelector`は、ノードを選択するための、最も簡単で推奨されている手法です。 `nodeSelector`はPodSpecのフィールドです。これはkey-valueペアのマップを特定します。 あるノードでPodを稼働させるためには、そのノードがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。 最も一般的な使用方法は、1つのkey-valueペアを付与する方法です。 @@ -27,16 +27,16 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ ### ステップ0: 前提条件 -この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](https://github.com/kubernetes/kubernetes#documentation)がされていることが前提となっています。 +この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。 -### ステップ1: Nodeへのラベルの付与 +### ステップ1: ノードへのラベルの付与 `kubectl get nodes`で、クラスターのノードの名前を取得してください。 -そして、ラベルを付与するNodeを選び、`kubectl label nodes =`で選択したNodeにラベルを付与します。 -例えば、Nodeの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。 +そして、ラベルを付与するノードを選び、`kubectl label nodes =`で選択したノードにラベルを付与します。 +例えば、ノードの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。 `kubectl get nodes --show-labels`によって、ノードにラベルが付与されたかを確認することができます。 -また、`kubectl describe node "nodename"`から、そのNodeの全てのラベルを表示することもできます。 +また、`kubectl describe node "nodename"`から、そのノードの全てのラベルを表示することもできます。 ### ステップ2: PodへのnodeSelectorフィールドの追加 @@ -60,169 +60,170 @@ nodeSelectorを以下のように追加します: {{< codenew file="pods/pod-nginx.yaml" >}} -`kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。 -`kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。 +`kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したノードへスケジュールされます。 +`kubectl get pods -o wide`で表示される"NODE"の列から、Podがデプロイされているノードを確認することができます。 -## 補足: ビルトインNodeラベル +## 補足: ビルトインノードラベル {#built-in-node-labels} -明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 +明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にノードへ付与されているものもあります。 以下のようなラベルが該当します。 -* `kubernetes.io/hostname` -* `failure-domain.beta.kubernetes.io/zone` -* `failure-domain.beta.kubernetes.io/region` -* `beta.kubernetes.io/instance-type` -* `kubernetes.io/os` -* `kubernetes.io/arch` +* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) +* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) +* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) +* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) +* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) +* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) +* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) {{< note >}} これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 -例えば、`kubernetes.io/hostname`の値はNodeの名前と同じである環境もあれば、異なる環境もあります。 +例えば、`kubernetes.io/hostname`の値はノードの名前と同じである環境もあれば、異なる環境もあります。 {{< /note >}} -## Nodeの隔離や制限 -Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。 -これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。 -この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 -これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。 +## ノードの隔離や制限 + +ノードにラベルを付与することで、Podは特定のノードやノードグループにスケジュールされます。 +これにより、特定のPodを、確かな隔離性や安全性、特性を持ったノードで稼働させることができます。 +この目的でラベルを使用する際に、ノード上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 +これは、安全性が損なわれたノードがkubeletの認証情報をノードのオブジェクトに設定したり、スケジューラーがそのようなノードにデプロイすることを防ぎます。 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 -Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。 +ノードの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 -1. NodeRestrictionを使用するため、Kubernetesのバージョンがv1.11以上であること。 -2. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっていること。 -3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 +1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。 +2. ノードに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 -## Affinity と Anti-Affinity {#affinity-and-anti-affinity} +## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} -`nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。 -Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。 +`nodeSelector`はPodの稼働を特定のラベルが付与されたノードに制限する最も簡単な方法です。 +アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。 拡張機能は以下の通りです。 -1. 様々な指定方法がある ("AND条件"に限らない) -2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができる -3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができる +1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。 +2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。 +3. ノード自体のラベルではなく、ノード(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。 -Affinityは"Node Affinity"と"Inter-Pod Affinity/Anti-Affinity"の2種類から成ります。 -Node affinityは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Inter-Pod Affinity/Anti-Affinityは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 +アフィニティは"ノードアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。 +ノードアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、ノードのラベルではなくPodのラベルに対して制限をかけます。 -`nodeSelector`は問題なく使用することができますが、Node affinityは`nodeSelector`で指定できる条件を全て実現できるため、将来的には推奨されなくなります。 +### ノードアフィニティ -### Node Affinity +ノードアフィニティはα機能としてKubernetesのv1.2から導入されました。 +ノードアフィニティは概念的には、ノードのラベルによってPodがどのノードにスケジュールされるかを制限する`nodeSelector`と同様です。 -Node Affinityはα機能としてKubernetesのv1.2から導入されました。 -Node Affinityは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 - -現在は2種類のNode Affinityがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 -前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 -"IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも -PodはそのNodeで稼働し続けるということです。 -将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNode Affinityに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 +現在は2種類のノードアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 +前者はノードにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 +"IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、ノードのラベルが変更され、Podがその条件を満たさなくなった場合でも +Podはそのノードで稼働し続けるということです。 +将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、Podのノードアフィニティに記された必須要件を満たさなくなったノードからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 それぞれの使用例として、 -`requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、 +`requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたノード上でPodを稼働させる"、 `preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる" といった方法が挙げられます。 -Node Affinityは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 +ノードアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 -Node Affinityを使用したPodの例を以下に示します: +ノードアフィニティを使用したPodの例を以下に示します: {{< codenew file="pods/pod-with-node-affinity.yaml" >}} -このNode Affinityでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 -加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。 +このノードアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたノードにしか配置されません。 +加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたノードが優先されます。 この例ではオペレーター`In`が使われています。 -Node Affinityでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 -`NotIn`と`DoesNotExist`はNode Anti-Affinity、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 +ノードアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 +`NotIn`と`DoesNotExist`はノードアンチアフィニティ、またはPodを特定のノードにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 -`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。 +`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすノードにスケジュールされます。 -`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 +`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたノードへスケジュールされます。 -`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。 +`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたノードへスケジュールされます。 -PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。 -言い換えると、AffinityはPodをスケジュールする際にのみ考慮されます。 +Podがスケジュールされたノードのラベルを削除したり変更しても、Podは削除されません。 +言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。 `preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。 -全ての必要条件(リソースやRequiredDuringScheduling Affinity等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 -このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。 +全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたノードに対して、スケジューラーはそのノードがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 +このスコアがノードの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したノードが優先されます。 -### Inter-Pod Affinity/Anti-Affinity +### Pod間アフィニティとアンチアフィニティ -Inter-Pod AffinityとAnti-Affinityは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 -このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(Anti-Affinityの場合は稼働させない)"という形式です。 +Pod間アフィニティとアンチアフィニティは、ノードのラベルではなく、すでにノードで稼働しているPodのラベルに従ってPodがスケジュールされるノードを制限します。 +このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。 Yはnamespaceのリストで指定したLabelSelectorで表されます。 -Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 -概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 -これらを表すためにシステムが使用するNode Labelのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 -先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 +ノードと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 +概念的に、Xはノードや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 +これらを表すためにシステムが使用するノードラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 +先述のセクション[補足: ビルトインノードラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 {{< note >}} -Inter-Pod AffinityとAnti-Affinityは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 -そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。 +Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 +そのため、数百台以上のノードから成るクラスターでは使用することを推奨されません。 {{< /note >}} {{< note >}} -Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。 -例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 -それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。 +Podのアンチアフィニティは、ノードに必ずラベルが付与されている必要があります。 +言い換えると、クラスターの全てのノードが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 +それらが付与されていないノードが存在する場合、意図しない挙動を示すことがあります。 {{< /note >}} -Node Affinityと同様に、Pod AffinityとPod Anti-Affinityにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 -前述のNode Affinityのセクションを参照してください。 -`requiredDuringSchedulingIgnoredDuringExecution`を指定するAffinityの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 -また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するAnti-Affinityの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 +ノードアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 +前述のノードアフィニティのセクションを参照してください。 +`requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 +また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 -Inter-Pod Affinityは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Inter-Pod Anti-Affinityは、`podAntiAffinity`で指定します。 +Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。 -#### Pod Affinityを使用したPodの例 +#### Podアフィニティを使用したPodの例 {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} -このPodのAffifnityは、Pod AffinityとPod Anti-Affinityを1つずつ定義しています。 +このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 -Pod Affinityは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 -Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。 -Pod Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています -(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 -Pod AffinityとPod Anti-Affinityや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 +Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているノードが同じゾーンにあれば、Podはそのノードにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるノードが少なくとも1つはある状態で、 +ノードNがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはノードNで稼働させることができます)。 +Podアンチアフィニティは、「すでにあるノード上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのノード上で稼働させない」という条件を指定しています +(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のノードにはスケジュールされなくなります)。 +PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 -Pod AffinityとPod Anti-Affinityで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 +PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 原則として、`topologyKey`には任意のラベルとキーが使用できます。 しかし、パフォーマンスやセキュリティの観点から、以下の制約があります: -1. Affinityと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しないことは許可されていません。 -2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 +1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。 +2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。 -3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しなかった場合、"全てのトポロジー"と解釈されます("全てのトポロジー"とは、ここでは`kubernetes.io/hostname`、`failure-domain.beta.kubernetes.io/zone`、`failure-domain.beta.kubernetes.io/region`を合わせたものを意味します)。 +3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。 4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。 `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。 -省略した場合や空の場合は、AffinityとAnti-Affinityが定義されたPodのnamespaceがデフォルトで設定されます。 +省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。 -`requiredDuringSchedulingIgnoredDuringExecution`が指定されたAffinityとAnti-Affinityでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 +`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるノードにPodがスケジュールされます。 #### 実際的なユースケース -Inter-Pod AffinityとAnti-Affinityは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。 -Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 +Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。 +Workloadが、ノード等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 -##### 常に同じNodeで稼働させる場合 +##### 常に同じノードで稼働させる場合 ３つのノードから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。 このような場合、ウェブサーバーは可能な限りキャッシュと共存させることが望ましいです。 ラベル`app=store`を付与した3つのレプリカから成るredisのdeploymentを記述したyamlファイルを示します。 -Deploymentには、1つのNodeにレプリカを共存させないために`PodAntiAffinity`を付与しています。 +Deploymentには、1つのノードにレプリカを共存させないために`PodAntiAffinity`を付与しています。 ```yaml @@ -322,24 +323,24 @@ web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4 web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2 ``` -##### 同じNodeに共存させない場合 +##### 同じノードに共存させない場合 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。 -同様の方法で、Anti-Affinityを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 +同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 ## nodeName -`nodeName`はNodeの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。 +`nodeName`はノードの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。 `nodeName`はPodSpecのフィールドです。 -ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているNodeのkubeletはPodを稼働させようとします。 -そのため、PodSpecに`nodeName`が指定されると、上述のNodeの選択方法よりも優先されます。 +ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているノードのkubeletはPodを稼働させようとします。 +そのため、PodSpecに`nodeName`が指定されると、上述のノードの選択方法よりも優先されます。 `nodeName`を使用することによる制約は以下の通りです: -- その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。 -- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由はOutOfmemoryやOutOfcpuになります。 -- クラウド上のNodeの名前は予期できず、変更される可能性があります。 +- その名前のノードが存在しない場合、Podは起動されす、自動的に削除される場合があります。 +- その名前のノードにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 +- クラウド上のノードの名前は予期できず、変更される可能性があります。 `nodeName`を指定したPodの設定ファイルの例を示します: @@ -355,17 +356,18 @@ spec: nodeName: kube-01 ``` -上記のPodはkube-01という名前のNodeで稼働します。 +上記のPodはkube-01という名前のノードで稼働します。 ## {{% heading "whatsnext" %}} -[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。 - -[Node Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と -[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) -には、Taintsの要点に関して様々な背景が紹介されています。 +[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、ノードはPodを追い出すことができます。 +[ノードアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と +[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) +のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。 +一度Podがノードに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。 +[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はノードレベルのリソース割り当てを決定する際に関与します。 From a02aee02260500f205952aaea4d47fb6be6ed2ca Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Sat, 20 Jun 2020 07:51:49 +0900 Subject: [PATCH 039/119] Update content/ja/docs/concepts/overview/components.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/overview/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 7b475c3a8f..c146ffae73 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -25,7 +25,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。 コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。 -コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのマスターコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 +コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 ### kube-apiserver From c9b4e527cf4414c123ae2bcab2f8eeec3770d282 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Sat, 20 Jun 2020 07:51:56 +0900 Subject: [PATCH 040/119] Update content/ja/docs/concepts/overview/components.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/overview/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index c146ffae73..9ce6783fdc 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -23,7 +23,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。 ## コントロールプレーンコンポーネント -コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。 +コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。 コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 From 3ea00ef562fa1a4e9dcb3beddfd932142776b335 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 20 Jun 2020 16:15:09 +0900 Subject: [PATCH 041/119] Translate /docs/tasks/inject-data-application/environment-variable-expose-pod-information/ into Japanese --- ...ronment-variable-expose-pod-information.md | 150 ++++++++++++++++++ 1 file changed, 150 insertions(+) create mode 100644 content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md new file mode 100644 index 0000000000..8eded8f8a0 --- /dev/null +++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -0,0 +1,150 @@ +--- +title: 環境変数によりコンテナにPod情報を公開する +content_type: task +weight: 30 +--- + + + +このページでは、Podが環境変数を使用して、Pod内で実行されているコンテナに自分自身の情報を公開する方法を説明します。環境変数は、Podのフィールドとコンテナのフィールドを公開できます。 + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + + +## Downward API {#the-downward-api} + +Podとコンテナのフィールドを実行中のコンテナに公開する方法は2つあります: + +* 環境変数 +* [ボリュームファイル](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) + +これら2つの方法を合わせて、Podとコンテナフィールドを公開する方法を*Downward API*と呼びます。 + + +## Podフィールドを環境変数の値として使用する {#use-pod-fields-as-values-for-environment-variables} + +この演習では、1つのコンテナを持つPodを作成します。Podの設定ファイルは次のとおりです: + +{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} + +設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素は、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。 + +{{< note >}} +この例のフィールドはPodのフィールドです。これらはPod内のコンテナのフィールドではありません。 +{{< /note >}} + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml +``` + +Podのコンテナが実行されていることを確認します: + +```shell +kubectl get pods +``` + +コンテナのログを表示します: + +```shell +kubectl logs dapi-envars-fieldref +``` + +出力には、選択した環境変数の値が表示されます: + +``` +minikube +dapi-envars-fieldref +default +172.17.0.4 +default +``` + +これらの値がログにある理由を確認するには、設定ファイルの`command`および`args`フィールドを確認してください。コンテナが起動すると、5つの環境変数の値が標準出力に書き込まれます。これを10秒ごとに繰り返します。 + +次に、Podで実行しているコンテナへのシェルを取得します: + +```shell +kubectl exec -it dapi-envars-fieldref -- sh +``` + +シェルで環境変数を表示します: + +```shell +/# printenv +``` + +出力は、特定の環境変数にPodフィールドの値が割り当てられていることを示しています: + +``` +MY_POD_SERVICE_ACCOUNT=default +... +MY_POD_NAMESPACE=default +MY_POD_IP=172.17.0.4 +... +MY_NODE_NAME=minikube +... +MY_POD_NAME=dapi-envars-fieldref +``` + +## コンテナフィールドを環境変数の値として使用する {#use-container-fields-as-values-for-environment-variables} + +前の演習では、環境変数の値としてPodフィールドを使用しました。次の演習では、環境変数の値としてコンテナフィールドを使用します。これは、1つのコンテナを持つPodの設定ファイルです: + +{{< codenew file="pods/inject/dapi-envars-container.yaml" >}} + +設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素は、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。 + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml +``` + +Podのコンテナが実行されていることを確認します: + +```shell +kubectl get pods +``` + +コンテナのログを表示します: + +```shell +kubectl logs dapi-envars-resourcefieldref +``` + +出力には、選択した環境変数の値が表示されます: + +``` +1 +1 +33554432 +67108864 +``` + + + +## {{% heading "whatsnext" %}} + + +* [コンテナの環境変数の定義](/ja/docs/tasks/inject-data-application/define-environment-variable-container/) +* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core) +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) +* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core) +* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) + + + From 279e2cca55cc6b0ba4fb4fbece8cfd4f5cb4e5b6 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 20 Jun 2020 18:17:34 +0900 Subject: [PATCH 042/119] Translate glossary/cncf into Japanese --- content/ja/docs/reference/glossary/cncf.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100755 content/ja/docs/reference/glossary/cncf.md diff --git a/content/ja/docs/reference/glossary/cncf.md b/content/ja/docs/reference/glossary/cncf.md new file mode 100755 index 0000000000..1525d9a277 --- /dev/null +++ b/content/ja/docs/reference/glossary/cncf.md @@ -0,0 +1,21 @@ +--- +title: Cloud Native Computing Foundation (CNCF) +id: cncf +date: 2019-05-26 +full_link: https://cncf.io/ +short_description: > + Cloud Native Computing Foundation + +aka: +tags: +- community +--- + Cloud Native Computing Foundation (CNCF)は、持続可能なエコシステムを構築し、マイクロサービスアーキテクチャの一部としてコンテナをオーケストレーションする[プロジェクト](https://www.cncf.io/projects/)を中心としたコミュニティを育成します。 + +KubernetesはCNCFプロジェクトです。 + + + +CNCFは[Linux Foundation](https://www.linuxfoundation.org/)のサブファウンデーションです。 +その使命は、クラウドネイティブコンピューティングをユビキタスにすることです。 + From 9599c20fae6034084ff1dfd8f473258671ced487 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 20 Jun 2020 18:36:44 +0900 Subject: [PATCH 043/119] Update content/ja/docs/reference/glossary/cncf.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/glossary/cncf.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/cncf.md b/content/ja/docs/reference/glossary/cncf.md index 1525d9a277..85e6f60f0a 100755 --- a/content/ja/docs/reference/glossary/cncf.md +++ b/content/ja/docs/reference/glossary/cncf.md @@ -17,5 +17,4 @@ KubernetesはCNCFプロジェクトです。 CNCFは[Linux Foundation](https://www.linuxfoundation.org/)のサブファウンデーションです。 -その使命は、クラウドネイティブコンピューティングをユビキタスにすることです。 - +CNCFの使命は、クラウドネイティブコンピューティングをユビキタスにすることです。 From 478ba38c78dceec90b2223c2128f677db241262a Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 21 Jun 2020 18:50:20 +0900 Subject: [PATCH 044/119] modify postpositional particles --- .../environment-variable-expose-pod-information.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index 8eded8f8a0..ed7d78123b 100644 --- a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -37,7 +37,7 @@ Podとコンテナのフィールドを実行中のコンテナに公開する {{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} -設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素は、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。 +設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。 {{< note >}} この例のフィールドはPodのフィールドです。これらはPod内のコンテナのフィールドではありません。 @@ -104,7 +104,7 @@ MY_POD_NAME=dapi-envars-fieldref {{< codenew file="pods/inject/dapi-envars-container.yaml" >}} -設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素は、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。 +設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。 Podを作成します: From 590650a6abe2b3b961cdb5bfe9fc562dc6964bcd Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 21 Jun 2020 18:51:21 +0900 Subject: [PATCH 045/119] modify `expose` translation --- .../environment-variable-expose-pod-information.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index ed7d78123b..8193b2dc4c 100644 --- a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -1,12 +1,12 @@ --- -title: 環境変数によりコンテナにPod情報を公開する +title: 環境変数によりコンテナにPod情報を共有する content_type: task weight: 30 --- -このページでは、Podが環境変数を使用して、Pod内で実行されているコンテナに自分自身の情報を公開する方法を説明します。環境変数は、Podのフィールドとコンテナのフィールドを公開できます。 +このページでは、Podが環境変数を使用して、Pod内で実行されているコンテナに自分自身の情報を共有する方法を説明します。環境変数は、Podのフィールドとコンテナのフィールドを共有できます。 @@ -23,12 +23,12 @@ weight: 30 ## Downward API {#the-downward-api} -Podとコンテナのフィールドを実行中のコンテナに公開する方法は2つあります: +Podとコンテナのフィールドを実行中のコンテナに共有する方法は2つあります: * 環境変数 * [ボリュームファイル](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) -これら2つの方法を合わせて、Podとコンテナフィールドを公開する方法を*Downward API*と呼びます。 +これら2つの方法を合わせて、Podとコンテナフィールドを共有する方法を*Downward API*と呼びます。 ## Podフィールドを環境変数の値として使用する {#use-pod-fields-as-values-for-environment-variables} From 4e5a0b2ce6eda14cdc375daf02e148f80d4ffd0f Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 21 Jun 2020 18:53:09 +0900 Subject: [PATCH 046/119] modify `Environment variables can expose...` translation --- .../environment-variable-expose-pod-information.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index 8193b2dc4c..c2e4f1f1b4 100644 --- a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -6,7 +6,7 @@ weight: 30 -このページでは、Podが環境変数を使用して、Pod内で実行されているコンテナに自分自身の情報を共有する方法を説明します。環境変数は、Podのフィールドとコンテナのフィールドを共有できます。 +このページでは、Podが環境変数を使用して、Pod内で実行されているコンテナに自分自身の情報を共有する方法を説明します。環境変数を使うと、Podのフィールドとコンテナのフィールドを共有できます。 From ac34a1aff97b29a0cee1c748299f5fdacae9911a Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 21 Jun 2020 20:53:57 +0900 Subject: [PATCH 047/119] Translate /docs/tasks/access-application-cluster/list-all-running-container-images/ into Japanese --- .../list-all-running-container-images.md | 112 ++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md diff --git a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md new file mode 100644 index 0000000000..3d36d99539 --- /dev/null +++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -0,0 +1,112 @@ +--- +title: クラスターで実行されているすべてのコンテナイメージを一覧表示する +content_type: task +weight: 100 +--- + + + +このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。 + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +この演習では、kubectlを使用してクラスターで実行されているすべてのPodを取得し、出力をフォーマットしてそれぞれのコンテナの一覧を取得します。 + +## すべての名前空間のコンテナイメージを一覧表示する {#list-all-container-images-in-all-namespaces} + +- `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します +- `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。 + - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。 +- `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。 + - `tr`を使用してスペースを改行に置換します。 + - `sort`を使用して結果を並べ替えます。 + - `uniq`を使用してイメージ数を集計します。 + +```sh +kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +tr -s '[[:space:]]' '\n' |\ +sort |\ +uniq -c +``` + +上記のコマンドは、返されるすべてのアイテムについて、`image`という名前のすべてのフィールドを再帰的に返します。 + +別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます: + +```sh +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +jsonpathは次のように解釈されます: + +- `.items[*]`: 各戻り値 +- `.spec`: 仕様の取得 +- `.containers[*]`: 各コンテナ +- `.image`: イメージの取得 + +{{< note >}} +例えば`kubectl get pod nginx`のように名前を指定して単一のPodを取得する場合、アイテムのリストではなく単一のPodが返されるので、パスの`.items[*]`部分は省略してください。 +{{< /note >}} + +## Podごとにコンテナイメージを一覧表示する {#list-container-images-by-pod} + +`range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。 + +```sh +kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +sort +``` + +## Podのラベルを使用してコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace} + +特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。 + +```sh +kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +``` + +## Podの名前空間でコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace} + +特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。 + +```sh +kubectl get pods --namespace kube-system -o jsonpath="{..image}" +``` + +## jsonpathの代わりにgo-templateを使用してコンテナイメージを一覧表示する {#list-container-images-using-a-go-template-instead-of-jsonpath} + +jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています: + + +```sh +kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" +``` + + + + + + + + + +## {{% heading "whatsnext" %}} + + +### 参照 + +* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド +* [Go template](https://golang.org/pkg/text/template/)参照ガイド + + + + From 7b0bb76766471eafd5bec028f8d818fea7e0e1b2 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Mon, 22 Jun 2020 10:51:07 +0900 Subject: [PATCH 048/119] update overview.md to follow v1.17 --- content/ja/docs/concepts/configuration/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 791582e11b..fc3fb0efb3 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -27,7 +27,7 @@ weight: 10 - よりよいイントロスペクションのために、オブジェクトの説明をアノテーションに入れましょう。 -## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob +## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob{#naked-pods-vs-replicasets-deployments-and-jobs} - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。 @@ -81,7 +81,7 @@ weight: 10 - `imagePullPolicy: Never`: 常にローカルでイメージを探そうとします。ない場合にもイメージはpullしません。 {{< note >}} -コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます(例:`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。 +コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます。`:`を`@`で置き換えます(例:`image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。 {{< /note >}} {{< note >}} From 8afb93810646b8f8c9fad895493373cb7a0c013a Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Mon, 22 Jun 2020 13:35:03 +0900 Subject: [PATCH 049/119] Translate node-conformance.md for v1.17 --- .../setup/best-practices/node-conformance.md | 63 +++++++------------ 1 file changed, 24 insertions(+), 39 deletions(-) diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index 129bd762ba..8e8af44cc4 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -7,43 +7,36 @@ weight: 30 ## ノード適合テスト -*Node conformance test* is a containerized test framework that provides a system -verification and functionality test for a node. The test validates whether the -node meets the minimum requirements for Kubernetes; a node that passes the test -is qualified to join a Kubernetes cluster. +*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスタに参加する資格があることになります。 ## 制約 -In Kubernetes version 1.5, node conformance test has the following limitations: +Kubernetesのバージョン1.5ではノード適合テストには以下の制約があります: -* Node conformance test only supports Docker as the container runtime. +* ノード適合テストはコンテナのランタイムとしてDockerのみをサポートします。 ## ノードの前提条件 -To run node conformance test, a node must satisfy the same prerequisites as a -standard Kubernetes node. At a minimum, the node should have the following -daemons installed: +適合テストを実行するにはノードは通常のKubernetesノードと同じ前提条件を満たしている必要があります。 最低でもノードに以下のデーモンがインストールされている必要があります: -* Container Runtime (Docker) +* コンテナランタイム (Docker) * Kubelet ## ノード適合テストの実行 -To run the node conformance test, perform the following steps: +ノード適合テストを実行するには、以下の手順に従います: -1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`, -because the test framework starts a local master to test Kubelet. There are some -other Kubelet flags you may care: - * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR - to Kubelet, for example `--pod-cidr=10.180.0.0/24`. - * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should - remove the flag to run the test. +1. Kubeletをlocalhostに指定します(`--api-servers="http://localhost:8080"`)、 +なぜならテストフレームワークはKubeletをテストするためにローカルマスターを起動するからです。 +他にも配慮するべきKubeletフラグがいくつかあります: + * `--pod-cidr`: `kubenet`を利用している場合は、Kubeletに任意のCIDR(例: `--pod-cidr=10.180.0.0/24`)を指定する必要があります。 + * `--cloud-provider`: `--cloud-provider=gce`を指定している場合は、テストを実行する前にこのフラグを取り除いてください。 -2. Run the node conformance test with command: +2. 以下のコマンドでノード適合テストを実行します: ```shell -# $CONFIG_DIR is the pod manifest path of your Kubelet. -# $LOG_DIR is the test output path. +# $CONFIG_DIRはKubeletのPodのマニフェストパスです。 +# $LOG_DIRはテスト出力のパスです。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ k8s.gcr.io/node-test:0.2 @@ -51,8 +44,7 @@ sudo docker run -it --rm --privileged --net=host \ ## 他アーキテクチャ向けのノード適合テストの実行 -Kubernetes also provides node conformance test docker images for other -architectures: +Kubernetesは他のアーキテクチャ用のノード適合テストのdockerイメージを提供しています: Arch | Image | --------|:-----------------:| @@ -62,37 +54,30 @@ architectures: ## 選択したテストの実行 -To run specific tests, overwrite the environment variable `FOCUS` with the -regular expression of tests you want to run. +特定のテストを実行するには、環境変数`FOCUS`を実行したいテストの正規表現で上書きします。 ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e FOCUS=MirrorPod \ # Only run MirrorPod test + -e FOCUS=MirrorPod \ # MirrorPodテストのみを実行します k8s.gcr.io/node-test:0.2 ``` -To skip specific tests, overwrite the environment variable `SKIP` with the -regular expression of tests you want to skip. +特定のテストをスキップするには、環境変数`SKIP`をスキップしたいテストの正規表現で上書きします。 ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test + -e SKIP=MirrorPod \ # MirrorPodテスト以外のすべてのノード適合テストを実行します k8s.gcr.io/node-test:0.2 ``` -Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). -By default, it runs all conformance tests. +ノード適合テストは、[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md)のコンテナ化されたバージョンです。 +デフォルトでは、すべての適合テストが実行されます。 -Theoretically, you can run any node e2e test if you configure the container and -mount required volumes properly. But **it is strongly recommended to only run conformance -test**, because it requires much more complex configuration to run non-conformance test. +理論的には、コンテナを構成し必要なボリュームを適切にマウントすれば、どのノードのe2eテストも実行できます。しかし、不適合テストを実行するためにはより複雑な設定が必要となるため、**適合テストのみを実行することを強く推奨します**。 ## 注意事項 -* The test leaves some docker images on the node, including the node conformance - test image and images of containers used in the functionality - test. -* The test leaves dead containers on the node. These containers are created - during the functionality test. +* このテストでは、ノード適合テストイメージや機能テストで使用されるコンテナのイメージなど、いくつかのdockerイメージがノード上に残ります。 +* このテストでは、ノード上にデッドコンテナが残ります。これらのコンテナは機能テスト中に作成されます。 From d7e48d226d4287a37401bb61394935ee2e753771 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Mon, 22 Jun 2020 14:30:10 +0900 Subject: [PATCH 050/119] change expression according to review --- content/ja/docs/setup/best-practices/node-conformance.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index 8e8af44cc4..0db9cb4432 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -27,8 +27,7 @@ Kubernetesのバージョン1.5ではノード適合テストには以下の制 ノード適合テストを実行するには、以下の手順に従います: 1. Kubeletをlocalhostに指定します(`--api-servers="http://localhost:8080"`)、 -なぜならテストフレームワークはKubeletをテストするためにローカルマスターを起動するからです。 -他にも配慮するべきKubeletフラグがいくつかあります: +このテストフレームワークはKubeletのテストにローカルマスターを起動するため、Kubeletをローカルホストに設定します(`--api-servers="http://localhost:8080"`)。他にも配慮するべきKubeletフラグがいくつかあります: * `--pod-cidr`: `kubenet`を利用している場合は、Kubeletに任意のCIDR(例: `--pod-cidr=10.180.0.0/24`)を指定する必要があります。 * `--cloud-provider`: `--cloud-provider=gce`を指定している場合は、テストを実行する前にこのフラグを取り除いてください。 From 0a110e49f0e1dadde0f435639cd1c95dff398107 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Mon, 22 Jun 2020 16:49:03 +0900 Subject: [PATCH 051/119] Update cloud-controller.md for v1.17 --- .../concepts/architecture/cloud-controller.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index d722ced7a6..24e443ace6 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -1,7 +1,7 @@ --- title: クラウドコントローラーマネージャーとそのコンセプト content_type: concept -weight: 30 +weight: 40 --- @@ -52,7 +52,7 @@ CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつ ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。 {{< /note >}} -CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、Flexボリュームを使うことでした。しかし、競合しているCSIとして知られている機能が、Flexを置き換える予定です。 +CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。 これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。 @@ -223,13 +223,18 @@ rules: 下記のクラウドプロバイダーがCCMを実装しています: -* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) * [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) * [Linode](https://github.com/linode/linode-cloud-controller-manager) +* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) +* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) + ## クラスター管理 From 8eedab253b663fd935c010d13c6962aaba3dac8f Mon Sep 17 00:00:00 2001 From: makocchi Date: Mon, 22 Jun 2020 19:43:20 +0900 Subject: [PATCH 052/119] Update content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md Co-authored-by: inductor(Kohei) --- .../extend-kubernetes/api-extension/custom-resources.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 066fbc483f..879280d522 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -147,7 +147,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | 機能 | 詳細 | CRD | アグリゲートAPI | | ---- | ---- | --- | --------------- | | バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 | -| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (しかしこの方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい | +| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (ただし、この方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい | | 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい | | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい | | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい | @@ -221,4 +221,3 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ * [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ - From 20599792a8d75e097ee9011d32af66de3edfa723 Mon Sep 17 00:00:00 2001 From: makocchi Date: Mon, 22 Jun 2020 19:43:39 +0900 Subject: [PATCH 053/119] Update content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md Co-authored-by: inductor(Kohei) --- .../extend-kubernetes/api-extension/custom-resources.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 879280d522..534fdb1dc3 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -152,7 +152,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい | | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい | | サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい | -| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際により詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | +| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | | その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい | | strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい | | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい | From 7ce33bc34c2d107c063a497b9e6055e16750dd54 Mon Sep 17 00:00:00 2001 From: makocchi Date: Mon, 22 Jun 2020 19:44:54 +0900 Subject: [PATCH 054/119] Update content/ja/docs/concepts/containers/runtime-class.md Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 43ad3402c2..cb604e064b 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -129,7 +129,7 @@ CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照 {{< feature-state for_k8s_version="v1.16" state="beta" >}} Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。 -このフィールドを使うことで、Podに設定されたRuntimeClassをサポートしているノードへPodがスケジュールされることを保証することができます。 +このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。 スケジューリングをサポートするためにはRuntimeClass [admission controller][]を有効にしなければなりません。（1.16ではデフォルトです） 特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。 From 396a23d0e5a4a7ce44515e0d7d7f29de3de45ac0 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 19:55:38 +0900 Subject: [PATCH 055/119] translate admission controller --- content/ja/docs/concepts/containers/runtime-class.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index cb604e064b..463eb1a15c 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -130,7 +130,7 @@ CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照 Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。 このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。 -スケジューリングをサポートするためにはRuntimeClass [admission controller][]を有効にしなければなりません。（1.16ではデフォルトです） +スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。（1.16ではデフォルトです） 特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。 RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。 @@ -141,7 +141,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。 -[admission controller]: /docs/reference/access-authn-authz/admission-controllers/ +[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/ ### Podオーバーヘッド From 998a483d989bc3071e6c40bea74218cafff5b186 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 20:04:00 +0900 Subject: [PATCH 056/119] revert translation --- .../docs/concepts/configuration/assign-pod-node.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 05dd0bcb36..b4747605e9 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -29,14 +29,14 @@ SSDが搭載されているノードにPodをデプロイしたり、同じア この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。 -### ステップ1: ノードへのラベルの付与 +### ステップ1: Nodeへのラベルの付与 -`kubectl get nodes`で、クラスターのノードの名前を取得してください。 -そして、ラベルを付与するノードを選び、`kubectl label nodes =`で選択したノードにラベルを付与します。 -例えば、ノードの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。 +`kubectl get nodes`で、クラスターのNodeの名前を取得してください。 +そして、ラベルを付与するNodeを選び、`kubectl label nodes =`で選択したNodeにラベルを付与します。 +例えば、Nodeの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。 -`kubectl get nodes --show-labels`によって、ノードにラベルが付与されたかを確認することができます。 -また、`kubectl describe node "nodename"`から、そのノードの全てのラベルを表示することもできます。 +`kubectl get nodes --show-labels`によって、Nodeにラベルが付与されたかを確認することができます。 +また、`kubectl describe node "nodename"`から、そのNodeの全てのラベルを表示することもできます。 ### ステップ2: PodへのnodeSelectorフィールドの追加 @@ -89,7 +89,7 @@ nodeSelectorを以下のように追加します: ノードにラベルを付与することで、Podは特定のノードやノードグループにスケジュールされます。 これにより、特定のPodを、確かな隔離性や安全性、特性を持ったノードで稼働させることができます。 この目的でラベルを使用する際に、ノード上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 -これは、安全性が損なわれたノードがkubeletの認証情報をノードのオブジェクトに設定したり、スケジューラーがそのようなノードにデプロイすることを防ぎます。 +これは、安全性が損なわれたノードがkubeletの認証情報をiノードのオブジェクトに設定したり、スケジューラーがそのようなノードにデプロイすることを防ぎます。 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 ノードの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 From fac39f3adf6854c180a7b647fc7b382d70b970b8 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 20:04:46 +0900 Subject: [PATCH 057/119] fix typo --- content/ja/docs/concepts/configuration/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index b4747605e9..2f12a937a2 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -89,7 +89,7 @@ nodeSelectorを以下のように追加します: ノードにラベルを付与することで、Podは特定のノードやノードグループにスケジュールされます。 これにより、特定のPodを、確かな隔離性や安全性、特性を持ったノードで稼働させることができます。 この目的でラベルを使用する際に、ノード上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 -これは、安全性が損なわれたノードがkubeletの認証情報をiノードのオブジェクトに設定したり、スケジューラーがそのようなノードにデプロイすることを防ぎます。 +これは、安全性が損なわれたノードがkubeletの認証情報をノードのオブジェクトに設定したり、スケジューラーがそのようなノードにデプロイすることを防ぎます。 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 ノードの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 From 2defadb1eb3e12a308c4822c57bacf06769d7014 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 20:27:28 +0900 Subject: [PATCH 058/119] revert translation --- .../concepts/configuration/assign-pod-node.md | 154 +++++++++--------- 1 file changed, 77 insertions(+), 77 deletions(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 2f12a937a2..ecf908ddf1 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -1,5 +1,5 @@ --- -title: ノード上へのPodのスケジューリング +title: Node上へのPodのスケジューリング content_type: concept weight: 30 --- @@ -7,10 +7,10 @@ weight: 30 -{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="ノード" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node(s)" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 -スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のノードへデプロイしたり、Podを配置する際にリソースが不十分なノードにはデプロイされないことが挙げられます)が、 -SSDが搭載されているノードにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じノードにデプロイする等、柔軟な制御が必要なこともあります。 +スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 +SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 @@ -18,9 +18,9 @@ SSDが搭載されているノードにPodをデプロイしたり、同じア ## nodeSelector -`nodeSelector`は、ノードを選択するための、最も簡単で推奨されている手法です。 +`nodeSelector`は、Nodeを選択するための、最も簡単で推奨されている手法です。 `nodeSelector`はPodSpecのフィールドです。これはkey-valueペアのマップを特定します。 -あるノードでPodを稼働させるためには、そのノードがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。 +あるNodeでPodを稼働させるためには、そのNodeがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。 最も一般的な使用方法は、1つのkey-valueペアを付与する方法です。 以下に、`nodeSelector`の使用例を紹介します。 @@ -60,12 +60,12 @@ nodeSelectorを以下のように追加します: {{< codenew file="pods/pod-nginx.yaml" >}} -`kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したノードへスケジュールされます。 -`kubectl get pods -o wide`で表示される"NODE"の列から、Podがデプロイされているノードを確認することができます。 +`kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。 +`kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。 -## 補足: ビルトインノードラベル {#built-in-node-labels} +## 補足: ビルトインNodeラベル {#built-in-node-labels} -明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にノードへ付与されているものもあります。 +明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 以下のようなラベルが該当します。 * [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) @@ -80,103 +80,103 @@ nodeSelectorを以下のように追加します: {{< note >}} これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 -例えば、`kubernetes.io/hostname`の値はノードの名前と同じである環境もあれば、異なる環境もあります。 +例えば、`kubernetes.io/hostname`の値はNodeの名前と同じである環境もあれば、異なる環境もあります。 {{< /note >}} -## ノードの隔離や制限 +## Nodeの隔離や制限 -ノードにラベルを付与することで、Podは特定のノードやノードグループにスケジュールされます。 -これにより、特定のPodを、確かな隔離性や安全性、特性を持ったノードで稼働させることができます。 -この目的でラベルを使用する際に、ノード上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 -これは、安全性が損なわれたノードがkubeletの認証情報をノードのオブジェクトに設定したり、スケジューラーがそのようなノードにデプロイすることを防ぎます。 +Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。 +これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。 +この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 +これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 -ノードの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 +Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。 -2. ノードに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 +2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 ## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} -`nodeSelector`はPodの稼働を特定のラベルが付与されたノードに制限する最も簡単な方法です。 +`nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。 アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。 拡張機能は以下の通りです。 1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。 2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。 -3. ノード自体のラベルではなく、ノード(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。 +3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。 -アフィニティは"ノードアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。 -ノードアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、ノードのラベルではなくPodのラベルに対して制限をかけます。 +アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。 +Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 -### ノードアフィニティ +### Nodeアフィニティ -ノードアフィニティはα機能としてKubernetesのv1.2から導入されました。 -ノードアフィニティは概念的には、ノードのラベルによってPodがどのノードにスケジュールされるかを制限する`nodeSelector`と同様です。 +Nodeアフィニティはα機能としてKubernetesのv1.2から導入されました。 +Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 -現在は2種類のノードアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 -前者はノードにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 -"IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、ノードのラベルが変更され、Podがその条件を満たさなくなった場合でも -Podはそのノードで稼働し続けるということです。 -将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、Podのノードアフィニティに記された必須要件を満たさなくなったノードからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 +現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 +前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 +"IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも +PodはそのNodeで稼働し続けるということです。 +将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 それぞれの使用例として、 -`requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたノード上でPodを稼働させる"、 +`requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、 `preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる" といった方法が挙げられます。 -ノードアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 +Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 -ノードアフィニティを使用したPodの例を以下に示します: +Nodeアフィニティを使用したPodの例を以下に示します: {{< codenew file="pods/pod-with-node-affinity.yaml" >}} -このノードアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたノードにしか配置されません。 -加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたノードが優先されます。 +このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 +加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。 この例ではオペレーター`In`が使われています。 -ノードアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 -`NotIn`と`DoesNotExist`はノードアンチアフィニティ、またはPodを特定のノードにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 +Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 +`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 -`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすノードにスケジュールされます。 +`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。 -`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたノードへスケジュールされます。 +`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 -`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたノードへスケジュールされます。 +`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたNodeへスケジュールされます。 -Podがスケジュールされたノードのラベルを削除したり変更しても、Podは削除されません。 +PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。 言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。 `preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。 -全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたノードに対して、スケジューラーはそのノードがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 -このスコアがノードの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したノードが優先されます。 +全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 +このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。 ### Pod間アフィニティとアンチアフィニティ -Pod間アフィニティとアンチアフィニティは、ノードのラベルではなく、すでにノードで稼働しているPodのラベルに従ってPodがスケジュールされるノードを制限します。 +Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。 Yはnamespaceのリストで指定したLabelSelectorで表されます。 -ノードと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 -概念的に、Xはノードや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 -これらを表すためにシステムが使用するノードラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 -先述のセクション[補足: ビルトインノードラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 +Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 +概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 +これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 +先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 {{< note >}} Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 -そのため、数百台以上のノードから成るクラスターでは使用することを推奨されません。 +そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。 {{< /note >}} {{< note >}} -Podのアンチアフィニティは、ノードに必ずラベルが付与されている必要があります。 -言い換えると、クラスターの全てのノードが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 -それらが付与されていないノードが存在する場合、意図しない挙動を示すことがあります。 +Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。 +言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 +それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。 {{< /note >}} -ノードアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 -前述のノードアフィニティのセクションを参照してください。 +Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 +前述のNodeアフィニティのセクションを参照してください。 `requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 @@ -188,10 +188,10 @@ Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffin このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 -Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているノードが同じゾーンにあれば、Podはそのノードにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるノードが少なくとも1つはある状態で、 -ノードNがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはノードNで稼働させることができます)。 -Podアンチアフィニティは、「すでにあるノード上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのノード上で稼働させない」という条件を指定しています -(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のノードにはスケジュールされなくなります)。 +Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、Podはそのノードにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるノードが少なくとも1つはある状態で、 +NodeNがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはノードNで稼働させることができます)。 +Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのノード上で稼働させない」という条件を指定しています +(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 @@ -208,22 +208,22 @@ PodアフィニティとPodアンチアフィニティで使用できるオペ `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。 省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。 -`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるノードにPodがスケジュールされます。 +`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 #### 実際的なユースケース Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。 -Workloadが、ノード等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 +Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 -##### 常に同じノードで稼働させる場合 +##### 常に同じNodeで稼働させる場合 -３つのノードから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。 +３つのNodeから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。 このような場合、ウェブサーバーは可能な限りキャッシュと共存させることが望ましいです。 ラベル`app=store`を付与した3つのレプリカから成るredisのdeploymentを記述したyamlファイルを示します。 -Deploymentには、1つのノードにレプリカを共存させないために`PodAntiAffinity`を付与しています。 +Deploymentには、1つのNodeにレプリカを共存させないために`PodAntiAffinity`を付与しています。 ```yaml @@ -258,7 +258,7 @@ spec: ウェブサーバーのDeploymentを記載した以下のyamlファイルには、`podAntiAffinity` と`podAffinity`が設定されています。 全てのレプリカが`app=store`のラベルが付与されたPodと同じゾーンで稼働するよう、スケジューラーに設定されます。 -また、それぞれのウェブサーバーは1つのノードで稼働されないことも保証されます。 +また、それぞれのウェブサーバーは1つのNodeで稼働されないことも保証されます。 ```yaml @@ -300,7 +300,7 @@ spec: image: nginx:1.16-alpine ``` -上記2つのDeploymentが生成されると、3つのノードは以下のようになります。 +上記2つのDeploymentが生成されると、3つのNodeは以下のようになります。 | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -323,7 +323,7 @@ web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4 web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2 ``` -##### 同じノードに共存させない場合 +##### 同じNodeに共存させない場合 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。 同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 @@ -331,16 +331,16 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 ## nodeName -`nodeName`はノードの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。 +`nodeName`はNodeの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。 `nodeName`はPodSpecのフィールドです。 -ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているノードのkubeletはPodを稼働させようとします。 -そのため、PodSpecに`nodeName`が指定されると、上述のノードの選択方法よりも優先されます。 +ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているNodeのkubeletはPodを稼働させようとします。 +そのため、PodSpecに`nodeName`が指定されると、上述のNodeの選択方法よりも優先されます。 `nodeName`を使用することによる制約は以下の通りです: -- その名前のノードが存在しない場合、Podは起動されす、自動的に削除される場合があります。 -- その名前のノードにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 -- クラウド上のノードの名前は予期できず、変更される可能性があります。 +- その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。 +- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 +- クラウド上のNodeの名前は予期できず、変更される可能性があります。 `nodeName`を指定したPodの設定ファイルの例を示します: @@ -356,18 +356,18 @@ spec: nodeName: kube-01 ``` -上記のPodはkube-01という名前のノードで稼働します。 +上記のPodはkube-01という名前のNodeで稼働します。 ## {{% heading "whatsnext" %}} -[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、ノードはPodを追い出すことができます。 +[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。 -[ノードアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と +[Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と [Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。 -一度Podがノードに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。 -[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はノードレベルのリソース割り当てを決定する際に関与します。 +一度PodがNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。 +[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。 From 54744a2e129f30f528c3b54da375f662800d8fd0 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 20:32:58 +0900 Subject: [PATCH 059/119] revert translation 2 --- .../docs/concepts/configuration/assign-pod-node.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index ecf908ddf1..95e2be1874 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -20,7 +20,7 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ `nodeSelector`は、Nodeを選択するための、最も簡単で推奨されている手法です。 `nodeSelector`はPodSpecのフィールドです。これはkey-valueペアのマップを特定します。 -あるNodeでPodを稼働させるためには、そのNodeがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。 +あるノードでPodを稼働させるためには、そのノードがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。 最も一般的な使用方法は、1つのkey-valueペアを付与する方法です。 以下に、`nodeSelector`の使用例を紹介します。 @@ -31,11 +31,11 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ ### ステップ1: Nodeへのラベルの付与 -`kubectl get nodes`で、クラスターのNodeの名前を取得してください。 +`kubectl get nodes`で、クラスターのノードの名前を取得してください。 そして、ラベルを付与するNodeを選び、`kubectl label nodes =`で選択したNodeにラベルを付与します。 例えば、Nodeの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。 -`kubectl get nodes --show-labels`によって、Nodeにラベルが付与されたかを確認することができます。 +`kubectl get nodes --show-labels`によって、ノードにラベルが付与されたかを確認することができます。 また、`kubectl describe node "nodename"`から、そのNodeの全てのラベルを表示することもできます。 ### ステップ2: PodへのnodeSelectorフィールドの追加 @@ -219,7 +219,7 @@ Workloadが、Node等の定義された同じトポロジーに共存させる ##### 常に同じNodeで稼働させる場合 -３つのNodeから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。 +３つのノードから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。 このような場合、ウェブサーバーは可能な限りキャッシュと共存させることが望ましいです。 ラベル`app=store`を付与した3つのレプリカから成るredisのdeploymentを記述したyamlファイルを示します。 @@ -258,7 +258,7 @@ spec: ウェブサーバーのDeploymentを記載した以下のyamlファイルには、`podAntiAffinity` と`podAffinity`が設定されています。 全てのレプリカが`app=store`のラベルが付与されたPodと同じゾーンで稼働するよう、スケジューラーに設定されます。 -また、それぞれのウェブサーバーは1つのNodeで稼働されないことも保証されます。 +また、それぞれのウェブサーバーは1つのノードで稼働されないことも保証されます。 ```yaml @@ -300,7 +300,7 @@ spec: image: nginx:1.16-alpine ``` -上記2つのDeploymentが生成されると、3つのNodeは以下のようになります。 +上記2つのDeploymentが生成されると、3つのノードは以下のようになります。 | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| From 9f5934181568a0f32f9028a2521939a82912b185 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 20:35:41 +0900 Subject: [PATCH 060/119] revert translation 3 --- content/ja/docs/concepts/configuration/assign-pod-node.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 95e2be1874..f5f07d8690 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -189,8 +189,8 @@ Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffin このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、Podはそのノードにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるノードが少なくとも1つはある状態で、 -NodeNがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはノードNで稼働させることができます)。 -Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのノード上で稼働させない」という条件を指定しています +Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。 +Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています (`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 From fede6aad5564313dc246dd6b24c24dd07fce8954 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 20:38:36 +0900 Subject: [PATCH 061/119] revert translation 4 --- content/ja/docs/concepts/configuration/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index f5f07d8690..cc6f33542a 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -188,7 +188,7 @@ Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffin このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 -Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、Podはそのノードにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるノードが少なくとも1つはある状態で、 +Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。 Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています (`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 From e136bc34eca274011245483fe770f2498caef407 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 22 Jun 2020 20:40:54 +0900 Subject: [PATCH 062/119] revert blank line --- content/ja/docs/concepts/configuration/assign-pod-node.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index cc6f33542a..93461a9bfe 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -85,7 +85,6 @@ nodeSelectorを以下のように追加します: ## Nodeの隔離や制限 - Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。 これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。 この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 From 9d1cb8445c54aa622d704e144d45bc4036389e81 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Tue, 23 Jun 2020 01:27:54 +0900 Subject: [PATCH 063/119] Update content/ja/docs/concepts/configuration/assign-pod-node.md --- content/ja/docs/concepts/configuration/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 93461a9bfe..e8057f54aa 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -7,7 +7,7 @@ weight: 30 -{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node(s)" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 From e80821d3c48e5f04a2ecfbaa1b3a8ad3c36142e4 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Tue, 23 Jun 2020 12:14:07 +0900 Subject: [PATCH 064/119] update container-runtimes.md --- .../container-runtimes.md | 278 +++++++++++++----- 1 file changed, 208 insertions(+), 70 deletions(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index a9604a7b59..2eebe5c7ce 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -18,8 +18,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、 コンテナホストシステム上で任意のコマンドを実行する可能性があります。 -この問題の更なる情報は以下のリンクを参照してください。 -[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736) +詳細は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。 {{< /caution >}} ### 適用性 @@ -53,34 +52,45 @@ kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されてい ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。 +バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{% tab name="Ubuntu 16.04+" %}} + +```shell # Docker CEのインストール ## リポジトリをセットアップ -### aptパッケージインデックスを更新 - apt-get update - ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール - apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common +apt-get update && apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 +``` -### Docker公式のGPG鍵を追加 - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +```shell +# Docker公式のGPG鍵を追加 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### dockerのaptリポジトリを追加 - add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" +```shell +# dockerのaptリポジトリを追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" +``` -## docker ceのインストール -apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu +```shell +# docker ceのインストール +apt-get update && apt-get install -y \ + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) +``` -# デーモンをセットアップ +```shell +# Dockerデーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{% tab name="CentOS/RHEL 7.4+" %}} +```shell # Docker CEのインストール ## リポジトリをセットアップ ### 必要なパッケージのインストール - yum install yum-utils device-mapper-persistent-data lvm2 +yum install -y yum-utils device-mapper-persistent-data lvm2 +``` -### dockerパッケージ用のyumリポジトリを追加 -yum-config-manager \ - --add-repo \ - https://download.docker.com/linux/centos/docker-ce.repo +```shell +### Dockerリポジトリを追加 +yum-config-manager --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo +``` -## docker ceのインストール -yum update && yum install docker-ce-18.06.2.ce +```shell +# Docker CEのインストール +yum update -y && yum install -y \ + containerd.io-1.2.13 \ + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 +``` +```shell ## /etc/docker ディレクトリを作成 mkdir /etc/docker +``` -# デーモンをセットアップ +```shell +# Dockerデーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} {{< /tabs >}} +ブート時にdockerサービスを起動したい場合は、以下のコマンドを実行してください。 + +```shell +sudo systemctl enable docker +``` + 詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。 ## CRI-O @@ -164,37 +201,85 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{% tab name="Debian" %}} -# 必要なパッケージをインストールし、リポジトリを追加 -apt-get update -apt-get install software-properties-common +```shell +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` -add-apt-repository ppa:projectatomic/ppa -apt-get update +```shell +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - +``` +```shell +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` + +```shell +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` + +その後CRI-Oをインストール +```shell +sudo apt-get install cri-o-1.17 +``` +{{% /tab %}} + +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} + +```shell +# パッケージリポジトリの設定 +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update +``` + +```shell # CRI-Oをインストール -apt-get install cri-o-1.11 +sudo apt-get install cri-o-1.17 +``` +{{% /tab %}} -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{% tab name="CentOS/RHEL 7.4+" %}} -# 必要なリポジトリを追加 -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ +```shell +# 事前に必要なものをインストール +# Install prerequisites +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo +``` +```shell # CRI-Oをインストール -yum install --nogpgcheck cri-o +yum install -y cri-o +``` +{{% /tab %}} -{{< /tab >}} +{{% tab name="openSUSE Tumbleweed" %}} + +```shell +sudo zypper install cri-o +``` +{{% /tab %}} {{< /tabs >}} ### CRI-Oの起動 ``` +systemctl daemon-reload systemctl start crio ``` -詳細については、[CRI-Oインストールガイド](https://github.com/kubernetes-sigs/cri-o#getting-started)を参照してください。 +詳細については、[CRI-Oインストールガイド]((https://github.com/kubernetes-sigs/cri-o#getting-started)を参照してください。 ## Containerd @@ -202,9 +287,14 @@ systemctl start crio システムへContainerdをインストールするためには次のコマンドを実行します。 -### 必要な設定の追加 +### 事前準備 ```shell +cat > /etc/modules-load.d/containerd.conf <}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -apt-get install -y libseccomp2 -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -yum install -y libseccomp -{{< /tab >}} -{{< /tabs >}} - ### containerdのインストール -[Containerdは定期的にリリース](https://github.com/containerd/containerd/releases)されますが、以下に示すコマンドで利用している値は、この手順が作成された時点での最新のバージョンにしたがって書かれています。より新しいバージョンとダウンロードするファイルのハッシュ値については[こちら](https://storage.googleapis.com/cri-containerd-release)で確認するようにしてください。 +{{< tabs name="tab-cri-containerd-installation" >}} +{{% tab name="Ubuntu 16.04" %}} ```shell -# 必要な環境変数をexportします。 -export CONTAINERD_VERSION="1.1.2" -export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218" - -# containerdのtarボールをダウンロードします。 -wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# ハッシュ値をチェックします。 -echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check - - -# 解凍して展開します。 -tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# containerdを起動します。 -systemctl start containerd +# containerdのインストール +## リポジトリの設定 +### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール +apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common ``` +```shell +# Docker公式のGPG鍵を追加 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` + +```shell +## Dockerのaptリポジトリを追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" +``` + +```shell +## containerdのインストール +apt-get update && apt-get install -y containerd.io +``` + +```shell +# containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml +``` + +```shell +# containerdの再起動 +systemctl restart containerd +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell +# containerdのインストール +## リポジトリの設定 +### 必要なパッケージのインストール +yum install -y yum-utils device-mapper-persistent-data lvm2 +``` + +```shell +## Dockerリポジトリを追加 +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo +``` + +```shell +## containerdのインストール +yum update -y && yum install -y containerd.io +``` + +```shell +## containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml +``` + +```shell +# Restart containerd +systemctl restart containerd +``` +{{% /tab %}} +{{< /tabs >}} + +### systemd + +`systemd`のcgroupドライバーを使うには、`/etc/containerd/config.toml`内で`plugins.cri.systemd_cgroup = true`を設定してください。 +kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)を手動で設定してください。 + ## その他のCRIランタイム: frakti 詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。 - From 1579e3abe93470349bd127836419f1a855fc547d Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 13:45:30 +0900 Subject: [PATCH 065/119] Update nodes.md for v1.17 --- .../ja/docs/concepts/architecture/nodes.md | 46 ++++++++++++------- 1 file changed, 30 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index d5631319a7..88c3962085 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -43,7 +43,6 @@ kubectl describe node <ノード名> | ノードのCondition | 概要 | |----------------|-------------| -| `OutOfDisk` | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 | | `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | | `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | | `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | @@ -69,18 +68,9 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても` バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 -バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。 -同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。 +ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 -ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。 -上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。 - -{{< caution >}} - -この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。 -この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。 - -{{< /caution >}} +スケジューラーがPodをノードにアサインする際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 ### CapacityとAllocatable {#capacity} @@ -91,7 +81,7 @@ allocatableブロックは、通常のPodによって消費されるノード上 CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。 -### Info +### Info {#info} カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。 この情報はノードからkubeletを通じて取得されます。 @@ -114,6 +104,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で ``` Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。 +Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 {{< note >}} Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。 @@ -136,9 +127,19 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。 ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。 -バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。 +#### ハートビート +ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。 +２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。 +各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。 +Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。 + +kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。 + +- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです） +- Kubeletは10秒間隔（デフォルトの更新間隔）でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限としたエクスポネンシャル・バックオフでリトライします。 + +#### 信頼性 -NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。 Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため） バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。 @@ -201,6 +202,11 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。 {{< /note >}} +{{< caution >}} +`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという +サービスコントローラーの副次的な効果をもたらします。これにより、ロードバランサトラフィックの流入をcordonされたノードから効率的に除去する事ができます。 +{{< /caution >}} + ### ノードのキャパシティ ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。 @@ -213,10 +219,18 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。 +## ノードのトポロジー + +{{< feature-state state="alpha" >}} +`TopologyManager`の[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 +kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 ## APIオブジェクト NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます: [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). - +{{% capture whatsnext %}} +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#ノードコンポーネント)について読む。 +* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) +{{% /capture %}} From cb9025d84cbf4e30b223097071cdaed030dfb2c7 Mon Sep 17 00:00:00 2001 From: makocchi Date: Tue, 23 Jun 2020 19:19:26 +0900 Subject: [PATCH 066/119] Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/configuration/assign-pod-node.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index e8057f54aa..9c08d1fb9a 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -112,7 +112,6 @@ Nodeアフィニティは`nodeSelector`(前述の2つのメリットがありま ### Nodeアフィニティ -Nodeアフィニティはα機能としてKubernetesのv1.2から導入されました。 Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 From 09e8662e3358e7276ea60a50995e228a0af3616e Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 19:47:34 +0900 Subject: [PATCH 067/119] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 88c3962085..01893b2571 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -70,7 +70,7 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても` ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 -スケジューラーがPodをノードにアサインする際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 +スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 ### CapacityとAllocatable {#capacity} @@ -233,4 +233,3 @@ NodeはKubernetesのREST APIにおけるトップレベルのリソースです * [ノードコンポーネント](/ja/docs/concepts/overview/components/#ノードコンポーネント)について読む。 * ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) {{% /capture %}} - From 2e163f0a7a4418e44f555d4215b6ef9ac94bcaa7 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 19:47:54 +0900 Subject: [PATCH 068/119] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 01893b2571..319844e639 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -222,7 +222,7 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合 ## ノードのトポロジー {{< feature-state state="alpha" >}} -`TopologyManager`の[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 +`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 ## APIオブジェクト From 8b2e92af23e12ab177217b9f4e7e604cb84e1d78 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 19:48:21 +0900 Subject: [PATCH 069/119] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 319844e639..1e4f7d1e1d 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -230,6 +230,6 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます: [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). {{% capture whatsnext %}} -* [ノードコンポーネント](/ja/docs/concepts/overview/components/#ノードコンポーネント)について読む。 +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。 * ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) {{% /capture %}} From 125b3b36cb4a9d3cfa42e2e433825607c5b2ee37 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 21:34:43 +0900 Subject: [PATCH 070/119] update components.md - add index --- content/ja/docs/concepts/overview/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 43e839d19c..c805565665 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -67,7 +67,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 -## ノードコンポーネント +## ノードコンポーネント {#node-components} ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 From 3ea319696299bf241f0f0506603911bb2a4f4ad5 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Wed, 24 Jun 2020 10:15:57 +0900 Subject: [PATCH 071/119] add space --- 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 fc3fb0efb3..1a937abee0 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -27,7 +27,7 @@ weight: 10 - よりよいイントロスペクションのために、オブジェクトの説明をアノテーションに入れましょう。 -## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob{#naked-pods-vs-replicasets-deployments-and-jobs} +## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob {#naked-pods-vs-replicasets-deployments-and-jobs} - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。 From 99c730de3fab402d23bca952db1e52ba37f1bbcc Mon Sep 17 00:00:00 2001 From: mochizuki-pg Date: Wed, 24 Jun 2020 11:35:50 +0900 Subject: [PATCH 072/119] Change the text from Kubernetes to Cluster --- content/ja/docs/concepts/architecture/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/_index.md b/content/ja/docs/concepts/architecture/_index.md index d81eeab89c..b8906ee100 100644 --- a/content/ja/docs/concepts/architecture/_index.md +++ b/content/ja/docs/concepts/architecture/_index.md @@ -1,4 +1,4 @@ --- -title: "Kubernetesのアーキテクチャ" +title: "クラスターのアーキテクチャ" weight: 30 --- From ff95d5c2bb19037c452378dba824592e856e10ac Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Wed, 24 Jun 2020 12:15:29 +0900 Subject: [PATCH 073/119] update _index.md and kubernetes-objects.md --- content/ja/docs/concepts/_index.md | 2 +- .../overview/working-with-objects/kubernetes-objects.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 0f03287083..49a3ffd8a7 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -26,7 +26,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使 ## Kubernetesオブジェクト -Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。 +Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)をご覧ください。 基本的なKubernetesのオブジェクトは次のとおりです。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 16d1bdd27a..3b2fbaa32a 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -12,7 +12,7 @@ card: -## Kubernetesオブジェクトを理解する +## Kubernetesオブジェクトを理解する {#kubernetes-objects} *Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます: From 960f342effb7e83a4514a9d7a43d2bbdaf6112e9 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Wed, 24 Jun 2020 17:24:33 +0900 Subject: [PATCH 074/119] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 1e4f7d1e1d..f4c914e003 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -136,7 +136,7 @@ Leaseは軽量なリソースで、クラスターのスケールに応じてノ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。 - kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです） -- Kubeletは10秒間隔（デフォルトの更新間隔）でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限としたエクスポネンシャル・バックオフでリトライします。 +- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。 #### 信頼性 From 59664b886168601aab4ef6c26eefb12d69f46731 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Wed, 24 Jun 2020 19:24:05 +0900 Subject: [PATCH 075/119] Revert "update container-runtimes.md" This reverts commit e80821d3c48e5f04a2ecfbaa1b3a8ad3c36142e4. --- .../container-runtimes.md | 280 +++++------------- 1 file changed, 71 insertions(+), 209 deletions(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index 2eebe5c7ce..a9604a7b59 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -18,7 +18,8 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、 コンテナホストシステム上で任意のコマンドを実行する可能性があります。 -詳細は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。 +この問題の更なる情報は以下のリンクを参照してください。 +[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736) {{< /caution >}} ### 適用性 @@ -52,45 +53,34 @@ kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されてい ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 +バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 {{< tabs name="tab-cri-docker-installation" >}} -{{% tab name="Ubuntu 16.04+" %}} - -```shell +{{< tab name="Ubuntu 16.04" codelang="bash" >}} # Docker CEのインストール ## リポジトリをセットアップ +### aptパッケージインデックスを更新 + apt-get update + ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール -apt-get update && apt-get install -y \ - apt-transport-https ca-certificates curl software-properties-common gnupg2 -``` + apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common -```shell -# Docker公式のGPG鍵を追加 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -``` +### Docker公式のGPG鍵を追加 + curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -```shell -# dockerのaptリポジトリを追加 -add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" -``` +### dockerのaptリポジトリを追加 + add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" -```shell -# docker ceのインストール -apt-get update && apt-get install -y \ - containerd.io=1.2.13-2 \ - docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) -``` +## docker ceのインストール +apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu -```shell -# Dockerデーモンをセットアップ +# デーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} -{{% tab name="CentOS/RHEL 7.4+" %}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -```shell # Docker CEのインストール ## リポジトリをセットアップ ### 必要なパッケージのインストール -yum install -y yum-utils device-mapper-persistent-data lvm2 -``` + yum install yum-utils device-mapper-persistent-data lvm2 -```shell -### Dockerリポジトリを追加 -yum-config-manager --add-repo \ - https://download.docker.com/linux/centos/docker-ce.repo -``` +### dockerパッケージ用のyumリポジトリを追加 +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo -```shell -# Docker CEのインストール -yum update -y && yum install -y \ - containerd.io-1.2.13 \ - docker-ce-19.03.11 \ - docker-ce-cli-19.03.11 -``` +## docker ceのインストール +yum update && yum install docker-ce-18.06.2.ce -```shell ## /etc/docker ディレクトリを作成 mkdir /etc/docker -``` -```shell -# Dockerデーモンをセットアップ +# デーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} {{< /tabs >}} -ブート時にdockerサービスを起動したい場合は、以下のコマンドを実行してください。 - -```shell -sudo systemctl enable docker -``` - 詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。 ## CRI-O @@ -201,85 +164,37 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{% tab name="Debian" %}} +{{< tab name="Ubuntu 16.04" codelang="bash" >}} -```shell -# Debian Unstable/Sid -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - -``` +# 必要なパッケージをインストールし、リポジトリを追加 +apt-get update +apt-get install software-properties-common -```shell -# Debian Testing -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - -``` +add-apt-repository ppa:projectatomic/ppa +apt-get update -```shell -# Debian 10 -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - -``` - -```shell -# Raspbian 10 -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - -``` - -その後CRI-Oをインストール -```shell -sudo apt-get install cri-o-1.17 -``` -{{% /tab %}} - -{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} - -```shell -# パッケージリポジトリの設定 -. /etc/os-release -sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - -sudo apt-get update -``` - -```shell # CRI-Oをインストール -sudo apt-get install cri-o-1.17 -``` -{{% /tab %}} +apt-get install cri-o-1.11 -{{% tab name="CentOS/RHEL 7.4+" %}} +{{< /tab >}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -```shell -# 事前に必要なものをインストール -# Install prerequisites -curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo -curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo -``` +# 必要なリポジトリを追加 +yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ -```shell # CRI-Oをインストール -yum install -y cri-o -``` -{{% /tab %}} +yum install --nogpgcheck cri-o -{{% tab name="openSUSE Tumbleweed" %}} - -```shell -sudo zypper install cri-o -``` -{{% /tab %}} +{{< /tab >}} {{< /tabs >}} ### CRI-Oの起動 ``` -systemctl daemon-reload systemctl start crio ``` -詳細については、[CRI-Oインストールガイド]((https://github.com/kubernetes-sigs/cri-o#getting-started)を参照してください。 +詳細については、[CRI-Oインストールガイド](https://github.com/kubernetes-sigs/cri-o#getting-started)を参照してください。 ## Containerd @@ -287,14 +202,9 @@ systemctl start crio システムへContainerdをインストールするためには次のコマンドを実行します。 -### 事前準備 +### 必要な設定の追加 ```shell -cat > /etc/modules-load.d/containerd.conf <}} -{{% tab name="Ubuntu 16.04" %}} - -```shell -# containerdのインストール -## リポジトリの設定 -### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール -apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common -``` - -```shell -# Docker公式のGPG鍵を追加 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -``` - -```shell -## Dockerのaptリポジトリを追加 -add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" -``` - -```shell -## containerdのインストール -apt-get update && apt-get install -y containerd.io -``` - -```shell -# containerdの設定 -mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml -``` - -```shell -# containerdの再起動 -systemctl restart containerd -``` -{{% /tab %}} -{{% tab name="CentOS/RHEL 7.4+" %}} - -```shell -# containerdのインストール -## リポジトリの設定 -### 必要なパッケージのインストール -yum install -y yum-utils device-mapper-persistent-data lvm2 -``` - -```shell -## Dockerリポジトリを追加 -yum-config-manager \ - --add-repo \ - https://download.docker.com/linux/centos/docker-ce.repo -``` - -```shell -## containerdのインストール -yum update -y && yum install -y containerd.io -``` - -```shell -## containerdの設定 -mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml -``` - -```shell -# Restart containerd -systemctl restart containerd -``` -{{% /tab %}} +{{< tab name="Ubuntu 16.04+" codelang="bash" >}} +apt-get install -y libseccomp2 +{{< /tab >}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +yum install -y libseccomp +{{< /tab >}} {{< /tabs >}} -### systemd +### containerdのインストール -`systemd`のcgroupドライバーを使うには、`/etc/containerd/config.toml`内で`plugins.cri.systemd_cgroup = true`を設定してください。 -kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)を手動で設定してください。 +[Containerdは定期的にリリース](https://github.com/containerd/containerd/releases)されますが、以下に示すコマンドで利用している値は、この手順が作成された時点での最新のバージョンにしたがって書かれています。より新しいバージョンとダウンロードするファイルのハッシュ値については[こちら](https://storage.googleapis.com/cri-containerd-release)で確認するようにしてください。 + +```shell +# 必要な環境変数をexportします。 +export CONTAINERD_VERSION="1.1.2" +export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218" + +# containerdのtarボールをダウンロードします。 +wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz + +# ハッシュ値をチェックします。 +echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check - + +# 解凍して展開します。 +tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz + +# containerdを起動します。 +systemctl start containerd +``` ## その他のCRIランタイム: frakti 詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。 + From 9bc2a924df8bc6106dd38f7a4d848acf61c7f892 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Wed, 24 Jun 2020 20:04:18 +0900 Subject: [PATCH 076/119] follow 1.17 doc --- .../container-runtimes.md | 186 ++++++++++++------ 1 file changed, 127 insertions(+), 59 deletions(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index a9604a7b59..b91a8f4fc2 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -3,14 +3,14 @@ title: CRIのインストール content_type: concept weight: 10 --- - +{{% capture overview %}} {{< feature-state for_k8s_version="v1.6" state="stable" >}} Podのコンテナを実行するために、Kubernetesはコンテナランタイムを使用します。 様々なランタイムのインストール手順は次のとおりです。 +{{% /capture %}} - - +{{% capture body %}} {{< caution >}} @@ -47,9 +47,16 @@ systemdと一緒に `cgroupfs` を使用するということは、2つの異な kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されている残りのプロセスに `systemd` を使用するように設定されたノードが、 リソース圧迫下で不安定になる場合があります。 -あなたのコンテナランタイムとkubeletにcgroupドライバーとしてsystemdを使用するように設定を変更することはシステムを安定させました。 +コンテナランタイムとkubeletがcgroupドライバーとしてsystemdを使用するように設定を変更することでシステムは安定します。 以下のDocker設定の `native.cgroupdriver=systemd` オプションに注意してください。 +{{< caution >}} +すでにクラスターに組み込まれているノードのcgroupドライバーを変更することは非常におすすめしません。 +kubeletが一方のcgroupドライバーを使用してPodを作成した場合、コンテナランタイムを別のもう一方のcgroupドライバーに変更すると、そのような既存のPodのPodサンドボックスを再作成しようとするとエラーが発生する可能性があります。 +kubeletを再起動しても問題は解決しないでしょう。 +ワークロードからノードを縮退させ、クラスターから削除して再び組み込むことを推奨します。 +{{< /caution >}} + ## Docker それぞれのマシンに対してDockerをインストールします。 @@ -62,23 +69,24 @@ Kubernetesのリリースノートにある、Dockerの動作確認済み最新 {{< tab name="Ubuntu 16.04" codelang="bash" >}} # Docker CEのインストール ## リポジトリをセットアップ -### aptパッケージインデックスを更新 - apt-get update - ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール - apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common +apt-get update && apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 ### Docker公式のGPG鍵を追加 - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -### dockerのaptリポジトリを追加 - add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" +### Dockerのaptリポジトリを追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" -## docker ceのインストール -apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu +## Docker CEのインストール +apt-get update && apt-get install -y \ + containerd.io=1.2.10-3 \ + docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) # デーモンをセットアップ cat > /etc/docker/daemon.json <}} +CRI-OのメジャーとマイナーバージョンはKubernetesのメジャーとマイナーバージョンと一致しなければなりません。 +詳細は[CRI-O互換性表](https://github.com/cri-o/cri-o)を参照してください。 +{{< /note >}} + +### 事前準備 ```shell modprobe overlay @@ -164,33 +179,55 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Debian" codelang="bash" >}} +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - -# 必要なパッケージをインストールし、リポジトリを追加 -apt-get update -apt-get install software-properties-common +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - -add-apt-repository ppa:projectatomic/ppa -apt-get update +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - -# CRI-Oをインストール -apt-get install cri-o-1.11 +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +# CRI-Oのインストール +sudo apt-get install cri-o-1.17 {{< /tab >}} + +{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} +# リポジトリの設定 +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update + +# CRI-Oのインストール +sudo apt-get install cri-o-1.17 +{{< /tab >}} + {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +# 必要なパッケージのインストール +yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ -# 必要なリポジトリを追加 -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ - -# CRI-Oをインストール -yum install --nogpgcheck cri-o +# CRI-Oのインストール +yum install --nogpgcheck -y cri-o +{{< /tab >}} +{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +sudo zypper install cri-o {{< /tab >}} {{< /tabs >}} ### CRI-Oの起動 ``` +systemctl daemon-reload systemctl start crio ``` @@ -205,6 +242,11 @@ systemctl start crio ### 必要な設定の追加 ```shell +cat > /etc/modules-load.d/containerd.conf <}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -apt-get install -y libseccomp2 +{{< tab name="Ubuntu 16.04" codelang="bash" >}} +# containerdのインストール +## リポジトリの設定 +### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール +apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common + +### Docker公式のGPG鍵を追加 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - + +### Dockerのaptリポジトリの追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" + +## containerdのインストール +apt-get update && apt-get install -y containerd.io + +# containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml + +# containerdの再起動 +systemctl restart containerd {{< /tab >}} {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -yum install -y libseccomp +# containerdのインストール +## リポジトリの設定 +### 必要なパッケージのインストール +yum install -y yum-utils device-mapper-persistent-data lvm2 + +### Dockerのリポジトリの追加 +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo + +## containerdのインストール +yum update -y && yum install -y containerd.io + +# containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml + +# containerdの再起動 +systemctl restart containerd {{< /tab >}} {{< /tabs >}} -### containerdのインストール +### systemd -[Containerdは定期的にリリース](https://github.com/containerd/containerd/releases)されますが、以下に示すコマンドで利用している値は、この手順が作成された時点での最新のバージョンにしたがって書かれています。より新しいバージョンとダウンロードするファイルのハッシュ値については[こちら](https://storage.googleapis.com/cri-containerd-release)で確認するようにしてください。 - -```shell -# 必要な環境変数をexportします。 -export CONTAINERD_VERSION="1.1.2" -export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218" - -# containerdのtarボールをダウンロードします。 -wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# ハッシュ値をチェックします。 -echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check - - -# 解凍して展開します。 -tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# containerdを起動します。 -systemctl start containerd -``` +`systemd`のcgroupドライバーを使うには、`/etc/containerd/config.toml`内で`plugins.cri.systemd_cgroup = true`を設定してください。 +kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)を手動で設定してください。 ## その他のCRIランタイム: frakti 詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。 +{{% /capture %}} From b4e2cdfa593829d5a58351dfda72744124953a72 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Wed, 24 Jun 2020 20:19:57 +0900 Subject: [PATCH 077/119] fix caption --- .../docs/setup/production-environment/container-runtimes.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index b91a8f4fc2..ddb52386f3 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -3,14 +3,13 @@ title: CRIのインストール content_type: concept weight: 10 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.6" state="stable" >}} Podのコンテナを実行するために、Kubernetesはコンテナランタイムを使用します。 様々なランタイムのインストール手順は次のとおりです。 -{{% /capture %}} -{{% capture body %}} + {{< caution >}} @@ -320,5 +319,4 @@ kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/set 詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。 -{{% /capture %}} From 45cdfae246057ed05610ae049770530527444fd5 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Wed, 24 Jun 2020 20:21:27 +0900 Subject: [PATCH 078/119] tiny fix --- .../ja/docs/setup/production-environment/container-runtimes.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index ddb52386f3..26aa83ded8 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -9,6 +9,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ 様々なランタイムのインストール手順は次のとおりです。 + From 0a2907911cfc7b20ea092b8193caaf79ae277284 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 28 Jun 2020 08:30:31 +0900 Subject: [PATCH 079/119] Fix misc things. --- content/ja/docs/concepts/_index.md | 6 +++--- content/ja/docs/concepts/containers/runtime-class.md | 5 ++--- .../ja/docs/concepts/overview/what-is-kubernetes.md | 4 ++-- .../overview/working-with-objects/namespaces.md | 2 +- .../docs/concepts/workloads/pods/init-containers.md | 2 +- content/ja/docs/home/supported-doc-versions.md | 5 ++--- content/ja/docs/setup/_index.md | 2 +- .../tools/kubeadm/control-plane-flags.md | 6 +++--- .../service-access-application-cluster.md | 2 +- .../access-application-cluster/web-ui-dashboard.md | 12 ++++++------ .../debug-init-containers.md | 4 ++-- .../get-shell-running-container.md | 2 +- .../ja/docs/tutorials/kubernetes-basics/_index.html | 2 +- 13 files changed, 26 insertions(+), 28 deletions(-) diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 0f03287083..2cc381ede6 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -19,10 +19,10 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使 一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。 -* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 +* **Kubernetes Master**: [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 * クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。 - * **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。 - * **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 + * **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。 + * **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 ## Kubernetesオブジェクト diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 463eb1a15c..5cffc21b0d 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -26,9 +26,8 @@ RuntimeClassはコンテナランタイムの設定を選択するための機 ### セットアップ -RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、[Feature -Gates](/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 -その`RuntimeClass`のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。 +RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 +その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。 1. ノード上でCRI実装を設定する。（ランタイムに依存） 2. 対応するRuntimeClassリソースを作成する。 diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 1b90ef4a3f..054930e426 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -48,7 +48,7 @@ Kubernetesは... * サポートするアプリケーションの種類を限定しません。Kubernetesはステートレス、ステートフル、およびデータ処理ワークロードなど、非常に多様なワークロードをサポートするように作られています。アプリケーションをコンテナ内で実行できる場合は、Kubernetes上でもうまく動作するはずです。 * ソースコードのデプロイやアプリケーションのビルドを行いません。継続的インテグレーション、デリバリー、デプロイ(CI/CD)ワークフローは、技術選定がそうであるように、組織の文化や好みによって決まるからです。 -* ミドルウェア(例: message buses)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。 +* ミドルウェア(例: メッセージバス)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。 * ロギング、モニタリング、アラーティングソリューションへの指示は行いません。概念実証(PoC)としていくつかのインテグレーション、およびメトリックを収集およびエクスポートするためのメカニズムを提供します。 * 設定言語/システム(例： jsonnet)を提供も強制もしません。任意の形式の宣言仕様の対象となる可能性がある宣言APIを提供します。 * 包括的なインフラ構成、保守、管理、またはセルフヒーリングシステムを提供、導入しません。 @@ -57,7 +57,7 @@ Kubernetesは... ## なぜコンテナなのか？ -なぜコンテナを使うべきかの理由をお探しですか？ +コンテナを使うべき理由をお探しですか？ ![なぜコンテナなのか？](/images/docs/why_containers.svg) diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 1286e3c667..1b66e046f1 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -78,7 +78,7 @@ kubectl config view --minify | grep namespace: ## NamespaceとDNS ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 -このエントリは`..svc.cluster.local`という形式になり,これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 +このエントリは`..svc.cluster.local`という形式になり、これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 5d285b15d8..d32cd6dcae 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -202,7 +202,7 @@ myapp-pod 1/1 Running 0 9m このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。 -## Initコンテナのふるまいに関する詳細 {#Detailed behavior} +## Initコンテナのふるまいに関する詳細 {#detailed-behavior} Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 diff --git a/content/ja/docs/home/supported-doc-versions.md b/content/ja/docs/home/supported-doc-versions.md index a4c9ac18ce..0ca6fcee64 100644 --- a/content/ja/docs/home/supported-doc-versions.md +++ b/content/ja/docs/home/supported-doc-versions.md @@ -9,7 +9,7 @@ card: -本ウェブサイトでは、現行版とその直前4バージョンのKubernetesドキュメントを含んでいます。 +本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。 @@ -17,8 +17,7 @@ card: ## 現行版 -現在のバージョンは -[{{< param "version" >}}](/). +現在のバージョンは[{{< param "version" >}}](/)です。 ## 以前のバージョン diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 8ba1773f75..2d602e9300 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -49,6 +49,6 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。 +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index b4ff9024f6..b2b41f9128 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -35,7 +35,7 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag 詳細は[kube-apiserverのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -52,7 +52,7 @@ apiServer: 詳細は[kube-controller-managerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-controller-manager/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -68,7 +68,7 @@ controllerManager: 詳細は[kube-schedulerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index 8b0439ec3a..1fe8e47e7b 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -23,7 +23,7 @@ weight: 60 ## {{% heading "objectives" %}} -* 2つのHellow Worldアプリケーションを稼働させる。 +* 2つのHello Worldアプリケーションを稼働させる。 * Nodeのポートを公開するServiceオブジェクトを作成する。 * 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。 diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 99585c4631..8087e5602e 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -92,12 +92,12 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー 例: - ```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` - **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。 diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md index 5577881c95..fa5255ca7f 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -14,7 +14,7 @@ content_type: task {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。 +* [Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)の基本を理解しておきましょう。 * [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。 @@ -100,7 +100,7 @@ kubectl logs -c -## Podのステータスを理解する +## Podのステータスを理解する {#understanding-pod-status} `Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。 diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index b6825075b8..684fa981c1 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -47,7 +47,7 @@ kubectl exec -it shell-demo -- /bin/bash ``` {{< note >}} -ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。 +ダブルダッシュの記号 `--` はコマンドに渡す引数とkubectlの引数を分離します。 {{< /note >}} diff --git a/content/ja/docs/tutorials/kubernetes-basics/_index.html b/content/ja/docs/tutorials/kubernetes-basics/_index.html index 99174c2b21..3f31b8d5bc 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ja/docs/tutorials/kubernetes-basics/_index.html @@ -39,7 +39,7 @@ card:
-

Kubernetesはどんなことができるの?

+

Kubernetesはどんなことができるの？

モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。

From fdd75eeda71a614dcd5eb1986e98642c337efdd5 Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Thu, 2 Jul 2020 00:14:48 +0900 Subject: [PATCH 080/119] update ja version: concepts/overview/kubernetes-api.md --- .../docs/concepts/overview/kubernetes-api.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 4e21db1633..fac9769434 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -3,7 +3,7 @@ reviewers: title: Kubernetes API content_type: concept weight: 30 -card: +card: name: concepts weight: 30 --- @@ -30,7 +30,7 @@ Kubernetesそれ自身は複数のコンポーネントから構成されてお 我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。 -何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md)に詳解されています。 +何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。 ## OpenAPIとSwaggerの定義 @@ -44,7 +44,7 @@ Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポ Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` （デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません） Accept-Encoding | `gzip` （このヘッダーを送信しないことも許容されています） -1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。 +1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 **OpenAPI仕様の取得サンプル**: @@ -57,7 +57,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。 また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。 -このエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。 +このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 ## APIバージョニング @@ -102,15 +102,15 @@ APIグループは、RESTのパスとシリアライズされたオブジェク 1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。 1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。 -## APIグループの有効化 +## APIグループの有効化、無効化 いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 -重要: APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。 +{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}} -## APIグループのリソースの有効化 - -DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。 -その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。 +## APIグループextensions/v1beta1に含まれる特定のリソースの有効化 +APIグループ`extensions/v1beta1`に含まれるDaemonSets、Deployments、StatefulSet、NetworkPolicies、PodSecurityPolicies、ReplicaSetsはデフォルトで無効にされています。 +例えば、deploymentとdaemonsetを有効にするには、`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`と設定します。 +{{< note >}}リソースを個別に有効化、無効化することは歴史的な理由によりAPIグループ`extensions/v1beta1`に含まれるリソースに限りサポートされています。{{< /note >}} From 84a911c51b89f06f3aed5a27b0c235b6a1aec66c Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 14 Jun 2020 20:01:41 +0900 Subject: [PATCH 081/119] Copy /en/docs/concepts/architecture/controller.md into /ja directory. --- .../docs/concepts/architecture/controller.md | 162 ++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 content/ja/docs/concepts/architecture/controller.md diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..e5bee1d0a5 --- /dev/null +++ b/content/ja/docs/concepts/architecture/controller.md @@ -0,0 +1,162 @@ +--- +title: Controllers +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +In robotics and automation, a _control loop_ is +a non-terminating loop that regulates the state of a system. + +Here is one example of a control loop: a thermostat in a room. + +When you set the temperature, that's telling the thermostat +about your *desired state*. The actual room temperature is the +*current state*. The thermostat acts to bring the current state +closer to the desired state, by turning equipment on or off. + +{{< glossary_definition term_id="controller" length="short">}} + +{{% /capture %}} + + +{{% capture body %}} + +## Controller pattern + +A controller tracks at least one Kubernetes resource type. +These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) +have a spec field that represents the desired state. The +controller(s) for that resource are responsible for making the current +state come closer to that desired state. + +The controller might carry the action out itself; more commonly, in Kubernetes, +a controller will send messages to the +{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} that have +useful side effects. You'll see examples of this below. + +{{< comment >}} +Some built-in controllers, such as the namespace controller, act on objects +that do not have a spec. For simplicity, this page omits explaining that +detail. +{{< /comment >}} + +### Control via API server + +The {{< glossary_tooltip term_id="job" >}} controller is an example of a +Kubernetes built-in controller. Built-in controllers manage state by +interacting with the cluster API server. + +Job is a Kubernetes resource that runs a +{{< glossary_tooltip term_id="pod" >}}, or perhaps several Pods, to carry out +a task and then stop. + +(Once [scheduled](/docs/concepts/scheduling/), Pod objects become part of the +desired state for a kubelet). + +When the Job controller sees a new task it makes sure that, somewhere +in your cluster, the kubelets on a set of Nodes are running the right +number of Pods to get the work done. +The Job controller does not run any Pods or containers +itself. Instead, the Job controller tells the API server to create or remove +Pods. +Other components in the +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} +act on the new information (there are new Pods to schedule and run), +and eventually the work is done. + +After you create a new Job, the desired state is for that Job to be completed. +The Job controller makes the current state for that Job be nearer to your +desired state: creating Pods that do the work you wanted for that Job, so that +the Job is closer to completion. + +Controllers also update the objects that configure them. +For example: once the work is done for a Job, the Job controller +updates that Job object to mark it `Finished`. + +(This is a bit like how some thermostats turn a light off to +indicate that your room is now at the temperature you set). + +### Direct control + +By contrast with Job, some controllers need to make changes to +things outside of your cluster. + +For example, if you use a control loop to make sure there +are enough {{< glossary_tooltip text="Nodes" term_id="node" >}} +in your cluster, then that controller needs something outside the +current cluster to set up new Nodes when needed. + +Controllers that interact with external state find their desired state from +the API server, then communicate directly with an external system to bring +the current state closer in line. + +(There actually is a controller that horizontally scales the +nodes in your cluster. See +[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). + +## Desired versus current state {#desired-vs-current} + +Kubernetes takes a cloud-native view of systems, and is able to handle +constant change. + +Your cluster could be changing at any point as work happens and +control loops automatically fix failures. This means that, +potentially, your cluster never reaches a stable state. + +As long as the controllers for your cluster are running and able to make +useful changes, it doesn't matter if the overall state is or is not stable. + +## Design + +As a tenet of its design, Kubernetes uses lots of controllers that each manage +a particular aspect of cluster state. Most commonly, a particular control loop +(controller) uses one kind of resource as its desired state, and has a different +kind of resource that it manages to make that desired state happen. + +It's useful to have simple controllers rather than one, monolithic set of control +loops that are interlinked. Controllers can fail, so Kubernetes is designed to +allow for that. + +For example: a controller for Jobs tracks Job objects (to discover +new work) and Pod object (to run the Jobs, and then to see when the work is +finished). In this case something else creates the Jobs, whereas the Job +controller creates Pods. + +{{< note >}} +There can be several controllers that create or update the same kind of object. +Behind the scenes, Kubernetes controllers make sure that they only pay attention +to the resources linked to their controlling resource. + +For example, you can have Deployments and Jobs; these both create Pods. +The Job controller does not delete the Pods that your Deployment created, +because there is information ({{< glossary_tooltip term_id="label" text="labels" >}}) +the controllers can use to tell those Pods apart. +{{< /note >}} + +## Ways of running controllers {#running-controllers} + +Kubernetes comes with a set of built-in controllers that run inside +the {{< glossary_tooltip term_id="kube-controller-manager" >}}. These +built-in controllers provide important core behaviors. + +The Deployment controller and Job controller are examples of controllers that +come as part of Kubernetes itself (“built-in” controllers). +Kubernetes lets you run a resilient control plane, so that if any of the built-in +controllers were to fail, another part of the control plane will take over the work. + +You can find controllers that run outside the control plane, to extend Kubernetes. +Or, if you want, you can write a new controller yourself. +You can run your own controller as a set of Pods, +or externally to Kubernetes. What fits best will depend on what that particular +controller does. + +{{% /capture %}} + +{{% capture whatsnext %}} +* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) +* Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects) +* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) +* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes. +{{% /capture %}} From d9f70a427cfb8c24c222cb7d07f8ded7b1549b18 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 15 Jun 2020 17:10:44 +0900 Subject: [PATCH 082/119] Apply the diff from the latest en file. --- content/ja/docs/concepts/architecture/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index e5bee1d0a5..fe8965f3e2 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -26,7 +26,7 @@ closer to the desired state, by turning equipment on or off. ## Controller pattern A controller tracks at least one Kubernetes resource type. -These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) +These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) have a spec field that represents the desired state. The controller(s) for that resource are responsible for making the current state come closer to that desired state. From 587a6b6d97527ea194527f3e7b7e12e055b9df5b Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 3 Jul 2020 10:21:55 +0900 Subject: [PATCH 083/119] Copy content/ja/docs/tutorials/stateful-application/{_index,basic-stateful-set}.md from en. --- .../tutorials/stateful-application/_index.md | 5 + .../basic-stateful-set.md | 1203 +++++++++++++++++ 2 files changed, 1208 insertions(+) create mode 100755 content/ja/docs/tutorials/stateful-application/_index.md create mode 100644 content/ja/docs/tutorials/stateful-application/basic-stateful-set.md diff --git a/content/ja/docs/tutorials/stateful-application/_index.md b/content/ja/docs/tutorials/stateful-application/_index.md new file mode 100755 index 0000000000..01382e6b8c --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "Stateful Applications" +weight: 50 +--- + diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md new file mode 100644 index 0000000000..9c6edf784f --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md @@ -0,0 +1,1203 @@ +--- +reviewers: +- enisoc +- erictune +- foxish +- janetkuo +- kow3ns +- smarterclayton +title: StatefulSet Basics +content_type: tutorial +weight: 10 +--- + + +This tutorial provides an introduction to managing applications with +{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}. +It demonstrates how to create, delete, scale, and update the Pods of StatefulSets. + + +## {{% heading "prerequisites" %}} + +Before you begin this tutorial, you should familiarize yourself with the +following Kubernetes concepts: + +* [Pods](/docs/concepts/workloads/pods/) +* [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) +* [Headless Services](/docs/concepts/services-networking/service/#headless-services) +* [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) +* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +* [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) +* The [kubectl](/docs/reference/kubectl/kubectl/) command line tool + +{{< note >}} +This tutorial assumes that your cluster is configured to dynamically provision +PersistentVolumes. If your cluster is not configured to do so, you +will have to manually provision two 1 GiB volumes prior to starting this +tutorial. +{{< /note >}} + +## {{% heading "objectives" %}} + +StatefulSets are intended to be used with stateful applications and distributed +systems. However, the administration of stateful applications and +distributed systems on Kubernetes is a broad, complex topic. In order to +demonstrate the basic features of a StatefulSet, and not to conflate the former +topic with the latter, you will deploy a simple web application using a StatefulSet. + +After this tutorial, you will be familiar with the following. + +* How to create a StatefulSet +* How a StatefulSet manages its Pods +* How to delete a StatefulSet +* How to scale a StatefulSet +* How to update a StatefulSet's Pods + + + +## Creating a StatefulSet + +Begin by creating a StatefulSet using the example below. It is similar to the +example presented in the +[StatefulSets](/docs/concepts/workloads/controllers/statefulset/) concept. +It creates a [headless Service](/docs/concepts/services-networking/service/#headless-services), +`nginx`, to publish the IP addresses of Pods in the StatefulSet, `web`. + +{{< codenew file="application/web/web.yaml" >}} + +Download the example above, and save it to a file named `web.yaml` + +You will need to use two terminal windows. In the first terminal, use +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the creation +of the StatefulSet's Pods. + +```shell +kubectl get pods -w -l app=nginx +``` + +In the second terminal, use +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to create the +headless Service and StatefulSet defined in `web.yaml`. + +```shell +kubectl apply -f web.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +The command above creates two Pods, each running an +[NGINX](https://www.nginx.com) webserver. Get the `nginx` Service... +```shell +kubectl get service nginx +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +nginx ClusterIP None 80/TCP 12s +``` +...then get the `web` StatefulSet, to verify that both were created successfully: +```shell +kubectl get statefulset web +``` +``` +NAME DESIRED CURRENT AGE +web 2 1 20s +``` + +### Ordered Pod Creation + +For a StatefulSet with _n_ replicas, when Pods are being deployed, they are +created sequentially, ordered from _{0..n-1}_. Examine the output of the +`kubectl get` command in the first terminal. Eventually, the output will +look like the example below. + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 19s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +Notice that the `web-1` Pod is not launched until the `web-0` Pod is +_Running_ (see [Pod Phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)) +and _Ready_ (see `type` in [Pod Conditions](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)). + +## Pods in a StatefulSet + +Pods in a StatefulSet have a unique ordinal index and a stable network identity. + +### Examining the Pod's Ordinal Index + +Get the StatefulSet's Pods: + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 1m +web-1 1/1 Running 0 1m +``` + +As mentioned in the [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) +concept, the Pods in a StatefulSet have a sticky, unique identity. This identity +is based on a unique ordinal index that is assigned to each Pod by the +StatefulSet {{< glossary_tooltip term_id="controller" text="controller">}}. +The Pods' names take the form `-`. +Since the `web` StatefulSet has two replicas, it creates two Pods, `web-0` and `web-1`. + +### Using Stable Network Identities + +Each Pod has a stable hostname based on its ordinal index. Use +[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) to execute the +`hostname` command in each Pod: + +```shell +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done +``` +``` +web-0 +web-1 +``` + +Use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to execute +a container that provides the `nslookup` command from the `dnsutils` package. +Using `nslookup` on the Pods' hostnames, you can examine their in-cluster DNS +addresses: + +```shell +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +``` +which starts a new shell. In that new shell, run: +```shell +# Run this in the dns-test container shell +nslookup web-0.nginx +``` +The output is similar to: +``` +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.6 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.6 +``` + +(and now exit the container shell: `exit`) + +The CNAME of the headless service points to SRV records (one for each Pod that +is Running and Ready). The SRV records point to A record entries that +contain the Pods' IP addresses. + +In one terminal, watch the StatefulSet's Pods: + +```shell +kubectl get pod -w -l app=nginx +``` +In a second terminal, use +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete all +the Pods in the StatefulSet: + +```shell +kubectl delete pod -l app=nginx +``` +``` +pod "web-0" deleted +pod "web-1" deleted +``` + +Wait for the StatefulSet to restart them, and for both Pods to transition to +Running and Ready: + +```shell +kubectl get pod -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +Use `kubectl exec` and `kubectl run` to view the Pods' hostnames and in-cluster +DNS entries. First, view the Pods' hostnames: + +```shell +for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +``` +``` +web-0 +web-1 +``` +then, run: +``` +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +which starts a new shell. +In that new shell, run: +```shell +# Run this in the dns-test container shell +nslookup web-0.nginx +``` +The output is similar to: +``` +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.7 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.8 +``` + +(and now exit the container shell: `exit`) + +The Pods' ordinals, hostnames, SRV records, and A record names have not changed, +but the IP addresses associated with the Pods may have changed. In the cluster +used for this tutorial, they have. This is why it is important not to configure +other applications to connect to Pods in a StatefulSet by IP address. + + +If you need to find and connect to the active members of a StatefulSet, you +should query the CNAME of the headless Service +(`nginx.default.svc.cluster.local`). The SRV records associated with the +CNAME will contain only the Pods in the StatefulSet that are Running and +Ready. + +If your application already implements connection logic that tests for +liveness and readiness, you can use the SRV records of the Pods ( +`web-0.nginx.default.svc.cluster.local`, +`web-1.nginx.default.svc.cluster.local`), as they are stable, and your +application will be able to discover the Pods' addresses when they transition +to Running and Ready. + +### Writing to Stable Storage + +Get the PersistentVolumeClaims for `web-0` and `web-1`: + +```shell +kubectl get pvc -l app=nginx +``` +The output is similar to: +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s +``` + +The StatefulSet controller created two +{{< glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" >}} +that are bound to two +{{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}. + +As the cluster used in this tutorial is configured to dynamically provision PersistentVolumes, +the PersistentVolumes were created and bound automatically. + +The NGINX webserver, by default, serves an index file from +`/usr/share/nginx/html/index.html`. The `volumeMounts` field in the +StatefulSet's `spec` ensures that the `/usr/share/nginx/html` directory is +backed by a PersistentVolume. + +Write the Pods' hostnames to their `index.html` files and verify that the NGINX +webservers serve the hostnames: + +```shell +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done + +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +{{< note >}} +If you instead see **403 Forbidden** responses for the above curl command, +you will need to fix the permissions of the directory mounted by the `volumeMounts` +(due to a [bug when using hostPath volumes](https://github.com/kubernetes/kubernetes/issues/2630)), +by running: + +`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` + +before retrying the `curl` command above. +{{< /note >}} + +In one terminal, watch the StatefulSet's Pods: + +```shell +kubectl get pod -w -l app=nginx +``` + +In a second terminal, delete all of the StatefulSet's Pods: + +```shell +kubectl delete pod -l app=nginx +``` +``` +pod "web-0" deleted +pod "web-1" deleted +``` +Examine the output of the `kubectl get` command in the first terminal, and wait +for all of the Pods to transition to Running and Ready. + +```shell +kubectl get pod -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +Verify the web servers continue to serve their hostnames: + +``` +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +Even though `web-0` and `web-1` were rescheduled, they continue to serve their +hostnames because the PersistentVolumes associated with their +PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what +node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be +mounted to the appropriate mount points. + +## Scaling a StatefulSet + +Scaling a StatefulSet refers to increasing or decreasing the number of replicas. +This is accomplished by updating the `replicas` field. You can use either +[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) or +[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) to scale a StatefulSet. + +### Scaling Up + +In one terminal window, watch the Pods in the StatefulSet: + +```shell +kubectl get pods -w -l app=nginx +``` + +In another terminal window, use `kubectl scale` to scale the number of replicas +to 5: + +```shell +kubectl scale sts web --replicas=5 +``` +``` +statefulset.apps/web scaled +``` + +Examine the output of the `kubectl get` command in the first terminal, and wait +for the three additional Pods to transition to Running and Ready. + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2h +web-1 1/1 Running 0 2h +NAME READY STATUS RESTARTS AGE +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 ContainerCreating 0 0s +web-3 1/1 Running 0 18s +web-4 0/1 Pending 0 0s +web-4 0/1 Pending 0 0s +web-4 0/1 ContainerCreating 0 0s +web-4 1/1 Running 0 19s +``` + +The StatefulSet controller scaled the number of replicas. As with +[StatefulSet creation](#ordered-pod-creation), the StatefulSet controller +created each Pod sequentially with respect to its ordinal index, and it +waited for each Pod's predecessor to be Running and Ready before launching the +subsequent Pod. + +### Scaling Down + +In one terminal, watch the StatefulSet's Pods: + +```shell +kubectl get pods -w -l app=nginx +``` + +In another terminal, use `kubectl patch` to scale the StatefulSet back down to +three replicas: + +```shell +kubectl patch sts web -p '{"spec":{"replicas":3}}' +``` +``` +statefulset.apps/web patched +``` + +Wait for `web-4` and `web-3` to transition to Terminating. + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3h +web-1 1/1 Running 0 3h +web-2 1/1 Running 0 55s +web-3 1/1 Running 0 36s +web-4 0/1 ContainerCreating 0 18s +NAME READY STATUS RESTARTS AGE +web-4 1/1 Running 0 19s +web-4 1/1 Terminating 0 24s +web-4 1/1 Terminating 0 24s +web-3 1/1 Terminating 0 42s +web-3 1/1 Terminating 0 42s +``` + +### Ordered Pod Termination + +The controller deleted one Pod at a time, in reverse order with respect to its +ordinal index, and it waited for each to be completely shutdown before +deleting the next. + +Get the StatefulSet's PersistentVolumeClaims: + +```shell +kubectl get pvc -l app=nginx +``` +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-2 Bound pvc-e1125b27-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-3 Bound pvc-e1176df6-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO 13h + +``` + +There are still five PersistentVolumeClaims and five PersistentVolumes. +When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when the StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down. + +## Updating StatefulSets + +In Kubernetes 1.7 and later, the StatefulSet controller supports automated updates. The +strategy used is determined by the `spec.updateStrategy` field of the +StatefulSet API Object. This feature can be used to upgrade the container +images, resource requests and/or limits, labels, and annotations of the Pods in a +StatefulSet. There are two valid update strategies, `RollingUpdate` and +`OnDelete`. + +`RollingUpdate` update strategy is the default for StatefulSets. + +### Rolling Update + +The `RollingUpdate` update strategy will update all Pods in a StatefulSet, in +reverse ordinal order, while respecting the StatefulSet guarantees. + +Patch the `web` StatefulSet to apply the `RollingUpdate` update strategy: + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +``` +``` +statefulset.apps/web patched +``` + +In one terminal window, patch the `web` StatefulSet to change the container +image again: + +```shell +kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' +``` +``` +statefulset.apps/web patched +``` + +In another terminal, watch the Pods in the StatefulSet: + +```shell +kubectl get pod -l app=nginx -w +``` +The output is simular to: +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 7m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 8m +web-2 1/1 Terminating 0 8m +web-2 1/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-1 1/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 6s +web-0 1/1 Terminating 0 7m +web-0 1/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +``` + +The Pods in the StatefulSet are updated in reverse ordinal order. The +StatefulSet controller terminates each Pod, and waits for it to transition to Running and +Ready prior to updating the next Pod. Note that, even though the StatefulSet +controller will not proceed to update the next Pod until its ordinal successor +is Running and Ready, it will restore any Pod that fails during the update to +its current version. + +Pods that have already received the update will be restored to the updated version, +and Pods that have not yet received the update will be restored to the previous +version. In this way, the controller attempts to continue to keep the application +healthy and the update consistent in the presence of intermittent failures. + +Get the Pods to view their container images: + +```shell +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 + +``` + +All the Pods in the StatefulSet are now running the previous container image. + +{{< note >}} +You can also use `kubectl rollout status sts/` to view +the status of a rolling update to a StatefulSet +{{< /note >}} + +#### Staging an Update + +You can stage an update to a StatefulSet by using the `partition` parameter of +the `RollingUpdate` update strategy. A staged update will keep all of the Pods +in the StatefulSet at the current version while allowing mutations to the +StatefulSet's `.spec.template`. + +Patch the `web` StatefulSet to add a partition to the `updateStrategy` field: + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +``` +``` +statefulset.apps/web patched +``` + +Patch the StatefulSet again to change the container's image: + +```shell +kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +``` +``` +statefulset.apps/web patched +``` + +Delete a Pod in the StatefulSet: + +```shell +kubectl delete pod web-2 +``` +``` +pod "web-2" deleted +``` + +Wait for the Pod to be Running and Ready. + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +Get the Pod's container image: + +```shell +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.8 +``` + +Notice that, even though the update strategy is `RollingUpdate` the StatefulSet +restored the Pod with its original container. This is because the +ordinal of the Pod is less than the `partition` specified by the +`updateStrategy`. + +#### Rolling Out a Canary + +You can roll out a canary to test a modification by decrementing the `partition` +you specified [above](#staging-an-update). + +Patch the StatefulSet to decrement the partition: + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +``` +``` +statefulset.apps/web patched +``` + +Wait for `web-2` to be Running and Ready. + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +Get the Pod's container: + +```shell +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.7 + +``` + +When you changed the `partition`, the StatefulSet controller automatically +updated the `web-2` Pod because the Pod's ordinal was greater than or equal to +the `partition`. + +Delete the `web-1` Pod: + +```shell +kubectl delete pod web-1 +``` +``` +pod "web-1" deleted +``` + +Wait for the `web-1` Pod to be Running and Ready. + +```shell +kubectl get pod -l app=nginx -w +``` +The output is similar to: +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 0/1 Terminating 0 6m +web-2 1/1 Running 0 2m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +Get the `web-1` Pod's container image: + +```shell +kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.8 +``` + +`web-1` was restored to its original configuration because the Pod's ordinal +was less than the partition. When a partition is specified, all Pods with an +ordinal that is greater than or equal to the partition will be updated when the +StatefulSet's `.spec.template` is updated. If a Pod that has an ordinal less +than the partition is deleted or otherwise terminated, it will be restored to +its original configuration. + +#### Phased Roll Outs + +You can perform a phased roll out (e.g. a linear, geometric, or exponential +roll out) using a partitioned rolling update in a similar manner to how you +rolled out a [canary](#rolling-out-a-canary). To perform a phased roll out, set +the `partition` to the ordinal at which you want the controller to pause the +update. + +The partition is currently set to `2`. Set the partition to `0`: + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +``` +``` +statefulset.apps/web patched +``` + +Wait for all of the Pods in the StatefulSet to become Running and Ready. + +```shell +kubectl get pod -l app=nginx -w +``` +The output is similar to: +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3m +web-1 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 2m +web-1 1/1 Running 0 18s +web-0 1/1 Terminating 0 3m +web-0 1/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 3s +``` + +Get the container image details for the Pods in the StatefulSet: + +```shell +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 +``` + +By moving the `partition` to `0`, you allowed the StatefulSet to +continue the update process. + +### On Delete + +The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior, +When you select this update strategy, the StatefulSet controller will not +automatically update Pods when a modification is made to the StatefulSet's +`.spec.template` field. This strategy can be selected by setting the +`.spec.template.updateStrategy.type` to `OnDelete`. + + +## Deleting StatefulSets + +StatefulSet supports both Non-Cascading and Cascading deletion. In a +Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are +deleted. + +### Non-Cascading Delete + +In one terminal window, watch the Pods in the StatefulSet. + +``` +kubectl get pods -w -l app=nginx +``` + +Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the +StatefulSet. Make sure to supply the `--cascade=false` parameter to the +command. This parameter tells Kubernetes to only delete the StatefulSet, and to +not delete any of its Pods. + +```shell +kubectl delete statefulset web --cascade=false +``` +``` +statefulset.apps "web" deleted +``` + +Get the Pods, to examine their status: + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 5m +``` + +Even though `web` has been deleted, all of the Pods are still Running and Ready. +Delete `web-0`: + +```shell +kubectl delete pod web-0 +``` +``` +pod "web-0" deleted +``` + +Get the StatefulSet's Pods: + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 10m +web-2 1/1 Running 0 7m +``` + +As the `web` StatefulSet has been deleted, `web-0` has not been relaunched. + +In one terminal, watch the StatefulSet's Pods. + +```shell +kubectl get pods -w -l app=nginx +``` + +In a second terminal, recreate the StatefulSet. Note that, unless +you deleted the `nginx` Service (which you should not have), you will see +an error indicating that the Service already exists. + +```shell +kubectl apply -f web.yaml +``` +``` +statefulset.apps/web created +service/nginx unchanged +``` + +Ignore the error. It only indicates that an attempt was made to create the _nginx_ +headless Service even though that Service already exists. + +Examine the output of the `kubectl get` command running in the first terminal. + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 16m +web-2 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 18s +web-2 1/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +``` + +When the `web` StatefulSet was recreated, it first relaunched `web-0`. +Since `web-1` was already Running and Ready, when `web-0` transitioned to + Running and Ready, it simply adopted this Pod. Since you recreated the StatefulSet + with `replicas` equal to 2, once `web-0` had been recreated, and once + `web-1` had been determined to already be Running and Ready, `web-2` was + terminated. + +Let's take another look at the contents of the `index.html` file served by the +Pods' webservers: + +```shell +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +Even though you deleted both the StatefulSet and the `web-0` Pod, it still +serves the hostname originally entered into its `index.html` file. This is +because the StatefulSet never deletes the PersistentVolumes associated with a +Pod. When you recreated the StatefulSet and it relaunched `web-0`, its original +PersistentVolume was remounted. + +### Cascading Delete + +In one terminal window, watch the Pods in the StatefulSet. + +```shell +kubectl get pods -w -l app=nginx +``` + +In another terminal, delete the StatefulSet again. This time, omit the +`--cascade=false` parameter. + +```shell +kubectl delete statefulset web +``` +``` +statefulset.apps "web" deleted +``` +Examine the output of the `kubectl get` command running in the first terminal, +and wait for all of the Pods to transition to Terminating. + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 11m +web-1 1/1 Running 0 27m +NAME READY STATUS RESTARTS AGE +web-0 1/1 Terminating 0 12m +web-1 1/1 Terminating 0 29m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m + +``` + +As you saw in the [Scaling Down](#scaling-down) section, the Pods +are terminated one at a time, with respect to the reverse order of their ordinal +indices. Before terminating a Pod, the StatefulSet controller waits for +the Pod's successor to be completely terminated. + +{{< note >}} +Although a cascading delete removes a StatefulSet together with its Pods, +the cascade does not delete the headless Service associated with the StatefulSet. +You must delete the `nginx` Service manually. +{{< /note >}} + + +```shell +kubectl delete service nginx +``` +``` +service "nginx" deleted +``` + +Recreate the StatefulSet and headless Service one more time: + +```shell +kubectl apply -f web.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +When all of the StatefulSet's Pods transition to Running and Ready, retrieve +the contents of their `index.html` files: + +```shell +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +Even though you completely deleted the StatefulSet, and all of its Pods, the +Pods are recreated with their PersistentVolumes mounted, and `web-0` and +`web-1` continue to serve their hostnames. + +Finally, delete the `web` StatefulSet... + +```shell +kubectl delete service nginx +``` +``` +service "nginx" deleted +``` +...and the `nginx` Service: +```shell +kubectl delete statefulset web +``` +``` +statefulset "web" deleted +``` + +## Pod Management Policy + +For some distributed systems, the StatefulSet ordering guarantees are +unnecessary and/or undesirable. These systems require only uniqueness and +identity. To address this, in Kubernetes 1.7, we introduced +`.spec.podManagementPolicy` to the StatefulSet API Object. + +### OrderedReady Pod Management + +`OrderedReady` pod management is the default for StatefulSets. It tells the +StatefulSet controller to respect the ordering guarantees demonstrated +above. + +### Parallel Pod Management + +`Parallel` pod management tells the StatefulSet controller to launch or +terminate all Pods in parallel, and not to wait for Pods to become Running +and Ready or completely terminated prior to launching or terminating another +Pod. + +{{< codenew file="application/web/web-parallel.yaml" >}} + +Download the example above, and save it to a file named `web-parallel.yaml` + +This manifest is identical to the one you downloaded above except that the `.spec.podManagementPolicy` +of the `web` StatefulSet is set to `Parallel`. + +In one terminal, watch the Pods in the StatefulSet. + +```shell +kubectl get pod -l app=nginx -w +``` + +In another terminal, create the StatefulSet and Service in the manifest: + +```shell +kubectl apply -f web-parallel.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +Examine the output of the `kubectl get` command that you executed in the first terminal. + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-1 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +web-1 1/1 Running 0 10s +``` + +The StatefulSet controller launched both `web-0` and `web-1` at the same time. + +Keep the second terminal open, and, in another terminal window scale the +StatefulSet: + +```shell +kubectl scale statefulset/web --replicas=4 +``` +``` +statefulset.apps/web scaled +``` + +Examine the output of the terminal where the `kubectl get` command is running. + +``` +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 7s +web-3 0/1 ContainerCreating 0 7s +web-2 1/1 Running 0 10s +web-3 1/1 Running 0 26s +``` + + +The StatefulSet launched two new Pods, and it did not wait for +the first to become Running and Ready prior to launching the second. + +## {{% heading "cleanup" %}} + +You should have two terminals open, ready for you to run `kubectl` commands as +part of cleanup. + +```shell +kubectl delete sts web +# sts is an abbreviation for statefulset +``` + +You can watch `kubectl get` to see those Pods being deleted. +```shell +kubectl get pod -l app=nginx -w +``` +``` +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-1 1/1 Terminating 0 44m +web-0 1/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +``` + +During deletion, a StatefulSet removes all Pods concurrently; it does not wait for +a Pod's ordinal successor to terminate prior to deleting that Pod. + +Close the terminal where the `kubectl get` command is running and delete the `nginx` +Service: + +```shell +kubectl delete svc nginx +``` + + +{{< note >}} +You also need to delete the persistent storage media for the PersistentVolumes +used in this tutorial. + + +Follow the necessary steps, based on your environment, storage configuration, +and provisioning method, to ensure that all storage is reclaimed. +{{< /note >}} From 00379158f46a650f41007b65b27f77d4ad988d37 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 3 Jul 2020 10:22:53 +0900 Subject: [PATCH 084/119] Translate tutorials/stateful-application/basic-stateful-set into Japanese. --- .../tutorials/stateful-application/_index.md | 2 +- .../basic-stateful-set.md | 529 ++++++------------ 2 files changed, 177 insertions(+), 354 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/_index.md b/content/ja/docs/tutorials/stateful-application/_index.md index 01382e6b8c..421915d42c 100755 --- a/content/ja/docs/tutorials/stateful-application/_index.md +++ b/content/ja/docs/tutorials/stateful-application/_index.md @@ -1,5 +1,5 @@ --- -title: "Stateful Applications" +title: "ステートフルアプリケーション" weight: 50 --- diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md index 9c6edf784f..57aeccd7f2 100644 --- a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md @@ -1,83 +1,57 @@ --- -reviewers: -- enisoc -- erictune -- foxish -- janetkuo -- kow3ns -- smarterclayton -title: StatefulSet Basics +title: StatefulSetの基本 content_type: tutorial weight: 10 --- -This tutorial provides an introduction to managing applications with -{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}. -It demonstrates how to create, delete, scale, and update the Pods of StatefulSets. - +このチュートリアルでは、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}を使用したアプリケーションを管理するための基本を説明します。StatefulSetのPodを作成、削除、スケール、そして更新する方法について紹介します。 ## {{% heading "prerequisites" %}} -Before you begin this tutorial, you should familiarize yourself with the -following Kubernetes concepts: +このチュートリアルを始める前に、以下のKubernetesの概念について理解しておく必要があります。 -* [Pods](/docs/concepts/workloads/pods/) -* [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) -* [Headless Services](/docs/concepts/services-networking/service/#headless-services) -* [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) -* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) -* [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) -* The [kubectl](/docs/reference/kubectl/kubectl/) command line tool +* [Pod](/ja/docs/concepts/workloads/pods/) +* [Cluster DNS](/ja/docs/concepts/services-networking/dns-pod-service/) +* [Headless Service](/ja/docs/concepts/services-networking/service/#headless-services) +* [PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/) +* [PersistentVolumeのプロビジョニング](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +* [kubectl](/docs/reference/kubectl/kubectl/)コマンドラインツール {{< note >}} -This tutorial assumes that your cluster is configured to dynamically provision -PersistentVolumes. If your cluster is not configured to do so, you -will have to manually provision two 1 GiB volumes prior to starting this -tutorial. +このチュートリアルでは、クラスターがPersistentVolumeの動的なプロビジョニングが行われるように設定されていることを前提としています。クラスターがそのように設定されていない場合、チュートリアルを始める前に1GiBのボリュームを2つ手動でプロビジョニングする必要があります。 {{< /note >}} ## {{% heading "objectives" %}} -StatefulSets are intended to be used with stateful applications and distributed -systems. However, the administration of stateful applications and -distributed systems on Kubernetes is a broad, complex topic. In order to -demonstrate the basic features of a StatefulSet, and not to conflate the former -topic with the latter, you will deploy a simple web application using a StatefulSet. +StatefulSetはステートフルアプリケーションや分散システムで使用するために存在します。しかし、Kubernetes上のステートフルアプリケーションや分散システムは、広範で複雑なトピックです。StatefulSetの基本的な機能を示すという目的のため、また、分散システムをステートフルアプリケーションと混同しないようにするために、ここでは、Statefulsetを使用する単純なウェブアプリケーションのデプロイを行います。 -After this tutorial, you will be familiar with the following. +このチュートリアルを終えると、以下のことが理解できるようになります。 -* How to create a StatefulSet -* How a StatefulSet manages its Pods -* How to delete a StatefulSet -* How to scale a StatefulSet -* How to update a StatefulSet's Pods +* StatefulSetの作成方法 +* StatefulSetがどのようにPodを管理するのか +* StatefulSetの削除方法 +* StatefulSetのスケール方法 +* StatefulSetが管理するPodの更新方法 -## Creating a StatefulSet +## StatefulSetを作成する {#ordered-pod-creation} -Begin by creating a StatefulSet using the example below. It is similar to the -example presented in the -[StatefulSets](/docs/concepts/workloads/controllers/statefulset/) concept. -It creates a [headless Service](/docs/concepts/services-networking/service/#headless-services), -`nginx`, to publish the IP addresses of Pods in the StatefulSet, `web`. +はじめに、以下の例を使ってStatefulSetを作成しましょう。これは、コンセプトの[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のページで使ったものと同じような例です。`nginx`という[headless Service](/ja/docs/concepts/services-networking/service/#headless-services)を作成し、`web`というStatefulSet内のPodのIPアドレスを公開します。 {{< codenew file="application/web/web.yaml" >}} -Download the example above, and save it to a file named `web.yaml` +上の例をダウンロードして、`web.yaml`という名前で保存します。 -You will need to use two terminal windows. In the first terminal, use -[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the creation -of the StatefulSet's Pods. +ここでは、ターミナルウィンドウを2つ使う必要があります。1つ目のターミナルでは、[`kubectl get`](/ja/docs/reference/generated/kubectl/kubectl-commands/#get)を使って、StatefulSetのPodの作成を監視します。 ```shell kubectl get pods -w -l app=nginx ``` -In the second terminal, use -[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to create the -headless Service and StatefulSet defined in `web.yaml`. +2つ目のターミナルでは、[`kubectl apply`](/ja/docs/reference/generated/kubectl/kubectl-commands/#apply)を使って、`web.yaml`に定義されたheadless ServiceとStatefulSetを作成します。 ```shell kubectl apply -f web.yaml @@ -87,8 +61,7 @@ service/nginx created statefulset.apps/web created ``` -The command above creates two Pods, each running an -[NGINX](https://www.nginx.com) webserver. Get the `nginx` Service... +上のコマンドを実行すると、2つのPodが作成され、それぞれのPodで[NGINX](https://www.nginx.com)ウェブサーバーが実行されます。`nginx`Serviceを取得してみましょう。 ```shell kubectl get service nginx ``` @@ -96,7 +69,7 @@ kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None 80/TCP 12s ``` -...then get the `web` StatefulSet, to verify that both were created successfully: +そして、`web`StatefulSetを取得して、2つのリソースの作成が成功したことも確認します。 ```shell kubectl get statefulset web ``` @@ -105,12 +78,9 @@ NAME DESIRED CURRENT AGE web 2 1 20s ``` -### Ordered Pod Creation +### 順序付きPodの作成 -For a StatefulSet with _n_ replicas, when Pods are being deployed, they are -created sequentially, ordered from _{0..n-1}_. Examine the output of the -`kubectl get` command in the first terminal. Eventually, the output will -look like the example below. +_n_ 個のレプリカを持つStatefulSetは、Podをデプロイするとき、1つずつ順番に作成し、 _{0..n-1}_ という順序付けを行います。1つ目のターミナルで`kubectl get`コマンドの出力を確認しましょう。最終的に、以下の例のような出力が表示されるはずです。 ```shell kubectl get pods -w -l app=nginx @@ -127,17 +97,15 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -Notice that the `web-1` Pod is not launched until the `web-0` Pod is -_Running_ (see [Pod Phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)) -and _Ready_ (see `type` in [Pod Conditions](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)). +`web-0`Podが _Running_ ([Pod Phase](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)を参照)かつ _Ready_ ([Pod Conditions](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)の`type`を参照)の状態になるまでは、`web-1`Podが起動していないことに注目してください。 -## Pods in a StatefulSet +## StatefulSet内のPod -Pods in a StatefulSet have a unique ordinal index and a stable network identity. +StatefulSet内のPodは、ユニークな順序インデックスと安定したネットワーク識別子を持ちます。 -### Examining the Pod's Ordinal Index +### Podの順序インデックスを確かめる -Get the StatefulSet's Pods: +StatefulSetのPodを取得します。 ```shell kubectl get pods -l app=nginx @@ -148,18 +116,11 @@ web-0 1/1 Running 0 1m web-1 1/1 Running 0 1m ``` -As mentioned in the [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) -concept, the Pods in a StatefulSet have a sticky, unique identity. This identity -is based on a unique ordinal index that is assigned to each Pod by the -StatefulSet {{< glossary_tooltip term_id="controller" text="controller">}}. -The Pods' names take the form `-`. -Since the `web` StatefulSet has two replicas, it creates two Pods, `web-0` and `web-1`. +[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のコンセプトで説明したように、StatefulSet内のPodは安定したユニークな識別子を持ちます。この識別子は、StatefulSet{{< glossary_tooltip term_id="controller" text="コントローラー">}}によって各Podに割り当てられる、ユニークな順序インデックスに基づいて付けられます。Podの名前は、`-<順序インデックス>`という形式です。`web`StatefulSetは2つのレプリカを持つため、`web-0`と`web-1`という2つのPodを作成します。 -### Using Stable Network Identities +### 安定したネットワーク識別子の使用 -Each Pod has a stable hostname based on its ordinal index. Use -[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) to execute the -`hostname` command in each Pod: +各Podは、順序インデックスに基づいた安定したホスト名を持ちます。[`kubectl exec`](/ja/docs/reference/generated/kubectl/kubectl-commands/#exec)を使用して、各Pod内で`hostname`コマンドを実行してみましょう。 ```shell for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done @@ -169,20 +130,17 @@ web-0 web-1 ``` -Use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to execute -a container that provides the `nslookup` command from the `dnsutils` package. -Using `nslookup` on the Pods' hostnames, you can examine their in-cluster DNS -addresses: +[`kubectl run`](/ja/docs/reference/generated/kubectl/kubectl-commands/#run)を使用して、`dnsutils`パッケージの`nslookup`コマンドを提供するコンテナを実行します。Podのホスト名に対して`nslookup`を実行すると、クラスター内のDNSアドレスが確認できます。 ```shell kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm ``` -which starts a new shell. In that new shell, run: +これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。 ```shell -# Run this in the dns-test container shell +# このコマンドは、dns-testコンテナのシェルで実行してください nslookup web-0.nginx ``` -The output is similar to: +出力は次のようになります。 ``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -198,20 +156,16 @@ Name: web-1.nginx Address 1: 10.244.2.6 ``` -(and now exit the container shell: `exit`) +(コンテナのシェルを終了するために、`exit`コマンドを実行してください。) -The CNAME of the headless service points to SRV records (one for each Pod that -is Running and Ready). The SRV records point to A record entries that -contain the Pods' IP addresses. +headless serviceのCNAMEは、SRVレコードを指しています(1つのレコードがRunningかつReadyのPodに対応します)。SRVレコードは、PodのIPアドレスを含むAレコードを指します。 -In one terminal, watch the StatefulSet's Pods: +1つ目のターミナルで、StatefulSetのPodを監視します。 ```shell kubectl get pod -w -l app=nginx ``` -In a second terminal, use -[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete all -the Pods in the StatefulSet: +2つ目のターミナルで、[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetのすべてのPodを削除します。 ```shell kubectl delete pod -l app=nginx @@ -221,8 +175,7 @@ pod "web-0" deleted pod "web-1" deleted ``` -Wait for the StatefulSet to restart them, and for both Pods to transition to -Running and Ready: +StatefulSetがPodを再起動して、2つのPodがRunningかつReadyの状態に移行するのを待ちます。 ```shell kubectl get pod -w -l app=nginx @@ -238,8 +191,7 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 34s ``` -Use `kubectl exec` and `kubectl run` to view the Pods' hostnames and in-cluster -DNS entries. First, view the Pods' hostnames: +`kubectl exec`と`kubectl run`コマンドを使用して、Podのホスト名とクラスター内DNSエントリーを確認します。まず、Podのホスト名を見てみましょう。 ```shell for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done @@ -248,17 +200,16 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 ``` -then, run: +その後、次のコマンドを実行します。 ``` kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh ``` -which starts a new shell. -In that new shell, run: +これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。 ```shell -# Run this in the dns-test container shell +# このコマンドは、dns-testコンテナのシェルで実行してください nslookup web-0.nginx ``` -The output is similar to: +出力は次のようになります。 ``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -274,56 +225,35 @@ Name: web-1.nginx Address 1: 10.244.2.8 ``` -(and now exit the container shell: `exit`) +(コンテナのシェルを終了するために、`exit`コマンドを実行してください。) -The Pods' ordinals, hostnames, SRV records, and A record names have not changed, -but the IP addresses associated with the Pods may have changed. In the cluster -used for this tutorial, they have. This is why it is important not to configure -other applications to connect to Pods in a StatefulSet by IP address. +Podの順序インデックス、ホスト名、SRVレコード、そしてAレコード名は変化していませんが、Podに紐付けられたIPアドレスは変化する可能性があります。このチュートリアルで使用しているクラスターでは、IPアドレスは変わりました。このようなことがあるため、他のアプリケーションがStatefulSet内のPodに接続するときには、IPアドレスで指定しないことが重要です。 +StatefulSetの有効なメンバーを探して接続する必要がある場合は、headless ServiceのCNAME(`nginx.default.svc.cluster.local`)をクエリしなければなりません。CNAMEに紐付けられたSRVレコードには、StatefulSet内のRunnningかつReadyなPodだけが含まれます。 -If you need to find and connect to the active members of a StatefulSet, you -should query the CNAME of the headless Service -(`nginx.default.svc.cluster.local`). The SRV records associated with the -CNAME will contain only the Pods in the StatefulSet that are Running and -Ready. +アプリケーションがlivenessとreadinessをテストするコネクションのロジックをすでに実装している場合、PodのSRVレコード(`web-0.nginx.default.svc.cluster.local`、`web-1.nginx.default.svc.cluster.local`)をPodが安定しているものとして使用できます。PodがRunning and Readyな状態に移行すれば、アプリケーションはPodのアドレスを発見できるようになります。 -If your application already implements connection logic that tests for -liveness and readiness, you can use the SRV records of the Pods ( -`web-0.nginx.default.svc.cluster.local`, -`web-1.nginx.default.svc.cluster.local`), as they are stable, and your -application will be able to discover the Pods' addresses when they transition -to Running and Ready. +### 安定したストレージへの書き込み {#writing-to-stable-storage} -### Writing to Stable Storage - -Get the PersistentVolumeClaims for `web-0` and `web-1`: +`web-0`および`web-1`のためのPersistentVolumeClaimを取得しましょう。 ```shell kubectl get pvc -l app=nginx ``` -The output is similar to: +出力は次のようになります。 ``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s ``` -The StatefulSet controller created two -{{< glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" >}} -that are bound to two -{{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}. +StatefulSetコントローラーは、2つの{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}にバインドされた2つの{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}を作成しています。 -As the cluster used in this tutorial is configured to dynamically provision PersistentVolumes, -the PersistentVolumes were created and bound automatically. +このチュートリアルで使用しているクラスターでは、PersistentVolumeの動的なプロビジョニングが設定されているため、PersistentVolumeが自動的に作成されてバインドされています。 -The NGINX webserver, by default, serves an index file from -`/usr/share/nginx/html/index.html`. The `volumeMounts` field in the -StatefulSet's `spec` ensures that the `/usr/share/nginx/html` directory is -backed by a PersistentVolume. +デフォルトでは、NGINXウェブサーバーは`/usr/share/nginx/html/index.html`に置かれたindexファイルを配信します。StatefulSetの`spec`内の`volumeMounts`フィールドによって、`/usr/share/nginx/html`ディレクトリがPersistentVolume上にあることが保証されます。 -Write the Pods' hostnames to their `index.html` files and verify that the NGINX -webservers serve the hostnames: +Podのホスト名を`index.html`ファイルに書き込むことで、NGINXウェブサーバーがホスト名を配信することを検証しましょう。 ```shell for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done @@ -336,23 +266,18 @@ web-1 ``` {{< note >}} -If you instead see **403 Forbidden** responses for the above curl command, -you will need to fix the permissions of the directory mounted by the `volumeMounts` -(due to a [bug when using hostPath volumes](https://github.com/kubernetes/kubernetes/issues/2630)), -by running: +上記のcurlコマンドに対して代わりに**403 Forbidden**というレスポンスが返ってくる場合、`volumeMounts`でマウントしたディレクトリのパーミッションを修正する必要があります(これは、[hostPathボリュームを使用したときに起こるバグ](https://github.com/kubernetes/kubernetes/issues/2630)が原因です)。この問題に対処するには、上の`curl`コマンドを再実行する前に、次のコマンドを実行します。 `for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` - -before retrying the `curl` command above. {{< /note >}} -In one terminal, watch the StatefulSet's Pods: +1つ目のターミナルで、StatefulSetのPodを監視します。 ```shell kubectl get pod -w -l app=nginx ``` -In a second terminal, delete all of the StatefulSet's Pods: +2つ目のターミナルで、StatefulSetのすべてのPodを削除します。 ```shell kubectl delete pod -l app=nginx @@ -361,8 +286,7 @@ kubectl delete pod -l app=nginx pod "web-0" deleted pod "web-1" deleted ``` -Examine the output of the `kubectl get` command in the first terminal, and wait -for all of the Pods to transition to Running and Ready. +1つ目のターミナルで`kubectl get`コマンドの出力を確認して、すべてのPodがRunningかつReadyの状態に変わるまで待ちます。 ```shell kubectl get pod -w -l app=nginx @@ -378,7 +302,7 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 34s ``` -Verify the web servers continue to serve their hostnames: +ウェブサーバーがホスト名を配信し続けていることを確認します。 ``` for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done @@ -388,29 +312,22 @@ web-0 web-1 ``` -Even though `web-0` and `web-1` were rescheduled, they continue to serve their -hostnames because the PersistentVolumes associated with their -PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what -node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be -mounted to the appropriate mount points. +もし`web-0`および`web-1`が再スケジュールされたとしても、Podは同じホスト名を配信し続けます。これは、PodのPersistentVolumeClaimに紐付けられたPersistentVolumeが、Podの`volumeMounts`に再マウントされるためです。`web-0`と`web-1`がどんなノードにスケジュールされたとしても、PodのPersistentVolumeは適切なマウントポイントにマウントされます。 -## Scaling a StatefulSet +## StatefulSetをスケールする -Scaling a StatefulSet refers to increasing or decreasing the number of replicas. -This is accomplished by updating the `replicas` field. You can use either -[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) or -[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) to scale a StatefulSet. +StatefulSetのスケールとは、レプリカ数を増減することを意味します。これは、`replicas`フィールドを更新することによって実現できます。StatefulSetのスケールには、[`kubectl scale`](/ja/docs/reference/generated/kubectl/kubectl-commands/#scale)と +[`kubectl patch`](/ja/docs/reference/generated/kubectl/kubectl-commands/#patch)のどちらも使用できます。 -### Scaling Up +### スケールアップ -In one terminal window, watch the Pods in the StatefulSet: +1つ目のターミナルで、StatefulSet内のPodを監視します。 ```shell kubectl get pods -w -l app=nginx ``` -In another terminal window, use `kubectl scale` to scale the number of replicas -to 5: +2つ目のターミナルで、`kubectl scale`を使って、レプリカ数を5にスケールします。 ```shell kubectl scale sts web --replicas=5 @@ -419,8 +336,7 @@ kubectl scale sts web --replicas=5 statefulset.apps/web scaled ``` -Examine the output of the `kubectl get` command in the first terminal, and wait -for the three additional Pods to transition to Running and Ready. +1つ目のターミナルの`kubectl get`コマンドの出力を確認して、3つの追加のPodがRunningかつReadyの状態に変わるまで待ちます。 ```shell kubectl get pods -w -l app=nginx @@ -444,22 +360,18 @@ web-4 0/1 ContainerCreating 0 0s web-4 1/1 Running 0 19s ``` -The StatefulSet controller scaled the number of replicas. As with -[StatefulSet creation](#ordered-pod-creation), the StatefulSet controller -created each Pod sequentially with respect to its ordinal index, and it -waited for each Pod's predecessor to be Running and Ready before launching the -subsequent Pod. +StatefulSetコントローラーはレプリカ数をスケールします。 +[StatefulSetを作成する](#ordered-pod-creation)で説明したように、StatefulSetコントローラーは各Podを順序インデックスに従って1つずつ作成し、次のPodを起動する前に、1つ前のPodがRunningかつReadyの状態になるまで待ちます。 -### Scaling Down +### スケールダウン {#scaling-down} -In one terminal, watch the StatefulSet's Pods: +1つ目のターミナルで、StatefulSetのPodを監視します。 ```shell kubectl get pods -w -l app=nginx ``` -In another terminal, use `kubectl patch` to scale the StatefulSet back down to -three replicas: +2つ目のターミナルで、`kubectl patch`コマンドを使用して、StatefulSetを3つのレプリカにスケールダウンします。 ```shell kubectl patch sts web -p '{"spec":{"replicas":3}}' @@ -468,7 +380,7 @@ kubectl patch sts web -p '{"spec":{"replicas":3}}' statefulset.apps/web patched ``` -Wait for `web-4` and `web-3` to transition to Terminating. +`web-4`および`web-3`がTerminatingの状態になるまで待ちます。 ```shell kubectl get pods -w -l app=nginx @@ -488,13 +400,11 @@ web-3 1/1 Terminating 0 42s web-3 1/1 Terminating 0 42s ``` -### Ordered Pod Termination +### 順序付きPodを削除する -The controller deleted one Pod at a time, in reverse order with respect to its -ordinal index, and it waited for each to be completely shutdown before -deleting the next. +コントローラーは、順序インデックスの逆順に1度に1つのPodを削除し、次のPodを削除する前には、各Podが完全にシャットダウンするまで待機しています。 -Get the StatefulSet's PersistentVolumeClaims: +StatefulSetのPersistentVolumeClaimを取得しましょう。 ```shell kubectl get pvc -l app=nginx @@ -509,26 +419,19 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ``` -There are still five PersistentVolumeClaims and five PersistentVolumes. -When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when the StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down. +まだ、5つのPersistentVolumeClaimと5つのPersistentVolumeが残っています。[安定したストレージへの書き込み](#writing-to-stable-storage)を読むと、StatefulSetのPodが削除されても、StatefulSetのPodにマウントされたPersistentVolumeは削除されないと書かれています。このことは、StatefulSetのスケールダウンによってPodが削除された場合にも当てはまります。 -## Updating StatefulSets +## StatefulSetsを更新する -In Kubernetes 1.7 and later, the StatefulSet controller supports automated updates. The -strategy used is determined by the `spec.updateStrategy` field of the -StatefulSet API Object. This feature can be used to upgrade the container -images, resource requests and/or limits, labels, and annotations of the Pods in a -StatefulSet. There are two valid update strategies, `RollingUpdate` and -`OnDelete`. +Kubernetes 1.7以降では、StatefulSetコントローラーは自動アップデートをサポートしています。使われる戦略は、StatefulSet APIオブジェクトの`spec.updateStrategy`フィールドによって決まります。この機能はコンテナイメージのアップグレード、リソースのrequestsやlimits、ラベル、StatefulSet内のPodのアノテーションの更新時に利用できます。有効なアップデートの戦略は、`RollingUpdate`と`OnDelete`の2種類です。 -`RollingUpdate` update strategy is the default for StatefulSets. +`RollingUpdate`は、StatefulSetのデフォルトのアップデート戦略です。 -### Rolling Update +### RollingUpdate -The `RollingUpdate` update strategy will update all Pods in a StatefulSet, in -reverse ordinal order, while respecting the StatefulSet guarantees. +`RollingUpdate`アップデート戦略は、StatefulSetの保証を尊重しながら、順序インデックスの逆順にStatefulSet内のすべてのPodをアップデートします。 -Patch the `web` StatefulSet to apply the `RollingUpdate` update strategy: +`web`StatefulSetにpatchを当てて、`RollingUpdate`アップデート戦略を適用しましょう。 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' @@ -537,8 +440,7 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda statefulset.apps/web patched ``` -In one terminal window, patch the `web` StatefulSet to change the container -image again: +1つ目のターミナルで、`web`StatefulSetに再度patchを当てて、コンテナイメージを変更します。 ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' @@ -547,12 +449,12 @@ kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spe statefulset.apps/web patched ``` -In another terminal, watch the Pods in the StatefulSet: +2つ目のターミナルで、StatefulSet内のPodを監視します。 ```shell kubectl get pod -l app=nginx -w ``` -The output is simular to: +出力は次のようになります。 ``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 7m @@ -588,19 +490,11 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 10s ``` -The Pods in the StatefulSet are updated in reverse ordinal order. The -StatefulSet controller terminates each Pod, and waits for it to transition to Running and -Ready prior to updating the next Pod. Note that, even though the StatefulSet -controller will not proceed to update the next Pod until its ordinal successor -is Running and Ready, it will restore any Pod that fails during the update to -its current version. +StatefulSet内のPodは、順序インデックスの逆順に更新されました。StatefulSetコントローラーは各Podを終了させ、次のPodを更新する前に、新しいPodがRunningかつReadyの状態に変わるまで待機します。ここで、StatefulSetコントローラーは順序インデックスの前のPodがRunningかつReadyの状態になるまで次のPodの更新を始めず、現在の状態へのアップデートに失敗したPodがあった場合、そのPodをリストアすることに注意してください。 -Pods that have already received the update will be restored to the updated version, -and Pods that have not yet received the update will be restored to the previous -version. In this way, the controller attempts to continue to keep the application -healthy and the update consistent in the presence of intermittent failures. +すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。 -Get the Pods to view their container images: +Podを取得して、コンテナイメージを確認してみましょう。 ```shell for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done @@ -612,21 +506,17 @@ k8s.gcr.io/nginx-slim:0.8 ``` -All the Pods in the StatefulSet are now running the previous container image. +現在、StatefulSet内のすべてのPodは、前のコンテナイメージを実行しています。 {{< note >}} -You can also use `kubectl rollout status sts/` to view -the status of a rolling update to a StatefulSet +`kubectl rollout status sts/`を使って、StatefulSetへのローリングアップデートの状態を確認することもできます。 {{< /note >}} -#### Staging an Update +#### ステージングアップデート {#staging-an-update} -You can stage an update to a StatefulSet by using the `partition` parameter of -the `RollingUpdate` update strategy. A staged update will keep all of the Pods -in the StatefulSet at the current version while allowing mutations to the -StatefulSet's `.spec.template`. +`RollingUpdate`アップデート戦略に`partition`パラメーターを使用すると、StatefulSetへのアップデートをステージングすることができます。ステージングアップデートを利用すれば、StatefulSet内のすべてのPodを現在のバージョンにしたまま、StatefulSetの`.spec.template`を変更することが可能になります。 -Patch the `web` StatefulSet to add a partition to the `updateStrategy` field: +`web`StatefulSetにpatchを当てて、`updateStrategy`フィールドにpartitionを追加しましょう。 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' @@ -635,7 +525,7 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda statefulset.apps/web patched ``` -Patch the StatefulSet again to change the container's image: +StatefulSetに再度patchを当てて、コンテナイメージを変更します。 ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' @@ -644,7 +534,7 @@ kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spe statefulset.apps/web patched ``` -Delete a Pod in the StatefulSet: +StatefulSet内のPodを削除します。 ```shell kubectl delete pod web-2 @@ -653,7 +543,7 @@ kubectl delete pod web-2 pod "web-2" deleted ``` -Wait for the Pod to be Running and Ready. +PodがRunningかつReadyになるまで待ちます。 ```shell kubectl get pod -l app=nginx -w @@ -666,7 +556,7 @@ web-2 0/1 ContainerCreating 0 11s web-2 1/1 Running 0 18s ``` -Get the Pod's container image: +Podのコンテナイメージを取得します。 ```shell kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' @@ -675,17 +565,13 @@ kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image k8s.gcr.io/nginx-slim:0.8 ``` -Notice that, even though the update strategy is `RollingUpdate` the StatefulSet -restored the Pod with its original container. This is because the -ordinal of the Pod is less than the `partition` specified by the -`updateStrategy`. +アップデート戦略が`RollingUpdate`であっても、StatefulSetが元のコンテナを持つPodをリストアしたことがわかります。これは、Podの順序インデックスが`updateStrategy`で指定した`partition`より小さいためです。 -#### Rolling Out a Canary +#### カナリア版をロールアウトする {#rolling-out-a-canary} -You can roll out a canary to test a modification by decrementing the `partition` -you specified [above](#staging-an-update). +[ステージングアップデート](#staging-an-update)のときに指定した`partition`を小さくすることで、変更をテストするためのカナリア版をロールアウトできます。 -Patch the StatefulSet to decrement the partition: +StatefulSetにpatchを当てて、partitionを小さくします。 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' @@ -694,7 +580,7 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda statefulset.apps/web patched ``` -Wait for `web-2` to be Running and Ready. +`web-2`がRunningかつReadyの状態になるまで待ちます。 ```shell kubectl get pod -l app=nginx -w @@ -707,7 +593,7 @@ web-2 0/1 ContainerCreating 0 11s web-2 1/1 Running 0 18s ``` -Get the Pod's container: +Podのコンテナを取得します。 ```shell kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' @@ -717,11 +603,9 @@ k8s.gcr.io/nginx-slim:0.7 ``` -When you changed the `partition`, the StatefulSet controller automatically -updated the `web-2` Pod because the Pod's ordinal was greater than or equal to -the `partition`. +`partition`を変更すると、StatefulSetコントローラーはPodを自動的に更新します。Podの順序インデックスが`partition`以上の値であるためです。 -Delete the `web-1` Pod: +`web-1`Podを削除します。 ```shell kubectl delete pod web-1 @@ -730,12 +614,12 @@ kubectl delete pod web-1 pod "web-1" deleted ``` -Wait for the `web-1` Pod to be Running and Ready. +`web-1`PodがRunningかつReadyになるまで待ちます。 ```shell kubectl get pod -l app=nginx -w ``` -The output is similar to: +出力は次のようになります。 ``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m @@ -750,7 +634,7 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -Get the `web-1` Pod's container image: +`web-1`Podのコンテナイメージを取得します。 ```shell kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' @@ -759,22 +643,13 @@ kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image k8s.gcr.io/nginx-slim:0.8 ``` -`web-1` was restored to its original configuration because the Pod's ordinal -was less than the partition. When a partition is specified, all Pods with an -ordinal that is greater than or equal to the partition will be updated when the -StatefulSet's `.spec.template` is updated. If a Pod that has an ordinal less -than the partition is deleted or otherwise terminated, it will be restored to -its original configuration. +Podの順序インデックスがpartitionよりも小さいため、`web-1`は元の設定のコンテナイメージにリストアされました。partitionを指定すると、StatefulSetの`.spec.template`が更新されたときに、順序インデックスがそれ以上の値を持つすべてのPodがアップデートされます。partitionよりも小さな順序インデックスを持つPodが削除されたり終了されたりすると、元の設定のPodにリストアされます。 -#### Phased Roll Outs +#### フェーズロールアウト -You can perform a phased roll out (e.g. a linear, geometric, or exponential -roll out) using a partitioned rolling update in a similar manner to how you -rolled out a [canary](#rolling-out-a-canary). To perform a phased roll out, set -the `partition` to the ordinal at which you want the controller to pause the -update. +[カナリア版](#rolling-out-a-canary)をロールアウトするのと同じような方法でパーティションされたローリングアップデートを使用すると、フェーズロールアウト(例: 線形、幾何級数的、指数関数的ロールアウト)を実行できます。フェーズロールアウトを実行するには、コントローラーがアップデートを途中で止めてほしい順序インデックスを`partition`に設定します。 -The partition is currently set to `2`. Set the partition to `0`: +現在、partitionは`2`に設定されています。partitionを`0`に設定します。 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' @@ -783,12 +658,12 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda statefulset.apps/web patched ``` -Wait for all of the Pods in the StatefulSet to become Running and Ready. +StatefulSet内のすべてのPodがRunningかつReadyの状態になるまで待ちます。 ```shell kubectl get pod -l app=nginx -w ``` -The output is similar to: +出力は次のようになります。 ``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3m @@ -807,7 +682,7 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 3s ``` -Get the container image details for the Pods in the StatefulSet: +StatefulSet内のPodのコンテナイメージの詳細を取得します。 ```shell for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done @@ -818,36 +693,25 @@ k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 ``` -By moving the `partition` to `0`, you allowed the StatefulSet to -continue the update process. +`partition`を`0`に移動することで、StatefulSetがアップデート処理を続けられるようにできます。 -### On Delete +### OnDelete -The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior, -When you select this update strategy, the StatefulSet controller will not -automatically update Pods when a modification is made to the StatefulSet's -`.spec.template` field. This strategy can be selected by setting the -`.spec.template.updateStrategy.type` to `OnDelete`. +`OnDelete`アップデート戦略は、(1.6以前の)レガシーな動作を実装しています。このアップデート戦略を選択すると、StatefulSetの`.spec.template`フィールドへ変更を加えても、StatefulSetコントローラーが自動的にPodを更新しなくなります。この戦略を選択するには、`.spec.template.updateStrategy.type`に`OnDelete`を設定します。 +## StatefulSetを削除する -## Deleting StatefulSets +StatefulSetは、非カスケードな削除とカスケードな削除の両方をサポートしています。非カスケードな削除では、StatefulSetが削除されても、StatefulSet内のPodは削除されません。カスケードな削除では、StatefulSetとPodが一緒に削除されます。 -StatefulSet supports both Non-Cascading and Cascading deletion. In a -Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are -deleted. +### 非カスケードな削除 -### Non-Cascading Delete - -In one terminal window, watch the Pods in the StatefulSet. +1つ目のターミナルで、StatefulSet内のPodを監視します ``` kubectl get pods -w -l app=nginx ``` -Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the -StatefulSet. Make sure to supply the `--cascade=false` parameter to the -command. This parameter tells Kubernetes to only delete the StatefulSet, and to -not delete any of its Pods. +[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetを削除します。このとき、`--cascade=false`パラメーターをコマンドに与えてください。このパラメーターは、Kubernetesに対して、StatefulSetだけを削除して配下のPodは削除しないように指示します。 ```shell kubectl delete statefulset web --cascade=false @@ -856,7 +720,7 @@ kubectl delete statefulset web --cascade=false statefulset.apps "web" deleted ``` -Get the Pods, to examine their status: +Podを取得して、ステータスを確認します。 ```shell kubectl get pods -l app=nginx @@ -868,8 +732,7 @@ web-1 1/1 Running 0 7m web-2 1/1 Running 0 5m ``` -Even though `web` has been deleted, all of the Pods are still Running and Ready. -Delete `web-0`: +`web`が削除されても、すべてのPodはまだRunningかつReadyの状態のままです。`web-0`を削除します。 ```shell kubectl delete pod web-0 @@ -878,7 +741,7 @@ kubectl delete pod web-0 pod "web-0" deleted ``` -Get the StatefulSet's Pods: +StatefulSetのPodを取得します。 ```shell kubectl get pods -l app=nginx @@ -889,17 +752,15 @@ web-1 1/1 Running 0 10m web-2 1/1 Running 0 7m ``` -As the `web` StatefulSet has been deleted, `web-0` has not been relaunched. +`web`StatefulSetはすでに削除されているため、`web-0`は再起動しません。 -In one terminal, watch the StatefulSet's Pods. +1つ目のターミナルで、StatefulSetのPodを監視します。 ```shell kubectl get pods -w -l app=nginx ``` -In a second terminal, recreate the StatefulSet. Note that, unless -you deleted the `nginx` Service (which you should not have), you will see -an error indicating that the Service already exists. +2つ目のターミナルで、StatefulSetを再作成します。もし`nginx`Serviceを削除しなかった場合(この場合は削除するべきではありませんでした)、Serviceがすでに存在することを示すエラーが表示されます。 ```shell kubectl apply -f web.yaml @@ -909,10 +770,9 @@ statefulset.apps/web created service/nginx unchanged ``` -Ignore the error. It only indicates that an attempt was made to create the _nginx_ -headless Service even though that Service already exists. +このエラーは無視してください。このメッセージは、すでに存在する _nginx_ というheadless Serviceを作成しようと試みたということを示しているだけです。 -Examine the output of the `kubectl get` command running in the first terminal. +1つ目のターミナルで、`kubectl get`コマンドの出力を確認します。 ```shell kubectl get pods -w -l app=nginx @@ -932,15 +792,9 @@ web-2 0/1 Terminating 0 3m web-2 0/1 Terminating 0 3m ``` -When the `web` StatefulSet was recreated, it first relaunched `web-0`. -Since `web-1` was already Running and Ready, when `web-0` transitioned to - Running and Ready, it simply adopted this Pod. Since you recreated the StatefulSet - with `replicas` equal to 2, once `web-0` had been recreated, and once - `web-1` had been determined to already be Running and Ready, `web-2` was - terminated. + `web`StatefulSetが再作成されると、最初に`web-0`を再実行します。`web-1`はすでにRunningかつReadyの状態であるため、`web-0`がRunningかつReadyの状態に移行すると、StatefulSetは単純にこのPodを選びます。StatefulSetを`replicas`を2にして再作成したため、一度`web-0`が再作成されて、`web-1`がすでにRunningかつReadyの状態であることが判明したら、`web-2`は停止されます。 -Let's take another look at the contents of the `index.html` file served by the -Pods' webservers: +Podのウェブサーバーが配信している`index.html`ファイルのコンテンツをもう一度見てみましょう。 ```shell for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done @@ -950,22 +804,17 @@ web-0 web-1 ``` -Even though you deleted both the StatefulSet and the `web-0` Pod, it still -serves the hostname originally entered into its `index.html` file. This is -because the StatefulSet never deletes the PersistentVolumes associated with a -Pod. When you recreated the StatefulSet and it relaunched `web-0`, its original -PersistentVolume was remounted. +たとえStatefulSetと`web-0`Podの両方が削除されても、Podは最初に`index.html`ファイルに書き込んだホスト名をまだ配信しています。これは、StatefulSetがPodに紐付けられたPersistentVolumeを削除しないためです。StatefulSetを再作成して`web-0`を再実行すると、元のPersistentVolumeが再マウントされます。 -### Cascading Delete +### カスケードな削除 -In one terminal window, watch the Pods in the StatefulSet. +1つ目のターミナルで、StatefulSet内のPodを監視します。 ```shell kubectl get pods -w -l app=nginx ``` -In another terminal, delete the StatefulSet again. This time, omit the -`--cascade=false` parameter. +2つ目のターミナルで、StatefulSetをもう一度削除します。今回は、`--cascade=false`パラメーターを省略します。 ```shell kubectl delete statefulset web @@ -973,8 +822,8 @@ kubectl delete statefulset web ``` statefulset.apps "web" deleted ``` -Examine the output of the `kubectl get` command running in the first terminal, -and wait for all of the Pods to transition to Terminating. + +1つ目のターミナルで実行している`kubectl get`コマンドの出力を確認し、すべてのPodがTerminatingの状態に変わるまで待ちます。 ```shell kubectl get pods -w -l app=nginx @@ -995,15 +844,10 @@ web-1 0/1 Terminating 0 29m ``` -As you saw in the [Scaling Down](#scaling-down) section, the Pods -are terminated one at a time, with respect to the reverse order of their ordinal -indices. Before terminating a Pod, the StatefulSet controller waits for -the Pod's successor to be completely terminated. +[スケールダウン](#scaling-down)のセクションで見たように、順序インデックスの逆順に従って、Podは一度に1つずつ終了します。StatefulSetコントローラーは、次のPodを終了する前に、前のPodが完全に終了するまで待ちます。 {{< note >}} -Although a cascading delete removes a StatefulSet together with its Pods, -the cascade does not delete the headless Service associated with the StatefulSet. -You must delete the `nginx` Service manually. +カスケードな削除ではStatefulSetがPodとともに削除されますが、StatefulSetと紐付けられたheadless Serviceは削除されません。そのため、`nginx`Serviceは手動で削除する必要があります。 {{< /note >}} @@ -1014,7 +858,7 @@ kubectl delete service nginx service "nginx" deleted ``` -Recreate the StatefulSet and headless Service one more time: +さらにもう一度、StatefulSetとheadless Serviceを再作成します。 ```shell kubectl apply -f web.yaml @@ -1024,8 +868,7 @@ service/nginx created statefulset.apps/web created ``` -When all of the StatefulSet's Pods transition to Running and Ready, retrieve -the contents of their `index.html` files: +StatefulSet上のすべてのPodがRunningかつReadyの状態に変わったら、Pod上の`index.html`ファイルのコンテンツを取得します。 ```shell for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done @@ -1035,11 +878,9 @@ web-0 web-1 ``` -Even though you completely deleted the StatefulSet, and all of its Pods, the -Pods are recreated with their PersistentVolumes mounted, and `web-0` and -`web-1` continue to serve their hostnames. +StatefulSetを完全に削除して、すべてのPodが削除されたとしても、PersistentVolumeがマウントされたPodが再生成されて、`web-0`と`web-1`はホスト名の配信を続けます。 -Finally, delete the `web` StatefulSet... +最後に、`web`StatefulSetを削除します。 ```shell kubectl delete service nginx @@ -1047,7 +888,7 @@ kubectl delete service nginx ``` service "nginx" deleted ``` -...and the `nginx` Service: +そして、`nginx`Serviceも削除します。 ```shell kubectl delete statefulset web ``` @@ -1055,40 +896,31 @@ kubectl delete statefulset web statefulset "web" deleted ``` -## Pod Management Policy +## Pod管理ポリシー -For some distributed systems, the StatefulSet ordering guarantees are -unnecessary and/or undesirable. These systems require only uniqueness and -identity. To address this, in Kubernetes 1.7, we introduced -`.spec.podManagementPolicy` to the StatefulSet API Object. +分散システムによっては、StatefulSetの順序の保証が不必要であったり望ましくない場合もあります。こうしたシステムでは、一意性と同一性だけが求められます。この問題に対処するために、Kubernetes 1.7でStatefulSet APIオブジェクトに`.spec.podManagementPolicy`が導入されました。 -### OrderedReady Pod Management +### OrderedReadyのPod管理 -`OrderedReady` pod management is the default for StatefulSets. It tells the -StatefulSet controller to respect the ordering guarantees demonstrated -above. +`OrderedReady`のPod管理はStatefulSetのデフォルトの設定です。StatefulSetコントローラーに対して、これまでに紹介したような順序の保証を尊重するように指示します。 -### Parallel Pod Management +### ParallelのPod管理 -`Parallel` pod management tells the StatefulSet controller to launch or -terminate all Pods in parallel, and not to wait for Pods to become Running -and Ready or completely terminated prior to launching or terminating another -Pod. +`Parallel`のPod管理では、StatefulSetコントローラーに対して、PodがRunningかつReadyの状態や完全に停止するまで待たないように指示し、すべてのPodを並列に起動または停止させるようにします。 {{< codenew file="application/web/web-parallel.yaml" >}} -Download the example above, and save it to a file named `web-parallel.yaml` +上の例をダウンロードして、`web-parallel.yaml`という名前でファイルに保存してください。 -This manifest is identical to the one you downloaded above except that the `.spec.podManagementPolicy` -of the `web` StatefulSet is set to `Parallel`. +このマニフェストは、`.spec.podManagementPolicy`が`Parallel`に設定されている以外は、前にダウンロードした`web`StatefulSetと同一です。 -In one terminal, watch the Pods in the StatefulSet. +1つ目のターミナルで、StatefulSet内のPodを監視します。 ```shell kubectl get pod -l app=nginx -w ``` -In another terminal, create the StatefulSet and Service in the manifest: +2つ目のターミナルで、マニフェスト内のStatefulSetとServiceを作成します。 ```shell kubectl apply -f web-parallel.yaml @@ -1098,7 +930,7 @@ service/nginx created statefulset.apps/web created ``` -Examine the output of the `kubectl get` command that you executed in the first terminal. +1つ目のターミナルで実行した`kubectl get`コマンドの出力を確認します。 ```shell kubectl get pod -l app=nginx -w @@ -1115,10 +947,9 @@ web-0 1/1 Running 0 10s web-1 1/1 Running 0 10s ``` -The StatefulSet controller launched both `web-0` and `web-1` at the same time. +StatefulSetコントローラーは`web-0`と`web-1`を同時に起動しています。 -Keep the second terminal open, and, in another terminal window scale the -StatefulSet: +2つ目のターミナルで、StatefulSetをスケールしてみます。 ```shell kubectl scale statefulset/web --replicas=4 @@ -1127,7 +958,7 @@ kubectl scale statefulset/web --replicas=4 statefulset.apps/web scaled ``` -Examine the output of the terminal where the `kubectl get` command is running. +`kubectl get`コマンドを実行しているターミナルの出力を確認します。 ``` web-3 0/1 Pending 0 0s @@ -1138,21 +969,19 @@ web-2 1/1 Running 0 10s web-3 1/1 Running 0 26s ``` - -The StatefulSet launched two new Pods, and it did not wait for -the first to become Running and Ready prior to launching the second. +StatefulSetが2つのPodを実行し、1つ目のPodがRunningかつReadyの状態になるのを待たずに2つ目のPodを実行しているのがわかります。 ## {{% heading "cleanup" %}} -You should have two terminals open, ready for you to run `kubectl` commands as -part of cleanup. +2つのターミナルが開かれているはずなので、クリーンアップの一部として`kubectl`コマンドを実行する準備ができています。 ```shell kubectl delete sts web -# sts is an abbreviation for statefulset +# stsは、statefulsetの略です。 ``` -You can watch `kubectl get` to see those Pods being deleted. +`kubectl get`を監視すると、Podが削除されていく様子を確認できます。 + ```shell kubectl get pod -l app=nginx -w ``` @@ -1182,22 +1011,16 @@ web-3 0/1 Terminating 0 9m web-3 0/1 Terminating 0 9m ``` -During deletion, a StatefulSet removes all Pods concurrently; it does not wait for -a Pod's ordinal successor to terminate prior to deleting that Pod. +削除の間、StatefulSetはすべてのPodを並列に削除し、順序インデックスが1つ前のPodが停止するのを待つことはありません。 -Close the terminal where the `kubectl get` command is running and delete the `nginx` -Service: +`kubectl get`コマンドを実行しているターミナルを閉じて、`nginx`Serviceを削除します。 ```shell kubectl delete svc nginx ``` - {{< note >}} -You also need to delete the persistent storage media for the PersistentVolumes -used in this tutorial. +このチュートリアルで使用したPersistentVolumeのための永続ストレージも削除する必要があります。 - -Follow the necessary steps, based on your environment, storage configuration, -and provisioning method, to ensure that all storage is reclaimed. +すべてのストレージが再利用できるようにするために、環境、ストレージの設定、プロビジョニング方法に基づいて必要な手順に従ってください。 {{< /note >}} From 26fdec3e7e61e993b9146bfdbd4d817ce8f99b86 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 15 Jun 2020 15:13:26 +0900 Subject: [PATCH 085/119] Add anchor links. --- content/ja/docs/concepts/_index.md | 4 ++-- content/ja/docs/concepts/extend-kubernetes/extend-cluster.md | 2 +- .../overview/working-with-objects/kubernetes-objects.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 0f03287083..eb3a3566dd 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -24,7 +24,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使 * **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。 * **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 -## Kubernetesオブジェクト +## Kubernetesオブジェクト {#kubernetes-objects} Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。 @@ -43,7 +43,7 @@ Kubernetesには、[コントローラー](/docs/concepts/architecture/controlle * [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) -## Kubernetesコントロールプレーン +## Kubernetesコントロールプレーン {#kubernetes-control-plane} Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。 diff --git a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md index dad9190345..6e895347bb 100644 --- a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md @@ -42,7 +42,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。 結果として、ほとんどのKubernetesユーザーは既存のエクステンションを使えばよいため、新しいエクステンションを書く必要は無いと言えます。 -## エクステンションパターン +## エクステンションパターン {#extension-patterns} Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。 Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 16d1bdd27a..801e45550c 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -2,7 +2,7 @@ title: Kubernetesオブジェクトを理解する content_type: concept weight: 10 -card: +card: name: concepts weight: 40 --- @@ -12,7 +12,7 @@ card: -## Kubernetesオブジェクトを理解する +## Kubernetesオブジェクトを理解する {#kubernetes-objects} *Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます: From 61df64c8ee49f17fdfc0c41655381f04b14dfab1 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 2 Jul 2020 14:44:36 +0900 Subject: [PATCH 086/119] Translate concepts/architecture/controller into Japanese. --- .../docs/concepts/architecture/controller.md | 156 +++++------------- 1 file changed, 42 insertions(+), 114 deletions(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index fe8965f3e2..ff857fd67a 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -1,162 +1,90 @@ --- -title: Controllers +title: コントローラー content_template: templates/concept weight: 30 --- -{{% capture overview %}} + -In robotics and automation, a _control loop_ is -a non-terminating loop that regulates the state of a system. +ロボット工学やオートメーションの分野において、 _制御ループ_ とは、あるシステムの状態を制御する終了状態のないループのことです。 -Here is one example of a control loop: a thermostat in a room. +ここでは、制御ループの一例として、部屋の中にあるサーモスタットを挙げます。 -When you set the temperature, that's telling the thermostat -about your *desired state*. The actual room temperature is the -*current state*. The thermostat acts to bring the current state -closer to the desired state, by turning equipment on or off. +あなたが温度を設定すると、それはサーモスタットに *目的の状態(desired state)* を伝えることになります。実際の部屋の温度は *現在の状態* です。サーモスタットは、装置をオンまたはオフにすることによって、現在の状態を目的の状態に近づけるように動作します。 {{< glossary_definition term_id="controller" length="short">}} -{{% /capture %}} + +## コントローラーパターン -{{% capture body %}} +コントローラーは少なくとも1種類のKubernetesのリソースを監視します。これらの[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)には目的の状態を表すspecフィールドがあります。リソースのコントローラーは、現在の状態を目的の状態に近づける責務を持ちます。 -## Controller pattern - -A controller tracks at least one Kubernetes resource type. -These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) -have a spec field that represents the desired state. The -controller(s) for that resource are responsible for making the current -state come closer to that desired state. - -The controller might carry the action out itself; more commonly, in Kubernetes, -a controller will send messages to the -{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} that have -useful side effects. You'll see examples of this below. +コントローラーは自分自身でアクションを実行する場合もありますが、Kubernetesではコントローラーが{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に意味のある副作用を持つメッセージを送信することが一般的です。以下では、このような例を見ていきます。 {{< comment >}} -Some built-in controllers, such as the namespace controller, act on objects -that do not have a spec. For simplicity, this page omits explaining that -detail. +ネームスペースコントローラーなどの一部のビルトインのコントローラーは、specのないオブジェクトに対して作用します。簡単のため、このページではそのような詳細な説明は省略します。 {{< /comment >}} -### Control via API server +### APIサーバー経由でコントロールする -The {{< glossary_tooltip term_id="job" >}} controller is an example of a -Kubernetes built-in controller. Built-in controllers manage state by -interacting with the cluster API server. +{{< glossary_tooltip term_id="job" >}}コントローラーはKubernetesのビルトインのコントローラーの一例です。ビルトインのコントローラーは、クラスターのAPIサーバーとやりとりをして状態を管理します。 -Job is a Kubernetes resource that runs a -{{< glossary_tooltip term_id="pod" >}}, or perhaps several Pods, to carry out -a task and then stop. +Jobは、1つ以上の{{< glossary_tooltip term_id="pod" >}}を起動して、タスクを実行した後に停止する、Kubernetesのリソースです。 -(Once [scheduled](/docs/concepts/scheduling/), Pod objects become part of the -desired state for a kubelet). +(1度[スケジュール](/docs/concepts/scheduling-eviction/)されると、Podオブジェクトはkubeletに対する目的の状態の一部になります。) -When the Job controller sees a new task it makes sure that, somewhere -in your cluster, the kubelets on a set of Nodes are running the right -number of Pods to get the work done. -The Job controller does not run any Pods or containers -itself. Instead, the Job controller tells the API server to create or remove -Pods. -Other components in the -{{< glossary_tooltip text="control plane" term_id="control-plane" >}} -act on the new information (there are new Pods to schedule and run), -and eventually the work is done. +Jobコントローラーが新しいタスクを見つけると、その処理が完了するように、クラスター上のどこかで、一連のNode上のkubeletが正しい数のPodを実行することを保証します。ただし、Jobコントローラーは、自分自身でPodやコンテナーを実行することはありません。代わりに、APIサーバーに対してPodの作成や削除を依頼します。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上の他のコンポーネントが(スケジュールして実行するべき新しいPodが存在するという)新しい情報を基に動作することによって、最終的に目的の処理が完了します。 -After you create a new Job, the desired state is for that Job to be completed. -The Job controller makes the current state for that Job be nearer to your -desired state: creating Pods that do the work you wanted for that Job, so that -the Job is closer to completion. +新しいJobが作成されたとき、目的の状態は、そのJobが完了することです。JobコントローラーはそのJobに対する現在の状態を目的の状態に近づけるようにします。つまり、そのJobが行ってほしい処理を実行するPodを作成し、Jobが完了に近づくようにします。 -Controllers also update the objects that configure them. -For example: once the work is done for a Job, the Job controller -updates that Job object to mark it `Finished`. +コントローラーは、コントローラーを設定するオブジェクトも更新します。たとえば、あるJobが完了した場合、Jobコントローラーは、Jobオブジェクトに`Finished`というマークを付けます。 -(This is a bit like how some thermostats turn a light off to -indicate that your room is now at the temperature you set). +(これは、部屋が設定温度になったことを示すために、サーモスタットがランプを消灯するのに少し似ています。) -### Direct control +### 直接的なコントロール -By contrast with Job, some controllers need to make changes to -things outside of your cluster. +Jobとは対照的に、クラスターの外部に変更を加える必要があるコントローラーもあります。 -For example, if you use a control loop to make sure there -are enough {{< glossary_tooltip text="Nodes" term_id="node" >}} -in your cluster, then that controller needs something outside the -current cluster to set up new Nodes when needed. +たとえば、クラスターに十分な数の{{< glossary_tooltip text="Node" term_id="node" >}}が存在することを保証する制御ループの場合、そのコントローラーは、必要に応じて新しいNodeをセットアップするために、現在のクラスターの外部とやりとりをする必要があります。 -Controllers that interact with external state find their desired state from -the API server, then communicate directly with an external system to bring -the current state closer in line. +外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。 -(There actually is a controller that horizontally scales the -nodes in your cluster. See -[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). +(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。) -## Desired versus current state {#desired-vs-current} +## 目的の状態 vs 現在の状態 {#desired-vs-current} -Kubernetes takes a cloud-native view of systems, and is able to handle -constant change. +Kubernetesはシステムに対してクラウドネイティブな見方をするため、常に変化し続けるような状態を扱えるように設計されています。 -Your cluster could be changing at any point as work happens and -control loops automatically fix failures. This means that, -potentially, your cluster never reaches a stable state. +処理を実行したり、制御ループが故障を自動的に修正したりしているどの時点でも、クラスターは変化中である可能性があります。つまり、クラスターは決して安定した状態にならない可能性があるということです。 -As long as the controllers for your cluster are running and able to make -useful changes, it doesn't matter if the overall state is or is not stable. +コントローラーがクラスターのために実行されていて、有用な変更が行われるのであれば、全体的な状態が安定しているかどうかは問題にはなりません。 -## Design +## 設計 -As a tenet of its design, Kubernetes uses lots of controllers that each manage -a particular aspect of cluster state. Most commonly, a particular control loop -(controller) uses one kind of resource as its desired state, and has a different -kind of resource that it manages to make that desired state happen. +設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 -It's useful to have simple controllers rather than one, monolithic set of control -loops that are interlinked. Controllers can fail, so Kubernetes is designed to -allow for that. +相互にリンクされた単一のモノリシックな制御ループよりは、複数のシンプルなコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 -For example: a controller for Jobs tracks Job objects (to discover -new work) and Pod object (to run the Jobs, and then to see when the work is -finished). In this case something else creates the Jobs, whereas the Job -controller creates Pods. +たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 {{< note >}} -There can be several controllers that create or update the same kind of object. -Behind the scenes, Kubernetes controllers make sure that they only pay attention -to the resources linked to their controlling resource. +同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。 -For example, you can have Deployments and Jobs; these both create Pods. -The Job controller does not delete the Pods that your Deployment created, -because there is information ({{< glossary_tooltip term_id="label" text="labels" >}}) -the controllers can use to tell those Pods apart. +たとえば、DeploymentとJobがありますが、これらは両方ともPodを作成するものです。しかし、JobコントローラーはDeploymentが作成したPodを削除することはありません。各コントローラーが2つのPodを区別できる情報({{< glossary_tooltip term_id="label" text="ラベル" >}})が存在するためです。 {{< /note >}} -## Ways of running controllers {#running-controllers} +## コントローラーを実行する方法 {#running-controllers} -Kubernetes comes with a set of built-in controllers that run inside -the {{< glossary_tooltip term_id="kube-controller-manager" >}}. These -built-in controllers provide important core behaviors. +Kubernetesには、{{< glossary_tooltip term_id="kube-controller-manager" >}}内部で動作する一組のビルトインのコントローラーが用意されています。これらビルトインのコントローラーは、コアとなる重要な振る舞いを提供します。 -The Deployment controller and Job controller are examples of controllers that -come as part of Kubernetes itself (“built-in” controllers). -Kubernetes lets you run a resilient control plane, so that if any of the built-in -controllers were to fail, another part of the control plane will take over the work. +DeploymentコントローラーとJobコントローラーは、Kubernetes自体の一部として同梱されているコントローラーの例です(それゆえ「ビルトイン」のコントローラーと呼ばれます)。Kubernetesは回復性のあるコントロールプレーンを実行できるようにしているため、ビルトインのコントローラーの一部が故障しても、コントロールプレーンの別の部分が作業を引き継いでくれます。 -You can find controllers that run outside the control plane, to extend Kubernetes. -Or, if you want, you can write a new controller yourself. -You can run your own controller as a set of Pods, -or externally to Kubernetes. What fits best will depend on what that particular -controller does. +Kubernetesを拡張するためにコントロールプレーンの外で動作するコントローラーもあります。もし望むなら、新しいコントローラーを自分で書くこともできます。自作のコントローラーをPodセットとして動作させたり、Kubernetesの外部で動作させることもできます。どのような動作方法が最も適しているかは、そのコントローラーがどのようなことを行うのかに依存します。 -{{% /capture %}} +## {{% heading "whatsnext" %}} -{{% capture whatsnext %}} -* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) -* Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects) -* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) -* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes. -{{% /capture %}} +* [Kubernetesコントロールプレーン](/ja/docs/concepts/#kubernetes-control-plane)について読む +* 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ +* [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ +* 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。 From c4075c109eb8a7abc5fbada46dc682dd47d7a99b Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 4 Jul 2020 21:46:19 +0900 Subject: [PATCH 087/119] ja: Make docs/setup/production-environment/on-premises-vm/_index.md follow v1.17 of the original text --- .../docs/setup/production-environment/on-premises-vm/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/on-premises-vm/_index.md b/content/ja/docs/setup/production-environment/on-premises-vm/_index.md index a8dcf3523c..6de2892840 100644 --- a/content/ja/docs/setup/production-environment/on-premises-vm/_index.md +++ b/content/ja/docs/setup/production-environment/on-premises-vm/_index.md @@ -1,4 +1,4 @@ --- title: オンプレミスVM -weight: 60 +weight: 40 --- From 891a4732330e5635fe3a94e9dbc8af4c065140e3 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 4 Jul 2020 22:18:34 +0900 Subject: [PATCH 088/119] Copy content/en/docs/tutorials/statelful-application/mysql-wordpress-persistent-volume.md to Translate. --- .../mysql-wordpress-persistent-volume.md | 243 ++++++++++++++++++ 1 file changed, 243 insertions(+) create mode 100644 content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md new file mode 100644 index 0000000000..e93658f10d --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -0,0 +1,243 @@ +--- +title: "Example: Deploying WordPress and MySQL with Persistent Volumes" +content_type: tutorial +weight: 20 +card: + name: tutorials + weight: 40 + title: "Stateful Example: Wordpress with Persistent Volumes" +--- + + +This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data. + +A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. + +{{< warning >}} +This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production. +{{< /warning >}} + +{{< note >}} +The files provided in this tutorial are using GA Deployment APIs and are specific to kubernetes version 1.9 and later. If you wish to use this tutorial with an earlier version of Kubernetes, please update the API version appropriately, or reference earlier versions of this tutorial. +{{< /note >}} + + + +## {{% heading "objectives" %}} + +* Create PersistentVolumeClaims and PersistentVolumes +* Create a `kustomization.yaml` with + * a Secret generator + * MySQL resource configs + * WordPress resource configs +* Apply the kustomization directory by `kubectl apply -k ./` +* Clean up + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +The example shown on this page works with `kubectl` 1.14 and above. + +Download the following configuration files: + +1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml) + +1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) + + + + + +## Create PersistentVolumeClaims and PersistentVolumes + +MySQL and Wordpress each require a PersistentVolume to store data. Their PersistentVolumeClaims will be created at the deployment step. + +Many cluster environments have a default StorageClass installed. When a StorageClass is not specified in the PersistentVolumeClaim, the cluster's default StorageClass is used instead. + +When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provisioned based on the StorageClass configuration. + +{{< warning >}} +In local clusters, the default StorageClass uses the `hostPath` provisioner. `hostPath` volumes are only suitable for development and testing. With `hostPath` volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, or the node is rebooted, the data is lost. +{{< /warning >}} + +{{< note >}} +If you are bringing up a cluster that needs to use the `hostPath` provisioner, the `--enable-hostpath-provisioner` flag must be set in the `controller-manager` component. +{{< /note >}} + +{{< note >}} +If you have a Kubernetes cluster running on Google Kubernetes Engine, please follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk). +{{< /note >}} + +## Create a kustomization.yaml + +### Add a Secret generator +A [Secret](/docs/concepts/configuration/secret/) is an object that stores a piece of sensitive data like a password or key. Since 1.14, `kubectl` supports the management of Kubernetes objects using a kustomization file. You can create a Secret by generators in `kustomization.yaml`. + +Add a Secret generator in `kustomization.yaml` from the following command. You will need to replace `YOUR_PASSWORD` with the password you want to use. + +```shell +cat <./kustomization.yaml +secretGenerator: +- name: mysql-pass + literals: + - password=YOUR_PASSWORD +EOF +``` + +## Add resource configs for MySQL and WordPress + +The following manifest describes a single-instance MySQL Deployment. The MySQL container mounts the PersistentVolume at /var/lib/mysql. The `MYSQL_ROOT_PASSWORD` environment variable sets the database password from the Secret. + +{{< codenew file="application/wordpress/mysql-deployment.yaml" >}} + +The following manifest describes a single-instance WordPress Deployment. The WordPress container mounts the +PersistentVolume at `/var/www/html` for website data files. The `WORDPRESS_DB_HOST` environment variable sets +the name of the MySQL Service defined above, and WordPress will access the database by Service. The +`WORDPRESS_DB_PASSWORD` environment variable sets the database password from the Secret kustomize generated. + +{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}} + +1. Download the MySQL deployment configuration file. + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml + ``` + +2. Download the WordPress configuration file. + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml + ``` + +3. Add them to `kustomization.yaml` file. + +```shell +cat <>./kustomization.yaml +resources: + - mysql-deployment.yaml + - wordpress-deployment.yaml +EOF +``` + +## Apply and Verify +The `kustomization.yaml` contains all the resources for deploying a WordPress site and a +MySQL database. You can apply the directory by +```shell +kubectl apply -k ./ +``` + +Now you can verify that all objects exist. + +1. Verify that the Secret exists by running the following command: + + ```shell + kubectl get secrets + ``` + + The response should be like this: + + ```shell + NAME TYPE DATA AGE + mysql-pass-c57bb4t7mf Opaque 1 9s + ``` + +2. Verify that a PersistentVolume got dynamically provisioned. + + ```shell + kubectl get pvc + ``` + + {{< note >}} + It can take up to a few minutes for the PVs to be provisioned and bound. + {{< /note >}} + + The response should be like this: + + ```shell + NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE + mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + ``` + +3. Verify that the Pod is running by running the following command: + + ```shell + kubectl get pods + ``` + + {{< note >}} + It can take up to a few minutes for the Pod's Status to be `RUNNING`. + {{< /note >}} + + The response should be like this: + + ``` + NAME READY STATUS RESTARTS AGE + wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s + ``` + +4. Verify that the Service is running by running the following command: + + ```shell + kubectl get services wordpress + ``` + + The response should be like this: + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + ``` + + {{< note >}} + Minikube can only expose Services through `NodePort`. The EXTERNAL-IP is always pending. + {{< /note >}} + +5. Run the following command to get the IP Address for the WordPress Service: + + ```shell + minikube service wordpress --url + ``` + + The response should be like this: + + ``` + http://1.2.3.4:32406 + ``` + +6. Copy the IP address, and load the page in your browser to view your site. + + You should see the WordPress set up page similar to the following screenshot. + + ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png) + +{{< warning >}} +Do not leave your WordPress installation on this page. If another user finds it, they can set up a website on your instance and use it to serve malicious content.

Either install WordPress by creating a username and password or delete your instance. +{{< /warning >}} + + + +## {{% heading "cleanup" %}} + + +1. Run the following command to delete your Secret, Deployments, Services and PersistentVolumeClaims: + + ```shell + kubectl delete -k ./ + ``` + + + +## {{% heading "whatsnext" %}} + + +* Learn more about [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/) +* Learn more about [Jobs](/docs/concepts/workloads/controllers/job/) +* Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) +* Learn how to [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/) + + + From 499718bcabcb0e3b2352dd80dd69631239bf0f62 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 5 Jul 2020 00:44:50 +0900 Subject: [PATCH 089/119] Translate tutorials/stateful-application/mysql-wordpress-persistent-volume/ into Japanese. --- .../mysql-wordpress-persistent-volume.md | 120 +++++++++--------- 1 file changed, 60 insertions(+), 60 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index e93658f10d..47c37f9024 100644 --- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -1,37 +1,37 @@ --- -title: "Example: Deploying WordPress and MySQL with Persistent Volumes" +title: "例: Persistent Volumeを使用したWordpressとMySQLをデプロイする" content_type: tutorial weight: 20 card: name: tutorials weight: 40 - title: "Stateful Example: Wordpress with Persistent Volumes" + title: "ステートフルの例: Persistent Volumeを使用したWordpress" --- -This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data. +このチュートリアルでは、WordPressのサイトとMySQLデータベースをMinikubeを使ってデプロイする方法を紹介します。2つのアプリケーションとも、データを保存するためにPersistentVolumeとPersistentVolumeClaimを使用します。 -A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. +[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)(PV)とは、管理者が手動でプロビジョニングを行うか、[StorageClass](/docs/concepts/storage/storage-classes)を使ってKubernetesによって動的にプロビジョニングされた、ストレージから切り出された部分のことです。[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)は、PVによって満たすことができる、ユーザーによるストレージへのリクエストのことです。PersistentVolumeとPersistentVolumeClaimは、Podのライフサイクルからは独立していて、Podの再起動、Podの再スケジューリング、さらにはPodの削除が行われたとしても、その中のデータは削除されずに残ります。 {{< warning >}} -This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production. +シングルインスタンスのWordPressとMySQLのPodを使用しているため、ここで行うデプロイは本番のユースケースには適しません。WordPressを本番環境にデプロイするときは、[WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)を使用することを検討してください。 {{< /warning >}} {{< note >}} -The files provided in this tutorial are using GA Deployment APIs and are specific to kubernetes version 1.9 and later. If you wish to use this tutorial with an earlier version of Kubernetes, please update the API version appropriately, or reference earlier versions of this tutorial. +このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、PAIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。 {{< /note >}} ## {{% heading "objectives" %}} -* Create PersistentVolumeClaims and PersistentVolumes -* Create a `kustomization.yaml` with - * a Secret generator - * MySQL resource configs - * WordPress resource configs -* Apply the kustomization directory by `kubectl apply -k ./` -* Clean up +* PersistentVolumeClaimとPersistentVolumeを作成する +* 以下を含む`kustomization.yaml`を作成する + * Secret generator + * MySQLリソースの設定 + * WordPressリソースの設定 +* kustomizationディレクトリを`kubectl apply -k ./`で適用する +* クリーンアップする @@ -39,9 +39,9 @@ The files provided in this tutorial are using GA Deployment APIs and are specifi {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -The example shown on this page works with `kubectl` 1.14 and above. +このページで示された例は、`kubectl` 1.14以降で動作します。 -Download the following configuration files: +以下の設定ファイルをダウンロードします。 1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml) @@ -51,32 +51,33 @@ Download the following configuration files: -## Create PersistentVolumeClaims and PersistentVolumes +## PersistentVolumeClaimとPersistentVolumeを作成する -MySQL and Wordpress each require a PersistentVolume to store data. Their PersistentVolumeClaims will be created at the deployment step. +MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。 -Many cluster environments have a default StorageClass installed. When a StorageClass is not specified in the PersistentVolumeClaim, the cluster's default StorageClass is used instead. +多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。 -When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provisioned based on the StorageClass configuration. +PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。 {{< warning >}} -In local clusters, the default StorageClass uses the `hostPath` provisioner. `hostPath` volumes are only suitable for development and testing. With `hostPath` volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, or the node is rebooted, the data is lost. +ローカルのクラスターでは、デフォルトのStorageClassには`hostPath`プロビジョナーが使われます。`hostPath`ボリュームは開発およびテストにのみ適しています。`hostPath`ボリュームでは、データはPodがスケジュールされたノード上の`/tmp`内に保存されます。そのため、もしPodが死んだり、クラスター上の他のノードにスケジュールされたり、ノードが再起動すると、データは失われます。 {{< /warning >}} {{< note >}} -If you are bringing up a cluster that needs to use the `hostPath` provisioner, the `--enable-hostpath-provisioner` flag must be set in the `controller-manager` component. +`hostPath`プロビジョナーを使う必要があるクラスターを立ち上げたい場合は、`controller-manager`内に`--enable-hostpath-provisioner`フラグを設定しなければなりません。 {{< /note >}} {{< note >}} -If you have a Kubernetes cluster running on Google Kubernetes Engine, please follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk). +Google Kubernetes Engine上で動作するKubernetesクラスターを使っている場合は、[このガイド](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk?hl=ja)に従ってください。 {{< /note >}} -## Create a kustomization.yaml +## kustomization.yamlを作成する -### Add a Secret generator -A [Secret](/docs/concepts/configuration/secret/) is an object that stores a piece of sensitive data like a password or key. Since 1.14, `kubectl` supports the management of Kubernetes objects using a kustomization file. You can create a Secret by generators in `kustomization.yaml`. +### Secret generatorを追加する -Add a Secret generator in `kustomization.yaml` from the following command. You will need to replace `YOUR_PASSWORD` with the password you want to use. +[Secret](/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。 + +以下のコマンドを実行して、`kustomization.yaml`の中にSecret generatorを追加します。`YOUR_PASSWORD`の部分を使いたいパスワードに置換してください。 ```shell cat <./kustomization.yaml @@ -87,32 +88,30 @@ secretGenerator: EOF ``` -## Add resource configs for MySQL and WordPress +## MySQLとWordPressのためのリソースの設定を追加する -The following manifest describes a single-instance MySQL Deployment. The MySQL container mounts the PersistentVolume at /var/lib/mysql. The `MYSQL_ROOT_PASSWORD` environment variable sets the database password from the Secret. +以下のマニフェストには、シングルインスタンスのMySQLのDeploymentが書かれています。MySQLコンテナはPersistentVolumeを`/var/lib/mysql`にマウントします。`MYSQL_ROOT_PASSWORD`環境変数には、Secretから得られたデータベースのパスワードが設定されます。 {{< codenew file="application/wordpress/mysql-deployment.yaml" >}} -The following manifest describes a single-instance WordPress Deployment. The WordPress container mounts the -PersistentVolume at `/var/www/html` for website data files. The `WORDPRESS_DB_HOST` environment variable sets -the name of the MySQL Service defined above, and WordPress will access the database by Service. The -`WORDPRESS_DB_PASSWORD` environment variable sets the database password from the Secret kustomize generated. +以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータバースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。 + {{< codenew file="application/wordpress/wordpress-deployment.yaml" >}} -1. Download the MySQL deployment configuration file. +1. MySQLのDeploymentの設定ファイルをダウンロードします。 ```shell curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml ``` -2. Download the WordPress configuration file. +2. WordPressの設定ファイルをダウンロードします。 ```shell curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml ``` -3. Add them to `kustomization.yaml` file. +3. これらを`kustomization.yaml`ファイルに追加します。 ```shell cat <>./kustomization.yaml @@ -122,39 +121,40 @@ resources: EOF ``` -## Apply and Verify -The `kustomization.yaml` contains all the resources for deploying a WordPress site and a -MySQL database. You can apply the directory by +## 適用と確認 + +`kustomization.yaml`には、WordPressのサイトとMySQLデータベースのためのすべてのリソースが含まれています。次のコマンドでこのディレクトリを適用できます。 + ```shell kubectl apply -k ./ ``` -Now you can verify that all objects exist. +これで、すべてのオブジェクトが存在していることを確認できます。 -1. Verify that the Secret exists by running the following command: +1. 次のコマンドを実行して、Secretが存在していることを確認します。 ```shell kubectl get secrets ``` - The response should be like this: + 結果は次のようになるはずです。 ```shell NAME TYPE DATA AGE mysql-pass-c57bb4t7mf Opaque 1 9s ``` -2. Verify that a PersistentVolume got dynamically provisioned. +1. 次のコマンドを実行して、PersistentVolumeが動的にプロビジョニングされていることを確認します。 ```shell kubectl get pvc ``` {{< note >}} - It can take up to a few minutes for the PVs to be provisioned and bound. + PVがプロビジョニングされてバインドされるまでに、最大で数分かかる場合があります。 {{< /note >}} - The response should be like this: + 結果は次のようになるはずです。 ```shell NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE @@ -162,30 +162,30 @@ Now you can verify that all objects exist. wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s ``` -3. Verify that the Pod is running by running the following command: +3. 次のコマンドを実行して、Podが実行中であることを確認します。 ```shell kubectl get pods ``` {{< note >}} - It can take up to a few minutes for the Pod's Status to be `RUNNING`. + PodのStatusが`Running`の状態になる前に、最大で数分かかる場合があります。 {{< /note >}} - The response should be like this: + 結果は次のようになるはずです。 ``` NAME READY STATUS RESTARTS AGE wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s ``` -4. Verify that the Service is running by running the following command: +4. 次のコマンドを実行して、Serviceが実行中であることを確認します。 ```shell kubectl get services wordpress ``` - The response should be like this: + 結果は次のようになるはずです。 ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE @@ -193,29 +193,29 @@ Now you can verify that all objects exist. ``` {{< note >}} - Minikube can only expose Services through `NodePort`. The EXTERNAL-IP is always pending. + MinikubeではServiceを`NodePort`経由でしか公開できません。EXTERNAL-IPは常にpendingのままになります。 {{< /note >}} -5. Run the following command to get the IP Address for the WordPress Service: +5. 次のコマンドを実行して、WordPress ServiceのIPアドレスを取得します。 ```shell minikube service wordpress --url ``` - The response should be like this: + 結果は次のようになるはずです。 ``` http://1.2.3.4:32406 ``` -6. Copy the IP address, and load the page in your browser to view your site. +6. IPアドレスをコピーして、ブラウザーで読み込み、サイトを表示しましょう。 - You should see the WordPress set up page similar to the following screenshot. + WordPressによりセットアップされた次のスクリーンショットのようなページが表示されるはずです。 ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png) {{< warning >}} -Do not leave your WordPress installation on this page. If another user finds it, they can set up a website on your instance and use it to serve malicious content.

Either install WordPress by creating a username and password or delete your instance. +WordPressのインストールをこのページのまま放置してはいけません。もしほかのユーザーがこのページを見つけた場合、その人はインスタンス上にウェブサイトをセットアップして、悪意のあるコンテンツの配信に利用できてしまいます。

ユーザー名とパスワードを決めてWordPressをインストールするか、このインスタンスを削除してください。 {{< /warning >}} @@ -223,7 +223,7 @@ Do not leave your WordPress installation on this page. If another user finds it, ## {{% heading "cleanup" %}} -1. Run the following command to delete your Secret, Deployments, Services and PersistentVolumeClaims: +1. 次のコマンドを実行して、Secret、Deployment、Service、およびPersistentVolumeClaimを削除します。 ```shell kubectl delete -k ./ @@ -234,10 +234,10 @@ Do not leave your WordPress installation on this page. If another user finds it, ## {{% heading "whatsnext" %}} -* Learn more about [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/) -* Learn more about [Jobs](/docs/concepts/workloads/controllers/job/) -* Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) -* Learn how to [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/) +* [イントロスペクションとデバッグ](/docs/tasks/debug-application-cluster/debug-application-introspection/)についてさらに学ぶ +* [Job](/docs/concepts/workloads/controllers/job/)についてさらに学ぶ +* [Portフォワーディング](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)についてさらに学ぶ +* [コンテナへのシェルを取得する](/ja/docs/tasks/debug-application-cluster/get-shell-running-container/)方法について学ぶ From fb6a07074827be31520d748a2fbf0f34ad3de19f Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 5 Jul 2020 01:05:08 +0900 Subject: [PATCH 090/119] Add _index.md for tutorials/stateful-application. --- content/ja/docs/tutorials/stateful-application/_index.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 content/ja/docs/tutorials/stateful-application/_index.md diff --git a/content/ja/docs/tutorials/stateful-application/_index.md b/content/ja/docs/tutorials/stateful-application/_index.md new file mode 100644 index 0000000000..421915d42c --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "ステートフルアプリケーション" +weight: 50 +--- + From b2a85692d3c0468a4cecdd1a805d5aadcc965fdd Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Fri, 3 Jul 2020 02:23:27 +0900 Subject: [PATCH 091/119] Add Japanese translation of taint-and-toleration.md --- .../scheduling/taint-and-toleration.md | 221 ++++++++++++++++++ 1 file changed, 221 insertions(+) create mode 100644 content/ja/docs/concepts/scheduling/taint-and-toleration.md diff --git a/content/ja/docs/concepts/scheduling/taint-and-toleration.md b/content/ja/docs/concepts/scheduling/taint-and-toleration.md new file mode 100644 index 0000000000..21c047fcb6 --- /dev/null +++ b/content/ja/docs/concepts/scheduling/taint-and-toleration.md @@ -0,0 +1,221 @@ +--- +title: TaintとToleration +content_type: concept +weight: 40 +--- + + + +[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は +{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。 反対に_Taint_はNodeがある種のPodを排除できるようにします。 + +_Toleration_はPodに適用され、一致するTaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。 + +TaintとTolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。TaintはNodeに一つまたは複数個付与することができます。これはそのNodeがTaintを許容しないPodを受け入れるべきではないことを示します。 + + + + +## コンセプト + +NodeにTaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。 +例えば、次のコマンドは + +```shell +kubectl taint nodes node1 key=value:NoSchedule +``` + +`node1`にTaintを設定します。このTaintのキーは`key`、値は`value`、Taintの効果は`NoSchedule`です。 +これは`node1`にはPodに合致するTolerationがなければスケジューリングされないことを意味します。 + +上記のコマンドで付与したTaintを外すには、下記のコマンドを使います。 +```shell +kubectl taint nodes node1 key:NoSchedule- +``` + +PodのTolerationはPodSpecの中に指定します。下記のTolerationはどちらも、上記の`kubectl taint`コマンドで追加したTaintと合致するため、どちらのTolerationが設定されたPodも`node1`へスケジューリングされることができます。 + +```yaml +tolerations: +- key: "key" + operator: "Equal" + value: "value" + effect: "NoSchedule" +``` + +```yaml +tolerations: +- key: "key" + operator: "Exists" + effect: "NoSchedule" +``` + +Tolerationを設定したPodの例を示します。 + +{{< codenew file="pods/pod-with-toleration.yaml" >}} + +`operator`のデフォルトは`Equal`です。 + +TolerationがTaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。 + +* `operator`が`Exists`（`value`を指定すべきでない場合） +* `operator`が`Equal`であり、かつ`value`が同一である場合 + +{{< note >}} + +2つ特殊な場合があります。 + +空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのTaintと合致します。 + +空の`effect`は`key`が一致する全てのeffectと合致します。 + +{{< /note >}} + +上記の例では`effect`に`NoSchedule`を指定しました。代わりに、`effect`に`PreferNoSchedule`を指定することができます。 +これは`NoSchedule`の「ソフトな」バージョンであり、システムはTaintに対応するTolerationが設定されていないPodがNodeへ配置されることを避けようとしますが、必須の条件とはしません。3つ目の`effect`の値として`NoExecute`がありますが、これについては後述します。 + +同一のNodeに複数のTaintを付与することや、同一のPodに複数のTolerationを設定することができます。 +複数のTaintやTolerationが設定されている場合、Kubernetesはフィルタのように扱います。最初はNodeの全てのTaintがある状態から始め、Podが対応するTolerationを持っているTaintは無視され外されていきます。無視されずに残ったTaintが効果を及ぼします。 +具体的には、 + +* effect `NoSchedule`のTaintが無視されず残った場合、KubernetesはそのPodをNodeへスケジューリングしません。 +* effect `NoSchedule`のTaintは残らず、effect `PreferNoSchedule`のTaintは残った場合、KubernetesはそのNodeへのスケジューリングをしないように試みます。 +* effect `NoExecute`のTaintが残った場合、既に稼働中のPodはそのNodeから排除され、まだ稼働していないPodはスケジューリングされないようになります。 + +例として、下記のようなTaintが付与されたNodeを考えます。 + +```shell +kubectl taint nodes node1 key1=value1:NoSchedule +kubectl taint nodes node1 key1=value1:NoExecute +kubectl taint nodes node1 key2=value2:NoSchedule +``` + +Podには2つのTolerationが設定されています。 + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoSchedule" +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" +``` + +この例では、3つ目のTaintと合致するTolerationがないため、PodはNodeへはスケジューリングされません。 +しかし、これらのTaintが追加された時点で、そのNodeでPodが稼働していれば続けて稼働することが可能です。 これは、PodのTolerationと合致しないTaintは3つあるTaintのうちの3つ目のTaintのみであり、それが`NoSchedule`であるためです。 + +一般に、effect `NoExecute`のTaintがNodeに追加されると、合致するTolerationが設定されていないPodは即時にNodeから排除され、合致するTolerationが設定されたPodが排除されることは決してありません。 +しかし、effect`NoExecute`に対するTolerationは`tolerationSeconds`フィールドを任意で指定することができ、これはTaintが追加された後にそのNodeにPodが残る時間を示します。例えば、 + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" + tolerationSeconds: 3600 +``` + +この例のPodが稼働中で、対応するTaintがNodeへ追加された場合、PodはそのNodeに3600秒残り、その後排除されます。仮にTaintがそれよりも前に外された場合、Podは排除されません。 + +## ユースケースの例 + +TaintとTolerationは、実行されるべきではないNodeからPodを遠ざけたり、排除したりするための柔軟な方法です。いくつかのユースケースを示します。 + +* **専有Node**: あるNode群を特定のユーザーに専有させたい場合、そのNode群へTaintを追加し(`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) 対応するTolerationをPodへ追加します（これを実現する最も容易な方法はカスタム +[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を書くことです）。 +Tolerationが設定されたPodはTaintの設定された（専有の）Nodeと、クラスターにあるその他のNodeの使用が認められます。もしPodが必ず専有Node*のみ*を使うようにしたい場合は、Taintと同様のラベルをそのNode群に設定し(例: `dedicated=groupName`)、アドミッションコントローラーはNodeアフィニティを使ってPodが`dedicated=groupName`のラベルの付いたNodeへスケジューリングすることが必要であるということも設定する必要があります。 + +* **特殊なハードウェアを備えるNode**: クラスターの中の少数のNodeが特殊なハードウェア（例えばGPU）を備える場合、そのハードウェアを必要としないPodがスケジューリングされないようにして、後でハードウェアを必要とするPodができたときの余裕を確保したいことがあります。 +これは特殊なハードウェアを持つNodeにTaintを追加(例えば `kubectl taint nodes nodename special=true:NoSchedule` または +`kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するTolerationを追加することで可能です。 +専有Nodeのユースケースと同様に、Tolerationを容易に適用する方法はカスタム +[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を使うことです。 +例えば、特殊なハードウェアを表すために[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +を使い、ハードウェアを備えるNodeに拡張リソースの名称のTaintを追加して、 +[拡張リソースToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) +アドミッションコントローラーを実行することが推奨されます。NodeにはTaintが付与されているため、TolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースToleration` アドミッションコントローラーはPodに自動的に適切なTolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。 +これは特殊なハードウェアを備えたNodeではそれを必要とするPodのみが稼働し、Podに対して手作業でTolerationを追加しなくて済むようにします。 + +* **Taintを基にした排除**: Nodeに問題が起きたときにPodごとに排除する設定を行うことができます。次のセクションにて説明します。 + +## Taintを基にした排除 + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +上述したように、effect `NoExecute`のTaintはNodeで実行中のPodに次のような影響を与えます。 + + * 対応するTolerationのないPodは即座に除外される + * 対応するTolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける + * 対応するTolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される + +Nodeコントローラーは特定の条件を満たす場合に自動的にTaintを追加します。 +組み込まれているTaintは下記の通りです。 + + * `node.kubernetes.io/not-ready`: Nodeの準備ができていない場合。これはNodeCondition `Ready`が`False`である場合に対応します。 + * `node.kubernetes.io/unreachable`: NodeがNodeコントローラーから到達できない場合。これはNodeCondition`Ready`が`Unknown`の場合に対応します。 + * `node.kubernetes.io/out-of-disk`: Nodeのディスクの空きがない場合。 + * `node.kubernetes.io/memory-pressure`: Nodeのメモリーが不足している場合。 + * `node.kubernetes.io/disk-pressure`: Nodeのディスクが不足している場合。 + * `node.kubernetes.io/network-unavailable`: Nodeのネットワークが利用できない場合。 + * `node.kubernetes.io/unschedulable`: Nodeがスケジューリングできない場合。 + * `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるTaintで、このNodeは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのNodeを初期化した後にkubeletはこのTaintを外します。 + +Nodeから追い出すときには、Nodeコントローラーまたはkubeletは関連するTaintを`NoExecute`効果の状態で追加します。 +不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはNodeコントローラーは関連するTaintを外すことができます。 + +{{< note >}} +コントロールプレーンは新しいTaintをNodeに加えるレートを制限しています。 +このレート制限は一度に多くのNodeが到達不可能になった場合（例えばネットワークの断絶）に、退役させられるNodeの数を制御します。 +{{< /note >}} + +Podに`tolerationSeconds`を指定することで不具合があるか応答のないNodeに残る時間を指定することができます。 + +例えば、ローカルの状態を多数持つアプリケーションとネットワークが分断された場合を考えます。ネットワークが復旧して、Podを排除しなくて済むことを見込んで、長時間Nodeから排除されないようにしたいこともあるでしょう。 +この場合Podに設定するTolerationは次のようになります。 + +```yaml +tolerations: +- key: "node.kubernetes.io/unreachable" + operator: "Exists" + effect: "NoExecute" + tolerationSeconds: 6000 +``` + +{{< note >}} +Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的に`node.kubernetes.io/not-ready`と`node.kubernetes.io/unreachable`に対するTolerationを`tolerationSeconds=300`にて設定します。 + +自動的に設定されるTolerationは、Taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。 +{{< /note >}} + +[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のTaintに対して`NoExecute`のTolerationが`tolerationSeconds`を指定せずに設定されます。 + + * `node.kubernetes.io/unreachable` + * `node.kubernetes.io/not-ready` + +これはDaemonSetのPodはこれらの問題によって排除されないことを保証します。 + +## 条件によるTaintの付与 + +NodeのライフサイクルコントローラーはNodeの状態に応じて`NoSchedule`効果のTaintを付与します。 +スケジューラーはNodeの状態ではなく、Taintを確認します。 +Nodeに何がスケジューリングされるかは、そのNodeの状態に影響されないことを保証します。ユーザーは適切なTolerationをPodに付与することで、どの種類のNodeの問題を無視するかを選ぶことができます。 + +DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐために自動的に次の`NoSchedule`Tolerationを全てのDaemonSetに付与します。 + + * `node.kubernetes.io/memory-pressure` + * `node.kubernetes.io/disk-pressure` + * `node.kubernetes.io/out-of-disk` (*重要なPodのみ*) + * `node.kubernetes.io/unschedulable` (1.10またはそれ以降) + * `node.kubernetes.io/network-unavailable` (*ホストネットワークのみ*) + +これらのTolerationを追加することは後方互換性を保証します。DaemonSetに任意のTolerationを加えることもできます。 + + +## {{% heading "whatsnext" %}} + +* [リソース枯渇の対処](/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む +* [Podの優先度](/docs/concepts/configuration/pod-priority-preemption/)を読む From 1e191062ec6cd7d57919f7bf45aa6533703fa5d8 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 5 Jul 2020 11:44:24 +0900 Subject: [PATCH 092/119] =?UTF-8?q?Fix=20typo:=20Deploymnet=E2=86=92Deploy?= =?UTF-8?q?ment.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/workloads/controllers/deployment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 8fae6041e8..f3b210ff4a 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -3,7 +3,7 @@ title: Deployment feature: title: 自動化されたロールアウトとロールバック description: > - Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。 + Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。 content_type: concept weight: 30 @@ -1001,7 +1001,7 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成 Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。 -`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymnetの更新頻度と安定性に依存します。 +`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。 さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。 From eb19a090a3c7e1c70a73f14041c76c422b16f4d1 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 5 Jul 2020 19:44:09 +0900 Subject: [PATCH 093/119] ja: Make docs/setup/production-environment/turnkey/_index.md follow v1.17 of the original text --- content/ja/docs/setup/production-environment/turnkey/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/turnkey/_index.md b/content/ja/docs/setup/production-environment/turnkey/_index.md index c39cd2a714..6b9dabb7ab 100644 --- a/content/ja/docs/setup/production-environment/turnkey/_index.md +++ b/content/ja/docs/setup/production-environment/turnkey/_index.md @@ -1,4 +1,4 @@ --- title: ターンキークラウドソリューション -weight: 40 +weight: 30 --- From 3e42dcd9376688af291538b5f07bfe746227b0eb Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 5 Jul 2020 19:58:07 +0900 Subject: [PATCH 094/119] Update content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md Co-authored-by: inductor(Kohei) --- .../environment-variable-expose-pod-information.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index c2e4f1f1b4..a6679de198 100644 --- a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -6,7 +6,7 @@ weight: 30 -このページでは、Podが環境変数を使用して、Pod内で実行されているコンテナに自分自身の情報を共有する方法を説明します。環境変数を使うと、Podのフィールドとコンテナのフィールドを共有できます。 +このページでは、Podが内部で実行しているコンテナに自身の情報を共有する方法を説明します。環境変数ではPodのフィールドとコンテナのフィールドを共有することができます。 @@ -147,4 +147,3 @@ kubectl logs dapi-envars-resourcefieldref * [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) - From 2bea5957c4ded3cb285f9776eab91a8d782d4a64 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 5 Jul 2020 22:05:41 +0900 Subject: [PATCH 095/119] ja: remove docs/setup/production-environment/turnkey/stackpoint.md --- .../turnkey/stackpoint.md | 187 ------------------ 1 file changed, 187 deletions(-) delete mode 100644 content/ja/docs/setup/production-environment/turnkey/stackpoint.md diff --git a/content/ja/docs/setup/production-environment/turnkey/stackpoint.md b/content/ja/docs/setup/production-environment/turnkey/stackpoint.md deleted file mode 100644 index 47711bf4d8..0000000000 --- a/content/ja/docs/setup/production-environment/turnkey/stackpoint.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす -content_type: concept ---- - - - -[StackPointCloud](https://stackpoint.io/) is the universal control plane for Kubernetes Anywhere. StackPointCloud allows you to deploy and manage a Kubernetes cluster to the cloud provider of your choice in 3 steps using a web-based interface. - - - - - -## AWS - -To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Amazon Web Services (AWS). - -1. Configure Your Provider - - a. Add your Access Key ID and a Secret Access Key from AWS. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on AWS, [consult the Kubernetes documentation](/docs/getting-started-guides/aws/). - - -## GCE - -To create a Kubernetes cluster on GCE, you will need the Service Account JSON Data from Google. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Google Compute Engine (GCE). - -1. Configure Your Provider - - a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on GCE, [consult the Kubernetes documentation](/docs/getting-started-guides/gce/). - - -## Google Kubernetes Engine - -To create a Kubernetes cluster on Google Kubernetes Engine, you will need the Service Account JSON Data from Google. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Google Kubernetes Engine. - -1. Configure Your Provider - - a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/ja/docs/home/). - - -## DigitalOcean - -To create a Kubernetes cluster on DigitalOcean, you will need a DigitalOcean API Token. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select DigitalOcean. - -1. Configure Your Provider - - a. Add your DigitalOcean API Token. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on DigitalOcean, consult [the official documentation](/ja/docs/home/). - - -## Microsoft Azure - -To create a Kubernetes cluster on Microsoft Azure, you will need an Azure Subscription ID, Username/Email, and Password. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Microsoft Azure. - -1. Configure Your Provider - - a. Add your Azure Subscription ID, Username/Email, and Password. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Azure, [consult the Kubernetes documentation](/docs/getting-started-guides/azure/). - - -## Packet - -To create a Kubernetes cluster on Packet, you will need a Packet API Key. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Packet. - -1. Configure Your Provider - - a. Add your Packet API Key. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/). - - From bf33586da5fcc91c31869f6f2cc10df691dd657d Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 6 Jul 2020 18:15:45 +0900 Subject: [PATCH 096/119] tiny fix --- .../setup/production-environment/container-runtimes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index 26aa83ded8..12e9bc27fe 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -60,13 +60,13 @@ kubeletを再起動しても問題は解決しないでしょう。 ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。 +バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Ubuntu 16.04+" codelang="bash" >}} # Docker CEのインストール ## リポジトリをセットアップ ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール @@ -111,7 +111,7 @@ systemctl restart docker # Docker CEのインストール ## リポジトリをセットアップ ### 必要なパッケージのインストール - yum install yum-utils device-mapper-persistent-data lvm2 +yum install -y yum-utils device-mapper-persistent-data lvm2 ### Dockerリポジトリの追加 yum-config-manager --add-repo \ @@ -314,7 +314,7 @@ systemctl restart containerd ### systemd `systemd`のcgroupドライバーを使うには、`/etc/containerd/config.toml`内で`plugins.cri.systemd_cgroup = true`を設定してください。 -kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)を手動で設定してください。 +kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#マスターノードのkubeletによって使用されるcgroupドライバーの設定)を手動で設定してください。 ## その他のCRIランタイム: frakti From 720411b167be5f85f30ce83a95005fe135256a5e Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Mon, 6 Jul 2020 18:22:16 +0900 Subject: [PATCH 097/119] fix version --- .../ja/docs/setup/production-environment/container-runtimes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index 12e9bc27fe..b6ef66143f 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -60,7 +60,7 @@ kubeletを再起動しても問題は解決しないでしょう。 ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 +バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 From 30b375524e275afb0acc9f81553ea0ed95459f9e Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 7 Jul 2020 19:20:25 +0900 Subject: [PATCH 098/119] ja: remove docs/setup/release/building-from-source.md --- .../setup/release/building-from-source.md | 30 ------------------- 1 file changed, 30 deletions(-) delete mode 100644 content/ja/docs/setup/release/building-from-source.md diff --git a/content/ja/docs/setup/release/building-from-source.md b/content/ja/docs/setup/release/building-from-source.md deleted file mode 100644 index 21f056ce39..0000000000 --- a/content/ja/docs/setup/release/building-from-source.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: リリースのビルド -content_type: concept -card: - name: download - weight: 20 - title: リリースのビルド ---- - -ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。 - -Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。 - - - -## ソースからのビルド - -単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。 - -リリースをビルドすることは簡単です。 - -```shell -git clone https://github.com/kubernetes/kubernetes.git -cd kubernetes -make release -``` - -リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。 - - From 41580d0cb4f352bbfeb1ab87183e52bb62289249 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 7 Jul 2020 19:36:09 +0900 Subject: [PATCH 099/119] ja: remove docs/concepts/cluster-administration/controller-metrics.md --- .../controller-metrics.md | 42 ------------------- 1 file changed, 42 deletions(-) delete mode 100644 content/ja/docs/concepts/cluster-administration/controller-metrics.md diff --git a/content/ja/docs/concepts/cluster-administration/controller-metrics.md b/content/ja/docs/concepts/cluster-administration/controller-metrics.md deleted file mode 100644 index d77f5bdf44..0000000000 --- a/content/ja/docs/concepts/cluster-administration/controller-metrics.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: コントローラーマネージャーの指標 -content_type: concept -weight: 100 ---- - - -コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。 - - - - -## コントローラーマネージャーの指標とは何か - -コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。 -これらの指標にはgo_routineのカウントなどの一般的なGo言語ランタイムの指標と、etcdのリクエストレイテンシまたはCloudprovider（AWS、GCE、OpenStack）APIのレイテンシといったコントローラー固有の指標が含まれていて、クラスターの状態を測定するために利用できます。 - -Kubernetes 1.7からGCE、AWS、Vsphere、OpenStackのストレージ操作の詳細なCloudproviderの指標が利用可能になりました。 -これらの指標は永続的ボリュームの操作状況を監視するために利用できます。 - -たとえば、GCEの場合にはこれらの指標は次のように呼び出されます。 - -``` -cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} -cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} -``` - - - -## 設定 - -クラスターではコントローラーマネージャーの指標はコントローラーマネージャーが実行されているホストの`http://localhost:10252/metrics`から取得可能です。 - -この指標は[prometheusフォーマット](https://prometheus.io/docs/instrumenting/exposition_formats/)で出力され人間が読める形式になっています。 - -本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。 - - From 1525b27189532b07db6835fbd752276a4cd638ff Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Wed, 8 Jul 2020 00:32:24 +0900 Subject: [PATCH 100/119] ja: Make docs/setup/release/version-skew-policy.md follow v1.17 of the original text --- content/ja/docs/setup/release/version-skew-policy.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md index 19200d80a6..56e600ee6b 100644 --- a/content/ja/docs/setup/release/version-skew-policy.md +++ b/content/ja/docs/setup/release/version-skew-policy.md @@ -16,9 +16,10 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。 -セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。 +セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースチーム](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing)がこれを決定しています。パッチリリースチームは[リリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)の一部です。 +詳細は、[Kubernetesパッチリリース](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)ページを参照してください。 -詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。 +マイナーリリースは約3ヶ月ごとに行われるため、マイナーリリースのブランチはそれぞれ約9ヶ月保守されます。 ## サポートされるバージョンの差異 From fb628b59a8e213ec757c075cd03d7b3fc8e32e73 Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Wed, 8 Jul 2020 00:44:38 +0900 Subject: [PATCH 101/119] uncapitalize taint and toleration --- .../scheduling/taint-and-toleration.md | 114 +++++++++--------- 1 file changed, 57 insertions(+), 57 deletions(-) diff --git a/content/ja/docs/concepts/scheduling/taint-and-toleration.md b/content/ja/docs/concepts/scheduling/taint-and-toleration.md index 21c047fcb6..3a7364fb0b 100644 --- a/content/ja/docs/concepts/scheduling/taint-and-toleration.md +++ b/content/ja/docs/concepts/scheduling/taint-and-toleration.md @@ -1,5 +1,5 @@ --- -title: TaintとToleration +title: taintとtoleration content_type: concept weight: 40 --- @@ -7,33 +7,33 @@ weight: 40 [_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は -{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。 反対に_Taint_はNodeがある種のPodを排除できるようにします。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。 反対に_taint_はNodeがある種のPodを排除できるようにします。 -_Toleration_はPodに適用され、一致するTaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。 +_toleration_はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。 -TaintとTolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。TaintはNodeに一つまたは複数個付与することができます。これはそのNodeがTaintを許容しないPodを受け入れるべきではないことを示します。 +taintとtolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。taintはNodeに一つまたは複数個付与することができます。これはそのNodeがtaintを許容しないPodを受け入れるべきではないことを示します。 ## コンセプト -NodeにTaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。 +Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。 例えば、次のコマンドは ```shell kubectl taint nodes node1 key=value:NoSchedule ``` -`node1`にTaintを設定します。このTaintのキーは`key`、値は`value`、Taintの効果は`NoSchedule`です。 -これは`node1`にはPodに合致するTolerationがなければスケジューリングされないことを意味します。 +`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。 +これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。 -上記のコマンドで付与したTaintを外すには、下記のコマンドを使います。 +上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。 ```shell kubectl taint nodes node1 key:NoSchedule- ``` -PodのTolerationはPodSpecの中に指定します。下記のTolerationはどちらも、上記の`kubectl taint`コマンドで追加したTaintと合致するため、どちらのTolerationが設定されたPodも`node1`へスケジューリングされることができます。 +PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。 ```yaml tolerations: @@ -50,13 +50,13 @@ tolerations: effect: "NoSchedule" ``` -Tolerationを設定したPodの例を示します。 +tolerationを設定したPodの例を示します。 {{< codenew file="pods/pod-with-toleration.yaml" >}} `operator`のデフォルトは`Equal`です。 -TolerationがTaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。 +tolerationがtaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。 * `operator`が`Exists`（`value`を指定すべきでない場合） * `operator`が`Equal`であり、かつ`value`が同一である場合 @@ -65,24 +65,24 @@ TolerationがTaintと合致するのは、`key`と`effect`が同一であり、 2つ特殊な場合があります。 -空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのTaintと合致します。 +空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。 空の`effect`は`key`が一致する全てのeffectと合致します。 {{< /note >}} 上記の例では`effect`に`NoSchedule`を指定しました。代わりに、`effect`に`PreferNoSchedule`を指定することができます。 -これは`NoSchedule`の「ソフトな」バージョンであり、システムはTaintに対応するTolerationが設定されていないPodがNodeへ配置されることを避けようとしますが、必須の条件とはしません。3つ目の`effect`の値として`NoExecute`がありますが、これについては後述します。 +これは`NoSchedule`の「ソフトな」バージョンであり、システムはtaintに対応するtolerationが設定されていないPodがNodeへ配置されることを避けようとしますが、必須の条件とはしません。3つ目の`effect`の値として`NoExecute`がありますが、これについては後述します。 -同一のNodeに複数のTaintを付与することや、同一のPodに複数のTolerationを設定することができます。 -複数のTaintやTolerationが設定されている場合、Kubernetesはフィルタのように扱います。最初はNodeの全てのTaintがある状態から始め、Podが対応するTolerationを持っているTaintは無視され外されていきます。無視されずに残ったTaintが効果を及ぼします。 +同一のNodeに複数のtaintを付与することや、同一のPodに複数のtolerationを設定することができます。 +複数のtaintやtolerationが設定されている場合、Kubernetesはフィルタのように扱います。最初はNodeの全てのtaintがある状態から始め、Podが対応するtolerationを持っているtaintは無視され外されていきます。無視されずに残ったtaintが効果を及ぼします。 具体的には、 -* effect `NoSchedule`のTaintが無視されず残った場合、KubernetesはそのPodをNodeへスケジューリングしません。 -* effect `NoSchedule`のTaintは残らず、effect `PreferNoSchedule`のTaintは残った場合、KubernetesはそのNodeへのスケジューリングをしないように試みます。 -* effect `NoExecute`のTaintが残った場合、既に稼働中のPodはそのNodeから排除され、まだ稼働していないPodはスケジューリングされないようになります。 +* effect `NoSchedule`のtaintが無視されず残った場合、KubernetesはそのPodをNodeへスケジューリングしません。 +* effect `NoSchedule`のtaintは残らず、effect `PreferNoSchedule`のtaintは残った場合、KubernetesはそのNodeへのスケジューリングをしないように試みます。 +* effect `NoExecute`のtaintが残った場合、既に稼働中のPodはそのNodeから排除され、まだ稼働していないPodはスケジューリングされないようになります。 -例として、下記のようなTaintが付与されたNodeを考えます。 +例として、下記のようなtaintが付与されたNodeを考えます。 ```shell kubectl taint nodes node1 key1=value1:NoSchedule @@ -90,7 +90,7 @@ kubectl taint nodes node1 key1=value1:NoExecute kubectl taint nodes node1 key2=value2:NoSchedule ``` -Podには2つのTolerationが設定されています。 +Podには2つのtolerationが設定されています。 ```yaml tolerations: @@ -104,11 +104,11 @@ tolerations: effect: "NoExecute" ``` -この例では、3つ目のTaintと合致するTolerationがないため、PodはNodeへはスケジューリングされません。 -しかし、これらのTaintが追加された時点で、そのNodeでPodが稼働していれば続けて稼働することが可能です。 これは、PodのTolerationと合致しないTaintは3つあるTaintのうちの3つ目のTaintのみであり、それが`NoSchedule`であるためです。 +この例では、3つ目のtaintと合致するtolerationがないため、PodはNodeへはスケジューリングされません。 +しかし、これらのtaintが追加された時点で、そのNodeでPodが稼働していれば続けて稼働することが可能です。 これは、Podのtolerationと合致しないtaintは3つあるtaintのうちの3つ目のtaintのみであり、それが`NoSchedule`であるためです。 -一般に、effect `NoExecute`のTaintがNodeに追加されると、合致するTolerationが設定されていないPodは即時にNodeから排除され、合致するTolerationが設定されたPodが排除されることは決してありません。 -しかし、effect`NoExecute`に対するTolerationは`tolerationSeconds`フィールドを任意で指定することができ、これはTaintが追加された後にそのNodeにPodが残る時間を示します。例えば、 +一般に、effect `NoExecute`のtaintがNodeに追加されると、合致するtolerationが設定されていないPodは即時にNodeから排除され、合致するtolerationが設定されたPodが排除されることは決してありません。 +しかし、effect`NoExecute`に対するtolerationは`tolerationSeconds`フィールドを任意で指定することができ、これはtaintが追加された後にそのNodeにPodが残る時間を示します。例えば、 ```yaml tolerations: @@ -119,41 +119,41 @@ tolerations: tolerationSeconds: 3600 ``` -この例のPodが稼働中で、対応するTaintがNodeへ追加された場合、PodはそのNodeに3600秒残り、その後排除されます。仮にTaintがそれよりも前に外された場合、Podは排除されません。 +この例のPodが稼働中で、対応するtaintがNodeへ追加された場合、PodはそのNodeに3600秒残り、その後排除されます。仮にtaintがそれよりも前に外された場合、Podは排除されません。 ## ユースケースの例 -TaintとTolerationは、実行されるべきではないNodeからPodを遠ざけたり、排除したりするための柔軟な方法です。いくつかのユースケースを示します。 +taintとtolerationは、実行されるべきではないNodeからPodを遠ざけたり、排除したりするための柔軟な方法です。いくつかのユースケースを示します。 -* **専有Node**: あるNode群を特定のユーザーに専有させたい場合、そのNode群へTaintを追加し(`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) 対応するTolerationをPodへ追加します（これを実現する最も容易な方法はカスタム +* **専有Node**: あるNode群を特定のユーザーに専有させたい場合、そのNode群へtaintを追加し(`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) 対応するtolerationをPodへ追加します（これを実現する最も容易な方法はカスタム [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を書くことです）。 -Tolerationが設定されたPodはTaintの設定された（専有の）Nodeと、クラスターにあるその他のNodeの使用が認められます。もしPodが必ず専有Node*のみ*を使うようにしたい場合は、Taintと同様のラベルをそのNode群に設定し(例: `dedicated=groupName`)、アドミッションコントローラーはNodeアフィニティを使ってPodが`dedicated=groupName`のラベルの付いたNodeへスケジューリングすることが必要であるということも設定する必要があります。 +tolerationが設定されたPodはtaintの設定された（専有の）Nodeと、クラスターにあるその他のNodeの使用が認められます。もしPodが必ず専有Node*のみ*を使うようにしたい場合は、taintと同様のラベルをそのNode群に設定し(例: `dedicated=groupName`)、アドミッションコントローラーはNodeアフィニティを使ってPodが`dedicated=groupName`のラベルの付いたNodeへスケジューリングすることが必要であるということも設定する必要があります。 * **特殊なハードウェアを備えるNode**: クラスターの中の少数のNodeが特殊なハードウェア（例えばGPU）を備える場合、そのハードウェアを必要としないPodがスケジューリングされないようにして、後でハードウェアを必要とするPodができたときの余裕を確保したいことがあります。 -これは特殊なハードウェアを持つNodeにTaintを追加(例えば `kubectl taint nodes nodename special=true:NoSchedule` または -`kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するTolerationを追加することで可能です。 -専有Nodeのユースケースと同様に、Tolerationを容易に適用する方法はカスタム +これは特殊なハードウェアを持つNodeにtaintを追加(例えば `kubectl taint nodes nodename special=true:NoSchedule` または +`kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するtolerationを追加することで可能です。 +専有Nodeのユースケースと同様に、tolerationを容易に適用する方法はカスタム [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を使うことです。 例えば、特殊なハードウェアを表すために[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) -を使い、ハードウェアを備えるNodeに拡張リソースの名称のTaintを追加して、 -[拡張リソースToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) -アドミッションコントローラーを実行することが推奨されます。NodeにはTaintが付与されているため、TolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースToleration` アドミッションコントローラーはPodに自動的に適切なTolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。 -これは特殊なハードウェアを備えたNodeではそれを必要とするPodのみが稼働し、Podに対して手作業でTolerationを追加しなくて済むようにします。 +を使い、ハードウェアを備えるNodeに拡張リソースの名称のtaintを追加して、 +[拡張リソースtoleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) +アドミッションコントローラーを実行することが推奨されます。Nodeにはtaintが付与されているため、tolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースtoleration` アドミッションコントローラーはPodに自動的に適切なtolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。 +これは特殊なハードウェアを備えたNodeではそれを必要とするPodのみが稼働し、Podに対して手作業でtolerationを追加しなくて済むようにします。 -* **Taintを基にした排除**: Nodeに問題が起きたときにPodごとに排除する設定を行うことができます。次のセクションにて説明します。 +* **taintを基にした排除**: Nodeに問題が起きたときにPodごとに排除する設定を行うことができます。次のセクションにて説明します。 -## Taintを基にした排除 +## taintを基にした排除 {{< feature-state for_k8s_version="v1.18" state="stable" >}} -上述したように、effect `NoExecute`のTaintはNodeで実行中のPodに次のような影響を与えます。 +上述したように、effect `NoExecute`のtaintはNodeで実行中のPodに次のような影響を与えます。 - * 対応するTolerationのないPodは即座に除外される - * 対応するTolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける - * 対応するTolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される + * 対応するtolerationのないPodは即座に除外される + * 対応するtolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける + * 対応するtolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される -Nodeコントローラーは特定の条件を満たす場合に自動的にTaintを追加します。 -組み込まれているTaintは下記の通りです。 +Nodeコントローラーは特定の条件を満たす場合に自動的にtaintを追加します。 +組み込まれているtaintは下記の通りです。 * `node.kubernetes.io/not-ready`: Nodeの準備ができていない場合。これはNodeCondition `Ready`が`False`である場合に対応します。 * `node.kubernetes.io/unreachable`: NodeがNodeコントローラーから到達できない場合。これはNodeCondition`Ready`が`Unknown`の場合に対応します。 @@ -162,20 +162,20 @@ Nodeコントローラーは特定の条件を満たす場合に自動的にTain * `node.kubernetes.io/disk-pressure`: Nodeのディスクが不足している場合。 * `node.kubernetes.io/network-unavailable`: Nodeのネットワークが利用できない場合。 * `node.kubernetes.io/unschedulable`: Nodeがスケジューリングできない場合。 - * `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるTaintで、このNodeは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのNodeを初期化した後にkubeletはこのTaintを外します。 + * `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるtaintで、このNodeは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのNodeを初期化した後にkubeletはこのtaintを外します。 -Nodeから追い出すときには、Nodeコントローラーまたはkubeletは関連するTaintを`NoExecute`効果の状態で追加します。 -不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはNodeコントローラーは関連するTaintを外すことができます。 +Nodeから追い出すときには、Nodeコントローラーまたはkubeletは関連するtaintを`NoExecute`効果の状態で追加します。 +不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはNodeコントローラーは関連するtaintを外すことができます。 {{< note >}} -コントロールプレーンは新しいTaintをNodeに加えるレートを制限しています。 +コントロールプレーンは新しいtaintをNodeに加えるレートを制限しています。 このレート制限は一度に多くのNodeが到達不可能になった場合（例えばネットワークの断絶）に、退役させられるNodeの数を制御します。 {{< /note >}} Podに`tolerationSeconds`を指定することで不具合があるか応答のないNodeに残る時間を指定することができます。 例えば、ローカルの状態を多数持つアプリケーションとネットワークが分断された場合を考えます。ネットワークが復旧して、Podを排除しなくて済むことを見込んで、長時間Nodeから排除されないようにしたいこともあるでしょう。 -この場合Podに設定するTolerationは次のようになります。 +この場合Podに設定するtolerationは次のようになります。 ```yaml tolerations: @@ -186,25 +186,25 @@ tolerations: ``` {{< note >}} -Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的に`node.kubernetes.io/not-ready`と`node.kubernetes.io/unreachable`に対するTolerationを`tolerationSeconds=300`にて設定します。 +Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的に`node.kubernetes.io/not-ready`と`node.kubernetes.io/unreachable`に対するtolerationを`tolerationSeconds=300`にて設定します。 -自動的に設定されるTolerationは、Taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。 +自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。 {{< /note >}} -[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のTaintに対して`NoExecute`のTolerationが`tolerationSeconds`を指定せずに設定されます。 +[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。 * `node.kubernetes.io/unreachable` * `node.kubernetes.io/not-ready` これはDaemonSetのPodはこれらの問題によって排除されないことを保証します。 -## 条件によるTaintの付与 +## 条件によるtaintの付与 -NodeのライフサイクルコントローラーはNodeの状態に応じて`NoSchedule`効果のTaintを付与します。 -スケジューラーはNodeの状態ではなく、Taintを確認します。 -Nodeに何がスケジューリングされるかは、そのNodeの状態に影響されないことを保証します。ユーザーは適切なTolerationをPodに付与することで、どの種類のNodeの問題を無視するかを選ぶことができます。 +NodeのライフサイクルコントローラーはNodeの状態に応じて`NoSchedule`効果のtaintを付与します。 +スケジューラーはNodeの状態ではなく、taintを確認します。 +Nodeに何がスケジューリングされるかは、そのNodeの状態に影響されないことを保証します。ユーザーは適切なtolerationをPodに付与することで、どの種類のNodeの問題を無視するかを選ぶことができます。 -DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐために自動的に次の`NoSchedule`Tolerationを全てのDaemonSetに付与します。 +DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐために自動的に次の`NoSchedule`tolerationを全てのDaemonSetに付与します。 * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` @@ -212,7 +212,7 @@ DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐ * `node.kubernetes.io/unschedulable` (1.10またはそれ以降) * `node.kubernetes.io/network-unavailable` (*ホストネットワークのみ*) -これらのTolerationを追加することは後方互換性を保証します。DaemonSetに任意のTolerationを加えることもできます。 +これらのtolerationを追加することは後方互換性を保証します。DaemonSetに任意のtolerationを加えることもできます。 ## {{% heading "whatsnext" %}} From c0e3ff9c15c20095ca7a414bcebc2ad806f5015e Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 8 Jul 2020 01:59:17 +0900 Subject: [PATCH 102/119] Fix typos. Co-authored-by: bells17 --- .../mysql-wordpress-persistent-volume.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 47c37f9024..612cc223f7 100644 --- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -18,7 +18,7 @@ card: {{< /warning >}} {{< note >}} -このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、PAIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。 +このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、APIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。 {{< /note >}} @@ -94,7 +94,7 @@ EOF {{< codenew file="application/wordpress/mysql-deployment.yaml" >}} -以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータバースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。 +以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータベースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。 {{< codenew file="application/wordpress/wordpress-deployment.yaml" >}} @@ -240,4 +240,3 @@ WordPressのインストールをこのページのまま放置してはいけ * [コンテナへのシェルを取得する](/ja/docs/tasks/debug-application-cluster/get-shell-running-container/)方法について学ぶ - From 6bd367391fe101069e9270b1d2256c2bdb0c0519 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 8 Jul 2020 02:01:00 +0900 Subject: [PATCH 103/119] Improve translations. Co-authored-by: bells17 --- .../mysql-wordpress-persistent-volume.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 612cc223f7..7aed33777e 100644 --- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -11,7 +11,7 @@ card: このチュートリアルでは、WordPressのサイトとMySQLデータベースをMinikubeを使ってデプロイする方法を紹介します。2つのアプリケーションとも、データを保存するためにPersistentVolumeとPersistentVolumeClaimを使用します。 -[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)(PV)とは、管理者が手動でプロビジョニングを行うか、[StorageClass](/docs/concepts/storage/storage-classes)を使ってKubernetesによって動的にプロビジョニングされた、ストレージから切り出された部分のことです。[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)は、PVによって満たすことができる、ユーザーによるストレージへのリクエストのことです。PersistentVolumeとPersistentVolumeClaimは、Podのライフサイクルからは独立していて、Podの再起動、Podの再スケジューリング、さらにはPodの削除が行われたとしても、その中のデータは削除されずに残ります。 +[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)(PV)とは、管理者が手動でプロビジョニングを行うか、[StorageClass](/docs/concepts/storage/storage-classes)を使ってKubernetesによって動的にプロビジョニングされた、クラスター内のストレージの一部です。[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)は、PVによって満たすことができる、ユーザーによるストレージへのリクエストのことです。PersistentVolumeとPersistentVolumeClaimは、Podのライフサイクルからは独立していて、Podの再起動、Podの再スケジューリング、さらにはPodの削除が行われたとしても、その中のデータは削除されずに残ります。 {{< warning >}} シングルインスタンスのWordPressとMySQLのPodを使用しているため、ここで行うデプロイは本番のユースケースには適しません。WordPressを本番環境にデプロイするときは、[WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)を使用することを検討してください。 @@ -64,7 +64,7 @@ PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づ {{< /warning >}} {{< note >}} -`hostPath`プロビジョナーを使う必要があるクラスターを立ち上げたい場合は、`controller-manager`内に`--enable-hostpath-provisioner`フラグを設定しなければなりません。 +`hostPath`プロビジョナーを使用する必要があるクラスターを立ち上げたい場合は、`--enable-hostpath-provisioner`フラグを `controller-manager` コンポーネントで設定する必要があります。 {{< /note >}} {{< note >}} @@ -239,4 +239,3 @@ WordPressのインストールをこのページのまま放置してはいけ * [Portフォワーディング](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)についてさらに学ぶ * [コンテナへのシェルを取得する](/ja/docs/tasks/debug-application-cluster/get-shell-running-container/)方法について学ぶ - From f1080be9d69b373685e2b983ab611476573bdc5a Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Wed, 8 Jul 2020 19:45:57 +0900 Subject: [PATCH 104/119] fix: markdown formatting --- .../docs/setup/release/version-skew-policy.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md index 56e600ee6b..94e4113af5 100644 --- a/content/ja/docs/setup/release/version-skew-policy.md +++ b/content/ja/docs/setup/release/version-skew-policy.md @@ -88,21 +88,21 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある ## サポートされるコンポーネントのアップグレード順序 -コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)**へ移行するために、コンポーネントをアップグレードする順序を説明します。 +コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)** へ移行するために、コンポーネントをアップグレードする順序を説明します。 ### kube-apiserver 前提条件: * シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします -* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)**とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります） +* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります） * サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします（必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります） -* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)**とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります） +* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります） * 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます: - * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)**で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください） - * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)**のバージョンで追加された新しいフィールドを扱うことができます + * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください） + * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます -`kube-apiserver`を**1.(n+1)**にアップグレードしてください。 +`kube-apiserver`を**1.(n+1)** にアップグレードしてください。 {{< note >}} [非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。 @@ -112,17 +112,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 前提条件: -* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)**であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません） +* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません） -`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)**にアップグレードしてください。 +`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。 ### kubelet 前提条件: -* `kubelet`と通信する`kube-apiserver`が**1.(n+1)**であること +* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること -必要に応じて、`kubelet`インスタンスを**1.(n+1)**にアップグレードしてください（**1.n**や**1.(n-1)**のままにすることもできます）。 +必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください（**1.n**や**1.(n-1)** のままにすることもできます）。 {{< warning >}} `kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません: From a6b58c249a1dc4705671660fe93e852226aae015 Mon Sep 17 00:00:00 2001 From: bells17 Date: Fri, 10 Jul 2020 11:55:28 +0900 Subject: [PATCH 105/119] Update setup/production-environment/tools/kubespray page en --- .../production-environment/tools/kubespray.md | 58 +++++++++---------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubespray.md b/content/ja/docs/setup/production-environment/tools/kubespray.md index 921ab0e3d8..6c02ca5374 100644 --- a/content/ja/docs/setup/production-environment/tools/kubespray.md +++ b/content/ja/docs/setup/production-environment/tools/kubespray.md @@ -6,22 +6,22 @@ weight: 30 -This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray). +This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). -Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: +Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: * a highly available cluster * composable attributes * support for most popular Linux distributions * Container Linux by CoreOS - * Debian Jessie, Stretch, Wheezy + * Debian Buster, Jessie, Stretch, Wheezy * Ubuntu 16.04, 18.04 - * CentOS/RHEL 7 - * Fedora/CentOS Atomic - * openSUSE Leap 42.3/Tumbleweed + * CentOS/RHEL/Oracle Linux 7 + * Fedora 28 + * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops). +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). @@ -31,11 +31,11 @@ To choose a tool which best fits your use case, read [this comparison](https://g ### (1/5) 下地の要件の確認 -Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements): +Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements): -* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands** +* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands** * **Jinja 2.9 (or newer) is required to run the Ansible Playbooks** -* The target servers must have **access to the Internet** in order to pull docker images +* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * The target servers are configured to allow **IPv4 forwarding** * **Your ssh key must be copied** to all the servers part of your inventory * The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall @@ -44,12 +44,13 @@ Provision servers with the following [requirements](https://github.com/kubernete Kubespray provides the following utilities to help provision your environment: * [Terraform](https://www.terraform.io/) scripts for the following cloud providers: - * [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws) - * [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/openstack) + * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws) + * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack) + * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet) ### (2/5) インベントリファイルの用意 -After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) クラスタ作成の計画 @@ -58,14 +59,14 @@ Kubespray provides the ability to customize many aspects of the deployment: * Choice deployment mode: kubeadm or non-kubeadm * CNI (networking) plugins * DNS configuration -* Choice of control plane: native/binary or containerized with docker or rkt +* Choice of control plane: native/binary or containerized * Component versions * Calico route reflectors * Component runtime options - * docker - * rkt - * cri-o -* Certificate generation methods (**Vault being discontinued**) + * {{< glossary_tooltip term_id="docker" >}} + * {{< glossary_tooltip term_id="containerd" >}} + * {{< glossary_tooltip term_id="cri-o" >}} +* Certificate generation methods Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. @@ -73,18 +74,18 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co Next, deploy your cluster: -Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). +Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). ```shell ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \ --private-key=~/.ssh/private_key ``` -Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results. +Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results. ### (5/5) デプロイの確認 -Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. +Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. ## クラスタの操作 @@ -92,16 +93,16 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg ### クラスタのスケール -You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)". -You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)". +You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)". +You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)". ### クラスタのアップグレード -You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)". +You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)". ## クリーンアップ -You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml). +You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml). {{< caution >}} When running the reset playbook, be sure not to accidentally target your production cluster! @@ -109,14 +110,13 @@ When running the reset playbook, be sure not to accidentally target your product ## フィードバック -* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) -* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues) +* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/)) +* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues) ## {{% heading "whatsnext" %}} -Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md). - +Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md). From b786031d43cfee4de16676713ef655bf3db4953a Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 10 Jul 2020 15:36:24 +0900 Subject: [PATCH 106/119] Fix the order of words. Co-authored-by: bells17 --- .../docs/tutorials/stateful-application/basic-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md index 57aeccd7f2..d8a0acbdf6 100644 --- a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md @@ -25,7 +25,7 @@ weight: 10 ## {{% heading "objectives" %}} -StatefulSetはステートフルアプリケーションや分散システムで使用するために存在します。しかし、Kubernetes上のステートフルアプリケーションや分散システムは、広範で複雑なトピックです。StatefulSetの基本的な機能を示すという目的のため、また、分散システムをステートフルアプリケーションと混同しないようにするために、ここでは、Statefulsetを使用する単純なウェブアプリケーションのデプロイを行います。 +StatefulSetはステートフルアプリケーションや分散システムで使用するために存在します。しかし、Kubernetes上のステートフルアプリケーションや分散システムは、広範で複雑なトピックです。StatefulSetの基本的な機能を示すという目的のため、また、ステートフルアプリケーションを分散システムと混同しないようにするために、ここでは、Statefulsetを使用する単純なウェブアプリケーションのデプロイを行います。 このチュートリアルを終えると、以下のことが理解できるようになります。 From 0703a7bee23f3b9038cb12791173bb1be842f9e7 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 10 Jul 2020 15:43:43 +0900 Subject: [PATCH 107/119] Update content/ja/docs/concepts/architecture/controller.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/architecture/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index ff857fd67a..bdd29db3db 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -64,7 +64,7 @@ Kubernetesはシステムに対してクラウドネイティブな見方をす 設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 -相互にリンクされた単一のモノリシックな制御ループよりは、複数のシンプルなコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 +相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 From e93a81ad71f064a7f7d177757bbbc3bfff6c2cb5 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 10 Jul 2020 21:10:52 +0900 Subject: [PATCH 108/119] update doc to follow v1.17 --- .../windows/intro-windows-in-kubernetes.md | 48 +++++++++++++++---- 1 file changed, 40 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index ab0181fd49..fb6aa381fe 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -55,7 +55,7 @@ Key Kubernetes elements work the same way in Windows as they do in Linux. In thi * [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) - A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. The following Pod capabilities, properties and events are supported with Windows containers: + A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers: * Single or multiple containers per Pod with process isolation and volume sharing * Pod status fields @@ -99,14 +99,32 @@ Pods, Controllers and Services are critical elements to managing Windows workloa Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions. -#### Storage +#### Persistent Storage -Kubernetes Volumes enable complex applications with data persistence and Pod volume sharing requirements to be deployed on Kubernetes. Kubernetes on Windows supports the following types of [volumes](/ja/docs/concepts/storage/volumes/): +Kubernetes [volumes](/ja/docs/concepts/storage/volumes/) enable complex applications, with data persistence and Pod volume sharing requirements, to be deployed on Kubernetes. Management of persistent volumes associated with a specific storage back-end or protocol includes actions such as: provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod that needs to persist data. The code implementing these volume management actions for a specific storage back-end or protocol is shipped in the form of a Kubernetes volume [plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: -* FlexVolume out-of-tree plugin with [SMB and iSCSI](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) support +##### In-tree Volume Plugins +Code associated with in-tree volume plugins ship as part of the core Kubernetes code base. Deployment of in-tree volume plugins do not require installation of additional scripts or deployment of separate containerized plugin components. These plugins can handle: provisioning/de-provisioning and resizing of volumes in the storage backend, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. The following in-tree plugins support Windows nodes: + +* [awsElasticBlockStore](/ja/docs/concepts/storage/volumes/#awselasticblockstore) * [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk) * [azureFile](/ja/docs/concepts/storage/volumes/#azurefile) * [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk) +* [vsphereVolume](/ja/docs/concepts/storage/volumes/#vspherevolume) + +##### FlexVolume Plugins +Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume) plugins ship as out-of-tree scripts or binaries that need to be deployed directly on the host. FlexVolume plugins handle attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. Provisioning/De-provisioning of persistent volumes associated with FlexVolume plugins may be handled through an external provisioner that is typically separate from the FlexVolume plugins. The following FlexVolume [plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows), deployed as powershell scripts on the host, support Windows nodes: + +* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) +* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) + +##### CSI Plugins + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Code associated with {{< glossary_tooltip text="CSI" term_id="csi" >}} plugins ship as out-of-tree scripts and binaries that are typically distributed as container images and deployed using standard Kubernetes constructs like DaemonSets and StatefulSets. CSI plugins handle a wide range of volume management actions in Kubernetes: provisioning/de-provisioning/resizing of volumes, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod, backup/restore of persistent data using snapshots and cloning. CSI plugins typically consist of node plugins (that run on each node as a DaemonSet) and controller plugins. + +CSI node plugins (especially those associated with persistent volumes exposed as either block devices or over a shared file-system) need to perform various privileged operations like scanning of disk devices, mounting of file systems, etc. These operations differ for each host operating system. For Linux worker nodes, containerized CSI node plugins are typically deployed as privileged containers. For Windows worker nodes, privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node. Please refer to the deployment guide of the CSI plugin you wish to deploy for further details. #### Networking @@ -128,9 +146,9 @@ Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Ov | Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics | | -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | -| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires L2 adjacency between container hosts | +| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. | | L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) | -| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header, inner packet remains the same. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option may be used when the container hosts are not L2 adjacent but have L3 connectivity | +| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. | | Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.
Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller.
NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. | | NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness | @@ -215,7 +233,6 @@ As a result, the following storage functionality is not supported on Windows nod * Read-only root filesystem. Mapped volumes still support readOnly * Block device mapping * Memory as the storage medium -* CSI plugins which require privileged containers * File system features like uui/guid, per-user Linux filesystem permissions * NFS based storage/volume support * Expanding the mounted volume (resizefs) @@ -256,6 +273,7 @@ These features were added in Kubernetes v1.15: * ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution * On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with just that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**. +* On Windows, there are multiple DNS resolvers that can be used. As these come with slightly different behaviors, using the `Resolve-DNSName` utility for name query resolutions is recommended. ##### Security @@ -493,7 +511,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" ``` - Often it is worthwhile to modify the [InterfaceName](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. + Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. 1. My Pods are stuck at "Container Creating" or restarting over and over @@ -510,6 +528,20 @@ Your main source of help for troubleshooting your Kubernetes cluster should star This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones. If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat) +1. My Kubernetes installation is failing because my Windows Server node is behind a proxy + + If you are behind a proxy, the following PowerShell environment variables must be defined: + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` + +1. What is a `pause` container? + + In a Kubernetes Pod, an infrastructure or "pause" container is first created to host the container endpoint. Containers that belong to the same pod, including infrastructure and worker containers, share a common network namespace and endpoint (same IP and port space). Pause containers are needed to accommodate worker containers crashing or restarting without losing any of the networking configuration. + + The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat). + ### Further investigation If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through: From f5fa8d70ac0af309acfd39d5eb4e2abc7f096b4b Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Tue, 14 Jul 2020 19:07:32 +0900 Subject: [PATCH 109/119] remove japanese link Co-authored-by: Naoki Oketani --- .../windows/intro-windows-in-kubernetes.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index fb6aa381fe..d1042b58a7 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -101,7 +101,7 @@ Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubern #### Persistent Storage -Kubernetes [volumes](/ja/docs/concepts/storage/volumes/) enable complex applications, with data persistence and Pod volume sharing requirements, to be deployed on Kubernetes. Management of persistent volumes associated with a specific storage back-end or protocol includes actions such as: provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod that needs to persist data. The code implementing these volume management actions for a specific storage back-end or protocol is shipped in the form of a Kubernetes volume [plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: +Kubernetes [volumes](/docs/concepts/storage/volumes/) enable complex applications, with data persistence and Pod volume sharing requirements, to be deployed on Kubernetes. Management of persistent volumes associated with a specific storage back-end or protocol includes actions such as: provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod that needs to persist data. The code implementing these volume management actions for a specific storage back-end or protocol is shipped in the form of a Kubernetes volume [plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: ##### In-tree Volume Plugins Code associated with in-tree volume plugins ship as part of the core Kubernetes code base. Deployment of in-tree volume plugins do not require installation of additional scripts or deployment of separate containerized plugin components. These plugins can handle: provisioning/de-provisioning and resizing of volumes in the storage backend, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. The following in-tree plugins support Windows nodes: @@ -617,4 +617,3 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust * More CNIs * More Storage Plugins - From f18b523efb308ddacf9cad59b0cb713e4ad74dcb Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Tue, 14 Jul 2020 19:07:46 +0900 Subject: [PATCH 110/119] remove japanese link Co-authored-by: Naoki Oketani --- .../windows/intro-windows-in-kubernetes.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index d1042b58a7..bf620f4779 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -106,11 +106,11 @@ Kubernetes [volumes](/docs/concepts/storage/volumes/) enable complex application ##### In-tree Volume Plugins Code associated with in-tree volume plugins ship as part of the core Kubernetes code base. Deployment of in-tree volume plugins do not require installation of additional scripts or deployment of separate containerized plugin components. These plugins can handle: provisioning/de-provisioning and resizing of volumes in the storage backend, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. The following in-tree plugins support Windows nodes: -* [awsElasticBlockStore](/ja/docs/concepts/storage/volumes/#awselasticblockstore) -* [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk) -* [azureFile](/ja/docs/concepts/storage/volumes/#azurefile) -* [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk) -* [vsphereVolume](/ja/docs/concepts/storage/volumes/#vspherevolume) +* [awsElasticBlockStore](/docs/concepts/storage/volumes/#awselasticblockstore) +* [azureDisk](/docs/concepts/storage/volumes/#azuredisk) +* [azureFile](/docs/concepts/storage/volumes/#azurefile) +* [gcePersistentDisk](/docs/concepts/storage/volumes/#gcepersistentdisk) +* [vsphereVolume](/docs/concepts/storage/volumes/#vspherevolume) ##### FlexVolume Plugins Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume) plugins ship as out-of-tree scripts or binaries that need to be deployed directly on the host. FlexVolume plugins handle attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. Provisioning/De-provisioning of persistent volumes associated with FlexVolume plugins may be handled through an external provisioner that is typically separate from the FlexVolume plugins. The following FlexVolume [plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows), deployed as powershell scripts on the host, support Windows nodes: @@ -616,4 +616,3 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust * Beta support for Group Managed Service Accounts * More CNIs * More Storage Plugins - From 6d7ba5e7ef89dfc840c3f71cbb854d54eb0c402b Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Tue, 14 Jul 2020 19:11:18 +0900 Subject: [PATCH 111/119] update filename --- .../windows/intro-windows-in-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index bf620f4779..300e0dc1d4 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -152,7 +152,7 @@ Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Ov | Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.
Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller.
NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. | | NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness | -As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (net-conf.json), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local). +As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (cni.conf), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local). For the node, pod, and service objects, the following network flows are supported for TCP/UDP traffic: From 6c4d23384c5fc649496a42327e7935f719854b1e Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Tue, 14 Jul 2020 19:18:27 +0900 Subject: [PATCH 112/119] update icp.md to follow v1.17 --- content/ja/docs/setup/production-environment/turnkey/icp.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/setup/production-environment/turnkey/icp.md b/content/ja/docs/setup/production-environment/turnkey/icp.md index 79783a6364..6e3fb4c53f 100644 --- a/content/ja/docs/setup/production-environment/turnkey/icp.md +++ b/content/ja/docs/setup/production-environment/turnkey/icp.md @@ -35,7 +35,7 @@ IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To ## Azure上でのIBM Cloud Private -You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/azure_overview.html). +You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html). ## Red Hat OpenShift上でのIBM Cloud Private @@ -49,7 +49,7 @@ Integration capabilities: * Integrated core platform services, such as monitoring, metering, and logging * IBM Cloud Private uses the OpenShift image registry -For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/openshift/overview.html). +For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html). ## VirtualBox上でのIBM Cloud Private From 84aef362132443cd7768163c437830b3b2a08450 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Tue, 14 Jul 2020 19:31:51 +0900 Subject: [PATCH 113/119] update document link --- .../windows/intro-windows-in-kubernetes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 300e0dc1d4..2fd8b87366 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -128,7 +128,7 @@ CSI node plugins (especially those associated with persistent volumes exposed as #### Networking -Networking for Windows containers is exposed through [CNI plugins](/ja/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as: +Networking for Windows containers is exposed through [CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as: * Virtual networks (including creation of vSwitches) * Endpoints / vNICs @@ -282,7 +282,7 @@ Secrets are written in clear text on the node's volume (as compared to tmpfs/in- 1. Use file ACLs to secure the secrets file location 2. Use volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) -[RunAsUser ](/ja/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release. +[RunAsUser ](/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release. Linux specific pod security context privileges such as SELinux, AppArmor, Seccomp, Capabilities (POSIX Capabilities), and others are not supported. @@ -346,7 +346,7 @@ None of the PodSecurityContext fields work on Windows. They're listed here for r ## Getting Help and Troubleshooting {#troubleshooting} -Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/ja/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). +Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). 1. How do I know start.ps1 completed successfully? @@ -463,7 +463,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star 1. vNICs and HNS endpoints of containers are being deleted - This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/ja/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows: + This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows: ```powershell C:\k\kube-proxy.exe --hostname-override=$(hostname) From 2b295d81f5a4dc5fd4a05a5a6a8ef5bbb33a2bfc Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Tue, 14 Jul 2020 19:39:15 +0900 Subject: [PATCH 114/119] update aws.md to follow v1.17 --- content/ja/docs/setup/production-environment/turnkey/aws.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/turnkey/aws.md b/content/ja/docs/setup/production-environment/turnkey/aws.md index ebbb93160d..1fc53a1f28 100644 --- a/content/ja/docs/setup/production-environment/turnkey/aws.md +++ b/content/ja/docs/setup/production-environment/turnkey/aws.md @@ -16,7 +16,7 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス ### サポートされているプロダクショングレードのツール -* [conjure-up](/docs/getting-started-guides/ubuntu/)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。 +* [conjure-up](https://docs.conjure-up.io/stable/en/cni/k8s-and-aws)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。 * [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。 From a4d98cf349cb3756972b3b268fe94231e829c24c Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Tue, 14 Jul 2020 19:46:32 +0900 Subject: [PATCH 115/119] update alibaba-cloud.md to follow v1.17 --- .../setup/production-environment/turnkey/alibaba-cloud.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md b/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md index f8323743cf..d5b2eeefd5 100644 --- a/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md +++ b/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md @@ -4,7 +4,7 @@ title: Alibaba CloudでKubernetesを動かす ## Alibaba Cloud Container Service -[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 +[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上もしくはサーバーレスの形態でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 @@ -14,4 +14,4 @@ title: Alibaba CloudでKubernetesを動かす [Alibaba Cloudプロバイダーが実装されたKubernetesのソースコード](https://github.com/AliyunContainerService/kubernetes)はオープンソースであり、GitHubから入手可能です。 -さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)および[中国語](https://yq.aliyun.com/articles/66474)をご覧下さい。 +さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)をご覧下さい。 From c7ce81f743034848b10de77efe6ed6dacd4fcb51 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Tue, 14 Jul 2020 20:12:20 +0900 Subject: [PATCH 116/119] update self-hosting.md to follow v1.17 --- .../setup/production-environment/tools/kubeadm/self-hosting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md index 08f9efe0b8..a7bee37727 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -8,7 +8,7 @@ weight: 100 ### Self-hosting the Kubernetes control plane {#self-hosting} -As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control +kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control plane. This means that key components such as the API server, controller manager, and scheduler run as [DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/) configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/) From 184c826e7729f6d906e748b111f1f3f6c3ebbc70 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 16 Jul 2020 20:12:30 +0900 Subject: [PATCH 117/119] Fix the front-matter. Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index bdd29db3db..cf27948bb4 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -1,6 +1,6 @@ --- title: コントローラー -content_template: templates/concept +content_type: concept weight: 30 --- From c27a37ca1635380a55cdaf566e9cd1f7ee1c0532 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 16 Jul 2020 20:13:31 +0900 Subject: [PATCH 118/119] Fix a typo. Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index cf27948bb4..9fd8f201c5 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -34,7 +34,7 @@ Jobは、1つ以上の{{< glossary_tooltip term_id="pod" >}}を起動して、 (1度[スケジュール](/docs/concepts/scheduling-eviction/)されると、Podオブジェクトはkubeletに対する目的の状態の一部になります。) -Jobコントローラーが新しいタスクを見つけると、その処理が完了するように、クラスター上のどこかで、一連のNode上のkubeletが正しい数のPodを実行することを保証します。ただし、Jobコントローラーは、自分自身でPodやコンテナーを実行することはありません。代わりに、APIサーバーに対してPodの作成や削除を依頼します。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上の他のコンポーネントが(スケジュールして実行するべき新しいPodが存在するという)新しい情報を基に動作することによって、最終的に目的の処理が完了します。 +Jobコントローラーが新しいタスクを見つけると、その処理が完了するように、クラスター上のどこかで、一連のNode上のkubeletが正しい数のPodを実行することを保証します。ただし、Jobコントローラーは、自分自身でPodやコンテナを実行することはありません。代わりに、APIサーバーに対してPodの作成や削除を依頼します。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上の他のコンポーネントが(スケジュールして実行するべき新しいPodが存在するという)新しい情報を基に動作することによって、最終的に目的の処理が完了します。 新しいJobが作成されたとき、目的の状態は、そのJobが完了することです。JobコントローラーはそのJobに対する現在の状態を目的の状態に近づけるようにします。つまり、そのJobが行ってほしい処理を実行するPodを作成し、Jobが完了に近づくようにします。 From 4a7e3bf5312335a87dbca79e7a79ba579472ddb5 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Fri, 17 Jul 2020 13:26:17 +0900 Subject: [PATCH 119/119] Update content/ja/docs/setup/production-environment/turnkey/icp.md --- content/ja/docs/setup/production-environment/turnkey/icp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/turnkey/icp.md b/content/ja/docs/setup/production-environment/turnkey/icp.md index 6e3fb4c53f..9d1a0a17b3 100644 --- a/content/ja/docs/setup/production-environment/turnkey/icp.md +++ b/content/ja/docs/setup/production-environment/turnkey/icp.md @@ -37,7 +37,7 @@ IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html). -## Red Hat OpenShift上でのIBM Cloud Private +## Red Hat OpenShiftを用いたIBM Cloud Private You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.