Merge pull request #29220 from PI-Victor/config/update-release-1.18

Update config.toml for release-1.18 branch
config.toml: update dropdown
2021-08-04 15:55:12 -07:00 · 2021-08-04 19:39:24 +02:00 · 2021-07-27 18:33:35 -07:00 · 2021-07-03 23:28:59 +03:00 · 2021-05-30 19:46:26 -07:00 · 2021-05-26 13:50:29 +00:00
241 changed files with 3661 additions and 4350 deletions
@@ -115,13 +115,13 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.18"
+latest = "v1.22"

-fullversion = "v1.18.0"
+fullversion = "v1.18.20"
 version = "v1.18"
-githubbranch = "master"
-docsbranch = "master"
-deprecated = false
+githubbranch = "v1.18.20"
+docsbranch = "release-1.18"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
 githubWebsiteRepo = "github.com/kubernetes/website"
@@ -129,7 +129,7 @@ githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"

 # param for displaying an announcement block on every page.
 # See /i18n/en.toml for message text and title.
-announcement = true
+announcement = false
 announcement_bg = "#000000" #choose a dark color – text is white

 #Searching
@@ -157,39 +157,39 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.18.0"
-version = "v1.18"
-githubbranch = "v1.18.0"
-docsbranch = "release-1.18"
+fullversion = "v1.22.0"
+version = "v1.22"
+githubbranch = "v1.22.0"
+docsbranch = "main"
 url = "https://kubernetes.io"

 [[params.versions]]
-fullversion = "v1.17.4"
-version = "v1.17"
-githubbranch = "v1.17.4"
-docsbranch = "release-1.17"
-url = "https://v1-17.docs.kubernetes.io"
+fullversion = "v1.21.4"
+version = "v1.21"
+githubbranch = "v1.21.4"
+docsbranch = "master"
+url = "https://v1-21.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.16.8"
-version = "v1.16"
-githubbranch = "v1.16.8"
-docsbranch = "release-1.16"
-url = "https://v1-16.docs.kubernetes.io"
+fullversion = "v1.20.10"
+version = "v1.20"
+githubbranch = "v1.20.10"
+docsbranch = "release-1.20"
+url = "https://v1-20.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.15.11"
-version = "v1.15"
-githubbranch = "v1.15.11"
-docsbranch = "release-1.15"
-url = "https://v1-15.docs.kubernetes.io"
+fullversion = "v1.19.14"
+version = "v1.19"
+githubbranch = "v1.19.14"
+docsbranch = "release-1.19"
+url = "https://v1-19.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.14.10"
-version = "v1.14"
-githubbranch = "v1.14.10"
-docsbranch = "release-1.14"
-url = "https://v1-14.docs.kubernetes.io"
+fullversion = "v1.18.20"
+version = "v1.18"
+githubbranch = "v1.18.20"
+docsbranch = "release-1.18"
+url = "https://v1-18.docs.kubernetes.io"

 # User interface configuration
 [params.ui]
@@ -242,7 +242,7 @@ checks the state of each node every `--node-monitor-period` seconds.
 Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.

 There are two forms of heartbeats: updates of `NodeStatus` and the
-[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
+[Lease object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io).
 Each Node has an associated Lease object in the `kube-node-lease`
 {{< glossary_tooltip term_id="namespace" text="namespace">}}.
 Lease is a lightweight resource, which improves the performance
@@ -813,7 +813,7 @@ The output is similar to:
 The `imagePullSecrets` field is a list of references to secrets in the same namespace.
 You can use an `imagePullSecrets` to pass a secret that contains a Docker (or other) image registry
 password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod.
-See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
+See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.

 #### Manually specifying an imagePullSecret

@@ -613,11 +613,11 @@ metadata:
 provisioner: kubernetes.io/azure-disk
 parameters:
  storageaccounttype: Standard_LRS
-  kind: Shared
+  kind: managed
 ```

 * `storageaccounttype`: Azure storage account Sku tier. Default is empty.
-* `kind`: Possible values are `shared` (default), `dedicated`, and `managed`.
+* `kind`: Possible values are `shared`, `dedicated`, and `managed` (default).
  When `kind` is `shared`, all unmanaged disks are created in a few shared
  storage accounts in the same resource group as the cluster. When `kind` is
  `dedicated`, a new dedicated storage account will be created for the new
@@ -1,30 +1,12 @@
 ---
-title: Supported Versions of the Kubernetes Documentation
-content_type: concept
+title: Available Documentation Versions
+content_type: custom
+layout: supported-versions
 card:
  name: about
  weight: 10
-  title: Supported Versions of the Documentation
+  title: Available Documentation Versions
 ---

-<!-- overview -->
-
 This website contains documentation for the current version of Kubernetes
 and the four previous versions of Kubernetes.
-
-
-
-<!-- body -->
-
-## Current version
-
-The current version is
-[{{< param "version" >}}](/).
-
-## Previous versions
-
-{{< versions-other >}}
-
-
-
-
@@ -19,7 +19,7 @@ This section of the Kubernetes documentation contains references.
 ## API Reference

 * [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes.
-* [Kubernetes API Reference {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
+* [Kubernetes API Reference {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

 ## API Client Libraries

@@ -450,7 +450,7 @@ request (if not forced, see [Conflicts](#conflicts)).

 Field management is stored in a newly introduced `managedFields` field that is
 part of an object's
-[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta).
+[`metadata`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta).

 A simple example of an object created by Server Side Apply could look like this:

@@ -119,7 +119,7 @@ No Known Issues Reported
 - The following features are unconditionally enabled and the corresponding `--feature-gates` flags have been removed: `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` and `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness)) [SIG Apps and Scheduling]

 #### kubelet:
- `--enable-cadvisor-endpoints` is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, Node and Testing]
+- `--enable-cadvisor-json-endpoints` is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, Node and Testing]
 - Promote CSIMigrationOpenStack to Beta (off by default since it requires installation of the OpenStack Cinder CSI Driver. The in-tree AWS OpenStack Cinder driver "kubernetes.io/cinder" was deprecated in 1.16 and will be removed in 1.20. Users should enable CSIMigration + CSIMigrationOpenStack features and install the OpenStack Cinder CSI Driver (https://github.com/kubernetes-sigs/cloud-provider-openstack) to avoid disruption to existing Pod and PVC objects at that time. Users should start using the OpenStack Cinder CSI Driver directly for any new volumes. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG Cloud Provider]

 #### kubectl:
@@ -1039,7 +1039,7 @@ filename | sha512 hash
 ### API Change

 - Add kubescheduler.config.k8s.io/v1alpha2 ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
- --enable-cadvisor-endpoints is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, SIG Node, and SIG Testing]
+- --enable-cadvisor-json-endpoints is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, SIG Node, and SIG Testing]
 - The following feature gates are removed, because the associated features were unconditionally enabled in previous releases: CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]

 ### Feature
@@ -91,13 +91,6 @@ Find the latest stable 1.18 version:
    kubeadm version
    ```

-  Drain the control plane node:
-
-    ```shell
-    # replace <cp-node-name> with the name of your control plane node
-    kubectl drain <cp-node-name> --ignore-daemonsets
-    ```
-
 -   On the control plane node, run:

    ```shell
