Merge branch 'dev-1.17-ja.3' of https://github.com/kubernetes/website into dev-1.17-ja.3

2020-07-17 22:44:31 +09:00 · 2020-07-17 22:44:31 +09:00 · 44d8b263df
parent 8772fd1438 e6117c66e5
commit 44d8b263df
72 changed files with 2538 additions and 760 deletions
--- 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)によって管理されています。

 ## ありがとうございます！

--- 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
 ```

@ -40,7 +41,7 @@ Furthermore, in some cases, one of your reviewers might ask for a technical revi
 For more information about contributing to the Kubernetes documentation, see:

 * [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
-* [Using Page Templates](https://kubernetes.io/docs/contribute/style/page-templates/)
+* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
 * [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)

--- 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:

@ -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`.

--- 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.

--- 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.
--- 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

 <!-- overview -->

-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,30 +24,43 @@ 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
-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 
+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:
 ```
@ -59,9 +72,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

--- 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
--- 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.
--- 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
--- a/content/es/docs/concepts/architecture/cloud-controller.md
+++ b/content/es/docs/concepts/architecture/cloud-controller.md
@ -6,13 +6,13 @@ weight: 30

 <!-- overview -->

-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 y detalla 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)

@ -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).

-
--- 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.

--- 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**:
--- a/content/ja/docs/concepts/_index.md
+++ b/content/ja/docs/concepts/_index.md
@ -19,14 +19,14 @@ 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オブジェクト
+## Kubernetesオブジェクト {#kubernetes-objects}

-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のオブジェクトは次のとおりです。

@ -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オブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。

--- 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
 ---
--- 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
 ---

 <!-- overview -->
@ -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)
+

 ## クラスター管理

--- a/content/ja/docs/concepts/architecture/controller.md
+++ b/content/ja/docs/concepts/architecture/controller.md
@ -0,0 +1,90 @@
+---
+title: コントローラー
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+
+ロボット工学やオートメーションの分野において、 _制御ループ_ とは、あるシステムの状態を制御する終了状態のないループのことです。
+
+ここでは、制御ループの一例として、部屋の中にあるサーモスタットを挙げます。
+
+あなたが温度を設定すると、それはサーモスタットに *目的の状態(desired state)* を伝えることになります。実際の部屋の温度は *現在の状態* です。サーモスタットは、装置をオンまたはオフにすることによって、現在の状態を目的の状態に近づけるように動作します。
+
+{{< glossary_definition term_id="controller" length="short">}}
+
+<!-- body -->
+
+## コントローラーパターン
+
+コントローラーは少なくとも1種類のKubernetesのリソースを監視します。これらの[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)には目的の状態を表すspecフィールドがあります。リソースのコントローラーは、現在の状態を目的の状態に近づける責務を持ちます。
+
+コントローラーは自分自身でアクションを実行する場合もありますが、Kubernetesではコントローラーが{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に意味のある副作用を持つメッセージを送信することが一般的です。以下では、このような例を見ていきます。
+
+{{< comment >}}
+ネームスペースコントローラーなどの一部のビルトインのコントローラーは、specのないオブジェクトに対して作用します。簡単のため、このページではそのような詳細な説明は省略します。
+{{< /comment >}}
+
+### APIサーバー経由でコントロールする
+
+{{< glossary_tooltip term_id="job" >}}コントローラーはKubernetesのビルトインのコントローラーの一例です。ビルトインのコントローラーは、クラスターのAPIサーバーとやりとりをして状態を管理します。
+
+Jobは、1つ以上の{{< glossary_tooltip term_id="pod" >}}を起動して、タスクを実行した後に停止する、Kubernetesのリソースです。
+
+(1度[スケジュール](/docs/concepts/scheduling-eviction/)されると、Podオブジェクトはkubeletに対する目的の状態の一部になります。)
+
+Jobコントローラーが新しいタスクを見つけると、その処理が完了するように、クラスター上のどこかで、一連のNode上のkubeletが正しい数のPodを実行することを保証します。ただし、Jobコントローラーは、自分自身でPodやコンテナを実行することはありません。代わりに、APIサーバーに対してPodの作成や削除を依頼します。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上の他のコンポーネントが(スケジュールして実行するべき新しいPodが存在するという)新しい情報を基に動作することによって、最終的に目的の処理が完了します。
+
+新しいJobが作成されたとき、目的の状態は、そのJobが完了することです。JobコントローラーはそのJobに対する現在の状態を目的の状態に近づけるようにします。つまり、そのJobが行ってほしい処理を実行するPodを作成し、Jobが完了に近づくようにします。
+
+コントローラーは、コントローラーを設定するオブジェクトも更新します。たとえば、あるJobが完了した場合、Jobコントローラーは、Jobオブジェクトに`Finished`というマークを付けます。
+
+(これは、部屋が設定温度になったことを示すために、サーモスタットがランプを消灯するのに少し似ています。)
+
+### 直接的なコントロール
+
+Jobとは対照的に、クラスターの外部に変更を加える必要があるコントローラーもあります。
+
+たとえば、クラスターに十分な数の{{< glossary_tooltip text="Node" term_id="node" >}}が存在することを保証する制御ループの場合、そのコントローラーは、必要に応じて新しいNodeをセットアップするために、現在のクラスターの外部とやりとりをする必要があります。
+
+外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。
+
+(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。)
+
+## 目的の状態 vs 現在の状態 {#desired-vs-current}
+
+Kubernetesはシステムに対してクラウドネイティブな見方をするため、常に変化し続けるような状態を扱えるように設計されています。
+
+処理を実行したり、制御ループが故障を自動的に修正したりしているどの時点でも、クラスターは変化中である可能性があります。つまり、クラスターは決して安定した状態にならない可能性があるということです。
+
+コントローラーがクラスターのために実行されていて、有用な変更が行われるのであれば、全体的な状態が安定しているかどうかは問題にはなりません。
+
+## 設計
+
+設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。
+
+相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。
+
+たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。
+
+{{< note >}}
+同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。
+
+たとえば、DeploymentとJobがありますが、これらは両方ともPodを作成するものです。しかし、JobコントローラーはDeploymentが作成したPodを削除することはありません。各コントローラーが2つのPodを区別できる情報({{< glossary_tooltip term_id="label" text="ラベル" >}})が存在するためです。
+{{< /note >}}
+
+## コントローラーを実行する方法 {#running-controllers}
+
+Kubernetesには、{{< glossary_tooltip term_id="kube-controller-manager" >}}内部で動作する一組のビルトインのコントローラーが用意されています。これらビルトインのコントローラーは、コアとなる重要な振る舞いを提供します。
+
+DeploymentコントローラーとJobコントローラーは、Kubernetes自体の一部として同梱されているコントローラーの例です(それゆえ「ビルトイン」のコントローラーと呼ばれます)。Kubernetesは回復性のあるコントロールプレーンを実行できるようにしているため、ビルトインのコントローラーの一部が故障しても、コントロールプレーンの別の部分が作業を引き継いでくれます。
+
+Kubernetesを拡張するためにコントロールプレーンの外で動作するコントローラーもあります。もし望むなら、新しいコントローラーを自分で書くこともできます。自作のコントローラーをPodセットとして動作させたり、Kubernetesの外部で動作させることもできます。どのような動作方法が最も適しているかは、そのコントローラーがどのようなことを行うのかに依存します。
+
+## {{% heading "whatsnext" %}}
+
+* [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)を読んでください。
--- 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,17 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な

 Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。

+## ノードのトポロジー
+
+{{< feature-state state="alpha" >}}
+`TopologyManager`の[フィーチャーゲート](/ja/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/#node-components)について読む。
+* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
+{{% /capture %}}
--- a/content/ja/docs/concepts/cluster-administration/controller-metrics.md
+++ b/content/ja/docs/concepts/cluster-administration/controller-metrics.md
@ -1,42 +0,0 @@
---
-title: コントローラーマネージャーの指標
-content_type: concept
-weight: 100
---
-
-<!-- overview -->
-コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
-
-
-
-<!-- body -->
-## コントローラーマネージャーの指標とは何か
-
-コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
-これらの指標には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やその他の指標のスクレイパーを構成することが推奨されます。
-
-
--- 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

 <!-- overview -->

-[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
+{{< 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にデプロイする等、柔軟な制御が必要なこともあります。
@ -27,7 +27,7 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ

 ### ステップ0: 前提条件

-この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](https://github.com/kubernetes/kubernetes#documentation)がされていることが前提となっています。
+この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。

 ### ステップ1: Nodeへのラベルの付与

@ -63,17 +63,20 @@ nodeSelectorを以下のように追加します:
 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。
 `kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。

