Merge branch 'fix-22359' of https://github.com/hikkie3110/website into fix-22359

content/ja/docs/concepts/_index.md

@@ -19,14 +19,14 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使
 
 一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
 
-* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
+* **Kubernetes Master**: [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
 * クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。
-  * **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。
+  * **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。
-  * **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。
+  * **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。
 
-## Kubernetesオブジェクト
+## Kubernetesオブジェクト {#kubernetes-objects}
 
-Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
+Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)をご覧ください。
 
 基本的なKubernetesのオブジェクトは次のとおりです。
 
@@ -43,7 +43,7 @@ Kubernetesには、[コントローラー](/docs/concepts/architecture/controlle
 * [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
 * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 
-## Kubernetesコントロールプレーン
+## Kubernetesコントロールプレーン {#kubernetes-control-plane}
 
 Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。
 

content/ja/docs/concepts/architecture/_index.md

@@ -1,4 +1,4 @@
 ---
-title: "Kubernetesのアーキテクチャ"
+title: "クラスターのアーキテクチャ"
 weight: 30
 ---

content/ja/docs/concepts/architecture/controller.md

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

content/ja/docs/concepts/architecture/nodes.md

@@ -43,7 +43,6 @@ kubectl describe node <ノード名>
 
 | ノードのCondition | 概要 |
 |----------------|-------------|
-| `OutOfDisk`    | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 |
 | `Ready`        | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
 | `MemoryPressure`    | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
 | `PIDPressure`    | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
@@ -69,18 +68,9 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`
 
 バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
 
-バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。
+ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。
-同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。
 
-ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。
+スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。
-上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。
-
-{{< caution >}}
-
-この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。
-この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。
-
-{{< /caution >}}
 
 ### CapacityとAllocatable {#capacity}
 
@@ -91,7 +81,7 @@ allocatableブロックは、通常のPodによって消費されるノード上
 
 CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。
 
-### Info
+### Info {#info}
 
 カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。
 この情報はノードからkubeletを通じて取得されます。
@@ -114,6 +104,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で
 ```
 
 Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
+Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
 
 {{< note >}}
 Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。
@@ -136,9 +127,19 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ
 ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。
 ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。
 
-バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。
+#### ハートビート
+ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
+２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
+各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
+Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
+
+kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
+
+- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです）
+- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
+
+#### 信頼性
 
-NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。
 
 Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため）
 バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。
@@ -201,6 +202,11 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ
 これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。
 {{< /note >}}
 
+{{< caution >}}
+`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
+サービスコントローラーの副次的な効果をもたらします。これにより、ロードバランサトラフィックの流入をcordonされたノードから効率的に除去する事ができます。
+{{< /caution >}}
+
 ### ノードのキャパシティ
 
 ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。
@@ -213,6 +219,11 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な
 
 Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。
 
+## ノードのトポロジー
+
+{{< feature-state state="alpha" >}}
+`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、
+kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
 
 ## APIオブジェクト
 
@@ -220,3 +231,7 @@ NodeはKubernetesのREST APIにおけるトップレベルのリソースです
 [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
 
 
+## {{% heading "whatsnext" %}}
+
+* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。
+* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)

content/ja/docs/concepts/cluster-administration/controller-metrics.md

@@ -1,42 +0,0 @@
----
-title: コントローラーマネージャーの指標
-content_type: concept
-weight: 100
----
-
-<!-- overview -->
-コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
-
-
-
-<!-- body -->
-## コントローラーマネージャーの指標とは何か
-
-コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
-これらの指標にはgo_routineのカウントなどの一般的なGo言語ランタイムの指標と、etcdのリクエストレイテンシまたはCloudprovider（AWS、GCE、OpenStack）APIのレイテンシといったコントローラー固有の指標が含まれていて、クラスターの状態を測定するために利用できます。
-
-Kubernetes 1.7からGCE、AWS、Vsphere、OpenStackのストレージ操作の詳細なCloudproviderの指標が利用可能になりました。
-これらの指標は永続的ボリュームの操作状況を監視するために利用できます。
-
-たとえば、GCEの場合にはこれらの指標は次のように呼び出されます。
-
-```
-cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
-cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
-```
-
-
-
-## 設定
-
-クラスターではコントローラーマネージャーの指標はコントローラーマネージャーが実行されているホストの`http://localhost:10252/metrics`から取得可能です。
-
-この指標は[prometheusフォーマット](https://prometheus.io/docs/instrumenting/exposition_formats/)で出力され人間が読める形式になっています。
-
-本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。
-
-

content/ja/docs/concepts/configuration/assign-pod-node.md

@@ -7,7 +7,7 @@ weight: 30
 
 <!-- overview -->
 
-[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
+{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。
 これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。
 スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
 SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
@@ -27,7 +27,7 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ
 
 ### ステップ0: 前提条件
 
-この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](https://github.com/kubernetes/kubernetes#documentation)がされていることが前提となっています。
+この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。
 
 ### ステップ1: Nodeへのラベルの付与
 
@@ -63,17 +63,20 @@ nodeSelectorを以下のように追加します:
 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。
 `kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。
 
-## 補足: ビルトインNodeラベル
+## 補足: ビルトインNodeラベル {#built-in-node-labels}
 
 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。
 以下のようなラベルが該当します。
 
-* `kubernetes.io/hostname`
+* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
-* `failure-domain.beta.kubernetes.io/zone`
+* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
-* `failure-domain.beta.kubernetes.io/region`
+* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
-* `beta.kubernetes.io/instance-type`
+* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* `kubernetes.io/os`
+* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* `kubernetes.io/arch`
+* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
+* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
+* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
+* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
 
 {{< note >}}
 これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。
@@ -88,131 +91,127 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー
 これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。
 
 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
-Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。
+Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。
 
-1. NodeRestrictionを使用するため、Kubernetesのバージョンがv1.11以上であること。
+1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。
-2. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっていること。
+2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
-3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。
 
-## Affinity と Anti-Affinity {#affinity-and-anti-affinity}
+## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity}
 
 `nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。
-Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。
+アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。
 拡張機能は以下の通りです。
 
-1. 様々な指定方法がある ("AND条件"に限らない)
+1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。
-2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができる
+2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。
-3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができる
+3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。
 
-Affinityは"Node Affinity"と"Inter-Pod Affinity/Anti-Affinity"の2種類から成ります。
+アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。
-Node affinityは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Inter-Pod Affinity/Anti-Affinityは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。
+Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。
 
-`nodeSelector`は問題なく使用することができますが、Node affinityは`nodeSelector`で指定できる条件を全て実現できるため、将来的には推奨されなくなります。
+### Nodeアフィニティ
 
-### Node Affinity
+Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。
 
-Node Affinityはα機能としてKubernetesのv1.2から導入されました。
+現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。
-Node Affinityは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。
-
-現在は2種類のNode Affinityがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。
 前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。
 "IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも
 PodはそのNodeで稼働し続けるということです。
-将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNode Affinityに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。
+将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。
 
 それぞれの使用例として、
 `requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、
 `preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる"
 といった方法が挙げられます。
 
-Node Affinityは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。
+Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。
 
-Node Affinityを使用したPodの例を以下に示します:
+Nodeアフィニティを使用したPodの例を以下に示します:
 
 {{< codenew file="pods/pod-with-node-affinity.yaml" >}}
 
-このNode Affinityでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。
+このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。
 加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。
 
 この例ではオペレーター`In`が使われています。
-Node Affinityでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
+Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
-`NotIn`と`DoesNotExist`はNode Anti-Affinity、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
+`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
 
 `nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。
 
-`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
+`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
 
-`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。
+`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたNodeへスケジュールされます。
 
 PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。
-言い換えると、AffinityはPodをスケジュールする際にのみ考慮されます。
+言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。
 
 `preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。
-全ての必要条件(リソースやRequiredDuringScheduling Affinity等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。
+全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。
 このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。
 
-### Inter-Pod Affinity/Anti-Affinity
+### Pod間アフィニティとアンチアフィニティ
 
-Inter-Pod AffinityとAnti-Affinityは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。
+Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。
-このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(Anti-Affinityの場合は稼働させない)"という形式です。
+このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。
 Yはnamespaceのリストで指定したLabelSelectorで表されます。
 Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。
 概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。
-これらを表すためにシステムが使用するNode Labelのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。
+これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。
 先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。
 
 
 {{< note >}}
-Inter-Pod AffinityとAnti-Affinityは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。
+Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。
 そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。
 {{< /note >}}
 
 {{< note >}}
-Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。
+Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。
-例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
+言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
 それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。
 {{< /note >}}
 
-Node Affinityと同様に、Pod AffinityとPod Anti-Affinityにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
+Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
-前述のNode Affinityのセクションを参照してください。
+前述のNodeアフィニティのセクションを参照してください。
-`requiredDuringSchedulingIgnoredDuringExecution`を指定するAffinityの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。
+`requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。
-また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するAnti-Affinityの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。
+また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。
 
-Inter-Pod Affinityは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Inter-Pod Anti-Affinityは、`podAntiAffinity`で指定します。
+Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。
 
-#### Pod Affinityを使用したPodの例
+#### Podアフィニティを使用したPodの例
 
 {{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
 
-このPodのAffifnityは、Pod AffinityとPod Anti-Affinityを1つずつ定義しています。
+このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。
 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。
-Pod Affinityは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
+Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
 Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
-Pod Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
+Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
 (`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
-Pod AffinityとPod Anti-Affinityや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
+PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
 
-Pod AffinityとPod Anti-Affinityで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
+PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
 
 原則として、`topologyKey`には任意のラベルとキーが使用できます。
 しかし、パフォーマンスやセキュリティの観点から、以下の制約があります:
 
-1. Affinityと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しないことは許可されていません。
+1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。
-2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
+2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。
-3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しなかった場合、"全てのトポロジー"と解釈されます("全てのトポロジー"とは、ここでは`kubernetes.io/hostname`、`failure-domain.beta.kubernetes.io/zone`、`failure-domain.beta.kubernetes.io/region`を合わせたものを意味します)。
+3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。
 4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。
 
 `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。
-省略した場合や空の場合は、AffinityとAnti-Affinityが定義されたPodのnamespaceがデフォルトで設定されます。
+省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。
 
-`requiredDuringSchedulingIgnoredDuringExecution`が指定されたAffinityとAnti-Affinityでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 
+`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。
 
 
 #### 実際的なユースケース
 
-Inter-Pod AffinityとAnti-Affinityは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。
+Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。
 Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。
 
 
@@ -325,7 +324,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
 ##### 同じNodeに共存させない場合
 
 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。
-同様の方法で、Anti-Affinityを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。
+同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。
 
 
 ## nodeName
@@ -338,7 +337,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
  `nodeName`を使用することによる制約は以下の通りです:
 
 -   その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。
--   その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由はOutOfmemoryやOutOfcpuになります。
+-   その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。
 -   クラウド上のNodeの名前は予期できず、変更される可能性があります。
 
 `nodeName`を指定したPodの設定ファイルの例を示します:
@@ -364,8 +363,9 @@ spec:
 
 [Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
 
-[Node Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
+[Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
-[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
+[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
-には、Taintsの要点に関して様々な背景が紹介されています。
+のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。
-
 
+一度PodがNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。
+[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。

content/ja/docs/concepts/configuration/overview.md

@@ -27,7 +27,7 @@ weight: 10
 - よりよいイントロスペクションのために、オブジェクトの説明をアノテーションに入れましょう。
 
 
-## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob
+## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob {#naked-pods-vs-replicasets-deployments-and-jobs}
 
 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
 
@@ -81,7 +81,7 @@ weight: 10
 - `imagePullPolicy: Never`: 常にローカルでイメージを探そうとします。ない場合にもイメージはpullしません。
 
 {{< note >}}
-コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます(例:`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。
+コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます。`<image-name>:<tag>`を`<image-name>@<digest>`で置き換えます(例:`image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。
 {{< /note >}}
 
 {{< note >}}

content/ja/docs/concepts/containers/runtime-class.md

@@ -26,9 +26,8 @@ RuntimeClassはコンテナランタイムの設定を選択するための機
 
 ### セットアップ
 
-RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、[Feature
+RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
-Gates](/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
+その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。
-その`RuntimeClass`のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。
 
 1. ノード上でCRI実装を設定する。（ランタイムに依存）
 2. 対応するRuntimeClassリソースを作成する。
@@ -39,8 +38,8 @@ RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI
 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。
 
 {{< note >}}
-RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。
+RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのノードがコンテナランタイムに関して同じ方法で構成されていることを意味します)。
-設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/ja/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。
+設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。
 {{< /note >}}
 
 RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。
@@ -60,6 +59,9 @@ metadata:
 handler: myconfiguration  # 対応するCRI設定
 ```
 
+RuntimeClassオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)に従う必要があります。
+
+
 {{< note >}}
 RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター管理者のみに制限されることを推奨します。
 これはたいていデフォルトで有効となっています。さらなる詳細に関しては[Authorization
@@ -94,7 +96,7 @@ CRIランタイムのセットアップに関するさらなる詳細は、[CRI
 
 Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。
 
-#### [containerd](https://containerd.io/)
+#### {{< glossary_tooltip term_id="containerd" >}}
 
 ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。
 正しいハンドラーは、その`runtime`セクションで設定されます。
@@ -106,20 +108,49 @@ Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラ
 containerdの設定に関する詳細なドキュメントは下記を参照してください。  
 https://github.com/containerd/cri/blob/master/docs/config.md
 
-#### [cri-o](https://cri-o.io/)
+#### {{< glossary_tooltip term_id="cri-o" >}}
 
-ランタイムハンドラーは、`/etc/crio/crio.conf`にあるcri-oの設定ファイルにより設定されます。
+ランタイムハンドラーは、`/etc/crio/crio.conf`にあるCRI-Oの設定ファイルにより設定されます。
 正しいハンドラーは[crio.runtime
-table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。
+table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。
 
 ```
 [crio.runtime.runtimes.${HANDLER_NAME}]
   runtime_path = "${PATH_TO_BINARY}"
 ```
 
-cri-oの設定に関する詳細なドキュメントは下記を参照してください。  
+CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。
-https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
 
+[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
+
+### スケジューリング {#scheduling}
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。
+このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。
+スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。（1.16ではデフォルトです）
+
+特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。
+RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。
+もし設定が衝突した場合は、Pod作成は拒否されるでしょう。
+
+もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。
+`nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。
+
+ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。
+
+[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/
+
+### Podオーバーヘッド
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。
+`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。（デフォルトではoffです）
+
+PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。
+このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。
 
 ### RutimeClassをα版からβ版にアップグレードする
 
@@ -140,3 +171,9 @@ RuntimeClassのβ版の機能は、下記の変更点を含みます。
 - `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。
 
 
+### 参考文献
+
+- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
+- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む
+- [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)

content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -1,7 +1,7 @@
 ---
 title: カスタムリソース
 content_type: concept
-weight: 20
+weight: 10
 ---
 
 <!-- overview -->
@@ -24,7 +24,7 @@ weight: 20
 
 カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供します。カスタムリソースを *カスタムコントローラー* と組み合わせることで、カスタムリソースは真の _宣言的API_ を提供します。
 
-[宣言的API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesオブジェクトを理解する)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。
+[宣言的API](/ja/docs/concepts/overview/kubernetes-api/)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。
 コントローラーは、構造化データをユーザーが指定したあるべき状態と解釈し、その状態を管理し続けます。
 
 稼働しているクラスターのライフサイクルとは無関係に、カスタムコントローラーをデプロイ、更新することが可能です。カスタムコントローラーはあらゆるリソースと連携できますが、カスタムリソースと組み合わせると特に効果を発揮します。[オペレーターパターン](https://coreos.com/blog/introducing-operators.html)は、カスタムリソースとカスタムコントローラーの組み合わせです。カスタムコントローラーにより、特定アプリケーションのドメイン知識を、Kubernetes APIの拡張に変換することができます。
@@ -108,6 +108,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類
 ## CustomResourceDefinition
 
 [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。
+CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。
 
 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。
 
@@ -115,7 +116,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類
 
 ## APIサーバーアグリゲーション
 
-通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、また[CRD](#customresourcedefinition)を通じて、同じ方法でカスタムリソースも管理できます。
+通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。
 
 [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。
 
@@ -134,7 +135,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。
 
 | CRD                        | アグリゲートAPI |
 | -------------------------- | --------------- |
-| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要。ユーザーはCRDコントローラーとしてどの言語でも選択可能 |
+| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 |
 | 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある |
 | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない |
 | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 |
@@ -146,12 +147,12 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。
 | 機能 | 詳細 | CRD | アグリゲートAPI |
 | ---- | ---- | --- | --------------- |
 | バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 |
-| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.16でベータ)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9)を通じて可能 | はい |
+| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (ただし、この方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい |
 | 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい |
 | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい |
 | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい |
 | サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい |
-| サブリソースの状態 | <ul><li>より詳細なアクセスコントロール: ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む</li><li>カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソースがspecと、statusでセクションが分離している必要がある)</li></ul> | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい |
+| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい |
 | その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい |
 | strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
 | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい |
@@ -174,7 +175,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
 | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック |
 | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 |
 | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 |
-| 未設定 vs 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる |
+| 未設定 対 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる |
 | クライアントライブラリーの生成 | Kubernetesは、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 |
 | ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 |
 
@@ -220,5 +221,3 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl
 
 * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ
 * [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ
-
-

content/ja/docs/concepts/extend-kubernetes/extend-cluster.md

@@ -42,7 +42,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
 ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。
 結果として、ほとんどのKubernetesユーザーは既存のエクステンションを使えばよいため、新しいエクステンションを書く必要は無いと言えます。
 
-## エクステンションパターン
+## エクステンションパターン {#extension-patterns}
 
 Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。
 Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。

content/ja/docs/concepts/overview/components.md

@@ -67,7 +67,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー
   * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
   * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。
 
-## ノードコンポーネント
+## ノードコンポーネント {#node-components}
 
 ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。
 

content/ja/docs/concepts/overview/kubernetes-api.md

@@ -3,7 +3,7 @@ reviewers:
 title: Kubernetes API
 content_type: concept
 weight: 30
-card: 
+card:
   name: concepts
   weight: 30
 ---
@@ -30,7 +30,7 @@ Kubernetesそれ自身は複数のコンポーネントから構成されてお
 
 我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。
 
-何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md)に詳解されています。
+何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。
 
 ## OpenAPIとSwaggerの定義
 
@@ -44,7 +44,7 @@ Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポ
 Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` （デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません）
 Accept-Encoding | `gzip` （このヘッダーを送信しないことも許容されています）
 
-1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
+1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。
 
 **OpenAPI仕様の取得サンプル**:
 
@@ -57,7 +57,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
 Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
 
 また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。
-このエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
+このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。
 
 ## APIバージョニング
 
@@ -102,15 +102,15 @@ APIグループは、RESTのパスとシリアライズされたオブジェク
 1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。
 1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。
 
-## APIグループの有効化
+## APIグループの有効化、無効化
 
 いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
 
-重要: APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。
+{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}}
 
-## APIグループのリソースの有効化
+## APIグループextensions/v1beta1に含まれる特定のリソースの有効化
-
-DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。
-その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。
 
+APIグループ`extensions/v1beta1`に含まれるDaemonSets、Deployments、StatefulSet、NetworkPolicies、PodSecurityPolicies、ReplicaSetsはデフォルトで無効にされています。
+例えば、deploymentとdaemonsetを有効にするには、`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`と設定します。
 
+{{< note >}}リソースを個別に有効化、無効化することは歴史的な理由によりAPIグループ`extensions/v1beta1`に含まれるリソースに限りサポートされています。{{< /note >}}

content/ja/docs/concepts/overview/what-is-kubernetes.md

@@ -48,7 +48,7 @@ Kubernetesは...
 
 * サポートするアプリケーションの種類を限定しません。Kubernetesはステートレス、ステートフル、およびデータ処理ワークロードなど、非常に多様なワークロードをサポートするように作られています。アプリケーションをコンテナ内で実行できる場合は、Kubernetes上でもうまく動作するはずです。
 * ソースコードのデプロイやアプリケーションのビルドを行いません。継続的インテグレーション、デリバリー、デプロイ(CI/CD)ワークフローは、技術選定がそうであるように、組織の文化や好みによって決まるからです。
-* ミドルウェア(例: message buses)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。
+* ミドルウェア(例: メッセージバス)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。
 * ロギング、モニタリング、アラーティングソリューションへの指示は行いません。概念実証(PoC)としていくつかのインテグレーション、およびメトリックを収集およびエクスポートするためのメカニズムを提供します。
 * 設定言語/システム(例： jsonnet)を提供も強制もしません。任意の形式の宣言仕様の対象となる可能性がある宣言APIを提供します。
 * 包括的なインフラ構成、保守、管理、またはセルフヒーリングシステムを提供、導入しません。
@@ -57,7 +57,7 @@ Kubernetesは...
 
 ## なぜコンテナなのか？
 
-なぜコンテナを使うべきかの理由をお探しですか？
+コンテナを使うべき理由をお探しですか？
 
 ![なぜコンテナなのか？](/images/docs/why_containers.svg)
 

content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -2,7 +2,7 @@
 title: Kubernetesオブジェクトを理解する
 content_type: concept
 weight: 10
-card: 
+card:
   name: concepts
   weight: 40
 ---
@@ -12,7 +12,7 @@ card:
 
 
 <!-- body -->
-## Kubernetesオブジェクトを理解する
+## Kubernetesオブジェクトを理解する {#kubernetes-objects}
 
 *Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます:
 

content/ja/docs/concepts/overview/working-with-objects/namespaces.md

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

content/ja/docs/concepts/scheduling/taint-and-toleration.md

@@ -0,0 +1,221 @@
+---
+title: TaintとToleration
+content_type: concept
+weight: 40
+---
+
+
+<!-- overview -->
+[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は
+{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はNodeがある種のPodを排除できるようにします。
+
+_toleration_ はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。
+
+taintとtolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。taintはNodeに一つまたは複数個付与することができます。これはそのNodeがtaintを許容しないPodを受け入れるべきではないことを示します。
+
+
+<!-- body -->
+
+## コンセプト
+
+Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。
+例えば、次のコマンドは
+
+```shell
+kubectl taint nodes node1 key=value:NoSchedule
+```
+
+`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。
+これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。
+
+上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。
+```shell
+kubectl taint nodes node1 key:NoSchedule-
+```
+
+PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。
+
+```yaml
+tolerations:
+- key: "key"
+  operator: "Equal"
+  value: "value"
+  effect: "NoSchedule"
+```
+
+```yaml
+tolerations:
+- key: "key"
+  operator: "Exists"
+  effect: "NoSchedule"
+```
+
+tolerationを設定したPodの例を示します。
+
+{{< codenew file="pods/pod-with-toleration.yaml" >}}
+
+`operator`のデフォルトは`Equal`です。
+
+tolerationがtaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。
+
+* `operator`が`Exists`（`value`を指定すべきでない場合）
+* `operator`が`Equal`であり、かつ`value`が同一である場合
+
+{{< note >}}
+
+2つ特殊な場合があります。
+
+空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。
+
+空の`effect`は`key`が一致する全てのeffectと合致します。
+
+{{< /note >}}
+
+上記の例では`effect`に`NoSchedule`を指定しました。代わりに、`effect`に`PreferNoSchedule`を指定することができます。
+これは`NoSchedule`の「ソフトな」バージョンであり、システムはtaintに対応するtolerationが設定されていないPodがNodeへ配置されることを避けようとしますが、必須の条件とはしません。3つ目の`effect`の値として`NoExecute`がありますが、これについては後述します。
+
+同一のNodeに複数のtaintを付与することや、同一のPodに複数のtolerationを設定することができます。
+複数のtaintやtolerationが設定されている場合、Kubernetesはフィルタのように扱います。最初はNodeの全てのtaintがある状態から始め、Podが対応するtolerationを持っているtaintは無視され外されていきます。無視されずに残ったtaintが効果を及ぼします。
+具体的には、
+
+* effect `NoSchedule`のtaintが無視されず残った場合、KubernetesはそのPodをNodeへスケジューリングしません。
+* effect `NoSchedule`のtaintは残らず、effect `PreferNoSchedule`のtaintは残った場合、KubernetesはそのNodeへのスケジューリングをしないように試みます。
+* effect `NoExecute`のtaintが残った場合、既に稼働中のPodはそのNodeから排除され、まだ稼働していないPodはスケジューリングされないようになります。
+
+例として、下記のようなtaintが付与されたNodeを考えます。
+
+```shell
+kubectl taint nodes node1 key1=value1:NoSchedule
+kubectl taint nodes node1 key1=value1:NoExecute
+kubectl taint nodes node1 key2=value2:NoSchedule
+```
+
+Podには2つのtolerationが設定されています。
+
+```yaml
+tolerations:
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoSchedule"
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoExecute"
+```
+
+この例では、3つ目のtaintと合致するtolerationがないため、PodはNodeへはスケジューリングされません。
+しかし、これらのtaintが追加された時点で、そのNodeでPodが稼働していれば続けて稼働することが可能です。 これは、Podのtolerationと合致しないtaintは3つあるtaintのうちの3つ目のtaintのみであり、それが`NoSchedule`であるためです。
+
+一般に、effect `NoExecute`のtaintがNodeに追加されると、合致するtolerationが設定されていないPodは即時にNodeから排除され、合致するtolerationが設定されたPodが排除されることは決してありません。
+しかし、effect`NoExecute`に対するtolerationは`tolerationSeconds`フィールドを任意で指定することができ、これはtaintが追加された後にそのNodeにPodが残る時間を示します。例えば、
+
+```yaml
+tolerations:
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoExecute"
+  tolerationSeconds: 3600
+```
+
+この例のPodが稼働中で、対応するtaintがNodeへ追加された場合、PodはそのNodeに3600秒残り、その後排除されます。仮にtaintがそれよりも前に外された場合、Podは排除されません。
+
+## ユースケースの例
+
+taintとtolerationは、実行されるべきではないNodeからPodを遠ざけたり、排除したりするための柔軟な方法です。いくつかのユースケースを示します。
+
+* **専有Node**: あるNode群を特定のユーザーに専有させたい場合、そのNode群へtaintを追加し(`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) 対応するtolerationをPodへ追加します（これを実現する最も容易な方法はカスタム
+[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を書くことです）。
+tolerationが設定されたPodはtaintの設定された（専有の）Nodeと、クラスターにあるその他のNodeの使用が認められます。もしPodが必ず専有Node*のみ*を使うようにしたい場合は、taintと同様のラベルをそのNode群に設定し(例: `dedicated=groupName`)、アドミッションコントローラーはNodeアフィニティを使ってPodが`dedicated=groupName`のラベルの付いたNodeへスケジューリングすることが必要であるということも設定する必要があります。
+
+* **特殊なハードウェアを備えるNode**: クラスターの中の少数のNodeが特殊なハードウェア（例えばGPU）を備える場合、そのハードウェアを必要としないPodがスケジューリングされないようにして、後でハードウェアを必要とするPodができたときの余裕を確保したいことがあります。
+これは特殊なハードウェアを持つNodeにtaintを追加(例えば `kubectl taint nodes nodename special=true:NoSchedule` または
+`kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するtolerationを追加することで可能です。
+専有Nodeのユースケースと同様に、tolerationを容易に適用する方法はカスタム
+[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を使うことです。
+例えば、特殊なハードウェアを表すために[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+を使い、ハードウェアを備えるNodeに拡張リソースの名称のtaintを追加して、
+[拡張リソースtoleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
+アドミッションコントローラーを実行することが推奨されます。Nodeにはtaintが付与されているため、tolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースtoleration` アドミッションコントローラーはPodに自動的に適切なtolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。
+これは特殊なハードウェアを備えたNodeではそれを必要とするPodのみが稼働し、Podに対して手作業でtolerationを追加しなくて済むようにします。
+
+* **taintを基にした排除**: Nodeに問題が起きたときにPodごとに排除する設定を行うことができます。次のセクションにて説明します。
+
+## taintを基にした排除
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+上述したように、effect `NoExecute`のtaintはNodeで実行中のPodに次のような影響を与えます。
+
+ * 対応するtolerationのないPodは即座に除外される
+ * 対応するtolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける
+ * 対応するtolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される
+
+Nodeコントローラーは特定の条件を満たす場合に自動的にtaintを追加します。
+組み込まれているtaintは下記の通りです。
+
+ * `node.kubernetes.io/not-ready`: Nodeの準備ができていない場合。これはNodeCondition `Ready`が`False`である場合に対応します。
+ * `node.kubernetes.io/unreachable`: NodeがNodeコントローラーから到達できない場合。これはNodeCondition`Ready`が`Unknown`の場合に対応します。
+ * `node.kubernetes.io/out-of-disk`: Nodeのディスクの空きがない場合。
+ * `node.kubernetes.io/memory-pressure`: Nodeのメモリーが不足している場合。
+ * `node.kubernetes.io/disk-pressure`: Nodeのディスクが不足している場合。
+ * `node.kubernetes.io/network-unavailable`: Nodeのネットワークが利用できない場合。
+ * `node.kubernetes.io/unschedulable`: Nodeがスケジューリングできない場合。
+ * `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるtaintで、このNodeは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのNodeを初期化した後にkubeletはこのtaintを外します。
+
+Nodeから追い出すときには、Nodeコントローラーまたはkubeletは関連するtaintを`NoExecute`効果の状態で追加します。
+不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはNodeコントローラーは関連するtaintを外すことができます。
+
+{{< note >}}
+コントロールプレーンは新しいtaintをNodeに加えるレートを制限しています。
+このレート制限は一度に多くのNodeが到達不可能になった場合（例えばネットワークの断絶）に、退役させられるNodeの数を制御します。
+{{< /note >}}
+
+Podに`tolerationSeconds`を指定することで不具合があるか応答のないNodeに残る時間を指定することができます。
+
+例えば、ローカルの状態を多数持つアプリケーションとネットワークが分断された場合を考えます。ネットワークが復旧して、Podを排除しなくて済むことを見込んで、長時間Nodeから排除されないようにしたいこともあるでしょう。
+この場合Podに設定するtolerationは次のようになります。
+
+```yaml
+tolerations:
+- key: "node.kubernetes.io/unreachable"
+  operator: "Exists"
+  effect: "NoExecute"
+  tolerationSeconds: 6000
+```
+
+{{< note >}}
+Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的に`node.kubernetes.io/not-ready`と`node.kubernetes.io/unreachable`に対するtolerationを`tolerationSeconds=300`にて設定します。
+
+自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。
+{{< /note >}}
+
+[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。
+
+  * `node.kubernetes.io/unreachable`
+  * `node.kubernetes.io/not-ready`
+
+これはDaemonSetのPodはこれらの問題によって排除されないことを保証します。
+
+## 条件によるtaintの付与
+
+NodeのライフサイクルコントローラーはNodeの状態に応じて`NoSchedule`効果のtaintを付与します。
+スケジューラーはNodeの状態ではなく、taintを確認します。
+Nodeに何がスケジューリングされるかは、そのNodeの状態に影響されないことを保証します。ユーザーは適切なtolerationをPodに付与することで、どの種類のNodeの問題を無視するかを選ぶことができます。
+
+DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐために自動的に次の`NoSchedule`tolerationを全てのDaemonSetに付与します。
+
+  * `node.kubernetes.io/memory-pressure`
+  * `node.kubernetes.io/disk-pressure`
+  * `node.kubernetes.io/out-of-disk` (*重要なPodのみ*)
+  * `node.kubernetes.io/unschedulable` (1.10またはそれ以降)
+  * `node.kubernetes.io/network-unavailable` (*ホストネットワークのみ*)
+
+これらのtolerationを追加することは後方互換性を保証します。DaemonSetに任意のtolerationを加えることもできます。
+
+
+## {{% heading "whatsnext" %}}
+
+* [リソース枯渇の対処](/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む
+* [Podの優先度](/docs/concepts/configuration/pod-priority-preemption/)を読む

content/ja/docs/concepts/services-networking/ingress-controllers.md

@@ -0,0 +1,57 @@
+---
+title: Ingressコントローラー
+reviewers:
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+Ingressリソースが動作するためには、クラスターでIngressコントローラーが実行されている必要があります。
+
+`kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。
+
+プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。
+
+
+
+<!-- body -->
+
+## 追加のコントローラー {#additional-controllers}
+
+* [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)のサポートと保守を提供しています。
+* [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)を提供しています。
+* [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/)を参照してください。
+* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。
+* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。
+* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
+* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。
+
+## 複数の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コントローラーを使用する場合があります。
+
+理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。
+
+
+{{< note >}}
+Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。
+{{< /note >}}
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細
+* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)

content/ja/docs/concepts/workloads/controllers/deployment.md

@@ -3,7 +3,7 @@ title: Deployment
 feature:
   title: 自動化されたロールアウトとロールバック
   description: >
-    Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。
+    Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。
 
 content_type: concept
 weight: 30
@@ -1001,7 +1001,7 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
 
 Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。
 
-`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymnetの更新頻度と安定性に依存します。
+`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。
 
 さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。
 

content/ja/docs/concepts/workloads/pods/init-containers.md

@@ -202,7 +202,7 @@ myapp-pod   1/1       Running   0          9m
 
 このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。
 
-## Initコンテナのふるまいに関する詳細 {#Detailed behavior}
+## Initコンテナのふるまいに関する詳細 {#detailed-behavior}
 
 Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。
 

content/ja/docs/home/supported-doc-versions.md

@@ -9,7 +9,7 @@ card:
 
 <!-- overview -->
 
-本ウェブサイトでは、現行版とその直前4バージョンのKubernetesドキュメントを含んでいます。
+本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。
 
 
 
@@ -17,8 +17,7 @@ card:
 
 ## 現行版
 
-現在のバージョンは
+現在のバージョンは[{{< param "version" >}}](/)です。
-[{{< param "version" >}}](/).
 
 ## 以前のバージョン
 

content/ja/docs/reference/glossary/cncf.md

@@ -0,0 +1,20 @@
+---
+title: Cloud Native Computing Foundation (CNCF)
+id: cncf
+date: 2019-05-26
+full_link: https://cncf.io/
+short_description: >
+  Cloud Native Computing Foundation
+
+aka:
+tags:
+- community
+---
+ Cloud Native Computing Foundation (CNCF)は、持続可能なエコシステムを構築し、マイクロサービスアーキテクチャの一部としてコンテナをオーケストレーションする[プロジェクト](https://www.cncf.io/projects/)を中心としたコミュニティを育成します。
+
+KubernetesはCNCFプロジェクトです。
+
+<!--more-->
+
+CNCFは[Linux Foundation](https://www.linuxfoundation.org/)のサブファウンデーションです。
+CNCFの使命は、クラウドネイティブコンピューティングをユビキタスにすることです。

content/ja/docs/reference/glossary/image.md

@@ -0,0 +1,17 @@
+---
+title: イメージ
+id: image
+date: 2018-04-12
+full_link:
+short_description: >
+  アプリケーションの実行に必要なソフトウェアのセットを持つ、保存されたコンテナの実体です。
+
+aka:
+tags:
+- fundamental
+---
+ アプリケーションの実行に必要なソフトウェアのセットを持つ、保存された{{< glossary_tooltip text="コンテナ"  term_id="container" >}}の実体です。
+
+<!--more-->
+
+コンテナレジストリに格納し、ローカルシステムにプルして、アプリケーションとして実行できるようにするソフトウェアをパッケージ化する方法です。イメージに含まれているメタデータは、実行する実行可能ファイル、作成者、およびその他の情報を示すことができます。

content/ja/docs/setup/_index.md

@@ -49,6 +49,6 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ
 
 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。
 
-[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。 
+[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。
 
 

content/ja/docs/setup/best-practices/multiple-zones.md

@@ -303,7 +303,7 @@ kubectl get nodes --show-labels
 Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
 
 ```shell
-find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}
+find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
 ```
 
 The pods should be spread across all 3 zones:

content/ja/docs/setup/best-practices/node-conformance.md

@@ -7,43 +7,35 @@ weight: 30
 
 ## ノード適合テスト
 
-*Node conformance test* is a containerized test framework that provides a system
+*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスタに参加する資格があることになります。
-verification and functionality test for a node. The test validates whether the
-node meets the minimum requirements for Kubernetes; a node that passes the test
-is qualified to join a Kubernetes cluster.
 
 ## 制約
 
-In Kubernetes version 1.5, node conformance test has the following limitations:
+Kubernetesのバージョン1.5ではノード適合テストには以下の制約があります:
 
-* Node conformance test only supports Docker as the container runtime.
+* ノード適合テストはコンテナのランタイムとしてDockerのみをサポートします。
 
 ## ノードの前提条件
 
-To run node conformance test, a node must satisfy the same prerequisites as a
+適合テストを実行するにはノードは通常のKubernetesノードと同じ前提条件を満たしている必要があります。 最低でもノードに以下のデーモンがインストールされている必要があります:
-standard Kubernetes node. At a minimum, the node should have the following
-daemons installed:
 
-* Container Runtime (Docker)
+* コンテナランタイム (Docker)
 * Kubelet
 
 ## ノード適合テストの実行
 
-To run the node conformance test, perform the following steps:
+ノード適合テストを実行するには、以下の手順に従います:
 
-1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`,
+1. Kubeletをlocalhostに指定します(`--api-servers="http://localhost:8080"`)、
-because the test framework starts a local master to test Kubelet. There are some
+このテストフレームワークはKubeletのテストにローカルマスターを起動するため、Kubeletをローカルホストに設定します(`--api-servers="http://localhost:8080"`)。他にも配慮するべきKubeletフラグがいくつかあります:
-other Kubelet flags you may care:
+  * `--pod-cidr`: `kubenet`を利用している場合は、Kubeletに任意のCIDR(例: `--pod-cidr=10.180.0.0/24`)を指定する必要があります。
-  * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR
+  * `--cloud-provider`: `--cloud-provider=gce`を指定している場合は、テストを実行する前にこのフラグを取り除いてください。
-    to Kubelet, for example `--pod-cidr=10.180.0.0/24`.
-  * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
-    remove the flag to run the test.
 
-2. Run the node conformance test with command:
+2. 以下のコマンドでノード適合テストを実行します:
 
 ```shell
-# $CONFIG_DIR is the pod manifest path of your Kubelet.
+# $CONFIG_DIRはKubeletのPodのマニフェストパスです。
-# $LOG_DIR is the test output path.
+# $LOG_DIRはテスト出力のパスです。
 sudo docker run -it --rm --privileged --net=host \
   -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
   k8s.gcr.io/node-test:0.2
@@ -51,8 +43,7 @@ sudo docker run -it --rm --privileged --net=host \
 
 ## 他アーキテクチャ向けのノード適合テストの実行
 
-Kubernetes also provides node conformance test docker images for other
+Kubernetesは他のアーキテクチャ用のノード適合テストのdockerイメージを提供しています:
-architectures:
 
   Arch  |       Image       |
 --------|:-----------------:|
@@ -62,37 +53,30 @@ architectures:
 
 ## 選択したテストの実行
 
-To run specific tests, overwrite the environment variable `FOCUS` with the
+特定のテストを実行するには、環境変数`FOCUS`を実行したいテストの正規表現で上書きします。
-regular expression of tests you want to run.
 
 ```shell
 sudo docker run -it --rm --privileged --net=host \
   -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-  -e FOCUS=MirrorPod \ # Only run MirrorPod test
+  -e FOCUS=MirrorPod \ # MirrorPodテストのみを実行します
   k8s.gcr.io/node-test:0.2
 ```
 
-To skip specific tests, overwrite the environment variable `SKIP` with the
+特定のテストをスキップするには、環境変数`SKIP`をスキップしたいテストの正規表現で上書きします。
-regular expression of tests you want to skip.
 
 ```shell
 sudo docker run -it --rm --privileged --net=host \
   -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-  -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test
+  -e SKIP=MirrorPod \ # MirrorPodテスト以外のすべてのノード適合テストを実行します
   k8s.gcr.io/node-test:0.2
 ```
 
-Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md).
+ノード適合テストは、[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md)のコンテナ化されたバージョンです。
-By default, it runs all conformance tests.
+デフォルトでは、すべての適合テストが実行されます。
 
-Theoretically, you can run any node e2e test if you configure the container and
+理論的には、コンテナを構成し必要なボリュームを適切にマウントすれば、どのノードのe2eテストも実行できます。しかし、不適合テストを実行するためにはより複雑な設定が必要となるため、**適合テストのみを実行することを強く推奨します**。
-mount required volumes properly. But **it is strongly recommended to only run conformance
-test**, because it requires much more complex configuration to run non-conformance test.
 
 ## 注意事項
 
-* The test leaves some docker images on the node, including the node conformance
+* このテストでは、ノード適合テストイメージや機能テストで使用されるコンテナのイメージなど、いくつかのdockerイメージがノード上に残ります。
-  test image and images of containers used in the functionality
+* このテストでは、ノード上にデッドコンテナが残ります。これらのコンテナは機能テスト中に作成されます。
-  test.
-* The test leaves dead containers on the node. These containers are created
-  during the functionality test.

content/ja/docs/setup/production-environment/container-runtimes.md

@@ -47,38 +47,46 @@ systemdと一緒に `cgroupfs` を使用するということは、2つの異な
 kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されている残りのプロセスに `systemd` を使用するように設定されたノードが、
 リソース圧迫下で不安定になる場合があります。
 
-あなたのコンテナランタイムとkubeletにcgroupドライバーとしてsystemdを使用するように設定を変更することはシステムを安定させました。
+コンテナランタイムとkubeletがcgroupドライバーとしてsystemdを使用するように設定を変更することでシステムは安定します。
 以下のDocker設定の `native.cgroupdriver=systemd` オプションに注意してください。
 
+{{< caution >}}
+すでにクラスターに組み込まれているノードのcgroupドライバーを変更することは非常におすすめしません。
+kubeletが一方のcgroupドライバーを使用してPodを作成した場合、コンテナランタイムを別のもう一方のcgroupドライバーに変更すると、そのような既存のPodのPodサンドボックスを再作成しようとするとエラーが発生する可能性があります。
+kubeletを再起動しても問題は解決しないでしょう。
+ワークロードからノードを縮退させ、クラスターから削除して再び組み込むことを推奨します。
+{{< /caution >}}
+
 ## Docker
 
 それぞれのマシンに対してDockerをインストールします。
-バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。
+バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。
 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。
 
 システムへDockerをインストールするには、次のコマンドを実行します。
 
 {{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04" codelang="bash" >}}
+{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
 # Docker CEのインストール
 ## リポジトリをセットアップ
-### aptパッケージインデックスを更新
-    apt-get update
-
 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
-    apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
+apt-get update && apt-get install -y \
+  apt-transport-https ca-certificates curl software-properties-common gnupg2
 
 ### Docker公式のGPG鍵を追加
-    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
 
-### dockerのaptリポジトリを追加
+### Dockerのaptリポジトリを追加
-    add-apt-repository \
+add-apt-repository \
-    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-    $(lsb_release -cs) \
+  $(lsb_release -cs) \
-    stable"
+  stable"
 
-## docker ceのインストール
+## Docker CEのインストール
-apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
+apt-get update && apt-get install -y \
+  containerd.io=1.2.10-3 \
+  docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
+  docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
 
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
@@ -103,15 +111,17 @@ systemctl restart docker
 # Docker CEのインストール
 ## リポジトリをセットアップ
 ### 必要なパッケージのインストール
-    yum install yum-utils device-mapper-persistent-data lvm2
+yum install -y yum-utils device-mapper-persistent-data lvm2
 
-### dockerパッケージ用のyumリポジトリを追加
+### Dockerリポジトリの追加
-yum-config-manager \
+yum-config-manager --add-repo \
-    --add-repo \
+  https://download.docker.com/linux/centos/docker-ce.repo
-    https://download.docker.com/linux/centos/docker-ce.repo
 
-## docker ceのインストール
+## Docker CEのインストール
-yum update && yum install docker-ce-18.06.2.ce
+yum update -y && yum install -y \
+  containerd.io-1.2.10 \
+  docker-ce-19.03.4 \
+  docker-ce-cli-19.03.4
 
 ## /etc/docker ディレクトリを作成
 mkdir /etc/docker
@@ -147,7 +157,12 @@ systemctl restart docker
 
 システムへCRI-Oをインストールするためには以下のコマンドを利用します:
 
-### 必要な設定の追加
+{{< note >}}
+CRI-OのメジャーとマイナーバージョンはKubernetesのメジャーとマイナーバージョンと一致しなければなりません。
+詳細は[CRI-O互換性表](https://github.com/cri-o/cri-o)を参照してください。
+{{< /note >}}
+
+### 事前準備
 
 ```shell
 modprobe overlay
@@ -164,33 +179,55 @@ sysctl --system
 ```
 
 {{< tabs name="tab-cri-cri-o-installation" >}}
-{{< tab name="Ubuntu 16.04" codelang="bash" >}}
+{{< tab name="Debian" codelang="bash" >}}
+# Debian Unstable/Sid
+echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
 
-# 必要なパッケージをインストールし、リポジトリを追加
+# Debian Testing
-apt-get update
+echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-apt-get install software-properties-common
+wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
 
-add-apt-repository ppa:projectatomic/ppa
+# Debian 10
-apt-get update
+echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
 
-# CRI-Oをインストール
+# Raspbian 10
-apt-get install cri-o-1.11
+echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
 
+# CRI-Oのインストール
+sudo apt-get install cri-o-1.17
 {{< /tab >}}
+
+{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}}
+# リポジトリの設定
+. /etc/os-release
+sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
+wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
+sudo apt-get update
+
+# CRI-Oのインストール
+sudo apt-get install cri-o-1.17
+{{< /tab >}}
+
 {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+# 必要なパッケージのインストール
+yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
 
-# 必要なリポジトリを追加
+# CRI-Oのインストール
-yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/
+yum install --nogpgcheck -y cri-o
-
+{{< /tab >}}
-# CRI-Oをインストール
-yum install --nogpgcheck cri-o
 
+{{< tab name="openSUSE Tumbleweed" codelang="bash" >}}
+sudo zypper install cri-o
 {{< /tab >}}
 {{< /tabs >}}
 
 ### CRI-Oの起動
 
 ```
+systemctl daemon-reload
 systemctl start crio
 ```
 
@@ -205,6 +242,11 @@ systemctl start crio
 ### 必要な設定の追加
 
 ```shell
+cat > /etc/modules-load.d/containerd.conf <<EOF
+overlay
+br_netfilter
+EOF
+
 modprobe overlay
 modprobe br_netfilter
 
@@ -218,36 +260,61 @@ EOF
 sysctl --system
 ```
 
+### containerdのインストール
+
 {{< tabs name="tab-cri-containerd-installation" >}}
-{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
+{{< tab name="Ubuntu 16.04" codelang="bash" >}}
-apt-get install -y libseccomp2
+# containerdのインストール
+## リポジトリの設定
+### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
+apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+
+### Docker公式のGPG鍵を追加
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+
+### Dockerのaptリポジトリの追加
+add-apt-repository \
+    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+    $(lsb_release -cs) \
+    stable"
+
+## containerdのインストール
+apt-get update && apt-get install -y containerd.io
+
+# containerdの設定
+mkdir -p /etc/containerd
+containerd config default > /etc/containerd/config.toml
+
+# containerdの再起動
+systemctl restart containerd
 {{< /tab >}}
 {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
-yum install -y libseccomp
+# containerdのインストール
+## リポジトリの設定
+### 必要なパッケージのインストール
+yum install -y yum-utils device-mapper-persistent-data lvm2
+
+### Dockerのリポジトリの追加
+yum-config-manager \
+    --add-repo \
+    https://download.docker.com/linux/centos/docker-ce.repo
+
+## containerdのインストール
+yum update -y && yum install -y containerd.io
+
+# containerdの設定
+mkdir -p /etc/containerd
+containerd config default > /etc/containerd/config.toml
+
+# containerdの再起動
+systemctl restart containerd
 {{< /tab >}}
 {{< /tabs >}}
 
-### containerdのインストール
+### systemd
 
-[Containerdは定期的にリリース](https://github.com/containerd/containerd/releases)されますが、以下に示すコマンドで利用している値は、この手順が作成された時点での最新のバージョンにしたがって書かれています。より新しいバージョンとダウンロードするファイルのハッシュ値については[こちら](https://storage.googleapis.com/cri-containerd-release)で確認するようにしてください。
+`systemd`のcgroupドライバーを使うには、`/etc/containerd/config.toml`内で`plugins.cri.systemd_cgroup = true`を設定してください。
-
+kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#マスターノードのkubeletによって使用されるcgroupドライバーの設定)を手動で設定してください。
-```shell
-# 必要な環境変数をexportします。
-export CONTAINERD_VERSION="1.1.2"
-export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218"
-
-# containerdのtarボールをダウンロードします。
-wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz
-
-# ハッシュ値をチェックします。
-echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check -
-
-# 解凍して展開します。
-tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz
-
-# containerdを起動します。
-systemctl start containerd
-```
 
 ## その他のCRIランタイム: frakti
 

content/ja/docs/setup/production-environment/on-premises-vm/_index.md

@@ -1,4 +1,4 @@
 ---
 title: オンプレミスVM
-weight: 60
+weight: 40
 ---

content/ja/docs/setup/production-environment/tools/kops.md

@@ -1,6 +1,6 @@
 ---
 title: kopsを使ったAWS上でのKubernetesのインストール
-content_type: concept
+content_type: task
 weight: 20
 ---
 
@@ -9,35 +9,40 @@ weight: 20
 This quickstart shows you how to easily install a Kubernetes cluster on AWS.
 It uses a tool called [`kops`](https://github.com/kubernetes/kops).
 
-kops is an opinionated provisioning system:
+kops is an automated provisioning system:
 
 * Fully automated installation
 * Uses DNS to identify clusters
 * Self-healing: everything runs in Auto-Scaling Groups
-* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md)
+* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md)
-* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
+* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md)
 * Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
 
-If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
+
-a building block.  kops builds on the kubeadm work.
+
+## {{% heading "prerequisites" %}}
+
+
+* You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed.
+
+* 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.
 
 
 
-<!-- body -->
+<!-- steps -->
 
 ## クラスタの作成
 
 ### (1/5) kopsのインストール
 
-#### 要件
-
-You must have [kubectl](/ja/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
-
 #### インストール
 
 Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
 
-On macOS:
+{{< tabs name="kops_installation" >}}
+{{% tab name="macOS" %}}
 
 Download the latest release with the command:
 
@@ -45,14 +50,12 @@ Download the latest release with the command:
 curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
 ```
 
-To download a specific version, replace the
+To download a specific version, replace the following portion of the command with the specific kops version.
 
 ```shell
 $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
 ```
 
-portion of the command with the specific version.
-
 For example, to download kops version v1.15.0 type:
 
 ```shell
@@ -76,8 +79,8 @@ You can also install kops using [Homebrew](https://brew.sh/).
 ```shell
 brew update && brew install kops
 ```
-
+{{% /tab %}}
-On Linux:
+{{% tab name="Linux" %}}
 
 Download the latest release with the command:
 
@@ -85,11 +88,11 @@ Download the latest release with the command:
 curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
 ```
 
-To download a specific version, replace the
+To download a specific version of kops, replace the following portion of the command with the specific kops version.
+
 ```shell
 $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
 ```
-portion of the command with the specific version.
 
 For example, to download kops version v1.15.0 type:
 
@@ -115,9 +118,13 @@ You can also install kops using [Homebrew](https://docs.brew.sh/Homebrew-on-Linu
 brew update && brew install kops
 ```
 
+{{% /tab %}}
+{{< /tabs >}}
+
+
 ### (2/5) クラスタ用のroute53ドメインの作成
 
-kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server
+kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server
 from clients.
 
 kops has a strong opinion on the cluster name: it should be a valid DNS name.  By doing so you will
@@ -174,7 +181,7 @@ the S3 bucket name.
 
 ### (4/5) クラスタ設定の構築
 
-Run "kops create cluster" to create your cluster configuration:
+Run `kops create cluster` to create your cluster configuration:
 
 `kops create cluster --zones=us-east-1c useast1.dev.example.com`
 
@@ -213,24 +220,20 @@ for production clusters!
 
 ### 他のアドオンの参照
 
-See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization &amp; control of your Kubernetes cluster.
+See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.
 
 ## クリーンアップ
 
 * To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
 
-## フィードバック
-
-* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
-* [GitHub Issues](https://github.com/kubernetes/kops/issues)
-
 
 
 ## {{% heading "whatsnext" %}}
 
 
 * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
-* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
+* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
-* See the `kops` [docs](https://github.com/kubernetes/kops) section 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)
 
 

content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md

@@ -35,7 +35,7 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag
 
 詳細は[kube-apiserverのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。
 
-Example usage:
+使用例:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
@@ -52,7 +52,7 @@ apiServer:
 
 詳細は[kube-controller-managerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-controller-manager/)を参照してください。
 
-Example usage:
+使用例:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
@@ -68,7 +68,7 @@ controllerManager:
 
 詳細は[kube-schedulerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
 
-Example usage:
+使用例:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration

content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md

@@ -8,16 +8,14 @@ weight: 60
 
 このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します:
 
-- 積み重なったコントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。
+- 積層コントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。
 - 外部のetcdクラスターを使う方法。こちらのアプローチには、より多くのインフラストラクチャーが必要です。コントロールプレーンノードと、etcdのメンバーは分離されます。
 
-先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。
+先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/)が、それぞれの利点/欠点について概説しています。
 
-クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)で我々にフィードバックを提供してくれることを推奨します。
+高可用性クラスターの作成で問題が発生した場合は、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)でフィードバックを提供してください。
 
-alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.13で削除されたことに留意してください。
+[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)も参照してください。
-
-[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13)も参照してください。
 
 {{< caution >}}
 このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。
@@ -30,8 +28,8 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
 
 どちらの方法でも、以下のインフラストラクチャーが必要です:
 
-- master用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
+- master用に、[kubeadmの最小要件](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#始める前に)を満たす3台のマシン
-- worker用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
+- worker用に、[kubeadmの最小要件](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#始める前に)を満たす3台のマシン
 - クラスター内のすべてのマシン間がフルにネットワーク接続可能であること(パブリック、もしくはプライベートネットワーク)
 - すべてのマシンにおいて、sudo権限
 - あるデバイスから、システム内のすべてのノードに対しSSH接続できること
@@ -41,22 +39,11 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
 
 - etcdメンバー用に、追加で3台のマシン
 
-{{< note >}}
-以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。
-{{< /note >}}
-
-
 
 <!-- steps -->
 
 ## 両手順における最初のステップ
 
-{{< note >}}
-コントロールプレーンや、etcdノードでのコマンドはすべてrootとして実行してください。
-{{< /note >}}
-
-- CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。
-
 ### kube-apiserver用にロードバランサーを作成
 
 {{< note >}}
@@ -84,7 +71,181 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
 
 1.  残りのコントロールプレーンノードを、ロードバランサーのターゲットグループに追加します。
 
-### SSHの設定
+## 積層コントロールプレーンとetcdノード
+
+### 最初のコントロールプレーンノードの手順
+
+1.  最初のコントロールプレーンノードを初期化します:
+
+    ```sh
+    sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
+    ```
+
+    - `--kubernetes-version`フラグで使用するKubernetesのバージョンを設定できます。kubeadm、kubelet、kubectl、Kubernetesのバージョンを一致させることが推奨されます。
+    - `--control-plane-endpoint`フラグは、ロードバランサーのIPアドレスまたはDNS名と、ポートが設定される必要があります。
+    - `--upload-certs`フラグは全てのコントロールプレーンノードで共有する必要がある証明書をクラスターにアップロードするために使用されます。代わりに、コントロールプレーンノード間で手動あるいは自動化ツールを使用して証明書をコピーしたい場合は、このフラグを削除し、以下の[証明書の手動配布](#manual-certs)のセクションを参照してください。
+
+    {{< 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 >}}
+
+    - このような出力がされます:
+
+    ```sh
+    ...
+    You can now join any number of control-plane node by running the following command on each as a root:
+        kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+    
+    Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
+    As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
+    
+    Then you can join any number of worker nodes by running the following on each as root:
+        kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+    ```
+
+    - この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードとワーカーノードをクラスターに参加させる際に必要です。
+
+    - `--upload-certs`フラグを`kubeadm init`で使用すると、プライマリコントロールプレーンの証明書が暗号化されて、`kubeadm-certs` Secretにアップロードされます。
+
+    - 証明書を再アップロードして新しい復号キーを生成するには、すでにクラスターに参加しているコントロールプレーンノードで次のコマンドを使用します:
+
+    ```sh
+    sudo kubeadm init phase upload-certs --upload-certs
+    ```
+
+    - また、後で`join`で使用できるように、`init`中にカスタムした`--certificate-key`を指定することもできます。このようなキーを生成するには、次のコマンドを使用します:
+
+    ```sh
+    kubeadm alpha certs certificate-key
+    ```
+
+    {{< note >}}
+    `kubeadm-certs`のSecretと復号キーは2時間で期限切れとなります。
+    {{< /note >}}
+
+    {{< caution >}}
+    コマンド出力に記載されているように、証明書キーはクラスターの機密データへのアクセスを提供します。秘密にしてください！
+    {{< /caution >}}
+
+1.  使用するCNIプラグインを適用します:  
+    [こちらの手順に従い](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)CNIプロバイダーをインストールします。該当する場合は、kubeadmの設定で指定されたPodのCIDRに対応していることを確認してください。
+
+    Weave Netを使用する場合の例:
+
+    ```sh
+    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+    ```
+
+1.  以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します:
+
+    ```sh
+    kubectl get pod -n kube-system -w
+    ```
+
+### 残りのコントロールプレーンノードの手順
+
+{{< note >}}
+kubeadmバージョン1.15以降、複数のコントロールプレーンノードを並行してクラスターに参加させることができます。
+このバージョンの前は、最初のノードの初期化が完了した後でのみ、新しいコントロールプレーンノードを順番にクラスターに参加させる必要があります。
+{{< /note >}}
+
+追加のコントロールプレーンノード毎に、以下の手順を行います。
+
+1.  `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、新しく追加するコントロールプレーンノードで`kubeadm join`を開始します。このようなコマンドになるはずです:
+
+    ```sh
+    sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+    ```
+
+    - `--control-plane`フラグによって、`kubeadm join`の実行は新しいコントロールプレーンを作成します。
+    - `-certificate-key ...`を指定したキーを使って、クラスターの`kubeadm-certs` Secretからダウンロードされたコントロールプレーンの証明書が復号されます。
+
+## 外部のetcdノード
+
+外部のetcdノードを使ったクラスターの設定は、積層etcdの場合と似ていますが、最初にetcdを設定し、kubeadmの設定ファイルにetcdの情報を渡す必要があります。
+
+### etcdクラスターの構築
+
+1. [こちらの手順](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。
+
+1. [こちらの手順](#manual-certs)にしたがって、SSHを構築してください。
+
+1. 以下のファイルをクラスター内の任意のetcdノードから最初のコントロールプレーンノードにコピーしてください:
+
+    ```sh
+    export CONTROL_PLANE="ubuntu@10.0.0.7"
+    scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+    scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+    scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
+    ```
+
+    - `CONTROL_PLANE`の値を、最初のコントロールプレーンノードの`user@host`で置き換えます。
+
+### 最初のコントロールプレーンノードの構築
+
+1.  以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します:
+
+        apiVersion: kubeadm.k8s.io/v1beta2
+        kind: ClusterConfiguration
+        kubernetesVersion: stable
+        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+        etcd:
+            external:
+                endpoints:
+                - https://ETCD_0_IP:2379
+                - https://ETCD_1_IP:2379
+                - https://ETCD_2_IP:2379
+                caFile: /etc/kubernetes/pki/etcd/ca.crt
+                certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
+                keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+
+    {{< note >}}
+    ここで、積層etcdと外部etcdの違いは、外部etcdの構成では`etcd`の`external`オブジェクトにetcdのエンドポイントが記述された設定ファイルが必要です。積層etcdトポロジーの場合、これは自動で管理されます。
+    {{< /note >}}
+
+    -  テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます:
+
+        - `LOAD_BALANCER_DNS`
+        - `LOAD_BALANCER_PORT`
+        - `ETCD_0_IP`
+        - `ETCD_1_IP`
+        - `ETCD_2_IP`
+
+以下の手順は、積層etcdの構築と同様です。
+
+1.  `sudo kubeadm init --config kubeadm-config.yaml --upload-certs`をこのノードで実行します。
+
+1.  表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。
+
+1.  使用するCNIプラグインを適用します。以下はWeave CNIの場合です:
+
+    ```sh
+    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+    ```
+
+### 残りのコントロールプレーンノードの手順
+
+手順は、積層etcd構築の場合と同じです:
+
+- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。
+- テキストファイルに保存したjoinコマンドを使って、それぞれのコントロールプレーンノードをクラスターへ参加させます。コントロールプレーンノードは1台ずつクラスターへ参加させるのを推奨します。
+- `--certificate-key`で指定する復号キーは、デフォルトで2時間で期限切れになることを忘れないでください。
+
+## コントロールプレーン起動後の共通タスク
+
+### workerのインストール
+
+`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。
+
+```sh
+sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+```
+
+## 証明書の手動配布 {#manual-certs}
+
+`--upload-certs`フラグを指定して`kubeadm init`を実行しない場合、プライマリコントロールプレーンノードから他のコントロールプレーンノードへ証明書を手動でコピーする必要があります。
+
+コピーを行うには多くの方法があります。次の例では`ssh`と`scp`を使用しています。
 
 1台のマシンから全てのノードをコントロールしたいのであれば、SSHが必要です。
 
@@ -114,61 +275,12 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
         sudo -E -s
         ```
 
-## 積み重なったコントロールプレーンとetcdノード
+1.  全てのノードでSSHを設定したら、`kubeadm init`を実行した後、最初のコントロールノードプレーンノードで次のスクリプトを実行します。このスクリプトは、最初のコントロールプレーンノードから残りのコントロールプレーンノードへ証明書ファイルをコピーします:
 
-### 最初のコントロールプレーンノードの手順
+    次の例の、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスに置き換えます。
-
-1.  最初のコントロールプレーンノードで、`kubeadm-config.yaml`という設定ファイルを作成します:
-
-        apiVersion: kubeadm.k8s.io/v1beta1
-        kind: ClusterConfiguration
-        kubernetesVersion: stable
-        apiServer:
-          certSANs:
-          - "LOAD_BALANCER_DNS"
-        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
-
-    - `kubernetesVersion`には使用するKubernetesのバージョンを設定します。この例では`stable`を使用しています。
-    - `controlPlaneEndpoint` はロードバランサーのアドレスかDNSと、ポートに一致する必要があります。
-    - kubeadm、kubelet、kubectlとKubernetesのバージョンを一致させることが推奨されます。
-
-1.  ノードがきれいな状態であることを確認します:
 
     ```sh
-    sudo kubeadm init --config=kubeadm-config.yaml
+    USER=ubuntu # 環境に合わせる
-    ```
-
-    このような出力がされます:
-
-    ```sh
-    ...
-    You can now join any number of machines by running the following on each node
-    as root:
-
-    kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash    sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
-    ```
-
-1.  この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードをクラスターに参加させる際に必要になります。
-
-1.  Weave CNIプラグインをapplyします:
-
-    ```sh
-    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-    ```
-
-1.  以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します:
-
-    ```sh
-    kubectl get pod -n kube-system -w
-    ```
-
-    - 最初のコントロールプレーンノードが初期化を完了してから、新しいノードを参加させることが推奨されます。
-
-1.  証明書ファイルを最初のコントロールプレーンノードから残りのノードにコピーします:
-
-    以下の例では、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスで置き換えます。
-    ```sh
-    USER=ubuntu # 変更可能
     CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
     for host in ${CONTROL_PLANE_IPS}; do
         scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
@@ -178,21 +290,19 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
         scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
         scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
         scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
+        # 外部のetcdノード使用時はこちらのコマンドを実行
         scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
-        scp /etc/kubernetes/admin.conf "${USER}"@$host:
     done
     ```
 
-{{< caution >}}
+    {{< caution >}}
-上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。
+    上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。
-{{< /caution >}}
+    {{< /caution >}}
 
-### 残りのコントロールプレーンノードの手順
+1.  次に、クラスターに参加させる残りの各コントロールプレーンノードで`kubeadm join`を実行する前に次のスクリプトを実行する必要があります。このスクリプトは、前の手順でコピーした証明書をホームディレクトリから`/etc/kubernetes/pki`へ移動します:
-
-1.  `scp`を使用する手順で作成したファイルを移動します:
 
     ```sh
-    USER=ubuntu # 変更可能
+    USER=ubuntu # 環境に合わせる
     mkdir -p /etc/kubernetes/pki/etcd
     mv /home/${USER}/ca.crt /etc/kubernetes/pki/
     mv /home/${USER}/ca.key /etc/kubernetes/pki/
@@ -201,103 +311,6 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
     mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
     mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
     mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
+    # 外部のetcdノード使用時はこちらのコマンドを実行
     mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
-    mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
     ```
-
-    この手順で、`/etc/kubernetes`フォルダーに必要な全てのファイルが書き込まれます。
-
-1.  `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、このノードで`kubeadm join`を開始します。このようなコマンドになるはずです:
-
-    ```sh
-    sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
-    ```
-    - `--experimental-control-plane`フラグが追加されています。このフラグは、コントロールプレーンノードのクラスターへの参加を自動化します。
-
-1.  以下のコマンドをタイプし、コンポーネントのPodが起動するのを確認します:
-
-    ```sh
-    kubectl get pod -n kube-system -w
-    ```
-
-1.  これらのステップを、残りのコントロールプレーンノードに対して繰り返します。
-
-## 外部のetcdノード
-
-### etcdクラスターの構築
-
-- [こちらの手順](/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。
-
-### 最初のコントロールプレーンノードの構築
-
-1.  以下のファイルをetcdクラスターのどれかのノードからこのノードへコピーしてください:
-
-    ```sh
-    export CONTROL_PLANE="ubuntu@10.0.0.7"
-    +scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
-    +scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
-    +scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
-    ```
-
-    - `CONTROL_PLANE`の値を、このマシンの`user@host`で置き換えます。
-
-1.  以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します:
-
-        apiVersion: kubeadm.k8s.io/v1beta1
-        kind: ClusterConfiguration
-        kubernetesVersion: stable
-        apiServer:
-          certSANs:
-          - "LOAD_BALANCER_DNS"
-        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
-        etcd:
-            external:
-                endpoints:
-                - https://ETCD_0_IP:2379
-                - https://ETCD_1_IP:2379
-                - https://ETCD_2_IP:2379
-                caFile: /etc/kubernetes/pki/etcd/ca.crt
-                certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
-                keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
-
-    - ここで、積み重なったetcdと外部etcdの違いは、kubeadmコンフィグの`etcd`に`external`フィールドを使用していることです。積み重なったetcdトポロジーの場合、これは自動で管理されます。
-
-    -  テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます:
-
-        - `LOAD_BALANCER_DNS`
-        - `LOAD_BALANCER_PORT`
-        - `ETCD_0_IP`
-        - `ETCD_1_IP`
-        - `ETCD_2_IP`
-
-1.  `kubeadm init --config kubeadm-config.yaml`をこのノードで実行します。
-
-1.  表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。
-
-1.  Weave CNIプラグインをapplyします:
-
-    ```sh
-    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-    ```
-
-### 残りのコントロールプレーンノードの手順
-
-残りのコントロールプレーンノードを参加させるために、[こちらの手順](#残りのコントロールプレーンノードの手順)に従います。ローカルetcdメンバーが作られないことを除いて、積み重なったetcdの構築と同じ手順です。
-
-まとめると:
-
-- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。
-- 証明書を、最初のコントロールプレーンノードから他のコントロールプレーンノードへコピーします。
-- テキストファイルに保存したjoinコマンドに`--experimental-control-plane` フラグを加えたものを使って、それぞれのコントロールプレーンノードを参加させます。
-
-## コントロールプレーン起動後の共通タスク
-
-### Podネットワークのインストール
-
-Podネットワークをインストールするには、[こちらの手順に従ってください](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)。master設定ファイルで提供したPod CIDRのどれかに一致することを確認します。
-
-### workerのインストール
-
-`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。
-
-

content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md

@@ -8,7 +8,7 @@ weight: 100
 
 ### Self-hosting the Kubernetes control plane {#self-hosting}
 
-As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control
+kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
 plane. This means that key components such as the API server, controller
 manager, and scheduler run as [DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/)
 configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)

content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md

@@ -6,6 +6,14 @@ weight: 70
 
 <!-- overview -->
 
+{{< note >}}
+While kubeadm is being used as the management tool for external etcd nodes
+in this guide, please note that kubeadm does not plan to support certificate rotation
+or upgrades for such nodes. The long term plan is to empower the tool
+[etcdadm](https://github.com/kubernetes-sigs/etcdadm) to manage these
+aspects.
+{{< /note >}}
+
 Kubeadm defaults to running a single member etcd cluster in a static pod managed
 by the kubelet on the control plane node. This is not a high availability setup
 as the etcd cluster contains only one member and cannot sustain any members
@@ -52,7 +60,8 @@ this example.
     cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
     [Service]
     ExecStart=
-    ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests
+    #  Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
+    ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
     Restart=always
     EOF
 
@@ -81,7 +90,7 @@ this example.
     HOST=${ETCDHOSTS[$i]}
     NAME=${NAMES[$i]}
     cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
-    apiVersion: "kubeadm.k8s.io/v1beta1"
+    apiVersion: "kubeadm.k8s.io/v1beta2"
     kind: ClusterConfiguration
     etcd:
         local:
@@ -241,15 +250,17 @@ this example.
     ```sh
     docker run --rm -it \
     --net host \
-    -v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:${ETCD_TAG} etcdctl \
+    -v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \
-    --cert-file /etc/kubernetes/pki/etcd/peer.crt \
+    --cert /etc/kubernetes/pki/etcd/peer.crt \
-    --key-file /etc/kubernetes/pki/etcd/peer.key \
+    --key /etc/kubernetes/pki/etcd/peer.key \
-    --ca-file /etc/kubernetes/pki/etcd/ca.crt \
+    --cacert /etc/kubernetes/pki/etcd/ca.crt \
-    --endpoints https://${HOST0}:2379 cluster-health
+    --endpoints https://${HOST0}:2379 endpoint health --cluster
     ...
-    cluster is healthy
+    https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
+    https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
+    https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
     ```
-    - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `v3.2.24`.
+    - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `3.4.3-0`. To see the etcd image and tag that kubeadm uses execute `kubeadm config images list --kubernetes-version ${K8S_VERSION}`, where `${K8S_VERSION}` is for example `v1.17.0`
     - Set `${HOST0}`to the IP address of the host you are testing.
 
 

content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md

@@ -1,7 +1,7 @@
 ---
 title: kubeadmのトラブルシューティング
 content_type: concept
-weight: 90
+weight: 20
 ---
 
 <!-- overview -->
@@ -152,7 +152,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
 
 - 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 -d` command can be used to decode the certificate
+  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:
 
@@ -170,6 +170,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
 
   ```sh
   mv  $HOME/.kube $HOME/.kube.bak
+  mkdir $HOME/.kube
   sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
   sudo chown $(id -u):$(id -g) $HOME/.kube/config
   ```
@@ -197,15 +198,15 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
 ```
 
 - 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.
-- Digital Ocean 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.
+- 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.
 
-  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 Digital Ocean allows to query for the anchor IP from the droplet:
+  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:
 
   ```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 Digital Ocean, 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.
+  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.
 
   Then restart `kubelet`:
 
@@ -306,16 +307,56 @@ The tracking issue for this problem is [here](https://github.com/kubernetes/kube
 
 *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.*
 
-By default, kubeadm applies the `role.kubernetes.io/master:NoSchedule` taint to control-plane nodes.
+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.
 
 There are at least two workarounds:
 
-1. Use the `role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity.
+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.
 
 2. Remove the taint after kubeadm init exits:
 ```bash
-kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
+kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
+ ```
+
+## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}
+
+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.
+
+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).
+
+On the primary control-plane Node (created using `kubeadm init`) pass the following
+file using `--config`:
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: InitConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
+---
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+controllerManager:
+  extraArgs:
+    flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
 ```
 
+On joining Nodes:
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: JoinConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    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.

content/ja/docs/setup/production-environment/tools/kubespray.md

@@ -6,22 +6,22 @@ weight: 30
 
 <!-- overview -->
 
-This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
+This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
 
-Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
 
 * a highly available cluster
 * composable attributes
 * support for most popular Linux distributions
   * Container Linux by CoreOS
-  * Debian Jessie, Stretch, Wheezy
+  * Debian Buster, Jessie, Stretch, Wheezy
   * Ubuntu 16.04, 18.04
-  * CentOS/RHEL 7
+  * CentOS/RHEL/Oracle Linux 7
-  * Fedora/CentOS Atomic
+  * Fedora 28
-  * openSUSE Leap 42.3/Tumbleweed
+  * openSUSE Leap 15
 * continuous integration tests
 
-To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
 
 
 
@@ -31,11 +31,11 @@ To choose a tool which best fits your use case, read [this comparison](https://g
 
 ### (1/5) 下地の要件の確認
 
-Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements):
+Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
 
-* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands**
+* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands**
 * **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
-* The target servers must have **access to the Internet** in order to pull docker images
+* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
 * The target servers are configured to allow **IPv4 forwarding**
 * **Your ssh key must be copied** to all the servers part of your inventory
 * The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
@@ -44,12 +44,13 @@ Provision servers with the following [requirements](https://github.com/kubernete
 Kubespray provides the following utilities to help provision your environment:
 
 * [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
-  * [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
+  * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
-  * [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/openstack)
+  * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
+  * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
 
 ### (2/5) インベントリファイルの用意
 
-After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
 
 ### (3/5) クラスタ作成の計画
 
@@ -58,14 +59,14 @@ Kubespray provides the ability to customize many aspects of the deployment:
 * Choice deployment mode: kubeadm or non-kubeadm
 * CNI (networking) plugins
 * DNS configuration
-* Choice of control plane: native/binary or containerized with docker or rkt
+* Choice of control plane: native/binary or containerized
 * Component versions
 * Calico route reflectors
 * Component runtime options
-  * docker
+  * {{< glossary_tooltip term_id="docker" >}}
-  * rkt
+  * {{< glossary_tooltip term_id="containerd" >}}
-  * cri-o
+  * {{< glossary_tooltip term_id="cri-o" >}}
-* Certificate generation methods (**Vault being discontinued**)
+* Certificate generation methods
 
 Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
 
@@ -73,18 +74,18 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co
 
 Next, deploy your cluster:
 
-Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
+Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
 
 ```shell
 ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
   --private-key=~/.ssh/private_key
 ```
 
-Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results.
+Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results.
 
 ### (5/5) デプロイの確認
 
-Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
+Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
 
 ## クラスタの操作
 
@@ -92,16 +93,16 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg
 
 ### クラスタのスケール
 
-You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
+You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
-You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
+You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
 
 ### クラスタのアップグレード
 
-You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)".
+You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)".
 
 ## クリーンアップ
 
-You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml).
+You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml).
 
 {{< caution >}}
 When running the reset playbook, be sure not to accidentally target your production cluster!
@@ -109,14 +110,13 @@ When running the reset playbook, be sure not to accidentally target your product
 
 ## フィードバック
 
-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
-* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
+* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
 
 
 
 ## {{% heading "whatsnext" %}}
 
 
-Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
+Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
-
 

content/ja/docs/setup/production-environment/turnkey/_index.md

@@ -1,4 +1,4 @@
 ---
 title: ターンキークラウドソリューション
-weight: 40
+weight: 30
 ---

content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md

@@ -4,7 +4,7 @@ title: Alibaba CloudでKubernetesを動かす
 
 ## Alibaba Cloud Container Service
 
-[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。
+[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上もしくはサーバーレスの形態でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。
 
 クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。
 
@@ -14,4 +14,4 @@ title: Alibaba CloudでKubernetesを動かす
 
 [Alibaba Cloudプロバイダーが実装されたKubernetesのソースコード](https://github.com/AliyunContainerService/kubernetes)はオープンソースであり、GitHubから入手可能です。
 
-さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)および[中国語](https://yq.aliyun.com/articles/66474)をご覧下さい。
+さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)をご覧下さい。

content/ja/docs/setup/production-environment/turnkey/aws.md

@@ -16,7 +16,7 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス
 
 ### サポートされているプロダクショングレードのツール
 
-* [conjure-up](/docs/getting-started-guides/ubuntu/)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。
+* [conjure-up](https://docs.conjure-up.io/stable/en/cni/k8s-and-aws)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。
 
 * [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。
 

content/ja/docs/setup/production-environment/turnkey/icp.md

@@ -35,9 +35,9 @@ IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To
 
 ## Azure上でのIBM Cloud Private
 
-You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/azure_overview.html).
+You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html).
 
-## Red Hat OpenShift上でのIBM Cloud Private
+## Red Hat OpenShiftを用いたIBM Cloud Private
 
 You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.
 
@@ -49,7 +49,7 @@ Integration capabilities:
 * Integrated core platform services, such as monitoring, metering, and logging
 * IBM Cloud Private uses the OpenShift image registry
 
-For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/openshift/overview.html).
+For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html).
 
 ## VirtualBox上でのIBM Cloud Private
 

content/ja/docs/setup/production-environment/turnkey/stackpoint.md

@@ -1,187 +0,0 @@
----
-title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす
-content_type: concept
----
-
-<!-- overview -->
-
-[StackPointCloud](https://stackpoint.io/) is the universal control plane for Kubernetes Anywhere. StackPointCloud allows you to deploy and manage a Kubernetes cluster to the cloud provider of your choice in 3 steps using a web-based interface.
-
-
-
-<!-- body -->
-
-## AWS
-
-To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
-
-1. Choose a Provider
-
-    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
-
-    b. Click **+ADD A CLUSTER NOW**.
-
-    c. Click to select Amazon Web Services (AWS).
-
-1. Configure Your Provider
-
-    a. Add your Access Key ID and a Secret Access Key from AWS. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
-
-    b. Click **SUBMIT** to submit the authorization information.
-
-1. Configure Your Cluster
-
-    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
-
-1. Run the Cluster
-
-    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
-
-    For information on using and managing a Kubernetes cluster on AWS, [consult the  Kubernetes documentation](/docs/getting-started-guides/aws/).
-
-
-## GCE
-
-To create a Kubernetes cluster on GCE, you will need the Service Account JSON Data from Google.
-
-1. Choose a Provider
-
-    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
-
-    b. Click **+ADD A CLUSTER NOW**.
-
-    c. Click to select Google Compute Engine (GCE).
-
-1. Configure Your Provider
-
-    a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
-
-    b. Click **SUBMIT** to submit the authorization information.
-
-1. Configure Your Cluster
-
-    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
-
-1. Run the Cluster
-
-    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
-
-    For information on using and managing a Kubernetes cluster on GCE, [consult the  Kubernetes documentation](/docs/getting-started-guides/gce/).
-
-
-## Google Kubernetes Engine
-
-To create a Kubernetes cluster on Google Kubernetes Engine, you will need the Service Account JSON Data from Google.
-
-1. Choose a Provider
-
-    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
-
-    b. Click **+ADD A CLUSTER NOW**.
-
-    c. Click to select Google Kubernetes Engine.
-
-1. Configure Your Provider
-
-    a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
-
-    b. Click **SUBMIT** to submit the authorization information.
-
-1. Configure Your Cluster
-
-    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
-
-1. Run the Cluster
-
-    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
-
-    For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/ja/docs/home/).
-
-
-## DigitalOcean
-
-To create a Kubernetes cluster on DigitalOcean, you will need a DigitalOcean API Token.
-
-1. Choose a Provider
-
-    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
-
-    b. Click **+ADD A CLUSTER NOW**.
-
-    c. Click to select DigitalOcean.
-
-1. Configure Your Provider
-
-    a. Add your DigitalOcean API Token. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
-
-    b. Click **SUBMIT** to submit the authorization information.
-
-1. Configure Your Cluster
-
-    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
-
-1. Run the Cluster
-
-    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
-
-    For information on using and managing a Kubernetes cluster on DigitalOcean, consult [the official documentation](/ja/docs/home/).
-
-
-## Microsoft Azure
-
-To create a Kubernetes cluster on Microsoft Azure, you will need an Azure Subscription ID, Username/Email, and Password.
-
-1. Choose a Provider
-
-    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
-
-    b. Click **+ADD A CLUSTER NOW**.
-
-    c. Click to select Microsoft Azure.
-
-1. Configure Your Provider
-
-    a. Add your Azure Subscription ID, Username/Email, and Password. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
-
-    b. Click **SUBMIT** to submit the authorization information.
-
-1. Configure Your Cluster
-
-    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
-
-1. Run the Cluster
-
-    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
-
-    For information on using and managing a Kubernetes cluster on Azure, [consult the  Kubernetes documentation](/docs/getting-started-guides/azure/).
-
-
-## Packet
-
-To create a Kubernetes cluster on Packet, you will need a Packet API Key.
-
-1. Choose a Provider
-
-    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
-
-    b. Click **+ADD A CLUSTER NOW**.
-
-    c. Click to select Packet.
-
-1. Configure Your Provider
-
-    a. Add your Packet API Key. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
-
-    b. Click **SUBMIT** to submit the authorization information.
-
-1. Configure Your Cluster
-
-    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
-
-1. Run the Cluster
-
-    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
-
-    For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/).
-
-

content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md

@@ -55,7 +55,7 @@ Key Kubernetes elements work the same way in Windows as they do in Linux. In thi
 
 * [Pods](/ja/docs/concepts/workloads/pods/pod-overview/)
 
-    A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. The following Pod capabilities, properties and events are supported with Windows containers:
+    A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers:
 
   * Single or multiple containers per Pod with process isolation and volume sharing
   * Pod status fields
@@ -99,18 +99,36 @@ Pods, Controllers and Services are critical elements to managing Windows workloa
 
 Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions.
 
-#### Storage
+#### Persistent Storage
 
-Kubernetes Volumes enable complex applications with data persistence and Pod volume sharing requirements to be deployed on Kubernetes. Kubernetes on Windows supports the following types of [volumes](/ja/docs/concepts/storage/volumes/):
+Kubernetes [volumes](/docs/concepts/storage/volumes/) enable complex applications, with data persistence and Pod volume sharing requirements, to be deployed on Kubernetes. Management of persistent volumes associated with a specific storage back-end or protocol includes actions such as: provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod that needs to persist data. The code implementing these volume management actions for a specific storage back-end or protocol is shipped in the form of a Kubernetes volume [plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows:
 
-* FlexVolume out-of-tree plugin with [SMB and iSCSI](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) support
+##### In-tree Volume Plugins
-* [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk)
+Code associated with in-tree volume plugins ship as part of the core Kubernetes code base. Deployment of in-tree volume plugins do not require installation of additional scripts or deployment of separate containerized plugin components. These plugins can handle: provisioning/de-provisioning and resizing of volumes in the storage backend, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. The following in-tree plugins support Windows nodes:
-* [azureFile](/ja/docs/concepts/storage/volumes/#azurefile)
+
-* [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk)
+* [awsElasticBlockStore](/docs/concepts/storage/volumes/#awselasticblockstore)
+* [azureDisk](/docs/concepts/storage/volumes/#azuredisk)
+* [azureFile](/docs/concepts/storage/volumes/#azurefile)
+* [gcePersistentDisk](/docs/concepts/storage/volumes/#gcepersistentdisk)
+* [vsphereVolume](/docs/concepts/storage/volumes/#vspherevolume)
+
+##### FlexVolume Plugins
+Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume) plugins ship as out-of-tree scripts or binaries that need to be deployed directly on the host. FlexVolume plugins handle attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. Provisioning/De-provisioning of persistent volumes associated with FlexVolume plugins may be handled through an external provisioner that is typically separate from the FlexVolume plugins. The following FlexVolume [plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows), deployed as powershell scripts on the host, support Windows nodes:
+
+* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
+* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd)
+
+##### CSI Plugins
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Code associated with {{< glossary_tooltip text="CSI" term_id="csi" >}} plugins ship as out-of-tree scripts and binaries that are typically distributed as container images and deployed using standard Kubernetes constructs like DaemonSets and StatefulSets. CSI plugins handle a wide range of volume management actions in Kubernetes: provisioning/de-provisioning/resizing of volumes, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod, backup/restore of persistent data using snapshots and cloning. CSI plugins typically consist of node plugins (that run on each node as a DaemonSet) and controller plugins.
+
+CSI node plugins (especially those associated with persistent volumes exposed as either block devices or over a shared file-system) need to perform various privileged operations like scanning of disk devices, mounting of file systems, etc. These operations differ for each host operating system. For Linux worker nodes, containerized CSI node plugins are typically deployed as privileged containers. For Windows worker nodes, privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node. Please refer to the deployment guide of the CSI plugin you wish to deploy for further details.
 
 #### Networking
 
-Networking for Windows containers is exposed through [CNI plugins](/ja/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as:
+Networking for Windows containers is exposed through [CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as:
 
 * Virtual networks (including creation of vSwitches)
 * Endpoints / vNICs
@@ -128,13 +146,13 @@ Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Ov
 
 | Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics |
 | -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
-| L2bridge       | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires L2 adjacency between container hosts |
+| L2bridge       | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. |
 | L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) |
-| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header, inner packet remains the same. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags)  if you are restricted on IPs in your datacenter. This option may be used when the container hosts are not L2 adjacent but have L3 connectivity |
+| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags)  if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. |
 | Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.  <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. |
 | NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
 
-As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (net-conf.json), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local).
+As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (cni.conf), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local).
 
 For the node, pod, and service objects, the following network flows are supported for TCP/UDP traffic:
 
@@ -215,7 +233,6 @@ As a result, the following storage functionality is not supported on Windows nod
 * Read-only root filesystem. Mapped volumes still support readOnly
 * Block device mapping
 * Memory as the storage medium
-* CSI plugins which require privileged containers
 * File system features like uui/guid, per-user Linux filesystem permissions
 * NFS based storage/volume support
 * Expanding the mounted volume (resizefs)
@@ -256,6 +273,7 @@ These features were added in Kubernetes v1.15:
 
 * ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution
 * On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with just that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**.
+* On Windows, there are multiple DNS resolvers that can be used. As these come with slightly different behaviors, using the `Resolve-DNSName` utility for name query resolutions is recommended.
 
 ##### Security
 
@@ -264,7 +282,7 @@ Secrets are written in clear text on the node's volume (as compared to tmpfs/in-
 1. Use file ACLs to secure the secrets file location
 2. Use volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)
 
-[RunAsUser ](/ja/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release.
+[RunAsUser ](/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release.
 
 Linux specific pod security context privileges such as SELinux, AppArmor, Seccomp, Capabilities (POSIX Capabilities), and others are not supported.
 
@@ -328,7 +346,7 @@ None of the PodSecurityContext fields work on Windows. They're listed here for r
 
 ## Getting Help and Troubleshooting {#troubleshooting}
 
-Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/ja/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs).
+Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs).
 
 1. How do I know start.ps1 completed successfully?
 
@@ -445,7 +463,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
 
 1. vNICs and HNS endpoints of containers are being deleted
 
-    This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/ja/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows:
+    This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows:
 
     ```powershell
     C:\k\kube-proxy.exe --hostname-override=$(hostname)
@@ -493,7 +511,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
     Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
     ```
 
-    Often it is worthwhile to modify the [InterfaceName](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
+    Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
 
 1. My Pods are stuck at "Container Creating" or restarting over and over
 
@@ -510,6 +528,20 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
     This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones.
     If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)
 
+1. My Kubernetes installation is failing because my Windows Server node is behind a proxy
+
+    If you are behind a proxy, the following PowerShell environment variables must be defined:
+    ```PowerShell
+    [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
+    [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
+    ```
+
+1. What is a `pause` container?
+
+    In a Kubernetes Pod, an infrastructure or "pause" container is first created to host the container endpoint. Containers that belong to the same pod, including infrastructure and worker containers, share a common network namespace and endpoint (same IP and port space). Pause containers are needed to accommodate worker containers crashing or restarting without losing any of the networking configuration.
+
+    The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat).
+
 ### Further investigation
 
 If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through:
@@ -584,5 +616,3 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust
 * Beta support for Group Managed Service Accounts
 * More CNIs
 * More Storage Plugins
-
-

content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md

@@ -27,44 +27,47 @@ Windows applications constitute a large portion of the services and applications
 To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below:
 
 ```yaml
-    apiVersion: v1
+apiVersion: v1
-    kind: Service
+kind: Service
-    metadata:
+metadata:
-      name: win-webserver
+  name: win-webserver
-      labels:
+  labels:
-        app: win-webserver
+    app: win-webserver
-    spec:
+spec:
-      ports:
+  ports:
-      # the port that this service should serve on
+    # the port that this service should serve on
-      - port: 80
+    - port: 80
-        targetPort: 80
+      targetPort: 80
-      selector:
+  selector:
-        app: win-webserver
+    app: win-webserver
-      type: NodePort
+  type: NodePort
-    ---
+---
-    apiVersion: extensions/v1beta1
+apiVersion: apps/v1
-    kind: Deployment
+kind: Deployment
+metadata:
+  labels:
+    app: win-webserver
+  name: win-webserver
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: win-webserver
+  template:
     metadata:
       labels:
         app: win-webserver
       name: win-webserver
     spec:
-      replicas: 2
+      containers:
-      template:
+        - name: windowswebserver
-        metadata:
+          image: mcr.microsoft.com/windows/servercore:ltsc2019
-          labels:
+          command:
-            app: win-webserver
-          name: win-webserver
-        spec:
-          containers:
-          - name: windowswebserver
-            image: mcr.microsoft.com/windows/servercore:ltsc2019
-            command:
             - powershell.exe
             - -command
-            - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ;  ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus)  } ; "
+            - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ;  ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count = $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus)  } ; "
-          nodeSelector:
+      nodeSelector:
-            kubernetes.io/os: windows
+        kubernetes.io/os: windows
 ```
 
 {{< note >}}
@@ -101,6 +104,18 @@ Port mapping is also supported, but for simplicity in this example the container
 Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
 {{< /note >}}
 
+## Observability
+
+### Capturing logs from workloads
+
+Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs <pod>`.
+
+Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT.
+
+## Using configurable Container usernames
+
+Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
+
 ## Managing Workload Identity with Group Managed Service Accounts
 
 Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
@@ -116,22 +131,114 @@ Users can ensure Windows containers can be scheduled on the appropriate host usi
 * kubernetes.io/os = [windows|linux]
 * kubernetes.io/arch = [amd64|arm64|...]
 
-If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
+If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
 
 However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
 
-For example:  `--register-with-taints='os=Win1809:NoSchedule'`
+For example:  `--register-with-taints='os=windows:NoSchedule'`
 
 By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
 
 ```yaml
 nodeSelector:
-    "beta.kubernetes.io/os": windows
+    kubernetes.io/os: windows
+    node.kubernetes.io/windows-build: '10.0.17763'
 tolerations:
     - key: "os"
       operator: "Equal"
-      value: "Win1809"
+      value: "windows"
       effect: "NoSchedule"
 ```
 
+### Handling multiple Windows versions in the same cluster
 
+The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
+Server versions in the same cluster, then you should set additional node labels and nodeSelectors.
+
+Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
+
+This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
+
+| Product Name                         |   Build Number(s)      |
+|--------------------------------------|------------------------|
+| Windows Server 2019                  | 10.0.17763             |
+| Windows Server version 1809          | 10.0.17763             |
+| Windows Server version 1903          | 10.0.18362             |
+
+
+### Simplifying with RuntimeClass
+
+[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
+
+
+1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
+
+```yaml
+apiVersion: node.k8s.io/v1beta1
+kind: RuntimeClass
+metadata:
+  name: windows-2019
+handler: 'docker'
+scheduling:
+  nodeSelector:
+    kubernetes.io/os: 'windows'
+    kubernetes.io/arch: 'amd64'
+    node.kubernetes.io/windows-build: '10.0.17763'
+  tolerations:
+  - effect: NoSchedule
+    key: os
+    operator: Equal
+    value: "windows"
+```
+
+1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
+1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
+
+For example:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: iis-2019
+  labels:
+    app: iis-2019
+spec:
+  replicas: 1
+  template:
+    metadata:
+      name: iis-2019
+      labels:
+        app: iis-2019
+    spec:
+      runtimeClassName: windows-2019
+      containers:
+      - name: iis
+        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
+        resources:
+          limits:
+            cpu: 1
+            memory: 800Mi
+          requests:
+            cpu: .1
+            memory: 300Mi
+        ports:
+          - containerPort: 80
+ selector:
+    matchLabels:
+      app: iis-2019
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: iis
+spec:
+  type: LoadBalancer
+  ports:
+  - protocol: TCP
+    port: 80
+  selector:
+    app: iis-2019
+```
+
+[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/

content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md

@@ -91,9 +91,9 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
 
 1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check:
     1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan.
-        * VNI 4096 is set in the backend
+      * VNI 4096 is set in the backend
-        * Port 4789 is set in the backend
+      * Port 4789 is set in the backend
-    2. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
+    1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
 
 
     Your `cni-conf.json` should look as follows:
@@ -134,7 +134,18 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
     kubectl get pods --all-namespaces
     ```
 
-    ![alt_text](../flannel-master-kubeclt-get-pods.png "flannel master kubectl get pods screen capture")
+    The output looks like as follows:
+
+    ```
+    NAMESPACE     NAME                                      READY        STATUS    RESTARTS   AGE
+    kube-system   etcd-flannel-master                       1/1          Running   0          1m
+    kube-system   kube-apiserver-flannel-master             1/1          Running   0          1m
+    kube-system   kube-controller-manager-flannel-master    1/1          Running   0          1m
+    kube-system   kube-dns-86f4d74b45-hcx8x                 3/3          Running   0          12m
+    kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m
+    kube-system   kube-proxy-Zjlxz                          1/1          Running   0          1m
+    kube-system   kube-scheduler-flannel-master             1/1          Running   0          1m
+    ```
 
     Verify that the Flannel DaemonSet has the NodeSelector applied.
 
@@ -142,13 +153,20 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
     kubectl get ds -n kube-system
     ```
 
-    ![alt_text](../flannel-master-kubectl-get-ds.png "flannel master kubectl get ds screen capture")
+    The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied.
+
+    ```
+    NAME              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                               AGE
+    kube-flannel-ds   2         2         2       2            2           beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux   21d
+    kube-proxy        2         2         2       2            2           beta.kubernetes.io/os=linux                                 26d
+    ```
 
 #### Join Windows Worker
 
 In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section.
 
 #### Preparing a Windows Node
+
 {{< note >}}
 All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin).
 {{< /note >}}
@@ -171,9 +189,28 @@ All code snippets in Windows sections are to be run in a PowerShell environment
     [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
     ```
 
-    If after reboot you see the following error, you need to restart the docker service manually
+    After reboot, you can verify that the docker service is ready with the command below.
 
-    ![alt_text](../windows-docker-error.png "windows docker error screen capture")
+    ```PowerShell
+    docker version
+    ```
+
+    If you see error message like the following, you need to start the docker service manually.
+
+    ```
+    Client:
+     Version: 17.06.2-ee-11
+     API version: 1.30
+     Go version: go1.8.7
+     Git commit: 06fc007
+     Built: Thu May 17 06:14:39 2018
+     OS/Arch: windows / amd64
+    error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c
+    annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to
+    connect. This error may also indicate that the docker daemon is not running.
+    ```
+
+    You can start the docker service manually like below.
 
     ```PowerShell
     Start-Service docker
@@ -220,7 +257,13 @@ wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/s
 {{< /note >}}
 
 ```PowerShell
-.\start.ps1 -ManagementIP <Windows Node IP> -NetworkMode overlay  -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory>
+cd c:\k
+.\start.ps1 -ManagementIP <Windows Node IP> `
+  -NetworkMode overlay `
+  -ClusterCIDR <Cluster CIDR> `
+  -ServiceCIDR <Service CIDR> `
+  -KubeDnsServiceIP <Kube-dns Service IP> `
+  -LogDir <Log directory>
 ```
 
 | Parameter | Default Value | Notes |
@@ -261,4 +304,3 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust
 
 Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster.
 
-

content/ja/docs/setup/release/building-from-source.md

@@ -1,30 +0,0 @@
----
-title: リリースのビルド
-content_type: concept
-card:
-  name: download
-  weight: 20
-  title: リリースのビルド
----
-<!-- overview -->
-ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。
-
-Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。
-
-
-<!-- body -->
-## ソースからのビルド
-
-単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。
-
-リリースをビルドすることは簡単です。
-
-```shell
-git clone https://github.com/kubernetes/kubernetes.git
-cd kubernetes
-make release
-```
-
-リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。
-
-

content/ja/docs/setup/release/version-skew-policy.md

@@ -16,9 +16,10 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ
 
 Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。
 
-セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。
+セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースチーム](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing)がこれを決定しています。パッチリリースチームは[リリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)の一部です。
+詳細は、[Kubernetesパッチリリース](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)ページを参照してください。
 
-詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。
+マイナーリリースは約3ヶ月ごとに行われるため、マイナーリリースのブランチはそれぞれ約9ヶ月保守されます。
 
 ## サポートされるバージョンの差異
 
@@ -87,21 +88,21 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
 
 ## サポートされるコンポーネントのアップグレード順序
 
-コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)**へ移行するために、コンポーネントをアップグレードする順序を説明します。
+コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)** へ移行するために、コンポーネントをアップグレードする順序を説明します。
 
 ### kube-apiserver
 
 前提条件:
 
 * シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします
-* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)**とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります）
+* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります）
 * サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします（必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります）
-* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)**とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります）
+* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります）
 * 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます:
-  * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)**で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください）
+  * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください）
-  * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)**のバージョンで追加された新しいフィールドを扱うことができます
+  * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます
 
-`kube-apiserver`を**1.(n+1)**にアップグレードしてください。
+`kube-apiserver`を**1.(n+1)** にアップグレードしてください。
 
 {{< note >}}
 [非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。
@@ -111,17 +112,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
 
 前提条件:
 
-* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)**であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません）
+* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません）
 
-`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)**にアップグレードしてください。
+`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。
 
 ### kubelet
 
 前提条件:
 
-* `kubelet`と通信する`kube-apiserver`が**1.(n+1)**であること
+* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること
 
-必要に応じて、`kubelet`インスタンスを**1.(n+1)**にアップグレードしてください（**1.n**や**1.(n-1)**のままにすることもできます）。
+必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください（**1.n**や**1.(n-1)** のままにすることもできます）。
 
 {{< warning >}}
 `kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません:

content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md

@@ -0,0 +1,112 @@
+---
+title: クラスターで実行されているすべてのコンテナイメージを一覧表示する
+content_type: task
+weight: 100
+---
+
+<!-- overview -->
+
+このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+<!-- steps -->
+
+この演習では、kubectlを使用してクラスターで実行されているすべてのPodを取得し、出力をフォーマットしてそれぞれのコンテナの一覧を取得します。
+
+## すべての名前空間のコンテナイメージを一覧表示する {#list-all-container-images-in-all-namespaces}
+
+- `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します
+- `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。
+  - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。
+- `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。
+  - `tr`を使用してスペースを改行に置換します。
+  - `sort`を使用して結果を並べ替えます。
+  - `uniq`を使用してイメージ数を集計します。
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+上記のコマンドは、返されるすべてのアイテムについて、`image`という名前のすべてのフィールドを再帰的に返します。
+
+別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます:
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+jsonpathは次のように解釈されます:
+
+- `.items[*]`: 各戻り値
+- `.spec`: 仕様の取得
+- `.containers[*]`: 各コンテナ
+- `.image`: イメージの取得
+
+{{< note >}}
+例えば`kubectl get pod nginx`のように名前を指定して単一のPodを取得する場合、アイテムのリストではなく単一のPodが返されるので、パスの`.items[*]`部分は省略してください。
+{{< /note >}}
+
+## Podごとにコンテナイメージを一覧表示する {#list-container-images-by-pod}
+
+`range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+## Podのラベルを使用してコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace}
+
+特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+## Podの名前空間でコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace}
+
+特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。
+
+```sh
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+## jsonpathの代わりにgo-templateを使用してコンテナイメージを一覧表示する {#list-container-images-using-a-go-template-instead-of-jsonpath}
+
+jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています:
+
+
+```sh
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+
+
+
+
+<!-- discussion -->
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### 参照
+
+* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド
+* [Go template](https://golang.org/pkg/text/template/)参照ガイド
+
+
+
+

content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md

@@ -23,7 +23,7 @@ weight: 60
 ## {{% heading "objectives" %}}
 
 
-* 2つのHellow Worldアプリケーションを稼働させる。
+* 2つのHello Worldアプリケーションを稼働させる。
 * Nodeのポートを公開するServiceオブジェクトを作成する。
 * 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。
 

content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -92,12 +92,12 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
 
   例:
 
-  ```conf
+   ```conf
-release=1.0
+   release=1.0
-tier=frontend
+   tier=frontend
-environment=pod
+   environment=pod
-track=stable
+   track=stable
-```
+   ```
 
 - **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。
 

content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md

@@ -14,7 +14,7 @@ content_type: task
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
+* [Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)の基本を理解しておきましょう。
 * [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
 
 
@@ -100,7 +100,7 @@ kubectl logs <pod-name> -c <init-container-2>
 
 <!-- discussion -->
 
-## Podのステータスを理解する
+## Podのステータスを理解する {#understanding-pod-status}
 
 `Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。
 

content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md

@@ -47,7 +47,7 @@ kubectl exec -it shell-demo -- /bin/bash
 ```
 {{< note >}}
 
-ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。
+ダブルダッシュの記号 `--` はコマンドに渡す引数とkubectlの引数を分離します。
 
 {{< /note >}}
 

content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md

@@ -0,0 +1,149 @@
+---
+title: 環境変数によりコンテナにPod情報を共有する
+content_type: task
+weight: 30
+---
+
+<!-- overview -->
+
+このページでは、Podが内部で実行しているコンテナに自身の情報を共有する方法を説明します。環境変数ではPodのフィールドとコンテナのフィールドを共有することができます。
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+<!-- steps -->
+
+## Downward API {#the-downward-api}
+
+Podとコンテナのフィールドを実行中のコンテナに共有する方法は2つあります:
+
+* 環境変数
+* [ボリュームファイル](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+
+これら2つの方法を合わせて、Podとコンテナフィールドを共有する方法を*Downward API*と呼びます。
+
+
+## Podフィールドを環境変数の値として使用する {#use-pod-fields-as-values-for-environment-variables}
+
+この演習では、1つのコンテナを持つPodを作成します。Podの設定ファイルは次のとおりです:
+
+{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
+
+設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。
+
+{{< note >}}
+この例のフィールドはPodのフィールドです。これらはPod内のコンテナのフィールドではありません。
+{{< /note >}}
+
+Podを作成します:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
+```
+
+Podのコンテナが実行されていることを確認します:
+
+```shell
+kubectl get pods
+```
+
+コンテナのログを表示します:
+
+```shell
+kubectl logs dapi-envars-fieldref
+```
+
+出力には、選択した環境変数の値が表示されます:
+
+```
+minikube
+dapi-envars-fieldref
+default
+172.17.0.4
+default
+```
+
+これらの値がログにある理由を確認するには、設定ファイルの`command`および`args`フィールドを確認してください。コンテナが起動すると、5つの環境変数の値が標準出力に書き込まれます。これを10秒ごとに繰り返します。
+
+次に、Podで実行しているコンテナへのシェルを取得します:
+
+```shell
+kubectl exec -it dapi-envars-fieldref -- sh
+```
+
+シェルで環境変数を表示します:
+
+```shell
+/# printenv
+```
+
+出力は、特定の環境変数にPodフィールドの値が割り当てられていることを示しています:
+
+```
+MY_POD_SERVICE_ACCOUNT=default
+...
+MY_POD_NAMESPACE=default
+MY_POD_IP=172.17.0.4
+...
+MY_NODE_NAME=minikube
+...
+MY_POD_NAME=dapi-envars-fieldref
+```
+
+## コンテナフィールドを環境変数の値として使用する {#use-container-fields-as-values-for-environment-variables}
+
+前の演習では、環境変数の値としてPodフィールドを使用しました。次の演習では、環境変数の値としてコンテナフィールドを使用します。これは、1つのコンテナを持つPodの設定ファイルです:
+
+{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
+
+設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。
+
+Podを作成します:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
+```
+
+Podのコンテナが実行されていることを確認します:
+
+```shell
+kubectl get pods
+```
+
+コンテナのログを表示します:
+
+```shell
+kubectl logs dapi-envars-resourcefieldref
+```
+
+出力には、選択した環境変数の値が表示されます:
+
+```
+1
+1
+33554432
+67108864
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [コンテナの環境変数の定義](/ja/docs/tasks/inject-data-application/define-environment-variable-container/)
+* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
+* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
+* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
+* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
+
+

content/ja/docs/tutorials/kubernetes-basics/_index.html

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

content/ja/docs/tutorials/stateful-application/_index.md

@@ -0,0 +1,5 @@
+---
+title: "ステートフルアプリケーション"
+weight: 50
+---
+

content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md

@@ -0,0 +1,241 @@
+---
+title: "例: Persistent Volumeを使用したWordpressとMySQLをデプロイする"
+content_type: tutorial
+weight: 20
+card:
+  name: tutorials
+  weight: 40
+  title: "ステートフルの例: Persistent Volumeを使用したWordpress"
+---
+
+<!-- overview -->
+このチュートリアルでは、WordPressのサイトとMySQLデータベースをMinikubeを使ってデプロイする方法を紹介します。2つのアプリケーションとも、データを保存するためにPersistentVolumeとPersistentVolumeClaimを使用します。
+
+[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)(PV)とは、管理者が手動でプロビジョニングを行うか、[StorageClass](/docs/concepts/storage/storage-classes)を使ってKubernetesによって動的にプロビジョニングされた、クラスター内のストレージの一部です。[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)は、PVによって満たすことができる、ユーザーによるストレージへのリクエストのことです。PersistentVolumeとPersistentVolumeClaimは、Podのライフサイクルからは独立していて、Podの再起動、Podの再スケジューリング、さらにはPodの削除が行われたとしても、その中のデータは削除されずに残ります。
+
+{{< warning >}}
+シングルインスタンスのWordPressとMySQLのPodを使用しているため、ここで行うデプロイは本番のユースケースには適しません。WordPressを本番環境にデプロイするときは、[WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)を使用することを検討してください。
+{{< /warning >}}
+
+{{< note >}}
+このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、APIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。
+{{< /note >}}
+
+
+
+## {{% heading "objectives" %}}
+
+* PersistentVolumeClaimとPersistentVolumeを作成する
+* 以下を含む`kustomization.yaml`を作成する
+  * Secret generator
+  * MySQLリソースの設定
+  * WordPressリソースの設定
+* kustomizationディレクトリを`kubectl apply -k ./`で適用する
+* クリーンアップする
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+このページで示された例は、`kubectl` 1.14以降で動作します。
+
+以下の設定ファイルをダウンロードします。
+
+1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml)
+
+1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml)
+
+
+
+<!-- lessoncontent -->
+
+## PersistentVolumeClaimとPersistentVolumeを作成する
+
+MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。
+
+多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。
+
+PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。
+
+{{< warning >}}
+ローカルのクラスターでは、デフォルトのStorageClassには`hostPath`プロビジョナーが使われます。`hostPath`ボリュームは開発およびテストにのみ適しています。`hostPath`ボリュームでは、データはPodがスケジュールされたノード上の`/tmp`内に保存されます。そのため、もしPodが死んだり、クラスター上の他のノードにスケジュールされたり、ノードが再起動すると、データは失われます。
+{{< /warning >}}
+
+{{< note >}}
+`hostPath`プロビジョナーを使用する必要があるクラスターを立ち上げたい場合は、`--enable-hostpath-provisioner`フラグを `controller-manager` コンポーネントで設定する必要があります。
+{{< /note >}}
+
+{{< note >}}
+Google Kubernetes Engine上で動作するKubernetesクラスターを使っている場合は、[このガイド](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk?hl=ja)に従ってください。
+{{< /note >}}
+
+## kustomization.yamlを作成する
+
+### Secret generatorを追加する
+
+[Secret](/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。
+
+以下のコマンドを実行して、`kustomization.yaml`の中にSecret generatorを追加します。`YOUR_PASSWORD`の部分を使いたいパスワードに置換してください。
+
+```shell
+cat <<EOF >./kustomization.yaml
+secretGenerator:
+- name: mysql-pass
+  literals:
+  - password=YOUR_PASSWORD
+EOF
+```
+
+## MySQLとWordPressのためのリソースの設定を追加する
+
+以下のマニフェストには、シングルインスタンスのMySQLのDeploymentが書かれています。MySQLコンテナはPersistentVolumeを`/var/lib/mysql`にマウントします。`MYSQL_ROOT_PASSWORD`環境変数には、Secretから得られたデータベースのパスワードが設定されます。
+
+{{< codenew file="application/wordpress/mysql-deployment.yaml" >}}
+
+以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータベースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。
+
+
+{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
+
+1. MySQLのDeploymentの設定ファイルをダウンロードします。
+
+      ```shell
+      curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
+      ```
+
+2. WordPressの設定ファイルをダウンロードします。
+
+      ```shell
+      curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
+      ```
+
+3. これらを`kustomization.yaml`ファイルに追加します。
+
+```shell
+cat <<EOF >>./kustomization.yaml
+resources:
+  - mysql-deployment.yaml
+  - wordpress-deployment.yaml
+EOF
+```
+
+## 適用と確認
+
+`kustomization.yaml`には、WordPressのサイトとMySQLデータベースのためのすべてのリソースが含まれています。次のコマンドでこのディレクトリを適用できます。
+
+```shell
+kubectl apply -k ./
+```
+
+これで、すべてのオブジェクトが存在していることを確認できます。
+
+1. 次のコマンドを実行して、Secretが存在していることを確認します。
+
+      ```shell
+      kubectl get secrets
+      ```
+
+      結果は次のようになるはずです。
+
+      ```shell
+      NAME                    TYPE                                  DATA   AGE
+      mysql-pass-c57bb4t7mf   Opaque                                1      9s
+      ```
+
+1. 次のコマンドを実行して、PersistentVolumeが動的にプロビジョニングされていることを確認します。
+
+      ```shell
+      kubectl get pvc
+      ```
+
+      {{< note >}}
+      PVがプロビジョニングされてバインドされるまでに、最大で数分かかる場合があります。
+      {{< /note >}}
+
+      結果は次のようになるはずです。
+
+      ```shell
+      NAME             STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
+      mysql-pv-claim   Bound     pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002   20Gi       RWO            standard           77s
+      wp-pv-claim      Bound     pvc-8cd0df54-4044-11e9-b2bb-42010a800002   20Gi       RWO            standard           77s
+      ```
+
+3. 次のコマンドを実行して、Podが実行中であることを確認します。
+
+      ```shell
+      kubectl get pods
+      ```
+
+      {{< note >}}
+      PodのStatusが`Running`の状態になる前に、最大で数分かかる場合があります。
+      {{< /note >}}
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME                               READY     STATUS    RESTARTS   AGE
+      wordpress-mysql-1894417608-x5dzt   1/1       Running   0          40s
+      ```
+
+4. 次のコマンドを実行して、Serviceが実行中であることを確認します。
+
+      ```shell
+      kubectl get services wordpress
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
+      wordpress   ClusterIP   10.0.0.89    <pending>     80:32406/TCP   4m
+      ```
+
+      {{< note >}}
+      MinikubeではServiceを`NodePort`経由でしか公開できません。EXTERNAL-IPは常にpendingのままになります。
+      {{< /note >}}
+
+5. 次のコマンドを実行して、WordPress ServiceのIPアドレスを取得します。
+
+      ```shell
+      minikube service wordpress --url
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      http://1.2.3.4:32406
+      ```
+
+6. IPアドレスをコピーして、ブラウザーで読み込み、サイトを表示しましょう。
+
+   WordPressによりセットアップされた次のスクリーンショットのようなページが表示されるはずです。
+
+   ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png)
+
+{{< warning >}}
+WordPressのインストールをこのページのまま放置してはいけません。もしほかのユーザーがこのページを見つけた場合、その人はインスタンス上にウェブサイトをセットアップして、悪意のあるコンテンツの配信に利用できてしまいます。<br/><br/>ユーザー名とパスワードを決めてWordPressをインストールするか、このインスタンスを削除してください。
+{{< /warning >}}
+
+
+
+## {{% heading "cleanup" %}}
+
+
+1. 次のコマンドを実行して、Secret、Deployment、Service、およびPersistentVolumeClaimを削除します。
+
+      ```shell
+      kubectl delete -k ./
+      ```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [イントロスペクションとデバッグ](/docs/tasks/debug-application-cluster/debug-application-introspection/)についてさらに学ぶ
+* [Job](/docs/concepts/workloads/controllers/job/)についてさらに学ぶ
+* [Portフォワーディング](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)についてさらに学ぶ
+* [コンテナへのシェルを取得する](/ja/docs/tasks/debug-application-cluster/get-shell-running-container/)方法について学ぶ
+

content/ja/docs/tutorials/stateless-application/guestbook.md

@@ -0,0 +1,370 @@
+---
+title: "例: Redisを使用したPHPのゲストブックアプリケーションのデプロイ"
+content_type: tutorial
+weight: 20
+card:
+  name: tutorials
+  weight: 30
+  title: "ステートレスの例: Redisを使用したPHPのゲストブック"
+---
+
+<!-- overview -->
+このチュートリアルでは、Kubernetesと[Docker](https://www.docker.com/)を使用した、シンプルなマルチティアのウェブアプリケーションのビルドとデプロイの方法を紹介します。この例は、以下のコンポーネントから構成されています。
+
+* ゲストブックのエントリーを保存するための、シングルインスタンスの[Redis](https://redis.io/)マスター
+* 読み込みデータ配信用の、複数の[レプリケーションされたRedis](https://redis.io/topics/replication)インスタンス
+* 複数のウェブフロントエンドのインスタンス
+
+
+
+## {{% heading "objectives" %}}
+
+* Redisのマスターを起動する。
+* Redisのスレーブを起動する。
+* ゲストブックのフロントエンドを起動する。
+* フロントエンドのServiceを公開して表示を確認する。
+* クリーンアップする。
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+{{< version-check >}}
+
+
+
+<!-- lessoncontent -->
+
+## Redisのマスターを起動する
+
+ゲストブックアプリケーションでは、データを保存するためにRedisを使用します。ゲストブックはRedisのマスターインスタンスにデータを書き込み、複数のRedisのスレーブインスタンスからデータを読み込みます。
+
+### RedisのマスターのDeploymentを作成する
+
+以下のマニフェストファイルは、シングルレプリカのRedisのマスターPodを実行するDeploymentコントローラーを指定しています。
+
+{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}}
+
+1. マニフェストファイルをダウンロードしたディレクトリ内で、ターミナルウィンドウを起動します。
+1. `redis-master-deployment.yaml`ファイルから、RedisのマスターのDeploymentを適用します。
+
+      ```shell
+      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
+      ```
+
+1. Podのリストを問い合わせて、RedisのマスターのPodが実行中になっていることを確認します。
+
+      ```shell
+      kubectl get pods
+      ```
+
+      結果は次のようになるはずです。
+
+      ```shell
+      NAME                            READY     STATUS    RESTARTS   AGE
+      redis-master-1068406935-3lswp   1/1       Running   0          28s
+      ```
+
+1. 次のコマンドを実行して、RedisのマスターのPodからログを表示します。
+
+     ```shell
+     kubectl logs -f POD-NAME
+     ```
+
+{{< note >}}
+POD-NAMEの部分を実際のPodの名前に書き換えてください。
+{{< /note >}}
+
+### RedisのマスターのServiceを作成する
+
+ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
+
+{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
+
+1. 次の`redis-master-service.yaml`から、RedisのマスターのServiceを適用します。
+
+      ```shell
+      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
+      ```
+
+1. Serviceのリストを問い合わせて、RedisのマスターのServiceが実行中になっていることを確認します。
+
+      ```shell
+      kubectl get service
+      ```
+
+      The response should be similar to this:
+
+      ```shell
+      NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
+      kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    1m
+      redis-master   ClusterIP   10.0.0.151   <none>        6379/TCP   8s
+      ```
+
+{{< note >}}
+このマニフェストファイルは、`redis-master`という名前のServiceを、前に定義したラベルにマッチする一連のラベル付きで作成します。これにより、ServiceはネットワークトラフィックをRedisのマスターのPodへとルーティングできるようになります。
+{{< /note >}}
+
+
+## Redisのスレーブを起動する
+
+Redisのマスターは1つのPodですが、レプリカのRedisのスレーブを追加することで、トラフィックの需要を満たすための高い可用性を持たせることができます。
+
+### RedisのスレーブのDeploymentを作成する
+
+Deploymentはマニフェストファイル内に書かれた設定に基づいてスケールします。ここでは、Deploymentオブジェクトは2つのレプリカを指定しています。
+
+もし1つもレプリカが実行されていなければ、このDeploymentは2つのレプリカをコンテナクラスター上で起動します。逆に、もしすでに2つ以上のレプリカが実行されていれば、実行中のレプリカが2つになるようにスケールダウンします。
+
+{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}}
+
+1. `redis-slave-deployment.yaml`ファイルから、RedisのスレーブのDeploymentを適用します。
+
+      ```shell
+      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
+      ```
+
+1. Podのリストを問い合わせて、RedisのスレーブのPodが実行中になっていることを確認します。
+
+      ```shell
+      kubectl get pods
+      ```
+
+      結果は次のようになるはずです。
+
+      ```shell
+      NAME                            READY     STATUS              RESTARTS   AGE
+      redis-master-1068406935-3lswp   1/1       Running             0          1m
+      redis-slave-2005841000-fpvqc    0/1       ContainerCreating   0          6s
+      redis-slave-2005841000-phfv9    0/1       ContainerCreating   0          6s
+      ```
+
+### RedisのスレーブのServiceを作成する
+
+ゲストブックアプリケーションは、データを読み込むためにRedisのスレーブと通信する必要があります。Redisのスレーブが発見できるようにするためには、Serviceをセットアップする必要があります。Serviceは一連のPodに対する透過的なロードバランシングを提供します。
+
+{{< codenew file="application/guestbook/redis-slave-service.yaml" >}}
+
+1. 次の`redis-slave-service.yaml`ファイルから、RedisのスレーブのServiceを適用します。
+
+      ```shell
+      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml
+      ```
+
+1. Serviceのリストを問い合わせて、RedisのスレーブのServiceが実行中になっていることを確認します。
+
+      ```shell
+      kubectl get services
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
+      kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    2m
+      redis-master   ClusterIP   10.0.0.151   <none>        6379/TCP   1m
+      redis-slave    ClusterIP   10.0.0.223   <none>        6379/TCP   6s
+      ```
+
+## ゲストブックのフロントエンドをセットアップして公開する
+
+ゲストブックアプリケーションには、HTTPリクエストをサーブするPHPで書かれたウェブフロントエンドがあります。このアプリケーションは、書き込みリクエストに対しては`redis-master` Serviceに、読み込みリクエストに対しては`redis-slave` Serviceに接続するように設定されています。
+
+### ゲストブックのフロントエンドのDeploymentを作成する
+
+{{< codenew file="application/guestbook/frontend-deployment.yaml" >}}
+
+1. `frontend-deployment.yaml`ファイルから、フロントエンドのDeploymentを適用します。
+
+      ```shell
+      kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
+      ```
+
+1. Podのリストを問い合わせて、3つのフロントエンドのレプリカが実行中になっていることを確認します。
+
+      ```shell
+      kubectl get pods -l app=guestbook -l tier=frontend
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME                        READY     STATUS    RESTARTS   AGE
+      frontend-3823415956-dsvc5   1/1       Running   0          54s
+      frontend-3823415956-k22zn   1/1       Running   0          54s
+      frontend-3823415956-w9gbt   1/1       Running   0          54s
+      ```
+
+### フロントエンドのServiceを作成する
+
+適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
+
+もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。
+
+{{< note >}}
+一部のクラウドプロバイダーでは、Google Compute EngineやGoogle Kubernetes Engineなど、外部のロードバランサーをサポートしているものがあります。もしクラウドプロバイダーがロードバランサーをサポートしていて、それを使用したい場合は、`type: NodePort`という行を単に削除またはコメントアウトして、`type: LoadBalancer`のコメントアウトを外せば使用できます。
+{{< /note >}}
+
+{{< codenew file="application/guestbook/frontend-service.yaml" >}}
+
+1. `frontend-service.yaml`ファイルから、フロントエンドのServiceを提供します。
+
+      ```shell
+      kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
+      ```
+
+1. Serviceのリストを問い合わせて、フロントエンドのServiceが実行中であることを確認します。
+
+      ```shell
+      kubectl get services
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
+      frontend       NodePort    10.0.0.112   <none>       80:31323/TCP   6s
+      kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP        4m
+      redis-master   ClusterIP   10.0.0.151   <none>        6379/TCP       2m
+      redis-slave    ClusterIP   10.0.0.223   <none>        6379/TCP       1m
+      ```
+
+### フロントエンドのServiceを`NodePort`経由で表示する
+
+このアプリケーションをMinikubeやローカルのクラスターにデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。
+
+1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。
+
+      ```shell
+      minikube service frontend --url
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      http://192.168.99.100:31323
+      ```
+
+1. IPアドレスをコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。
+
+### フロントエンドのServiceを`LoadBalancer`経由で表示する
+
+もし`frontend-service.yaml`マニフェストを`type: LoadBalancer`でデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。
+
+1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。
+
+      ```shell
+      kubectl get service frontend
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME       TYPE        CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE
+      frontend   ClusterIP   10.51.242.136   109.197.92.229     80:32372/TCP   1m
+      ```
+
+1. 外部IPアドレス(EXTERNAL-IP)をコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。
+
+## ウェブフロントエンドをスケールする
+
+サーバーがDeploymentコントローラーを使用するServiceとして定義されているため、スケールアップやスケールダウンは簡単です。
+
+1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールアップできます。
+
+      ```shell
+      kubectl scale deployment frontend --replicas=5
+      ```
+
+1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。
+
+      ```shell
+      kubectl get pods
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME                            READY     STATUS    RESTARTS   AGE
+      frontend-3823415956-70qj5       1/1       Running   0          5s
+      frontend-3823415956-dsvc5       1/1       Running   0          54m
+      frontend-3823415956-k22zn       1/1       Running   0          54m
+      frontend-3823415956-w9gbt       1/1       Running   0          54m
+      frontend-3823415956-x2pld       1/1       Running   0          5s
+      redis-master-1068406935-3lswp   1/1       Running   0          56m
+      redis-slave-2005841000-fpvqc    1/1       Running   0          55m
+      redis-slave-2005841000-phfv9    1/1       Running   0          55m
+      ```
+
+1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールダウンできます。
+
+      ```shell
+      kubectl scale deployment frontend --replicas=2
+      ```
+
+1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。
+
+      ```shell
+      kubectl get pods
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      NAME                            READY     STATUS    RESTARTS   AGE
+      frontend-3823415956-k22zn       1/1       Running   0          1h
+      frontend-3823415956-w9gbt       1/1       Running   0          1h
+      redis-master-1068406935-3lswp   1/1       Running   0          1h
+      redis-slave-2005841000-fpvqc    1/1       Running   0          1h
+      redis-slave-2005841000-phfv9    1/1       Running   0          1h
+      ```
+
+
+
+## {{% heading "cleanup" %}}
+
+DeploymentとServiceを削除すると、実行中のPodも削除されます。ラベルを使用すると、複数のリソースを1つのコマンドで削除できます。
+
+1. 次のコマンドを実行すると、すべてのPod、Deployment、Serviceが削除されます。
+
+      ```shell
+      kubectl delete deployment -l app=redis
+      kubectl delete service -l app=redis
+      kubectl delete deployment -l app=guestbook
+      kubectl delete service -l app=guestbook
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      deployment.apps "redis-master" deleted
+      deployment.apps "redis-slave" deleted
+      service "redis-master" deleted
+      service "redis-slave" deleted
+      deployment.apps "frontend" deleted
+      service "frontend" deleted
+      ```
+
+1. Podのリストを問い合わせて、実行中のPodが存在しないことを確認します。
+
+      ```shell
+      kubectl get pods
+      ```
+
+      結果は次のようになるはずです。
+
+      ```
+      No resources found.
+      ```
+
+
+
+## {{% heading "whatsnext" %}}
+
+* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
+* [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる
+* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
+* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む
+* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む

content/ja/examples/pods/pod-with-toleration.yaml

@@ -0,0 +1,15 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  labels:
+    env: test
+spec:
+  containers:
+  - name: nginx
+    image: nginx
+    imagePullPolicy: IfNotPresent
+  tolerations:
+  - key: "example-key"
+    operator: "Exists"
+    effect: "NoSchedule"