@@ -244,13 +237,6 @@ For more information see the [certificate management guide](/docs/tasks/administ

    This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.

-  Uncordon the control plane node:
-
-    ```shell
-    # replace <cp-node-name> with the name of your control plane node
-    kubectl uncordon <cp-node-name>
-    ```
-
 ### Upgrade additional control plane nodes

 Same as the first control plane node but use:
@@ -267,6 +253,15 @@ sudo kubeadm upgrade apply

 Also `sudo kubeadm upgrade plan` is not needed.

+###  Drain the control plane node
+
+- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
+
+    ```shell
+    # replace <cp-node-name> with the name of your control plane node
+    kubectl drain <cp-node-name> --ignore-daemonsets
+    ```
+
 ### Upgrade kubelet and kubectl

 Upgrade the kubelet and kubectl on all control plane nodes:
@@ -295,6 +290,15 @@ sudo systemctl daemon-reload
 sudo systemctl restart kubelet
 ```

+###  Uncordon the control plane node
+
+- Bring the node back online by marking it schedulable:
+
+    ```shell
+    # replace <cp-node-name> with the name of your control plane node
+    kubectl uncordon <cp-node-name>
+    ```
+
 ## Upgrade worker nodes

 The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time,
@@ -321,6 +325,14 @@ without compromising the minimum required capacity for running your workloads.
 {{% /tab %}}
 {{< /tabs >}}

+### Upgrade the kubelet configuration
+
+-  Call the following command:
+
+    ```shell
+    sudo kubeadm upgrade node
+    ```
+
 ### Drain the node

 -  Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
@@ -338,14 +350,6 @@ without compromising the minimum required capacity for running your workloads.
    node/ip-172-31-85-18 drained
    ```

-### Upgrade the kubelet configuration
-
-  Call the following command:
-
-    ```shell
-    sudo kubeadm upgrade node
-    ```
-
 ### Upgrade kubelet and kubectl

 -  Upgrade the kubelet and kubectl on all worker nodes:
@@ -41,12 +41,12 @@ Kubernetesはオープンソースなので、オンプレミスやパブリッ
        <button id="desktopShowVideoButton" onclick="kub.showVideo()">ビデオを見る</button>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">2020年8月17日-20日のKubeCon EUバーチャルに参加する</a>
-        <br>
-        <br>
-        <br>
-        <br>
        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">2020年11月17日-20日のKubeCon NAバーチャルに参加する</a>
+        <br>
+        <br>
+        <br>
+        <br>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">2021年5月4日-7日のKubeCon EUバーチャルに参加する</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -1,3 +1,4 @@
 ---
-title: ドキュメント 
+linktitle: Kubernetesドキュメント
+title: ドキュメント
 ---
@@ -1,21 +1,18 @@
 ---
-title: クラウドコントローラーマネージャーとそのコンセプト
+title: クラウドコントローラーマネージャー
 content_type: concept
 weight: 40
 ---

 <!-- overview -->

-クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
+{{< feature-state state="beta" for_k8s_version="v1.11" >}}

-クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
+クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーを信条としています。

-このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。
-
-これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。
-
-![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
+{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}}

+cloud-controller-managerは、プラグイン機構を用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。



@@ -23,91 +20,49 @@ weight: 40

 ## 設計

-上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します:
+![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)

-* Kubelet
-* Kubernetesコントローラーマネージャー
-* Kubernetes APIサーバー
+クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。

-CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります:
-
-![CCM Kube Arch](/images/docs/post-ccm-arch.png)
-
-## CCMのコンポーネント
-
-CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつかの機能群を切り離し、別のプロセスとして動かします。具体的には、KCMに含まれるクラウド依存のコントローラーを分離します。KCMは、下記に示すクラウド依存のコントローラーループを持っています:
-
- * ノードコントローラー
- * ボリュームコントローラー
- * ルートコントローラー
- * サービスコントローラー
-
-バージョン1.9では、CCMは前述のリスト内の下記コントローラーを動かします:
-
-* ノードコントローラー
-* ルートコントローラー
-* サービスコントローラー

 {{< note >}}
-ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。
+コントロールプレーンの一部ではなく、Kubernetesの{{< glossary_tooltip text="addon" term_id="addons" >}}としてクラウドコントローラーマネージャーを実行することもできます。
 {{< /note >}}

-CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。
+## クラウドコントローラーマネージャーの機能 {#functions-of-the-ccm}

-これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。
-
-## CCMの機能群
-
-CCMは、クラウドに依存しているKubernetesのコンポーネントから機能を継承しています。このセクションはそれらのコンポーネントをベースに構造化されています。
-
-### 1. Kubernetesコントローラーマネージャー
-
-CCMの大半の機能は、KCMから派生しています。前セクションで説明したとおり、CCMは下記のコントロールループを動かします:
-
-* ノードコントローラー
-* ルートコントローラー
-* サービスコントローラー
+クラウドコントローラーマネージャーのコントローラーは以下を含んでいます。

 #### ノードコントローラー

-ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責務を持ちます。ノードコントローラーは下記に示す機能を実行します:
+ノードコントローラーは、クラウドインフラストラクチャーで新しいサーバーが作成された際に、{{< glossary_tooltip text="Node" term_id="node" >}}オブジェクトを作成する責務を持ちます。ノードコントローラーは、クラウドプロバイダーのテナント内で動作しているホストの情報を取得します。ノードコントローラーは下記に示す機能を実行します:

-1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する
-2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する
-3. ノードのネットワークアドレスとホスト名を取得する
-4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する
+1. Nodeオブジェクトを、コントローラーがクラウドプロバイダーAPIを通じて見つけた各サーバーで初期化する
+2. Nodeオブジェクトに、ノードがデプロイされているリージョンや利用可能なリソース（CPU、メモリなど）のようなクラウド特有な情報を注釈付けやラベル付けをする
+3. ノードのホスト名とネットワークアドレスを取得する
+4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する
+
+いくつかのクラウドプロバイダーは、これをノードコントローラーと個別のノードライフサイクルコントローラーに分けて実装しています。

 #### ルートコントローラー

-ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
+ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。
+
+クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。

 #### サービスコントローラー

-サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
-
-### 2. Kubelet
-
-ノードコントローラーは、kubeletのクラウドに依存した機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責務を持っていました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。
-
-この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。
-
-## プラグインメカニズム
-
-クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
-
-上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。
-
-プラグインを開発するためのさらなる情報は、[クラウドコントローラーマネージャーを開発する](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を参照してください。
+{{< glossary_tooltip text="Services" term_id="service" >}}は、マネージドロードバランサー、IPアドレスネットワークパケットフィルタや対象のヘルスチェックのようなクラウドインフラストラクチャーコンポーネントのインテグレーションを行います。サービスコントローラーは、ロードバランサーや他のインフラストラクチャーコンポーネントを必要とするServiceリソースを宣言する際にそれらのコンポーネントを設定するため、クラウドプロバイダーのAPIと対話します。

 ## 認可

-このセクションでは、CCMが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。
+このセクションでは、クラウドコントローラーマネージャーが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。

-### ノードコントローラー
+### ノードコントローラー {#authorization-node-controller}

-ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。
+ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、readとmodifyの全権限が必要です。

-v1/Node:
+`v1/Node`:

 - Get
 - List
@@ -117,23 +72,23 @@ v1/Node:
 - Watch
 - Delete

-### ルートコントローラー
+### ルートコントローラー  {#authorization-route-controller}

 ルートコントローラーは、Nodeオブジェクトの作成を待ち受け、ルートを適切に設定します。Nodeオブジェクトについて、get権限が必要です。

-v1/Node:
+`v1/Node`:

 - Get

-### サービスコントローラー
+### サービスコントローラー {#authorization-service-controller}

-サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。
+サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのEndpointを適切に設定します。

 サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。

-サービスのエンドポイントを設定するため、create、list、get、watchそしてupdateの権限が必要です。
+サービスのEndpointリソースを設定するため、create、list、get、watchそしてupdateの権限が必要です。

-v1/Service:
+`v1/Service`:

 - List
 - Get
@@ -141,21 +96,21 @@ v1/Service:
 - Patch
 - Update

-### その他
+### その他 {#authorization-miscellaneous}

-CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。
+クラウドコントローラーマネージャーのコア機能の実装は、Eventオブジェクトのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。

-v1/Event:
+`v1/Event`:

 - Create
 - Patch
 - Update

-v1/ServiceAccount:
+`v1/ServiceAccount`:

 - Create

-CCMのRBAC ClusterRoleはこのようになります:
+クラウドコントローラーマネージャーの{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRoleはこのようになります:

 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -219,25 +174,16 @@ rules:
  - update
 ```

-## ベンダー実装

-下記のクラウドプロバイダーがCCMを実装しています:
+## {{% heading "whatsnext" %}}

-* [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)
+[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+はクラウドコントラーマネージャーの実行と管理を説明しています。

+どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？

-## クラスター管理
-
-CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。
+クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。

+本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。

+プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。
@@ -62,12 +62,10 @@ Kubernetesはシステムに対してクラウドネイティブな見方をす

 ## 設計

-設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。
+設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。

 相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。

-たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。
-
 {{< note >}}
 同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。

@@ -88,3 +86,4 @@ Kubernetesを拡張するためにコントロールプレーンの外で動作
 * 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ
 * [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ
 * 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。
+
@@ -6,27 +6,108 @@ weight: 10

 <!-- overview -->

-ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/ja/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。
-
+Kubernetesはコンテナを _Node_ 上で実行されるPodに配置することで、ワークロードを実行します。
+ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。
+各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。

+通常、1つのクラスターで複数のノードを持ちます。学習用途やリソースの制限がある環境では、1ノードかもしれません。

+1つのノード上の[コンポーネント](/ja/docs/concepts/overview/components/#node-components)には、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}が含まれます。

 <!-- body -->

+## 管理 {#management}
+
+ノードを{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に加えるには2つの方法があります:
+
+1. ノード上のkubeletが、コントロールプレーンに自己登録する。
+2. あなた、もしくは他のユーザーが手動でNodeオブジェクトを追加する。
+
+Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう:
+
+```json
+{
+  "kind": "Node",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "10.240.79.157",
+    "labels": {
+      "name": "my-first-k8s-node"
+    }
+  }
+}
+```
+
+Kubernetesは内部的にNodeオブジェクトを作成します。 APIサーバーに登録したkubeletがノードの`metadata.name`フィールドが一致しているか検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
+
+{{< note >}}
+Kubernetesは無効なNodeのオブジェクトを保持し、それが有効になるまで検証を続けます。
+
+ヘルスチェックを止めるためには、あなた、もしくは{{< glossary_tooltip term_id="controller" text="コントローラー">}}が明示的にNodeを削除する必要があります。
+{{< /note >}}
+
+Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
+### ノードの自己登録 {#self-registration-of-nodes}
+
+kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。
+
+自己登録については、kubeletは以下のオプションを伴って起動されます:
+
+  - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス
+  - `--cloud-provider` - 自身に関するメタデータを読むために{{< glossary_tooltip text="クラウドプロバイダー" term_id="cloud-provider" >}}と会話する方法
+  - `--register-node` - 自身をAPIサーバーに自動的に登録
+  - `--register-with-taints` - 与えられた{{< glossary_tooltip text="taint" term_id="taint" >}}のリストでノードを登録します (カンマ区切りの `<key>=<value>:<effect>`)。 
+  
+  `register-node`がfalseの場合、このオプションは機能しません
+  - `--node-ip` - ノードのIPアドレス
+  - `--node-labels` - ノードをクラスターに登録するときに追加する{{< glossary_tooltip text="Label" term_id="label" >}}（[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照）
+  - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定
+
+[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。
+
+### 手動によるノード管理 {#manual-node-administration}
+
+クラスター管理者は{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}を使用してNodeオブジェクトを作成および変更できます。
+
+管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。
+
+管理者は`--register-node`の設定に関係なくNodeオブジェクトを変更することができます。
+例えば、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
+
+ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクターと組み合わせて使用できます。
+例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。
+
+ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。
+これは、ノードの再起動などの前の準備ステップとして役立ちます。
+
+ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します:
+
+```shell
+kubectl cordon $ノード名
+```
+
+{{< note >}}
+{{< glossary_tooltip term_id="daemonset" >}}によって作成されたPodはノード上のunschedulable属性を考慮しません。
+これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、DaemonSetがマシンに属していることを前提としているためです。
+{{< /note >}}
+
 ## ノードのステータス

-ノードのステータスには以下のような情報が含まれます:
+ノードのステータスは以下の情報を含みます:

 * [Addresses](#addresses)
 * [Conditions](#condition)
 * [CapacityとAllocatable](#capacity)
 * [Info](#info)

-ノードのステータスや、ノードに関するその他の詳細は、下記のコマンドを使うことで表示できます:
+`kubectl`を使用し、ノードのステータスや詳細を確認できます:
+
 ```shell
-kubectl describe node <ノード名>
+kubectl describe node <ノード名をここに挿入>
 ```
-各セクションについては、下記で説明します。
+
+出力情報の各箇所について、以下で説明します。

 ### Addresses

@@ -41,15 +122,22 @@ kubectl describe node <ノード名>

 `conditions`フィールドは全ての`Running`なノードのステータスを表します。例として、以下のような状態を含みます:

-| ノードのCondition | 概要 |
-|----------------|-------------|
-| `Ready`        | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
-| `MemoryPressure`    | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
-| `PIDPressure`    | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
-| `DiskPressure`    | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
-| `NetworkUnavailable`    | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 |
+{{< table caption = "ノードのConditionと、各condition適用時の概要" >}}
+| ノードのCondition       | 概要 |
+|----------------------|-------------|
+| `Ready`              | ノードの状態が有効でPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
+| `DiskPressure`       | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `MemoryPressure`     | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `PIDPressure`        | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
+| `NetworkUnavailable` | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 |
+{{< /table >}}

-ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のようなレスポンスが表示されます。
+{{< note >}}
+コマンドラインを使用してcordonされたNodeを表示する場合、Conditionは`SchedulingDisabled`を含みます。
+`SchedulingDisabled`はKubernetesのAPIにおけるConditionではありません;その代わり、cordonされたノードはUnschedulableとしてマークされます。
+{{< /note >}}
+
+ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のような構造体が表示されます。

 ```json
 "conditions": [
@@ -64,14 +152,15 @@ kubectl describe node <ノード名>
 ]
 ```

-Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`Unknown`や`False`のままになっている場合、[kube-controller-manager](/docs/admin/kube-controller-manager/)に引数が渡され、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodたちは切り離されたノードの上で稼働を続けることになります。
+Ready conditionが`pod-eviction-timeout`({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に渡された引数)に設定された時間を超えても`Unknown`や`False`のままになっている場合、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodは切り離されたノードの上で稼働を続けることになります。

-バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
-
-ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。
+ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。

+ノードのライフサイクルコントローラーがconditionを表した[taint](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を自動的に生成します。
 スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。

+詳細は[条件によるtaintの付与](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)を参照してください。
+
 ### CapacityとAllocatable {#capacity}

 ノードで利用可能なリソース（CPU、メモリ、およびノードでスケジュールできる最大Pod数）について説明します。
@@ -115,7 +204,7 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ

 ### ノードコントローラー

-ノードコントローラーは、ノードのさまざまな側面を管理するKubernetesのマスターコンポーネントです。
+ノード{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、ノードのさまざまな側面を管理するKubernetesのコントロールプレーンコンポーネントです。

 ノードコントローラーは、ノードの存続期間中に複数の役割を果たします。1つ目は、ノードが登録されたときにCIDRブロックをノードに割り当てることです（CIDR割り当てがオンになっている場合）。

@@ -140,10 +229,6 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担

 #### 信頼性

-
-Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため）
-バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。
-
 ほとんどの場合、排除の速度は1秒あたり`--node-eviction-rate`に設定された数値（デフォルトは秒間0.1）です。つまり、10秒間に1つ以上のPodをノードから追い出すことはありません。

 特定のアベイラビリティーゾーン内のノードのステータスが異常になると、ノード排除の挙動が変わります。ノードコントローラーは、ゾーン内のノードの何%が異常（NodeReady条件がConditionUnknownまたはConditionFalseである）であるかを同時に確認します。
@@ -156,51 +241,8 @@ Kubernetes 1.4では、マスターに問題が発生した場合の対処方法
 コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。
 このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。

-Kubernetes 1.6以降では、ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
-さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応するtaintを追加する責務があります。
-`NoExecute`のtaint及び上述のアルファ機能に関する詳細は、[こちらのドキュメント](/docs/concepts/configuration/taint-and-toleration/)をご覧ください。
-
-バージョン1.8以降、ノードコントローラーに対してノードの状態を表すtaintを作成する責務を持たせることができます。これはバージョン1.8のアルファ機能です。
-
-### ノードの自己登録
-
-kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。
-
-自己登録については、kubeletは以下のオプションを伴って起動されます:
-
-  - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス
-  - `--cloud-provider` - 自身に関するメタデータを読むためにクラウドプロバイダーと会話する方法
-  - `--register-node` - 自身をAPIサーバーに自動的に登録
-  - `--register-with-taints` - 与えられたtaintのリストでノードを登録します (カンマ区切りの `<key>=<value>:<effect>`). `register-node`がfalseの場合、このオプションは機能しません
-  - `--node-ip` - ノードのIPアドレス
-  - `--node-labels` - ノードをクラスターに登録するときに追加するラベル（1.13以降の[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照）
-  - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定
-
-[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。
-
-#### 手動によるノード管理 {#manual-node-administration}
-
-クラスター管理者はNodeオブジェクトを作成および変更できます。
-
-管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。
-
-管理者は`--register-node`の設定に関係なくNodeリソースを変更することができます。
-変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
-
-ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。
-例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。
-
-ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。
-これは、ノードの再起動などの前の準備ステップとして役立ちます。たとえば、ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します:
-
-```shell
-kubectl cordon $ノード名
-```
-
-{{< note >}}
-DaemonSetコントローラーによって作成されたPodはKubernetesスケジューラーをバイパスし、ノード上のunschedulable属性を考慮しません。
-これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。
-{{< /note >}}
+ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
+さらに、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。

 {{< caution >}}
 `kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
@@ -209,29 +251,28 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ

 ### ノードのキャパシティ

-ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。
-通常、ノードは自分自身を登録し、Nodeオブジェクトを作成するときにキャパシティを報告します。
+Nodeオブジェクトはノードのリソースキャパシティ（CPUの数とメモリの量）を監視します。
+[自己登録](#self-registration-of-nodes)したノードは、Nodeオブジェクトを作成するときにキャパシティを報告します。
 [手動によるノード管理](#manual-node-administration)を実行している場合は、ノードを追加するときにキャパシティを設定する必要があります。

-Kubernetesスケジューラーは、ノード上のすべてのPodに十分なリソースがあることを確認します。
-ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
-これは、kubeletによって開始されたすべてのコンテナを含みますが、[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)によって直接開始されたコンテナやコンテナの外で実行されているプロセスは含みません。
+Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。スケジューラーは、ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
+これは、kubeletによって管理されたすべてのコンテナを含みますが、コンテナランタイムによって直接開始されたコンテナやkubeletの制御外で実行されているプロセスは含みません。

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

 ## ノードのトポロジー

-{{< feature-state state="alpha" >}}
+{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
 `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).
-
+詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。

 ## {{% heading "whatsnext" %}}

-* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。
-* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
+* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。
+* [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。
+* アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。
+* [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。
+* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。
@@ -9,7 +9,7 @@ weight: 50
 ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。
 Kubernetesには、4つの異なる対応すべきネットワークの問題があります:

-1. 高度に結合されたコンテナ間の通信: これは、[Pod](/ja/docs/concepts/workloads/pods/pod/)および`localhost`通信によって解決されます。
+1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pod" term_id="pod" >}}および`localhost`通信によって解決されます。
 2. Pod間の通信: 本ドキュメントの主な焦点です。
 3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
 4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
@@ -24,7 +24,7 @@ Kubernetesは、言ってしまえばアプリケーション間でマシンを

 動的ポート割り当てはシステムに多くの複雑さをもたらします。すべてのアプリケーションはパラメータとしてポートを管理する必要があり、APIサーバーにて動的なポート番号を設定値として注入する方法が必要となり、各サービスはお互いにお互いを見つける方法が必要です。Kubernetesはこれに対処するのではなく、別のアプローチを取ります。

-## Kubernetesのネットワークモデル
+## Kubernetesのネットワークモデル {#the-kubernetes-network-model}

 すべての`Pod`は独自のIPアドレスを持ちます。これは、`Pod`間のリンクを明示的に作成する必要がなく、コンテナポートをホストポートにマッピングする必要がほとんどないことを意味します。こうすることで、ポート割り当て、名前解決、サービスディスカバリー、負荷分散、アプリケーション設定、および移行の観点から、`Pod`をVMまたは物理ホストと同様に扱うことができる、クリーンで後方互換性のあるモデルを生み出しています。

@@ -45,7 +45,7 @@ KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内の

 `Pod`に転送する`ノード`自体のポート(ホストポートと呼ばれる)を要求することは可能ですが、これは非常にニッチな操作です。このポート転送の実装方法も、コンテナランタイムの詳細部分です。`Pod`自体は、ホストポートの有無を認識しません。

-## Kubernetesネットワークモデルの実装方法
+## Kubernetesネットワークモデルの実装方法 {#how-to-implement-the-kubernetes-networking-model}

 このネットワークモデルを実装する方法はいくつかあります。このドキュメントは、こうした方法を網羅的にはカバーしませんが、いくつかの技術の紹介として、また出発点として役立つことを願っています。

@@ -67,7 +67,7 @@ Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to i

 ### AOS from Apstra

-[AOS](http://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform.  AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs.
+[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform.  AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs.

 The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems.  These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs).  AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment.

@@ -75,7 +75,7 @@ AOS has a rich set of REST API endpoints that enable Kubernetes to quickly chang

 AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux.

-Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/
+Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/

 ### AWS VPC CNI for Kubernetes

@@ -97,7 +97,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https:/

 With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed.

-BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
+BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).

 ### Cilium

@@ -109,7 +109,7 @@ addressing, and it can be used in combination with other CNI plugins.

 ### CNI-Genie from Huawei

-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
+[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).

 CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.

@@ -131,11 +131,11 @@ network complexity required to deploy Kubernetes at scale within AWS.

 ### Contiv

-[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced.
+[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.

 ### Contrail / Tungsten Fabric

-[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
+[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.

 ### DANM

@@ -216,7 +216,7 @@ traffic to the internet.

 ### Kube-router

-[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
+[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.

 ### L2 networks and linux bridging

@@ -226,8 +226,8 @@ Note that these instructions have only been tried very casually - it seems to
 work, but has not been thoroughly tested.  If you use this technique and
 perfect the process, please let us know.

-Follow the "With Linux Bridge devices" section of [this very nice
-tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
+Follow the "With Linux Bridge devices" section of
+[this very nice tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
 Lars Kellogg-Stedman.

 ### Multus (a Multi Network plugin)
@@ -236,6 +236,10 @@ Lars Kellogg-Stedman.

 Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.

+### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin)
+
+[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
+
 ### NSX-T

 [VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal.
@@ -244,7 +248,7 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p

 ### Nuage Networks VCS (Virtualized Cloud Services)

-[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
+[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.

 The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.

@@ -264,7 +268,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).

 ### Project Calico

-[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
+[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine.

 Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)).  Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking.  Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.

@@ -272,7 +276,7 @@ Calico can also be run in policy enforcement mode in conjunction with other netw

 ### Romana

-[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
+[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.

 ### Weave Net from Weaveworks

@@ -84,7 +84,7 @@ CPUは常に相対量としてではなく、絶対量として要求されま
 ### メモリーの意味

 `メモリー`の制限と要求はバイト単位で測定されます。
-E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点整数として表すことができます。
+E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点数として表すことができます。
 また、Ei、Pi、Ti、Gi、Mi、Kiのような2の累乗の値を使用することもできます。
 たとえば、以下はほぼ同じ値を表しています。

@@ -104,11 +104,9 @@ metadata:
  name: frontend
 spec:
  containers:
-  - name: db
-    image: mysql
+  - name: app
+    image: images.my-company.example/app:v4
    env:
-    - name: MYSQL_ROOT_PASSWORD
-      value: "password"
    resources:
      requests:
        memory: "64Mi"
@@ -116,8 +114,8 @@ spec:
      limits:
        memory: "128Mi"
        cpu: "500m"
-  - name: wp
-    image: wordpress
+  - name: log-aggregator
+    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
@@ -185,7 +183,7 @@ kubeletは、ローカルのエフェメラルストレージを使用して、P
 また、kubeletはこの種類のストレージを使用して、[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)、コンテナイメージ、実行中のコンテナの書き込み可能なレイヤーを保持します。

 {{< caution >}}
-Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。  
+Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。
 アプリケーションは、ローカルのエフェメラルストレージにパフォーマンスのサービス品質保証(ディスクのIOPSなど)を期待することはできません。
 {{< /caution >}}

@@ -242,7 +240,7 @@ Podの各コンテナは、次の1つ以上を指定できます。
 * `spec.containers[].resources.requests.ephemeral-storage`

 `ephemeral-storage`の制限と要求はバイト単位で記します。
-ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点整数として表すことができます。
+ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点数として表すことができます。
 E、P、T、G、M、K。Ei、Pi、Ti、Gi、Mi、Kiの2のべき乗を使用することもできます。
 たとえば、以下はほぼ同じ値を表しています。

@@ -262,18 +260,15 @@ metadata:
  name: frontend
 spec:
  containers:
-  - name: db
-    image: mysql
-    env:
-    - name: MYSQL_ROOT_PASSWORD
-      value: "password"
+  - name: app
+    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
-  - name: wp
-    image: wordpress
+  - name: log-aggregator
+    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
@@ -300,6 +295,7 @@ kubeletがローカルのエフェメラルストレージをリソースとし
 Podが許可するよりも多くのエフェメラルストレージを使用している場合、kubeletはPodの排出をトリガーするシグナルを設定します。

 コンテナレベルの分離の場合、コンテナの書き込み可能なレイヤーとログ使用量がストレージの制限を超えると、kubeletはPodに排出のマークを付けます。
+
 Podレベルの分離の場合、kubeletはPod内のコンテナの制限を合計し、Podの全体的なストレージ制限を計算します。
 このケースでは、すべてのコンテナからのローカルのエフェメラルストレージの使用量とPodの`emptyDir`ボリュームの合計がPod全体のストレージ制限を超過する場合、
 kubeletはPodをまた排出対象としてマークします。
@@ -345,7 +341,7 @@ Kubernetesでは、`1048576`から始まるプロジェクトIDを使用しま
 Kubernetesが使用しないようにする必要があります。

 クォータはディレクトリスキャンよりも高速で正確です。
-ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。  
+ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。
 ファイルが作成されて削除されても、開いているファイルディスクリプタがあれば、スペースを消費し続けます。
 クォータトラッキングはそのスペースを正確に記録しますが、ディレクトリスキャンは削除されたファイルが使用するストレージを見落としてしまいます。

@@ -354,7 +350,7 @@ Kubernetesが使用しないようにする必要があります。
 * kubelet設定で、`LocalocalStorpactionCapactionIsolationFSQuotaMonitoring=true`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gate/)を有効にします。

 * ルートファイルシステム(またはオプションのランタイムファイルシステム))がプロジェクトクォータを有効にしていることを確認してください。
-  すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。  
+  すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。
  ext4ファイルシステムでは、ファイルシステムがマウントされていない間は、プロジェクトクォータ追跡機能を有効にする必要があります。
  ```bash
  # ext4の場合、/dev/block-deviceがマウントされていません
@@ -31,7 +31,7 @@ weight: 10

 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。

-  明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
+  明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/job/)のほうが適切な場合もあるかもしれません。

 ## Service

@@ -68,11 +68,11 @@ weight: 10

 ## コンテナイメージ

-[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/admin/kubelet/)が特定のイメージをpullしようとしたときに作用します。
+[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/reference/command-line-tools-reference/kubelet/)が特定のイメージをpullしようとしたときに作用します。

 - `imagePullPolicy: IfNotPresent`: ローカルでイメージが見つからない場合にのみイメージをpullします。

- `imagePullPolicy: Always`: Podの起動時に常にイメージをpullします。
+- `imagePullPolicy: Always`: kubeletがコンテナを起動する度に、kubeletはコンテナイメージレジストリに問い合わせて、イメージのダイジェストの名前解決を行います。もし、kubeletが同じダイジェストのコンテナイメージをローカルにキャッシュしていたら、kubeletはそのキャッシュされたイメージを利用します。そうでなければ、kubeletは解決されたダイジェストのイメージをダウンロードし、そのイメージを利用してコンテナを起動します。

 - `imagePullPolicy` のタグが省略されていて、利用してるイメージのタグが`:latest`の場合や省略されている場合、`Always`が適用されます。

@@ -98,6 +98,6 @@ weight: 10

 - `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。

-
+- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment`や`kubectl expose`を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。


@@ -1,4 +1,33 @@
 ---
-title: "コンテナ"
+title: コンテナ
 weight: 40
+description: アプリケーションとランタイムの依存関係を一緒にパッケージ化するための技術
+reviewers:
+content_type: concept
+no_list: true
 ---
+
+<!-- overview -->
+
+実行するそれぞれのコンテナは繰り返し使用可能です。依存関係を含めて標準化されており、どこで実行しても同じ動作が得られることを意味しています。
+
+コンテナは基盤となるホストインフラからアプリケーションを切り離します。これにより、さまざまなクラウドやOS環境下でのデプロイが容易になります。
+
+
+
+
+<!-- body -->
+
+## コンテナイメージ
+[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
+
+設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
+
+## コンテナランタイム
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+
+* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。
+* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。
@@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
 ハンドラーにパラメーターは渡されません。

-終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。
+終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。

 ### フックハンドラーの実装

@@ -102,4 +102,3 @@ Events:
 * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン


-
@@ -11,20 +11,18 @@ weight: 20

 このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。

-{{< warning >}}
-RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。
-{{< /warning >}}
-
-
+RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。


 <!-- body -->

-## RuntimeClassについて
+## RuntimeClassを使う動機

-RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。
+異なるPodに異なるRuntimeClassを設定することで、パフォーマンスとセキュリティのバランスをとることができます。例えば、ワークロードの一部に高レベルの情報セキュリティ保証が必要な場合、ハードウェア仮想化を使用するコンテナランタイムで実行されるようにそれらのPodをスケジュールすることを選択できます。その後、追加のオーバーヘッドを犠牲にして、代替ランタイムをさらに分離することでメリットが得られます。

-### セットアップ
+RuntimeClassを使用して、コンテナランタイムは同じで設定が異なるPodを実行することもできます。
+
+## セットアップ

 RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
 その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。
@@ -32,7 +30,7 @@ RuntimeClass機能のフィーチャーゲートが有効になっているこ
 1. ノード上でCRI実装を設定する。(ランタイムに依存)
 2. 対応するRuntimeClassリソースを作成する。

-#### 1. ノード上でCRI実装を設定する。
+### 1. ノード上でCRI実装を設定する

 RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。
 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。
@@ -44,7 +42,7 @@ RuntimeClassは、クラスター全体で同じ種類のノード設定であ

 RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。

-#### 2. 対応するRuntimeClassリソースを作成する
+### 2. 対応するRuntimeClassリソースを作成する

 ステップ1にて設定する各項目は、関連する`ハンドラー` 名を持ちます。それはどの設定かを指定するものです。各ハンドラーにおいて、対応するRuntimeClassオブジェクトが作成されます。

@@ -68,7 +66,7 @@ RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター
 Overview](/docs/reference/access-authn-authz/authorization/)を参照してください。
 {{< /note >}}

-### 使用例
+## 使用例

 一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecの`runtimeClassName`を指定してください。  
 例えば
@@ -119,17 +117,15 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim
  runtime_path = "${PATH_TO_BINARY}"
 ```

-CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。
+詳細はCRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)を参照してください。

-[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
-
-### スケジューリング {#scheduling}
+## スケジューリング {#scheduling}

 {{< feature-state for_k8s_version="v1.16" state="beta" >}}

 Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。
 このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。
-スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです)
+スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)を有効にしなければなりません。(1.16ではデフォルトです)

 特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。
 RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。
@@ -138,40 +134,20 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele
 もしサポートされているノードが他の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/
+ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)を参照してください。

 ### Podオーバーヘッド

-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}

-Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。
-`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです)
+Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
+Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです)

-PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。
+PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。
 このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。

-### RutimeClassをα版からβ版にアップグレードする

-RuntimeClassのβ版の機能は、下記の変更点を含みます。
-
- `node.k8s.io`APIグループと`runtimeclasses.node.k8s.io`リソースはCustomResourceDefinitionからビルトインAPIへとマイグレーションされました。
- `spec`はRuntimeClassの定義内にインライン化されました(RuntimeClassSpecはすでにありません)。
- `runtimeHandler`フィールドは`handler`にリネームされました。
- `handler`フィールドは、全てのAPIバージョンにおいて必須となりました。これはα版のAPIでの`runtimeHandler`フィールドもまた必須であることを意味します。
- `handler`フィールドは正しいDNSラベルの形式である必要があり([RFC 1123](https://tools.ietf.org/html/rfc1123))、これは`.`文字はもはや含むことができないことを意味します(全てのバージョンにおいて)。有効なハンドラー名は、次の正規表現に従います。`^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
-
-**Action Required:** 次のアクションはRuntimeClassのα版からβ版へのアップグレードにおいて対応が必須です。
-
- RuntimeClassリソースはKubernetes v1.14にアップグレードされた*後に* 再作成されなくてはなりません。そして`runtimeclasses.node.k8s.io`というCRDは手動で削除されるべきです。  
-  ```
-  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
-  ```
- `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。
-
-
-### 参考文献
+## {{% heading "whatsnext" %}}

 - [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)
@@ -1,4 +1,164 @@
 ---
 title: Kubernetesを拡張する
 weight: 110
+description: Kubernetesクラスターの挙動を変えるいろいろな方法
+content_type: concept
+no_list: true
 ---
+
+<!-- overview -->
+Kubernetesは柔軟な設定が可能で、高い拡張性を持っています。
+結果として、Kubernetesのプロジェクトソースコードをフォークしたり、パッチを当てて利用することは滅多にありません。
+このガイドは、Kubernetesクラスターをカスタマイズするための選択肢を記載します。
+管理しているKubernetesクラスターを、動作環境の要件にどのように適合させるべきかを理解したい{{< glossary_tooltip text="クラスター管理者" term_id="cluster-operator" >}}を対象にしています。
+将来の {{< glossary_tooltip text="プラットフォーム開発者" term_id="platform-developer" >}} 、またはKubernetesプロジェクトの{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}にとっても、どのような拡張のポイントやパターンが存在するのか、また、それぞれのトレードオフや制限事項を学ぶための導入として役立つでしょう。
+<!-- body -->
+## 概要
+カスタマイズのアプローチには大きく分けて、フラグ、ローカル設定ファイル、またはAPIリソースの変更のみを含んだ *設定* と、稼働しているプログラムまたはサービスも含んだ *拡張* があります。このドキュメントでは、主に拡張について説明します。
+## 設定
+
+*設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:
+
+* [kubelet](/docs/admin/kubelet/)
+* [kube-apiserver](/docs/admin/kube-apiserver/)
+* [kube-controller-manager](/docs/admin/kube-controller-manager/)
+* [kube-scheduler](/docs/admin/kube-scheduler/)
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
+
+ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
+
+[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
+
+## 拡張
+
+拡張はKubernetesを拡張し、深く統合されたソフトウェアの構成要素です。
+これは新しいタイプと、新しい種類のハードウェアをサポートするために利用されます。
+
+ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。
+結果として、ほとんどのKubernetesユーザーは既存の拡張を使えばよいため、新しい拡張を書く必要は無いと言えます。
+
+## 拡張パターン {#extension-patterns}
+
+Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。
+Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。
+*自動化機能* はクラスター上、またはクラスター外で実行できます。
+このドキュメントに後述のガイダンスに従うことで、高い可用性を持つ頑強な自動化機能を書くことができます。
+自動化機能は通常、ホスティングされているクラスター、マネージドな環境など、どのKubernetesクラスター上でも動きます。
+
+Kubernetes上でうまく動くクライアントプログラムを書くために、*コントローラー* パターンという明確なパターンがあります。
+コントローラーは通常、オブジェクトの `.spec` を読み取り、何らかの処理をして、オブジェクトの `.status` を更新します。
+
+コントローラーはKubernetesのクライアントです。Kubernetesがクライアントとして動き、外部のサービスを呼び出す場合、それは *Webhook* と呼ばれます。
+呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。
+
+Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
+*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
+バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。
+
+下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
+
+<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
+
+## 拡張ポイント
+
+この図は、Kubernetesにおける拡張ポイントを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
+
+<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
+
+1.   ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。
+2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセス拡張](/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。
+3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセス拡張と一緒に使われます。
+4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラー拡張](/docs/concepts/extend-kubernetes/#scheduler-extensions)セクションに記載されています。
+5.   Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。
+6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
+7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。
+
+もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類の拡張を含んでいることを留意してください。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
+
+<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
+
+## API拡張
+### ユーザー定義タイプ
+
+新しいコントローラー、アプリケーションの設定に関するオブジェクト、また宣言型APIを定義し、それらを`kubectl`のようなKubernetesのツールから管理したい場合、Kubernetesにカスタムリソースを追加することを検討して下さい。
+
+カスタムリソースはアプリケーション、ユーザー、監視データのデータストレージとしては使わないで下さい。
+
+カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を参照して下さい。
+
+### 新しいAPIと自動化機能の連携
+
+カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
+
+### ビルトインリソースの変更
+
+カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセス拡張の場合、その可能性があります。
+
+### APIアクセス拡張 {#api-access-extensions}
+
+リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
+
+これらの各ステップごとに拡張ポイントが用意されています。
+
+Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/)でカバーされています。
+
+### 認証
+
+[認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
+
+Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
+
+### 認可
+
+[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可メカニズムが要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
+
+### 動的Admission Control
+
+リクエストが認可された後、もしそれが書き込み操作だった場合、リクエストは[Admission Control](/docs/reference/access-authn-authz/admission-controllers/)のステップを通ります。ビルトインのステップに加え、いくつかの拡張が存在します:
+
+*   [イメージポリシーWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)は、コンテナでどのイメージを実行することができるかを制限する
+*   任意のAdmission Controlの決定を行うには、一般的な[Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)が利用できる。Admission Webhookは作成、更新を拒絶できる
+
+## インフラストラクチャ拡張
+
+### ストレージプラグイン
+
+[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
+
+### デバイスプラグイン
+
+[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
+
+### ネットワークプラグイン
+
+他のネットワークファブリックが[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じてサポートされます。
+
+### スケジューラー拡張
+
+スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)を同時に動かすこともできます。
+
+これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
+
+スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラー拡張)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)についてより深く学ぶ
+* [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
+* インフラストラクチャ拡張についてより深く学ぶ
+  * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+  * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+* [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
+* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
@@ -32,9 +32,9 @@ kube-apiserverとの間を5秒以内に往復するためには、ディスカ
 ## {{% heading "whatsnext" %}}


-* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します
-* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します
-* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい
+* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)します
+* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/extend-kubernetes/setup-extension-api-server/)します
+* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)方法を学んで下さい
 * [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい


@@ -18,7 +18,7 @@ weight: 10

 *カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。

-カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/user-guide/kubectl-overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。
+カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。

 ## カスタムコントローラー

@@ -31,7 +31,7 @@ weight: 10

 ## カスタムリソースをクラスターに追加するべきか？

-新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。
+新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。

 | APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: |
 | ------------------------------ | ---------------------------- |
@@ -78,7 +78,7 @@ APIが宣言的ではない兆候として、次のものがあります:
 * ファイルが更新されたときに、Deploymentなどを介してローリングアップデートを行いたい

 {{< note >}}
-センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/docs/concepts/configuration/secret/)を使ってください
+センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/ja/docs/concepts/configuration/secret/)を使ってください
 {{< /note >}}

 下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください:
@@ -107,7 +107,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類

 ## CustomResourceDefinition

-[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。
+[CustomResourceDefinition](/docs/tasks/extend-kubernetes/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サーバーアグリゲーション)と比べると、柔軟性に欠けます。
@@ -136,7 +136,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。
 | CRD                        | アグリゲートAPI |
 | -------------------------- | --------------- |
 | プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 |
-| 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある |
+| 追加のサービスは不要。CRDはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある |
 | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない |
 | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 |

@@ -146,17 +146,17 @@ 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)によりサポートされている | はい、任意のバリデーションが可能 |
+| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 |
 | デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (ただし、この方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい |
-| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい |
+| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | はい |
 | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい |
 | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい |
-| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい |
-| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい |
+| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | はい |
+| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/extend-kubernetes/custom-resources/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/)を参照 | いいえ | はい |
+| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
 | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい |
-| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
+| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |

 ### 一般的な機能

@@ -166,7 +166,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
 | ---- | -------------- |
 | CRUD | 新しいエンドポイントが、HTTP、`kubectl`を通じて、基本的なCRUD処理をサポート |
 | Watch | 新しいエンドポイントが、HTTPを通じて、KubernetesのWatch処理をサポート |
-| Discovery | kubectlやダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 |
+| Discovery | `kubectl`やダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 |
 | json-patch | 新しいエンドポイントが`Content-Type: application/json-patch+json`を用いたPATCHをサポート |
 | merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート |
 | HTTPS | 新しいエンドポイントがHTTPSを利用 |
@@ -205,11 +205,11 @@ CRDでは、APIサーバーのビルトインリソースと同じ認証、認

 ## カスタムリソースへのアクセス

-Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、GoとPythonのライブラリーはサポートしています。
+Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_ と _Python_ のライブラリーはサポートしています。

 カスタムリソースは、下記のような方法で操作できます:

- kubectl
+- `kubectl`
 - kubernetesの動的クライアント
 - 自作のRESTクライアント
 - [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります)
@@ -220,4 +220,4 @@ 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/)について学ぶ
+* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)について学ぶ
@@ -25,14 +25,14 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています

 *設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:

-* [kubelet](/docs/admin/kubelet/)
-* [kube-apiserver](/docs/admin/kube-apiserver/)
-* [kube-controller-manager](/docs/admin/kube-controller-manager/)
-* [kube-scheduler](/docs/admin/kube-scheduler/)
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)

 ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。

-[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
+[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/using-api/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。

 ## エクステンション

@@ -58,7 +58,7 @@ Kubernetes上でうまく動くクライアントプログラムを書くため

 Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
 *バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
-バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/))、またkubectlで利用されています。
+バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。

 下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。

@@ -75,12 +75,12 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->

 1.   ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。
-2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセスエクステンション](/docs/concepts/overview/extending#api-access-extensions)セクションに記載されています。
-3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/overview/extending#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセスエクステンションと一緒に使われます。
-4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラーエクステンション](/docs/concepts/overview/extending#scheduler-extensions)セクションに記載されています。
+2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセスエクステンション](/ja/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。
+3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/ja/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセスエクステンションと一緒に使われます。
+4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラーエクステンション](/ja/docs/concepts/extend-kubernetes/#scheduler-extensions)セクションに記載されています。
 5.   Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。
-6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/overview/extending#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
-7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/overview/extending#storage-plugins)を通じてサポートされます。
+6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/ja/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
+7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/ja/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。

 もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類のエクステンションを含んでいることを留意してください。

@@ -95,11 +95,11 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま

 カスタムリソースはアプリケーション、ユーザー、監視データのデータストレージとしては使わないで下さい。

-カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/docs/concepts/api-extension/custom-resources/)を参照して下さい。
+カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を参照して下さい。

 ### 新しいAPIと自動化機能の連携

-カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
+カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。

 ### ビルトインリソースの変更

@@ -111,11 +111,11 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま

 これらの各ステップごとに拡張ポイントが用意されています。

-Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
+Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/)でカバーされています。

 ### 認証

-[認証](/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
+[認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。

 Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。

@@ -134,19 +134,19 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件

 ### ストレージプラグイン

-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
+[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。

 ### デバイスプラグイン

-[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
+[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。

 ### ネットワークプラグイン

-他のネットワークファブリックが[ネットワークプラグイン](/docs/admin/network-plugins/)を通じてサポートされます。
+他のネットワークファブリックが[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じてサポートされます。

 ### スケジューラーエクステンション

-スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/administer-cluster/configure-multiple-schedulers/)を同時に動かすこともできます。
+スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)を同時に動かすこともできます。

 これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。

@@ -157,12 +157,10 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
 ## {{% heading "whatsnext" %}}


-* [カスタムリソース](/docs/concepts/api-extension/custom-resources/)についてより深く学ぶ
+* [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)についてより深く学ぶ
 * [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
 * インフラストラクチャエクステンションについてより深く学ぶ
-  * [ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)
-  * [デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)
+  * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+  * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 * [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
 * [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
-
-
@@ -6,8 +6,8 @@ weight: 30

 <!-- overview -->

-オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。
-オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。
+オペレーターは[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。
+オペレーターは、特に[制御ループ](/ja/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。



@@ -75,7 +75,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
 ## 自分でオペレーターを書く {#writing-operator}

 必要な振る舞いを実装したオペレーターがエコシステム内に無い場合、自分で作成することができます。
-[次の項目](#what-s-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。
+[次の項目](#whats-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。

 オペレーター（すなわち、コントローラー）はどの言語/ランタイムでも実装でき、[Kubernetes APIのクライアント](/docs/reference/using-api/client-libraries/)として機能させることができます。

@@ -95,4 +95,3 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
 * オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます
 * Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます

-
@@ -1,6 +1,8 @@
 ---
 title: Kubernetesのコンポーネント
 content_type: concept
+description: >
+  Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。
 weight: 20
 card: 
  name: concepts
@@ -53,20 +55,18 @@ Kubernetesをデプロイすると、クラスターが展開されます。

 ### cloud-controller-manager

-[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) は、基盤であるクラウドプロバイダーと対話するコントローラーを実行します。
-cloud-controller-managerバイナリは、Kubernetesリリース1.6で導入された機能です。
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}

-cloud-controller-managerは、クラウドプロバイダー固有のコントローラーループのみを実行します。これらのコントローラーループはkube-controller-managerで無効にする必要があります。 kube-controller-managerの起動時に `--cloud-provider` フラグを `external` に設定することで、コントローラーループを無効にできます。
+cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。
+KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。

-cloud-controller-managerを使用すると、クラウドベンダーのコードとKubernetesコードを互いに独立して進化させることができます。以前のリリースでは、コアKubernetesコードは、機能的にクラウドプロバイダー固有のコードに依存していました。将来のリリースでは、クラウドベンダーに固有のコードはクラウドベンダー自身で管理し、Kubernetesの実行中にcloud-controller-managerにリンクする必要があります。
+kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。

-次のコントローラーには、クラウドプロバイダーへの依存関係があります。
+次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。

  * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。
  * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。
  * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
-  * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。
-
 ## ノードコンポーネント {#node-components}

 ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。
@@ -3,6 +3,9 @@ reviewers:
 title: Kubernetes API
 content_type: concept
 weight: 30
+description: >
+  Kubernetes APIを使用すると、Kubernetes内のオブジェクトの状態をクエリで操作できます。
+  Kubernetesのコントロールプレーンの中核は、APIサーバーとそれが公開するHTTP APIです。ユーザー、クラスターのさまざまな部分、および外部コンポーネントはすべて、APIサーバーを介して互いに通信します。
 card:
  name: concepts
  weight: 30
@@ -10,64 +13,80 @@ card:

 <!-- overview -->

-全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。
-
-APIエンドポイント、リソースタイプ、そしてサンプルは[APIリファレンス](/docs/reference)に記載されています。
-
-APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。
-
-Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。
-
-また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。
-
-Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。
+Kubernetesの中核である {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。
+APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。

+Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。

+APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。

 <!-- body -->

 ## APIの変更

-我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。
+成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。
+したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。
+Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。

-何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。
+基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。
+リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。

-## OpenAPIとSwaggerの定義
+互換性のある変更の構成要素とAPIの変更方法については、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。

-完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)に記載されています。

-Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポイントを通じて、OpenAPI仕様を提供しています。
-リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます:
+## OpenAPI 仕様 {#api-specification}

-ヘッダ | 設定可能な値
------ | ---------------
-Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません)
-Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています)
+完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。

-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で削除されました。
+Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。
+次のように要求ヘッダーを使用して、応答フォーマットを要求できます。

-**OpenAPI仕様の取得サンプル**:

-1.10より前 | Kubernetes1.10以降
----------- | -----------------------------
-GET /swagger.json | GET /openapi/v2 **Accept**: application/json
-GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
-GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip
+<table>
+  <thead>
+     <tr>
+        <th>Header</th>
+        <th style="min-width: 50%;">Possible values</th>
+        <th>Notes</th>
+     </tr>
+  </thead>
+  <tbody>
+     <tr>
+        <td><code>Accept-Encoding</code></td>
+        <td><code>gzip</code></td>
+        <td><em>このヘッダーを使わないことも可能</em></td>
+     </tr>
+     <tr>
+        <td rowspan="3"><code>Accept</code></td>
+        <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td>
+        <td><em>主にクラスター内での使用</em></td>
+     </tr>
+     <tr>
+        <td><code>application/json</code></td>
+        <td><em>デフォルト</em></td>
+     </tr>
+     <tr>
+        <td><code>*</code></td>
+        <td><code>application/json</code>を提供</td>
+     </tr>
+  </tbody>
+  <caption>OpenAPI v2クエリの有効なリクエストヘッダー値</caption>
+</table>
+

 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で削除されました。
-
 ## APIバージョニング

-フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/extensions/v1beta1`のように、それぞれ異なるAPIのパスが割り当てられています。
+フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。

-APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンを付けることを選択しました。JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。
+APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。
+
+JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。

 APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。

-異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます:
+異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます:

 - アルファレベル(版):
  - バージョン名に`alpha`を含みます(例、`v1alpha1`)。
@@ -88,29 +107,37 @@ APIとソフトウエアのバージョニングは、間接的にしか関連

 ## APIグループ {#api-groups}

-KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
+APIの拡張を簡易に行えるようにするため、Kubernetesは[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
 APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。

-現在、いくつかのAPIグループが利用されています:
+クラスターにはいくつかのAPIグループがあります:

-1. *core* グループ(たびたび、*legacy group* と呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
+1. *core* グループ(*legacy group* とも呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。

-1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。
+1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。Kubernetesの[APIリファレンス](/docs/reference/kubernetes-api/)にすべての使用可能なAPIグループのリストがあります。

-[カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています:
+[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)でAPIを拡張するために、2つの方法があります:

-1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。
-1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。
+1. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。
+1. [独自の拡張APIサーバーを実装](/docs/tasks/extend-kubernetes/setup-extension-api-server/)し、[アグリゲーター](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)を使用してクライアントに対してシームレスにすることもできます。

 ## APIグループの有効化、無効化

-いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
+いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、kube-apiserverのコマンドラインオプションとしてAPIサーバーの`--runtime-config`設定で、有効化、無効化できます。

-{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}}
+`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。

-## APIグループextensions/v1beta1に含まれる特定のリソースの有効化
+{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、kube-apiserverとkube-controller-managerの再起動が必要です。{{< /note >}}

-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 >}}
+KubernetesはAPIリソースの観点からシリアル化された状態を{{< glossary_tooltip term_id="etcd" >}}に書き込むことで保存します。
+
+
+## {{% heading "whatsnext" %}}
+
+[APIアクセスの制御](/docs/reference/access-authn-authz/controlling-access/)は、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。
+
+全体的なAPI規則は、[API規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)の資料で説明されています。
+
+APIエンドポイント、リソースタイプ、サンプルについては、[APIリファレンス](/docs/reference/kubernetes-api/)をご覧ください。
@@ -57,7 +57,7 @@ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロッ
 Kubernetesは以下を提供します。

 * **サービスディスカバリーと負荷分散**  
-Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。
+Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。
 * **ストレージ オーケストレーション**  
 Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。
 * **自動化されたロールアウトとロールバック**  
@@ -71,11 +71,11 @@ Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密

 ## Kubernetesにないもの

-Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。
+Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散といったPaaSが提供するのと共通の機能をいくつか提供し、またユーザーはロギングやモニタリング及びアラートを行うソリューションを統合できます。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。

 Kubernetesは...

-* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
+* サポートするアプリケーションの種類を制限しません。Kubernetesは、ステートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
 * ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。
 * ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。
 * ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。
@@ -26,7 +26,7 @@ content_type: concept
 | キー                                 | 説明           | 例  | 型 |
 | ----------------------------------- | --------------------- | -------- | ---- |
 | `app.kubernetes.io/name`            | アプリケーション名 | `mysql` | 文字列 |
-| `app.kubernetes.io/instance`        | アプリケーションのインスタンスを特定するための固有名 | `wordpress-abcxzy` | 文字列 |
+| `app.kubernetes.io/instance`        | アプリケーションのインスタンスを特定するための固有名 | `mysql-abcxzy` | 文字列 |
 | `app.kubernetes.io/version`         | アプリケーションの現在のバージョン (例: セマンティックバージョン、リビジョンのハッシュなど) | `5.7.21` | 文字列 |
 | `app.kubernetes.io/component`       | アーキテクチャ内のコンポーネント | `database` | 文字列 |
 | `app.kubernetes.io/part-of`         | このアプリケーションによって構成される上位レベルのアプリケーション | `wordpress` | 文字列 |
@@ -40,7 +40,7 @@ kind: StatefulSet
 metadata:
  labels:
    app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
@@ -17,12 +17,7 @@ kubectl get pods --field-selector status.phase=Running
 ```

 {{< note >}}
-フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、下記の2つの`kubectl`クエリが同じであることを意味します。  
-
-```shell
-kubectl get pods
-kubectl get pods --field-selector ""
-```
+フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、`kubectl`クエリの`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。  
 {{< /note >}}

 ## サポートされているフィールド
@@ -28,7 +28,7 @@ Kubernetesオブジェクトを操作するには、作成、変更、または

 ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。

-`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
+`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesシステムとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。

 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。

@@ -73,7 +73,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場


 * [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。
-* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。
+* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。
 * Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。


@@ -81,7 +81,7 @@ spec:

 ## ラベルセレクター {#label-selectors}

-[名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。
+[名前とUID](/ja/docs/concepts/overview/working-with-objects/names/)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。

 *ラベルセレクター* を介して、クライアントとユーザーはオブジェクトのセットを指定できます。ラベルセレクターはKubernetesにおいてコアなグルーピング機能となります。

@@ -222,7 +222,7 @@ selector:

 #### *集合ベース* の要件指定をサポートするリソース

-[`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。  
+[`Job`](/docs/concepts/workloads/controllers/job/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。  
 ```yaml
 selector:
  matchLabels:
@@ -238,6 +238,6 @@ selector:

 #### Nodeのセットを選択する  
 ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。  
-さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。 
+さらなる情報に関しては、[Node選定](/ja/docs/concepts/scheduling-eviction/assign-pod-node/) のドキュメントを参照してください。 


@@ -33,6 +33,10 @@ Kubernetesの将来的なバージョンにおいて、同一のNamespace内の

 Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。

+{{< note >}}
+　　プレフィックス`kube-`を持つNamespaceは、KubernetesシステムのNamespaceとして予約されているため利用は避けてください。
+{{< /note >}}
+
 ### Namespaceの表示

 ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
@@ -41,18 +45,20 @@ Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメン
 kubectl get namespace
 ```
 ```
-NAME          STATUS    AGE
-default       Active    1d
-kube-system   Active    1d
-kube-public   Active    1d
+NAME              STATUS   AGE
+default           Active   1d
+kube-node-lease   Active   1d
+kube-system       Active   1d
+kube-public       Active   1d
 ```

-Kubernetesの起動時には3つの初期Namespaceが作成されています。
+Kubernetesの起動時には4つの初期Namespaceが作成されています。

   * `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace
   * `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace
   * `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。)
    このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。
+   * `kube-node-lease` クラスターのスケールに応じたノードハートビートのパフォーマンスを向上させる各ノードに関連したLeaseオブジェクトのためのNamespace。

 ### Namespaceの設定

@@ -79,7 +85,7 @@ kubectl config view --minify | grep namespace:

 ユーザーが[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に対して名前解決されます。
-これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
+これはデベロップメント、ステージング、プロダクションといった複数のNamespaceをまたいで同じ設定を使う時に効果的です。
 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。

 ## すべてのオブジェクトはNamespaceに属しているとは限らない
@@ -23,7 +23,7 @@ weight: 10
 - 管理者は各名前空間で1つの`ResourceQuota`を作成します。
 - ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。
+- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。

 `ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.

@@ -58,9 +58,9 @@ weight: 10

 ### 拡張リソースのためのリソースクォータ

-上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。
+上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。

-拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。
+拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`limits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。

 GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で、ユーザーが名前空間内でリクエストされるGPUの上限を4に指定するとき、下記のようにリソースクォータを定義します。

@@ -163,7 +163,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース

 ### PriorityClass毎のリソースクォータ

-{{< feature-state for_k8s_version="1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}

 Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。

@@ -451,7 +451,8 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset
 ```

 ```shell
-kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
+kubectl create deployment nginx --image=nginx --namespace=myspace
+kubectl scale deployment nginx --replicas=2 --namespace=myspace
 ```

 ```shell
@@ -549,5 +550,5 @@ plugins:

 ## {{% heading "whatsnext" %}}

-さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
+- さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。

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

 この例ではオペレーター`In`が使われています。
 Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
-`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
+`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)に使用します。

 `nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。

@@ -201,7 +201,7 @@ PodアフィニティとPodアンチアフィニティで使用できるオペ
 2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。
 3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。
-4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。
+4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができます。

 `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。
 省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。
@@ -361,7 +361,7 @@ spec:
 ## {{% heading "whatsnext" %}}


-[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
+[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。

 [Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
 [Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
@@ -98,7 +98,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン

 - `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なるPodが同じNode上で実行しないことを示唆できます。

- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/)にて確認できます。
+- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にて確認できます。

 - `TaintTolerationPriority`: Node上における許容できないTaintsの数に基づいて、全てのNodeの優先順位リストを準備します。このポリシーでは優先順位リストを考慮してNodeのランクを調整します。

@@ -106,7 +106,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン

 - `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。

- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
+- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。

 - `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。

@@ -6,7 +6,7 @@ weight: 40


 <!-- overview -->
-[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は
+[_Nodeアフィニティ_](/ja/docs/concepts/scheduling-eviction/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へ必ずスケジューリングされるとは限りません。
@@ -1,4 +1,12 @@
 ---
 title: "Service、負荷分散とネットワーキング"
 weight: 60
+description: >
+  Kubernetesにおけるネットワーキングの概念とリソース。
 ---
+
+Kubernetesのネットワーキングは4つの懸念事項に対処します。
+- Pod内のコンテナは、ネットワーキングを利用してループバック経由の通信を行います。
+- クラスターネットワーキングは、異なるPod間の通信を提供します。
+- Serviceリソースは、Pod内で動作しているアプリケーションへクラスターの外部から到達可能なように露出を許可します。
+- Serviceを利用して、クラスタ内部のみで使用するServiceの公開も可能です。
@@ -23,7 +23,6 @@ Kubernetesでは、どのホストで稼働するかに関わらず、Podが他
 このドキュメントの残りの部分では、このようなネットワークモデルで信頼できるサービスを実行する方法について詳しく説明します。

 このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。
-同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。



@@ -140,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク
 ## Serviceにアクセスする

 Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
-前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
+前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
 {{< note >}}
 サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
 {{< /note >}}
@@ -400,8 +399,8 @@ kubectl edit svc my-nginx
 kubectl get svc my-nginx
 ```
 ```
-NAME       TYPE        CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
-my-nginx   ClusterIP   10.0.162.149   162.222.184.144    80/TCP,81/TCP,82/TCP  21s
+NAME       TYPE           CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
+my-nginx   LoadBalancer   10.0.162.149     xx.xxx.xxx.xxx     8080:30163/TCP        21s
 ```
 ```
 curl https://<EXTERNAL-IP> -k
@@ -42,6 +42,20 @@ Headless Serviceに対しては、このSRVレコードは複数の結果を返

 ## Pod

+### A/AAAAレコード
+
+一般的にPodは下記のDNS解決となります。
+
+`pod-ip-address.my-namespace.pod.cluster-domain.example`
+
+例えば、`default`ネームスペースのpodのIPアドレスが172.17.0.3で、クラスターのドメイン名が`cluster.local`の場合、PodのDNS名は以下になります。
+
+`172-17-0-3.default.pod.cluster.local`
+
+DeploymentかDaemonSetに作成され、Serviceに公開されるどのPodも以下のDNS解決が利用できます。
+
+`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`
+
 ### Podのhostnameとsubdomainフィールド

 現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。
@@ -113,9 +127,9 @@ A(AAAA)レコードはPodの名前に対して作成されないため、`hostna
 DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。

 - "`Default`": そのPodはPodが稼働しているNodeから名前解決の設定を継承します。詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)を参照してください。
- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。
+- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。このような場合におけるDNSクエリー処理の詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)を参照してください。
 - "`ClusterFirstWithHostNet`": hostNetworkによって稼働しているPodに対しては、ユーザーは明示的にDNSポリシーを"`ClusterFirstWithHostNet`"とセットするべきです。
- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-s-dns-config)を参照ください。
+- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-dns-config)を参照ください。

 {{< note >}}
 "Default"は、デフォルトのDNSポリシーではありません。もし`dnsPolicy`が明示的に指定されていない場合、"ClusterFirst"が使用されます。
@@ -142,7 +156,7 @@ spec:
  dnsPolicy: ClusterFirstWithHostNet
 ```

-### PodのDNS設定 {#pods-dns-config}
+### PodのDNS設定 {#pod-dns-config}

 PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。

@@ -21,11 +21,11 @@ Ingressリソースが動作するためには、クラスターでIngressコン

 * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。
 * [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。
-* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](http://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
+* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
 * [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。
 * [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
 * Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。
-* F5 Networksは[F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
+* F5 Networksは[F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
 * [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。
 * [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。
 * [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。
@@ -37,7 +37,7 @@ Ingressリソースが動作するためには、クラスターでIngressコン

 ## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers}

-[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。
+[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。

 クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。

@@ -33,15 +33,15 @@ weight: 40
   [ Services ]
 ```

-IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
+IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。

 Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。

 ## Ingressを使用する上での前提条件

-Ingressを提供するためには[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。
+Ingressを提供するためには[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。

-[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の中から選択してください。
+[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の中から選択してください。

 理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすはずです。しかし実際には、各Ingressコントローラーは微妙に異なる動作をします。

@@ -65,14 +65,15 @@ spec:
  - http:
      paths:
      - path: /testpath
+        pathType: Prefix
        backend:
          serviceName: test
          servicePort: 80
 ```

-他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
+他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。

-Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。
+Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。

 ### Ingressのルール

@@ -86,10 +87,65 @@ Ingressコントローラーでは、デフォルトのバックエンドが設

 ### デフォルトのバックエンド

-ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
+ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。

 IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。

+### パスのタイプ
+
+Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。
+
+* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。
+
+* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。
+
+* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
+  
+  {{< note >}}
+  パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。
+  {{< /note >}}
+
+#### 複数のパスとの一致
+
+リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。
+
+## Ingress Class
+
+Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。
+IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: IngressClass
+metadata:
+  name: external-lb
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    apiGroup: k8s.example.com/v1alpha
+    kind: IngressParameters
+    name: external-lb
+```
+
+IngressClassリソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。
+
+### 非推奨のアノテーション
+
+Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールドが追加される前は、Ingressの種別はIngressの`kubernetes.io/ingress.class`アノテーションにより指定されていました。
+このアノテーションは正式に定義されたことはありませんが、Ingressコントローラーに広くサポートされています。
+
+Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。
+アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。
+
+### デフォルトのIngress Class
+
+特定のIngressClassをクラスターでのデフォルトとすることができます。
+IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。
+
+{{< caution >}}
+複数のIngressClassをクラスターのデフォルトに設定すると、アドミッションコントローラーは`ingressClassName`が指定されていないIngressオブジェクトの作成を防ぐようになります。クラスターのデフォルトのIngressClassを1つ以下にすることで、これを解消することができます。
+{{< /caution >}}
+
 ## Ingressのタイプ

 ### 単一ServiceのIngress
@@ -176,7 +232,7 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。

 {{< note >}}
-使用する[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
+使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
 {{< /note >}}

 ### 名前ベースのバーチャルホスティング
@@ -268,16 +324,16 @@ metadata:
 spec:
  tls:
  - hosts:
-    - sslexample.foo.com
+      - sslexample.foo.com
    secretName: testsecret-tls
  rules:
-    - host: sslexample.foo.com
-      http:
-        paths:
-        - path: /
-          backend:
-            serviceName: service1
-            servicePort: 80
+  - host: sslexample.foo.com
+    http:
+      paths:
+      - path: /
+        backend:
+          serviceName: service1
+          servicePort: 80
 ```

 {{< note >}}
@@ -288,7 +344,7 @@ spec:

 Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。

-Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
+Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。

 ## Ingressの更新

@@ -374,7 +430,7 @@ Events:

 ## アベイラビリティーゾーンをまたいだ障害について

-障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。
+障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。

 ## 将来追加予定の内容

@@ -390,6 +446,5 @@ Ingressリソースを直接含まない複数の方法でサービスを公開

 ## {{% heading "whatsnext" %}}
 * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
-* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ
+* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
 * [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
-
@@ -143,6 +143,14 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊

 エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。

+### アプリケーションプロトコル
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。
+
+アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。
+
 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}

 Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
@@ -272,7 +280,7 @@ Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主

 PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。
 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
-[makeLinkVariables関数](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
+[makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。

 例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。

@@ -373,6 +381,26 @@ NodePortの使用は、Kubernetesによって完全にサポートされてい
 注意点として、このServiceは`<NodeIP>:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。
 (もしkube-proxyにおいて`--nodeport-addressses`が設定された場合、<NodeIP>はフィルターされたNodeIPとなります。)

+例えば:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  type: NodePort
+  selector:
+    app: MyApp
+  ports:
+      # デフォルトでは利便性のため、 `targetPort` は `port` と同じ値にセットされます。
+    - port: 80
+      targetPort: 80
+      # 省略可能なフィールド
+      # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲:30000-32767)
+      nodePort: 30007
+```
+
 ### LoadBalancer タイプ {#loadbalancer}

 外部のロードバランサーをサポートするクラウドプロバイダー上で、`type`フィールドに`LoadBalancer`を設定すると、Service用にロードバランサーがプロビジョニングされます。
@@ -461,6 +489,17 @@ metadata:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+{{% /tab %}}
+{{% tab name="IBM Cloud" %}}
+```yaml
+[...]
+metadata:
+    name: my-service
+    annotations:
+        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
+[...]
+```
+
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
 ```yaml
@@ -532,7 +571,7 @@ TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBは

 上記の例では、もしServiceが`80`、`443`、`8443`と3つのポートを含んでいる場合、`443`と`8443`はSSL証明書を使いますが、`80`では単純にHTTPでのプロキシーとなります。

-Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。
+Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。
 どのポリシーが使用できるかを確認するために、`aws`コマンドラインツールを使用できます。

 ```bash
@@ -654,7 +693,7 @@ AWSでNetwork Load Balancerを使用するには、値を`nlb`に設定してア
 ```

 {{< note >}}
-NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。
+NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。
 {{< /note >}}

 古いタイプのElastic Load Balancersとは異なり、Network Load Balancers (NLBs)はクライアントのIPアドレスをNodeに転送します。
@@ -663,7 +702,7 @@ NLBは特定のインスタンスクラスでのみ稼働します。サポー
 `.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。
 特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。

-均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を設定します。
+均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。

 また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。

@@ -673,7 +712,7 @@ NLBの背後にあるインスタンスに対してクライアントのトラ
 |------|----------|---------|------------|---------------------|
 | ヘルスチェック | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
 | クライアントのトラフィック | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
-| MTCによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
+| MTUによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |

 どのクライアントIPがNLBにアクセス可能かを制限するためには、`loadBalancerSourceRanges`を指定してください。

@@ -689,7 +728,7 @@ spec:

 {{< /note >}}

-#### Tencent Kubernetes Engine（TKE）におけるその他のCLBアノテーション
+#### Tencent Kubernetes Engine(TKE)におけるその他のCLBアノテーション

 以下に示すように、TKEでCloud Load Balancerを管理するためのその他のアノテーションがあります。

@@ -700,7 +739,7 @@ spec:
        # 指定したノードでロードバランサーをバインドします
        service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)
        # 既存のロードバランサーのID
-        service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx
+        service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx

        # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません
        service.kubernetes.io/service.extensiveParameters: ""
@@ -714,7 +753,7 @@ spec:
        # パブリックネットワーク帯域幅の課金方法を指定します
        # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth)
        service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx
-        # 帯域幅の値を指定します(値の範囲：[1-2000] Mbps)。
+        # 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。
        service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"
        # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
        # そうでない場合、すべてのノードが登録されます
@@ -785,10 +824,10 @@ spec:
  - 80.11.12.10
 ```

-## Serviceのデメリット
+## Serviceの欠点

 仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。
-これについては、[Serviceのデザインプロポーザル](http://issue.k8s.io/1107)にてさらなる詳細を確認できます。
+これについては、[Serviceのデザインプロポーザル](https://github.com/kubernetes/kubernetes/issues/1107)にてさらなる詳細を確認できます。

 userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。
 これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。
@@ -812,8 +851,8 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ
 各Serviceが固有のIPを割り当てられるのを保証するために、内部のアロケーターは、Serviceを作成する前に、etcd内のグローバルの割り当てマップをアトミックに更新します。
 そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。

-コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesのマイグレーションも必要です)。
-また、Kubernetesは無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。
+コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesからのマイグレーションをサポートすることも必要です)。
+また、Kubernetesは(例えば、管理者の介入によって)無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。

 ### ServiceのIPアドレス {#ips-and-vips}

@@ -894,9 +933,9 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

-Kubernetesは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-gates=SCTPSupport=true,…`といったように設定します。

-そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
+そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。

 #### 警告 {#caveat-sctp-overview}
@@ -936,5 +975,3 @@ kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理
 * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
 * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
-
-
@@ -11,7 +11,7 @@ weight: 20

 <!-- overview -->

-このドキュメントではKubernetesの`PersistentVolume`について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
+このドキュメントではKubernetesの _PersistentVolume_ について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。



@@ -20,13 +20,13 @@ weight: 20

 ## 概要

-ストレージを管理することはインスタンスを管理することとは全くの別物です。`PersistentVolume`サブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するための`PersistentVolume`と`PersistentVolumeClaim`という2つの新しいAPIリソースを紹介します。
+ストレージを管理することはインスタンスを管理することとは全くの別物です。PersistentVolumeサブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するためのPersistentVolumeとPersistentVolumeClaimという2つの新しいAPIリソースを紹介します。

-`PersistentVolume`(PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。
+_PersistentVolume_ (PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。

-`PersistentVolumeClaim`(PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、1ノードからのみ読み書きマウントができるモードや、複数ノードから読み込み専用マウントができるモードなどです)を要求することができます。
+_PersistentVolumeClaim_ (PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、ReadWriteOnce、ReadOnlyMany、ReadWriteManyにマウントできます。詳しくは[アクセスモード](#access-modes)を参照してください)を要求することができます。

-`PersistentVolumeClaim`はユーザーに抽象化されたストレージリソースの消費を許可する一方、ユーザーは色々な問題に対処するためにパフォーマンスといった様々なプロパティを持った`PersistentVolume`を必要とすることは一般的なことです。クラスター管理者はユーザーに様々なボリュームがどのように実装されているかを表に出すことなく、サイズやアクセスモードだけではない色々な点で異なった、様々な`PersistentVolume`を提供できる必要があります。これらのニーズに応えるために`StorageClass`リソースがあります。
+PersistentVolumeClaimはユーザーに抽象化されたストレージリソースの消費を許可する一方、ユーザーは色々な問題に対処するためにパフォーマンスといった様々なプロパティを持ったPersistentVolumeを必要とすることは一般的なことです。クラスター管理者はユーザーに様々なボリュームがどのように実装されているかを表に出すことなく、サイズやアクセスモードだけではない色々な点で異なった、様々なPersistentVolumeを提供できる必要があります。これらのニーズに応えるために _StorageClass_ リソースがあります。

 [実例を含む詳細なチュートリアル](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)を参照して下さい。

@@ -45,8 +45,8 @@ PVは静的か動的どちらかでプロビジョニングされます。

 #### 動的

-ユーザーの`PersistentVolumeClaim`が管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。
-このプロビジョニングは`StorageClass`に基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。
+ユーザーのPersistentVolumeClaimが管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。
+このプロビジョニングはStorageClassに基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。

 ストレージクラスに基づいたストレージの動的プロビジョニングを有効化するには、クラスター管理者が`DefaultStorageClass`[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)をAPIサーバーで有効化する必要があります。
 これは例えば、`DefaultStorageClass`がAPIサーバーコンポーネントの`--enable-admission-plugins`フラグのコンマ区切りの順序付きリストの中に含まれているかで確認できます。
@@ -114,19 +114,19 @@ Events:            <none>

 ### 再クレーム

-ユーザーは、ボリュームの使用が完了したら、リソースの再クレームを許可するAPIからPVCオブジェクトを削除できます。`PersistentVolume`の再クレームポリシーはそのクレームが解放された後のボリュームの処理をクラスターに指示します。現在、ボリュームは保持、リサイクル、または削除できます。
+ユーザーは、ボリュームの使用が完了したら、リソースの再クレームを許可するAPIからPVCオブジェクトを削除できます。PersistentVolumeの再クレームポリシーはそのクレームが解放された後のボリュームの処理をクラスターに指示します。現在、ボリュームは保持、リサイクル、または削除できます。

 #### 保持

-`Retain`という再クレームポリシーはリソースを手動で再クレームすることができます。`PersistentVolumeClaim`が削除される時、`PersistentVolume`は依然として存在はしますが、ボリュームは解放済みです。ただし、以前のクレームデータはボリューム上に残っているため、別のクレームにはまだ使用できません。管理者は次の手順でボリュームを手動で再クレームできます。
+`Retain`という再クレームポリシーはリソースを手動で再クレームすることができます。PersistentVolumeClaimが削除される時、PersistentVolumeは依然として存在はしますが、ボリュームは解放済みです。ただし、以前のクレームデータはボリューム上に残っているため、別のクレームにはまだ使用できません。管理者は次の手順でボリュームを手動で再クレームできます。

-1. `PersistentVolume`を削除します。PVが削除された後も、外部インフラストラクチャー(AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど)に関連付けられたストレージアセットは依然として残ります。
+1. PersistentVolumeを削除します。PVが削除された後も、外部インフラストラクチャー(AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど)に関連付けられたストレージアセットは依然として残ります。
 1. ストレージアセットに関連するのデータを手動で適切にクリーンアップします。
-1. 関連するストレージアセットを手動で削除するか、同じストレージアセットを再利用したい場合、新しいストレージアセット定義と共に`PersistentVolume`を作成します。
+1. 関連するストレージアセットを手動で削除するか、同じストレージアセットを再利用したい場合、新しいストレージアセット定義と共にPersistentVolumeを作成します。

 #### 削除

-`Delete`再クレームポリシーをサポートするボリュームプラグインの場合、削除すると`PersistentVolume`オブジェクトがKubernetesから削除されるだけでなく、AWS EBS、GCE PD、Azure Disk、Cinderボリュームなどの外部インフラストラクチャーの関連ストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、[`StorageClass`の再クレームポリシー](#reclaim-policy)を継承します。これはデフォルトで削除です。管理者は、ユーザーの需要に応じて`StorageClass`を構成する必要があります。そうでない場合、PVは作成後に編集またはパッチを適用する必要があります。[PersistentVolumeの再クレームポリシーの変更](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)を参照してください。
+`Delete`再クレームポリシーをサポートするボリュームプラグインの場合、削除するとPersistentVolumeオブジェクトがKubernetesから削除されるだけでなく、AWS EBS、GCE PD、Azure Disk、Cinderボリュームなどの外部インフラストラクチャーの関連ストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、[StorageClassの再クレームポリシー](#reclaim-policy)を継承します。これはデフォルトで削除です。管理者は、ユーザーの需要に応じてStorageClassを構成する必要があります。そうでない場合、PVは作成後に編集またはパッチを適用する必要があります。[PersistentVolumeの再クレームポリシーの変更](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)を参照してください。

 #### リサイクル

@@ -136,7 +136,9 @@ Events:            <none>

 基盤となるボリュームプラグインでサポートされている場合、`Recycle`再クレームポリシーはボリュームに対して基本的な削除(`rm -rf /thevolume/*`)を実行し、新しいクレームに対して再び利用できるようにします。

-管理者は[こちら](/docs/admin/kube-controller-manager/)で説明するように、Kubernetesコントローラーマネージャーのコマンドライン引数を使用して、カスタムリサイクラーPodテンプレートを構成できます。カスタムリサイクラーPodテンプレートには、次の例に示すように、`volumes`仕様が含まれている必要があります。
+管理者は[reference](/docs/reference/command-line-tools-reference/kube-controller-manager/)で説明するように、Kubernetesコントローラーマネージャーのコマンドライン引数を使用して、カスタムリサイクラーPodテンプレートを構成できます。カスタムリサイクラーPodテンプレートには、次の例に示すように、`volumes`仕様が含まれている必要があります。
+
+

 ```yaml
 apiVersion: v1
@@ -194,7 +196,7 @@ parameters:
 allowVolumeExpansion: true
 ```

-PVCに対してさらに大きなボリュームを要求するには、PVCオブジェクトを編集してより大きなサイズを指定します。これにより`PersistentVolume`を受け持つ基盤にボリュームの拡大がトリガーされます。クレームを満たすため新しく`PersistentVolume`が作成されることはありません。代わりに既存のボリュームがリサイズされます。
+PVCに対してさらに大きなボリュームを要求するには、PVCオブジェクトを編集してより大きなサイズを指定します。これによりPersistentVolumeを受け持つ基盤にボリュームの拡大がトリガーされます。クレームを満たすため新しくPersistentVolumeが作成されることはありません。代わりに既存のボリュームがリサイズされます。

 #### CSIボリュームの拡張

@@ -231,10 +233,19 @@ FlexVolumeのリサイズは、基盤となるドライバーがリサイズを
 EBSの拡張は時間がかかる操作です。また変更は、ボリュームごとに6時間に1回までというクォータもあります。
 {{< /note >}}

+#### ボリューム拡張時の障害からの復旧
+
+基盤ストレージの拡張に失敗した際には、クラスターの管理者はPersistent Volume Claim (PVC)の状態を手動で復旧し、リサイズ要求をキャンセルします。それをしない限り、リサイズ要求は管理者の介入なしにコントローラーによって継続的に再試行されます。  
+
+1. PersistentVolumeClaim(PVC)にバインドされているPersistentVolume(PV)を`Retain`再クレームポリシーとしてマークします。
+2. PVCを削除します。PVは`Retain`再クレームポリシーを持っているため、PVCを再び作成したときにいかなるデータも失うことはありません。  
+3. `claimRef`エントリーをPVスペックから削除して、新しいPVCがそれにバインドできるようにします。これによりPVは`Available`になります。  
+4. PVより小さいサイズでPVCを再作成し、PVCの`volumeName`フィールドをPVの名前に設定します。これにより新しいPVCを既存のPVにバインドします。  
+5. PVを再クレームポリシーを復旧することを忘れずに行ってください。  

 ## 永続ボリュームの種類

-`PersistentVolume`の種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
+PersistentVolumeの種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。

 * GCEPersistentDisk
 * AWSElasticBlockStore
@@ -297,13 +308,22 @@ spec:

 ### ボリュームモード

-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}

-Kubernetes 1.9より前は、すべてのボリュームプラグインが永続ボリュームにファイルシステムを作成していました。現在はRawブロックデバイスを使うために`volumeMode`の値を`block`に設定するか、ファイルシステムを使うために`filesystem`を設定できます。値が省略された場合のデフォルトは`filesystem`です。これはオプションのAPIパラメーターです。
+KubernetesはPersistentVolumesの2つの`volumeModes`をサポートしています: `Filesystem`と`Block`です。  
+`volumeMode`は任意のAPIパラメーターです。  
+`Filesystem`は`volumeMode`パラメーターが省略されたときに使用されるデフォルトのモードです。  
+
+`volumeMode: Filesystem`であるボリュームはPodに*マウント*されてディレクトリになります。 ボリュームがブロックデバイスでデバイスが空の時、Kubernetesは初めてそれにマウントされる前にデバイスのファイルシステムを作成します。  
+
+`volumeMode`の値を`Block`に設定してボリュームをRAWブロックデバイスとして使用します。  
+このようなボリュームは、ファイルシステムを持たないブロックデバイスとしてPodに提示されます。  
+このモードは、Podとボリュームの間のファイルシステムレイヤなしにボリュームにアクセスする可能な限り最速の方法をPodに提供するのに便利です。一方で、Pod上で実行しているアプリケーションはRAWブロックデバイスの扱い方を知っていなければなりません。  
+Pod内で`volumeMode: Block`とともにボリュームを使用する例としては、[Raw Block Volume Support](#raw-block-volume-support)を参照してください。

 ### アクセスモード

-`PersistentVolume`は、リソースプロバイダーがサポートする方法でホストにマウントできます。次の表に示すように、プロバイダーにはさまざまな機能があり、各PVのアクセスモードは、その特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFSは複数の読み取り/書き込みクライアントをサポートできますが、特定のNFSのPVはサーバー上で読み取り専用としてエクスポートされる場合があります。各PVは、その特定のPVの機能を記述する独自のアクセスモードのセットを取得します。
+PersistentVolumeは、リソースプロバイダーがサポートする方法でホストにマウントできます。次の表に示すように、プロバイダーにはさまざまな機能があり、各PVのアクセスモードは、その特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFSは複数の読み取り/書き込みクライアントをサポートできますが、特定のNFSのPVはサーバー上で読み取り専用としてエクスポートされる場合があります。各PVは、その特定のPVの機能を記述する独自のアクセスモードのセットを取得します。

 アクセスモードは次の通りです。

@@ -476,7 +496,7 @@ PVCが`selector`を要求することに加えて`StorageClass`を指定する

 ## ボリュームとしてのクレーム

-Podは、クレームをボリュームとして使用してストレージにアクセスします。クレームは、そのクレームを使用するPodと同じ名前空間に存在する必要があります。クラスターは、Podの名前空間でクレームを見つけ、それを使用してクレームを支援している`PersistentVolume`を取得します。次に、ボリュームがホストとPodにマウントされます。
+Podは、クレームをボリュームとして使用してストレージにアクセスします。クレームは、そのクレームを使用するPodと同じ名前空間に存在する必要があります。クラスターは、Podの名前空間でクレームを見つけ、それを使用してクレームを支援しているPersistentVolumeを取得します。次に、ボリュームがホストとPodにマウントされます。

 ```yaml
 apiVersion: v1
@@ -498,29 +518,26 @@ spec:

 ### 名前空間に関する注意

-`PersistentVolume`バインドは排他的であり、`PersistentVolumeClaim`は名前空間オブジェクトであるため、"多"モード(`ROX`、`RWX`)でクレームをマウントすることは1つの名前空間内でのみ可能です。
+PersistentVolumeバインドは排他的であり、PersistentVolumeClaimは名前空間オブジェクトであるため、"多"モード(`ROX`、`RWX`)でクレームをマウントすることは1つの名前空間内でのみ可能です。

 ## Rawブロックボリュームのサポート

-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}

 次のボリュームプラグインは、必要に応じて動的プロビジョニングを含むrawブロックボリュームをサポートします。

 * AWSElasticBlockStore
 * AzureDisk
+* CSI
 * FC (Fibre Channel)
 * GCEPersistentDisk
 * iSCSI
 * Local volume
+* OpenStack Cinder
 * RBD (Ceph Block Device)
-* VsphereVolume (alpha)
+* VsphereVolume 

-{{< note >}}
-Kubernetes 1.9では、FCおよびiSCSIボリュームのみがrawブロックボリュームをサポートしていました。
-追加のプラグインのサポートは1.10で追加されました。
-{{< /note >}}
-
-### Rawブロックボリュームを使用した永続ボリューム
+### Rawブロックボリュームを使用した永続ボリューム {#persistent-volume-using-a-raw-block-volume}

 ```yaml
 apiVersion: v1
@@ -584,7 +601,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス

 ### ブロックボリュームのバインド

-ユーザーが`PersistentVolumeClaim`specの`volumeMode`フィールドを使用してrawブロックボリュームの要求を示す場合、バインディングルールは、このモードをspecの一部として考慮しなかった以前のリリースとわずかに異なります。表にリストされているのは、ユーザーと管理者がrawブロックデバイスを要求するために指定可能な組み合わせの表です。この表は、ボリュームがバインドされるか、組み合わせが与えられないかを示します。静的にプロビジョニングされたボリュームのボリュームバインディングマトリクスはこちらです。
+ユーザーがPersistentVolumeClaim specの`volumeMode`フィールドを使用してrawブロックボリュームの要求を示す場合、バインディングルールは、このモードをspecの一部として考慮しなかった以前のリリースとわずかに異なります。表にリストされているのは、ユーザーと管理者がrawブロックデバイスを要求するために指定可能な組み合わせの表です。この表は、ボリュームがバインドされるか、組み合わせが与えられないかを示します。静的にプロビジョニングされたボリュームのボリュームバインディングマトリクスはこちらです。

 | PVボリュームモード | PVCボリュームモード | 結果         |
 | -------------------|:-------------------:| ------------:|
@@ -610,7 +627,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス

 ボリュームスナップショットのデータソースからボリュームを復元する機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。

-### ボリュームスナップショットから永続ボリュームクレームを作成する
+### ボリュームスナップショットから永続ボリュームクレームを作成する {#create-persistent-volume-claim-from-volume-snapshot}

 ```yaml
 apiVersion: v1
@@ -632,13 +649,11 @@ spec:

 ## ボリュームの複製

-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-
-ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
+[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)はCSIボリュームプラグインにのみ利用可能です。

 PVCデータソースからのボリューム複製機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。

-### 既存のPVCからの永続ボリュームクレーム作成
+### 既存のPVCからの永続ボリュームクレーム作成 {#create-persistent-volume-claim-from-an-existing-pvc} 

 ```yaml
 apiVersion: v1
@@ -664,7 +679,7 @@ spec:
 - 構成にPersistentVolumeClaimオブジェクトを含める(DeploymentやConfigMapと共に)
 - ユーザーが設定をインスタンス化する際にPersistentVolumeを作成する権限がない場合があるため、設定にPersistentVolumeオブジェクトを含めない。
 - テンプレートをインスタンス化する時にストレージクラス名を指定する選択肢をユーザーに与える
-  - ユーザーがストレージクラス名を指定する場合、`persistentVolumeClaim.storageClassName`フィールドにその値を入力する。これにより、クラスターが管理者によって有効にされたストレージクラスを持っている場合、PVCは正しいストレージクラスと一致する。
+  - ユーザーがストレージクラス名を指定する場合、persistentVolumeClaim.storageClassName フィールドにその値を入力する。これにより、クラスターが管理者によって有効にされたストレージクラスを持っている場合、PVCは正しいストレージクラスと一致する。
  - ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
 - ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。

@@ -6,7 +6,6 @@ weight: 30

 <!-- overview -->

-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
 このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。


@@ -31,6 +30,7 @@ weight: 30
 * 複製は同じストレージクラス内でのみサポートされます。
    - 宛先ボリュームは、ソースと同じストレージクラスである必要があります。
    - デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。
+* 複製は同じVolumeMode設定を使用する2つのボリューム間でのみ実行できます(ブロックモードのボリュームを要求する場合、ソースもブロックモードである必要があります)。


 ## プロビジョニング
@@ -8,7 +8,7 @@ weight: 80

 {{< feature-state for_k8s_version="v1.8" state="beta" >}}

-_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。
+_CronJob_ は繰り返しのスケジュールによって{{< glossary_tooltip term_id="job" text="Job" >}}を作成します。

 _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。
 [Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。
@@ -22,13 +22,25 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら
 CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。
 名前は52文字を超えることはできません。これはCronJobコントローラーが自動的に、与えられたジョブ名に11文字を追加し、ジョブ名の長さは最大で63文字以内という制約があるためです。

-cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。



 <!-- body -->

-## CronJobの制限
+## CronJob
+
+CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。
+CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするなど、特定の時間に個々のタスクをスケジュールすることもできます。
+
+### 例
+
+このCronJobマニフェスト例は、毎分ごとに現在の時刻とhelloメッセージを表示します。
+
+{{< codenew file="application/job/cronjob.yaml" >}}
+
+([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).
+
+## CronJobの制限 {#cron-job-limitations}

 cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1つのジョブオブジェクトを作成します。ここで _おおよそ_ と言っているのは、ある状況下では2つのジョブが作成される、もしくは1つも作成されない場合があるためです。通常、このようなことが起こらないようになっていますが、完全に防ぐことはできません。したがって、ジョブは _冪等_ であるべきです。

@@ -50,4 +62,8 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).

 CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。

+## {{% heading "whatsnext" %}}

+[Cron表現形式](https://en.wikipedia.org/wiki/Cron)では、CronJobの`schedule`フィールドのフォーマットを説明しています。
+
+cronジョブの作成や動作の説明、CronJobマニフェストの例については、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)を見てください。
@@ -2,7 +2,7 @@
 reviewers:
 title: DaemonSet
 content_type: concept
-weight: 50
+weight: 40
 ---

 <!-- overview -->
@@ -11,12 +11,11 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー

 DaemonSetのいくつかの典型的な使用例は以下の通りです。

- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。
- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。
- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)や[Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)などのようなNodeのモニタリングデーモンを各Node上で稼働させる。
+- クラスターのストレージデーモンを全てのNode上で稼働させる。
+- ログ集計デーモンを全てのNode上で稼働させる。
+- Nodeのモニタリングデーモンを全てのNode上で稼働させる。

-シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
-さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
+シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。



@@ -27,8 +26,7 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。

 ### DaemonSetの作成

-ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。  
-例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。
+ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。

 {{< codenew file="controllers/daemonset.yaml" >}}

@@ -40,8 +38,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 ### 必須のフィールド

-他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。  
-設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。
+他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。

 DaemonSetオブジェクトの名前は、有効な
 [DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
@@ -52,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な

 `.spec.template`は`.spec`内での必須のフィールドの1つです。

-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、[Pod](/ja/docs/concepts/workloads/pods/pod/)のテンプレートと同じスキーマとなります。
+`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。

 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。

@@ -60,7 +57,7 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts

 ### Podセレクター

-`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)の`.spec.selector`と同じものです。
+`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。

 Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。

@@ -75,11 +72,10 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ

 また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{<glossary_tooltip term_id = "controller">}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。

-### 特定のいくつかのNode上のみにPodを稼働させる
+### 選択したNode上でPodを稼働させる

 もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node
-selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。  
-同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/configuration/assign-pod-node/)マッチするPodをNode上に作成します。
+selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするPodをNode上に作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)マッチするPodをNode上に作成します。
 もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。

 ## Daemon Podがどのようにスケジューリングされるか
@@ -94,7 +90,7 @@ DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働さ
 * 矛盾するPodのふるまい: スケジューリングされるのを待っている通常のPodは、作成されているが`Pending`状態となりますが、DaemonSetのPodは`Pending`状態で作成されません。これはユーザーにとって困惑するものです。
 * [Podプリエンプション(Pod preemption)](/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。

-`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。
+`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます(ターゲットホストを選択する前に、元のNodeAffinityが考慮されます)。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。

 ```yaml
 nodeAffinity:
@@ -111,17 +107,16 @@ nodeAffinity:

 ### TaintsとTolerations

-DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。  
-下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
+DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。

-| Toleration Key                           | Effect     | Version | Description                                                  |
-| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
-| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+    | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
-| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+    | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
-| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    |                                                              |
-| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    |                                                              |
-| `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。                                                |
-| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。  
+| Toleration Key                           | Effect     | Version | Description |
+| ---------------------------------------- | ---------- | ------- | ----------- |
+| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
+| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
+| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | |
+| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | |
+| `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 |
+| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 |

 ## Daemon Podとのコミュニケーション

@@ -158,8 +153,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`

 ### 静的Pod Pods

-Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/concepts/cluster-administration/static-pod/)と呼ばれます。  
-DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
+Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。

 ### Deployment

@@ -168,4 +162,3 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ
 フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
 Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。

-
@@ -6,14 +6,14 @@ feature:
    Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。

 content_type: concept
-weight: 30
+weight: 10
 ---

 <!-- overview -->

-_Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
+_Deployment_ は{{< glossary_tooltip text="Pod" term_id="pod" >}}と{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}の宣言的なアップデート機能を提供します。

-Deploymentにおいて_理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。
+Deploymentにおいて _理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。

 {{< note >}}
 Deploymentによって作成されたReplicaSetを管理しないでください。ご自身のユースケースが以下の項目に含まれない場合、メインのKubernetesリポジトリーにIssueを作成することを検討してください。
@@ -31,8 +31,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 * ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。
 * DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
 * Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
-* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する
+* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する。
 * PodTemplateSpecに対する複数の修正を適用するために[Deploymentを停止(Pause)し](#pausing-and-resuming-a-deployment)、それを再開して新しいロールアウトを開始します。
+* [Deploymentのステータス](#deployment-status) をロールアウトが失敗したサインとして利用する。
 * 今後必要としない[古いReplicaSetのクリーンアップ](#clean-up-policy)

 ## Deploymentの作成 {#creating-a-deployment}
@@ -44,21 +45,22 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 この例では、

 * `.metadata.name`フィールドで指定された`nginx-deployment`という名前のDeploymentが作成されます。
-* このDeploymentは`replicas`フィールドで指定された通り、3つのレプリカPodを作成します。
-* `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。ここでは、Podテンプレートにて定義されたラベル(`app: nginx`)を選択しています。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
+* このDeploymentは`.spec.replicas`フィールドで指定された通り、3つのレプリカPodを作成します。
+* `.spec.selector`フィールドは、Deploymentが管理するPodのラベルを定義します。ここでは、Podテンプレートにて定義されたラベル(`app: nginx`)を選択しています。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。

    {{< note >}}
-    `matchLabels`フィールドはキーバリューペアのマップです。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しくなります。
+    `.spec.selector.matchLabels`フィールドはキーバリューペアのマップです。
+    `matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しくなります。
    `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
    {{< /note >}}

 * `template`フィールドは、以下のサブフィールドを持ちます。:
-  * Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられます。
+  * Podは`.metadata.labels`フィールドによって指定された`app: nginx`というラベルがつけられます。
  * PodTemplate、または`.template.spec`フィールドは、Podが`nginx`という名前で[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.14.2が動くコンテナを1つ動かすことを示します。
-  * 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます。
+  * 1つのコンテナを作成し、`.spec.template.spec.containers[0].name`フィールドを使って`nginx`という名前をつけます。

-上記のDeploymentを作成するためには以下のステップにしたがってください。
 作成を始める前に、Kubernetesクラスターが稼働していることを確認してください。
+上記のDeploymentを作成するためには以下のステップにしたがってください:

 1. 以下のコマンドを実行してDeploymentを作成してください。

@@ -67,11 +69,12 @@ Deploymentによって作成されたReplicaSetを管理しないでください
  ```

  {{< note >}}
-  実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
+  実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。
+  これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
  {{< /note >}}


-2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。
+2. Deploymentが作成されたことを確認するために、`kubectl get deployments`を実行してください。

  Deploymentがまだ作成中の場合、コマンドの実行結果は以下のとおりです。
  ```shell
@@ -80,7 +83,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
  ```
  クラスターにてDeploymentを調査するとき、以下のフィールドが出力されます。
  * `NAME`は、クラスター内にあるDeploymentの名前一覧です。
-  * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。
+  * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。使用可能な数/理想的な数の形式で表示されます。
  * `UP-TO-DATE`は、理想的な状態を満たすためにアップデートが完了したレプリカの数です。
  * `AVAILABLE`は、ユーザーが利用可能なレプリカの数です。
  * `AGE`は、アプリケーションが稼働してからの時間です。
@@ -95,14 +98,15 @@ Deploymentによって作成されたReplicaSetを管理しないでください
  deployment.apps/nginx-deployment successfully rolled out
  ```

-4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は以下のとおりです。
+4. 数秒後、再度`kubectl get deployments`を実行してください。
+  コマンドの実行結果は以下のとおりです。
  ```shell
  NAME               READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-deployment   3/3     3            3           18s
  ```
  Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。

-5. Deploymentによって作成されたReplicaSet(`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は以下のとおりです。
+5. Deploymentによって作成されたReplicaSet(`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は以下のとおりです:
  ```shell
  NAME                          DESIRED   CURRENT   READY   AGE
  nginx-deployment-75675f5897   3         3         3       18s
@@ -110,15 +114,15 @@ Deploymentによって作成されたReplicaSetを管理しないでください
  ReplicaSetの出力には次のフィールドが表示されます:

  * `NAME`は、名前空間内にあるReplicaSetの名前の一覧です。
-  * `DESIRED`は、アプリケーションの理想的な_レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
+  * `DESIRED`は、アプリケーションの理想的な _レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが _理想的な状態_ と呼ばれるものです。
  * `CURRENT`は現在実行されているレプリカの数です。
  * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。
  * `AGE`は、アプリケーションが稼働してからの時間です。

  ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。

-
-6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は以下のとおりです。
+6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。
+  コマンドの実行結果は以下のとおりです:
  ```shell
  NAME                                READY     STATUS    RESTARTS   AGE       LABELS
  nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
@@ -128,7 +132,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
  作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。

 {{< note >}}
-Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
+Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。
+
+ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを阻止しないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
 {{< /note >}}

 ### pod-template-hashラベル
@@ -141,7 +147,7 @@ Deploymentに対して適切なセレクターとPodテンプレートのラベ

 このラベルはDeploymentが管理するReplicaSetが重複しないことを保証します。このラベルはReplicaSetの`PodTemplate`をハッシュ化することにより生成され、生成されたハッシュ値はラベル値としてReplicaSetセレクター、Podテンプレートラベル、ReplicaSetが作成した全てのPodに対して追加されます。

-## Deploymentの更新
+## Deploymentの更新 {#updating-a-deployment}

 {{< note >}}
 Deploymentのロールアウトは、DeploymentのPodテンプレート(この場合`.spec.template`)が変更された場合にのみトリガーされます。例えばテンプレートのラベルもしくはコンテナーイメージが更新された場合です。Deploymentのスケールのような更新では、ロールアウトはトリガーされません。
@@ -468,7 +474,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー

    実行結果は以下のとおりです。
    ```
-    deployment.apps/nginx-deployment
+    deployment.apps/nginx-deployment rolled back
    ```
    その他に、`--to-revision`を指定することにより特定のリビジョンにロールバックできます。

@@ -478,7 +484,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー

    実行結果は以下のとおりです。
    ```
-    deployment.apps/nginx-deployment
+    deployment.apps/nginx-deployment rolled back
    ```

    ロールアウトに関連したコマンドのさらなる情報は[`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)を参照してください。
@@ -584,13 +590,11 @@ Deploymentのローリングアップデートは、同時に複数のバージ
  ```

 * クラスター内で、解決できない新しいイメージに更新します。
-* You update to a new image which happens to be unresolvable from inside the cluster.
    ```shell
    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
    ```

    実行結果は以下のとおりです。
-    The output is similar to this:
    ```
    deployment.apps/nginx-deployment image updated
    ```
@@ -599,7 +603,8 @@ Deploymentのローリングアップデートは、同時に複数のバージ
    ```shell
    kubectl get rs
    ```
-      実行結果は以下のとおりです。
+
+    実行結果は以下のとおりです。
    ```
    NAME                          DESIRED   CURRENT   READY     AGE
    nginx-deployment-1989198191   5         5         0         9s
@@ -610,24 +615,26 @@ Deploymentのローリングアップデートは、同時に複数のバージ

 上記の例では、3つのレプリカが古いReplicaSetに追加され、2つのレプリカが新しいReplicaSetに追加されました。ロールアウトの処理では、新しいレプリカ数のPodが正常になったと仮定すると、最終的に新しいReplicaSetに全てのレプリカを移動させます。これを確認するためには以下のコマンドを実行して下さい。

-    ```shell
-    kubectl get deploy
-    ```
-    実行結果は以下のとおりです。
-    ```
-    NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-    nginx-deployment     15        18        7            8           7m
-    ```
-  　ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
-    ```shell
-    kubectl get rs
-    ```
-    実行結果は以下のとおりです。
-    ```
-    NAME                          DESIRED   CURRENT   READY     AGE
-    nginx-deployment-1989198191   7         7         0         7m
-    nginx-deployment-618515232    11        11        11        7m
-    ```
+```shell
+kubectl get deploy
+```
+
+実行結果は以下のとおりです。
+```
+NAME                 DESIRED   CURRENT   UP-TO-DATE  AVAILABLE   AGE
+nginx-deployment     15        18        7           8           7m
+```
+ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
+```shell
+kubectl get rs
+```
+
+実行結果は以下のとおりです。
+```
+NAME                          DESIRED   CURRENT  READY     AGE
+nginx-deployment-1989198191   7         7        0         7m
+nginx-deployment-618515232    11        11       11        7m
+```

 ## Deployment更新の一時停止と再開 {#pausing-and-resuming-a-deployment}

@@ -747,7 +754,7 @@ Deploymentのローリングアップデートは、同時に複数のバージ
    nginx-3926361531   3         3         3         28s
    ```
 {{< note >}}
-一時停止したDeploymentの稼働を再開させない限り、Deploymentをロールバックすることはできません。
+Deploymentの稼働を再開させない限り、一時停止したDeploymentをロールバックすることはできません。
 {{< /note >}}

 ## Deploymentのステータス {#deployment-status}
@@ -756,7 +763,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し

 ### Deploymentの更新処理 {#progressing-deployment}

-以下のタスクが実行中のとき、KubernetesはDeploymentの状態を_progressing_ にします。
+以下のタスクが実行中のとき、KubernetesはDeploymentの状態を _進行中_ にします。

 * Deploymentが新しいReplicaSetを作成します。
 * Deploymentが新しいReplicaSetをスケールアップさせています。
@@ -767,7 +774,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し

 ### Deploymentの更新処理の完了 {#complete-deployment}

-Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを_complete_ にします。
+Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを _完了_ にします。

 * Deploymentの全てのレプリカが、指定された最新のバージョンに更新されます。これは指定した更新処理が完了したことを意味します。
 * Deploymentの全てのレプリカが利用可能になります。
@@ -782,7 +789,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
 deployment.apps/nginx-deployment successfully rolled out
-$ echo $?
+```
+そして`kubectl rollout`の終了ステータスが0となります（成功です）:
+```shell
+echo $?
+```
+```
 0
 ```

@@ -821,7 +833,8 @@ Kubernetesは停止状態のDeploymentに対して、ステータス状態を報
 {{< /note >}}

 {{< note >}}
-Deploymentを停止すると、Kubernetesは指定したデッドラインを超えたかどうかチェックしません。ロールアウトの途中でもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
+Deploymentを停止すると、Kubernetesは指定したデッドラインを超えたかどうかチェックしません。
+ロールアウトの途中でもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
 {{< /note >}}

 設定したタイムアウトの秒数が小さかったり、一時的なエラーとして扱える他の種類のエラーが原因となり、Deploymentで一時的なエラーが出る場合があります。例えば、リソースの割り当てが不十分な場合を考えます。Deploymentの詳細情報を確認すると、以下のセクションが表示されます。
@@ -903,7 +916,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 error: deployment "nginx" exceeded its progress deadline
-$ echo $?
+```
+そして`kubectl rollout`の終了ステータスが1となります(エラーを示しています):
+```shell
+echo $?
+```
+```
 1
 ```

@@ -921,19 +939,20 @@ Deploymentが管理する古いReplicaSetをいくつ保持するかを指定す

 ## カナリアパターンによるデプロイ

-Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
+Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#canary-deployments-カナリアデプロイ)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。

 ## Deployment Specの記述

-他の全てのKubernetesの設定と同様に、Deploymentは`apiVersion`、`kind`や`metadata`フィールドを必要とします。設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
-Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
+他の全てのKubernetesの設定と同様に、Deploymentは`.apiVersion`、`.kind`や`.metadata`フィールドを必要とします。
+設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/ja/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
+Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
 Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。

 ### Podテンプレート

 `.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。

-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては[Pod](/ja/docs/concepts/workloads/pods/pod/)と同じスキーマとなります。
+`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては{{< glossary_tooltip text="Pod" term_id="pod" >}}と同じスキーマとなります。

 Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。

@@ -967,49 +986,44 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成

 `.spec.strategy.type==Recreate`と指定されているとき、既存の全てのPodは新しいPodが作成される前に削除されます。

+{{< note >}}
+これは更新のための作成の前にPodを停止する事を保証するだけです。Deploymentを更新する場合、古いリビジョンのPodは全てすぐに停止されます。削除に成功するまでは、新しいリビジョンのPodは作成されません。手動でPodを削除すると、ライフサイクルがReplicaSetに制御されているのですぐに置き換えが実施されます（たとえ古いPodがまだ停止中のステータスでも）。Podに"高々この程度の"保証を求めるならば[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)の使用を検討してください。
+{{< /note >}}
+
 #### Deploymentのローリングアップデート

-`.spec.strategy.type==RollingUpdate`と指定されているとき、Deploymentは[ローリングアップデート](/docs/tasks/run-application/rolling-update-replication-controller/)によりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
+`.spec.strategy.type==RollingUpdate`と指定されているとき、DeploymentはローリングアップデートによりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。

-##### maxUnavailable
+##### Max Unavailable {#max-unavailable}

 `.spec.strategy.rollingUpdate.maxUnavailable`はオプションのフィールドで、更新処理において利用不可となる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り捨てされて計算されます。`.spec.strategy.rollingUpdate.maxSurge`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。

 例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると古いReplicaSetはすぐに理想状態の70%にスケールダウンされます。一度新しいPodが稼働できる状態になると、古いReplicaSetはさらにスケールダウンされ、続いて新しいReplicaSetがスケールアップされます。この間、利用可能なPodの総数は理想状態のPodの少なくとも70%以上になるように保証されます。

-##### maxSurge
+##### Max Surge {#max-surge}

 `.spec.strategy.rollingUpdate.maxSurge`はオプションのフィールドで、理想状態のPod数を超えて作成できる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り上げで計算されます。`MaxUnavailable`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。

 例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると新しいReplicaSetはすぐに更新されます。このとき古いPodと新しいPodの総数は理想状態の130%を超えないように更新されます。一度古いPodが削除されると、新しいReplicaSetはさらにスケールアップされます。この間、利用可能なPodの総数は理想状態のPodに対して最大130%になるように保証されます。

-### progressDeadlineSeconds
+### Progress Deadline Seconds

-`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
+`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。デフォルト値は600です。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。

 この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。

-### minReadySeconds {#min-ready-seconds}
+### Min Ready Seconds {#min-ready-seconds}

 `.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。

-### rollbackTo
-
-`.spec.rollbackTo`は、`extensions/v1beta1`と`apps/v1beta1`のAPIバージョンにおいて非推奨で、`apps/v1beta2`以降のAPIバージョンではサポートされません。かわりに、[前のリビジョンへのロールバック](#rolling-back-to-a-previous-revision)で説明されているように`kubectl rollout undo`を使用するべきです。
-
 ### リビジョン履歴の保持上限

 Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。

 `.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。

-さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。
+さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを元に戻すことができません。

 ### paused

 `.spec.paused`はオプションのboolean値で、Deploymentの一時停止と再開のための値です。一時停止されているものと、そうでないものとの違いは、一時停止されているDeploymentはPodTemplateSpecのいかなる変更があってもロールアウトがトリガーされないことです。デフォルトではDeploymentは一時停止していない状態で作成されます。
-
-## Deploymentの代替案
-### kubectl rolling-update
-
-[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)によって、同様の形式でPodとReplicationControllerを更新できます。しかしDeploymentの使用が推奨されます。なぜならDeploymentの作成は宣言的であり、ローリングアップデートが更新された後に過去のリビジョンにロールバックできるなど、いくつかの追加機能があるためです。
@@ -83,9 +83,6 @@ Kubernetes1.7では、認証されていない従属オブジェクトがオー

 カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。

-Kubernetes1.9以前では多くのコントローラーにおけるデフォルトのガベージコレクションポリシーは`orphan`でした。
-この対象のコントローラーはReplicationController、ReplicaSet、StatefulSet、DaemonSetとDeploymentを含みます。`extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2`のグループバージョンに含まれるオブジェクト種においては、もしユーザーがガベージコレクションに他の値を設定しない限り、デフォルトで従属オブジェクトはみなしご(orphaned)になります。
-Kubernetes1.9において、`apps/v1`というグループバージョンにおいて、従属オブジェクトはデフォルトで削除されます。

 下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。

@@ -1,387 +0,0 @@
---
-title: Job
-content_type: concept
-feature:
-  title: バッチ実行
-  description: >
-    Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。
-weight: 60
---
-
-<!-- overview -->
-
-Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。
-JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。
-
-簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。
-ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。
-
-また、Jobを使用して複数のPodを並行して実行することもできます。
-
-
-
-
-<!-- body -->
-
-## Jobの実行例
-
-ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。
-完了までに10秒程度かかります。
-
-{{< codenew file="controllers/job.yaml" >}}
-
-このコマンドで例を実行できます。
-
-```shell
-kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
-```
-```
-job.batch/pi created
-```
-
-Jobのステータスは、`kubectl`を用いて確認します。
-
-```shell
-kubectl describe jobs/pi
-```
-```
-Name:           pi
-Namespace:      default
-Selector:       controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
-Labels:         controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
-                job-name=pi
-Annotations:    kubectl.kubernetes.io/last-applied-configuration:
-                  {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":...
-Parallelism:    1
-Completions:    1
-Start Time:     Mon, 02 Dec 2019 15:20:11 +0200
-Completed At:   Mon, 02 Dec 2019 15:21:16 +0200
-Duration:       65s
-Pods Statuses:  0 Running / 1 Succeeded / 0 Failed
-Pod Template:
-  Labels:  controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
-           job-name=pi
-  Containers:
-   pi:
-    Image:      perl
-    Port:       <none>
-    Host Port:  <none>
-    Command:
-      perl
-      -Mbignum=bpi
-      -wle
-      print bpi(2000)
-    Environment:  <none>
-    Mounts:       <none>
-  Volumes:        <none>
-Events:
-  Type    Reason            Age   From            Message
-  ----    ------            ----  ----            -------
-  Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7
-```
-
-Jobの完了したPodを表示するには、`kubectl get pods`を使います。
-
-あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。
-
-```shell
-pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
-echo $pods
-```
-```
-pi-5rwd7
-```
-
-ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。
-
-
-いずれかのPodの標準出力を表示します。
-
-```shell
-kubectl logs $pods
-```
-出力例は以下の通りです。
-```shell
-3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
-```
-
-## Jobの仕様の作成
-
-他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。
-その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
-
-Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
-
-### Podテンプレート
-
-`.spec.template`は、`.spec`の唯一の必須フィールドです。
-
-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。
-ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。
-
-Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。
-
-`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。
-
-### Podセレクター {#pod-selector}
-
-`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。
-セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。
-
-
-### Jobの並列実行 {#parallel-jobs}
-
-Jobとして実行するのに適したタスクは、大きく分けて3つあります。
-
-1. 非並列Job
-   - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。
-   - そのPodが正常に終了するとすぐにJobが完了します。
-2. *固定の完了数*を持つ並列Job
-   - `.spec.completions`に、0以外の正の値を指定します。
-   - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。
-   - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。
-3. *ワークキュー*を持つ並列Job
-   - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。
-   - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。
-   - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。
-   - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。
-   - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。
-   - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。
-
-_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。
-
-_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。
-
-
-様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。
-
-#### 並列処理の制御
-
-並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。
-指定しない場合、デフォルトで1になります。
-0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。
-
-以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。
-
- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。
- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。
- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。
- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。
- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。
- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。
-
-## Podおよびコンテナの障害の処理
-
-Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。
-`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。
-
-さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。
-
-たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。
-
-`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。
-
-### Pod Backoff Failure Policy
-
-構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。
-そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。
-失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。
-JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。
-
-{{< note >}}
-Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。
-{{< /note >}}
-
-## Jobの終了とクリーンアップ
-
-Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。
-Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。
-
-デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。
-
-Jobを終了する別の方法は、アクティブな期限を設定することです。
-これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します
-`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。
-Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。
-
-Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。
-
-以下に例を挙げます。
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: pi-with-timeout
-spec:
-  backoffLimit: 5
-  activeDeadlineSeconds: 100
-  template:
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-      restartPolicy: Never
-```
-
-Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。
-
-`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。
-つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。
-
-## 終了したJobの自動クリーンアップ
-
-終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 
-
-### 終了したJobのTTLメカニズム
-
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-
-完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。
-
-TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。
-
-例は以下の通りです。
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: pi-with-ttl
-spec:
-  ttlSecondsAfterFinished: 100
-  template:
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-      restartPolicy: Never
-```
-
-Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。
-
-フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。
-
-このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。
-
-## Jobのパターン {#job-patterns}
-
-Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。
-
-例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。
-
-複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。
-
-並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。
-トレードオフは以下の通りです。
-
- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。
- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。
- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。
-
-ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。
-パターン名は、例とより詳細な説明へのリンクでもあります。
-
-|                            パターン名                                                            | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ |  Kube 1.1で動作するか？ |
-| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
-| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/)                      |                   |                             |          ✓          |          ✓          |
-| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) |         ✓         |                             |      場合による      |          ✓          |
-| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/)         |         ✓         |             ✓               |                     |          ✓          |
-| 単一のJob静的な処理を割り当てる                                                                      |         ✓         |                             |          ✓          |                     |
-
-完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。
-
-以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。
-ここで、`W`はワークアイテム数とします。
-
-|                            パターン名                                                            | `.spec.completions` |  `.spec.parallelism` |
-| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:|
-| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/)                      |          1          |     1とする必要あり      |
-| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) |          W          |        任意           |
-| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/)         |          1          |        任意          |
-| 単一のJob静的な処理を割り当てる                                                                      |          W          |        任意           |
-
-
-## 高度な使用方法
-
-### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector}
-
-通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。
-システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。
-セレクターの値は、他のJobと重複しないように選択されます。
-
-しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。
-これを行うには、Jobの`.spec.selector`を指定します。
-
-これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。
-もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。
-
-ここでは、この機能を使いたくなるようなケースの例をご紹介します。
-`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。
-これらのフィールドは更新が不可能であるため、Jobを更新することはできません。
-そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。
-削除する前に、どのセレクターを使っているかメモしておきます。
-
-```
-kubectl get job old -o yaml
-```
-```
-kind: Job
-metadata:
-  name: old
-  ...
-spec:
-  selector:
-    matchLabels:
-      controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
-  ...
-```
-次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。
-既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。
-
-システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。
-
-```
-kind: Job
-metadata:
-  name: new
-  ...
-spec:
-  manualSelector: true
-  selector:
-    matchLabels:
-      controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
-  ...
-```
-
-新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。
-`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。
-
-## 代替案
-
-### ベアPod
-
-Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。
-このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。
-
-### レプリケーションコントローラー
-
-Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。
-レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。
-
-[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。
-(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。)
-
-### 単一のJobでコントローラーPodを起動
-
-もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。
-
-このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。
-
-このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。
-
-## Cron Job {#cron-jobs}
-
-Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。
@@ -2,7 +2,7 @@
 reviewers:
 title: ReplicaSet
 content_type: concept
-weight: 10
+weight: 20
 ---

 <!-- overview -->
@@ -207,9 +207,9 @@ ReplicaSetオブジェクトの名前は、有効な
 `.spec.selector`フィールドは[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)です。
 [先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。
 先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました
-```shell
+```yaml
 matchLabels:
-	tier: frontend
+  tier: frontend
 ```

 そのReplicaSetにおいて、`.spec.template.metadata.labels`フィールドの値は`spec.selector`と一致しなくてはならず、一致しない場合はAPIによって拒否されます。
@@ -281,7 +281,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
 同様のことを行うための代替案として、`kubectl autoscale`コマンドも使用できます。(こちらの方がより簡単です。)

 ```shell
-kubectl autoscale rs frontend --max=10
+kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
 ```

 ## ReplicaSetの代替案
@@ -2,7 +2,7 @@
 reviewers:
 title: StatefulSet
 content_type: concept
-weight: 40
+weight: 30
 ---

 <!-- overview -->
@@ -117,6 +117,15 @@ StatefulSetは、Podのドメインをコントロールするために[Headless
 このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。
 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。

+クラスターでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。
+この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリーをすでに送信していた場合に発生する可能性があります。
+(DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。
+
+Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。
+
+- DNSルックアップに依存するのではなく、Kubernetes APIに直接(例えばwatchを使って)問い合わせる。
+- Kubernetes DNS プロバイダーのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。
+
 [制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。

 ここで、クラスタードメイン、Service名、StatefulSet名の選択と、それらがStatefulSetのPodのDNS名にどう影響するかの例をあげます。
@@ -150,7 +159,7 @@ StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controlle

 StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。

-上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
+上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。

 もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。

@@ -167,7 +176,7 @@ Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podM

 ## アップデートストラテジー

-Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStarategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。
+Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStrategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。

 ### OnDelete

@@ -199,4 +208,3 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
 * [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
 * [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
 * [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
-
@@ -2,7 +2,7 @@
 reviewers:
 title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources)
 content_type: concept
-weight: 65
+weight: 70
 ---

 <!-- overview -->
@@ -10,7 +10,7 @@ weight: 65
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

 TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。  
-TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。
+TTLコントローラーは現在{{< glossary_tooltip text="Job" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。

 α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。

@@ -23,7 +23,7 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs

 ## TTLコントローラー

-TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。  
+TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。  
 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。

 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
@@ -50,8 +50,6 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode
 ## {{% heading "whatsnext" %}}


-[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
-
-[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
-
+* [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)

+* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
@@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー

 Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。

-また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`をサポートしていません。
+また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`lifecycle`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。

 複数のInitコンテナを単一のPodに対して指定した場合、KubeletはそれらのInitコンテナを1つずつ順番に実行します。各Initコンテナは、次のInitコンテナが稼働する前に正常終了しなくてはなりません。全てのInitコンテナの実行が完了すると、KubeletはPodのアプリケーションコンテナを初期化し、通常通り実行します。

@@ -200,11 +200,11 @@ NAME        READY     STATUS    RESTARTS   AGE
 myapp-pod   1/1       Running   0          9m
 ```

-このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。
+このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#whats-next)にさらに詳細な使用例に関するリンクがあります。

 ## Initコンテナのふるまいに関する詳細 {#detailed-behavior}

-Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。
+Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従ってPodのInitコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。

 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。

@@ -6,186 +6,110 @@ weight: 30

 <!-- overview -->

-このページではPodのライフサイクルについて説明します。
+このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。

+Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。

+Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。
+
+Podはその生存期間に1回だけ[スケジューリング](/docs/concepts/scheduling-eviction/)されます。PodがNodeにスケジュール(割り当て)されると、Podは停止または[終了](#pod-termination)するまでそのNode上で実行されます。


 <!-- body -->

-## PodのPhase {#pod-phase}
+## Podのライフタイム
+
+個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。Podが作成されると、一意のID([UID](ja/docs/concepts/overview/working-with-objects/names/#uids))が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。  
+{{< glossary_tooltip term_id="node" >}}が停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に[削除](#pod-garbage-collection)されます。
+
+Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりポッドはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。
+
+特定のPod(UIDで定義)は新しいNodeに"再スケジュール"されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。
+
+{{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。
+
+{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
+
+*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。*
+
+
+## Podのフェーズ {#pod-phase}

 Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。

-Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。
-このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。
+Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。

-Podの各フェーズの値と意味は厳重に守られています。
-ここに記載されているもの以外に`phase`の値は存在しないと思ってください。
+Podの各フェーズの値と意味は厳重に守られています。ここに記載されているもの以外に`phase`の値は存在しないと思ってください。

 これらが`phase`の取りうる値です。

 値 | 概要
 :-----|:-----------
-`Pending` | PodがKubernetesシステムによって承認されましたが、1つ以上のコンテナイメージが作成されていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。これには時間がかかることがあります。
+`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。
 `Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。
 `Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。
 `Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
-`Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。
+`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。

-## Podのconditions {#pod-conditions}
-
-PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。
-PodCondition配列の各要素には、次の6つのフィールドがあります。
-
-* `lastProbeTime` は、Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。
-
-* `lastTransitionTime` は、最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。
-
-* `message` は、ステータスの遷移に関する詳細を示す人間向けのメッセージです。
-
-* `reason` は、最後の状態遷移の理由を示す、一意のキャメルケースでの単語です。
-
-* `status` は`True`と`False`、`Unknown`のうちのどれかです。
-
-* `type` 次の値を取る文字列です。
-
-  * `PodScheduled`: PodがNodeにスケジュールされました。
-  * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
-  * `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
-  * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
-
-
-## コンテナのProbe {#container-probes}
-
-[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。
-診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。
-Handlerには次の3つの種類があります:
-
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
-  コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。
-
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
-  コンテナのIPの特定のポートにTCPチェックを行います。
-  そのポートが空いていれば診断を成功とみなします。
-
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
-  コンテナのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。
-  レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。
-
-各Probe 次の3つのうちの一つの結果を持ちます:
-
-* Success: コンテナの診断が成功しました。
-* Failure: コンテナの診断が失敗しました。
-* Unknown: コンテナの診断が失敗し、取れるアクションがありません。
-
-Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます:
-
-* `livenessProbe`: コンテナが動いているかを示します。
-   livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
-   コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。
-
-* `readinessProbe`: コンテナがServiceのリクエストを受けることができるかを示します。
-   readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。
-   initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。
-   コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。
-
-* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。
-   startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。
-   startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
-   コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。
-
-### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe}
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば
-livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。
-
-Probeに失敗したときにコンテナを殺したり再起動させたりするには、
-livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。
-
-### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe}
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
-この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、
-readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。
-コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。
-
-コンテナがメンテナンスのために停止できるようにするには、
-livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。
-
-Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。
-Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。
-Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。
-
-### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。
-`periodSeconds`のデフォルトは30秒です。
-
-`failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。
-
-livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、
-[Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。
-
-## Podとコンテナのステータス {#pod-and-container-status}
-
-PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。
-Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。
+Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。

 ## コンテナのステータス {#container-states}

-PodがスケジューラによってNodeに割り当てられると、
-kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。
-コンテナの状態はWaiting、RunningまたはTerminatedの3ついずれかです。
-コンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。
-Pod内のコンテナごとにStateの項目として表示されます。
+Pod全体の[フェーズ](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。

-* `Waiting`: コンテナのデフォルトの状態。コンテナがRunningまたはTerminatedのいずれの状態でもない場合コンテナはWaitingの状態になります。Waiting状態のコンテナは引き続きイメージを取得したりSecretsを適用したりするなど必要な操作を実行します。この状態に加えてメッセージに関する情報と状態に関する理由が表示されます。
+Podが{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}によってNodeに割り当てられると、kubeletは{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}を使用してコンテナの作成を開始します。コンテナの状態は`Waiting`、`Running`または`Terminated`の3ついずれかです。

-    ```yaml
-   ...
-      State:          Waiting
-       Reason:       ErrImagePull
-   ...
-   ```
+Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。Pod内のコンテナごとにStateの項目として表示されます。

-* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。
+各状態の意味は次のとおりです。

-   ```yaml
-   ...
-      State:          Running
-       Started:      Wed, 30 Jan 2019 16:46:38 +0530
-   ...
-   ```
+### `Waiting` {#container-state-waiting}

-* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。
+コンテナが`Running`または`Terminated`のいずれの状態でもない場合コンテナは`Waiting`の状態になります。Waiting状態のコンテナは引き続きコンテナイメージレジストリからイメージを取得したり{{< glossary_tooltip text="Secret" term_id="secret" >}}を適用したりするなど必要な操作を実行します。`Waiting`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Waiting`の状態である理由の要約が表示されます。

-   ```yaml
-   ...
-      State:          Terminated
-        Reason:       Completed
-        Exit Code:    0
-        Started:      Wed, 30 Jan 2019 11:45:26 +0530
-        Finished:     Wed, 30 Jan 2019 11:45:26 +0530
-    ...
-   ```
+### `Running` {#container-state-running}

-## PodReadinessGate {#pod-readiness-gate}
+`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。
+
+### `Terminated` {#container-state-terminated}
+
+`Terminated`状態のコンテナは実行されて、完了したときまたは何らかの理由で失敗したことを示します。`Terminated`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。
+
+コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。
+
+## コンテナの再起動ポリシー {#restart-policy}
+
+Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。
+
+`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。
+
+## PodのCondition {#pod-conditions}
+
+PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。
+
+* `PodScheduled`: PodがNodeにスケジュールされました。
+* `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
+* `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
+* `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
+
+フィールド名         | 内容
+:--------------------|:-----------
+`type`               | このPodの状態の名前です。
+`status`             | その状態が適用可能かどうか示します。可能な値は"`True`"と"`False`"、"`Unknown`"のうちのいずれかです。
+`lastProbeTime`      | Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。
+`lastTransitionTime` | 最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。
+`reason`             | 最後の状態遷移の理由を示す、機械可読のアッパーキャメルケースのテキストです。
+`message`            | ステータスの遷移に関する詳細を示す人間向けのメッセージです。
+
+## PodのReadiness {#pod-readiness-gate}

 {{< feature-state for_k8s_version="v1.14" state="stable" >}}

-追加のフィードバックやシグナルを`PodStatus`に注入できるようにしてPodのReadinessに拡張性を持たせるため、
-Kubernetes 1.11 では[Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)という機能が導入されました。
-`PodSpec`の新しいフィールド`ReadinessGate`を使用して、PodのRedinessを評価する追加の状態を指定できます。
-KubernetesがPodのstatus.conditionsフィールドでそのような状態を発見できない場合、
-ステータスはデフォルトで`False`になります。以下はその例です。
+追加のフィードバックやシグナルをPodStatus:_Pod readiness_に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。
+
+ReadinessゲートはPodの`status.conditions`フィールドの現在の状態によって決まります。Kubernetesが`Podのstatus.conditions`フィールドでそのような状態を発見できない場合、ステータスはデフォルトで`False`になります。
+
+以下はその例です。

 ```yaml
 Kind: Pod
@@ -209,130 +133,139 @@ status:
 ...
 ```

-新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
-`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、
-新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。
+PodのConditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。

-新しいPod Conditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます:
+### PodのReadinessの状態 {#pod-readiness-status}
+
+`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていません。Podにこれらの`status.conditions`を設定するには、アプリケーションと{{< glossary_tooltip term_id="operator-pattern" text="operators">}}は`PATCH`アクションを使用する必要があります。[Kubernetes client library](/docs/reference/using-api/client-libraries/)を使用して、PodのReadinessのためにカスタムのPodのConditionを設定するコードを記述できます。
+
+カスタムのPodのConditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます:

 * Pod内のすべてのコンテナが準備完了している。
 * `ReadinessGates`で指定された条件が全て`True`である。

-PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。
+Podのコンテナは準備完了ですが、少なくとも1つのカスタムのConditionが欠落しているか「False」の場合、kubeletはPodの[Condition](#pod-condition)を`ContainersReady`に設定します。

-## RestartPolicy {#restart-policy}
+## コンテナのProbe {#container-probes}

-PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。
-デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。
-`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。
-kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延（10秒、20秒、40秒...）で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。
+[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります:

-## Podのライフタイム {#pod-lifetime}
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+  コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。

-一般にPodは人間またはコントローラーが明示的に削除するまで存在します。
-コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。
-これはPodが作成されて時間とともに終了するため、リソースリークを避けます。
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
+  PodのIPの特定のポートにTCPチェックを行います。
+  そのポートが空いていれば診断を成功とみなします。

-次の3種類のコントローラがあります。
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
+  PodのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。
+  レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。

- バッチ計算などのように終了が予想されるPodに対しては、[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用します。
-   Jobは`restartPolicy`がOnFailureまたはNeverになるPodに対してのみ適切です。
+各Probe 次の3つのうちの一つの結果を持ちます:

- 停止することを期待しないPod（たとえばWebサーバーなど）には、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)、または[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)を使用します。ReplicationControllerは`restartPolicy`がAlwaysのPodに対してのみ適切です。
+* `Success`: コンテナの診断が成功しました。
+* `Failure`: コンテナの診断が失敗しました。
+* `Unknown`: コンテナの診断が失敗し、取れるアクションがありません。

- マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodには[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を使用します。
+Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます:

-3種類のコントローラにはすべてPodTemplateが含まれます。
-Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。
-これはPod単独ではマシンの障害に対して回復力がないためです。コントローラにはこの機能があります。
+* `livenessProbe`: コンテナが動いているかを示します。
+   livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
+   コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。

-Nodeが停止したりクラスタの他のNodeから切断された場合、
-Kubernetesは失われたノード上のすべてのPodの`phase`をFailedに設定するためのポリシーを適用します。
+* `readinessProbe`: コンテナがリクエスト応答する準備ができているかを示します。
+   readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。
+   initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。
+   コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。

-## 例
+* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。
+   startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。
+   startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
+   コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。

-### 高度なliveness probeの例
+livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、[Liveness Probe、Readiness ProbeおよびStartup Probeを使用する](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。

-Liveness Probeはkubeletによって実行されるため、
-すべてのリクエストはkubeletネットワークのnamespaceで行われます。
+### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe}

-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  labels:
-    test: liveness
-  name: liveness-http
-spec:
-  containers:
-  - args:
-    - /server
-    image: k8s.gcr.io/liveness
-    livenessProbe:
-      httpGet:
-        # "host" が定義されていない場合、"PodIP"が使用されます
-        # host: my-host
-        # "scheme"が定義されていない場合、HTTPスキームが使用されます。"HTTP"と"HTTPS"のみ
-        # scheme: HTTPS
-        path: /healthz
-        port: 8080
-        httpHeaders:
-        - name: X-Custom-Header
-          value: Awesome
-      initialDelaySeconds: 15
-      timeoutSeconds: 1
-    name: liveness
-```
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}

-### statesの例
+コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができればlivenessProbeは不要です.
+この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。

-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナは正常終了しました。
-     * 完了のイベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: Podの`phase`はSucceededになります。
-       * Never: Podの`phase`はSucceededになります。
+Probeに失敗したときにコンテナを殺したり再起動させたりするには、livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。

-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナは失敗終了しました。
-     * 失敗イベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: Podの`phase`はFailedになります。
+### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe}

-   * Podが実行中で、その中には2つのコンテナがあります。コンテナ1は失敗終了しました。
-     * 失敗イベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: コンテナを再起動しません。Podの`phase`はRunningのままです。
-     * コンテナ1が死んでいてコンテナ2は動いている場合
-       * 失敗イベントを記録します。
-       * `restartPolicy`が、
-         * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-         * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-         * Never: Podの`phase`はFailedになります。
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}

-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナはメモリーを使い果たしました。
-     * コンテナは失敗で終了します。
-     * OOMイベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: 失敗イベントを記録します。Podの`phase`はFailedになります。
+Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
+この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。

-   * Podが実行中ですがディスクは死んでいます。
-     * すべてのコンテナを殺します。
-     * 適切なイベントを記録します。
-     * Podの`phase`はFailedになります。
-     * Podがコントローラで作成されていた場合は、別の場所で再作成されます。
+コンテナがメンテナンスのために停止できるようにするには、livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。

-   * Podが実行中ですがNodeが切り離されました。
-     * Nodeコントローラがタイムアウトを待ちます。
-     * NodeコントローラがPodの`phase`をFailedにします。
-     * Podがコントローラで作成されていた場合は、別の場所で再作成されます。
+{{< note >}}
+Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。
+{{< /note >}}
+
+### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。
+コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。
+
+## Podの終了 {#pod-termination}
+
+Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
+
+ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。
+
+通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。
+
+フローの例は下のようになります。
+
+1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するために`kubectl`コマンドを送信する。
+1. API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。  
+   削除中のPodに対して`kubectl describe`コマンドを使用すると、Podは「終了中」と表示される。  
+   Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。
+    1. Pod内のコンテナの1つが`preStop`[フック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。
+   {{< note >}}
+   `preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要があります。
+   {{< /note >}}
+    1. kubeletはコンテナランタイムをトリガーして、コンテナ内のプロセス番号1にTERMシグナルを送信する。
+   {{< note >}}
+   Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。
+   {{< /note >}}
+1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシーのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。
+1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。
+1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。
+1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。


+### Podの強制削除 {#pod-termination-forced}
+
+{{< caution >}}
+強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。
+{{< /caution >}}
+
+デフォルトでは、すべての削除は30秒以内に正常に行われます。`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=<seconds>` オプションをサポートします。
+
+`--grace-period`を`0`に設定した場合、PodはAPI serverから即座に強制的に削除されます。PodがNode上でまだ実行されている場合、その強制削除によりkubeletがトリガーされ、すぐにクリーンアップが開始されます。
+
+{{< note >}}
+強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。
+{{< /note >}}
+
+強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。
+
+StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
+
+
+### 失敗したPodのガベージコレクション {#pod-garbage-collection}
+
+失敗したPodは人間または{{< glossary_tooltip term_id="controller" text="controller" >}}が明示的に削除するまで存在します。
+
+コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値(kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される)を超えたとき、それらのPodを削除します。これはPodが作成されて時間とともに終了するため、リソースリークを避けます。


 ## {{% heading "whatsnext" %}}
@@ -344,4 +277,4 @@ spec:

 * [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ

-
+* APIのPod/コンテナステータスの詳細情報は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)および[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください
@@ -33,7 +33,7 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで
  * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)

 各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。
-Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。
+Kubernetesにおいて、これは一般的に _レプリケーション_ と呼ばれます。
 レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。
 さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。

@@ -1,188 +0,0 @@
---
-reviewers:
-title: Pod
-content_type: concept
-weight: 20
---
-
-<!-- overview -->
-
-_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。
-
-
-
-
-<!-- body -->
-
-## Podとは
-
-_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
-
-Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。
-
-Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離する一連の要素と同じものがコンテキストとして共有されます。
-Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。
-
-Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。
-また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。
-異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。
-これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。
-
-Pod内のアプリケーションからアクセスできる共有ボリュームを、Podの一部として定義できます。
-このボリュームは個々のアプリケーションのファイルシステムにマウント可能です。
-
-[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
-
-個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。
-[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。
-Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
-特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。
-代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。
-
-ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。
-そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。
-
-{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
-
-*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
-
-## Podを用いる動機
-
-### 管理
-
-Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。
-構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。
-Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。
-Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
-
-### リソース共有と通信
-
-Podは、構成要素間でのデータ共有および通信を可能にします。
-
-Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
-このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。
-各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。
-
-Pod内のアプリケーションコンテナのホスト名には、Podの名前が設定されます。
-詳細は[クラスターネットワーク](/docs/concepts/cluster-administration/networking/)をご覧ください。
-
-Podで実行されるアプリケーションコンテナの定義に加えて、Podによって共有ストレージであるボリュームを複数設定することも可能です。
-ボリュームを使用すると、データはコンテナの再起動後も存続し、Pod内のアプリケーション間で共有できます。
-
-## Podの用途
-
-Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。
-しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。
-
-* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
-* ログとチェックポイントのバックアップ、圧縮、ローテーション、スナップショットなど
-* データの変更を監視するもの、ログをtailするもの、ロギングおよび監視の補助プログラム、イベントを発行するものなど
-* プロキシ、ブリッジ、およびアダプタ
-* コントローラー、マネージャー、コンフィギュレーター、およびアップデーター
-
-個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。
-
-詳細については、[The Distributed System ToolKit: Patterns for
-Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。
-
-## 考えられる代替案
-
-_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_
-
-1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。
-これは、ユーザーに多くの便益を提供します。
-1. ソフトウェアの依存関係を減らすため。
-個々のコンテナは、独立してバージョン管理、再構築、および再デプロイできます。
-Kubernetesはいつか個々のコンテナのライブアップデートをサポートするかもしれません。
-1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
-1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。
-
-_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
-
-このアプローチによって、コンテナの共同配置は提供されるでしょう。
-しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。
-
-
-## Podの耐久性(またはその欠如) {#pod-durability}
-
-Podは、耐久性のある存在として扱われることを意図していません。
-スケジューリングの失敗や、Nodeの故障には耐えられません。
-リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。
-
-一般に、ユーザーはPodを直接作成する必要はありません。
-ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/ja/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。
-コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。
-[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset.md)ようなコントローラーもステートフルなPodをサポートします。
-
-主要なユーザー向けのプリミティブとして集合APIを使用することは、[Borg](https://research.google.com/pubs/pub43438.html)、 [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、[Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)などのクラスタースケジューリングシステムで比較的一般的です。
-
-Podは、以下のことを容易にするためにプリミティブとして公開されています。
-
-* スケジューラーとコントローラーをプラガブルにする
-* コントローラーAPIを介して「プロキシ」の必要なしに、Podレベルの操作をサポートする
-* ブートストラップなどのために、コントローラーの寿命からPodの寿命を切り離す
-* コントローラーとサービスを分離する――エンドポイントコントローラーはPodのみを監視する
-* Kubeletレベルの機能とクラスターレベルの機能をきれいに組み合わせる――Kubeletは事実上「Podコントローラー」となる
-* アプリケーションの可用性を高める。
-即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する
-
-## Podの終了 {#termination-of-pods}
-
-Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
-ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
-ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。
-猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。
-プロセスの終了を待っている間にKubeletかコンテナマネージャーが再起動されると、終了処理は猶予期間の後にリトライされます。
-
-フローの例は下のようになります。
-
-1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する
-1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
-1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
-1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
-    1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
-    猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
-    1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
-1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
-ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
-1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
-1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。
-PodはAPIから消え、クライアントからは見えなくなる
-
-デフォルトでは、すべての削除は30秒以内に正常に行われます。
-`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=<seconds>` オプションをサポートします。
-値 `0` はPodを[強制的に削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)します。
-kubectlのバージョン1.5以降では、強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。
-
-### Podの強制削除
-
-Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。
-強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。
-API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。
-Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。
-
-強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。
-StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
-
-## Podコンテナの特権モード {#privileged-mode-for-pod-containers}
-
-Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。
-これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。
-コンテナ内のプロセスは、コンテナ外のプロセスで利用できるものとほぼ同じ特権を獲得します。
-特権モードでは、ネットワークプラグインとボリュームプラグインを別々のPodとして作成する方が簡単なはずです。それらをkubeletにコンパイルする必要はありません。
-
-マスターがKubernetes v1.1以降を実行しており、Nodeがv1.1より前のバージョンを実行している場合、新しい特権付きのPodはAPIサーバーに受け入れられますが、起動されません。
-それらは保留状態になります。
-ユーザーが `kubectl describe pod FooPodName` を実行すると、Podが保留状態になっている理由を確認できます。
-describeコマンド出力のイベントテーブルには、次のように表示されます。
-`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
-
-マスターがv1.1より前のバージョンを実行している場合、特権を持つPodは作成できません。
-ユーザーが特権付きのコンテナを含むPodを作成しようとすると、次のエラーを受け取ります。 
-`The Pod "FooPodName" is invalid.
-spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
-
-## APIオブジェクト
-
-PodはKubernetes REST APIのトップレベルのリソースです。
-APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
@@ -6,25 +6,36 @@ weight: 50
 ---

 <!-- overview -->
-このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。  
+{{< feature-state for_k8s_version="v1.6" state="alpha" >}}

+このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。


 <!-- body -->
 ## PodPresetを理解する

-`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
-ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
+`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。

-PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。  
-この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
+PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。

-PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。
+
+## クラスターでPodPresetを有効にする {#enable-pod-preset}
+
+ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
+
+1.  `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
+1.  `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。例えば、Minikubeにおいては、クラスターの起動時に
+
+  ```shell
+  --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+  ```
+
+  を追加することで可能になります。

 ## PodPresetはどのように動くか

-Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。  
-Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。
+
+Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。

 1. 使用可能な全ての`PodPreset`を取得する。
 1. それらの`PodPreset`のラベルセレクターが、作成されたPod上のラベルと一致するかチェックする。
@@ -32,36 +43,22 @@ Pod作成要求が発生した時、Kubernetesシステムは下記の処理を
 1. エラーが起きた時、そのPod上でマージエラーが起きたことを説明するイベントをスローし、`PodPreset`からリソースを1つも注入されていないPodを作成します。
 1. `PodPreset`によって修正されたことを示すために、マージ後の修正されたPodにアノテーションをつけます。そのアノテーションは`podpreset.admission.kubernetes.io/podpreset-<PodPreset名>: "<リソースのバージョン>"`という形式になります。

-各Podは0以上のPodPresetにマッチすることができます。そして各`PodPreset`は0以上のPodに適用されます。単一の`PodPreset`が1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`Env`、`EnvFrom`、`VolumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`Volume`への変更があった場合、KubernetesはそのPodのSpecを修正します。
+各Podは0以上のPodPresetにマッチすることができます。そして各PodPresetは0以上のPodに適用されます。単一のPodPresetが1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`env`、`envFrom`、`volumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`volumes`への変更があった場合、KubernetesはそのPodのSpecを修正します。

 {{< note >}}
-単一のPodPresetは必要に応じてPodのSpec内の`.spec.containers`を修正することができます。PodPresetからのリソース定義は`initContainers`フィールドに対して1つも適用されません。
+単一のPodPresetは必要に応じてPodのspec内の以下のフィールドを修正することができます。
+- `.spec.containers`フィールド
+- `.spec.initContainers`フィールド
 {{< /note >}}

 ### 特定のPodに対するPodPresetを無効にする

-PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。  
+PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodの`.spec`内に次のような形式のアノテーションを追加できます。  
 `podpreset.admission.kubernetes.io/exclude: "true"`

-## PodPresetを有効にする
-
-ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
-
-1.  `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
-1.  `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に
-
-  ```shell
-  --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
-  ```
-
-  を追加することで可能になります。
-1.  ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。
-
-

 ## {{% heading "whatsnext" %}}

+[PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)

-* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
-
-
+PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。
@@ -54,8 +54,8 @@ card:
 #### 既存のページの誤字脱字や古い記述を修正する場合の手順

 1. `kubernetes/website`リポジトリをフォークする
-2. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する
-3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する
+2. `dev-1.18-ja.2`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する
+3. `dev-1.18-ja.2`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する

 ### マイルストーンについて {#milestones}

@@ -0,0 +1,14 @@
+---
+title: 変更のレビュー
+weight: 30
+---
+
+<!-- overview -->
+
+このセクションでは、コンテンツのレビュー方法について説明します。
+
+
+
+<!-- body -->
+
+
@@ -0,0 +1,62 @@
+---
+title: ドキュメントコンテンツガイド
+linktitle: コンテンツガイド
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+このページでは、Kubernetesのドキュメント上のコンテンツのガイドラインを説明します。
+
+許可されるコンテンツに関して疑問がある場合は、[Kubernetes Slack](https://slack.k8s.io/)の#sig-docsチャンネルに参加して質問してください！
+
+Kubernetes Slackには、<https://slack.k8s.io/> から参加登録ができます。
+
+Kubernetesドキュメントの新しいコンテンツの作成に関する情報については、[スタイルガイド](/docs/contribute/style/style-guide)に従ってください。
+
+<!-- body -->
+
+## 概要
+
+ドキュメントを含むKubernetesのウェブサイトのソースは、[kubernetes/website](https://github.com/kubernetes/website)リポジトリに置かれています。
+
+Kubernetesの主要なドキュメントは`kubernetes/website/content/<language_code>/docs`フォルダに置かれており、これらは[Kubernetesプロジェクト](https://github.com/kubernetes/kubernetes)を対象としています。
+
+## 許可されるコンテンツ
+
+Kubernetesのドキュメントにサードパーティーのコンテンツを掲載することが許されるのは、次の場合のみです。
+
+- コンテンツがKubernetesプロジェクト内のソフトウェアのドキュメントとなる場合
+- コンテンツがプロジェクト外のソフトウェアのドキュメントとなるが、Kubernetesを機能させるために必要である場合
+- コンテンツがkubernetes.ioの正規のコンテンツであるか、他の場所の正規のコンテンツへのリンクである場合
+
+### サードパーティーのコンテンツ
+
+Kubernetesのドキュメントには、Kubernetesプロジェクト([kubernetes](https://github.com/kubernetes)および[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizationsに存在するプロジェクト)の適用例が含まれています。
+
+Kubernetesプロジェクト内のアクティブなコンテンツへのリンクは常に許可されます。
+
+Kubernetesを機能させるためには、一部サードパーティーのコンテンツが必要です。たとえば、コンテナランタイム(containerd、CRI-O、Docker)、[ネットワークポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)(CNI plugin)、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)、[ロギング](/docs/concepts/cluster-administration/logging/)などです。
+
+ドキュメント内で、Kubernetesプロジェクト外のサードパーティーのオープンソースソフトウェア(OSS)にリンクすることができるのは、Kubernetesを機能させるために必要な場合のみです。
+
+### 情報源が重複するコンテンツ
+
+可能な限り、Kubernetesのドキュメントは正規の情報源にリンクするようにし、情報源が重複してしまうようなホスティングは行いません。
+
+情報源が重複したコンテンツは、メンテナンスするために2倍の労力(あるいはそれ以上！)が必要になり、より早く情報が古くなってしまいます。
+
+{{< note >}}
+
+あなたがKubernetesのプロジェクトのメンテナーであり、ドキュメントのホスティングに関して手助けが必要なときは、[Kubernetes Slackの#sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/)で教えてください。
+
+{{< /note >}}
+
+### その他の情報
+
+許可されるコンテンツに関して疑問がある場合は、[Kubernetes Slack](https://slack.k8s.io/)の#sig-docsチャンネルに参加して質問してください！
+
+## {{% heading "whatsnext" %}}
+
+* [スタイルガイド](/docs/contribute/style/style-guide)を読む
@@ -0,0 +1,123 @@
+---
+title: コンテンツの構造化
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+このサイトではHugoを使用しています。Hugoでは、[コンテンツの構造化](https://gohugo.io/content-management/organization/)がコアコンセプトとなっています。
+
+<!-- body -->
+
+{{% note %}}
+**Hugoのヒント:** コンテンツの編集を始めるときは、`hugo server --navigateToChanged`コマンドを使用してHugoを実行してください。
+{{% /note %}}
+
+## ページの一覧
+
+### ページの順序
+
+ドキュメントのサイドメニューやページブラウザーなどでは、Hugoのデフォルトのソート順序を使用して一覧を作成しています。デフォルトでは、weight(1から開始)、日付(最新のものが1番目)、最後にリンクのタイトルの順でソートされます。
+
+そのため、特定のページやセッションを上に移動したい場合には、ページのフロントマター内のweightを設定します。
+
+```yaml
+title: My Page
+weight: 10
+```
+
+{{% note %}}
+ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。
+{{% /note %}}
+
+### ドキュメントのメインメニュー
+
+ドキュメントのメインメニューは、`docs/`以下に置かれたセクションのコンテンツファイル`_index.md`のフロントマター内に`main_menu`フラグが設定されたものから生成されます。
+
+```yaml
+main_menu: true
+```
+
+リンクのタイトルは、ページの`linkTitle`から取得されることに注意してください。そのため、ページのタイトルとは異なるリンクテキストにしたい場合、コンテンツファイル内の値を以下のように設定します。
+
+```yaml
+main_menu: true
+title: ページタイトル
+linkTitle: リンク内で使われるタイトル
+```
+
+{{% note %}}
+上記の設定は言語ごとに行う必要があります。メニュー上にセクションが表示されないときは、Hugoからセクションとして認識されていないためである可能性が高いです。セクションフォルダー内に`_index.md`コンテンツファイルを作成してください。
+{{% /note %}}
+
+### ドキュメントのサイドメニュー
+
+ドキュメントのサイドバーメニューは、`docs/`以下の*現在のセクションツリー*から生成されます。
+
+セクションと、そのセクション内のページがすべて表示されます。
+
+特定のセクションやページをリストに表示したくない場合、フロントマター内の`toc_hide`フラグを`true`に設定してください。
+
+```yaml
+toc_hide: true
+```
+
+コンテンツが存在するセクションに移動すると、特定のセクションまたはページ(例:`index.md`)が表示されます。それ以外の場合、そのセクションの最初のページが表示されます。
+
+### ドキュメントのブラウザー
+
+ドキュメントのホームページのページブラウザーは、`docs`セクション直下のすべてのセクションとページを使用して生成されています。
+
+特定のセクションやページを表示したくない場合、フロントマターの`toc_hide`フラグを`true`に設定してください。
+
+```yaml
+toc_hide: true
+```
+
+### メインメニュー
+
+右上のメニュー(およびフッター)にあるサイトリンクは、page-lookupの機能を使用して実装されています。これにより、ページが実際に存在することを保証しています。そのため、たとえば`case-studies`のセクションが特定の言語のサイトに存在しない場合、メニューにはケーススタディのリンクが表示されません。
+
+## Page Bundle
+
+スタンドアローンのコンテンツページ(Markdownファイル)に加えて、Hugoでは、[Page Bundles](https://gohugo.io/content-management/page-bundles/)がサポートされています。
+
+Page Bundleの1つの例は、[カスタムのHugo Shortcode](/docs/contribute/style/hugo-shortcodes/)です。これは、`leaf bundle`であると見做されます。ディレクトリ内のすべてのファイルは、`index.md`を含めてバンドルの一部となります。これには、ページからの相対リンク、処理可能な画像なども含まれます。
+
+```bash
+en/docs/home/contribute/includes
+├── example1.md
+├── example2.md
+├── index.md
+└── podtemplate.json
+```
+
+もう1つのPage Bundleがよく使われる例は、`includes`バンドルです。フロントマターに`headless: true`を設定すると、自分自身のURLを持たなくなり、他のページ内でのみ使用されるようになります。
+
+```bash
+en/includes
+├── default-storage-class-prereqs.md
+├── index.md
+├── partner-script.js
+├── partner-style.css
+├── task-tutorial-prereqs.md
+├── user-guide-content-moved.md
+└── user-guide-migration-notice.md
+```
+
+バンドル内のファイルに関して、いくつか重要な注意点があります。
+
+* 翻訳されたバンドルに対しては、コンテンツ以外の見つからなかったファイルは上位の言語から継承されます。これにより重複が回避できます。
+* バンドル内のすべてのファイルは、Hugoが`Resources`と呼ぶファイルになり、フロントマター(YAMLファイルなど)をサポートしていない場合であっても、言語ごとにパラメーターやタイトルなどのメタデータを提供できます。詳しくは、[Page Resourcesメタデータ](https://gohugo.io/content-management/page-resources/#page-resources-metadata)を参照してください。
+* `Resource`の`.RelPermalink`から取得した値は、ページからの相対的なものとなっています。詳しくは、[Permalinks](https://gohugo.io/content-management/urls/#permalinks)を参照してください。
+
+## スタイル
+
+このサイトのスタイルシートの[SASS](https://sass-lang.com/)のソースは、`assets/sass`に置かれていて、Hugoによって自動的にビルドされます。
+
+## {{% heading "whatsnext" %}}
+
+* [カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)について学ぶ
+* [スタイルガイド](/docs/contribute/style/style-guide)について学ぶ
+* [コンテンツガイド](/docs/contribute/style/content-guide)について学ぶ
@@ -0,0 +1,45 @@
+---
+title: コンテンツの改善を提案する
+slug: suggest-improvements
+content_type: concept
+weight: 10
+card:
+  name: contribute
+  weight: 20
+---
+
+<!-- overview -->
+
+Kubernetesのドキュメントに何か問題を見つけたり、新しいコンテンツに関してアイデアを思い付いたときは、issueを作ってください。必要なものは、[GitHubアカウント](https://github.com/join)とウェブブラウザーだけです。
+
+Kubernetesのドキュメント上の新しい作業は、ほとんどの場合、GitHubのissueから始まります。Kubernetesのコントリビューターは、必要に応じてレビュー、分類、タグ付けを行います。次に、あなたやKubernetesコミュニティの他のメンバーが、そのissueを解決するための変更を加えるpull requestを開きます。
+
+<!-- body -->
+
+## issueを作る
+
+既存のコンテンツに対して改善を提案したい場合や、間違いを発見した場合は、issueを作ってください。
+
+1. ページの右側のサイドバーにある**ドキュメントのissueを作成**ボタンをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。
+2. 問題や改善の提案について書きます。できる限り多くの詳細情報を提供するようにしてください。
+3. **Submit new issue**ボタンをクリックします。
+
+送信後、定期的にissueを確認するか、GitHubの通知を設定してください。レビュアや他のコミュニティメンバーが、issueに対して作業を行うために、あなたに何か質問をするかもしれません。
+
+## 新しいコンテンツの提案
+
+新しいコンテンツに関するアイデアがあるものの、どの場所に追加すればわからないときでも、issueを作ることができます。次のいずれかを選択して行ってください。
+
+- コンテンツが追加されるべきだと思う既存のページを選択し、**ドキュメントのissueを作成**ボタンをクリックする。
+- [GitHub](https://github.com/kubernetes/website/issues/new/)に移動し、直接issueを作る。
+
+## よいissueを作るには
+
+issueを作るときは、以下のことを心に留めてください。
+
+- 明確なissueの説明を書く。不足している点、古くなっている点、誤っている点、改善が必要な点など、どの点がそうであるか明確に書く。
+- issueがユーザーに与える具体的な影響を説明する。
+- 合理的な作業単位になるように、特定のissueのスコープを制限する。スコープの大きな問題については、小さな複数のissueに分割する。たとえば、"Fix the security docs"(セキュリティのドキュメントを修正する)というのはスコープが大きすぎますが、"Add details to the 'Restricting network access' topic"(トピック「ネットワークアクセスの制限」に詳細情報を追加する)であれば十分に作業可能な大きさです。
+- すでにあるissueを検索し、関連または同様のissueがないかどうか確認する。
+- 新しいissueがほかのissueやpull requestと関係する場合は、完全なURLを参照するか、issueやpull requestの数字の前に`#`の文字を付けて参照する。例えば、`Introduced by #987654`のように書きます。
+- [行動規範](/ja/community/code-of-conduct/)に従って、仲間のコントリビューターに敬意を払いましょう。たとえば、"The docs are terrible"(このドキュメントは最悪だ)のようなコメントは、役に立つ敬意のあるフィードバックではありません。
@@ -1,28 +1,11 @@
 ---
-title: Kubernetesドキュメントがサポートしているバージョン
-content_type: concept
+title: 利用可能なドキュメントバージョン
+content_type: custom
+layout: supported-versions 
 card:
  name: about
  weight: 10
-  title: ドキュメントがサポートしているバージョン
+  title: 利用可能なドキュメントバージョン
 ---

-<!-- overview -->
-
 本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。
-
-
-
-<!-- body -->
-
-## 現行版
-
-現在のバージョンは[{{< param "version" >}}](/)です。
-
-## 以前のバージョン
-
-{{< versions-other >}}
-
-
-
-
@@ -31,16 +31,18 @@ content_type: concept
 ## CLIリファレンス

 * [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
-    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
 * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。

-## 設定リファレンス
+## コンポーネントリファレンス

 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。
 * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
+  * [kube-schedulerポリシー](/docs/reference/scheduling/policies)
+  * [kube-schedulerプロファイル](/docs/reference/scheduling/profiles)

 ## 設計のドキュメント

@@ -13,7 +13,15 @@ weight: 10

 すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。

-通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。
+クラスターから独立したサービスは通常のユーザーを以下の方法で管理することを想定されています。
+
+- 秘密鍵を配布する管理者
+- KeystoneやGoogle Accountsのようなユーザーストア
+- ユーザー名とパスワードのリストを持つファイル
+
+これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。
+
+APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(例えば、“/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。

 対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。

@@ -236,7 +244,7 @@ Secretは常にbase64でエンコードされるため、これらの値もbase6

 重要なのは、APIサーバーはOAuth2クライアントではなく、ある単一の発行者を信頼するようにしか設定できないことです。これにより、サードパーティーに発行されたクレデンシャルを信頼せずに、Googleのようなパブリックプロバイダーを使用することができます。複数のOAuthクライアントを利用したい管理者は、`azp`クレームをサポートしているプロバイダや、あるクライアントが別のクライアントに代わってトークンを発行できるような仕組みを検討する必要があります。

-KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。
+KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。

 IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。

@@ -319,7 +327,7 @@ Webhook認証は、Bearerトークンを検証するためのフックです。
 * `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです
 * `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です

-設定ファイルは、[kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)のファイル形式を使用します。
+設定ファイルは、[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。
 ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。

 ```yaml
@@ -35,23 +35,18 @@ content_type: concept

 | 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン |
 |---------|---------|-------|-------|-------|
+| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | |
 | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
 | `APIListChunking` | `true` | Beta | 1.9 | |
 | `APIPriorityAndFairness` | `false` | Alpha | 1.17 | |
 | `APIResponseCompression` | `false` | Alpha | 1.7 | |
 | `AppArmor` | `true` | Beta | 1.4 | |
 | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
-| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
-| `BlockVolume` | `true` | Beta | 1.13 | - |
 | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | |
 | `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
 | `CPUManager` | `true` | Beta | 1.10 | |
 | `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 |
 | `CRIContainerLogRotation` | `true` | Beta| 1.11 | |
-| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 |
-| `CSIBlockVolume` | `true` | Beta | 1.14 | |
-| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
-| `CSIDriverRegistry` | `true` | Beta | 1.14 | |
 | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
 | `CSIInlineVolume` | `true` | Beta | 1.16 | - |
 | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
@@ -68,6 +63,7 @@ content_type: concept
 | `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
 | `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | |
+| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
 | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
@@ -80,6 +76,8 @@ content_type: concept
 | `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
 | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | Beta | 1.17 | |
+| `EndpointSlice` | `true` | Beta | 1.18 | |
+| `EndpointSliceProxying` | `false` | Alpha | 1.18 | |
 | `EphemeralContainers` | `false` | Alpha | 1.16 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
@@ -88,9 +86,12 @@ content_type: concept
 | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
-| `EvenPodsSpread` | `false` | Alpha | 1.16 | |
+| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 |
+| `EvenPodsSpread` | `true` | Beta | 1.18 | |
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
+| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | |
 | `HyperVContainer` | `false` | Alpha | 1.10 | |
+| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | |
 | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | Beta | 1.15 | |
 | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
@@ -100,6 +101,8 @@ content_type: concept
 | `MountContainers` | `false` | Alpha | 1.9 | |
 | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
 | `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
+| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 |
+| `PodDisruptionBudget` | `true` | Beta | 1.5 | |
 | `PodOverhead` | `false` | Alpha | 1.16 | - |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
@@ -114,8 +117,12 @@ content_type: concept
 | `SCTPSupport` | `false` | Alpha | 1.12 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
+| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
-| `StartupProbe` | `true` | Beta | 1.17 | |
+| `ServiceTopology` | `false` | Alpha | 1.17 | |
+| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
+| `StartupProbe` | `true` | Beta | 1.18 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
 | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
@@ -125,8 +132,6 @@ content_type: concept
 | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
 | `SupportPodPidsLimit` | `true` | Beta | 1.14 | |
 | `Sysctls` | `true` | Beta | 1.11 | |
-| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
-| `TaintBasedEvictions` | `true` | Beta | 1.13 | |
 | `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
 | `TokenRequest` | `true` | Beta | 1.12 | |
 | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
@@ -160,6 +165,15 @@ content_type: concept
 | `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
 | `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
 | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
+| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
+| `BlockVolume` | `true` | Beta | 1.13 | 1.17 |
+| `BlockVolume` | `true` | GA | 1.18 | - |
+| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 |
+| `CSIBlockVolume` | `true` | Beta | 1.14 | 1.17 |
+| `CSIBlockVolume` | `true` | GA | 1.18 | - |
+| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
+| `CSIDriverRegistry` | `true` | Beta | 1.14 | 1.17 |
+| `CSIDriverRegistry` | `true` | GA | 1.18 | |
 | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
 | `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 |
 | `CSINodeInfo` | `true` | GA | 1.17 | |
@@ -240,9 +254,18 @@ content_type: concept
 | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
 | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
+| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
+| `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 |
+| `TaintBasedEvictions` | `true` | GA | 1.18 | - |
 | `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
 | `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 |
 | `TaintNodesByCondition` | `true` | GA | 1.17 | - |
+| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
+| `VolumePVCDataSource` | `true` | Beta | 1.16 | 1.17 |
+| `VolumePVCDataSource` | `true` | GA | 1.18 | - |
+| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
+| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
+| `VolumeScheduling` | `true` | GA | 1.13 | - |
 | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
@@ -253,6 +276,12 @@ content_type: concept
 | `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
 | `WatchBookmark` | `true` | Beta | 1.16 | 1.16 |
 | `WatchBookmark` | `true` | GA | 1.17 | - |
+| `WindowsGMSA` | `false` | Alpha | 1.14 | 1.15 |
+| `WindowsGMSA` | `true` | Beta | 1.16 | 1.17 |
+| `WindowsGMSA` | `true` | GA | 1.18 | - |
+| `WindowsRunAsUserName` | `false` | Alpha | 1.16 | 1.16 |
+| `WindowsRunAsUserName` | `true` | Beta | 1.17 | 1.17 |
+| `WindowsRunAsUserName` | `true` | GA | 1.18 | - |
 {{< /table >}}

 ## 機能を使用する
@@ -292,7 +321,8 @@ GAになってからさらなる変更を加えることは現実的ではない

 - `Accelerators`: DockerでのNvidia GPUのサポートを有効にします。
 - `AdvancedAuditing`: [高度な監査機能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)を有効にします。
- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を有効にします。
+- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を有効にします。
+- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}の`DataSource`としてカスタムリソースの使用を有効にします。
 - `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。
 - `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。
 `APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
@@ -302,6 +332,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。
 - `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。
+- `ConfigurableFSGroupPolicy`: Podにボリュームをマウントするときに、ユーザーがfsGroupsのボリューム権限変更ポリシーを設定できるようにします。詳細については、[Podのボリューム権限と所有権変更ポリシーの設定](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をご覧ください。
 - `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。
 - `CRIContainerLogRotation`: criコンテナランタイムのコンテナログローテーションを有効にします。
 - `CSIBlockVolume`: 外部CSIボリュームドライバーを有効にしてブロックストレージをサポートします。詳細は[`csi`Rawブロックボリュームのサポート](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)で確認できます。
@@ -309,7 +340,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。
 - `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。
 - `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。ノードにEBS CSIプラグインがインストールおよび設定されていない場合、ツリー内のEBSプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。 CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。
+- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。
 - `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。ノードにAzureDisk CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureDiskプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
 - `CSIMigrationAzureDiskComplete`: Azure-Diskツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Diskツリー内プラグインからAzureDisk CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureDisk機能フラグを有効にし、クラスター内のすべてのノードにAzureDisk CSIプラグインをインストールおよび設定する必要があります。
 - `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。ノードにAzureFile CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureFileプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
@@ -325,9 +356,9 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。
 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。
- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
+- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
+- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
+- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
 - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。
 - `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。
 - `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。
@@ -340,29 +371,33 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)をご覧ください。
 - `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。
 - `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。
- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のpodへの *クリティカル* の注釈を加える設定を有効にします。
+- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のPodへの *クリティカル* の注釈を加える設定を有効にします。
 - `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。
- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。対応するAPIとコントローラーを有効にする必要があります。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
+- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
+- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。
 - `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
 - `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
+- `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。
 - `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
 - `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。
+- `ImmutableEphemeralVolumes`: 安全性とパフォーマンスを向上させるために、個々のSecretとConfigMapが不変となるように指定できるようにします。
 - `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。
 - `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。
- `KubeletPodResources`: kubeletのpodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)で確認できます。
+- `KubeletPodResources`: kubeletのPodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)で確認できます。
 - `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。
- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
+- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
 - `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。
- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはpodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。
+- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはPodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。
 - `NodeDisruptionExclusion`: ノードラベル`node.kubernetes.io/exclude-disruption`の使用を有効にします。これにより、ゾーン障害時にノードが退避するのを防ぎます。
 - `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。
 - `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。
- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。
+- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、Podアフィニティを指定する必要があります。
 - `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。
+- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。
 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
+- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。
@@ -375,26 +410,30 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。
 - `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
 - `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
+- `ServiceAccountIssuerDiscovery`: APIサーバーにてサービスアカウント発行者のOIDC検出エンドポイント（発行者とJWKS URL）を有効にします。詳細については、[Podのサービスアカウント設定](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)をご覧ください。
+- `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。
 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
+- `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。
 - `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
 - `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。
 - `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
 - `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。
- `Sysctls`: 各podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
- `TaintBasedEvictions`: ノードの汚染とpodの許容に基づいてノードからpodを排除できるようにします。。詳細は[汚染と許容](/docs/concepts/configuration/taint-and-toleration/)で確認できます。
- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。
+- `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
+- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。
+- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。
 - `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。
- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したpodへのサービスアカウントのトークンの注入を有効にします。
+- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。
 - `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
 - `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。
 - `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。
 - `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。
 - `VolumeSubpathEnvExpansion`: 環境変数を`subPath`に展開するための`subPathExpr`フィールドを有効にします。
 - `WatchBookmark`: ブックマークイベントの監視サポートを有効にします。
- `WindowsGMSA`: GMSA資格仕様をpodからコンテナランタイムに渡せるようにします。
+- `WindowsGMSA`: GMSA資格仕様をPodからコンテナランタイムに渡せるようにします。
+- `WindowsRunAsUserName`: デフォルト以外のユーザーでWindowsコンテナアプリケーションを実行するためのサポートを有効にします。詳細については、[RunAsUserNameの設定](/docs/tasks/configure-pod-container/configure-runasusername)を参照してください。
 - `WinDSR`: kube-proxyがWindows用のDSRロードバランサーを作成できるようにします。
 - `WinOverlay`: kube-proxyをWindowsのオーバーレイモードで実行できるようにします。

@@ -402,4 +441,3 @@ GAになってからさらなる変更を加えることは現実的ではない
 ## {{% heading "whatsnext" %}}

 * Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。
-
@@ -0,0 +1,18 @@
+---
+title: クラウドコントローラーマネージャー
+id: cloud-controller-manager
+date: 2018-04-12
+full_link: /ja/docs/concepts/architecture/cloud-controller/
+short_description: >
+  サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント
+aka: 
+tags:
+- core-object
+- architecture
+- operation
+---
+ クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
+
+<!--more-->
+
+Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。
@@ -11,3 +11,15 @@ tags:
 - fundamental
 ---
 コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
+
+ <!--more-->
+
+ このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。
+
+ * {{< glossary_tooltip text="etcd" term_id="etcd" >}}
+ * {{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}
+ * {{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}
+ * {{< glossary_tooltip text="コントローラーマネージャー" term_id="kube-controller-manager" >}}
+ * {{< glossary_tooltip text="クラウドコントローラーマネージャー" term_id="cloud-controller-manager" >}}
+
+ これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。
@@ -4,7 +4,7 @@ id: deployment
 date: 2018-04-12
 full_link: /ja/docs/concepts/workloads/controllers/deployment/
 short_description: >
-  複製されたアプリケーションを管理するAPIオブジェクトです。
+  クラスター上の複製されたアプリケーションを管理します。

 aka: 
 tags:
@@ -12,8 +12,9 @@ tags:
 - core-object
 - workload
 ---
- 複製されたアプリケーションを管理するAPIオブジェクトです。
+ 複製されたアプリケーションを管理するAPIオブジェクトで、通常はステートレスなPodを実行します。

 <!--more--> 

-各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。
+各レプリカは{{< glossary_tooltip text="Pod" term_id="pod" >}}で表され、Podはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。
+ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。
@@ -2,7 +2,7 @@
 title: APIサーバー
 id: kube-apiserver
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-apiserver/
+full_link: /docs/concepts/overview/components/#kube-apiserver
 short_description: >
  Kubernetes APIを提供するコントロールプレーンのコンポーネントです。

@@ -15,3 +15,4 @@ tags:
 <!--more--> 

 ワーカーノードは、クラスターに応じてVMまたは物理マシンの場合があります。{{< glossary_tooltip text="Pod" term_id="pod" >}}の実行に必要なローカルデーモンまたはサービスがあり、コントロールプレーンによって管理されます。ノード上のデーモンには、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}、および{{< glossary_tooltip term_id="docker" >}}などの{{< glossary_tooltip text="CRI" term_id="cri" >}}を実装するコンテナランタイムが含まれます。
+Kubernetesの初期バージョンでは、ノードは"Minion"と呼ばれていました。
@@ -14,4 +14,4 @@ tags:

 <!--more--> 

-プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/docs/concepts/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/docs/concepts/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。
+プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。
@@ -4,7 +4,7 @@ id: statefulset
 date: 2018-04-12
 full_link: /ja/docs/concepts/workloads/controllers/statefulset/
 short_description: >
-  StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。
+  StatefulSetはDeploymentとPodのセットのスケーリングを管理し、永続化ストレージと各Podの永続的な識別子を備えています。

 aka: 
 tags:
@@ -20,5 +20,4 @@ StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}の

 {{< glossary_tooltip term_id="deployment" >}}のように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。

-StatefulSetは他のコントローラーと同様のパターンで動作します。ユーザーはStatefulSet*オブジェクト* の理想的な状態を定義し、StatefulSet*コントローラー* は現在の状態から、理想状態になるために必要なアップデートを行います。
-
+ワークロードに永続性を持たせるためにストレージボリュームを使いたい場合は、解決策の1つとしてStatefulSetが利用できます。StatefulSet内の個々のPodは障害の影響を受けやすいですが、永続化したPodの識別子は既存のボリュームと障害によって置換された新しいPodの紐付けを簡単にします。
@@ -4,17 +4,17 @@ id: volume
 date: 2018-04-12
 full_link: /docs/concepts/storage/volumes/
 short_description: >
-  Pod内のコンテナからアクセス可能なデータを含むディレクトリです。
+  データを格納するディレクトリで、Pod内のコンテナからアクセス可能です。

-aka: 
+aka:
 tags:
 - core-object
 - fundamental
 ---
- {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。
+ データを格納するディレクトリで、{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。

-<!--more--> 
+<!--more-->

-Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。
+Kubernetesボリュームはボリュームを含んだPodが存在する限り有効です。そのため、ボリュームはPod内で実行されるどのコンテナよりも長く存在し、コンテナが再起動してもボリューム内のデータは維持されます。

-詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。
+詳しくは[ストレージ](/ja/docs/concepts/storage/)をご覧ください。
@@ -8,16 +8,10 @@ card:

 <!-- overview -->

-[Kubectl概要](/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。
-
-このページは`kubectl`コマンドの概要です。
-
-
+このページには、一般的によく使われる`kubectl`コマンドとフラグのリストが含まれています。

 <!-- body -->

-# kubectl - チートシート
-
 ## Kubectlコマンドの補完

 ### BASH
@@ -37,14 +31,14 @@ complete -F __start_kubectl k
 ### ZSH

 ```bash
-source <(kubectl completion zsh)  # 現在のzshシェルでコマンド補完を設定します
+source <(kubectl completion zsh)  # 現在のzshシェルにコマンド補完を設定します
 echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
 ```

 ## Kubectlコンテキストの設定

 `kubectl`がどのKubernetesクラスターと通信するかを設定します。
-設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。
+設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。

 ```bash
 kubectl config view # マージされたkubeconfigの設定を表示します。
@@ -63,10 +57,10 @@ kubectl config get-contexts                          # コンテキストのリ
 kubectl config current-context                       # 現在のコンテキストを表示します
 kubectl config use-context my-cluster-name           # デフォルトのコンテキストをmy-cluster-nameに設定します

-# basic認証をサポートする新たなクラスターをkubeconfigに追加します
+# basic認証をサポートする新たなユーザーをkubeconfigに追加します
 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

-# 現在のコンテキストでkubectlのサブコマンドのネームスペースを永続的に変更します
+# 現在のコンテキストでkubectlのサブコマンドの名前空間を永続的に変更します
 kubectl config set-context --current --namespace=ggckad-s2

 # 特定のユーザー名と名前空間を使用してコンテキストを設定します
@@ -76,7 +70,7 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
 kubectl config unset users.foo    # ユーザーfooを削除します
 ```

-## Apply
+## Kubectl Apply

 `apply`はKubernetesリソースを定義するファイルを通じてアプリケーションを管理します。`kubectl apply`を実行して、クラスター内のリソースを作成および更新します。これは、本番環境でKubernetesアプリケーションを管理する推奨方法です。
 詳しくは[Kubectl Book](https://kubectl.docs.kubernetes.io)をご覧ください。
@@ -141,18 +135,18 @@ EOF

 ```bash
 # Getコマンドで基本的な情報を確認します
-kubectl get services                          # 現在のネームスペース上にあるすべてのサービスのリストを表示します
-kubectl get pods --all-namespaces             # すべてのネームスペース上にあるすべてのPodのリストを表示します
-kubectl get pods -o wide                      # 現在のネームスペース上にあるすべてのPodについてより詳細なリストを表示します
+kubectl get services                          # 現在の名前空間上にあるすべてのサービスのリストを表示します
+kubectl get pods --all-namespaces             # すべての名前空間上にあるすべてのPodのリストを表示します
+kubectl get pods -o wide                      # 現在の名前空間上にあるすべてのPodについてより詳細なリストを表示します
 kubectl get deployment my-dep                 # 特定のDeploymentを表示します
-kubectl get pods                              # 現在のネームスペース上にあるすべてのPodのリストを表示します
+kubectl get pods                              # 現在の名前空間上にあるすべてのPodのリストを表示します
 kubectl get pod my-pod -o yaml                # PodのYAMLを表示します

 # Describeコマンドで詳細な情報を確認します
 kubectl describe nodes my-node
 kubectl describe pods my-pod

-# 名前順にソートしたリストを表示します
+# 名前順にソートしたServiceのリストを表示します
 kubectl get services --sort-by=.metadata.name

 # Restartカウント順にPodのリストを表示します
@@ -165,33 +159,33 @@ kubectl get pv --sort-by=.spec.capacity.storage
 kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

+# 'ca.crt'のようなピリオドが含まれるキーの値を取得します
+kubectl get configmap myconfig \
+  -o jsonpath='{.data.ca\.crt}'
+
 # すべてのワーカーノードを取得します（セレクターを使用して、
 # 「node-role.kubernetes.io/master」という名前のラベルを持つ結果を除外します）
 kubectl get node --selector='!node-role.kubernetes.io/master'

-# 現在のネームスペースでrunning状態のPodをリストを表示します
+# 現在の名前空間でrunning状態のPodのリストを表示します
 kubectl get pods --field-selector=status.phase=Running

-# すべてのノードのExternal IPをリストを表示します
+# すべてのノードのExternal IPのリストを表示します
 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

 # 特定のRCに属するPodの名前のリストを表示します
 # `jq`コマンドは複雑なjsonpathを変換する場合に便利であり、https://stedolan.github.io/jq/で見つけることが可能です
-
 sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
 echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

 # すべてのPod(またはラベル付けをサポートする他のKubernetesオブジェクト)のラベルのリストを表示します
-
 kubectl get pods --show-labels

 # どのノードがready状態か確認します
-
 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

 # Podで現在使用中のSecretをすべて表示します
-
 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

 # すべてのPodのInitContainerのコンテナIDのリストを表示します
@@ -199,17 +193,21 @@ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secre
 kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3

 # タイムスタンプでソートされたEventのリストを表示します
-
 kubectl get events --sort-by=.metadata.creationTimestamp

 # クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。
 kubectl diff -f ./my-manifest.yaml
+
+# Nodeから返されるすべてのキーをピリオド区切りの階層表記で生成します。
+# 複雑にネストされたJSON構造をもつキーを指定したい時に便利です
+kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+
+# Pod等から返されるすべてのキーをピリオド区切り階層表記で生成します。
+kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
 ```

 ## リソースのアップデート

-version 1.11で`rolling-update`は廃止されました、代わりに`rollout`コマンドをお使いください(詳しくはこちらをご覧ください [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))。
-
 ```bash
 kubectl set image deployment/frontend www=image:v2               # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします
 kubectl rollout history deployment/frontend                      # frontend Deploymentの改訂履歴を確認します
@@ -219,11 +217,6 @@ kubectl rollout status -w deployment/frontend                    # frontend Depl
 kubectl rollout restart deployment/frontend                      # frontend Deployment を再起動します


-# これらのコマンドは1.11から廃止されました
-kubectl rolling-update frontend-v1 -f frontend-v2.json           # (廃止) frontend-v1 Podをローリングアップデートします
-kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (廃止) リソース名とイメージを変更します
-kubectl rolling-update frontend --image=image:v2                 # (廃止) frontendのイメージを変更します
-kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (廃止) 現在実行中のローリングアップデートを中止します
 cat pod.json | kubectl replace -f -                              # 標準入力から渡されたJSONに基づいてPodを置き換えます

 # リソースを強制的に削除してから再生成し、置き換えます。サービスの停止が発生します
@@ -260,7 +253,6 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1",
 ```

 ## リソースの編集
-
 任意のエディターでAPIリソースを編集します。

 ```bash
@@ -301,10 +293,10 @@ kubectl logs -f my-pod                              # Podのログをストリ
 kubectl logs -f my-pod -c my-container              # 複数のコンテナがあるPodで、特定のコンテナのログをストリームで確認します(標準出力)
 kubectl logs -f -l name=myLabel --all-containers    # name-myLabelラベルを持つすべてのコンテナのログをストリームで確認します(標準出力)
 kubectl run -i --tty busybox --image=busybox -- sh  # Podをインタラクティブシェルとして実行します
-kubectl run nginx --image=nginx --restart=Never -n 
-mynamespace                                         # 特定のネームスペースでnginx Podを実行します
-kubectl run nginx --image=nginx --restart=Never     # nginx Podを実行し、マニフェストファイルををpod.yamlという名前で書き込みます
--dry-run -o yaml > pod.yaml
+kubectl run nginx --image=nginx -n 
+mynamespace                                         # 特定の名前空間でnginx Podを実行します
+kubectl run nginx --image=nginx                     # nginx Podを実行し、マニフェストファイルをpod.yamlという名前で書き込みます
+--dry-run=client -o yaml > pod.yaml
 kubectl attach my-pod -i                            # 実行中のコンテナに接続します
 kubectl port-forward my-pod 5000:6000               # ローカルマシンのポート5000を、my-podのポート6000に転送します
 kubectl exec my-pod -- ls /                         # 既存のPodでコマンドを実行(単一コンテナの場合)
@@ -315,9 +307,9 @@ kubectl top pod POD_NAME --containers               # 特定のPodとそのコ
 ## ノードおよびクラスターとの対話処理

 ```bash
-kubectl cordon my-node                                                # my-nodeにスケーリングされないように設定します
+kubectl cordon my-node                                                # my-nodeをスケーリングされないように設定します
 kubectl drain my-node                                                 # メンテナンスの準備としてmy-nodeで動作中のPodを空にします
-kubectl uncordon my-node                                              # my-nodeにスケーリングされるように設定します
+kubectl uncordon my-node                                              # my-nodeをスケーリングされるように設定します
 kubectl top node my-node                                              # 特定のノードのメトリクスを表示します
 kubectl cluster-info                                                  # Kubernetesクラスターのマスターとサービスのアドレスを表示します
 kubectl cluster-info dump                                             # 現在のクラスター状態を標準出力にダンプします
@@ -329,7 +321,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule

 ### リソースタイプ

-サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
+サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/ja/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。

 ```bash
 kubectl api-resources
@@ -352,7 +344,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの

 出力フォーマット | 説明
 ---------------- | -----------
-`-o=custom-columns=<spec>` | カスタムカラムを使用してコンマ区切りのテーブルを表示します
+`-o=custom-columns=<spec>` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します
 `-o=custom-columns-file=<filename>` | `<filename>`ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します
 `-o=json`     | JSON形式のAPIオブジェクトを出力します
 `-o=jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
@@ -361,13 +353,28 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
 `-o=wide`     | 追加の情報を含むプレーンテキスト形式で出力します。Podの場合、Node名が含まれます。
 `-o=yaml`     | YAML形式のAPIオブジェクトを出力します

+`-o=custom-columns`を使用したサンプル:
+
+```bash
+# クラスター内で実行中のすべてのイメージ名を表示する
+kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
+
+# "k8s.gcr.io/coredns:1.6.2"を除いたすべてのイメージ名を表示する
+kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
+
+# 名前に関係なくmetadata以下のすべてのフィールドを表示する
+kubectl get pods -A -o=custom-columns='DATA:metadata.*'
+```
+
+kubectlに関するより多くのサンプルは[カスタムカラムのリファレンス](/ja/docs/reference/kubectl/overview/#custom-columns)を参照してください。
+
 ### Kubectlのログレベルとデバッグ
 kubectlのログレベルは、レベルを表す整数が後に続く`-v`または`--v`フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、[こちら](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)で説明します。

 ログレベル    | 説明
 --------------| -----------
 `--v=0`       | これは、クラスターオペレーターにログレベルが0であることを"常に"見えるようにするために役立ちます
-`--v=1`       | 冗長性が必要ない場合は、妥当なデフォルトのログレベルです
+`--v=1`       | ログレベルが必要ない場合に、妥当なデフォルトのログレベルです
 `--v=2`       | サービスに関する重要な定常状態情報と、システムの重要な変更に関連する可能性がある重要なログメッセージを表示します。 これは、ほとんどのシステムで推奨されるデフォルトのログレベルです。
 `--v=3`       | 変更に関するより詳細なログレベルを表示します
 `--v=4`       | デバックにむいたログレベルで表示します
@@ -380,13 +387,10 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また

 ## {{% heading "whatsnext" %}}

-
-* kubectlについてより深く学びたい方は[kubectl概要](/docs/reference/kubectl/overview/)をご覧ください。
+* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)や[JsonPath](/docs/reference/kubectl/jsonpath)をご覧ください。

 * オプションについては[kubectl](/docs/reference/kubectl/kubectl/) optionsをご覧ください。
-
+ 
 * また[kubectlの利用パターン](/docs/reference/kubectl/conventions/)では再利用可能なスクリプトでkubectlを利用する方法を学べます。

 * コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
-
-
@@ -8,9 +8,9 @@ card:
 ---

 <!-- overview -->
-`kubectl`は、Kubernetesクラスターを制御するためのコマンドラインツールです。`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
+`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
+この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。

-この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/kubectl/install/)をご覧ください。


 <!-- body -->
@@ -29,11 +29,11 @@ kubectl [command] [TYPE] [NAME] [flags]

 * `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。

-      ```shell
-      kubectl get pod pod1
-      kubectl get pods pod1
-      kubectl get po pod1
-      ```
+   ```shell
+   kubectl get pod pod1
+   kubectl get pods pod1
+   kubectl get po pod1
+   ```

 * `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。

@@ -49,7 +49,7 @@ kubectl [command] [TYPE] [NAME] [flags]

   * リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。

-      * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/docs/concepts/configuration/overview/#general-configuration-tips)。<br/>
+      * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。<br/>
     例: `kubectl get pod -f ./pod.yaml`

 * `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。<br/>
@@ -64,42 +64,59 @@ kubectl [command] [TYPE] [NAME] [flags]

 以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。

-操作       | 構文    |       説明
+操作&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;       | 構文    |       説明
 -------------------- | -------------------- | --------------------
+`alpha`| `kubectl alpha SUBCOMMAND [flags]` | アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。
 `annotate`    | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのアノテーションを、追加または更新します。
-`api-versions`    | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを表示します。
+`api-resources`    | `kubectl api-resources [flags]` | 利用可能なAPIリソースを一覧表示します。
+`api-versions`    | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを一覧表示します。
 `apply`            | `kubectl apply -f FILENAME [flags]`| ファイルまたは標準出力から、リソースの設定変更を適用します。
 `attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 実行中のコンテナにアタッチして、出力ストリームを表示するか、コンテナ(標準入力)と対話します。
+`auth`    | `kubectl auth [flags] [options]` | 認可を検査します。
 `autoscale`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | ReplicationControllerで管理されているPodのセットを、自動的にスケールします。
+`certificate`    | `kubectl certificate SUBCOMMAND [options]` | 証明書のリソースを変更します。
 `cluster-info`    | `kubectl cluster-info [flags]` | クラスター内のマスターとサービスに関するエンドポイント情報を表示します。
+`completion`    | `kubectl completion SHELL [options]` | 指定されたシェル(bashまたはzsh)のシェル補完コードを出力します。
 `config`        | `kubectl config SUBCOMMAND [flags]` | kubeconfigファイルを変更します。詳細は、個々のサブコマンドを参照してください。
+`convert`    | `kubectl convert -f FILENAME [options]` | 異なるAPIバージョン間で設定ファイルを変換します。YAMLとJSONに対応しています。
+`cordon`    | `kubectl cordon NODE [options]` | Nodeをスケジュール不可に設定します。
+`cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | コンテナとの間でファイルやディレクトリをコピーします。
 `create`        | `kubectl create -f FILENAME [flags]` | ファイルまたは標準出力から、1つ以上のリソースを作成します。
 `delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。
 `describe`    | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 1つ以上のリソースの詳細な状態を表示します。
 `diff`        | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。
+`drain`    | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。
 `edit`        | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。
 `exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。
 `explain`    | `kubectl explain  [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。
 `expose`        | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。
 `get`        | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 1つ以上のリソースを表示します。
+`kustomize`    | `kubectl kustomize <dir> [flags] [options]` | kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath，またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。
 `label`        | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのラベルを、追加または更新します。
 `logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Pod内のコンテナのログを表示します。
+`options`    | `kubectl options` | すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。
 `patch`        | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。
-`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のリーカルポートを、Podに転送します。
+`plugin`    | `kubectl plugin [flags] [options]` | プラグインと対話するためのユーティリティを提供します。
+`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のローカルポートを、Podに転送します。
 `proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。
 `replace`        | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。
-`rolling-update`    | <code>kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE &#124; -f NEW_CONTROLLER_SPEC) [flags]</code> | 指定されたReplicationControllerとそのPodを徐々に置き換えることで、ローリングアップデートを実行します。
-`run`        | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=server|client|none] [--overrides=inline-json] [flags]` | 指定したイメージを、クラスタ上で実行します。
-`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | していしたReplicationControllerのサイズを更新します。
+`rollout`    | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
+`run`        | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスタ上で実行します。
+`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 指定したReplicationControllerのサイズを更新します。
+`set`    | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。
+`taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。
+`top`    | `kubectl top [flags] [options]` | リソース(CPU/メモリー/ストレージ)の使用量を表示します。
+`uncordon`    | `kubectl uncordon NODE [options]` | Nodeをスケジュール可に設定します。
 `version`        | `kubectl version [--client] [flags]` | クライアントとサーバーで実行中のKubernetesのバージョンを表示します。
+`wait`    | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 実験中の機能: 1つ以上のリソースが特定の状態になるまで待ちます。

-コマンド操作の詳細については、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントを参照してください。
+コマンド操作について詳しく知りたい場合は、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。

 ## リソースタイプ {#resource-types}

 以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。

-(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確です。)
+(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。)

 | リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 |
 |---|---|---|---|---|
@@ -155,7 +172,7 @@ kubectl [command] [TYPE] [NAME] [flags]

 ## 出力オプション

-ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントをご覧ください。
+ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。

 ### 出力のフォーマット

@@ -188,13 +205,12 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
 kubectl get pod web-pod-13je7 -o yaml
 ```

-各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントを参照してください。
+各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。

 #### カスタムカラム {#custom-columns}

 カスタムカラムを定義して、必要な詳細のみをテーブルに出力するには、`custom-columns`オプションを使います。カスタムカラムをインラインで定義するか、`-o custom-columns=<spec>`または`-o custom-columns-file=<filename>`のようにテンプレートファイルを使用するかを選択できます。

-
 ##### 例

 インラインで定義する例は、以下の通りです。
@@ -215,10 +231,9 @@ kubectl get pods <pod-name> -o custom-columns-file=template.txt
 NAME          RSRC
 metadata.name metadata.resourceVersion
 ```
-
 どちらのコマンドを実行した場合でも、以下の結果を得ます。

-```shell
+```
 NAME           RSRC
 submit-queue   610995
 ```
@@ -229,22 +244,21 @@ submit-queue   610995
 つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。
 これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。

-この機能は、`kubectl`1.11以降ではデフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。
+この機能は、デフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。

 ##### 例

 Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。

-
 ```shell
 kubectl get pods <pod-name> --server-print=false
 ```

 以下のように出力されます。

-```shell
-NAME       READY     STATUS              RESTARTS   AGE
-pod-name   1/1       Running             0          1m
+```
+NAME       AGE
+pod-name   1m
 ```

 ### オブジェクトリストのソート
@@ -315,6 +329,7 @@ kubectl describe pods/<pod-name>

 # ReplicationController <rc-name>が管理しているすべてのPodの詳細を表示します。
 # ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。
+kubectl describe pods <rc-name>

 # すべてのPodの詳細を表示します。
 kubectl describe pods
@@ -330,8 +345,8 @@ kubectl describe pods
 # pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。
 kubectl delete -f pod.yaml

-# name=<label-name>というラベルを持つPodとServiceをすべて削除します。
-kubectl delete pods,services -l name=<label-name>
+# '<label-key>=<label-value>'というラベルを持つPodとServiceをすべて削除します。
+kubectl delete pods,services -l <label-key>=<label-value>

 # 初期化されていないPodを含む、すべてのPodを削除します。
 kubectl delete pods --all
@@ -341,14 +356,13 @@ kubectl delete pods --all

 ```shell
 # Pod <pod-name>から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。
-kubectl exec <pod-name> date
+kubectl exec <pod-name> -- date

 # Pod <pod-name>のコンテナ <container-name>から、'date'を実行している時の出力を取得します。
-kubectl exec <pod-name> -c <container-name> date
+kubectl exec <pod-name> -c <container-name> -- date

 # インタラクティブな TTY を取得し、Pod <pod-name>から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。
-Get an interactive TTY and run /bin/bash from pod <pod-name>. By default, output is from the first container.
-kubectl exec -ti <pod-name> /bin/bash
+kubectl exec -ti <pod-name> -- /bin/bash
 ```

 `kubectl logs` - Pod内のコンテナのログを表示します。
@@ -379,16 +393,20 @@ cat service.yaml | kubectl diff -f -
 # 任意の言語でシンプルなプラグインを作成し、生成される実行可能なファイルに
 # プレフィックス"kubectl-"で始まる名前を付けます。
 cat ./kubectl-hello
-#!/bin/bash
+```
+```shell
+#!/bin/sh

 # このプラグインは、"hello world"という単語を表示します。
 echo "hello world"
-
-# プラグインを書いたら、実行可能にします。
-sudo chmod +x ./kubectl-hello
+```
+プラグインを書いたら、実行可能にします。
+```bash
+chmod a+x ./kubectl-hello

 # さらに、PATH内の場所に移動させます。
 sudo mv ./kubectl-hello /usr/local/bin
+sudo chown root:root /usr/local/bin

 # これでkubectlプラグインを作成し、"インストール"できました。
 # 通常のコマンドのようにkubectlから呼び出すことで、プラグインを使用できます。
@@ -399,14 +417,16 @@ hello world
 ```

 ```shell
-# 単純にPATHから削除することで、プラグインを"アンインストール"できます。
+# 配置したPATHのフォルダから削除することで、プラグインを"アンインストール"できます。
 sudo rm /usr/local/bin/kubectl-hello
 ```

-`kubectl`で利用可能なプラグインをすべて表示するには、以下のように`kubectl plugin list`サブコマンドを使用します。
+`kubectl`で利用可能なプラグインをすべて表示するには、`kubectl plugin list`サブコマンドを使用してください。
+
 ```shell
 kubectl plugin list
 ```
+出力は以下のようになります。
 ```
 The following kubectl-compatible plugins are available:

@@ -414,9 +434,10 @@ The following kubectl-compatible plugins are available:
 /usr/local/bin/kubectl-foo
 /usr/local/bin/kubectl-bar
 ```
+
+`kubectl plugin list`コマンドは、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。例えば、以下のようになります。
 ```shell
-# このコマンドで、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。
-sudo chmod -x /usr/local/bin/kubectl-foo
+sudo chmod -x /usr/local/bin/kubectl-foo # 実行権限を削除します。
 kubectl plugin list
 ```
 ```
@@ -434,14 +455,19 @@ error: one plugin warning was found

 ```shell
 cat ./kubectl-whoami
+```
+次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。
+The next few examples assume that you already made `kubectl-whoami` have
+the following contents:
+```shell
 #!/bin/bash

 # このプラグインは、`kubectl config`コマンドを使って
 # 現在選択されているコンテキストに基づいて、現在のユーザーに関する情報を提供します。
-kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}'
+kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
 ```

-上記のプラグインを実行すると、以下のように、KUBECONFIGファイルの中で現在選択されているユーザーを含む出力が得られます。
+上記のコマンドを実行すると、KUBECONFIGファイル内のカレントコンテキストのユーザーを含んだ出力を得られます。

 ```shell
 # ファイルを実行可能にします。
@@ -454,10 +480,8 @@ kubectl whoami
 Current user: plugins-user
 ```

-プラグインについてより詳しく知りたい場合は、[example cli plugin](https://github.com/kubernetes/sample-cli-plugin)をご覧ください。
-
-
 ## {{% heading "whatsnext" %}}

-[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。
+* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。

+* プラグインについてより詳しく知りたい場合は, [example cli plugin](https://github.com/kubernetes/sample-cli-plugin)を御覧ください。
@@ -17,12 +17,11 @@ card:
 <!-- overview -->

 このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。
+Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。

-各Kubernetesソリューションはそれぞれ、メンテナンス性、セキュリティ、管理、利用可能なリソース、クラスターの運用に専門知識が必要など、異なる要件があります。

-Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションを選ぶことも可能です。
+Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。

-簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。



@@ -30,25 +29,14 @@ Kubernetesクラスタはローカルマシン、クラウド、オンプレの

 ## 環境について学ぶ

-Kubernetesについて学んでいる場合、Dockerベースのソリューションを使いましょう。これらはKubernetesコミュニティにサポートされていたり、あるいはKubernetesクラスターをローカル環境にセットアップするエコシステムを持っていたりします。
+Kubernetesについて学んでいる場合、Kubernetesコミュニティにサポートされているツールや、Kubernetesクラスターをローカルマシンにセットアップするエコシステム内のツールを使いましょう。

-{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}}
-
-|コミュニティ           |エコシステム     |
-| ------------       | --------     |
-| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
-| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
-|                     | [Minishift](https://docs.okd.io/latest/minishift/)|
-|                     | [MicroK8s](https://microk8s.io/)|
-|                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
-|                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
-|                     | [k3s](https://k3s.io)|


 ## 本番環境

 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。

-[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。
+[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)を参照してください。


@@ -26,10 +26,10 @@ Kubernetesは下記の用途でPKIを必要とします：
 * APIサーバーがetcdと通信するためのクライアント証明書
 * controller managerがAPIサーバーと通信するためのクライアント証明書およびkubeconfig
 * スケジューラーがAPIサーバーと通信するためのクライアント証明書およびkubeconfig
-* [front-proxy][proxy]用のクライアント証明書およびサーバー証明書
+* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用のクライアント証明書およびサーバー証明書

 {{< note >}}
-`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。
+`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/extend-kubernetes/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。
 {{< /note >}}

 さらに、etcdはクライアントおよびピア間の認証に相互TLS通信を実装しています。
@@ -52,7 +52,7 @@ kubeadmで証明書を生成したくない場合は、下記の方法のいず
 |------------------------|---------------------------|----------------------------------|
 | ca.crt,key             | kubernetes-ca             | Kubernetes全体の認証局　　　        |
 | etcd/ca.crt,key        | etcd-ca                   | etcd用　　　　　　　　　　　　　　   |
-| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy]用　　　 |
+| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用　　　 |

 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。

@@ -72,9 +72,9 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全
 | kube-apiserver-kubelet-client | kubernetes-ca             | system:masters | client                                 |                                             |
 | front-proxy-client            | kubernetes-front-proxy-ca |                | client                                 |                                             |

-[1]: クラスターに接続するIPおよびDNS名( [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`)
+[1]: クラスターに接続するIPおよびDNS名( [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`)

-`kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます:
+`kind`は下記の[x509の鍵用途](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)のタイプにマッピングされます:

 | 種類   | 鍵の用途  　　　                                                                     |
 |--------|---------------------------------------------------------------------------------|
@@ -96,7 +96,8 @@ kubeadm利用者のみ：

 ### 証明書のパス

-証明書は推奨パスに配置するべきです([kubeadm][kubeadm]を使用する場合と同様)。パスは場所に関係なく与えられた引数で特定されます。
+証明書は推奨パスに配置するべきです([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様)。
+パスは場所に関係なく与えられた引数で特定されます。

 | デフォルトCN                   | 鍵の推奨パス        　　　　　　 | 証明書の推奨パス    　　　　　   | コマンド        | 鍵を指定する引数               | 証明書を指定する引数                          |
 |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
@@ -157,8 +158,5 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 | controller-manager.conf | kube-controller-manager | `manifests/kube-controller-manager.yaml`のマニフェストファイルに追記する必要があります。 |
 | scheduler.conf          | kube-scheduler          | `manifests/kube-scheduler.yaml`のマニフェストファイルに追記する必要があります。          |

-[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
-[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
-[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/


@@ -12,15 +12,12 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
 * No more than 300000 total containers
 * No more than 100 pods per node

-<br>
-
-{{< toc >}}

 ## 構築

 A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).

-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).

 Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.

@@ -80,7 +77,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c

 ### アドオンのリソース

-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)).

 For example:

@@ -94,28 +91,26 @@ For example:
        memory: 200Mi
 ```

-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.

 To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:

 * Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
-  * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
-  * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+  * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+  * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+  * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
 * Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
-  * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+  * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
 * Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
-  * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+  * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+  * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)

 Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
 and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
 out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).

-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
-
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
-We welcome PRs that implement those features.
+For directions on how to detect if addon containers are hitting resource limits, see the
+[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).

 ### 少数のノードの起動の失敗を許容する

@@ -6,101 +6,57 @@ content_type: concept

 <!-- overview -->

-This page describes how to run a cluster in multiple zones.
-
+このページでは、複数のゾーンでクラスタを実行する方法について説明します。


 <!-- body -->

-## 始めに
+## はじめに

-Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
-(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
-This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
-nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
-Full Cluster Federation allows combining separate
-Kubernetes clusters running in different regions or cloud providers
-(or on-premises data centers).  However, many
-users simply want to run a more available Kubernetes cluster in multiple zones
-of their single cloud provider, and this is what the multizone support in 1.2 allows
-(this previously went by the nickname "Ubernetes Lite").
+Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"、AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
+これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
+完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。

-Multizone support is deliberately limited: a single Kubernetes cluster can run
-in multiple zones, but only within the same region (and cloud provider).  Only
-GCE and AWS are currently supported automatically (though it is easy to
-add similar support for other clouds or even bare metal, by simply arranging
-for the appropriate labels to be added to nodes and volumes).
+マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。


 ## 機能性

-When nodes are started, the kubelet automatically adds labels to them with
-zone information.
+ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。

-Kubernetes will automatically spread the pods in a replication controller
-or service across nodes in a single-zone cluster (to reduce the impact of
-failures.)  With multiple-zone clusters, this spreading behavior is
-extended across zones (to reduce the impact of zone failures.)  (This is
-achieved via `SelectorSpreadPriority`).  This is a best-effort
-placement, and so if the zones in your cluster are heterogeneous
-(e.g. different numbers of nodes, different types of nodes, or
-different pod resource requirements), this might prevent perfectly
-even spreading of your pods across zones. If desired, you can use
-homogeneous zones (same number and types of nodes) to reduce the
-probability of unequal spreading.
+Kubernetesはレプリケーションコントローラーやサービス内のPodをシングルゾーンクラスターにおけるノードにデプロイします(障害の影響を減らすため)。マルチゾーンクラスターでは、このデプロイの挙動はゾーンを跨いで拡張されます(障害の影響を減らすため)(これは`SelectorSpreadPriority`によって可能になります)。これはベストエフォートな配置であり、つまりもしクラスターのゾーンが異種である(例:異なる数のノード、異なるタイプのノードや異なるPodのリソース要件)場合、これはゾーンを跨いだPodのデプロイを完璧に防ぐことができます。必要であれば、同種のゾーン(同一の数及びタイプのノード)を利用して不平等なデプロイの可能性を減らすことができます。

-When persistent volumes are created, the `PersistentVolumeLabel`
-admission controller automatically adds zone labels to them.  The scheduler (via the
-`VolumeZonePredicate` predicate) will then ensure that pods that claim a
-given volume are only placed into the same zone as that volume, as volumes
-cannot be attached across zones.
+永続ボリュームが作成されると、`PersistentVolumeLabel`アドミッションコントローラーがそれらにゾーンラベルを付与します。スケジューラーは`VolumeZonePredicate`を通じて与えられたボリュームを請求するPodがそのボリュームと同じゾーンにのみ配置されることを保証します、これはボリュームはゾーンを跨いでアタッチすることができないためです。

 ## 制限

-There are some important limitations of the multizone support:
+マルチゾーンサポートにはいくつか重要な制限があります:

-* We assume that the different zones are located close to each other in the
-network, so we don't perform any zone-aware routing.  In particular, traffic
-that goes via services might cross zones (even if some pods backing that service
-exist in the same zone as the client), and this may incur additional latency and cost.
+* 異なるゾーンはネットワーク内においてお互いに近接して位置していることが想定されているため、いかなるzone-aware routingも行われません。特に、トラフィックはゾーンを跨いだサービスを通じて行き来するため(サービスをサポートするいくつかのPodがクライアントと同じゾーンに存在していても)、これは追加のレイテンシやコストを生むかもしれません。

-* Volume zone-affinity will only work with a `PersistentVolume`, and will not
-work if you directly specify an EBS volume in the pod spec (for example).
+* Volume zone-affinityは`PersistentVolume`と共に動作し、例えばPodのスペックにおいてEBSボリュームを直接指定しても動作しません。

-* Clusters cannot span clouds or regions (this functionality will require full
-federation support).
+* クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。

-* Although your nodes are in multiple zones, kube-up currently builds
-a single master node by default.  While services are highly
-available and can tolerate the loss of a zone, the control plane is
-located in a single zone.  Users that want a highly available control
-plane should follow the [high availability](/docs/admin/high-availability) instructions.
+*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに配置されます。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。

 ### ボリュームの制限
-The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).

-* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
-  pod affinity or anti-affinity policies.
+以下の制限は[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode)に記載されています。

-* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
-  may not provide a uniform distribution of storage across zones.
+* 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。

-* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
-  needs to be configured for a specific single zone, or the PVs need to be
-  statically provisioned in a specific zone. Another workaround is to use a
-  StatefulSet, which will ensure that all the volumes for a replica are
-  provisioned in the same zone.
+* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。
+
+* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の1つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。

 ## 全体の流れ

-We're now going to walk through setting up and using a multi-zone
-cluster on both GCE & AWS.  To do so, you bring up a full cluster
-(specifying `MULTIZONE=true`), and then you add nodes in additional zones
-by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
+GCEとAWSの両方にマルチゾーンのクラスターをセットアップし使用する手順について説明します。そのために、フルクラスターを用意し(`MULTIZONE=true`と指定する)、`kube-up`を再び実行して追加のゾーンにノードを追加します(`KUBE_USE_EXISTING_MASTER=true`と指定する)。

 ### クラスターの立ち上げ

-Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
+通常と同様にクラスターを作成します、しかし複数のゾーンを管理するためにMULTIZONEをクラスターに設定します。ノードをus-central1-aに作成します。

 GCE:

@@ -114,21 +70,20 @@ AWS:
 curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
 ```

-This step brings up a cluster as normal, still running in a single zone
-(but `MULTIZONE=true` has enabled multi-zone capabilities).
+このステップは通常と同様にクラスターを立ち上げ、1つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。
+

 ### ノードはラベルが付与される

-View the nodes; you can see that they are labeled with zone information.
-They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far.  The
-labels are `failure-domain.beta.kubernetes.io/region` for the region,
-and `failure-domain.beta.kubernetes.io/zone` for the zone:
+ノードを見てください。それらがゾーン情報と共にラベルされているのが分かります。
+それら全ては今のところ`us-central1-a` (GCE)あるいは`us-west-2a` (AWS)にあります。ラベルは`failure-domain.beta.kubernetes.io/region`がリージョンに、`failure-domain.beta.kubernetes.io/zone`はゾーンに付けられています:
+

 ```shell
 kubectl get nodes --show-labels
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
@@ -140,11 +95,8 @@ kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0

 ### 2つ目のゾーンにさらにノードを追加

-Let's add another set of nodes to the existing cluster, reusing the
-existing master, running in a different zone (us-central1-b or us-west-2b).
-We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
-kube-up will not create a new master, but will reuse one that was previously
-created instead.
+それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう1つのノードのセットを追加しましょう。
+kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。

 GCE:

@@ -152,22 +104,21 @@ GCE:
 KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
 ```

-On AWS we also need to specify the network CIDR for the additional
-subnet, along with the master internal IP address:
+
+AWSではマスターの内部IPアドレスに加えて追加のサブネット用のネットワークCIDRを指定する必要があります:

 ```shell
 KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
 ```


-View the nodes again; 3 more nodes should have launched and be tagged
-in us-central1-b:
+ノードをもう1度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです:

 ```shell
 kubectl get nodes --show-labels
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
@@ -182,7 +133,7 @@ kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0

 ### ボリュームのアフィニティ

-Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
+動的ボリュームを使用してボリュームを作成します(PersistentVolumeのみがゾーンアフィニティに対してサポートされています):

 ```bash
 kubectl apply -f - <<EOF
@@ -210,30 +161,28 @@ EOF
 ```

 {{< note >}}
-For version 1.3+ Kubernetes will distribute dynamic PV claims across
-the configured zones. For version 1.2, dynamic persistent volumes were
-always created in the zone of the cluster master
-(here us-central1-a / us-west-2a); that issue
+バージョン1.3以降のKubernetesは設定したゾーンを跨いでPVクレームを分配します。
+バージョン1.2では動的永続ボリュームは常にクラスターのマスターがあるゾーンに作成されます。
+(ここではus-central1-a / us-west-2a); このイシューは
 ([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
-was addressed in 1.3+.
+にバージョン1.3以降で記載されています。
 {{< /note >}}

-Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
+それでは、KubernetesがPVが作成されたゾーン及びリージョンを自動的にラベルしているか確認しましょう。

 ```shell
 kubectl get pv --show-labels
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
 pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
 ```

-So now we will create a pod that uses the persistent volume claim.
-Because GCE PDs / AWS EBS volumes cannot be attached across zones,
-this means that this pod can only be created in the same zone as the volume:
+では永続ボリュームクレームを使用するPodを作成します。
+GCE PD / AWS EBSボリュームはゾーンを跨いでアタッチできないため、これはこのPodがボリュームと同じゾーンにのみ作成されることを意味します:

 ```yaml
 kubectl apply -f - <<EOF
@@ -255,8 +204,7 @@ spec:
 EOF
 ```

-Note that the pod was automatically created in the same zone as the volume, as
-cross-zone attachments are not generally permitted by cloud providers:
+一般的にゾーンを跨いだアタッチはクラウドプロバイダーによって許可されていないため、Podは自動的にボリュームと同じゾーンに作成されることに注意してください:

 ```shell
 kubectl describe pod mypod | grep Node
@@ -266,7 +214,7 @@ kubectl describe pod mypod | grep Node
 Node:        kubernetes-minion-9vlv/10.240.0.5
 ```

-And check node labels:
+ノードのラベルをチェックします:

 ```shell
 kubectl get node kubernetes-minion-9vlv --show-labels
@@ -279,8 +227,7 @@ kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/in

 ### Podがゾーンをまたがって配置される

-Pods in a replication controller or service are automatically spread
-across zones.  First, let's launch more nodes in a third zone:
+レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、3つ目のゾーンに更なるノードを立ち上げましょう:

 GCE:

@@ -294,19 +241,19 @@ AWS:
 KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
 ```

-Verify that you now have nodes in 3 zones:
+3つのゾーンにノードがあることを確認します:

 ```shell
 kubectl get nodes --show-labels
 ```

-Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
+シンプルなWebアプリケーションを動作する、3つのRCを持つguestbook-goの例を作成します:

 ```shell
 find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
 ```

-The pods should be spread across all 3 zones:
+Podは3つの全てのゾーンにデプロイされているはずです:

 ```shell
 kubectl describe pod -l app=guestbook | grep Node
@@ -330,44 +277,43 @@ kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kuberne
 ```


-Load-balancers span all zones in a cluster; the guestbook-go example
-includes an example load-balanced service:
+ロードバランサーはクラスター内の全てのゾーンにデプロイされています; guestbook-goの例は負荷分散サービスのサンプルを含みます:

 ```shell
 kubectl describe service guestbook | grep LoadBalancer.Ingress
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 LoadBalancer Ingress:   130.211.126.21
 ```

-Set the above IP:
+IPの上に設定します:

 ```shell
 export IP=130.211.126.21
 ```

-Explore with curl via IP:
+IPをcurlを通じて探索します:

 ```shell
 curl -s http://${IP}:3000/env | grep HOSTNAME
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
  "HOSTNAME": "guestbook-44sep",
 ```

-Again, explore multiple times:
+再び、複数回探索します:

 ```shell
 (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
  "HOSTNAME": "guestbook-44sep",
@@ -375,11 +321,11 @@ The output is similar to this:
  "HOSTNAME": "guestbook-ppm40",
 ```

-The load balancer correctly targets all the pods, even though they are in multiple zones.
+ロードバランサーは、たとえPodが複数のゾーンに存在していても、全てのPodをターゲットします。

 ### クラスターの停止

-When you're done, clean up:
+終了したら、クリーンアップします:

 GCE:

@@ -397,4 +343,3 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k
 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
 ```

-
@@ -3,7 +3,6 @@ title: ノードのセットアップの検証
 weight: 30
 ---

-{{< toc >}}

 ## ノード適合テスト

@@ -26,7 +26,7 @@ MinikubeのサポートするKubernetesの機能:

 ## インストール

-[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を参照してください。
+ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従ってください。

 ## クイックスタート

@@ -50,7 +50,8 @@ MinikubeのサポートするKubernetesの機能:
   特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。

 2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。
-単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。
+
+   単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。

   ```shell
   kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
@@ -69,6 +70,7 @@ MinikubeのサポートするKubernetesの機能:
   ```

   `--type=NodePort`オプションで、Serviceのタイプを指定します。
+
   出力はこのようになります:

   ```
@@ -78,6 +80,7 @@ MinikubeのサポートするKubernetesの機能:
 4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。

   Podが稼働しているか確認します:
+
   ```shell
   kubectl get pod
   ```
@@ -110,19 +113,19 @@ MinikubeのサポートするKubernetesの機能:
   Hostname: hello-minikube-7c77b68cff-8wdzq
   
   Pod Information:
-   	-no pod information available-
+    -no pod information available-
   
   Server values:
-   	server_version=nginx: 1.13.3 - lua: 10008
+    server_version=nginx: 1.13.3 - lua: 10008
   
   Request Information:
-   	client_address=172.17.0.1
-   	method=GET
-   	real path=/
-   	query=
-   	request_version=1.1
-   	request_scheme=http
-   	request_uri=http://192.168.99.100:8080/
+    client_address=172.17.0.1
+    method=GET
+    real path=/
+    query=
+    request_version=1.1
+    request_scheme=http
+    request_uri=http://192.168.99.100:8080/
   
   Request Headers:
   	accept=*/*
@@ -168,8 +171,8 @@ MinikubeのサポートするKubernetesの機能:
   出力はこのようになります:

   ```
-   Stopping local Kubernetes cluster...
   Stopping "minikube"...
+   "minikube" stopped.
   ```

   詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。
@@ -222,24 +225,27 @@ minikube start --kubernetes-version {{< param "fullversion" >}}

 #### VMドライバーの指定

-もしVMドライバーを変更したい場合は、`--vm-driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。
+もしVMドライバーを変更したい場合は、`--driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。

 ```shell
-minikube start --vm-driver=<driver_name>
+minikube start --driver=<driver_name>
 ```

 Minikubeは以下のドライバーをサポートしています:
 {{< note >}}
-サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。
+サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/)を参照してください。
 {{< /note >}}

-* virtualbox  
+* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/))
+* virtualbox ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/))
+* podman ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (実験的)
 * vmwarefusion
-* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
-* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
-* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/))
+* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/))
+* hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/))
 注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。
 * vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver)
+* parallels ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/))
 * none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします)

 {{< caution >}}
@@ -372,7 +378,12 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し
 このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。

 ### minikubeのアップグレード {#upgrading-minikube}
-[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。
+macOSを使用し[Brew Package Manager](https://brew.sh/)がインストールされている場合、以下を実行します:
+
+```shell
+brew update
+brew upgrade minikube
+```

 ## クラスターに触れてみよう {#interacting-with-your-cluster}

@@ -383,9 +394,11 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し

 Minikubeはこのコンテキストを自動的にデフォルトに設定しますが、将来的に設定を切り戻す場合には次のコマンドを実行してください:

-`kubectl config use-context minikube`,
+`kubectl config use-context minikube`

-もしくは各コマンドにコンテキストを次のように渡します: `kubectl get pods --context=minikube`
+もしくは各コマンドにコンテキストを次のように渡します:
+
+ `kubectl get pods --context=minikube`

 ### ダッシュボード

@@ -500,13 +513,13 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr

 ## 追加リンク集

-* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://git.k8s.io/minikube/docs/contributors/roadmap.md)を参照してください。
-* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。
-* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。
-* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。
-* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。
+* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)を参照してください。
+* **開発ガイド**: プルリクエストを送る方法の概要については、[コントリビュートする](https://minikube.sigs.k8s.io/docs/contrib/)を参照してください。
+* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://minikube.sigs.k8s.io/docs/contrib/building/)を参照してください。
+* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/drivers/)を参照してください。
+* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/addons/)を参照してください。
 * **MicroK8s**: 仮想マシンを実行したくないLinuxユーザーは代わりに[MicroK8s](https://microk8s.io/)を検討してみてください。

 ## コミュニティ

-コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
+コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
@@ -18,8 +18,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ
 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、
 コンテナホストシステム上で任意のコマンドを実行する可能性があります。

-この問題の更なる情報は以下のリンクを参照してください。
-[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736)
+この問題の更なる情報は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。
 {{< /caution >}}

 ### 適用性
@@ -60,34 +59,44 @@ kubeletを再起動しても問題は解決しないでしょう。
 ## Docker

 それぞれのマシンに対してDockerをインストールします。
-バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。
+バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。
 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。

 システムへDockerをインストールするには、次のコマンドを実行します。

 {{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
-# Docker CEのインストール
+{{% tab name="Ubuntu 16.04+" %}}
+
+```shell
+# (Install Docker CE)
 ## リポジトリをセットアップ
 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
 apt-get update && apt-get install -y \
  apt-transport-https ca-certificates curl software-properties-common gnupg2
+```

-### Docker公式のGPG鍵を追加
+```shell
+# Docker公式のGPG鍵を追加:
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+```

-### Dockerのaptリポジトリを追加
+```shell
+# Dockerのaptレポジトリを追加:
 add-apt-repository \
  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) \
  stable"
+```

-## Docker CEのインストール
+```shell
+# 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)
+containerd.io=1.2.13-2 \
+docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
+docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
+```

+```shell
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -99,33 +108,47 @@ cat > /etc/docker/daemon.json <<EOF
  "storage-driver": "overlay2"
 }
 EOF
+```

+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```

+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+```
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}

-# Docker CEのインストール
+```shell
+# (Docker CEのインストール)
 ## リポジトリをセットアップ
 ### 必要なパッケージのインストール
 yum install -y yum-utils device-mapper-persistent-data lvm2
+```

-### Dockerリポジトリの追加
+```shell
+## Dockerリポジトリの追加
 yum-config-manager --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo
+```

+```shell
 ## Docker CEのインストール
 yum update -y && yum install -y \
-  containerd.io-1.2.10 \
-  docker-ce-19.03.4 \
-  docker-ce-cli-19.03.4
+  containerd.io-1.2.13 \
+  docker-ce-19.03.11 \
+  docker-ce-cli-19.03.11
+```

+```shell
 ## /etc/docker ディレクトリを作成
 mkdir /etc/docker
+```

+```shell
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -140,15 +163,26 @@ cat > /etc/docker/daemon.json <<EOF
  ]
 }
 EOF
+```

+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```

+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}

+ブート時にDockerサービスを開始させたい場合は、以下のコマンドを入力してください:
+
+```shell
+sudo systemctl enable docker
+```
+
 詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。

 ## CRI-O
@@ -179,54 +213,112 @@ sysctl --system
 ```

 {{< tabs name="tab-cri-cri-o-installation" >}}
-{{< 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 -
+{{% tab name="Debian" %}}

-# 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 -
+ CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。

-# 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 -
+| Operating system | $OS               |
+| ---------------- | ----------------- |
+| Debian Unstable  | `Debian_Unstable` |
+| Debian Testing   | `Debian_Testing`  |

-# 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 -
+<br />
+そして、`$VERSION`にKubernetesのバージョンに合わせたCRI-Oのバージョンを設定します。例えば、CRI-O 1.18をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3をインストールするには、`VERSION=1.18:1.18.3` を設定します。
+<br />

-# CRI-Oのインストール
-sudo apt-get install cri-o-1.17
-{{< /tab >}}
+以下を実行します。
+```shell
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list

-{{< 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
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -

-# CRI-Oのインストール
-sudo apt-get install cri-o-1.17
-{{< /tab >}}
+apt-get update
+apt-get install cri-o cri-o-runc
+```

-{{< 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/
+{{% /tab %}}

-# CRI-Oのインストール
-yum install --nogpgcheck -y cri-o
-{{< /tab >}}
+{{% tab name="Ubuntu" %}}

-{{< tab name="openSUSE Tumbleweed" codelang="bash" >}}
-sudo zypper install cri-o
-{{< /tab >}}
+ CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。
+
+| Operating system | $OS               |
+| ---------------- | ----------------- |
+| Ubuntu 20.04     | `xUbuntu_20.04`   |
+| Ubuntu 19.10     | `xUbuntu_19.10`   |
+| Ubuntu 19.04     | `xUbuntu_19.04`   |
+| Ubuntu 18.04     | `xUbuntu_18.04`   |
+
+<br />
+次に、`$VERSION`をKubernetesのバージョンと一致するCRI-Oのバージョンに設定します。例えば、CRI-O 1.18をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3 をインストールするには、`VERSION=1.18:1.18.3` を設定します。
+<br />
+
+以下を実行します。
+```shell
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
+
+apt-get update
+apt-get install cri-o cri-o-runc
+```
+{{% /tab %}}
+
+{{% tab name="CentOS" %}}
+
+ CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。
+
+| Operating system | $OS               |
+| ---------------- | ----------------- |
+| Centos 8         | `CentOS_8`        |
+| Centos 8 Stream  | `CentOS_8_Stream` |
+| Centos 7         | `CentOS_7`        |
+
+<br />
+次に、`$VERSION`をKubernetesのバージョンと一致するCRI-Oのバージョンに設定します。例えば、CRI-O 1.18 をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3 をインストールするには、`VERSION=1.18:1.18.3` を設定します。
+<br />
+
+以下を実行します。
+```shell
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
+yum install cri-o
+```
+
+{{% /tab %}}
+
+{{% tab name="openSUSE Tumbleweed" %}}
+
+```shell
+ sudo zypper install cri-o
+```
+{{% /tab %}}
+{{% tab name="Fedora" %}}
+
+$VERSIONには、Kubernetesのバージョンと一致するCRI-Oのバージョンを設定します。例えば、CRI-O 1.18をインストールしたい場合は、$VERSION=1.18を設定します。
+以下のコマンドで、利用可能なバージョンを見つけることができます。
+```shell
+dnf module list cri-o
+```
+CRI-OはFedoraの特定のリリースにピン留めすることをサポートしていません。
+
+以下を実行します。
+```shell
+dnf module enable cri-o:$VERSION
+dnf install cri-o
+```
+
+{{% /tab %}}
 {{< /tabs >}}

+
 ### CRI-Oの起動

-```
+```shell
 systemctl daemon-reload
 systemctl start crio
 ```
@@ -263,52 +355,76 @@ sysctl --system
 ### containerdのインストール

 {{< tabs name="tab-cri-containerd-installation" >}}
-{{< tab name="Ubuntu 16.04" codelang="bash" >}}
-# containerdのインストール
+{{% tab name="Ubuntu 16.04" %}}
+
+```shell
+# (containerdのインストール)
 ## リポジトリの設定
 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
 apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+```

-### Docker公式のGPG鍵を追加
+```shell
+## Docker公式のGPG鍵を追加
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+```

-### Dockerのaptリポジトリの追加
+```shell
+## Dockerのaptリポジトリの追加
 add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    $(lsb_release -cs) \
    stable"
+```

+```shell
 ## containerdのインストール
 apt-get update && apt-get install -y containerd.io
+```

+```shell
 # containerdの設定
 mkdir -p /etc/containerd
 containerd config default > /etc/containerd/config.toml
+```

+```shell
 # containerdの再起動
 systemctl restart containerd
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
-# containerdのインストール
+```
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
+
+```shell
+# (containerdのインストール)
 ## リポジトリの設定
 ### 必要なパッケージのインストール
 yum install -y yum-utils device-mapper-persistent-data lvm2
+```

-### Dockerのリポジトリの追加
+```shell
+## Dockerのリポジトリの追加
 yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
+```

+```shell
 ## containerdのインストール
 yum update -y && yum install -y containerd.io
+```

-# containerdの設定
+```shell
+## containerdの設定
 mkdir -p /etc/containerd
 containerd config default > /etc/containerd/config.toml
+```

+```shell
 # containerdの再起動
 systemctl restart containerd
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}

 ### systemd
@@ -7,7 +7,7 @@ content_type: concept

 [CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.

-[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
+[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.

 This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.

@@ -27,7 +27,7 @@ kops is an automated provisioning system:

 * You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.

-* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them.
+* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).



@@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde
 but not under `example.com`).

 Let's assume you're using `dev.example.com` as your hosted zone.  You create that hosted zone using
-the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
 with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.

 You must then set up your NS records in the parent domain, so that records in the domain will resolve.  Here,
@@ -231,7 +231,7 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
 ## {{% heading "whatsnext" %}}


-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
 * Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
 * Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
 * Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
@@ -1,12 +1,12 @@
 ---
-title: kubeadmを使用したシングルコントロールプレーンクラスターの作成
+title: kubeadmを使用したクラスターの作成
 content_type: task
 weight: 30
 ---

 <!-- overview -->

-<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">`kubeadm`ツールは、ベストプラクティスに準拠した実用最小限のKubernetesクラスターをブートストラップする手助けをします。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">ベストプラクティスに準拠した実用最小限のKubernetesクラスターを作成します。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。

 `kubeadm`ツールは、次のようなときに適しています。

@@ -41,7 +41,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。

 ## 目的

-* シングルコントロールプレーンのKubernetesクラスターまたは[高可用性クラスター](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)をインストールする
+* シングルコントロールプレーンのKubernetesクラスターをインストールする
 * クラスター上にPodネットワークをインストールして、Podがお互いに通信できるようにする

 ## 手順
@@ -63,7 +63,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。
 1. (推奨)シングルコントロールプレーンの`kubeadm`クラスターを高可用性クラスターにアップグレードする予定がある場合、`--control-plane-endpoint`を指定して、すべてのコントロールプレーンノードとエンドポイントを共有する必要があります。エンドポイントにはDNSネームやロードバランサーのIPアドレスが使用できます。
 1. Podネットワークアドオンを選んで、`kubeadm init`に引数を渡す必要があるかどうか確認してください。選んだサードパーティーのプロバイダーによっては、`--pod-network-cidr`をプロバイダー固有の値に設定する必要がある場合があります。詳しくは、[Podネットワークアドオンのインストール](#pod-network)を参照してください。
 1. (オプション)バージョン1.14から、`kubeadm`はよく知られたドメインソケットのパスリストを用いて、Linux上のコンテナランタイムの検出を試みます。異なるコンテナランタイムを使用する場合やプロビジョニングするノードに2つ以上のランタイムがインストールされている場合、`kubeadm init`に`--cri-socket`引数を指定してください。詳しくは、[ランタイムのインストール](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)を読んでください。
-1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertize-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
+1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertise-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
 1. (オプション)`kubeadm init`を実行する前に`kubeadm config images pull`を実行して、gcr.ioコンテナイメージレジストリに接続できるかどうかを確認します。

 コントロールプレーンノードを初期化するには、次のコマンドを実行します。
@@ -76,7 +76,7 @@ kubeadm init <args>

 `--apiserver-advertise-address`は、この特定のコントロールプレーンノードのAPIサーバーへのadvertise addressを設定するために使えますが、`--control-plane-endpoint`は、すべてのコントロールプレーンノード共有のエンドポイントを設定するために使えます。

-`--control-plane-endpoint`はIPアドレスを受け付けますが、IPアドレスへマッピングされるDNSネームも使用できます。利用可能なソリューションをそうしたマッピングの観点から評価するには、ネットワーク管理者に相談してください。
+`--control-plane-endpoint`はIPアドレスと、IPアドレスへマッピングできるDNS名を使用できます。利用可能なソリューションをそうしたマッピングの観点から評価するには、ネットワーク管理者に相談してください。

 以下にマッピングの例を示します。

@@ -203,9 +203,14 @@ export KUBECONFIG=/etc/kubernetes/admin.conf

 {{< /caution >}}

-CNIを使用するKubernetes Podネットワークを提供する外部のプロジェクトがいくつかあります。一部のプロジェクトでは、[ネットワークポリシー](/docs/concepts/services-networking/networkpolicies/)もサポートしています。
+{{< note >}}
+現在、Calicoはkubeadmプロジェクトがe2eテストを実施している唯一のCNIプラグインです。
+もしCNIプラグインに関する問題を見つけた場合、kubeadmやkubernetesではなく、そのCNIプラグインの課題管理システムへ問題を報告してください。
+{{< /note >}}

-利用できる[ネットワークアドオンとネットワークポリシーアドオン](/docs/concepts/cluster-administration/addons/#networking-and-network-policy)のリストを確認してください。
+CNIを使用するKubernetes Podネットワークを提供する外部のプロジェクトがいくつかあります。一部のプロジェクトでは、[ネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/)もサポートしています。
+
+[Kubernetesのネットワークモデル](/ja/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model)を実装したアドオンの一覧も確認してください。

 Podネットワークアドオンをインストールするには、コントロールプレーンノード上またはkubeconfigクレデンシャルを持っているノード上で、次のコマンドを実行します。

@@ -213,91 +218,7 @@ Podネットワークアドオンをインストールするには、コント
 kubectl apply -f <add-on.yaml>
 ```

-インストールできるPodネットワークは、クラスターごとに1つだけです。以下の手順で、いくつかのよく使われるPodネットワークプラグインをインストールできます。
-
-{{< tabs name="tabs-pod-install" >}}
-
-{{% tab name="Calico" %}}
-[Calico](https://docs.projectcalico.org/latest/introduction/)は、ネットワークとネットワークポリシーのプロバイダーです。Calicoは柔軟なさまざまなネットワークオプションをサポートするため、自分の状況に適した最も効果的なオプションを選択できます。たとえば、ネットワークのオーバーレイの有無や、BGPの有無が選べます。Calicoは、ホスト、Pod、(もしIstioとEnvoyを使っている場合)サービスメッシュレイヤー上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用しています。Calicoは、`amd64`、`arm64`、`ppc64le`を含む複数のアーキテクチャで動作します。
-
-デフォルトでは、Calicoは`192.168.0.0/16`をPodネットワークのCIDRとして使いますが、このCIDRはcalico.yamlファイルで設定できます。Calicoを正しく動作させるためには、これと同じCIDRを`--pod-network-cidr=192.168.0.0/16`フラグまたはkubeadmの設定を使って、`kubeadm init`コマンドに渡す必要があります。
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml
-```
-
-{{% /tab %}}
-
-{{% tab name="Cilium" %}}
-Ciliumを正しく動作させるためには、`kubeadm init`に `--pod-network-cidr=10.217.0.0/16`を渡さなければなりません。
-
-Ciliumのデプロイは、次のコマンドを実行するだけでできます。
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
-```
-
-すべてのCilium Podが`READY`とマークされたら、クラスターを使い始められます。
-
-```shell
-kubectl get pods -n kube-system --selector=k8s-app=cilium
-```
-
-出力は次のようになります。
-
-```
-NAME           READY   STATUS    RESTARTS   AGE
-cilium-drxkl   1/1     Running   0          18m
-```
-
-Ciliumはkube-proxyの代わりに利用することもできます。詳しくは[Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free)を読んでください。
-
-KubernetesでのCiliumの使い方に関するより詳しい情報は、[Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/)を参照してください。
-{{% /tab %}}
-
-{{% tab name="Contiv-VPP" %}}
-[Contiv-VPP](https://contivpp.io/)は、[FD.io VPP](https://fd.io/)をベースとするプログラマブルなCNF vSwitchを採用し、機能豊富で高性能なクラウドネイティブなネットワーキングとサービスを提供します。
-
-Contiv-VPPは、k8sサービスとネットワークポリシーを(VPP上の)ユーザースペースで実装しています。
-
-こちらのインストールガイドを参照してください: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
-{{% /tab %}}
-
-{{% tab name="Flannel" %}}
-`flannel`を正しく動作させるためには、`--pod-network-cidr=10.244.0.0/16`を`kubeadm init`に渡す必要があります。
-
-オーバーレイネットワークに参加しているすべてのホスト上で、ファイアウォールのルールが、UDPポート8285と8472のトラフィックを許可するように設定されていることを確認してください。この設定に関するより詳しい情報は、Flannelのトラブルシューティングガイドの[Firewall](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls)のセクションを参照してください。
-
-Flannelは、Linux下の`amd64`、`arm`、`arm64`、`ppc64le`、`s390x`アーキテクチャ上で動作します。Windows(`amd64`)はv0.11.0でサポートされたとされていますが、使用方法はドキュメントに書かれていません。
-
-```shell
-kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml
-```
-
-`flannel`に関するより詳しい情報は、[GitHub上のCoreOSのflannelリポジトリ](https://github.com/coreos/flannel)を参照してください。
-{{% /tab %}}
-
-{{% tab name="Kube-router" %}}
-Kube-routerは、ノードへのPod CIDRの割り当てをkube-controller-managerに依存しています。そのため、`kubeadm init`時に`--pod-network-cidr`フラグを使用する必要があります。
-
-Kube-routerは、Podネットワーク、ネットワークポリシー、および高性能なIP Virtual Server(IPVS)/Linux Virtual Server(LVS)ベースのサービスプロキシーを提供します。
-
-Kube-routerを有効にしたKubernetesクラスターをセットアップするために`kubeadm`ツールを使用する方法については、公式の[セットアップガイド](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md)を参照してください。
-{{% /tab %}}
-
-{{% tab name="Weave Net" %}}
-Weave Netを使用してKubernetesクラスターをセットアップするより詳しい情報は、[アドオンを使用してKubernetesを統合する](https://www.weave.works/docs/net/latest/kube-addon/)を読んでください。
-
-Weave Netは、`amd64`、`arm`、`arm64`、`ppc64le`プラットフォームで追加の操作なしで動作します。Weave Netはデフォルトでharipinモードをセットします。このモードでは、Pod同士はPodIPを知らなくても、Service IPアドレス経由でアクセスできます。
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
-
-{{% /tab %}}
-
-{{< /tabs >}}
-
+インストールできるPodネットワークは、クラスターごとに1つだけです。

 Podネットワークがインストールされたら、`kubectl get pods --all-namespaces`の出力結果でCoreDNS Podが`Running`状態であることをチェックすることで、ネットワークが動作していることを確認できます。そして、一度CoreDNS Podが動作すれば、続けてノードを追加できます。

@@ -375,7 +296,7 @@ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outfor
 ```

 {{< note >}}
-IPv6タプルを`<control-plane-host>:<control-plane-ip>`に指定するためには、IPv6アドレスをブラケットで囲みます。たとえば、`[fd00::101]:2073`のように書きます。
+IPv6タプルを`<control-plane-host>:<control-plane-port>`と指定するためには、IPv6アドレスを角括弧で囲みます。たとえば、`[fd00::101]:2073`のように書きます。
 {{< /note >}}

 出力は次のようになります。
@@ -407,7 +328,7 @@ kubectl --kubeconfig ./admin.conf get nodes
 {{< note >}}
 上の例では、rootユーザーに対するSSH接続が有効であることを仮定しています。もしそうでない場合は、`admin.conf`ファイルを誰か他のユーザーからアクセスできるようにコピーした上で、代わりにそのユーザーを使って`scp`してください。

-`admin.conf`ファイルはユーザーにクラスターに対する _特権ユーザー_ の権限を与えます。そのため、このファイルを使うのは控えめにしなければなりません。通常のユーザーには、一部の権限をホワイトリストに加えたユニークなクレデンシャルを生成することを推奨します。これには、`kubeadm alpha kubeconfig user --client-name <CN>`コマンドが使えます。このコマンドを実行すると、KubeConfigファイルがSTDOUTに出力されるので、ファイルに保存してユーザーに配布します。その後、`kubectl create (cluster)rolebinding`コマンドを使って権限をホワイトリストに加えます。
+`admin.conf`ファイルはユーザーにクラスターに対する _特権ユーザー_ の権限を与えます。そのため、このファイルを使うのは控えめにしなければなりません。通常のユーザーには、明示的に許可した権限を持つユニークなクレデンシャルを生成することを推奨します。これには、`kubeadm alpha kubeconfig user --client-name <CN>`コマンドが使えます。このコマンドを実行すると、KubeConfigファイルがSTDOUTに出力されるので、ファイルに保存してユーザーに配布します。その後、`kubectl create (cluster)rolebinding`コマンドを使って権限を付与します。
 {{< /note >}}

 ### (オプション)APIサーバーをlocalhostへプロキシする
@@ -433,10 +354,9 @@ kubectl --kubeconfig ./admin.conf proxy

 ```bash
 kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
-kubectl delete node <node name>
 ```

-その後、ノードが削除されたら、`kubeadm`のインストール状態をすべてリセットします。
+ノードが削除される前に、`kubeadm`によってインストールされた状態をリセットします。

 ```bash
 kubeadm reset
@@ -454,6 +374,11 @@ IPVS tablesをリセットしたい場合は、次のコマンドを実行する
 ipvsadm -C
 ```

+ノードを削除します。
+```bash
+kubectl delete node <node name>
+```
+
 クラスターのセットアップを最初から始めたいときは、`kubeadm init`や`kubeadm join`を適切な引数を付けて実行すればいいだけです。

 ### コントロールプレーンのクリーンアップ
@@ -469,7 +394,7 @@ ipvsadm -C
 * [Sonobuoy](https://github.com/heptio/sonobuoy)を使用してクラスターが適切に動作しているか検証する。
 * <a id="lifecycle" />`kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。
 * `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。
-* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/docs/user-guide/kubectl-overview/)についてもっと学ぶ。
+* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。
 * Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。
 * <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。
 * クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。
@@ -486,9 +411,9 @@ ipvsadm -C

 ## バージョン互換ポリシー {#version-skew-policy}

-バージョンvX.Yの`kubeadm`ツールは、バージョンvX.YまたはvX.(Y-1)のコントロールプレーンを持つクラスターをデプロイできます。また、`kubeadm` vX.Yは、kubeadmで構築された既存のvX.(Y-1)のクラスターをアップグレートできます。
+バージョンv{{< skew latestVersion >}}の`kubeadm`ツールは、バージョンv{{< skew latestVersion >}}またはv{{< skew prevMinorVersion >}}のコントロールプレーンを持つクラスターをデプロイできます。また、バージョンv{{< skew latestVersion >}}の`kubeadm`は、バージョンv{{< skew prevMinorVersion >}}のkubeadmで構築されたクラスターをアップグレートできます。

-未来を見ることはできないため、kubeadm CLI vX.YはvX.(Y+1)をデプロイすることはできません。
+未来を見ることはできないため、kubeadm CLI v{{< skew latestVersion >}}はv{{< skew nextMinorVersion >}}をデプロイできないかもしれません。

 例: `kubeadm` v1.8は、v1.7とv1.8のクラスターをデプロイでき、v1.7のkubeadmで構築されたクラスターをv1.8にアップグレートできます。

@@ -507,7 +432,7 @@ kubeletとコントロールプレーンの間や、他のKubernetesコンポー

 * 定期的に[etcdをバックアップ](https://coreos.com/etcd/docs/latest/admin_guide.html)する。kubeadmが設定するetcdのデータディレクトリは、コントロールプレーンノードの`/var/lib/etcd`にあります。

-* 複数のコントロールプレーンノードを使用する。[高可用性トポロジーのオプション](/docs/setup/production-environment/tools/kubeadm/ha-topology/)では、より高い可用性を提供するクラスターのトポロジーの選択について説明してます。
+* 複数のコントロールプレーンノードを使用する。[高可用性トポロジーのオプション](/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/)では、[より高い可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)を提供するクラスターのトポロジーの選択について説明してます。

 ### プラットフォームの互換性 {#multi-platform}

@@ -520,4 +445,3 @@ kubeadmのdeb/rpmパッケージおよびバイナリは、[multi-platform propo
 ## トラブルシューティング {#troubleshooting}

 kubeadmに関する問題が起きたときは、[トラブルシューティングドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を確認してください。
-
@@ -15,7 +15,10 @@ HAクラスターは次の方法で設定できます。

 HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。

-
+{{< note >}}
+kubeadmは、etcdクラスターを静的にブートストラップします。
+詳細については、etcd[クラスタリングガイド](https://github.com/etcd-io/etcd/blob/release-3.4/Documentation/op-guide/clustering.md#static)をご覧ください。
+{{< /note >}}

 <!-- body -->

@@ -57,10 +57,10 @@ weight: 60

    - ロードバランサーは、apiserverポートで、全てのコントロールプレーンノードと通信できなければなりません。また、リスニングポートに対する流入トラフィックも許可されていなければなりません。

-    - [HAProxy](http://www.haproxy.org/)をロードバランサーとして使用することができます。
-
    - ロードバランサーのアドレスは、常にkubeadmの`ControlPlaneEndpoint`のアドレスと一致することを確認してください。

+    - 詳細は[Options for Software Load Balancing](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)をご覧ください。
+
 1.  ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする:

    ```sh
@@ -87,7 +87,7 @@ weight: 60

    {{< note >}}`kubeadm init`の`--config`フラグと`--certificate-key`フラグは混在させることはできないため、[kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用する場合は`certificateKey`フィールドを適切な場所に追加する必要があります(`InitConfiguration`と`JoinConfiguration: controlPlane`の配下)。{{< /note >}}

-    {{< note >}}CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}}
+    {{< note >}}いくつかのCNIネットワークプラグインはPodのIPのCIDRの指定など追加の設定を必要としますが、必要としないプラグインもあります。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}}

    - このような出力がされます:

@@ -64,7 +64,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub

 ### `kubeadm init`実行時の流れ

-`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`.X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。
+`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。

 二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。

@@ -99,7 +99,7 @@ kubeletが新たな設定を読み込むと、kubeadmは、KubeConfigファイ
 `kubeadm`には、systemdがどのようにkubeletを実行するかを指定した設定ファイルが同梱されています。
 kubeadm CLIコマンドは決してこのsystemdファイルには触れないことに注意してください。

-kubeadmの[DEBパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。
+kubeadmの[DEBパッケージ](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。

 ```none
 [Service]
@@ -134,6 +134,5 @@ Kubernetesに同梱されるDEB、RPMのパッケージは以下の通りです
 | `kubeadm`    | `/usr/bin/kubeadm`CLIツールと、[kubelet用のsystemdファイル](#the-kubelet-drop-in-file-for-systemd)をインストールします。 |
 | `kubelet`    | kubeletバイナリを`/usr/bin`に、CNIバイナリを`/opt/cni/bin`にインストールします。 |
 | `kubectl`    | `/usr/bin/kubectl`バイナリをインストールします。 |
-| `kubernetes-cni` | 公式のCNIバイナリを`/opt/cni/bin`ディレクトリにインストールします。 |
 | `cri-tools` | `/usr/bin/crictl`バイナリを[cri-tools gitリポジトリ](https://github.com/kubernetes-incubator/cri-tools)からインストールします。 |

@@ -1,68 +1,48 @@
 ---
-title: Configuring your kubernetes cluster to self-host the control plane
+title: コントロールプレーンをセルフホストするようにkubernetesクラスターを構成する
 content_type: concept
 weight: 100
 ---

 <!-- overview -->

-### Self-hosting the Kubernetes control plane {#self-hosting}
+### コントロールプレーンのセルフホスティング {#self-hosting}

-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/)
-configured in the kubelet via static files.
+kubeadmを使用すると、セルフホスト型のKubernetesコントロールプレーンを実験的に作成できます。これはAPIサーバー、コントローラーマネージャー、スケジューラーなどの主要コンポーネントは、静的ファイルを介してkubeletで構成された[static pods](/docs/tasks/configure-pod-container/static-pod/)ではなく、Kubernetes APIを介して構成された[DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/)として実行されることを意味します。

-To create a self-hosted cluster see the
-[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
+セルフホスト型クラスターを作成する場合は[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)を参照してください。



 <!-- body -->

-#### Caveats
+#### 警告

 {{< caution >}}
-This feature pivots your cluster into an unsupported state, rendering kubeadm unable
-to manage you cluster any longer. This includes `kubeadm upgrade`.
+この機能により、クラスターがサポートされていない状態になり、kubeadmがクラスターを管理できなくなります。これには`kubeadm upgrade`が含まれます。
 {{< /caution >}}

-1. Self-hosting in 1.8 and later has some important limitations. In particular, a
-  self-hosted cluster _cannot recover from a reboot of the control-plane node_
-  without manual intervention.
+1. 1.8以降のセルフホスティングには、いくつかの重要な制限があります。特に、セルフホスト型クラスターは、手動の介入なしにコントロールプレーンのNode再起動から回復することはできません。

-1. By default, self-hosted control plane Pods rely on credentials loaded from
-  [`hostPath`](/docs/concepts/storage/volumes/#hostpath)
-  volumes. Except for initial creation, these credentials are not managed by
-  kubeadm.
+1. デフォルトでは、セルフホスト型のコントロールプレーンのPodは、[`hostPath`](/docs/concepts/storage/volumes/#hostpath)ボリュームからロードされた資格情報に依存しています。最初の作成を除いて、これらの資格情報はkubeadmによって管理されません。

-1. The self-hosted portion of the control plane does not include etcd,
-  which still runs as a static Pod.
+1. コントロールプレーンのセルフホストされた部分にはetcdが含まれていませんが、etcdは静的Podとして実行されます。

-#### Process
+#### プロセス

-The self-hosting bootstrap process is documented in the [kubeadm design
-document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
+セルフホスティングのブートストラッププロセスは、[kubeadm design
+document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)に記載されています。

-In summary, `kubeadm alpha selfhosting` works as follows:
+要約すると、`kubeadm alpha selfhosting`は次のように機能します。

-  1. Waits for this bootstrap static control plane to be running and
-    healthy. This is identical to the `kubeadm init` process without self-hosting.
+  1. 静的コントロールプレーンのブートストラップが起動し、正常になるのを待ちます。これは`kubeadm init`のセルフホスティングを使用しないプロセスと同じです。

-  1. Uses the static control plane Pod manifests to construct a set of
-    DaemonSet manifests that will run the self-hosted control plane.
-    It also modifies these manifests where necessary, for example adding new volumes
-    for secrets.
+  1. 静的コントロールプレーンのPodのマニフェストを使用して、セルフホスト型コントロールプレーンを実行する一連のDaemonSetのマニフェストを構築します。また、必要に応じてこれらのマニフェストを変更します。たとえば、シークレット用の新しいボリュームを追加します。

-  1. Creates DaemonSets in the `kube-system` namespace and waits for the
-     resulting Pods to be running.
+  1. `kube-system`のネームスペースにDaemonSetを作成し、Podの結果が起動されるのを待ちます。

-  1. Once self-hosted Pods are operational, their associated static Pods are deleted
-     and kubeadm moves on to install the next component. This triggers kubelet to
-     stop those static Pods.
+  1. セルフホスト型のPodが操作可能になると、関連する静的Podが削除され、kubeadmは次のコンポーネントのインストールに進みます。これによりkubeletがトリガーされて静的Podが停止します。

-  1. When the original static control plane stops, the new self-hosted control
-    plane is able to bind to listening ports and become active.
+  1. 元の静的なコントロールプレーンが停止すると、新しいセルフホスト型コントロールプレーンはリスニングポートにバインドしてアクティブになります。


@@ -29,7 +29,8 @@ when using kubeadm to set up a kubernetes cluster.
 * Three hosts that can talk to each other over ports 2379 and 2380. This
  document assumes these default ports. However, they are configurable through
  the kubeadm config file.
-* Each host must [have docker, kubelet, and kubeadm installed][toolbox].
+* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using `kubeadm config images list/pull`. This guide will setup etcd instances as [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
 * Some infrastructure to copy files between hosts. For example `ssh` and `scp`
  can satisfy this requirement.

@@ -6,68 +6,100 @@ weight: 20

 <!-- overview -->

-As with any program, you might run into an error installing or running kubeadm.
-This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
+どのプログラムでもそうですが、kubeadmのインストールや実行でエラーが発生することがあります。このページでは、一般的な失敗例をいくつか挙げ、問題を理解して解決するための手順を示しています。

-If your problem is not listed below, please follow the following steps:
-
- If you think your problem is a bug with kubeadm:
-  - Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
-  - If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
-
- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
-  relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
+本ページに問題が記載されていない場合は、以下の手順を行ってください:

+- 問題がkubeadmのバグによるものと思った場合:
+  - [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues)にアクセスして、既存のIssueを探してください。
+  - Issueがない場合は、テンプレートにしたがって[新しくIssueを立ててください](https://github.com/kubernetes/kubeadm/issues/new)。

+- kubeadmがどのように動作するかわからない場合は、[Slack](http://slack.k8s.io/)の#kubeadmチャンネルで質問するか、[StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes)で質問をあげてください。その際は、他の方が助けを出しやすいように`#kubernetes`や`#kubeadm`といったタグをつけてください。

 <!-- body -->

+## RBACがないため、v1.18ノードをv1.17クラスタに結合できない
+v1.18では、同名のノードが既に存在する場合にクラスタ内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。
+
+しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスタに参加できないという問題が発生します。
+
+この問題を回避するには、次の2つの方法があります。
+- kubeadm v1.18を用いて、コントロールプレーンノード上で`kubeadm init phase bootstrap-token`を実行します。
+これには、ブートストラップトークンの残りのパーミッションも同様に有効にすることに注意してください。
+
+- `kubectl apply -f ...`を使って以下のRBACを手動で適用します。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: kubeadm:get-nodes
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - nodes
+  verbs:
+  - get
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: kubeadm:get-nodes
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: kubeadm:get-nodes
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: Group
+  name: system:bootstrappers:kubeadm:default-node-token
+```
+
 ## インストール中に`ebtables`もしくは他の似たような実行プログラムが見つからない

-If you see the following warnings while running `kubeadm init`
+`kubeadm init`の実行中に以下のような警告が表示された場合は、以降に記載するやり方を行ってください。

 ```sh
 [preflight] WARNING: ebtables not found in system path
 [preflight] WARNING: ethtool not found in system path
 ```

-Then you may be missing `ebtables`, `ethtool` or a similar executable on your node. You can install them with the following commands:
+このような場合、ノード上に`ebtables`, `ethtool`などの実行ファイルがない可能性があります。これらをインストールするには、以下のコマンドを実行します。

- For Ubuntu/Debian users, run `apt install ebtables ethtool`.
- For CentOS/Fedora users, run `yum install ebtables ethtool`.
+- Ubuntu/Debianユーザーは、`apt install ebtables ethtool`を実行してください。
+- CentOS/Fedoraユーザーは、`yum install ebtables ethtool`を実行してください。

 ## インストール中にkubeadmがコントロールプレーンを待ち続けて止まる

-If you notice that `kubeadm init` hangs after printing out the following line:
+以下のを出力した後に`kubeadm init`が止まる場合は、`kubeadm init`を実行してください:

 ```sh
 [apiclient] Created API client, waiting for the control plane to become ready
 ```

-This may be caused by a number of problems. The most common are:
+これはいくつかの問題が原因となっている可能性があります。最も一般的なのは:

- network connection problems. Check that your machine has full network connectivity before continuing.
- the default cgroup driver configuration for the kubelet differs from that used by Docker.
-  Check the system log file (e.g. `/var/log/message`) or examine the output from `journalctl -u kubelet`. If you see something like the following:
+- ネットワーク接続の問題が挙げられます。続行する前に、お使いのマシンがネットワークに完全に接続されていることを確認してください。
+- kubeletのデフォルトのcgroupドライバの設定がDockerで使用されているものとは異なっている場合も考えられます。
+  システムログファイル(例: `/var/log/message`)をチェックするか、`journalctl -u kubelet`の出力を調べてください:

  ```shell
  error: failed to run Kubelet: failed to create kubelet:
  misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
  ```

-  There are two common ways to fix the cgroup driver problem:
+  以上のようなエラーが現れていた場合、cgroupドライバの問題を解決するには、以下の2つの方法があります:

- 1. Install Docker again following instructions
-  [here](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
+ 1. [ここ](/ja/docs/setup/independent/install-kubeadm/#installing-docker)の指示に従ってDockerを再度インストールします。

- 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
-    [Configure cgroup driver used by kubelet on Master Node](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
+ 1. Dockerのcgroupドライバに合わせてkubeletの設定を手動で変更します。その際は、[マスターノード上でkubeletが使用するcgroupドライバを設定する](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)を参照してください。

- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`.
+- control plane Dockerコンテナがクラッシュループしたり、ハングしたりしています。これは`docker ps`を実行し、`docker logs`を実行して各コンテナを調査することで確認できます。

 ## 管理コンテナを削除する時にkubeadmが止まる

-The following could happen if Docker halts and does not remove any Kubernetes-managed containers:
+Dockerが停止して、Kubernetesで管理されているコンテナを削除しないと、以下のようなことが起こる可能性があります:

 ```bash
 sudo kubeadm reset
@@ -78,95 +110,70 @@ sudo kubeadm reset
 (block)
 ```

-A possible solution is to restart the Docker service and then re-run `kubeadm reset`:
+考えられる解決策は、Dockerサービスを再起動してから`kubeadm reset`を再実行することです:

 ```bash
 sudo systemctl restart docker.service
 sudo kubeadm reset
 ```

-Inspecting the logs for docker may also be useful:
+dockerのログを調べるのも有効な場合があります:

 ```sh
-journalctl -ul docker
+journalctl -u docker
 ```

-## Podの状態が`RunContainerError`、`CrashLoopBackOff`、または`Error`
+## Podの状態が`RunContainerError`、`CrashLoopBackOff`、または`Error`となる

-Right after `kubeadm init` there should not be any pods in these states.
+`kubeadm init`の直後には、これらの状態ではPodは存在しないはずです。

- If there are pods in one of these states _right after_ `kubeadm init`, please open an
-  issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state
-  until you have deployed the network solution.
- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
-  after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
-  it's very likely that the Pod Network solution that you installed is somehow broken.
-  You might have to grant it more RBAC privileges or use a newer version. Please file
-  an issue in the Pod Network providers' issue tracker and get the issue triaged there.
- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
-  when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`.
-  MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state.
-  The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files.
+- `kubeadm init`の _直後_ にこれらの状態のいずれかにPodがある場合は、kubeadmのリポジトリにIssueを立ててください。ネットワークソリューションをデプロイするまでは`coredns`(または`kube-dns`)は`Pending`状態でなければなりません。
+- ネットワークソリューションをデプロイしても`coredns`(または`kube-dns`)に何も起こらない場合にRunContainerError`、`CrashLoopBackOff`、`Error`の状態でPodが表示された場合は、インストールしたPodネットワークソリューションが壊れている可能性が高いです。より多くのRBACの特権を付与するか、新しいバージョンを使用する必要があるかもしれません。PodネットワークプロバイダのイシュートラッカーにIssueを出して、そこで問題をトリアージしてください。
+- 1.12.1よりも古いバージョンのDockerをインストールした場合は、`systemd`で`dockerd`を起動する際に`MountFlags=slave`オプションを削除して`docker`を再起動してください。マウントフラグは`/usr/lib/systemd/system/docker.service`で確認できます。MountFlagsはKubernetesがマウントしたボリュームに干渉し、Podsを`CrashLoopBackOff`状態にすることがあります。このエラーは、Kubernetesが`var/run/secrets/kubernetes.io/serviceaccount`ファイルを見つけられない場合に発生します。

 ## `coredns`(もしくは`kube-dns`)が`Pending`状態でスタックする

-This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
-should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
-of choice. You have to install a Pod Network
-before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
+kubeadmはネットワークプロバイダに依存しないため、管理者は選択した[Podネットワークソリューションをインストール](/docs/concepts/cluster-administration/addons/)をする必要があります。CoreDNSを完全にデプロイする前にPodネットワークをインストールする必要があります。したがって、ネットワークがセットアップされる前の `Pending`状態になります。

 ## `HostPort`サービスが動かない

-The `HostPort` and `HostIP` functionality is available depending on your Pod Network
-provider. Please contact the author of the Pod Network solution to find out whether
-`HostPort` and `HostIP` functionality are available.
+`HostPort`と`HostIP`の機能は、ご使用のPodネットワークプロバイダによって利用可能です。Podネットワークソリューションの作者に連絡して、`HostPort`と`HostIP`機能が利用可能かどうかを確認してください。

-Calico, Canal, and Flannel CNI providers are verified to support HostPort.
+Calico、Canal、FlannelのCNIプロバイダは、HostPortをサポートしていることが確認されています。

-For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
+詳細については、[CNI portmap documentation] (https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md) を参照してください。

-If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of
-services](/ja/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`.
+ネットワークプロバイダが portmap CNI プラグインをサポートしていない場合は、[NodePortサービス](/ja/docs/concepts/services-networking/service/#nodeport)を使用するか、`HostNetwork=true`を使用してください。

 ## サービスIP経由でPodにアクセスすることができない

- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
-  which allows pods to access themselves via their Service IP. This is an issue related to
-  [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
-  add-on provider to get the latest status of their support for hairpin mode.
+- 多くのネットワークアドオンは、PodがサービスIPを介して自分自身にアクセスできるようにする[ヘアピンモード](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)を有効にしていません。これは[CNI](https://github.com/containernetworking/cni/issues/476)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。

- If you are using VirtualBox (directly or via Vagrant), you will need to
-  ensure that `hostname -i` returns a routable IP address. By default the first
-  interface is connected to a non-routable host-only network. A work around
-  is to modify `/etc/hosts`, see this [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)
-  for an example.
+- VirtualBoxを使用している場合(直接またはVagrant経由)は、`hostname -i`がルーティング可能なIPアドレスを返すことを確認する必要があります。デフォルトでは、最初のインターフェースはルーティング可能でないホスト専用のネットワークに接続されています。これを回避するには`/etc/hosts`を修正する必要があります。例としてはこの[Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)を参照してください。

 ## TLS証明書のエラー

-The following error indicates a possible certificate mismatch.
+以下のエラーは、証明書の不一致の可能性を示しています。

 ```none
 # kubectl get pods
 Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
 ```

- Verify that the `$HOME/.kube/config` file contains a valid certificate, and
-  regenerate a certificate if necessary. The certificates in a kubeconfig file
-  are base64 encoded. The `base64 --decode` command can be used to decode the certificate
-  and `openssl x509 -text -noout` can be used for viewing the certificate information.
- Unset the `KUBECONFIG` environment variable using:
+- `HOME/.kube/config`ファイルに有効な証明書が含まれていることを確認し、必要に応じて証明書を再生成します。kubeconfigファイル内の証明書はbase64でエンコードされています。証明書をデコードするには`base64 --decode`コマンドを、証明書情報を表示するには`openssl x509 -text -noout`コマンドを用いてください。
+- 環境変数`KUBECONFIG`の設定を解除するには以下のコマンドを実行するか:

  ```sh
  unset KUBECONFIG
  ```

-  Or set it to the default `KUBECONFIG` location:
+  設定をデフォルトの`KUBECONFIG`の場所に設定します:

  ```sh
  export KUBECONFIG=/etc/kubernetes/admin.conf
  ```

- Another workaround is to overwrite the existing `kubeconfig` for the "admin" user:
+- もう一つの回避策は、既存の`kubeconfig`を"admin"ユーザに上書きすることです:

  ```sh
  mv  $HOME/.kube $HOME/.kube.bak
@@ -177,38 +184,38 @@ Unable to connect to the server: x509: certificate signed by unknown authority (

 ## Vagrant内でPodネットワークとしてflannelを使用する時のデフォルトNIC

-The following error might indicate that something was wrong in the pod network:
+以下のエラーは、Podネットワークに何か問題があったことを示している可能性を示しています:

 ```sh
 Error from server (NotFound): the server could not find the requested resource
 ```

- If you're using flannel as the pod network inside Vagrant, then you will have to specify the default interface name for flannel.
+- Vagrant内のPodネットワークとしてflannelを使用している場合は、flannelのデフォルトのインターフェース名を指定する必要があります。

-  Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed.
+  Vagrantは通常、2つのインターフェースを全てのVMに割り当てます。1つ目は全てのホストにIPアドレス`10.0.2.15`が割り当てられており、NATされる外部トラフィックのためのものです。

-  This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen.
+  これは、ホストの最初のインターフェイスをデフォルトにしているflannelの問題につながるかもしれません。これは、すべてのホストが同じパブリックIPアドレスを持っていると考えます。これを防ぐには、2番目のインターフェイスが選択されるように `--iface eth1`フラグをflannelに渡してください。

 ## 公開されていないIPがコンテナに使われている

-In some situations `kubectl logs` and `kubectl run` commands may return with the following errors in an otherwise functional cluster:
+状況によっては、`kubectl logs`や`kubectl run`コマンドが以下のようなエラーを返すことがあります:

 ```sh
 Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
 ```

- This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider.
- DigitalOcean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one.
+- これには、おそらくマシンプロバイダのポリシーによって、一見同じサブネット上の他のIPと通信できないIPをKubernetesが使用している可能性があります。
+- DigitalOceanはパブリックIPとプライベートIPを`eth0`に割り当てていますが、`kubelet`はパブリックIPではなく、ノードの`InternalIP`として後者を選択します。

-  Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to DigitalOcean allows to query for the anchor IP from the droplet:
+  `ifconfig`ではエイリアスIPアドレスが表示されないため、`ifconfig`の代わりに`ip addr show`を使用してこのシナリオをチェックしてください。あるいは、DigitalOcean専用のAPIエンドポイントを使用して、ドロップレットからアンカーIPを取得することもできます:

  ```sh
  curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
  ```

-  The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using DigitalOcean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
+  回避策としては、`--node-ip`を使ってどのIPを使うかを`kubelet`に伝えることです。DigitalOceanを使用する場合、オプションのプライベートネットワークを使用したい場合は、パブリックIP（`eth0`に割り当てられている）かプライベートIP（`eth1`に割り当てられている）のどちらかを指定します。これにはkubeadm `NodeRegistrationOptions`構造体の [`KubeletExtraArgs`セクション](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) が利用できます。

-  Then restart `kubelet`:
+  `kubelet`を再起動してください:

  ```sh
  systemctl daemon-reload
@@ -217,13 +224,12 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6

 ## `coredns`のPodが`CrashLoopBackOff`もしくは`Error`状態になる

-If you have nodes that are running SELinux with an older version of Docker you might experience a scenario
-where the `coredns` pods are not starting. To solve that you can try one of the following options:
+SELinuxを実行しているノードで古いバージョンのDockerを使用している場合、`coredns` Podが起動しないということが起きるかもしれません。この問題を解決するには、以下のオプションのいずれかを試してみてください:

- Upgrade to a [newer version of Docker](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
+- [新しいDockerのバージョン](/ja/docs/setup/independent/install-kubeadm/#installing-docker)にアップグレードする。

- [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`:
+- [SELinuxを無効化する](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux)。
+- `coredns`を変更して、`allowPrivilegeEscalation`を`true`に設定:

 ```bash
 kubectl -n kube-system get deployment coredns -o yaml | \
@@ -231,108 +237,84 @@ kubectl -n kube-system get deployment coredns -o yaml | \
  kubectl apply -f -
 ```

-Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
-are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits.
+CoreDNSに`CrashLoopBackOff`が発生する別の原因は、KubernetesにデプロイされたCoreDNS Podがループを検出したときに発生します。CoreDNSがループを検出して終了するたびに、KubernetesがCoreDNS Podを再起動しようとするのを避けるために、[いくつかの回避策](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)が用意されています。

 {{< warning >}}
-Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
-the security of your cluster.
+SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスタのセキュリティが損なわれる可能性があります。
 {{< /warning >}}

 ## etcdのpodが継続的に再起動する

-If you encounter the following error:
+以下のエラーが発生した場合は:

 ```
 rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
 ```

-this issue appears if you run CentOS 7 with Docker 1.13.1.84.
-This version of Docker can prevent the kubelet from executing into the etcd container.
+この問題は、CentOS 7をDocker 1.13.1.84で実行した場合に表示されます。このバージョンのDockerでは、kubeletがetcdコンテナに実行されないようにすることができます。

-To work around the issue, choose one of these options:
+この問題を回避するには、以下のいずれかのオプションを選択します:

- Roll back to an earlier version of Docker, such as 1.13.1-75
+- 1.13.1-75のような以前のバージョンのDockerにロールバックする
 ```
 yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
 ```

- Install one of the more recent recommended versions, such as 18.06:
+- 18.06のような最新の推奨バージョンをインストールする:
 ```bash
 sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
 yum install docker-ce-18.06.1.ce-3.el7.x86_64
 ```

-## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
+## コンマで区切られた値のリストを`--component-extra-args`フラグ内の引数に渡すことができない

-`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
-component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
-the values (`mapStringString`).
+`-component-extra-args`のような`kubeadm init`フラグを使うと、kube-apiserverのようなコントロールプレーンコンポーネントにカスタム引数を渡すことができます。しかし、このメカニズムは値の解析に使われる基本的な型 (`mapStringString`) のために制限されています。

-If you decide to pass an argument that supports multiple, comma-separated values such as
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
-`flag: malformed pair, expect string=string`. This happens because the list of arguments for
-`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
-as a key that is missing a value.
+もし、`--apiserver-extra-args "enable-admission plugins=LimitRanger,NamespaceExists"`のようにカンマで区切られた複数の値をサポートする引数を渡した場合、このフラグは`flag: malformed pair, expect string=string`で失敗します。これは`--apiserver-extra-args`の引数リストが`key=value`のペアを期待しており、この場合`NamespacesExists`は値を欠いたキーとみなされるためです。

-Alternatively, you can try separating the `key=value` pairs like so:
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
-but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
+別の方法として、`key=value`のペアを以下のように分離してみることもできます:
+`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`しかし、この場合は、キー`enable-admission-plugins`は`NamespaceExists`の値しか持ちません。既知の回避策としては、kubeadm[設定ファイル](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)を使用することが挙げられます。

-A known workaround is to use the kubeadm [configuration file](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
+## cloud-controller-managerによってノードが初期化される前にkube-proxyがスケジューリングされる

-## kube-proxy scheduled before node is initialized by cloud-controller-manager
+クラウドプロバイダのシナリオでは、クラウドコントローラマネージャがノードアドレスを初期化する前に、kube-proxyが新しいワーカーノードでスケジューリングされてしまうことがあります。これにより、kube-proxyがノードのIPアドレスを正しく拾えず、ロードバランサを管理するプロキシ機能に悪影響を及ぼします。

-In cloud provider scenarios, kube-proxy can end up being scheduled on new worker nodes before
-the cloud-controller-manager has initialized the node addresses. This causes kube-proxy to fail
-to pick up the node's IP address properly and has knock-on effects to the proxy function managing
-load balancers.
-
-The following error can be seen in kube-proxy Pods:
+kube-proxy Podsでは以下のようなエラーが発生します:
 ```
 server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
 proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
 ```

-A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on control-plane
-nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
-conditions abate:
+既知の解決策は、初期のガード条件が緩和されるまで他のノードから離しておき、条件に関係なくコントロールプレーンノード上でスケジューリングできるように、キューブプロキシDaemonSetにパッチを当てることです:
+
 ```
 kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
 ```

-The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).
+Tこの問題のトラッキング問題は[こちら](https://github.com/kubernetes/kubeadm/issues/1027)。

-## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
+## kubeadmの設定をマーシャリングする際、NodeRegistration.Taintsフィールドが省略される

-*Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.*
+*注意: この[Issue](https://github.com/kubernetes/kubeadm/issues/1358)は、kubeadmタイプをマーシャルするツール(YAML設定ファイルなど)にのみ適用されます。これはkubeadm API v1beta2で修正される予定です。*

-By default, kubeadm applies the `node-role.kubernetes.io/master:NoSchedule` taint to control-plane nodes.
-If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice,
-the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint.
+デフォルトでは、kubeadmはコントロールプレーンノードに`node-role.kubernetes.io/master:NoSchedule`のテイントを適用します。kubeadmがコントロールプレーンノードに影響を与えないようにし、`InitConfiguration.NodeRegistration.Taints`を空のスライスに設定すると、マーシャリング時にこのフィールドは省略されます。フィールドが省略された場合、kubeadmはデフォルトのテイントを適用します。

-There are at least two workarounds:
+少なくとも2つの回避策があります:

-1. Use the `node-role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity.
+1. 空のスライスの代わりに`node-role.kubernetes.io/master:PreferNoSchedule`テイントを使用します。他のノードに容量がない限り、[Podsはマスター上でスケジュールされます](/docs/concepts/scheduling-eviction/taint-and-toleration/)。

-2. Remove the taint after kubeadm init exits:
+2. kubeadm init終了後のテイントの除去:
 ```bash
 kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
 ```

-## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}
+## ノード{#usr-mounted-read-only}に`/usr`が読み取り専用でマウントされる

-On Linux distributions such as Fedora CoreOS, the directory `/usr` is mounted as a read-only filesystem.
-For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md),
-Kubernetes components like the kubelet and kube-controller-manager use the default path of
-`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_
-for the feature to work.
+Fedora CoreOSなどのLinuxディストリビューションでは、ディレクトリ`/usr`が読み取り専用のファイルシステムとしてマウントされます。 [flex-volumeサポート](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md)では、kubeletやkube-controller-managerのようなKubernetesコンポーネントはデフォルトで`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`のパスを使用していますが、この機能を動作させるためにはflex-volumeディレクトリは _書き込み可能_ な状態でなければなりません。

-To workaround this issue you can configure the flex-volume directory using the kubeadm
-[configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2).
+この問題を回避するには、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用してflex-volumeディレクトリを設定します。

-On the primary control-plane Node (created using `kubeadm init`) pass the following
-file using `--config`:
+プライマリコントロールプレーンノード（`kubeadm init`で作成されたもの）上で、`--config`で以下のファイルを渡します:

 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
@@ -348,7 +330,7 @@ controllerManager:
    flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
 ```

-On joining Nodes:
+ノードをジョインするには:

 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
@@ -358,5 +340,9 @@ nodeRegistration:
    volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
 ```

-Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please
-be advised that this is modifying a design principle of the Linux distribution.
+あるいは、`/usr`マウントを書き込み可能にするために `/etc/fstab`を変更することもできますが、これはLinuxディストリビューションの設計原理を変更していることに注意してください。
+
+## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する
+このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
+
+この問題はバージョン1.19で修正されます。
@@ -8,7 +8,7 @@ weight: 30

 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-sigs/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](https://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
@@ -21,7 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
  * openSUSE Leap 15
 * continuous integration tests

-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/).
+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/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).



@@ -50,7 +51,7 @@ Kubespray provides the following utilities to help provision your environment:

 ### (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-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](https://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) クラスタ作成の計画

@@ -68,7 +69,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
  * {{< 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.
+Kubespray customizations can be made to a [variable file](https://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.

 ### (4/5) クラスタのデプロイ

@@ -110,7 +111,7 @@ When running the reset playbook, be sure not to accidentally target your product

 ## フィードバック

-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
 * [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)


@@ -20,9 +20,7 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス

 * [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。

-* [CoreOS Tectonic](https://coreos.com/tectonic/)はAWS上のContainer Linuxノードを含むKubernetesクラスターを作成できる、オープンソースの[Tectonic Installer](https://github.com/coreos/tectonic-installer)を含みます。
-
-* CoreOSから生まれ、Kubernetes IncubatorがメンテナンスしているCLIツール[kube-aws](https://github.com/kubernetes-incubator/kube-aws)は、[Container Linux](https://coreos.com/why/)ノードを使用したAWSツール(EC2、CloudFormation、Auto Scaling)によるKubernetesクラスターを作成および管理できます。
+* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) EC2、CloudFormation、Auto Scalingを使用して、[Flatcar Linux](https://www.flatcar-linux.org/)ノードでKubernetesクラスターを作成および管理します。

 * [KubeOne](https://github.com/kubermatic/kubeone)は可用性の高いKubernetesクラスターを作成、アップグレード、管理するための、オープンソースのライフサイクル管理ツールです。

@@ -46,10 +44,10 @@ export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
 export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
 ```

-ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/user-guide/kubectl/)
+ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/reference/kubectl/kubectl/)

 デフォルトでは、`kubectl`はクラスターの起動中に生成された`kubeconfig`ファイルをAPIに対する認証に使用します。
-詳細な情報は、[kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。
+詳細な情報は、[kubeconfig files](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。

 ### 例

@@ -61,7 +59,7 @@ export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH

 ## クラスターのスケーリング

-`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。
+`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。

 ## クラスターの解体

@@ -77,12 +75,8 @@ cluster/kube-down.sh
 IaaS プロバイダー    | 構成管理     | OS            | ネットワーク  | ドキュメント                                  | 適合     | サポートレベル
 -------------------- | ------------ | ------------- | ------------  | --------------------------------------------- | ---------| ----------------------------
 AWS                  | kops         | Debian        | k8s (VPC)     | [docs](https://github.com/kubernetes/kops)    |          | Community ([@justinsb](https://github.com/justinsb))
-AWS                  | CoreOS       | CoreOS        | flannel       | [docs](/docs/getting-started-guides/aws)      |          | Community
-AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | [docs](/docs/getting-started-guides/ubuntu)      | 100%     | Commercial, Community
+AWS                  | CoreOS       | CoreOS        | flannel     | -  |          | Community
+AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | - | 100%     | Commercial, Community
 AWS                  | KubeOne         | Ubuntu, CoreOS, CentOS   | canal, weavenet     | [docs](https://github.com/kubermatic/kubeone)      | 100%    | Commercial, Community

-## 参考文献
-
-Kubernetesクラスターの利用と管理に関する詳細は、[Kubernetesドキュメント](/ja/docs/)を参照してください。
-

@@ -1,340 +0,0 @@
---
-title: CenturyLink Cloud上でKubernetesを動かす
---
-
-
-These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
-
-You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
-
-## ヘルプの検索
-
-If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
-
- Submit a github issue
- Send an email to Kubernetes AT ctl DOT io
- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
-
-## 仮想マシンもしくは物理サーバーのクラスター、その選択
-
- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag.
- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
- Physical serves are only available in the VA1 and GB3 data centers.
- VMs are available in all 13 of our public cloud locations
-
-## 必要条件
-
-The requirements to run this script are:
-
- A linux administrative host (tested on ubuntu and macOS)
- python 2 (tested on 2.7.11)
-  - pip (installed with python as of 2.7.9)
- git
- A CenturyLink Cloud account with rights to create new hosts
- An active VPN connection to the CenturyLink Cloud from your linux host
-
-## スクリプトのインストール
-
-After you have all the requirements met, please follow these instructions to install this script.
-
-1) Clone this repository and cd into it.
-
-```shell
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc
-```
-
-2) Install all requirements, including
-
-  * Ansible
-  * CenturyLink Cloud SDK
-  * Ansible Modules
-
-```shell
-sudo pip install -r ansible/requirements.txt
-```
-
-3) Create the credentials file from the template and use it to set your ENV variables
-
-```shell
-cp ansible/credentials.sh.template ansible/credentials.sh
-vi ansible/credentials.sh
-source ansible/credentials.sh
-
-```
-
-4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)
-
-
-#### スクリプトのインストールの例: Ububtu 14の手順
-
-If you use an ubuntu 14, for your convenience we have provided a step by step
-guide to install the requirements and install the script.
-
-```shell
-# system
-apt-get update
-apt-get install -y git python python-crypto
-curl -O https://bootstrap.pypa.io/get-pip.py
-python get-pip.py
-
-# installing this repository
-mkdir -p ~home/k8s-on-clc
-cd ~home/k8s-on-clc
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git
-cd adm-kubernetes-on-clc/
-pip install -r requirements.txt
-
-# getting started
-cd ansible
-cp credentials.sh.template credentials.sh; vi credentials.sh
-source credentials.sh
-```
-
-
-
-## クラスターの作成
-
-To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete
-list of script options and some examples are listed below.
-
-```shell
-CLC_CLUSTER_NAME=[name of kubernetes cluster]
-cd ./adm-kubernetes-on-clc
-bash kube-up.sh -c="$CLC_CLUSTER_NAME"
-```
-
-It takes about 15 minutes to create the cluster. Once the script completes, it
-will output some commands that will help you setup kubectl on your machine to
-point to the new cluster.
-
-When the cluster creation is complete, the configuration files for it are stored
-locally on your administrative host, in the following directory
-
-```shell
-> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/
-```
-
-
-#### クラスターの作成: スクリプトのオプション
-
-```shell
-Usage: kube-up.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
-All options (both short and long form) require arguments, and must include "="
-between option name and option value.
-
-     -h (--help)                   display this help and exit
-     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
-     -t= (--minion_type=)          standard -> VM (default), bareMetal -> physical]
-     -d= (--datacenter=)           VA1 (default)
-     -m= (--minion_count=)         number of kubernetes minion nodes
-     -mem= (--vm_memory=)          number of GB ram for each minion
-     -cpu= (--vm_cpu=)             number of virtual cps for each minion node
-     -phyid= (--server_conf_id=)   physical server configuration id, one of
-                                      physical_server_20_core_conf_id
-                                      physical_server_12_core_conf_id
-                                      physical_server_4_core_conf_id (default)
-     -etcd_separate_cluster=yes    create a separate cluster of three etcd nodes,
-                                   otherwise run etcd on the master node
-```
-
-## クラスターの拡張
-
-To expand an existing Kubernetes cluster, run the ```add-kube-node.sh```
-script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options).
-This script must be run from the same host that created the cluster (or a host
-that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```).
-
-```shell
-cd ./adm-kubernetes-on-clc
-bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2
-```
-
-#### クラスターの拡張: スクリプトのオプション
-
-```shell
-Usage: add-kube-node.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and add to an
-existing CLC kubernetes cluster
-
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
-     -h (--help)                   display this help and exit
-     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
-     -m= (--minion_count=)         number of kubernetes minion nodes to add
-```
-
-## クラスターの削除
-
-There are two ways to delete an existing cluster:
-
-1) Use our python script:
-
-```shell
-python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1
-```
-
-2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink
-Cloud control portal and delete the parent server group that contains the
-Kubernetes Cluster. We hope to add a scripted option to do this soon.
-
-## 例
-
-Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
-```
-
-Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
-```
-
-Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
-```
-
-
-
-## クラスターの機能とアーキテクチャ
-
-We configure the Kubernetes cluster with the following features:
-
-* KubeDNS: DNS resolution and service discovery
-* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
-* Grafana: Kubernetes/Docker metric dashboard
-* KubeUI: Simple web interface to view Kubernetes state
-* Kube Dashboard: New web interface to interact with your cluster
-
-We use the following to create the Kubernetes cluster:
-
-* Kubernetes 1.1.7
-* Ubuntu 14.04
-* Flannel 0.5.4
-* Docker 1.9.1-0~trusty
-* Etcd 2.2.2
-
-## 任意のアドオン
-
-* Logging: We offer an integrated centralized logging ELK platform so that all
-  Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack
-  and configure Kubernetes to send logs to it, follow [the log
-  aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as
-  the footprint isn't trivial.
-
-## クラスターの管理
-
-The most widely used tool for managing a Kubernetes cluster is the command-line
-utility ```kubectl```.  If you do not already have a copy of this binary on your
-administrative machine, you may run the script ```install_kubectl.sh``` which will
-download it and install it in ```/usr/bin/local```.
-
-The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary
-authentication certificates for the particular cluster.  The configuration file is
-written to the  ```${CLC_CLUSTER_HOME}/kube``` directory
-
-
-```shell
-export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
-kubectl version
-kubectl cluster-info
-```
-
-### プログラムでクラスターへアクセス
-
-It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice.
-
-To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https:
-
-```shell
-curl \
-   --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt  \
-   --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \
-   --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt  https://${MASTER_IP}:6443
-```
-
-But please note, this *does not* work out of the box with the ```curl``` binary
-distributed with macOS.
-
-### ブラウザーを使ったクラスターへのアクセス
-
-We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you
-create a cluster, the script should output URLs for these interfaces like this:
-
-kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.
-
-Note on Authentication to the UIs:
-
-The cluster is set up to use basic authentication for the user _admin_.
-Hitting the url at ```https://${MASTER_IP}:6443``` will
-require accepting the self-signed certificate
-from the apiserver, and then presenting the admin
-password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
-
-
-### 設定ファイル
-
-Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
-to access the cluster from machines other than where you created the cluster from.
-
-* ```config/```: Ansible variable files containing parameters describing the master and minion hosts
-* ```hosts/```: hosts files listing access information for the Ansible playbooks
-* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API
-* ```pki/```: public key infrastructure files enabling TLS communication in the cluster
-* ```ssh/```: SSH keys for root access to the hosts
-
-
-## ```kubectl``` usage examples
-
-There are a great many features of _kubectl_.  Here are a few examples
-
-List existing nodes, pods, services and more, in all namespaces, or in just one:
-
-```shell
-kubectl get nodes
-kubectl get --all-namespaces pods
-kubectl get --all-namespaces services
-kubectl get --namespace=kube-system replicationcontrollers
-```
-
-The Kubernetes API server exposes services on web URLs, which are protected by requiring
-client certificates.  If you run a kubectl proxy locally, ```kubectl``` will provide
-the necessary certificates and serve locally over http.
-
-```shell
-kubectl proxy -p 8001
-```
-
-Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser.
-
-
-## どのKubernetesの機能がCenturyLink Cloud上で動かないのか
-
-These are the known items that don't work on CenturyLink cloud but do work on other cloud providers:
-
- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016.
-
- At this time, there is no support for persistent storage volumes provided by
-  CenturyLink Cloud. However, customers can bring their own persistent storage
-  offering. We ourselves use Gluster.
-
-
-## Ansibleのファイル
-
-If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
-
-## 参考文献
-
-Please see the [Kubernetes docs](/ja/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
-
@@ -67,7 +67,7 @@ cluster/kube-up.sh
 If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.

 If you run into trouble, please see the section on [troubleshooting](/ja/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
-[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.

 The next few steps will show you:

@@ -80,7 +80,7 @@ The next few steps will show you:

 The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.

-The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster
+The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
 manager.  It lets you inspect your cluster resources, create, delete, and update
 components, and much more. You will use it to look at your new cluster and bring
 up example apps.
@@ -93,7 +93,7 @@ gcloud components install kubectl

 {{< note >}}
 The kubectl version bundled with `gcloud` may be older than the one
-downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
+The [kubectl](/ja/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
 document to see how you can set up the latest `kubectl` on your workstation.
 {{< /note >}}

@@ -107,7 +107,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru
 kubectl get --all-namespaces services
 ```

-should show a set of [services](/docs/user-guide/services) that look something like this:
+should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:

 ```shell
 NAMESPACE     NAME          TYPE             CLUSTER_IP       EXTERNAL_IP       PORT(S)        AGE
@@ -117,7 +117,7 @@ kube-system   kube-ui       ClusterIP        10.0.0.3         <none>
 ...
 ```

-Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/ja/docs/concepts/workloads/pods/) that were created during cluster startup.
 You can do this via the

 ```shell
@@ -144,7 +144,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh

 ### いくつかの例の実行

-Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
+Then, see [a simple nginx example](/ja/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.

 For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/).  The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.

@@ -215,10 +215,3 @@ IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs
 -------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
 GCE                  | Saltstack    | Debian | GCE         | [docs](/ja/docs/setup/production-environment/turnkey/gce/)                                    |   | Project

-
-## 参考文献
-
-Please see the [Kubernetes docs](/ja/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
@@ -25,13 +25,9 @@ The following modules are available where you can deploy IBM Cloud Private by us

 ## AWS上でのIBM Cloud Private

-You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform.
+You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) using Terraform.

-IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide.
-
-This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/).
-
-IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md).
+IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws).

 ## Azure上でのIBM Cloud Private

@@ -64,4 +60,4 @@ You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. F

 The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud.

-For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/services/vmwaresolutions/vmonic?topic=vmware-solutions-prod_overview#ibm-cloud-private-hosted).
+For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview).
@@ -14,7 +14,7 @@ Windowsアプリケーションは、多くの組織で実行されているサ

 ## KubernetesのWindowsコンテナ

-KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。
+KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの{{< glossary_tooltip text="Pod" term_id="pod" >}}でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。

 Windowsコンテナを実行するには、Kubernetesクラスターに複数のオペレーティングシステムを含める必要があります。コントロールプレーンノードはLinux、ワーカーノードはワークロードのニーズに応じてWindowsまたはLinuxで実行します。Windows Server 2019は、サポートされている唯一のWindowsオペレーティングシステムであり、Windows (kubelet、[コンテナランタイム](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、kube-proxyを含む)で[Kubernetesノード](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)を有効にします。Windowsディストリビューションチャンネルの詳細については、[Microsoftのドキュメント](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)を参照してください。

@@ -52,7 +52,7 @@ Windows Serverホストオペレーティングシステムには、[Windows Ser

 Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能します。このセクションでは、主要なワークロードイネーブラーのいくつかと、それらがWindowsにどのようにマップされるかについて説明します。

-* [Pods](/ja/docs/concepts/workloads/pods/pod-overview/)
+* [Pods](/ja/docs/concepts/workloads/pods/)

    Podは、Kubernetesにおける最も基本的な構成要素です。人間が作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最もシンプルな単位です。WindowsとLinuxのコンテナを同じPodにデプロイすることはできません。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャを表す単一のノードにスケジュールされます。次のPod機能、プロパティ、およびイベントがWindowsコンテナでサポートされています。:

@@ -96,7 +96,27 @@ Pod、Controller、Serviceは、KubernetesでWindowsワークロードを管理

 #### コンテナランタイム

-KubernetesのWindows Server 2019/1809ノードでは、Docker EE-basic 18.09が必要です。これは、kubeletに含まれているdockershimコードで動作します。CRI-ContainerDなどの追加のランタイムは、Kubernetesの以降のバージョンでサポートされる可能性があります。
+##### Docker EE
+
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
+
+Docker EE-basic 18.09+は、Kubernetesを実行しているWindows Server 2019 / 1809ノードに推奨されるコンテナランタイムです。kubeletに含まれるdockershimコードで動作します。
+
+##### CRI-ContainerD
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+ContainerDはLinux上のKubernetesで動作するOCI準拠のランタイムです。Kubernetes v1.18では、Windows上での{{< glossary_tooltip term_id="containerd" text="ContainerD" >}}のサポートが追加されています。Windows上でのContainerDの進捗状況は[enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001)で確認できます。
+
+{{< caution >}}
+
+Kubernetes v1.18におけるWindows上でのContainerDは以下の既知の欠点があります:
+
+* ContainerDは公式リリースではWindowsをサポートしていません。すなわち、Kubernetesでのすべての開発はアクティブなContainerD開発ブランチに対して行われています。本番環境へのデプロイは常に、完全にテストされセキュリティ修正をサポートした公式リリースを利用するべきです。
+* ContainerDを利用した場合、Group Managed Service Accountsは実装されていません。詳細は[containerd/cri#1276](https://github.com/containerd/cri/issues/1276)を参照してください。
+
+{{< /caution >}}
+

 #### 永続ストレージ

@@ -404,7 +424,6 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

        # kubelet.exeを登録
        # マイクロソフトは、mcr.microsoft.com/k8s/core/pause:1.2.0としてポーズインフラストラクチャコンテナをリリース
-        # 詳細については、「KubernetesにWindowsノードを追加するためのガイド」で「pause」を検索してください
        nssm install kubelet C:\k\kubelet.exe
        nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
        nssm set kubelet AppDirectory C:\k
@@ -516,7 +535,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

    PauseイメージがOSバージョンと互換性があることを確認してください。[説明](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)では、OSとコンテナの両方がバージョン1803であると想定しています。それ以降のバージョンのWindowsを使用している場合は、Insiderビルドなどでは、それに応じてイメージを調整する必要があります。イメージについては、Microsoftの[Dockerレジストリ](https://hub.docker.com/u/microsoft/)を参照してください。いずれにしても、PauseイメージのDockerfileとサンプルサービスの両方で、イメージに:latestのタグが付けられていると想定しています。

-    Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。詳細については、[KubernetesにWindowsノードを追加するためのガイド](../user-guide-windows-nodes)で「Pause」を検索してください。
+    Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。

 1. DNS名前解決が正しく機能していない

@@ -539,7 +558,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

    Kubernetes Podでは、インフラストラクチャまたは「pause」コンテナが最初に作成され、コンテナエンドポイントをホストします。インフラストラクチャやワーカーコンテナなど、同じPodに属するコンテナは、共通のネットワークネームスペースとエンドポイント（同じIPとポートスペース）を共有します。Pauseコンテナは、ネットワーク構成を失うことなくクラッシュまたは再起動するワーカーコンテナに対応するために必要です。

-    「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)をご覧ください。
+    「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)をご覧ください。

 ### さらなる調査

@@ -568,18 +587,16 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

 ロードマップには多くの機能があります。高レベルの簡略リストを以下に示しますが、[ロードマッププロジェクト](https://github.com/orgs/kubernetes/projects/8)を見て、[貢献すること](https://github.com/kubernetes/community/blob/master/sig-windows/)によってWindowsサポートを改善することをお勧めします。

-### CRI-ContainerD

-{{< glossary_tooltip term_id="containerd" >}}は、最近{{< glossary_tooltip text="CNCF" term_id="cncf" >}}プロジェクトとして卒業した、もう1つのOCI準拠ランタイムです。現在Linuxでテストされていますが、1.3はWindowsとHyper-Vをサポートします。[[リファレンス](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)]
+### Hyper-V分離

-CRI-ContainerDインターフェイスは、Hyper-Vに基づいてサンドボックスを管理できるようになります。これにより、RuntimeClassを次のような新しいユースケースに実装できる基盤が提供されます:
+Hyper-V分離はKubernetesで以下のWindowsコンテナのユースケースを実現するために必要です。

 * Pod間のハイパーバイザーベースの分離により、セキュリティを強化
 * 下位互換性により、コンテナの再構築を必要とせずにノードで新しいWindows Serverバージョンを実行
 * Podの特定のCPU/NUMA設定
 * メモリの分離と予約

-### Hyper-V分離

 既存のHyper-V分離サポートは、v1.10の試験的な機能であり、上記のCRI-ContainerD機能とRuntimeClass機能を優先して将来廃止される予定です。現在の機能を使用してHyper-V分離コンテナを作成するには、kubeletのフィーチャーゲートを`HyperVContainer=true`で開始し、Podにアノテーション`experimental.windows.kubernetes.io/isolation-type=hyperv`を含める必要があります。実験的リリースでは、この機能はPodごとに1つのコンテナに制限されています。

@@ -609,7 +626,7 @@ spec:

 ### kubeadmとクラスターAPIを使用したデプロイ

-Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。
+Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは進行中ですが、ガイドはすでに[ここ](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)で利用可能です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。

 ### その他の主な機能
 * グループ管理サービスアカウントのベータサポート
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Kubernetes Prow Robot	e20b8746f2	Merge pull request #29220 from PI-Victor/config/update-release-1.18 Update config.toml for release-1.18 branch	2021-08-04 15:55:12 -07:00
Victor Palade	3e9e868445	config.toml: update dropdown This commit will bump all the versions according to the latest release patches. Signed-off-by: Victor Palade <victor@cloudflavor.io>	2021-08-04 19:39:24 +02:00
Kubernetes Prow Robot	e79e9b918a	Merge pull request #28778 from ialidzhikov/automated-cherry-pick-of-#28763-origin-release-1.18 Automated cherry pick of #28763: Fix default disk type for Azure	2021-07-27 18:33:35 -07:00
ialidzhikov	1bf1e75b43	Fix default disk type for Azure Signed-off-by: ialidzhikov <i.alidjikov@gmail.com>	2021-07-03 23:28:59 +03:00
Kubernetes Prow Robot	5f2fb6173d	Merge pull request #28130 from kubernetes/release-1.18-ja.1 Commit work from 1.18 milestone	2021-05-30 19:46:26 -07:00
inductor	beddfbc9a6	add glossary	2021-05-26 13:50:29 +00:00
inductor	63bfad9d85	fix script	2021-05-26 13:40:43 +00:00
inductor	312f2bafef	sync submodule	2021-05-26 13:38:10 +00:00
inductor	8ba43eb386	delete endpoint slices	2021-05-26 13:35:41 +00:00
inductor	c31af9b03c	remove some additional uncecessary files	2021-05-26 13:33:45 +00:00
inductor	d322844be6	remove some pages	2021-05-26 13:27:24 +00:00
inductor	7332a28c24	revert case studies	2021-05-26 13:20:28 +00:00
inductor	c60df272cb	Merge upstream work for release-1.19	2021-05-26 10:16:04 +00:00
Kubernetes Prow Robot	d0903bdfa0	Merge pull request #27453 from reylejano/update-release-1.18-config.toml Update 1.18 config.toml for release 1.21	2021-04-08 12:30:03 -07:00
Rey Lejano	76689fda9b	update release-1.18 config.toml for release 1.21	2021-04-07 15:54:57 -07:00
Kubernetes Prow Robot	79d7dbd723	Merge pull request #26978 from kubernetes/backport-node-assign ja: Backport node assign	2021-03-17 10:01:58 -07:00
Kazuki Suda	bb240e29e5	ja: Fix the translation about nodeSelectorTerms of Node affinity	2021-03-10 02:53:51 +00:00
Kubernetes Prow Robot	337f16b0fd	Merge pull request #25885 from sculley/fix-upgrade-kubeadm-docs-release-1.18 re-positioned drain/uncorden steps in kubeadm upgrade docs in release-1.18	2020-12-31 16:25:52 -08:00
Sam Culley	91cff33a6c	re-positioned drain/uncorden steps in kubeadm upgrade docs	2020-12-31 07:13:22 +00:00
Kubernetes Prow Robot	46fdf32635	Merge pull request #25557 from kbhawkey/fix-latest-1.18 release-1.18, fix latest version to deprecated version	2020-12-14 03:05:28 -08:00
Karen Bradshaw	16d39bf577	modify latest to deprecated version replace latest-version shortcode	2020-12-13 19:44:02 -05:00
Kubernetes Prow Robot	b03fcb5896	Merge pull request #25574 from sftim/20201210_match_api_reference_to_version_1.18 Match API reference to version of Kubernetes we're documenting	2020-12-13 15:01:27 -08:00
Tim Bannister	d9b6db476a	Match API reference to version of Kubernetes we're documenting	2020-12-11 17:32:50 +00:00
Kubernetes Prow Robot	db141bdf45	Merge pull request #25390 from annajung/release-1.18 Update 1.18 config.toml for release 1.20	2020-12-08 14:09:35 -08:00
Kubernetes Prow Robot	1891156155	Merge pull request #25395 from jiaj12/patch-34 update typo	2020-12-05 02:15:25 -08:00
jiajie	f9456a4344	update typo	2020-12-04 11:08:36 +08:00
Anna Jung (VMware)	9379cba0be	Update config.toml for release 1.20	2020-12-03 17:50:58 -06:00
Kubernetes Prow Robot	2ec37ce382	Merge pull request #25104 from mysunshine92/Fix-1.18-Release-Notes v1.18 Release Notes: Fix kubelet flag enable-cadvisor-json-endpoints	2020-11-25 21:54:21 -08:00
wangyamei	a3723655db	v1.18 Release Notes: Fix kubelet flag enable-cadvisor-json-endpoints	2020-11-18 23:26:06 +08:00
Kubernetes Prow Robot	6c87e3c77e	Merge pull request #23925 from kubernetes/dev-1.18-ko.11 Eleventh Korean l10n work for release-1.18	2020-09-16 18:22:45 -07:00
Daehyun Paik	2a94b058ce	Eleventh Korean l10n work for release 1.18 - Update outdated files in the dev-1.18-ko.11 branch (#23643) - Fix inconsistent translation in Ko (#23683) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Daehyun Paik <paik@a30a.dev>	2020-09-16 23:52:34 +09:00
Kubernetes Prow Robot	e79459a064	Merge pull request #23666 from sftim/v1.18-backport-available-docs-versions Revise list of available documentation versions (v1.18)	2020-09-03 16:21:41 -07:00
Tim Bannister	b0469e6de0	Revise list of available documentation versions For older releases, the previous rendering wasn't quite right. Implement a custom layout for the supported versions list This commit does NOT remove the shortcode named {{< versions-other >}} because it is still used in some localizations.	2020-09-02 20:48:49 +01:00
Kubernetes Prow Robot	b4485527d8	Merge pull request #23633 from zacharysarah/docsy-patch-1dot18 Update the theme submodule	2020-08-31 21:41:51 -07:00
zacharysarah	129cb53c35	Update the theme submodule	2020-08-31 21:27:54 -07:00
Kubernetes Prow Robot	387ac7765c	Merge pull request #23503 from sftim/20200828_remove_announcement_banner_v1.18 Disable announcement banner for v1.18 release (leaving banner on live site)	2020-08-27 17:20:17 -07:00
Tim Bannister	3213d57d9a	Disable announcement banner Announcements should display on the live documentation	2020-08-28 00:04:08 +01:00
Jim Angel	dd6768a8e1	Merge pull request #23361 from savitharaghunathan/config_update_1_18 release-1.18 branch: Updated config.toml for release v1.19	2020-08-26 14:55:17 -05:00
Jim Angel	169627295a	Merge pull request #23459 from savitharaghunathan/merged-master-release-1.18 Branch sync: Merge `master` into `release 1.18`	2020-08-26 14:27:00 -05:00
Savitha Raghunathan	46446654d0	Merge remote-tracking branch 'upstream/master' into release-1.18	2020-08-26 12:21:43 -04:00
Kubernetes Prow Robot	bdce54543f	Merge pull request #23365 from savitharaghunathan/merged-master-release-1.18 Branch sync: Merge main branch into release-1.18	2020-08-23 12:09:40 -07:00
Savitha Raghunathan	1e038098d6	Merge remote-tracking branch 'upstream/master' into release-1.18	2020-08-23 14:26:54 -04:00
Kubernetes Prow Robot	9c162a8102	Merge pull request #23362 from savitharaghunathan/merged-master-release-1.18 Branch sync: Merge master release 1.18	2020-08-23 11:07:41 -07:00
Savitha Raghunathan	889060d337	Fixing versions in config.toml for release v1.19	2020-08-23 12:00:03 -04:00
Savitha Raghunathan	e6ab65b556	Updated config.toml for release v1.19	2020-08-23 11:57:30 -04:00