-## 補足: ビルトインNodeラベル
+## 補足: ビルトインNodeラベル {#built-in-node-labels}

 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前に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 >}}
 これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。
@ -88,131 +91,127 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー
 これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。

 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
-Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。
+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に`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では、より柔軟な指定方法が提供されています。
+アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。
 拡張機能は以下の通りです。

-1. 様々な指定方法がある ("AND条件"に限らない)
-2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができる
-3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができる
+1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。
+2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。
+3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。

-Affinityは"Node Affinity"と"Inter-Pod Affinity/Anti-Affinity"の2種類から成ります。
-Node affinityは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Inter-Pod Affinity/Anti-Affinityは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。
+アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。
+Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。

-`nodeSelector`は問題なく使用することができますが、Node affinityは`nodeSelector`で指定できる条件を全て実現できるため、将来的には推奨されなくなります。
+### Nodeアフィニティ

-### Node Affinity
+Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。

-Node Affinityはα機能としてKubernetesのv1.2から導入されました。
-Node Affinityは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。
-
-現在は2種類のNode Affinityがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。
+現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。
 前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。
 "IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも
 PodはそのNodeで稼働し続けるということです。
-将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNode Affinityに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。
+将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。

 それぞれの使用例として、
 `requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、
 `preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる"
 といった方法が挙げられます。

-Node Affinityは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。
+Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。

-Node Affinityを使用したPodの例を以下に示します:
+Nodeアフィニティを使用したPodの例を以下に示します:

 {{< codenew file="pods/pod-with-node-affinity.yaml" >}}

-このNode Affinityでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。
+このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。
 加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。

 この例ではオペレーター`In`が使われています。
-Node Affinityでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
-`NotIn`と`DoesNotExist`はNode Anti-Affinity、またはPodを特定のNodeにスケジュールさせない場合に使われる[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は**両方の**条件を満たすNodeにスケジュールされます。

-`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
+`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。

-`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。
+`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたNodeへスケジュールされます。

 PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。
-言い換えると、AffinityはPodをスケジュールする際にのみ考慮されます。
+言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。

 `preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。
-全ての必要条件(リソースやRequiredDuringScheduling Affinity等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。
+全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。
 このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。

-### Inter-Pod Affinity/Anti-Affinity
+### Pod間アフィニティとアンチアフィニティ

-Inter-Pod AffinityとAnti-Affinityは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。
-このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(Anti-Affinityの場合は稼働させない)"という形式です。
+Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。
+このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。
 Yはnamespaceのリストで指定したLabelSelectorで表されます。
 Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。
 概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。
-これらを表すためにシステムが使用するNode Labelのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。
+これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。
 先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。


 {{< note >}}
-Inter-Pod AffinityとAnti-Affinityは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。
+Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。
 そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。
 {{< /note >}}

 {{< note >}}
-Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。
-例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
+Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。
+言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
 それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。
 {{< /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の数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。
+Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
+前述のNodeアフィニティのセクションを参照してください。
+`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つはある状態で、
+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 Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
+Podアンチアフィニティは、「すでにある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アフィニティと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`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。


 #### 実際的なユースケース

-Inter-Pod AffinityとAnti-Affinityは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。
+Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。
 Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。


@ -325,7 +324,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
 ##### 同じ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
@ -338,7 +337,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
 `nodeName`を使用することによる制約は以下の通りです:

 -   その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。
-   その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由はOutOfmemoryやOutOfcpuになります。
+-   その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。
 -   クラウド上のNodeの名前は予期できず、変更される可能性があります。

 `nodeName`を指定したPodの設定ファイルの例を示します:
@ -364,8 +363,9 @@ spec:

 [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の要点に関して様々な背景が紹介されています。
-
+[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がNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。
+[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。
--- 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-name>:<tag>`を`<image-name>@<digest>`で置き換えます(例:`image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。
 {{< /note >}}

 {{< note >}}
--- 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"
--- 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リソースを作成する。
@ -39,8 +38,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は、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのノードがコンテナランタイムに関して同じ方法で構成されていることを意味します)。
+設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。
 {{< /note >}}

 RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。
@ -60,6 +59,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 +96,7 @@ CRIランタイムのセットアップに関するさらなる詳細は、[CRI

 Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。

-#### [containerd](https://containerd.io/)
+#### {{< glossary_tooltip term_id="containerd" >}}

 ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。
 正しいハンドラーは、その`runtime`セクションで設定されます。
@ -106,20 +108,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`フィールドを使ったクラスター内での異なる設定をサポートしています。
+このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。
+スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。（1.16ではデフォルトです）
+
+特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。
+RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。
+もし設定が衝突した場合は、Pod作成は拒否されるでしょう。
+
+もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。
+`nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。
+
+ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。
+
+[アドミッションコントローラー]: /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 +171,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)
--- 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
 ---

 <!-- overview -->
@ -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サブドメイン名](/ja/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* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。

 [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。

@ -134,7 +135,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。

 | CRD                        | アグリゲート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) | はい |
-| サブリソースの状態 | <ul><li>より詳細なアクセスコントロール: ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む</li><li>カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソースがspecと、statusでセクションが分離している必要がある)</li></ul> | [はい](/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は、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 |
 | ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 |

@ -220,5 +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/)について学ぶ
-
-
--- 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に読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。
--- a/content/ja/docs/concepts/overview/components.md
+++ b/content/ja/docs/concepts/overview/components.md
@ -9,7 +9,7 @@ card:

 <!-- 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をデプロイすると、クラスターが展開されます。

 <!-- 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
@ -68,7 +67,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー
  * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
  * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。

-## ノードコンポーネント
+## ノードコンポーネント {#node-components}

 ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。

--- 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 >}}
--- 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)

--- 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:


 <!-- body -->
-## Kubernetesオブジェクトを理解する
+## Kubernetesオブジェクトを理解する {#kubernetes-objects}

 *Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます:

--- 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/)を作成します。
-このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
+このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり、これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
 これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。

--- a/content/ja/docs/concepts/scheduling/taint-and-toleration.md
+++ b/content/ja/docs/concepts/scheduling/taint-and-toleration.md
@ -0,0 +1,221 @@
+---
+title: taintとtoleration
+content_type: concept
+weight: 40
+---
+
+
+<!-- overview -->
+[_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を受け入れるべきではないことを示します。
+
+
+<!-- body -->
+
+## コンセプト
+
+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/)を読む
--- 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アソシエーションに応じてネットワークをセットアップします。
--- 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のロールアウトを完了することができません。

--- 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`が適用されます。

--- a/content/ja/docs/home/supported-doc-versions.md
+++ b/content/ja/docs/home/supported-doc-versions.md
@ -9,7 +9,7 @@ card:

 <!-- overview -->

-本ウェブサイトでは、現行版とその直前4バージョンのKubernetesドキュメントを含んでいます。
+本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。



@ -17,8 +17,7 @@ card:

 ## 現行版

-現在のバージョンは
-[{{< param "version" >}}](/).
+現在のバージョンは[{{< param "version" >}}](/)です。

 ## 以前のバージョン

--- a/content/ja/docs/reference/glossary/cncf.md
+++ b/content/ja/docs/reference/glossary/cncf.md
@ -0,0 +1,20 @@
+---
+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プロジェクトです。
+
+<!--more-->
+
+CNCFは[Linux Foundation](https://www.linuxfoundation.org/)のサブファウンデーションです。
+CNCFの使命は、クラウドネイティブコンピューティングをユビキタスにすることです。
--- 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)」を参照してください。


--- a/content/ja/docs/setup/best-practices/node-conformance.md
+++ b/content/ja/docs/setup/best-practices/node-conformance.md
@ -7,43 +7,35 @@ 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をローカルホストに設定します(`--api-servers="http://localhost:8080"`)。他にも配慮するべき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 +43,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 +53,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イメージがノード上に残ります。
+* このテストでは、ノード上にデッドコンテナが残ります。これらのコンテナは機能テスト中に作成されます。
--- a/content/ja/docs/setup/production-environment/container-runtimes.md
+++ b/content/ja/docs/setup/production-environment/container-runtimes.md
@ -47,38 +47,46 @@ 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をインストールします。
-バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。
+バージョン19.03.4が推奨されていますが、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のインストール
 ## リポジトリをセットアップ
-### 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 <<EOF
@ -103,15 +111,17 @@ 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リポジトリを追加
-yum-config-manager \
-    --add-repo \
-    https://download.docker.com/linux/centos/docker-ce.repo
+### 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
+## Docker CEのインストール
+yum update -y && yum install -y \
+  containerd.io-1.2.10 \
+  docker-ce-19.03.4 \
+  docker-ce-cli-19.03.4

 ## /etc/docker ディレクトリを作成
 mkdir /etc/docker
@ -147,7 +157,12 @@ systemctl restart docker

 システムへCRI-Oをインストールするためには以下のコマンドを利用します:

-### 必要な設定の追加
+{{< note >}}
+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 <<EOF
+overlay
+br_netfilter
+EOF
+
 modprobe overlay
 modprobe br_netfilter

@ -218,36 +260,61 @@ EOF
 sysctl --system
 ```

+### containerdのインストール
+
 {{< tabs name="tab-cri-containerd-installation" >}}
-{{< 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/#マスターノードのkubeletによって使用されるcgroupドライバーの設定)を手動で設定してください。

 ## その他のCRIランタイム: frakti

--- 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
 ---
--- 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
--- 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/)
--- 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

 <!-- overview -->

-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).

--- 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
 ---
--- 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)をご覧下さい。
--- 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をサポートしています。

--- a/content/ja/docs/setup/production-environment/turnkey/icp.md
+++ b/content/ja/docs/setup/production-environment/turnkey/icp.md
@ -35,9 +35,9 @@ 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
+## Red Hat OpenShiftを用いたIBM Cloud Private

 You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.

@ -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

--- a/content/ja/docs/setup/production-environment/turnkey/stackpoint.md
+++ b/content/ja/docs/setup/production-environment/turnkey/stackpoint.md
@ -1,187 +0,0 @@
---
-title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす
-content_type: concept
---
-
-<!-- overview -->
-
-[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.
-
-
-
-<!-- body -->
-
-## 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/).
-
-
--- 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,18 +99,36 @@ 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](/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
-* [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk)
-* [azureFile](/ja/docs/concepts/storage/volumes/#azurefile)
-* [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk)
+##### 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](/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:
+
+* [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

-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
@ -128,13 +146,13 @@ 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.  <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> 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:

@ -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

@ -264,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.

@ -328,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?

@ -445,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)
@ -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:
@ -584,5 +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
-
-
--- a/content/ja/docs/setup/release/building-from-source.md
+++ b/content/ja/docs/setup/release/building-from-source.md
@ -1,30 +0,0 @@
---
-title: リリースのビルド
-content_type: concept
-card:
-  name: download
-  weight: 20
-  title: リリースのビルド
---
-<!-- overview -->
-ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。
-
-Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。
-
-
-<!-- body -->
-## ソースからのビルド
-
-単にソースからリリースをビルドするだけであれば、完全な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/)ディレクトリを参照して下さい。
-
-
--- 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ヶ月保守されます。

 ## サポートされるバージョンの差異

@ -87,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`のアップグレードの際にマイナーバージョンをスキップしてはなりません。
@ -111,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`インスタンスを使用してクラスターを実行させることは推奨されません:
--- 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
@ -0,0 +1,112 @@
+---
+title: クラスターで実行されているすべてのコンテナイメージを一覧表示する
+content_type: task
+weight: 100
+---
+
+<!-- overview -->
+
+このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+<!-- steps -->
+
+この演習では、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}}"
+```
+
+
+
+
+
+<!-- discussion -->
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### 参照
+
+* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド
+* [Go template](https://golang.org/pkg/text/template/)参照ガイド
+
+
+
+
--- 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オブジェクトを使用する。

--- 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/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。

--- a/content/ja/docs/tasks/administer-cluster/coredns.md
+++ b/content/ja/docs/tasks/administer-cluster/coredns.md
@ -0,0 +1,79 @@
+---
+title: サービスディスカバリーにCoreDNSを使用する
+min-kubernetes-server-version: v1.9
+content_type: task
+---
+
+<!-- overview -->
+このページでは、CoreDNSのアップグレードプロセスと、kube-dnsの代わりにCoreDNSをインストールする方法を説明します。
+
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+<!-- steps -->
+
+## 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/)を参照してください。
+
+
+
--- 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 <pod-name> -c <init-container-2>

 <!-- discussion -->

-## Podのステータスを理解する
+## Podのステータスを理解する {#understanding-pod-status}

 `Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。

--- 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 >}}

--- 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
@ -0,0 +1,149 @@
+---
+title: 環境変数によりコンテナにPod情報を共有する
+content_type: task
+weight: 30
+---
+
+<!-- overview -->
+
+このページでは、Podが内部で実行しているコンテナに自身の情報を共有する方法を説明します。環境変数ではPodのフィールドとコンテナのフィールドを共有することができます。
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+<!-- steps -->
+
+## 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)
+
+
--- a/content/ja/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/_index.html
@ -39,7 +39,7 @@ card:

    <div class="row">
      <div class="col-md-9">
-        <h2>Kubernetesはどんなことができるの?</h2>
+        <h2>Kubernetesはどんなことができるの？</h2>
        <p>モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。</p>
      </div>
    </div>
--- a/content/ja/docs/tutorials/stateful-application/_index.md
+++ b/content/ja/docs/tutorials/stateful-application/_index.md
@ -0,0 +1,5 @@
+---
+title: "ステートフルアプリケーション"
+weight: 50
+---
+
--- a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md
--- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@ -0,0 +1,241 @@
+---
+title: "例: Persistent Volumeを使用したWordpressとMySQLをデプロイする"
+content_type: tutorial
+weight: 20
+card:
+  name: tutorials
+  weight: 40
+  title: "ステートフルの例: Persistent Volumeを使用したWordpress"
+---
+
+<!-- overview -->
+このチュートリアルでは、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の削除が行われたとしても、その中のデータは削除されずに残ります。
+
+{{< warning >}}
+シングルインスタンスのWordPressとMySQLのPodを使用しているため、ここで行うデプロイは本番のユースケースには適しません。WordPressを本番環境にデプロイするときは、[WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)を使用することを検討してください。
+{{< /warning >}}
+
+{{< note >}}
+このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、APIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。
+{{< /note >}}
+
+
+
+## {{% heading "objectives" %}}
+
+* PersistentVolumeClaimとPersistentVolumeを作成する
+* 以下を含む`kustomization.yaml`を作成する
+  * Secret generator
+  * MySQLリソースの設定
+  * WordPressリソースの設定
+* kustomizationディレクトリを`kubectl apply -k ./`で適用する
+* クリーンアップする
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+このページで示された例は、`kubectl` 1.14以降で動作します。
+
+以下の設定ファイルをダウンロードします。
+
+1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml)
+
+1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml)
+
+
+
+<!-- lessoncontent -->
+
+## PersistentVolumeClaimとPersistentVolumeを作成する
+
+MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。
+
+多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。
+
+PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。
+
+{{< warning >}}
+ローカルのクラスターでは、デフォルトのStorageClassには`hostPath`プロビジョナーが使われます。`hostPath`ボリュームは開発およびテストにのみ適しています。`hostPath`ボリュームでは、データはPodがスケジュールされたノード上の`/tmp`内に保存されます。そのため、もしPodが死んだり、クラスター上の他のノードにスケジュールされたり、ノードが再起動すると、データは失われます。
+{{< /warning >}}
+
+{{< note >}}
+`hostPath`プロビジョナーを使用する必要があるクラスターを立ち上げたい場合は、`--enable-hostpath-provisioner`フラグを `controller-manager` コンポーネントで設定する必要があります。
+{{< /note >}}
+
+{{< note >}}
+Google Kubernetes Engine上で動作するKubernetesクラスターを使っている場合は、[このガイド](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk?hl=ja)に従ってください。
+{{< /note >}}
+
+## kustomization.yamlを作成する
+
+### Secret generatorを追加する
+
+[Secret](/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。
+
+以下のコマンドを実行して、`kustomization.yaml`の中にSecret generatorを追加します。`YOUR_PASSWORD`の部分を使いたいパスワードに置換してください。
+
+```shell
+cat <<EOF >./kustomization.yaml
+secretGenerator:
+- name: mysql-pass
+  literals:
+  - password=YOUR_PASSWORD
+EOF
+```
+
+## MySQLとWordPressのためのリソースの設定を追加する
+
+以下のマニフェストには、シングルインスタンスのMySQLのDeploymentが書かれています。MySQLコンテナはPersistentVolumeを`/var/lib/mysql`にマウントします。`MYSQL_ROOT_PASSWORD`環境変数には、Secretから得られたデータベースのパスワードが設定されます。
+
+{{< 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から得たデータベースのパスワードが設定されます。
+
+
+{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
+
+1. MySQLのDeploymentの設定ファイルをダウンロードします。
+
+      ```shell
+      curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
+      ```
+
+2. WordPressの設定ファイルをダウンロードします。
+
+      ```shell
+      curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
+      ```
+
+3. これらを`kustomization.yaml`ファイルに追加します。
+
+```shell
+cat <<EOF >>./kustomization.yaml
+resources:
+  - mysql-deployment.yaml
+  - wordpress-deployment.yaml
+EOF
+```
+
+## 適用と確認
+
+`kustomization.yaml`には、WordPressのサイトとMySQLデータベースのためのすべてのリソースが含まれています。次のコマンドでこのディレクトリを適用できます。
+
+```shell
+kubectl apply -k ./
+```
+
+これで、すべてのオブジェクトが存在していることを確認できます。
+
+1. 次のコマンドを実行して、Secretが存在していることを確認します。
+
+      ```shell
+      kubectl get secrets
+      ```
+
+      結果は次のようになるはずです。
+
+      ```shell
+      NAME                    TYPE                                  DATA   AGE
+      mysql-pass-c57bb4t7mf   Opaque                                1      9s
+      ```
+
+1. 次のコマンドを実行して、PersistentVolumeが動的にプロビジョニングされていることを確認します。
+
+      ```shell
+      kubectl get pvc
+      ```
+
+      {{< note >}}
+      PVがプロビジョニングされてバインドされるまでに、最大で数分かかる場合があります。
+      {{< /note >}}
+
+      結果は次のようになるはずです。
+
+      ```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. 次のコマンドを実行して、Podが実行中であることを確認します。
+
+      ```shell
+      kubectl get pods
+      ```
+
+      {{< note >}}
+      PodのStatusが`Running`の状態になる前に、最大で数分かかる場合があります。
+      {{< /note >}}
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME                               READY     STATUS    RESTARTS   AGE
+      wordpress-mysql-1894417608-x5dzt   1/1       Running   0          40s
+      ```
+
+4. 次のコマンドを実行して、Serviceが実行中であることを確認します。
+
+      ```shell
+      kubectl get services wordpress
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
+      wordpress   ClusterIP   10.0.0.89    <pending>     80:32406/TCP   4m
+      ```
+
+      {{< note >}}
+      MinikubeではServiceを`NodePort`経由でしか公開できません。EXTERNAL-IPは常にpendingのままになります。
+      {{< /note >}}
+
+5. 次のコマンドを実行して、WordPress ServiceのIPアドレスを取得します。
+
+      ```shell
+      minikube service wordpress --url
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      http://1.2.3.4:32406
+      ```
+
+6. IPアドレスをコピーして、ブラウザーで読み込み、サイトを表示しましょう。
+
+   WordPressによりセットアップされた次のスクリーンショットのようなページが表示されるはずです。
+
+   ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png)
+
+{{< warning >}}
+WordPressのインストールをこのページのまま放置してはいけません。もしほかのユーザーがこのページを見つけた場合、その人はインスタンス上にウェブサイトをセットアップして、悪意のあるコンテンツの配信に利用できてしまいます。<br/><br/>ユーザー名とパスワードを決めてWordPressをインストールするか、このインスタンスを削除してください。
+{{< /warning >}}
+
+
+
+## {{% heading "cleanup" %}}
+
+
+1. 次のコマンドを実行して、Secret、Deployment、Service、およびPersistentVolumeClaimを削除します。
+
+      ```shell
+      kubectl delete -k ./
+      ```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [イントロスペクションとデバッグ](/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/)方法について学ぶ
+
--- a/content/ko/docs/contribute/localization_ko.md
+++ b/content/ko/docs/contribute/localization_ko.md
@ -132,21 +132,29 @@ weight: 10

 ### API 오브젝트 용어 한글화 방침

-API 오브젝트 중 `kubectl api-resources` 결과의 `kind`에 해당하는 오브젝트는
+일반적으로 `kubectl api-resources` 결과의 `kind` 에 해당하는 API 오브젝트는
 [국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에
-따라 한글 표기한다. 예를 들면 다음과 같다.
+따라 한글로 표기하고 영문을 병기한다. 예를 들면 다음과 같다.
+
+API 오브젝트(kind)      | 한글화(외래어 표기 및 영문 병기)
+---                   | ---
+ClusterRoleBinding    | 클러스터롤바인딩(ClusterRoleBinding)
+ConfigMap             | 컨피그맵(ConfigMap)
+Deployment            | 디플로이먼트(Deployment)
+PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim)
+...                   | ...
+
+`kind` 에 속하는 API 오브젝트 중에서도 일부는 표현의 간결함을 위해 한영병기를 하지 않는 등의 예외가 있으며,
+예외에 대해서는 [한글화 용어집](#한글화-용어집)에 등록된 방식을 준용한다. 예를 들면 다음과 같다.

 API 오브젝트(kind)      | 한글화(외래어 표기)
 ---                   | ---
-ClusterRoleBinding    | 클러스터롤바인딩
-ConfigMap             | 컨피그맵
-Deployment            | 디플로이먼트
 Pod                   | 파드
-PersistentVolumeClaim | 퍼시스턴트볼륨클레임
 Service               | 서비스
 ...                   | ...

-그 이외의 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고,
+
+`kind` 에 속하지 않는 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고,
 모두 원문 그대로 표기한다. 예를 들면 다음과 같다.

 API 오브젝트(kind가 아닌 경우) | 한글화(원문 유지)
@ -479,5 +487,3 @@ Windows | 윈도우 |
 Worker | 워커 | 노드의 형태에 한함
 Workload | 워크로드 |
 YAML | YAML |
-
-
--- a/content/pl/_index.html
+++ b/content/pl/_index.html
@ -3,9 +3,6 @@ title: "Produkcyjny system zarządzania kontenerami"
 abstract: "Automatyzacja wdrażania, skalowania i zarządzania kontenerami"
 cid: home
 ---
-{{< announcement >}}
-
-{{< deprecationwarning >}}

 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
--- a/content/pl/docs/contribute/_index.md
+++ b/content/pl/docs/contribute/_index.md
@ -23,8 +23,6 @@ Współtwórcy dokumentacji Kubernetesa:

 Zapraszamy do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych!

-
-
 <!-- body -->

 ## 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?

--- a/content/pl/docs/home/_index.md
+++ b/content/pl/docs/home/_index.md
@ -13,7 +13,7 @@ menu:
    title: "Dokumentacja"
    weight: 20
    post: >
-      <p>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 <a href="/editdocs/" data-auto-burger-exclude>pomóc w jej tworzeniu</a>!</p>
+      <p>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 <a href="/editdocs/" data-auto-burger-exclude data-proofer-ignore>pomóc w jej tworzeniu</a>!</p>
 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
--- 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 >}}
-
-
--- 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.

-
-
 <!-- body -->

 ## Ś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).
-
-
--- a/content/pl/docs/setup/release/_index.md
+++ b/content/pl/docs/setup/release/_index.md
@ -0,0 +1,4 @@
+---
+title: "Informacje o wydaniach i dozwolonych różnicach wersji"
+weight: 10
+---
--- a/content/pl/docs/tasks/_index.md
+++ b/content/pl/docs/tasks/_index.md
@ -5,80 +5,13 @@ weight: 50
 content_type: concept
 ---

-{{< toc >}}
-
 <!-- overview -->

 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.

-
-
-<!-- body -->
-
-## 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/).
-
-
--- a/content/zh/docs/concepts/configuration/configmap.md
+++ b/content/zh/docs/concepts/configuration/configmap.md
@ -6,7 +6,7 @@ weight: 20

 <!-- overview -->

-{{< glossary_definition term_id="configmap" prepend="ConfigMap 是" length="all" >}}
+{{< glossary_definition term_id="configmap" length="all" >}}

 {{< caution >}}
 <!--
--- 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/)?
--- 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