merge everything

content/ja/_index.html

@@ -3,9 +3,6 @@ title: "プロダクショングレードのコンテナ管理基盤"
 abstract: "自動化されたコンテナのデプロイ・スケール・管理"
 cid: home
 ---
-{{< announcement >}}
-
-{{< deprecationwarning >}}
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}

content/ja/docs/concepts/_index.md

@@ -15,7 +15,7 @@ weight: 40
 
 ## 概要
 
-Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired sate (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。
+Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired state (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。
 
 一旦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コントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
 
@@ -26,7 +26,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使
 
 ## Kubernetesオブジェクト
 
-Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
+Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
 
 基本的なKubernetesのオブジェクトは次のとおりです。
 

content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -20,7 +20,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
  - **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。
  - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**?
  - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
- - Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させるますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
+ - Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
  - **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。
  - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
  - クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。
@@ -39,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
 
 * [Certificates](/docs/concepts/cluster-administration/certificates/)では、異なるツールチェインを使用して証明書を作成する方法を説明します。
 
-* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment-variables/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
+* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
 
 * [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。
 

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

@@ -8,7 +8,7 @@ weight: 30
 <!-- overview -->
 
 [Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
-これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/docs/concepts/overview/working-with-objects/labels/)です。
+これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。
 スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
 SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
 

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

@@ -31,7 +31,7 @@ weight: 10
 
 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
 
-  明示的に[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
+  明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
 
 ## Service
 
@@ -58,7 +58,7 @@ weight: 10
 
 ## ラベルの使用
 
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
 
 セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
 
@@ -96,7 +96,7 @@ weight: 10
 
 - `kubectl apply -f <directory>`を使いましょう。これを使うと、ディレクトリ内のすべての`.yaml`、`.yml`、および`.json`ファイルが`apply`に渡されます。
 
-- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
+- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
 
 
 

content/ja/docs/concepts/containers/container-environment.md

@@ -1,5 +1,5 @@
 ---
-title: コンテナ環境変数
+title: コンテナ環境
 content_type: concept
 weight: 20
 ---

content/ja/docs/concepts/containers/container-lifecycle-hooks.md

@@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
 ハンドラーにパラメーターは渡されません。
 
-終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#podの終了)にあります。
+終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。
 
 ### フックハンドラーの実装
 
@@ -98,7 +98,7 @@ Events:
 ## {{% heading "whatsnext" %}}
 
 
-* [コンテナ環境](/docs/concepts/containers/container-environment-variables/)の詳細
+* [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細
 * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
 
 

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

@@ -0,0 +1,31 @@
+---
+title: コンテナの概要
+content_template: templates/concept
+weight: 1
+---
+
+{{% capture overview %}}
+
+コンテナは、アプリケーションの(コンパイルされた)コードと、実行時に必要な依存関係をパッケージ化するための技術です。実行する各コンテナは再現性があります。依存関係を含めることによる標準化は、どこで実行しても同じ動作が得られることを意味します。
+
+コンテナは、基礎となるホストインフラストラクチャからアプリケーションを切り離します。これにより、さまざまなクラウド環境やOS環境でのデプロイが容易になります。
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## コンテナイメージ {#container-images}
+[コンテナイメージ](/docs/concepts/containers/images/)は、アプリケーションを実行するために必要なすべてのものを含んだ、すぐに実行可能なソフトウェアパッケージです。コードとそれが必要とする任意のランタイム、アプリケーションとシステムのライブラリ、および必須の設定のデフォルト値が含まれています。
+
+設計上、コンテナは不変であるため、すでに実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり、変更を加えたい場合は、変更を含む新しいコンテナをビルドし、コンテナを再作成して更新されたイメージから起動する必要があります。
+
+## コンテナランタイム {#container-runtimes}
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+{{% /capture %}}
+{{% capture whatsnext %}}
+* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。
+* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。
+{{% /capture %}}

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

@@ -81,7 +81,7 @@ spec:
   # ...
 ```
 
-これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。
+これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。
 エラーメッセージに関しては対応する[イベント](/docs/tasks/debug-application-cluster/debug-application-introspection/)を参照して下さい。
 
 もし`runtimeClassName`が指定されていない場合、デフォルトのRuntimeHandlerが使用され、これはRuntimeClassの機能が無効であるときのふるまいと同じものとなります。

content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

@@ -1,24 +1,31 @@
 ---
 title: アグリゲーションレイヤーを使ったKubernetes APIの拡張
 content_type: concept
-weight: 10
+weight: 20
 ---
 
 <!-- overview -->
 
-アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。
+アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。追加のAPIは、[service-catalog](/docs/concepts/extend-kubernetes/service-catalog/)のような既製のソリューション、または自分で開発したAPIのいずれかです。
+
+アグリゲーションレイヤーは、[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。
 
 
 
 <!-- body -->
 
-## 概要
+## アグリゲーションレイヤー
 
-アグリゲーションレイヤーを使用すると、クラスターにKubernetesスタイルのAPIを追加でインストールできます。これらは、[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)や、[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)のようなユーザーが作成したAPIなど、出来合いのもの、また既存のサードパーティソリューションに関わらず使い始めることができます。
+アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシーします。
 
-バージョン1.7において、アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、APIServiceオブジェクトを追加しなければなりません。それを追加すると、アグリゲーションレイヤーはAPIパス（例、/apis/myextension.mycompany.io/v1/…）への全てのアクセスを、登録されたAPIServiceにプロキシします。
+APIServiceを実装する最も一般的な方法は、クラスター内で実行されるPodで*拡張APIサーバー* を実行することです。クラスター内のリソース管理に拡張APIサーバーを使用している場合、拡張APIサーバー("extension-apiserver"とも呼ばれます)は通常、1つ以上の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}とペアになっています。apiserver-builderライブラリは、拡張APIサーバーと関連するコントローラーの両方にスケルトンを提供します。
 
-通常、APIServiceは、クラスター上で動いているPod内の *extension-apiserver* で実装されます。このextension-apiserverは、追加されたリソースに対するアクティブな管理が必要な場合、通常、1つか複数のコントローラーとペアになっている必要があります。そのため、実際にapiserver-builderはextension-apiserverとコントローラーの両方のスケルトンを提供します。一例として、service-catalogがインストールされると、extension-apiserverと提供するサービスのコントローラーの両方を提供します。
+### 応答遅延
+
+拡張APIサーバーは、kube-apiserverとの間の低遅延ネットワーキングが必要です。
+kube-apiserverとの間を5秒以内に往復するためには、ディスカバリーリクエストが必要です。
+
+拡張APIサーバーがそのレイテンシ要件を達成できない場合は、その要件を満たすように変更することを検討してください。また、kube-apiserverで`EnableAggregatedDiscoveryTimeout=false` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を設定することで、タイムアウト制限を無効にすることができます。この非推奨のフィーチャーゲートは将来のリリースで削除される予定です。
 
 
 
@@ -28,6 +35,7 @@ weight: 10
 * アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します
 * そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します
 * また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい
+* [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい
 
 
 

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

@@ -84,7 +84,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
 ## {{% heading "whatsnext" %}}
 
 
-* [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます
+* [Custom Resources](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます
 * ユースケースに合わせた、既製のオペレーターを[OperatorHub.io](https://operatorhub.io/)から見つけます
 * 自前のオペレーターを書くために既存のツールを使います、例:
   * [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います

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

@@ -93,7 +93,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー
 
 ### DNS
 
-クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。
+クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。
 
 クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。
 
@@ -102,7 +102,7 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
 
 ### Web UI (ダッシュボード)
 
-[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。
+[ダッシュボード](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。
 
 ### コンテナリソース監視
 

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

@@ -86,7 +86,7 @@ APIとソフトウエアのバージョニングは、間接的にしか関連
   - バージョン名は`vX`のようになっており、`X`は整数です。
   - 安定版の機能は、今後のリリースバージョンにも適用されます。
 
-## APIグループ
+## APIグループ {#api-groups}
 
 KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
 APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。

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

@@ -34,7 +34,7 @@ Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザ
 
 Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。
 
-[ラベル](/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。
+[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。
 
 さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。
 

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

@@ -59,10 +59,23 @@ _アノテーション_ はキーとバリューのペアです。有効なア
 
 `kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
 
+たとえば、`imageregistry: https://hub.docker.com/`というアノテーションが付いたPodの構成ファイルは次のとおりです:
 
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotations-demo
+  annotations:
+    imageregistry: "https://hub.docker.com/"
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.14.2
+    ports:
+    - containerPort: 80
+```
 
 ## {{% heading "whatsnext" %}}
-
+[ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)について学習してください。
-[ラベルとセレクター](/docs/concepts/overview/working-with-objects/labels/)について学習してください。
-
 

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

@@ -128,11 +128,11 @@ kind: StatefulSet
 metadata:
   labels:
     app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
+    app.kubernetes.io/version: "5.7.21"
     app.kubernetes.io/managed-by: helm
     app.kubernetes.io/component: database
     app.kubernetes.io/part-of: wordpress
-    app.kubernetes.io/version: "5.7.21"
 ...
 ```
 
@@ -143,11 +143,11 @@ kind: Service
 metadata:
   labels:
     app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
+    app.kubernetes.io/version: "5.7.21"
     app.kubernetes.io/managed-by: helm
     app.kubernetes.io/component: database
     app.kubernetes.io/part-of: wordpress
-    app.kubernetes.io/version: "5.7.21"
 ...
 ```
 

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

@@ -10,7 +10,7 @@ _フィールドセレクター(Field Selectors)_ は、1つかそれ以上の
 * `metadata.namespace!=default`
 * `status.phase=Pending`  
 
-下記の`kubectl`コマンドは、[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。  
+下記の`kubectl`コマンドは、[`status.phase`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。  
 
 ```shell
 kubectl get pods --field-selector status.phase=Running
@@ -43,7 +43,7 @@ Error from server (BadRequest): Unable to find "ingresses" that match label sele
 例として、下記の`kubectl`コマンドは`default`ネームスペースに属していない全てのKubernetes Serviceを選択します。
 
 ```shell
-kubectl get services --field-selector metadata.namespace!=default
+kubectl get services  --all-namespaces --field-selector metadata.namespace!=default
 ```
 
 ## 連結されたセレクター
@@ -51,7 +51,7 @@ kubectl get services --field-selector metadata.namespace!=default
 下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。  
 
 ```shell
-kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
+kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
 ```
 
 ## 複数のリソースタイプ

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

@@ -22,11 +22,13 @@ card:
 
 Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。
 
-Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。
+Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。
 
 ### オブジェクトのspec（仕様）とstatus（状態）
 
-全てのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それは *spec* オブジェクトと *status* オブジェクトです。*spec* オブジェクトはあなたが指定しなければならない項目で、オブジェクトの *望ましい状態* を記述し、オブジェクトに持たせたい特徴を表現します。*status* オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。常に、Kubernetesコントロールプレーンは、あなたから指定された望ましい状態と現在の状態が一致するよう積極的に管理をします。
+ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。
+
+`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
 
 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。
 
@@ -58,9 +60,10 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
 
 * `apiVersion` - どのバージョンのKubernetesAPIを利用してオブジェクトを作成するか
 * `kind` - どの種類のオブジェクトを作成するか
-* `metadata` - オブジェクトを一意に特定するための情報、`name`、string、UID、また任意の`namespace`が該当する
+* `metadata` - オブジェクトを一意に特定するための情報、文字列の`name`、`UID`、また任意の`namespace`が該当する
+* `spec` - オブジェクトの望ましい状態
 
-またオブジェクトの`spec`の値も指定する必要があります。`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
+`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
 例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
 
 
@@ -68,6 +71,9 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
 ## {{% heading "whatsnext" %}}
 
 
+
+* [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。
 * 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。
+* Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。
 
 

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

@@ -20,7 +20,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
 ```
 
 ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。 
-識別用途でない情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。  
+識別用途でない情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。  
 
 
 
@@ -45,7 +45,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
 これらは単によく使われるラベルの例です。ユーザーは自由に規約を決めることができます。
 ラベルのキーは、ある1つのオブジェクトに対してユニークである必要があることは覚えておかなくてはなりません。  
 
-## 構文と文字セット
+## 構文と文字セット {#syntax-and-character-set}
 
 ラベルは、キーとバリューのベアです。正しいラベルキーは2つのセグメントを持ちます。  
 それは`/`によって分割されたオプショナルなプレフィックスと名前です。  
@@ -59,7 +59,27 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
 
 正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。  
 
-## ラベルセレクター
+例えば、`environment: production`と`app: nginx`の2つのラベルを持つPodの設定ファイルは下記のようになります。
+
+```yaml
+
+apiVersion: v1
+kind: Pod
+metadata:
+  name: label-demo
+  labels:
+    environment: production
+    app: nginx
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.14.2
+    ports:
+    - containerPort: 80
+
+```
+
+## ラベルセレクター {#label-selectors}
 
 [名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。
 
@@ -77,6 +97,10 @@ Kubernetes APIは現在2タイプのセレクターをサポートしていま
 ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。
 {{< /note >}}
 
+{{< caution >}}
+等価ベース、集合ベースともに、論理OR (`||`) オペレーターは存在しません。フィルターステートメントが意図した通りになっていることを確認してください。
+{{< /caution >}}
+
 ### *等価ベース(Equality-based)* の要件(requirement)
 
 *等価ベース(Equality-based)* もしくは*不等ベース(Inequality-based)* の要件は、ラベルキーとラベル値によるフィルタリングを可能にします。  
@@ -174,7 +198,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
 ```
 
 ### APIオブジェクトに参照を設定する
-[`Service`](/docs/user-guide/services) と [`ReplicationController`](/docs/user-guide/replication-controller)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/docs/user-guide/pods)のような他のリソースのセットを指定するのにも使われます。  
+[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/pod/)のような他のリソースのセットを指定するのにも使われます。  
 
 #### ServiceとReplicationController
 `Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。  

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

@@ -1,30 +1,79 @@
 ---
 reviewers:
-title: 名前
+title: オブジェクトの名前とID
 content_type: concept
 weight: 20
 ---
 
 <!-- overview -->
 
-KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明確に識別されます。
+クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。
 
-ユーザーが付与する一意ではない属性については、Kubernetesが[ラベル](/docs/user-guide/labels)と[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を付与します。
+たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。
 
-名前とUIDに関する正確な構文については、[識別子デザインドキュメント](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)を参照してください。
+ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。
 
 
 
 <!-- body -->
 
-## 名前
+## 名前 {#names}
 
 {{< glossary_definition term_id="name" length="all" >}}
 
-慣例的に、Kubernetesリソースの名前は最長253文字で、かつ英小文字、数字、また`-`、`.`から構成します。しかし、特定のリソースはより具体的な制限があります。
+次の3つの命名規則がよく使われます。
 
-## UID
+### DNSサブドメイン名 {#dns-subdomain-names}
+
+ほとんどのリソースタイプには、[RFC 1123](https://tools.ietf.org/html/rfc1123)で定義されているDNSサブドメイン名として使用できる名前が必要です。
+つまり、名前は次のとおりでなければなりません:
+
+- 253文字以内
+- 英小文字、数字、「-」または「.」のみを含む
+- 英数字で始まる
+- 英数字で終わる
+
+### DNSラベル名 {#dns-label-names}
+
+一部のリソースタイプでは、[RFC 1123](https://tools.ietf.org/html/rfc1123)で定義されているDNSラベル標準に従う名前が必要です。
+つまり、名前は次のとおりでなければなりません:
+
+- 63文字以内
+- 英小文字、数字または「-」のみを含む
+- 英数字で始まる
+- 英数字で終わる
+
+### パスセグメント名 {#path-segment-names}
+
+一部のリソースタイプでは、名前をパスセグメントとして安全にエンコードできるようにする必要があります。
+つまり、名前を「.」や「..」にすることはできず、名前に「/」または「%」を含めることはできません。
+
+以下は、`nginx-demo`という名前のPodのマニフェストの例です。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx-demo
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.14.2
+    ports:
+    - containerPort: 80
+```
+
+{{< note >}}
+一部のリソースタイプには、名前に追加の制限があります。
+{{< /note >}}
+
+## UID {#uids}
 
 {{< glossary_definition term_id="uid" length="all" >}}
 
+Kubernetes UIDは、UUIDのことを指します。
+UUIDは、ISO/IEC 9834-8およびITU-T X.667として標準化されています。
 
+## {{% heading "whatsnext" %}}
+* Kubernetesの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)についてお読みください。
+* [Kubernetesの識別子と名前](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)デザインドキュメントをご覧ください。

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

@@ -20,25 +20,25 @@ Namespaceは、複数のチーム・プロジェクトにまたがる多くの
 数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。
 Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。
 
-Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。  
+Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。Namespaceは相互にネストすることはできず、各Kubernetesリソースは1つのNamespaceにのみ存在できます。
 
 Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
 
 Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。
 
 同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
-同一のNamespace内でリソースを区別するためには[ラベル](/docs/user-guide/labels)を使用してください。  
+同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
 
 ## Namespaceを利用する
 
-Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/admin/namespaces)に記載されています。  
+Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
 
 ### Namespaceの表示
 
 ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
 
 ```shell
-kubectl get namespaces
+kubectl get namespace
 ```
 ```
 NAME          STATUS    AGE
@@ -56,12 +56,13 @@ Kubernetesの起動時には3つの初期Namespaceが作成されています。
 
 ### Namespaceの設定
 
-一時的な要求のためにNamespaceを設定したい場合、`--namespace`フラグを使用します。  
+現在のリクエストのNamespaceを設定するには、`--namespace`フラグを使用します。
+
 例:
 
 ```shell
-kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
+kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
-kubectl --namespace=<insert-namespace-name-here> get pods
+kubectl get pods --namespace=<insert-namespace-name-here>
 ```
 
 ### Namespace設定の永続化
@@ -69,14 +70,14 @@ kubectl --namespace=<insert-namespace-name-here> get pods
 ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
 
 ```shell
-kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
+kubectl config set-context --current --namespace=<insert-namespace-name-here>
 # Validate it
-kubectl config view | grep namespace:
+kubectl config view --minify | grep namespace:
 ```
 
 ## NamespaceとDNS
 
-ユーザーが[Service](/docs/user-guide/services)を作成するとき、Serviceは対応する[DNSエントリ](/docs/concepts/services-networking/dns-pod-service/)を作成します。  
+ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。
 このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
 これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
@@ -85,7 +86,7 @@ kubectl config view | grep namespace:
 
 ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。
 しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。
-そして[Node](/docs/admin/node)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。 
+そして[Node](/ja/docs/concepts/architecture/nodes/)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
 
 どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
 
@@ -97,4 +98,6 @@ kubectl api-resources --namespaced=true
 kubectl api-resources --namespaced=false
 ```
 
-
+## {{% heading "whatsnext" %}}
+* [新しいNamespaceの作成](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)について学習してください。
+* [Namespaceの削除](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)について学習してください。

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

@@ -0,0 +1,5 @@
+---
+title: "ポリシー"
+weight: 90
+---
+

content/ja/docs/concepts/policy/resource-quotas.md

@@ -0,0 +1,556 @@
+---
+reviewers:
+title: リソースクォータ
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+
+複数のユーザーやチームが決められた数のノードを持つクラスターを共有しているとき、1つのチームが公平に使えるリソース量を超えて使用するといった問題が出てきます。
+
+リソースクォータはこの問題に対処するための管理者向けツールです。
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。
+
+リソースクォータは下記のように働きます。
+
+- 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。
+- 管理者は各名前空間で1つの`ResourceQuota`を作成します。
+- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
+- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
+- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。
+
+`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.
+
+名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。
+
+- 32GiB RAM、16コアのキャパシティーを持つクラスターで、Aチームに20GiB、10コアを割り当て、Bチームに10GiB、4コアを割り当て、将来の割り当てのために2GiB、2コアを予約しておく。
+- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかけ、"production"という名前空間には制限をかけない。
+
+クラスターの総キャパシティーが、その名前空間のクォータの合計より少ない場合、リソースの競合が発生する場合があります。このとき、リソースの先着順で処理されます。
+
+リソースの競合もクォータの変更も、作成済みのリソースには影響しません。
+
+## リソースクォータを有効にする
+
+多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。
+
+特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。
+
+## リソースクォータの計算
+
+特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。
+
+下記のリソースタイプがサポートされています。
+
+
+| リソース名 | 説明 |
+| --------------------- | ----------------------------------------------------------- |
+| `limits.cpu` | 停止していない状態の全てのPodで、CPUリミットの合計がこの値を超えることができません。 |
+| `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 |
+| `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 |
+| `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 |
+
+### 拡張リソースのためのリソースクォータ
+
+上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。
+
+拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。
+
+GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で、ユーザーが名前空間内でリクエストされるGPUの上限を4に指定するとき、下記のようにリソースクォータを定義します。
+
+* `requests.nvidia.com/gpu: 4`
+
+さらなる詳細は[クォータの確認と設定](#viewing-and-setting-quotas)を参照してください。
+
+
+## ストレージのリソースクォータ
+
+特定の名前空間において[ストレージリソース](/ja/docs/concepts/storage/persistent-volumes/)の総数に上限をかけることができます。
+
+さらに、関連するストレージクラスに基づいて、ストレージリソースの消費量に上限をかけることもできます。
+
+| リソース名 | 説明 |
+| --------------------- | ----------------------------------------------------------- |
+| `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 |
+| `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
+
+例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。
+
+* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
+* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi`
+
+Kubernetes v1.8において、ローカルのエフェメラルストレージに対するリソースクォータのサポートがα版の機能として追加されました。
+
+| リソース名 | 説明 |
+| ------------------------------- |----------------------------------------------------------- |
+| `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 |
+| `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 |
+
+## オブジェクト数に対するクォータ
+
+Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。
+
+* `count/<resource>.<group>`
+
+オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。
+
+* `count/persistentvolumeclaims`
+* `count/services`
+* `count/secrets`
+* `count/configmaps`
+* `count/replicationcontrollers`
+* `count/deployments.apps`
+* `count/replicasets.apps`
+* `count/statefulsets.apps`
+* `count/jobs.batch`
+* `count/cronjobs.batch`
+* `count/deployments.extensions`
+
+Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。
+
+`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。
+
+Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。
+
+下記のタイプのリソースがサポートされています。
+
+| リソース名 | 説明 |
+| ------------------------------- | ------------------------------------------------- |
+| `configmaps` | 名前空間内で存在可能なConfigMapの総数。  |
+| `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
+| `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。  |
+| `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 |
+| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 |
+| `services` | 名前空間内で存在可能なServiceの総数。 |
+| `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 |
+| `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 |
+| `secrets` | 名前空間内で存在可能なSecretの総数。 |
+
+例えば、`pods`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`pods`のリソースクォータを名前空間に設定したい場合があります。
+
+## クォータのスコープについて
+
+各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。
+
+スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。
+
+| スコープ | 説明 |
+| ----- | ----------- |
+| `Terminating` | `.spec.activeDeadlineSeconds >= 0`であるPodに一致します。 |
+| `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 |
+| `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 |
+| `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 |
+
+`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods`
+
+`Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します:
+
+* `cpu`
+* `limits.cpu`
+* `limits.memory`
+* `memory`
+* `pods`
+* `requests.cpu`
+* `requests.memory`
+
+### PriorityClass毎のリソースクォータ
+
+{{< feature-state for_k8s_version="1.12" state="beta" >}}
+
+Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
+
+リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。
+
+この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。
+
+- クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。
+- 1つのリソースクォータのオブジェクトは優先度毎に作成されます。
+
+下記のYAMLを`quota.yml`というファイルに保存します。
+
+```yaml
+apiVersion: v1
+kind: List
+items:
+- apiVersion: v1
+  kind: ResourceQuota
+  metadata:
+    name: pods-high
+  spec:
+    hard:
+      cpu: "1000"
+      memory: 200Gi
+      pods: "10"
+    scopeSelector:
+      matchExpressions:
+      - operator : In
+        scopeName: PriorityClass
+        values: ["high"]
+- apiVersion: v1
+  kind: ResourceQuota
+  metadata:
+    name: pods-medium
+  spec:
+    hard:
+      cpu: "10"
+      memory: 20Gi
+      pods: "10"
+    scopeSelector:
+      matchExpressions:
+      - operator : In
+        scopeName: PriorityClass
+        values: ["medium"]
+- apiVersion: v1
+  kind: ResourceQuota
+  metadata:
+    name: pods-low
+  spec:
+    hard:
+      cpu: "5"
+      memory: 10Gi
+      pods: "10"
+    scopeSelector:
+      matchExpressions:
+      - operator : In
+        scopeName: PriorityClass
+        values: ["low"]
+```
+
+`kubectl create`を実行してYAMLの内容を適用します。
+
+```shell
+kubectl create -f ./quota.yml
+```
+
+```shell
+resourcequota/pods-high created
+resourcequota/pods-medium created
+resourcequota/pods-low created
+```
+
+`kubectl describe quota`を実行して`Used`クォータが`0`であることを確認します。
+
+```shell
+kubectl describe quota
+```
+
+```shell
+Name:       pods-high
+Namespace:  default
+Resource    Used  Hard
+--------    ----  ----
+cpu         0     1k
+memory      0     200Gi
+pods        0     10
+
+
+Name:       pods-low
+Namespace:  default
+Resource    Used  Hard
+--------    ----  ----
+cpu         0     5
+memory      0     10Gi
+pods        0     10
+
+
+Name:       pods-medium
+Namespace:  default
+Resource    Used  Hard
+--------    ----  ----
+cpu         0     10
+memory      0     20Gi
+pods        0     10
+```
+
+プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに保存します。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: high-priority
+spec:
+  containers:
+  - name: high-priority
+    image: ubuntu
+    command: ["/bin/sh"]
+    args: ["-c", "while true; do echo hello; sleep 10;done"]
+    resources:
+      requests:
+        memory: "10Gi"
+        cpu: "500m"
+      limits:
+        memory: "10Gi"
+        cpu: "500m"
+  priorityClassName: high
+```
+
+`kubectl create`でマニフェストを適用します。
+
+```shell
+kubectl create -f ./high-priority-pod.yml
+```
+
+`pods-high`という名前のプライオリティーが"high"のクォータにおける"Used"項目の値が変更され、それ以外の2つの値は変更されていないことを確認してください。
+
+```shell
+kubectl describe quota
+```
+
+```shell
+Name:       pods-high
+Namespace:  default
+Resource    Used  Hard
+--------    ----  ----
+cpu         500m  1k
+memory      10Gi  200Gi
+pods        1     10
+
+
+Name:       pods-low
+Namespace:  default
+Resource    Used  Hard
+--------    ----  ----
+cpu         0     5
+memory      0     10Gi
+pods        0     10
+
+
+Name:       pods-medium
+Namespace:  default
+Resource    Used  Hard
+--------    ----  ----
+cpu         0     10
+memory      0     20Gi
+pods        0     10
+```
+
+`scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。
+
+* `In`
+* `NotIn`
+* `Exist`
+* `DoesNotExist`
+
+## リクエスト vs リミット
+
+コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。
+
+クォータに`requests.cpu`や`requests.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、クォータに`limits.cpu`や`limits.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な制限を行います。
+
+## クォータの確認と設定 {#viewing-and-setting-quotas}
+
+kubectlでは、クォータの作成、更新、確認をサポートしています。
+
+```shell
+kubectl create namespace myspace
+```
+
+```shell
+cat <<EOF > compute-resources.yaml
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+  name: compute-resources
+spec:
+  hard:
+    requests.cpu: "1"
+    requests.memory: 1Gi
+    limits.cpu: "2"
+    limits.memory: 2Gi
+    requests.nvidia.com/gpu: 4
+EOF
+```
+
+```shell
+kubectl create -f ./compute-resources.yaml --namespace=myspace
+```
+
+```shell
+cat <<EOF > object-counts.yaml
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+  name: object-counts
+spec:
+  hard:
+    configmaps: "10"
+    persistentvolumeclaims: "4"
+    pods: "4"
+    replicationcontrollers: "20"
+    secrets: "10"
+    services: "10"
+    services.loadbalancers: "2"
+EOF
+```
+
+```shell
+kubectl create -f ./object-counts.yaml --namespace=myspace
+```
+
+```shell
+kubectl get quota --namespace=myspace
+```
+
+```shell
+NAME                    AGE
+compute-resources       30s
+object-counts           32s
+```
+
+```shell
+kubectl describe quota compute-resources --namespace=myspace
+```
+
+```shell
+Name:                    compute-resources
+Namespace:               myspace
+Resource                 Used  Hard
+--------                 ----  ----
+limits.cpu               0     2
+limits.memory            0     2Gi
+requests.cpu             0     1
+requests.memory          0     1Gi
+requests.nvidia.com/gpu  0     4
+```
+
+```shell
+kubectl describe quota object-counts --namespace=myspace
+```
+
+```shell
+Name:                   object-counts
+Namespace:              myspace
+Resource                Used    Hard
+--------                ----    ----
+configmaps              0       10
+persistentvolumeclaims  0       4
+pods                    0       4
+replicationcontrollers  0       20
+secrets                 1       10
+services                0       10
+services.loadbalancers  0       2
+```
+
+また、kubectlは`count/<resource>.<group>`というシンタックスを用いることにより、名前空間に依存した全ての主要なリソースに対するオブジェクト数のクォータをサポートしています。
+
+```shell
+kubectl create namespace myspace
+```
+
+```shell
+kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
+```
+
+```shell
+kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
+```
+
+```shell
+kubectl describe quota --namespace=myspace
+```
+
+```shell
+Name:                         test
+Namespace:                    myspace
+Resource                      Used  Hard
+--------                      ----  ----
+count/deployments.extensions  1     2
+count/pods                    2     3
+count/replicasets.extensions  1     4
+count/secrets                 1     4
+```
+
+## クォータとクラスター容量
+
+`ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。
+
+下記のようなより複雑なポリシーが必要な状況があります。
+
+  - 複数チーム間でクラスターリソースの総量を分けあう。
+  - 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。
+  - 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。
+
+このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。
+
+リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。
+
+## デフォルトで優先度クラスの消費を制限する
+
+例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。
+
+このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。
+
+これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。
+
+{{< tabs name="example1" >}}
+{{% tab name="apiserver.config.k8s.io/v1" %}}
+```yaml
+apiVersion: apiserver.config.k8s.io/v1
+kind: AdmissionConfiguration
+plugins:
+- name: "ResourceQuota"
+  configuration:
+    apiVersion: apiserver.config.k8s.io/v1
+    kind: ResourceQuotaConfiguration
+    limitedResources:
+    - resource: pods
+      matchScopes:
+      - scopeName: PriorityClass
+        operator: In
+        values: ["cluster-services"]
+```
+{{% /tab %}}
+{{% tab name="apiserver.k8s.io/v1alpha1" %}}
+```yaml
+# v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。
+apiVersion: apiserver.k8s.io/v1alpha1
+kind: AdmissionConfiguration
+plugins:
+- name: "ResourceQuota"
+  configuration:
+    # v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。
+    apiVersion: resourcequota.admission.k8s.io/v1beta1
+    kind: Configuration
+    limitedResources:
+    - resource: pods
+      matchScopes:
+      - scopeName: PriorityClass
+        operator: In
+        values: ["cluster-services"]
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。
+
+```yaml
+    scopeSelector:
+      matchExpressions:
+      - scopeName: PriorityClass
+        operator: In
+        values: ["cluster-services"]
+```
+
+さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。
+
+## 例
+
+[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
+
+{{% /capture %}}

content/ja/docs/concepts/scheduling/kube-scheduler.md

@@ -106,7 +106,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
 
 - `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
 
-- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
+- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
 
 - `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
 
@@ -114,6 +114,8 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
 ## {{% heading "whatsnext" %}}
 
 * [スケジューラーのパフォーマンスチューニング](/docs/concepts/scheduling/scheduler-perf-tuning/)を参照してください。
+* [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。
 * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
-* [複数のスケジューラーの設定](https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
+* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
-
+* [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。
+* [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。

content/ja/docs/concepts/services-networking/connect-applications-service.md

@@ -77,7 +77,7 @@ Kubernetes Serviceは、クラスター内のどこかで実行されるPodの
 このアドレスはServiceの有効期間に関連付けられており、Serviceが動作している間は変更されません。
 Podは、Serviceと通信するように構成でき、Serviceへの通信は、ServiceのメンバーであるPodに自動的に負荷分散されることを認識できます。
 
-2つのnginxレプリカのサービスを`kubectl exposed`で作成できます:
+2つのnginxレプリカのサービスを`kubectl expose`で作成できます:
 
 ```shell
 kubectl expose deployment/my-nginx

content/ja/docs/concepts/services-networking/dns-pod-service.md

@@ -25,13 +25,13 @@ Kubernetesの`bar`というネームスペース内で`foo`という名前のSer
 うまく機能する他のレイアウト、名前、またはクエリーは、実装の詳細を考慮し、警告なしに変更されることがあります。  
 最新の仕様に関する詳細は、[KubernetesにおけるDNSベースのServiceディスカバリ](https://github.com/kubernetes/dns/blob/master/docs/specification.md)を参照ください。
 
-## Service
+## Service {#services}
 
-### Aレコード
+### A/AAAAレコード
 
-"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。
+"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを、ServiceのIPバージョンに応じて割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。
 
-"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。通常のServiceとは異なり、このAレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います…
+"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを、ServiceのIPバージョンに応じて割り当てられます。通常のServiceとは異なり、このレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います。
 
 ### SRVレコード
 
@@ -42,12 +42,6 @@ Headless Serviceに対しては、このSRVレコードは複数の結果を返
 
 ## Pod
 
-### Aレコード
-
-DNSが有効なとき、Podは"`pod-ip-address.my-namespace.pod.cluster.local`"という形式のAレコードを割り当てられます。
-
-例えば、`default`ネームスペース内で`cluster.local`というDNS名を持ち、`1.2.3.4`というIPを持ったPodは次の形式のエントリーを持ちます。: `1-2-3-4.default.pod.cluster.local`。
-
 ### Podのhostnameとsubdomainフィールド
 
 現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。
@@ -105,13 +99,13 @@ spec:
     name: busybox
 ```
 
-もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのKubeDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するAレコードを返します。
+もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するA(AAAA)レコードを返します。
-例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはそのPodのIPを指し示すAレコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したAレコードを持ちます。
+例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはそのPodのIPを指し示すA(AAAA)レコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したA(AAAA)レコードを持ちます。
 
 そのエンドポイントオブジェクトはそのIPに加えて`hostname`を任意のエンドポイントアドレスに対して指定できます。
 
 {{< note >}}
-AレコードはPodの名前に対して作成されないため、`hostname`はPodのAレコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するAレコードのみ作成します。
+A(AAAA)レコードはPodの名前に対して作成されないため、`hostname`はPodのA(AAAA)レコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するA(AAAA)レコードのみ作成します。
 {{< /note >}}
 
 ### PodのDNSポリシー
@@ -148,7 +142,7 @@ spec:
   dnsPolicy: ClusterFirstWithHostNet
 ```
 
-### PodのDNS設定
+### PodのDNS設定 {#pods-dns-config}
 
 PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。
 

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

@@ -15,19 +15,15 @@ weight: 40
 
 まずわかりやすくするために、このガイドでは次の用語を定義します。
 
-- ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
+* ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
-
+* クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。
-- クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。  
+* エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。
-  
+* クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
-- エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。
+* Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。
-
-- クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
-
-- Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。
 
 ## Ingressとは何か
 
-Ingressはクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
+[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
 
 ```none
     internet
@@ -74,7 +70,8 @@ spec:
           servicePort: 80
 ```
 
-他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。  
+他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。
 Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。
 [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。
 
@@ -112,10 +109,10 @@ kubectl get ingress test-ingress
 
 ```
 NAME           HOSTS     ADDRESS           PORTS     AGE
-test-ingress   *         107.178.254.228   80        59s
+test-ingress   *         203.0.113.123     80        59s
 ```
 
-`107.178.254.228`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。
+`203.0.113.123`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。
 
 {{< note >}}
 IngressコントローラーとロードバランサーがIPアドレス割り当てるのに1、2分ほどかかります。この間、ADDRESSの情報は`<pending>`となっているのを確認できます。
@@ -288,7 +285,7 @@ spec:
 ```
 
 {{< note >}}
-Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://git.k8s.io/ingress-nginx/README.md#https)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
+Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
 {{< /note >}}
 
 ### 負荷分散
@@ -396,9 +393,8 @@ Ingressリソースに直接関与しない複数の方法でServiceを公開で
 * [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)
 
 
-
 ## {{% heading "whatsnext" %}}
-
+* [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
 * [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ
 * [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
 

content/ja/docs/concepts/services-networking/service.md

@@ -49,7 +49,7 @@ Serviceによる抽象化は、クライアントからバックエンドのPod
 
 ## Serviceの定義
 
-KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。
+KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。Serviceオブジェクトの名前は、有効な[DNSラベル名](/ja/docs/concepts/overview/working-with-objects/names#dns-label-names)である必要があります。
 
 例えば、TCPで9376番ポートで待ち受けていて、`app=Myapp`というラベルをもつPodのセットがあるとします。
 
@@ -123,6 +123,8 @@ subsets:
       - port: 9376
 ```
 
+Endpointsオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
 {{< note >}}
 Endpointsのipは、loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), や
 link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設定することができません。
@@ -183,7 +185,7 @@ kube-proxyは、どのバックエンドPodを使うかを決める際にService
 kube-proxyがiptablesモードで稼働し、最初に選択されたPodが応答しない場合、そのコネクションは失敗します。
 これはuser-spaceモードでの挙動と異なります: user-spaceモードにおいては、kube-proxyは最初のPodに対するコネクションが失敗したら、自動的に他のバックエンドPodに対して再接続を試みます。
 
-iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。  
+iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。
 
 ![iptablesプロキシーのService概要ダイアグラム](/images/docs/services-iptables-overview.svg)
 
@@ -196,7 +198,7 @@ iptablesモードのkube-proxyが正常なバックエンドPodのみをリダ
 Serviceにアクセスするとき、IPVSはトラフィックをバックエンドのPodに向けます。
 
 IPVSプロキシーモードはiptablesモードと同様に、netfilterのフック関数に基づいています。ただし、基礎となるデータ構造としてハッシュテーブルを使っているのと、kernel-spaceで動作します。
-これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。　　
+これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。
 他のプロキシーモードと比較して、IPVSモードはより高いネットワークトラフィックのスループットをサポートしています。
 
 IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。
@@ -219,7 +221,7 @@ kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュー
 
 このダイアグラムのプロキシーモデルにおいて、ServiceのIP:Portに対するトラフィックは、クライアントがKubernetesのServiceやPodについて何も知ることなく適切にバックエンドにプロキシーされています。
 
-特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`を"ClientIP"にセットすることにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。
+特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`に"ClientIP"を設定することにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。
 また、`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`を適切に設定することにより、セッションのタイムアウト時間を設定できます(デフォルトではこの値は18,000で、3時間となります)。
 
 ## 複数のポートを公開するService
@@ -306,7 +308,7 @@ CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、
 Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
 
 KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。
-[DNS Pods と Service](/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
+[DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
 
 ## Headless Service {#headless-service}
 
@@ -345,7 +347,7 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類
    * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
 
      {{< note >}}
-     `ExternalName`タイプのServiceを利用するためには、CoreDNSのバージョン1.7以上が必要となります。
+     `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
      {{< /note >}}
 
 また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
@@ -399,6 +401,8 @@ status:
 
 外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。
 
+LoadBalancerタイプのサービスで複数のポートが定義されている場合、すべてのポートが同じプロトコルである必要があり、さらにそのプロトコルは`TCP`、`UDP`、`SCTP`のいずれかである必要があります。
+
 いくつかのクラウドプロバイダーにおいて、`loadBalancerIP`の設定をすることができます。このようなケースでは、そのロードバランサーはユーザーが指定した`loadBalancerIP`に対してロードバランサーを作成します。
 もし`loadBalancerIP`フィールドの値が指定されていない場合、そのロードバランサーはエフェメラルなIPアドレスに対して作成されます。もしユーザーが`loadBalancerIP`を指定したが、使っているクラウドプロバイダーがその機能をサポートしていない場合、その`loadBalancerIP`フィールドに設定された値は無視されます。
 
@@ -512,7 +516,7 @@ metadata:
 
 2つ目のアノテーションはPodが利用するプロトコルを指定するものです。HTTPSとSSLの場合、ELBはそのPodが証明書を使って暗号化されたコネクションを介して自分自身のPodを認証すると推測します。
 
-HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwardef-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
+HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwarded-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
 
 TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。
 
@@ -740,14 +744,14 @@ IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginx
 IPアドレスをハードコードする場合、[Headless Service](#headless-service)の使用を検討してください。
 {{< /note >}}
 
-`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`CNAME`レコードと`my.database.example.com`という値を返します。  
+`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`my.database.example.com`という値をもつ`CNAME`レコードを返します。
 `my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
-後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。
+後にユーザーが使用しているデータベースをクラスター内に移行することになった場合は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。
 
 {{< warning >}}
 HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する際に問題が発生する場合があります。ExternalNameを使用する場合、クラスター内のクライアントが使用するホスト名は、ExternalNameが参照する名前とは異なります。
 
-ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストには、オリジンサーバーが認識しない`Host:`ヘッダーがあります。TLSサーバーは、クライアントが接続したホスト名に一致する証明書を提供できません。
+ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストがオリジンサーバーが認識しない`Host:`ヘッダーを持っていたなら、TLSサーバーはクライアントが接続したホスト名に一致する証明書を提供できません。
 {{< /warning >}}
 
 {{< note >}}
@@ -800,7 +804,7 @@ iptablesプロキシーモードはクラスター内の送信元IPを不明瞭
 ### 衝突の回避
 
 Kubernetesの主要な哲学のうちの一つは、ユーザーは、ユーザー自身のアクションによるミスでないものによって、ユーザーのアクションが失敗するような状況に晒されるべきでないことです。
-Serviceリソースの設計のでは、これはユーザーの指定したポートが衝突する可能性がある場合は、そのポートのServiceを作らないことを意味します。これは障害を分離することとなります。
+Serviceリソースの設計において、これはユーザーの指定したポートが衝突する可能性がある場合はそのポートのServiceを作らないことを意味します。これは障害を分離することとなります。
 
 Serviceのポート番号を選択できるようにするために、我々はどの2つのServiceでもポートが衝突しないことを保証します。
 Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てることで実現しています。
@@ -860,20 +864,14 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
 
 ### TCP
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 ユーザーはどの種類のServiceにおいてもTCPを利用できます。これはデフォルトのネットワークプロトコルです。
 
 ### UDP
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 ユーザーは多くのServiceにおいてUDPを利用できます。 type=LoadBalancerのServiceにおいては、UDPのサポートはこの機能を提供しているクラウドプロバイダーに依存しています。
 
 ### HTTP
 
-{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-
 もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
 
 {{< note >}}
@@ -882,8 +880,6 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
 
 ### PROXY プロトコル
 
-{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-
 もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
 
 ロードバランサーは、最初の一連のオクテットを送信します。
@@ -932,16 +928,6 @@ SCTPはWindowsベースのNodeではサポートされていません。
 kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。
 {{< /warning >}}
 
-## Future work
-
-将来的に、Serviceのプロキシーポリシーはシンプルなラウンドロビンのバランシングだけでなく、もっと細かな設定が可能になります。例えば、Masterによって選択されるものや、水平シャーディングされたりするようになります。  
-我々もまた、いくつかのServiceが"実際の"ロードバランサーを備えることを想定します。その場合、仮想IPは単純にパケットをそのロードバランサーに転送します。
-
-Kubernetesプロジェクトは、L7 (HTTP) Serviceへのサポートをもっと発展させようとしています。
-
-Kubernetesプロジェクトは、現在利用可能なClusterIP、NodePortやLoadBalancerタイプのServiceに対して、より柔軟なIngressのモードを追加する予定です。
-
-
 
 ## {{% heading "whatsnext" %}}
 

content/ja/docs/concepts/storage/dynamic-provisioning.md

@@ -8,7 +8,7 @@ weight: 40
 <!-- overview -->
 
 ボリュームの動的プロビジョニングにより、ストレージ用のボリュームをオンデマンドに作成することができます。
-動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。
+動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/ja/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。
 
 
 
@@ -20,11 +20,12 @@ weight: 40
 ボリュームの動的プロビジョニングの実装は`storage.k8s.io`というAPIグループ内の`StorageClass`というAPIオブジェクトに基づいています。クラスター管理者は`StorageClass`オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする*Volumeプラグイン* (別名*プロビジョナー*)と、プロビジョンされるときにプロビジョナーに渡されるパラメータを指定します。
 クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメータのカスタムセットを持ちます。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。
 
-StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/persistent-volumes/#storageclasses)を参照ください。
+StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/storage-classes/)を参照ください。
 
 ## 動的プロビジョニングを有効にする
 
-動的プロビジョニングを有効にするために、クラスター管理者はユーザーのために1つまたはそれ以上のStorageClassを事前に作成する必要があります。StorageClassオブジェクトは、動的プロビジョニングが実行されるときに、どのプロビジョナーが使用されるべきか、またどのようなパラメーターをプロビジョナーに渡すべきか定義します。  
+動的プロビジョニングを有効にするために、クラスター管理者はユーザーのために1つまたはそれ以上のStorageClassを事前に作成する必要があります。StorageClassオブジェクトは、動的プロビジョニングが実行されるときに、どのプロビジョナーが使用されるべきか、またどのようなパラメーターをプロビジョナーに渡すべきか定義します。StorageClassオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
 下記のマニフェストでは標準的な永続化ディスクをプロビジョンする"slow"というStorageClassを作成します。
 
 ```yaml

content/ja/docs/concepts/storage/persistent-volumes.md

@@ -54,7 +54,7 @@ APIサーバーのコマンドラインフラグの詳細については[kube-ap
 
 ### バインディング
 
-ユーザは、特定のサイズのストレージとアクセスモードを指定した上で`PersistentVolumeClaim`を作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なく`PersistentVolumeClaim`の紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは1対1です。
+ユーザは、特定のサイズのストレージとアクセスモードを指定した上でPersistentVolumeClaimを作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なくPersistentVolumeClaimの紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは、PersistentVolumeとPersistentVolumeClaim間の双方向の紐付けであるClaimRefを使用した1対1のマッピングになっています。
 
 一致するボリュームが存在しない場合、クレームはいつまでも紐付けされないままになります。一致するボリュームが利用可能になると、クレームがバインドされます。たとえば、50GiのPVがいくつもプロビジョニングされているクラスターだとしても、100Giを要求するPVCとは一致しません。100GiのPVがクラスターに追加されると、PVCを紐付けできます。
 
@@ -99,7 +99,7 @@ Labels:          type=local
 Annotations:     <none>
 Finalizers:      [kubernetes.io/pv-protection]
 StorageClass:    standard
-Status:          Available
+Status:          Terminating
 Claim:
 Reclaim Policy:  Delete
 Access Modes:    RWO
@@ -131,7 +131,7 @@ Events:            <none>
 #### リサイクル
 
 {{< warning >}}
-`Recycle`再クレームポリシーは廃止されました。代わりに、動的プロビジョニングを使用することをおすすめします。
+`Recycle`再クレームポリシーは非推奨になりました。代わりに、動的プロビジョニングを使用することをおすすめします。
 {{< /warning >}}
 
 基盤となるボリュームプラグインでサポートされている場合、`Recycle`再クレームポリシーはボリュームに対して基本的な削除(`rm -rf /thevolume/*`)を実行し、新しいクレームに対して再び利用できるようにします。
@@ -260,6 +260,8 @@ EBSの拡張は時間がかかる操作です。また変更は、ボリュー
 ## 永続ボリューム
 
 各PVには、仕様とボリュームのステータスが含まれているspecとstatusが含まれています。
+PersistentVolumeオブジェクトの名前は、有効な
+[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
 
 ```yaml
 apiVersion: v1
@@ -282,6 +284,11 @@ spec:
     server: 172.17.0.2
 ```
 
+{{< note >}}
+クラスター内でPersistentVolumeを使用するには、ボリュームタイプに関連するヘルパープログラムが必要な場合があります。
+この例では、PersistentVolumeはNFSタイプで、NFSファイルシステムのマウントをサポートするためにヘルパープログラム`/sbin/mount.nfs`が必要になります。
+{{< /note >}}
+
 ### 容量
 
 通常、PVには特定のストレージ容量があります。これはPVの`capacity`属性を使用して設定されます。容量によって期待される単位を理解するためには、Kubernetesの[リソースモデル](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)を参照してください。
@@ -400,10 +407,13 @@ PVは[ノードアフィニティ](/docs/reference/generated/kubernetes-api/{{<
 
 CLIにはPVに紐付いているPVCの名前が表示されます。
 
-## 永続ボリューム要求
+## 永続ボリューム要求 {#persistentvolumeclaims}
 
 各PVCにはspecとステータスが含まれます。これは、仕様とクレームのステータスです。
 
+PersistentVolumeClaimオブジェクトの名前は、有効な
+[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
 ```yaml
 apiVersion: v1
 kind: PersistentVolumeClaim
@@ -438,7 +448,7 @@ Podと同様に、クレームは特定の量のリソースを要求できま
 
 ### セレクター
 
-クレームでは、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を指定して、ボリュームセットをさらにフィルター処理できます。ラベルがセレクターに一致するボリュームのみがクレームにバインドできます。セレクターは2つのフィールドで構成できます。
+クレームでは、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を指定して、ボリュームセットをさらにフィルター処理できます。ラベルがセレクターに一致するボリュームのみがクレームにバインドできます。セレクターは2つのフィールドで構成できます。
 
 * `matchLabels` - ボリュームはこの値のラベルが必要です
 * `matchExpressions` - キー、値のリスト、およびキーと値を関連付ける演算子を指定することによって作成された要件のリスト。有効な演算子は、In、NotIn、ExistsおよびDoesNotExistです。
@@ -594,7 +604,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス
 
 ## ボリュームのスナップショットとスナップショットからのボリュームの復元のサポート
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
 ボリュームスナップショット機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームのスナップショット](/docs/concepts/storage/volume-snapshots/)を参照してください。
 
@@ -624,7 +634,7 @@ spec:
 
 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
 
-ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
+ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
 
 PVCデータソースからのボリューム複製機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
 
@@ -658,4 +668,15 @@ spec:
   - ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
 - ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。
 
+  ## {{% heading "whatsnext" %}}
 
+* [Creating a Persistent Volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)について学ぶ
+* [Creating a Persistent Volume Claim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)について学ぶ
+* [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)を読む
+
+### リファレンス
+
+* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
+* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
+* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
+* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)

content/ja/docs/concepts/storage/volume-pvc-datasource.md

@@ -6,16 +6,9 @@ weight: 30
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
 このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。
 
-この機能を使用するにはVolumePVCDataSourceのフィーチャーゲートを有効にする必要があります。
-
-```
---feature-gates=VolumePVCDataSource=true
-```
-
-
 
 
 
@@ -27,14 +20,17 @@ weight: 30
 
 複製は既存のKubernetesボリュームの複製として定義され、標準のボリュームと同じように使用できます。唯一の違いは、プロビジョニング時に「新しい」空のボリュームを作成するのではなく、バックエンドデバイスが指定されたボリュームの正確な複製を作成することです。
 
-複製の実装は、Kubernetes APIの観点からは新しいPVCの作成時に既存のバインドされていないPVCをdataSourceとして指定する機能を追加するだけです。
+複製の実装は、Kubernetes APIの観点からは新しいPVCの作成時に既存のPVCをdataSourceとして指定する機能を追加するだけです。ソースPVCはバインドされており、使用可能でなければなりません(使用中ではありません)。
 
 この機能を使用する場合、ユーザーは次のことに注意する必要があります:
 
 * 複製のサポート(`VolumePVCDataSource`)はCSIドライバーのみです。
 * 複製のサポートは動的プロビジョニングのみです。
 * CSIドライバーはボリューム複製機能を実装している場合としていない場合があります。
-* PVCは複製先のPVCと同じ名前空間に存在する場合にのみ複製できます（複製元と複製先は同じ名前空間になければなりません）。
+* PVCは複製先のPVCと同じ名前空間に存在する場合にのみ複製できます(複製元と複製先は同じ名前空間になければなりません)。
+* 複製は同じストレージクラス内でのみサポートされます。
+    - 宛先ボリュームは、ソースと同じストレージクラスである必要があります。
+    - デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。
 
 
 ## プロビジョニング
@@ -48,13 +44,21 @@ metadata:
     name: clone-of-pvc-1
     namespace: myns
 spec:
-  capacity:
+  accessModes:
-    storage: 10Gi
+  - ReadWriteOnce
+  storageClassName: cloning
+  resources:
+    requests:
+      storage: 5Gi
   dataSource:
     kind: PersistentVolumeClaim
     name: pvc-1
 ```
 
+{{< note >}}
+`spec.resources.requests.storage`に容量の値を指定する必要があります。指定する値は、ソースボリュームの容量と同じかそれ以上である必要があります。
+{{< /note >}}
+
 このyamlの作成結果は指定された複製元である`pvc-1`と全く同じデータを持つ`clone-of-pvc-1`という名前の新しいPVCです。
 
 ## 使い方

content/ja/docs/concepts/storage/volume-snapshot-classes.md

@@ -21,28 +21,35 @@ weight: 30
 
 ## VolumeSnapshotClass リソース
 
-各`VolumeSnapshotClass`は`snapshotter`と`parameters`フィールドを含み、それらは、そのクラスに属する`VolumeSnapshot`が動的にプロビジョンされるときに使われます。
+各`VolumeSnapshotClass`は`driver`、`deletionPolicy`と`parameters`フィールドを含み、それらは、そのクラスに属する`VolumeSnapshot`が動的にプロビジョンされるときに使われます。
 
 `VolumeSnapshotClass`オブジェクトの名前は重要であり、それはユーザーがどのように特定のクラスをリクエストできるかを示したものです。管理者は初めて`VolumeSnapshotClass`オブジェクトを作成するときに、その名前と他のパラメーターをセットし、そのオブジェクトは一度作成されるとそのあと更新することができません。
 
 管理者は、バインド対象のクラスを1つもリクエストしないようなVolumeSnapshotのために、デフォルトの`VolumeSnapshotClass`を指定することができます。
 
 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1alpha1
+apiVersion: snapshot.storage.k8s.io/v1beta1
 kind: VolumeSnapshotClass
 metadata:
   name: csi-hostpath-snapclass
-snapshotter: csi-hostpath
+driver: hostpath.csi.k8s.io
+deletionPolicy: Delete
 parameters:
 ```
 
-### Snapshotter
+### Driver
 
-VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何のCSIボリュームプラグインを使うか決定するための`snapshotter`フィールドを持っています。このフィールドは必須となります。
+VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何のCSIボリュームプラグインを使うか決定するための`driver`フィールドを持っています。このフィールドは必須となります。
+
+### DeletionPolicy
+
+VolumeSnapshotClassにはdeletionPolicyがあります。これにより、バインドされている `VolumeSnapshot`オブジェクトが削除されるときに、`VolumeSnapshotContent`がどうなるかを設定することができます。VolumeSnapshotのdeletionPolicyは、`Retain`または`Delete`のいずれかです。このフィールドは指定しなければなりません。
+
+deletionPolicyが`Delete`の場合、元となるストレージスナップショットは `VolumeSnapshotContent`オブジェクトとともに削除されます。deletionPolicyが`Retain`の場合、元となるスナップショットと`VolumeSnapshotContent`の両方が残ります。
 
 ## Parameters
 
 VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。
-`snapshotter`に応じて様々なパラメータを使用できます。
+`driver`に応じて様々なパラメータを使用できます。
 
 

content/ja/docs/concepts/workloads/controllers/cron-jobs.md

@@ -6,14 +6,21 @@ weight: 80
 
 <!-- overview -->
 
+{{< feature-state for_k8s_version="v1.8" state="beta" >}}
+
 _CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。
 
 _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。
 [Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。
 
-{{< note >}}
+{{< caution >}}
-すべての**CronJob**`スケジュール`: 時刻はジョブが開始されたマスタータイムゾーンに基づいています。
+すべての**CronJob**`スケジュール`: 時刻はジョブが開始された{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}のタイムゾーンに基づいています。
-{{< /note >}}
+
+コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、CronJobコントローラーのタイムゾーンとして、kube-controller-managerコンテナに設定されたタイムゾーンを使用します。
+{{< /caution >}}
+
+CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。
+名前は52文字を超えることはできません。これはCronJobコントローラーが自動的に、与えられたジョブ名に11文字を追加し、ジョブ名の長さは最大で63文字以内という制約があるためです。
 
 cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。
 
@@ -27,7 +34,7 @@ cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1
 
 `startingDeadlineSeconds`が大きな値、もしくは設定されていない(デフォルト)、そして、`concurrencyPolicy`を`Allow`に設定している場合には、少なくとも一度、ジョブが実行されることを保証します。
 
-最後にスケジュールされた時刻から現在までの間に、CronJobコントローラーはどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。
+最後にスケジュールされた時刻から現在までの間に、CronJob{{< glossary_tooltip term_id="controller" text="コントローラー">}}はどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。
 
 ````
 Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.

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

@@ -12,8 +12,8 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー
 DaemonSetのいくつかの典型的な使用例は以下の通りです。
 
 - `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。
-- `fluentd`や`logstash`のようなログ集計デーモンを各Node上で稼働させる。
+- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。
-- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`やInstana agentなどのようなNodeのモニタリングデーモンを各Node上で稼働させる。
+- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)や[Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)などのようなNodeのモニタリングデーモンを各Node上で稼働させる。
 
 シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
 さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
@@ -32,7 +32,8 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
 
 {{< codenew file="controllers/daemonset.yaml" >}}
 
-* YAMLファイルに基づいてDaemonSetを作成します。  
+YAMLファイルに基づいてDaemonSetを作成します。
+
 ```
 kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ```
@@ -42,6 +43,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。  
 設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。
 
+DaemonSetオブジェクトの名前は、有効な
+[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
 また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)セクションも必須となります。
 
 ### Podテンプレート
@@ -52,7 +56,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。
 
-DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
+DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
 
 ### Podセレクター
 
@@ -80,7 +84,7 @@ selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPod
 
 ## Daemon Podがどのようにスケジューリングされるか
 
-### デフォルトスケジューラーによってスケジューリングされる場合(Kubernetes1.12からデフォルトで有効)
+### デフォルトスケジューラーによってスケジューリングされる場合
 
 {{< feature-state state="stable" for-kubernetes-version="1.17" >}}
 

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

@@ -46,35 +46,39 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 * `nginx-deployment`という名前のDeploymentが作成され、`.metadata.name`フィールドで名前を指定します。
 * Deploymentは3つのレプリカPodを作成し、`replicas`フィールドによってレプリカ数を指定します。
 * `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。このケースにおいて、ユーザーはPodテンプレートにて定義されたラベル(`app: nginx`)を選択します。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
+
   {{< note >}}
   `matchLabels`フィールドは、キーとバリューのペアのマップとなります。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しいです。
   `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
   {{< /note >}}
+
 * `template`フィールドは、下記のサブフィールドを持ちます。:
   * Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられる
   * PodTemplateの仕様もしくは、`.template.spec`フィールドは、このPodは`nginx`という名前のコンテナーを1つ稼働させ、それは`nginx`というさせ、[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.14.2を使うことを示します
   * 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます
 
-  上記のDeploymentを作成するために、以下に示すステップにしたがってください。
 作成を始める前に、ユーザーのKubernetesクラスターが稼働していることを確認してください。
+上記のDeploymentを作成するために、以下に示すステップにしたがってください。
 
 1. 下記のコマンドを実行してDeploymentを作成してください。
 
-      {{< note >}}
-      実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
-      {{< /note >}}
-
   ```shell
   kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
   ```
 
-  2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。
+  {{< note >}}
+  実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
+  {{< /note >}}
+
+
+2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。
+
+  Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。
   ```shell
   NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   nginx-deployment   3         0         0            0           1s
   ```
   ユーザーのクラスターにおいてDeploymentを調査するとき、下記のフィールドが出力されます。
-
   * `NAME` クラスター内のDeploymentの名前を表示する
   * `DESIRED` アプリケーションの理想的な_replicas_ の値を表示する: これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
   * `CURRENT` 現在稼働中のレプリカ数
@@ -84,7 +88,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 
   上記のyamlの例だと、`.spec.replicas`フィールドの値によると、理想的なレプリカ数は3です。
 
-  3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。コマンドの実行結果は下記のとおりです。
+3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。
+
+  コマンドの実行結果は下記のとおりです。
   ```shell
   Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
   deployment.apps/nginx-deployment successfully rolled out
@@ -98,13 +104,21 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。
 
 5. Deploymentによって作成されたReplicaSet (`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は下記のとおりです。
-
   ```shell
   NAME                          DESIRED   CURRENT   READY   AGE
   nginx-deployment-75675f5897   3         3         3       18s
   ```
+  ReplicaSetの出力には次のフィールドが表示されます:
+
+  * `NAME`は名前空間内のReplicaSetの名前を一覧表示します。
+  * `DESIRED`は、アプリケーションの_replicas_の希望数を表示します。これは、Deploymentを作成するときに定義します。これが_desired state_です。
+  * `CURRENT`は現在実行されているレプリカの数を表示します。
+  * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数を表示します。
+  * `AGE`は、アプリケーションが実行されている時間を表示します。
+
   ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。
 
+
 6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は下記のとおりです。
   ```shell
   NAME                                READY     STATUS    RESTARTS   AGE       LABELS
@@ -120,9 +134,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 
 ### pod-template-hashラベル
 
-{{< note >}}
+{{< caution >}}
 このラベルを変更しないでください。
-{{< /note >}}
+{{< /caution >}}
 
 `pod-template-hash`ラベルはDeploymentコントローラーによってDeploymentが作成し適用した各ReplicaSetに対して追加されます。
 
@@ -919,7 +933,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/
 
 Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
 
-[`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。
+[`.spec.template.spec.restartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。
 
 ### レプリカ数
 
@@ -927,7 +941,7 @@ Podの必須フィールドに加えて、Deployment内のPodテンプレート
 
 ### セレクター {#selector}
 
-`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)を指定します。
+`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)を指定します。
 
 `.spec.selector`は`.spec.template.metadata.labels`と一致している必要があり、一致しない場合はAPIによって拒否されます。
 
@@ -973,7 +987,7 @@ Deploymentのテンプレートが`.spec.template`と異なる場合や、`.spec
 
 ### minReadySeconds {#min-ready-seconds}
 
-`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
+`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
 
 ### rollbackTo
 

content/ja/docs/concepts/workloads/controllers/garbage-collection.md

@@ -12,7 +12,7 @@ Kubernetesのガベージコレクターの役割は、かつてオーナーが
 
 <!-- body -->
 
-## オーナーとその従属オブジェクト
+## オーナーとその従属オブジェクト {#owners-and-dependents}
 
 いくつかのKubernetesオブジェクトは他のオブジェクトのオーナーとなります。例えば、ReplicaSetはPodのセットに対するオーナーです。オーナーによって所有されたオブジェクトは、オーナーオブジェクトの*従属オブジェクト(Dependents)* と呼ばれます。全ての従属オブジェクトは、オーナーオブジェクトを指し示す`metadata.ownerReferences`というフィールドを持ちます。
 
@@ -33,7 +33,7 @@ kubectl get pods --output=yaml
 
 その出力結果によると、そのPodのオーナーは`my-repset`という名前のReplicaSetです。
 
-```shell
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -70,7 +70,7 @@ metadata:
 
 一度"削除処理中"状態に遷移すると、そのガベージコレクターはオブジェクトの従属オブジェクトを削除します。一度そのガベージコレクターが全ての”ブロッキングしている”従属オブジェクトを削除すると(`ownerReference.blockOwnerDeletion=true`という値を持つオブジェクト)、それはオーナーのオブジェクトも削除します。
 
-注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。
+注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion=true`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。
 Kubernetes1.7では、認証されていない従属オブジェクトがオーナーオブジェクトの削除を遅らせることができないようにするために[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)が追加され、それは、オーナーオブジェクトの削除パーミッションに基づいて`blockOwnerDeletion`の値がtrueに設定してユーザーアクセスをコントロールします。
 
 もしオブジェクトの`ownerReferences`フィールドがコントローラー(DeploymentやReplicaSetなど)によってセットされている場合、`blockOwnerDeletion`は自動的にセットされ、ユーザーはこのフィールドを手動で修正する必要はありません。

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

@@ -18,9 +18,9 @@ ReplicaSetの目的は、どのような時でも安定したレプリカPodの
 
 ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示すためのセレクターや、稼働させたいPodのレプリカ数、Podテンプレート(理想のレプリカ数の条件を満たすために作成される新しいPodのデータを指定するために用意されるもの)といったフィールドとともに定義されます。ReplicaSetは、指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成します。ReplicaSetが新しいPodを作成するとき、ReplicaSetはそのPodテンプレートを使用します。
 
-ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。
+ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/ja/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。
 
-ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値がコントローラーでないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。
+ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値が {{< glossary_tooltip text="コントローラー" term_id="controller" >}}でないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。
 
 ## ReplicaSetを使うとき
 
@@ -59,51 +59,48 @@ kubectl describe rs/frontend
 ```shell
 Name:		frontend
 Namespace:	default
-Selector:	tier=frontend,tier in (frontend)
+Selector:	tier=frontend
 Labels:		app=guestbook
 		tier=frontend
-Annotations:	<none>
+Annotations:	kubectl.kubernetes.io/last-applied-configuration:
+                {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",...
 Replicas:	3 current / 3 desired
 Pods Status:	3 Running / 0 Waiting / 0 Succeeded / 0 Failed
 Pod Template:
-  Labels:       app=guestbook
+  Labels:  tier=frontend
-                tier=frontend
   Containers:
    php-redis:
     Image:        gcr.io/google_samples/gb-frontend:v3
-    Port:       80/TCP
+    Port:         <none>
-    Requests:
+    Host Port:    <none>
-      cpu:      100m
+    Environment:  <none>
-      memory:   100Mi
-    Environment:
-      GET_HOSTS_FROM:   dns
     Mounts:       <none>
   Volumes:        <none>
 Events:
-  FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
+  Type    Reason            Age   From                   Message
-  ---------    --------    -----    ----                -------------    --------    ------            -------
+  ----    ------            ----  ----                   -------
-  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-qhloh
+  Normal  SuccessfulCreate  117s  replicaset-controller  Created pod: frontend-wtsmm
-  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-dnjpy
+  Normal  SuccessfulCreate  116s  replicaset-controller  Created pod: frontend-b2zdv
-  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-9si5l
+  Normal  SuccessfulCreate  116s  replicaset-controller  Created pod: frontend-vcmts
 ```
 
 そして最後に、ユーザーはReplicaSetによって作成されたPodもチェックできます。
 ```shell
-kubectl get Pods
+kubectl get pods
 ```
 
 表示されるPodに関する情報は以下のようになります。
 ```shell
 NAME             READY   STATUS    RESTARTS   AGE
-frontend-9si5l   1/1       Running   0          1m
+frontend-b2zdv   1/1     Running   0          6m36s
-frontend-dnjpy   1/1       Running   0          1m
+frontend-vcmts   1/1     Running   0          6m36s
-frontend-qhloh   1/1       Running   0          1m
+frontend-wtsmm   1/1     Running   0          6m36s
 ```
 
 ユーザーはまた、それらのPodの`ownerReferences`が`frontend`ReplicaSetに設定されていることも確認できます。
 これを確認するためには、稼働しているPodの中のどれかのyamlファイルを取得します。
 ```shell
-kubectl get pods frontend-9si5l -o yaml
+kubectl get pods frontend-b2zdv -o yaml
 ```
 
 その表示結果は、以下のようになります。その`frontend`ReplicaSetの情報が`metadata`の`ownerReferences`フィールドにセットされています。
@@ -111,19 +108,19 @@ kubectl get pods frontend-9si5l -o yaml
 apiVersion: v1
 kind: Pod
 metadata:
-  creationTimestamp: 2019-01-31T17:20:41Z
+  creationTimestamp: "2020-02-12T07:06:16Z"
   generateName: frontend-
   labels:
     tier: frontend
-  name: frontend-9si5l
+  name: frontend-b2zdv
   namespace: default
   ownerReferences:
-  - apiVersion: extensions/v1beta1
+  - apiVersion: apps/v1
     blockOwnerDeletion: true
     controller: true
     kind: ReplicaSet
     name: frontend
-    uid: 892a2330-257c-11e9-aecd-025000000001
+    uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
 ...
 ```
 
@@ -148,16 +145,17 @@ kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
 
 下記のコマンドでPodを取得できます。
 ```shell
-kubectl get Pods
+kubectl get pods
 ```
 
 その表示結果で、新しいPodがすでに削除済みか、削除中のステータスになっているのを確認できます。
 ```shell
 NAME             READY   STATUS        RESTARTS   AGE
-frontend-9si5l   1/1     Running       0          1m
+frontend-b2zdv   1/1     Running       0          10m
-frontend-dnjpy   1/1     Running       0          1m
+frontend-vcmts   1/1     Running       0          10m
-frontend-qhloh   1/1     Running       0          1m
+frontend-wtsmm   1/1     Running       0          10m
-pod2             0/1     Terminating   0          4s
+pod1             0/1     Terminating   0          1s
+pod2             0/1     Terminating   0          1s
 ```
 
 もしユーザーがそのPodを最初に作成する場合
@@ -173,15 +171,15 @@ kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
 ユーザーはそのReplicaSetが作成したPodを所有し、さらにもともと存在していたPodと今回新たに作成されたPodの数が、理想のレプリカ数になるまでPodを作成するのを確認できます。
 ここでまたPodの状態を取得します。
 ```shell
-kubectl get Pods
+kubectl get pods
 ```
 
 取得結果は下記のようになります。
 ```shell
 NAME             READY   STATUS    RESTARTS   AGE
-frontend-pxj4r   1/1     Running   0          5s
+frontend-hmmj2   1/1     Running   0          9s
-pod1             1/1     Running   0          13s
+pod1             1/1     Running   0          36s
-pod2             1/1     Running   0          13s
+pod2             1/1     Running   0          36s
 ```
 
 この方法で、ReplicaSetはテンプレートで指定されたもの以外のPodを所有することができます。
@@ -192,6 +190,9 @@ pod2             1/1     Running   0          13s
 ReplicaSetでは、`kind`フィールドの値は`ReplicaSet`です。
 Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが現在のバージョンで、デフォルトで有効です。`apps/v1beta2`というAPIバージョンは廃止されています。先ほど作成した`frontend.yaml`ファイルの最初の行を参考にしてください。
 
+ReplicaSetオブジェクトの名前は、有効な
+[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
 また、ReplicaSetは[`.spec` セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必須です。
 
 ### Pod テンプレート
@@ -203,7 +204,7 @@ Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが
 
 ### Pod セレクター
 
-`.spec.selector`フィールドは[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)です。
+`.spec.selector`フィールドは[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)です。
 [先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。
 先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました
 ```shell
@@ -228,13 +229,13 @@ matchLabels:
 ### ReplicaSetとPodの削除
 
 ReplicaSetとそれが所有する全てのPod削除したいときは、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドを使ってください。  
-[ガーベージコレクター](/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。
+[ガベージコレクター](/ja/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。
 
 REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。
 例えば下記のように実行します。
 ```shell
 kubectl proxy --port=8080
-curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
 > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
 > -H "Content-Type: application/json"
 ```
@@ -245,7 +246,7 @@ curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
 REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Orphan`と指定しなくてはなりません。
 ```shell
 kubectl proxy --port=8080
-curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
 > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
 > -H "Content-Type: application/json"
 ```
@@ -309,7 +310,7 @@ PodをPodそれ自身で停止させたいような場合(例えば、バッチ
 ### ReplicationController
 
 ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/)の後継となるものです。
-この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。  
+この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。  
 このように、ReplicaSetはReplicationControllerよりも好まれます。
 
 

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

@@ -9,10 +9,6 @@ weight: 40
 
 StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。
 
-{{< note >}}
-StatefulSetはKubernetes1.9において利用可能(GA)です。
-{{< /note >}}
-
 {{< glossary_definition term_id="statefulset" length="all" >}}
 
 
@@ -28,12 +24,11 @@ StatefulSetは下記の1つ以上の項目を要求するアプリケーショ
 * 規則的で自動化されたローリングアップデート
 
 上記において安定とは、Podのスケジュール(または再スケジュール)をまたいでも永続的であることと同義です。
-もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するコントローラーを使ってアプリケーションをデプロイするべきです。
+もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するワークロードを使ってアプリケーションをデプロイするべきです。
 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)や[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)のようなコントローラーはこのようなステートレスな要求に対して最適です。
 
 ## 制限事項
 
-* StatefuleSetはKubernetes1.9より以前のバージョンではβ版のリソースであり、1.5より前のバージョンでは利用できません。
 * 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。
 * StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除*されません* 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。
 * StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を要求します。ユーザーはこのServiceを作成する責任があります。
@@ -101,6 +96,8 @@ spec:
 * webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。
 * volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。
 
+StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
 ## Podセレクター
 ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。
 
@@ -131,7 +128,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name)  | StatefulSet Domain
  kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |
 
 {{< note >}}
-クラスタードメインは[その他の設定](/docs/concepts/services-networking/dns-pod-service/)がされない限り、`cluster.local`にセットされます。
+クラスタードメインは[その他の設定](/ja/docs/concepts/services-networking/dns-pod-service/)がされない限り、`cluster.local`にセットされます。
 {{< /note >}}
 
 ### 安定したストレージ
@@ -142,7 +139,7 @@ Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/doc
 
 ### Podのネームラベル
 
-StatefulSetのコントローラーがPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。
+StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controller" >}} がPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。
 
 ## デプロイとスケーリングの保証
 
@@ -151,7 +148,7 @@ StatefulSetのコントローラーがPodを作成したとき、Podの名前と
 * Podに対してスケーリングオプションが適用される前に、そのPodの前の順番の全てのPodがRunningかつReady状態になっていなくてはなりません。
 * Podが停止される前に、そのPodの番号より大きい番号を持つの全てのPodは完全にシャットダウンされていなくてはなりません。
 
-StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
+StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
 
 上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
 
@@ -176,9 +173,9 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
 
 `OnDelete`というアップデートストラテジーは、レガシーな(Kubernetes1.6以前)振る舞いとなります。StatefulSetの`.spec.updateStrategy.type`が`OnDelete`にセットされていたとき、そのStatefulSetコントローラーはStatefulSet内でPodを自動的に更新しません。StatefulSetの`.spec.template`項目の修正を反映した新しいPodの作成をコントローラーに支持するためには、ユーザーは手動でPodを削除しなければなりません。
 
-### RollinUpdate
+### RollingUpdate
 
-`RollinUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。
+`RollingUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。
 
 #### パーティション
 
@@ -201,6 +198,5 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
 
 * [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
 * [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
-
+* [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
-
 

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

@@ -9,10 +9,10 @@ weight: 65
 
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}
 
-TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTLメカニズムを提供します。  
+TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。  
 TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。
 
-α版の免責事項: この機能は現在α版の機能で、[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
+α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
 
 
 
@@ -52,6 +52,6 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode
 
 [Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
 
-[設計ドキュメント](https://github.com/kubernetes/community/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
+[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
 
 

content/ja/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -13,7 +13,7 @@ weight: 30
 
 <!-- body -->
 
-## PodのPhase
+## PodのPhase {#pod-phase}
 
 Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。
 
@@ -33,7 +33,7 @@ Podの各フェーズの値と意味は厳重に守られています。
 `Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
 `Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。
 
-## Podのconditions
+## Podのconditions {#pod-conditions}
 
 PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。
 PodCondition配列の各要素には、次の6つのフィールドがあります。
@@ -53,11 +53,10 @@ PodCondition配列の各要素には、次の6つのフィールドがありま
   * `PodScheduled`: PodがNodeにスケジュールされました。
   * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
   * `Initialized`: すべての[init containers](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
-  * `Unschedulable`: リソースの枯渇やその他の理由で、Podがスケジュールできない状態です。
   * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
 
 
-## コンテナのProbe
+## コンテナのProbe {#container-probes}
 
 [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。
 診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。
@@ -80,7 +79,7 @@ Handlerには次の3つの種類があります:
 * Failure: コンテナの診断が失敗しました。
 * Unknown: コンテナの診断が失敗し、取れるアクションがありません。
 
-Kubeletは2種類のProbeを実行中のコンテナで行い、また反応することができます:
+Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます:
 
 * `livenessProbe`: コンテナが動いているかを示します。
    livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
@@ -91,7 +90,14 @@ Kubeletは2種類のProbeを実行中のコンテナで行い、また反応す
    initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。
    コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。
 
-### livenessProbeとreadinessProbeをいつ使うべきか?
+* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。
+   startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。
+   startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
+   コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。
+
+### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe}
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
 
 コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば
 livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。
@@ -99,6 +105,10 @@ livenessProbeは不要です。この場合kubeletが自動でPodの`restartPoli
 Probeに失敗したときにコンテナを殺したり再起動させたりするには、
 livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。
 
+### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe}
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
 Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
 この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、
 readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。
@@ -108,19 +118,28 @@ readinessProbeが存在するということは、Podがトラフィックを受
 livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。
 
 Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。
-Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunhealthyにします。
+Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。
-Pod内のコンテナが停止するのを待つ間Podはunhealthyのままです。
+Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。
 
-livenessProbeまたはreadinessProbeを設定する方法の詳細については、
+### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
-[Configure Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)を参照してください
 
-## Podとコンテナのステータス
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。
+`periodSeconds`のデフォルトは30秒です。
+
+`failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。
+
+livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、
+[Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。
+
+## Podとコンテナのステータス {#pod-and-container-status}
 
 PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と
 [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。
 Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。
 
-## コンテナのステータス
+## コンテナのステータス {#container-states}
 
 PodがスケジューラによってNodeに割り当てられると、
 kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。
@@ -137,7 +156,7 @@ Pod内のコンテナごとにStateの項目として表示されます。
    ...
    ```
 
-* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunningに入ると`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。
+* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。
 
    ```yaml
    ...
@@ -146,7 +165,7 @@ Pod内のコンテナごとにStateの項目として表示されます。
    ...
    ```
 
-* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあればあれば実行されます。
+* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。
 
    ```yaml
    ...
@@ -158,7 +177,7 @@ Pod内のコンテナごとにStateの項目として表示されます。
     ...
    ```
 
-## PodReadinessGate
+## PodReadinessGate {#pod-readiness-gate}
 
 {{< feature-state for_k8s_version="v1.14" state="stable" >}}
 
@@ -190,7 +209,7 @@ status:
 ...
 ```
 
-新しいPod Conditionは、Kubernetesの[label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
+新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
 `kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、
 新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。
 
@@ -201,18 +220,14 @@ status:
 
 PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。
 
-K8s 1.1ではAlpha機能のため"Pod Ready++" 機能は`PodReadinessGates` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)にて明示的に指定する必要があります。
+## RestartPolicy {#restart-policy}
-
-K8s 1.12ではこの機能はデフォルトで有効になっています。
-
-## RestartPolicy
 
 PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。
 デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。
 `restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。
 kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延（10秒、20秒、40秒...）で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。
 
-## Podのライフタイム
+## Podのライフタイム {#pod-lifetime}
 
 一般にPodは人間またはコントローラーが明示的に削除するまで存在します。
 コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。
@@ -325,7 +340,7 @@ spec:
 
 * [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる
 
-* [configuring liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のハンズオンをやってみる
+* [Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のハンズオンをやってみる
 
 * [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ
 

content/ja/docs/concepts/workloads/pods/pod-overview.md

@@ -13,7 +13,7 @@ card:
 
 
 <!-- body -->
-## Podについて理解する
+## Podについて理解する {#understanding-pods}
 
 *Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。
 
@@ -28,7 +28,7 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで
 * **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。  これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
 -- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。
 
-[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。  
+[Kubernetes Blog](https://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。
 
   * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
   * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
@@ -114,6 +114,6 @@ spec:
 
 * [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
 * Podの振る舞いに関して学ぶには下記を参照してください
-   * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#podの終了)
+   * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)
    * [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
 

content/ja/docs/concepts/workloads/pods/pod.md

@@ -34,7 +34,7 @@ Pod内のアプリケーションからアクセスできる共有ボリュー
 [Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
 
 個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。
-[Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
+[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
 Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
 特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。
 代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。
@@ -126,7 +126,7 @@ Podは、以下のことを容易にするためにプリミティブとして
 * アプリケーションの可用性を高める。
 即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する
 
-## Podの終了
+## Podの終了 {#termination-of-pods}
 
 Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。
 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
@@ -141,7 +141,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
 1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
 1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
     1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
-    猶予期間が終了した後も `preStop` フックがまだ実行されている場合は、次に、短い延長された猶予期間（2秒）でステップ2が呼び出される
+    猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
     1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
 1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
 ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
@@ -157,14 +157,14 @@ kubectlのバージョン1.5以降では、強制削除を実行するために
 ### Podの強制削除
 
 Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。
-強制削除が実行されると、apiserverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。
+強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。
 API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。
 Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。
 
 強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。
-StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
+StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
 
-## Podコンテナの特権モード
+## Podコンテナの特権モード {#privileged-mode-for-pod-containers}
 
 Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。
 これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。

content/ja/docs/concepts/workloads/pods/podpreset.md

@@ -14,7 +14,7 @@ weight: 50
 ## PodPresetを理解する
 
 `PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
-ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
+ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
 
 PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。  
 この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
@@ -48,7 +48,13 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ
 ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
 
 1.  `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
-1.  `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`を追加することで可能になります。
+1.  `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に
+
+  ```shell
+  --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+  ```
+
+  を追加することで可能になります。
 1.  ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。
 
 

content/ja/docs/home/_index.md

@@ -15,6 +15,8 @@ menu:
     weight: 20
     post: >
       <p>チュートリアル、サンプルやドキュメントのリファレンスを使って Kubernetes の利用方法を学んでください。あなたは<a href="/editdocs/" data-auto-burger-exclude>ドキュメントへコントリビュートをする</a>こともできます!</p>
+description: >
+  Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています。
 overview: >
   Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています（<a href="https://www.cncf.io/about">CNCF</a>）。
 cards:
@@ -38,6 +40,11 @@ cards:
   description: "一般的なタスク、そのタスクを短い手順でどのように実行するかを見てみます。"
   button: "タスクを見る"
   button_path: "/docs/tasks"
+- name: training
+  title: "トレーニング"
+  description: "Kubernetesの資格を取得して、クラウドネイティブプロジェクトを成功させます！"
+  button: "トレーニングを見る"
+  button_path: "/training"
 - name: reference
   title: "リファレンス情報を調べる"
   description: "用語、コマンドラインの構文、APIリソースタイプ、そして構築ツールのドキュメントを見て回ります。"

content/ja/docs/reference/_index.md

@@ -17,12 +17,7 @@ content_type: concept
 ## APIリファレンス
 
 * [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。
-* Kubernetes APIバージョン
+* [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
-  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
-  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
-  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
-  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
-  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
 
 ## APIクライアントライブラリー
 
@@ -35,18 +30,17 @@ content_type: concept
 
 ## CLIリファレンス
 
-* [kubectl](/docs/user-guide/kubectl-overview) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
+* [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
-    * [JSONPath](/docs/user-guide/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
-* [kubeadm](/docs/admin/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
+* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
-* [kubefed](/docs/admin/kubefed/) - 連合型クラスターを管理するのに役立つCLIツールです。
 
 ## 設定リファレンス
 
-* [kubelet](/docs/admin/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。
-* [kube-apiserver](/docs/admin/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。
-* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
-* [kube-proxy](/docs/admin/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
-* [kube-scheduler](/docs/admin/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
 
 ## 設計のドキュメント
 

content/ja/docs/reference/command-line-tools-reference/feature-gates.md

@@ -322,7 +322,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `CSIPersistentVolume`: [CSI(Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)互換のボリュームプラグインを通してプロビジョニングされたボリュームの検出とマウントを有効にします。
   詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。
 - `CustomCPUCFSQuotaPeriod`: ノードがCPUCFSQuotaPeriodを変更できるようにします。
-- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
+- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。
 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。
 - `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
@@ -333,7 +333,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。
 - `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。
 - `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。
-- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/docs/concepts/storage/dynamic-provisioning/)を有効にします。
+- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/ja/docs/concepts/storage/dynamic-provisioning/)を有効にします。
 - `EnableAggregatedDiscoveryTimeout` (*非推奨*): 集約されたディスカバリーコールで5秒のタイムアウトを有効にします。
 - `EnableEquivalenceClassCache`: Podをスケジュールするときにスケジューラーがノードの同等をキャッシュできるようにします。
 - `EphemeralContainers`: 稼働するPodに{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}を追加する機能を有効にします。
@@ -361,7 +361,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。
 - `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。
 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
-- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
+- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
 - `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
@@ -377,7 +377,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
-- `StartupProbe`: kubeletで[startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
+- `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
 - `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。

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

@@ -5,14 +5,15 @@ date: 2019-06-15
 full_link: 
 short_description: >
 
-   Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。
+   コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。
 
 aka: 
 tags:
 - fundamental
 - operation
 ---
-Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。
+コンテナ化されたアプリケーションを実行する、{{< glossary_tooltip text="ノード" term_id="node" >}}と呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。
 
 <!--more-->
 ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。
+ワーカーノードは、アプリケーションワークロードのコンポーネントである{{< glossary_tooltip text="Pod" term_id="pod" >}}をホストします。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、クラスター内のワーカーノードとPodを管理します。本番環境では、コントロールプレーンは複数のコンピューターを使用し、クラスターは複数のノードを使用し、耐障害性や高可用性を提供します。

content/ja/docs/reference/glossary/container-runtime.md

@@ -2,7 +2,7 @@
 title: コンテナランタイム
 id: container-runtime
 date: 2019-06-05
-full_link: /docs/reference/generated/container-runtime
+full_link: /ja/docs/setup/production-environment/container-runtimes
 short_description: >
  コンテナランタイムは、コンテナの実行を担当するソフトウェアです。
 
@@ -16,7 +16,7 @@ tags:
 <!--more-->
 
 Kubernetesは次の複数のコンテナランタイムをサポートします。
-[Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/),
+{{< glossary_tooltip term_id="docker">}}、{{< glossary_tooltip term_id="containerd" >}}、{{< glossary_tooltip term_id="cri-o" >}}、
-[rktlet](https://github.com/kubernetes-incubator/rktlet) および全ての
+および全ての
 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)
-実装。
+実装です。

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

@@ -2,7 +2,7 @@
 title: Controller
 id: controller
 date: 2018-04-12
-full_link: /docs/admin/kube-controller-manager/
+full_link: /docs/concepts/architecture/controller/
 short_description: >
   クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。
 
@@ -11,8 +11,11 @@ tags:
 - architecture
 - fundamental
 ---
- クラスターの状態を{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得して監視する制御ループで、現在の状態を望ましい状態に移行するように更新します。
+Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="cluster" text="クラスター" >}}の状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。それぞれのコントローラーは現在のクラスターの状態を望ましい状態に近づけるように動作します。
 
 <!--more--> 
 
-現在Kubernetesに同梱されているコントローラーの例には、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、およびサービスアカウントコントローラーがあります。
+コントローラーはクラスターの状態を{{< glossary_tooltip term_id="control-plane" text="コントロールプレーン" >}}の一部である{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}から取得します。
+
+コントロールプレーン内部で動くいくつかのコントローラーは、Kubernetesの主要な操作に対する制御ループを提供します。
+例えば、Deploymentコントローラー、Daemonsetコントローラー、Namespaceコントローラー、Persistent Volumeコントローラー等は{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}の内部で動作します。

content/ja/docs/reference/glossary/kube-apiserver.md

@@ -1,18 +1,22 @@
 ---
-title: kube-apiserver
+title: APIサーバー
 id: kube-apiserver
 date: 2018-04-12
 full_link: /docs/reference/generated/kube-apiserver/
 short_description: >
-  Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。
+  Kubernetes APIを提供するコントロールプレーンのコンポーネントです。
 
 aka:
+- kube-apiserver
 tags:
 - architecture
 - fundamental
 ---
- Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。
+ APIサーバーは、Kubernetes APIを外部に提供するKubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}のコンポーネントです。
+ APIサーバーはKubernetesコントロールプレーンのフロントエンドになります。
 
 <!--more-->
 
-このコンポーネントは、水平スケールするように設計されています。つまり追加でインスタンスを足すことでスケール可能です。さらなる情報は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。
+Kubernetes APIサーバーの主な実装は[kube-apiserver](/docs/reference/generated/kube-apiserver/)です。
+kube-apiserverは水平方向にスケールするように設計されています&mdash;つまり、インスタンスを追加することでスケールが可能です。
+複数のkube-apiserverインスタンスを実行することで、インスタンス間でトラフィックを分散させることが可能です。

content/ja/docs/reference/glossary/kube-controller-manager.md

@@ -2,17 +2,17 @@
 title: kube-controller-manager
 id: kube-controller-manager
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-controller-manager/
+full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
 short_description: >
-  マスター上に存在し、コントローラーを実行するコンポーネントです。
+  コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。
 
 aka: 
 tags:
 - architecture
 - fundamental
 ---
- マスター上に存在し、{{< glossary_tooltip text="controllers" term_id="controller" >}}を実行するコンポーネントです。
+ コントロールプレーン上で動作するコンポーネントで、複数の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}プロセスを実行します。
 
 <!--more--> 
 
-論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は個別のプロセスですが、複雑になるのを避けるために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
+論理的には、各{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は個別のプロセスですが、複雑さを減らすために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。

content/ja/docs/reference/glossary/kube-proxy.md

@@ -11,10 +11,10 @@ tags:
 - fundamental
 - networking
 ---
- [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) はクラスター内の各Nodeで動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。
+  kube-proxyはクラスター内の各{{< glossary_tooltip text="node" term_id="node" >}}で動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。
 
 <!--more-->
 
-kube-proxyは、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。
+[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)は、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。
 
 kube-proxyは、オペレーティングシステムにパケットフィルタリング層があり、かつ使用可能な場合、パケットフィルタリング層を使用します。それ以外の場合は自身でトラフィックを転送します。

content/ja/docs/reference/glossary/kube-scheduler.md

@@ -4,14 +4,14 @@ id: kube-scheduler
 date: 2018-04-12
 full_link: /docs/reference/generated/kube-scheduler/
 short_description: >
-  マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
+  コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
 
 aka: 
 tags:
 - architecture
 ---
-  マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
+  コントロールプレーン上で動作するコンポーネントで、新しく作られた{{< glossary_tooltip term_id="pod" text="Pod" >}}に{{< glossary_tooltip term_id="node" text="ノード" >}}が割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
 
 <!--more--> 
 
-スケジューリング決定で考慮される要素には、個々および集団のリソース要件、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉と有効期限が含まれます。
+スケジューリングの決定は、PodあるいはPod群のリソース要求量、ハードウェア/ソフトウェア/ポリシーによる制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉、有効期限などを考慮して行われます。

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

@@ -11,8 +11,7 @@ tags:
 - fundamental
 - core-object
 ---
- クラスター内の各ノードで実行されるエージェントです。各コンテナがPodで実行されていることを保証します。
+ クラスター内の各{{< glossary_tooltip text="ノード" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="コンテナ" term_id="container" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}で実行されていることを保証します。
 
 <!--more-->
-
+kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態を保証します。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。
-kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態に保ちます。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。

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

@@ -2,7 +2,7 @@
 title: 名前(Name)
 id: name
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /ja/docs/concepts/overview/working-with-objects/names
 short_description: >
   クライアントから提供され、リソースURL内のオブジェクトを参照する文字列です。例えば`/api/v1/pods/何らかの名前`のようになります。
 

content/ja/docs/reference/glossary/persistent-volume-claim.md

@@ -11,9 +11,8 @@ tags:
 - core-object
 - storage
 ---
- コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。
+ {{< glossary_tooltip text="コンテナ" term_id="container" >}}内でボリュームとしてマウントするために{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。
 
 <!--more--> 
 
-ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeの仕様にあります。
+ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。
-

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

@@ -10,8 +10,8 @@ aka:
 tags:
 - fundamental
 ---
- ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。
+ ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。
 
 <!--more--> 
 
-セレクターは、リソースのリストを照会して{{< glossary_tooltip text="ラベル" term_id="label" >}}でフィルターするときに適用されます。
+セレクターは、リソースのリストを照会してラベルでフィルターするときに適用されます。

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

@@ -15,7 +15,7 @@ tags:
 <!--more--> 
 
 SIGのメンバーは、アーキテクチャ、API machinery、ドキュメンテーションといった、特定のエリアの改善に共通の関心をもっています。
-SIGは[SIGガバナンス](https://github.com/kubernetes/community/blob/master/sig-governance.md)ガイドラインに準拠していなければなりませんが、独自の貢献ポリシーやコミュニケーションのチャンネルを持つことが可能です。
+SIGは[ガバナンスガイドライン](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md)に準拠していなければなりませんが、独自の貢献ポリシーやコミュニケーションのチャンネルを持つことが可能です。
 
 さらなる情報は[コミュニティ (kubernetes/community)](https://github.com/kubernetes/community)リポジトリと[SIGとワーキンググループ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照して下さい。
 

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

@@ -4,15 +4,17 @@ id: volume
 date: 2018-04-12
 full_link: /docs/concepts/storage/volumes/
 short_description: >
-  ポッド内のコンテナからアクセス可能なデータを含むディレクトリ。
+  Pod内のコンテナからアクセス可能なデータを含むディレクトリ。
 
 aka: 
 tags:
 - core-object
 - fundamental
 ---
- {{< glossary_tooltip text="ポッド" term_id="pod" >}}内のコンテナからアクセス可能なデータを含むディレクトリ。
+ {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。
 
 <!--more--> 
 
-Kubernetesボリュームはボリュームを含む{{< glossary_tooltip text="ポッド" term_id="pod" >}}が存在する限り有効です。そのためボリュームは{{< glossary_tooltip text="ポッド" term_id="pod" >}}内で実行されるすべての{{< glossary_tooltip text="コンテナ" term_id="container" >}}よりも長持ちし、{{< glossary_tooltip text="コンテナ" term_id="container" >}}の再起動後もデータは保持されます。
+Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。
+
+詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。

content/ja/docs/reference/kubectl/cheatsheet.md

@@ -38,7 +38,7 @@ complete -F __start_kubectl k
 
 ```bash
 source <(kubectl completion zsh)  # 現在のzshシェルでコマンド補完を設定します
-echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
+echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
 ```
 
 ## Kubectlコンテキストの設定
@@ -84,7 +84,7 @@ kubectl config unset users.foo    # ユーザーfooを削除します
 
 ## Objectの作成
 
-Kubernetesのマニフェストファイルは、jsonまたはyamlで定義できます。ファイル拡張子として、`.yaml`や`.yml`、`.json`が使えます。
+Kubernetesのマニフェストファイルは、JSONまたはYAMLで定義できます。ファイル拡張子として、`.yaml`や`.yml`、`.json`が使えます。
 
 ```bash
 kubectl apply -f ./my-manifest.yaml            # リソースを作成します
@@ -92,7 +92,7 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml      # 複数のファイルからリ
 kubectl apply -f ./dir                         # dirディレクトリ内のすべてのマニフェストファイルからリソースを作成します
 kubectl apply -f https://git.io/vPieo          # urlで公開されているファイルからリソースを作成します
 kubectl create deployment nginx --image=nginx  # 単一のnginx Deploymentを作成します
-kubectl explain pods,svc                       # PodおよびServiceマニフェストのドキュメントを取得します
+kubectl explain pods                           # Podマニフェストのドキュメントを取得します
 
 # 標準入力から複数のYAMLオブジェクトを作成します
 
@@ -147,7 +147,6 @@ kubectl get pods -o wide                      # 現在のネームスペース
 kubectl get deployment my-dep                 # 特定のDeploymentを表示します
 kubectl get pods                              # 現在のネームスペース上にあるすべてのPodのリストを表示します
 kubectl get pod my-pod -o yaml                # PodのYAMLを表示します
-kubectl get pod my-pod -o yaml --export       # クラスター固有の情報を除いたPodのマニフェストをYAMLで表示します
 
 # Describeコマンドで詳細な情報を確認します
 kubectl describe nodes my-node
@@ -159,8 +158,8 @@ kubectl get services --sort-by=.metadata.name
 # Restartカウント順にPodのリストを表示します
 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
 
-# capacity順にソートしたtestネームスペースに存在するPodのリストを表示します
+# capacity順にソートしたPersistentVolumeのリストを表示します
-kubectl get pods -n test --sort-by=.spec.capacity.storage
+kubectl get pv --sort-by=.spec.capacity.storage
 
 # app=cassandraラベルのついたすべてのPodのversionラベルを表示します
 kubectl get pods --selector=app=cassandra -o \
@@ -195,9 +194,16 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
 
 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
 
+# すべてのPodのInitContainerのコンテナIDのリストを表示します
+# initContainerの削除を回避しながら、停止したコンテナを削除するときに役立つでしょう
+kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
+
 # タイムスタンプでソートされたEventのリストを表示します
 
 kubectl get events --sort-by=.metadata.creationTimestamp
+
+# クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。
+kubectl diff -f ./my-manifest.yaml
 ```
 
 ## リソースのアップデート
@@ -210,6 +216,7 @@ kubectl rollout history deployment/frontend                      # frontend Depl
 kubectl rollout undo deployment/frontend                         # 1つ前のDeploymentにロールバックします
 kubectl rollout undo deployment/frontend --to-revision=2         # 特定のバージョンにロールバックします
 kubectl rollout status -w deployment/frontend                    # frontend Deploymentのローリングアップデートを状態をwatchします
+kubectl rollout restart deployment/frontend                      # frontend Deployment を再起動します
 
 
 # これらのコマンドは1.11から廃止されました
@@ -322,7 +329,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
 
 ### リソースタイプ
 
-サポートされているすべてのリソースタイプを、それらが[API group](/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
+サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
 
 ```bash
 kubectl api-resources
@@ -341,7 +348,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
 
 ### 出力のフォーマット
 
-特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o`または`--output`フラグを追加します。
+特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o`(または`--output`)フラグを追加します。
 
 出力フォーマット | 説明
 ---------------- | -----------

content/ja/docs/setup/_index.md

@@ -37,77 +37,18 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ
 |コミュニティ           |エコシステム     |
 | ------------       | --------     |
 | [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
-| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
+| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
 |                     | [Minishift](https://docs.okd.io/latest/minishift/)|
 |                     | [MicroK8s](https://microk8s.io/)|
 |                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
 |                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
 |                     | [k3s](https://k3s.io)|
-|                     | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)|
 
 
 ## 本番環境
 
 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。
 
-Kubernetesクラスタにおける抽象レイヤには {{< glossary_tooltip text="アプリケーション" term_id="applications" >}}、 {{< glossary_tooltip text="データプレーン" term_id="data-plane" >}}、 {{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}、 {{< glossary_tooltip text="クラスターインフラ" term_id="cluster-infrastructure" >}}、 {{< glossary_tooltip text="そして、クラスター運用" term_id="cluster-operations" >}}があります。
+[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。 
-
-次の図は、Kubernetesクラスターの抽象レイヤ一覧と、それぞれの抽象レイヤを自分で管理するのか、プロバイダによって管理されているのかを示しています。
-
-本番環境のソリューション![Production environment solutions](/images/docs/KubernetesSolutions.svg)
-
-{{< table caption="Production environment solutions table lists the providers and the solutions." >}}
-次の表は、各プロバイダーとそれらが提供するソリューションを一覧にしたものです。
-
-|プロバイダー | マネージド | 即時利用可能 | オンプレDC  | カスタム(クラウド) | カスタム(オンプレVM)| カスタム(ベアメタル) |
-| ---------  | ------  | ------         | ------         | ------         | ------                  | -----               |
-| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)|                | &#x2714;       | &#x2714;         |       |                    |
-| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)|     | &#x2714; |          |    |                      |
-| [Amazon](https://aws.amazon.com)   | [Amazon EKS](https://aws.amazon.com/eks/)   |[Amazon EC2](https://aws.amazon.com/ec2/)  |          |        |                       |
-| [AppsCode](https://appscode.com/products/pharmer/)          | &#x2714;      |  |       |         |  |
-| [APPUiO](https://appuio.ch/)  | &#x2714;     | &#x2714;  |   &#x2714; | |  | |
-| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | &#x2714; | | &#x2714; | &#x2714; | &#x2714; |
-| [CenturyLink Cloud](https://www.ctl.io/)     |       | &#x2714; |   |  | |
-| [Cisco Container Platform](https://cisco.com/go/containers)     |       |  | &#x2714;  |  | |
-| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)       |     |  |   | &#x2714; |&#x2714; |
-| [CloudStack](https://cloudstack.apache.org/)           |      |  |   | | &#x2714;|
-| [Canonical](https://ubuntu.com/kubernetes)      |       &#x2714;       | &#x2714;       |      &#x2714;       | &#x2714;     |&#x2714;  | &#x2714;
-| [Containership](https://containership.io)            | &#x2714;       |&#x2714;  |     |     |                   |
-| [D2iQ](https://d2iq.com/) |  | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
-| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html)            |        |  |      |     |  | &#x2714;
-| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/)        | &#x2714;      |  |      |     |            |
-| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) |       |&#x2714;  | &#x2714;     |  |     | &#x2714;
-| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)     |      |  |      | |    &#x2714;       | &#x2714;
-| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)     |      |  |      | |           | &#x2714;
-| [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
-| [Giant Swarm](https://www.giantswarm.io/)     | &#x2714;       | &#x2714; |   &#x2714;    |     |
-| [Google](https://cloud.google.com/)           |  [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/)       | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/)       |  |  |     |  |      |       |  |
-| [IBM](https://www.ibm.com/in-en/cloud)        | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
-| [Ionos](https://www.ionos.com/enterprise-cloud)        | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
-| [Kontena Pharos](https://www.kontena.io/pharos/)          |    |&#x2714;|    &#x2714;    |        |         |
-| [KubeOne](https://kubeone.io/) |  | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |
-| [Kubermatic](https://kubermatic.io/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |  |
-| [KubeSail](https://kubesail.com/)    | &#x2714;       |  |      |     |        |
-| [Kubespray](https://kubespray.io/#/)       |       |    |       |&#x2714;  | &#x2714; | &#x2714; |
-| [Kublr](https://kublr.com/)        |&#x2714; | &#x2714;  |&#x2714;       |&#x2714;  |&#x2714; |&#x2714; |
-| [Microsoft Azure](https://azure.microsoft.com)    |  [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/)     |  |     |        |    |
-| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)    |       |  | &#x2714; |  |    |
-| [Nirmata](https://www.nirmata.com/)          |              |   &#x2714;     | &#x2714;            |      |          |
-| [Nutanix](https://www.nutanix.com/en)         | [Nutanix Karbon](https://www.nutanix.com/products/karbon)             | [Nutanix Karbon](https://www.nutanix.com/products/karbon)       |             |      | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization)         |
-| [OpenNebula](https://www.opennebula.org)          |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html)              |        |            |      |   |
-| [OpenShift](https://www.openshift.com)          |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/)              |        | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/)            |      |  [OpenShift Container Platform](https://www.openshift.com/products/container-platform/)        |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
-| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm)          | &#x2714;             |   &#x2714;     |             |      |          |
-| [oVirt](https://www.ovirt.org/)         |              |        |             |     | &#x2714;          |
-| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service)           |      |          |
-| [Platform9](https://platform9.com/)         | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/)             |       | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/)            |  &#x2714;    |  &#x2714;    |   &#x2714;
-| [Rancher](https://rancher.com/)         |              |   [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/)     |             |  [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/)    |          | [k3s](https://k3s.io/)
-| [StackPoint](https://stackpoint.io/)          | &#x2714;            |  &#x2714;      |             |      |          |
-| [Supergiant](https://supergiant.io/)         |              |&#x2714;        |             |      |          |
-| [SUSE](https://www.suse.com/)        |              | &#x2714;       |             |      |          |
-| [SysEleven](https://www.syseleven.io/)         | &#x2714;             |        |             |      |          |
-| [Tencent Cloud](https://intl.cloud.tencent.com/)  | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) |   &#x2714;   |   &#x2714; |    |      |   &#x2714;  |
-| [VEXXHOST](https://vexxhost.com/)         | &#x2714;             | &#x2714;      |             |      |          |
-| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)              |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)        |   [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)          | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)      |          |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
-| [Z.A.R.V.I.S.](https://zarvis.ai/) | &#x2714; | | | | | |
 
 

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

@@ -184,7 +184,7 @@ kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0
 
 Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
 
-```json
+```bash
 kubectl apply -f - <<EOF
 {
   "apiVersion": "v1",

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

@@ -82,7 +82,7 @@ sudo docker run -it --rm --privileged --net=host \
   k8s.gcr.io/node-test:0.2
 ```
 
-Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md).
+Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md).
 By default, it runs all conformance tests.
 
 Theoretically, you can run any node e2e test if you configure the container and

content/ja/docs/setup/learning-environment/minikube.md

@@ -317,7 +317,7 @@ Minikubeはこのコンテキストを自動的にデフォルトに設定しま
 
 ### ダッシュボード
 
-[Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください:
+[Kubernetes Dashboard](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください:
 
 ```shell
 minikube dashboard

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

@@ -1,70 +1,59 @@
 ---
-title: Options for Highly Available topology
+title: 高可用性トポロジーのためのオプション
 content_type: concept
 weight: 50
 ---
 
 <!-- overview -->
 
-This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.
+このページでは、高可用性(HA)Kubernetesクラスターのトポロジーを設定するための2つのオプションについて説明します。
 
-You can set up an HA cluster:
+HAクラスターは次の方法で設定できます。
 
-- With stacked control plane nodes, where etcd nodes are colocated with control plane nodes
+- 積層コントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。
-- With external etcd nodes, where etcd runs on separate nodes from the control plane
+- 外部のetcdノードを使用する方法。こちらの場合、etcdがコントロールプレーンとは分離されたノードで動作します。
 
-You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.
+HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。
 
 
 
 <!-- body -->
 
-## Stacked etcd topology
+## 積層etcdトポロジー
 
-A stacked HA cluster is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed
+積層HAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
-data storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by
-kubeadm that run control plane components.
 
-Each control plane node runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`.
+各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`を実行します。`kube-apiserver` はロードバランサーを用いてワーカーノードに公開されます。
-The `kube-apiserver` is exposed to worker nodes using a load balancer.
 
-Each control plane node creates a local etcd member and this etcd member communicates only with
+各コントロールプレーンノードはローカルのetcdメンバーを作り、このetcdメンバーはそのノードの`kube-apiserver`とだけ通信します。ローカルの`kube-controller-manager`と`kube-scheduler`のインスタンスも同様です。
-the `kube-apiserver` of this node. The same applies to the local `kube-controller-manager`
-and `kube-scheduler` instances.
 
-This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster
+このトポロジーは、同じノード上のコントロールプレーンとetcdのメンバーを結合します。外部のetcdノードを使用するクラスターよりはセットアップがシンプルで、レプリケーションの管理もシンプルです。
-with external etcd nodes, and simpler to manage for replication.
 
-However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control
+しかし、積層クラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。
-plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.
 
-You should therefore run a minimum of three stacked control plane nodes for an HA cluster.
+そのため、HAクラスターのためには、最低でも3台の積層コントロールプレーンノードを実行しなければなりません。
 
-This is the default topology in kubeadm. A local etcd member is created automatically
+これがkubeadmのデフォルトのトポロジーです。`kubeadm init`や`kubeadm join --control-place`を実行すると、ローカルのetcdメンバーがコントロールプレーンノード上に自動的に作成されます。
-on control plane nodes when using `kubeadm init` and `kubeadm join --control-plane`.
 
-![Stacked etcd topology](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
+![積層etcdトポロジー](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
 
-## External etcd topology
+## 外部のetcdトポロジー
 
-An HA cluster with external etcd is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components.
+外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
 
-Like the stacked etcd topology, each control plane node in an external etcd topology runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`. And the `kube-apiserver` is exposed to worker nodes using a load balancer. However, etcd members run on separate hosts, and each etcd host communicates with the `kube-apiserver` of each control plane node.
+積層etcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。そして、`kube-apiserver`は、ロードバランサーを使用してワーカーノードに公開されます。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。
 
-This topology decouples the control plane and etcd member. It therefore provides an HA setup where
+このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積層HAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。
-losing a control plane instance or an etcd member has less impact and does not affect
-the cluster redundancy as much as the stacked HA topology.
 
-However, this topology requires twice the number of hosts as the stacked HA topology.
+しかし、このトポロジーでは積層HAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。
-A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology.
 
-![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
+![外部のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
 
 
 
 ## {{% heading "whatsnext" %}}
 
 
-- [Set up a highly available cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
+- [kubeadmを使用した高可用性クラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
 
 

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

@@ -53,7 +53,7 @@ export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
 
 ### 例
 
-新しいクラスターを試すには、[簡単なnginxの例](/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
+新しいクラスターを試すには、[簡単なnginxの例](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
 
 "Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
 

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

@@ -93,7 +93,7 @@ Port mapping is also supported, but for simplicity in this example the container
     * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response
     * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec
     * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods
-    * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
+    * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services)
     * Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
     * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
 

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

@@ -16,9 +16,9 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ
 
 Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。
 
-セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing)がこれを決定しています。パッチリリースマネージャーは[各リリースのリリースチーム](https://github.com/kubernetes/sig-release/tree/master/releases/)のメンバーです。
+セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。
 
-マイナーリリースは約3ヶ月ごとに行われるため、それぞれのリリースブランチは約9ヶ月間メンテナンスされます。
+詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。
 
 ## サポートされるバージョンの差異
 

content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -10,7 +10,7 @@ card:
 
 <!-- overview -->
 
-ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、contextの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。
+ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、コンテキストの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。
 
 {{< note >}}
 クラスターへのアクセスを設定するファイルを、*kubeconfig* ファイルと呼ぶことがあります。これは設定ファイルの一般的な呼び方です。`kubeconfig`という名前のファイルが存在するわけではありません。
@@ -27,7 +27,7 @@ card:
 
 <!-- steps -->
 
-## クラスター、ユーザー、contextを設定する
+## クラスター、ユーザー、コンテキストを設定する
 
 例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。
 
@@ -57,7 +57,7 @@ contexts:
   name: exp-scratch
 ```
 
-設定ファイルには、クラスター、ユーザー、contextの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのcontextの情報が含まれています。
+設定ファイルには、クラスター、ユーザー、コンテキストの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのコンテキストの情報が含まれています。
 
 `config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:
 
@@ -74,10 +74,12 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username=
 ```
 
 {{< note >}}
-`kubectl config unset users.<name>`を実行すると、ユーザーを削除することができます。
+`kubectl --kubeconfig=config-demo config unset users.<name>`を実行すると、ユーザーを削除することができます。
+`kubectl --kubeconfig=config-demo config unset clusters.<name>`を実行すると、クラスターを除去することができます。
+`kubectl --kubeconfig=config-demo config unset contexts.<name>`を実行すると、コンテキスト情報を除去することができます。
 {{< /note >}}
 
-context情報を設定ファイルに追加してください:
+コンテキスト情報を設定ファイルに追加してください:
 
 ```shell
 kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
@@ -91,7 +93,7 @@ kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratc
 kubectl config --kubeconfig=config-demo view
 ```
 
-出力には、二つのクラスター、二人のユーザー、三つのcontextが表示されます:
+出力には、二つのクラスター、二人のユーザー、三つのコンテキストが表示されます:
 
 ```shell
 apiVersion: v1
@@ -138,23 +140,23 @@ users:
 
 証明書ファイルのパスの代わりにbase64にエンコードされたデータを使用したい場合は、キーに`-data`の接尾辞を加えてください。例えば、`certificate-authority-data`、`client-certificate-data`、`client-key-data`とできます。
 
-それぞれのcontextは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`contextは、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。
+それぞれのコンテキストは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`は、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。
 
-現在のcontextを設定してください:
+現在のコンテキストを設定してください:
 
 ```shell
 kubectl config --kubeconfig=config-demo use-context dev-frontend
 ```
 
-これ以降実行される`kubectl`コマンドは、`dev-frontend`contextに設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`contextに設定されたユーザーの認証情報を使用します。
+これ以降実行される`kubectl`コマンドは、`dev-frontend`に設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`に設定されたユーザーの認証情報を使用します。
 
-現在のcontextの設定情報のみを確認するには、`--minify`フラグを使用してください。
+現在のコンテキストの設定情報のみを確認するには、`--minify`フラグを使用してください。
 
 ```shell
 kubectl config --kubeconfig=config-demo view --minify
 ```
 
-出力には、`dev-frontend`contextの設定情報が表示されます:
+出力には、`dev-frontend`の設定情報が表示されます:
 
 ```shell
 apiVersion: v1
@@ -181,15 +183,15 @@ users:
 
 今度は、実験用のクラスター内でしばらく作業する場合を考えます。
 
-現在のcontextを`exp-scratch`に切り替えてください:
+現在のコンテキストを`exp-scratch`に切り替えてください:
 
 ```shell
 kubectl config --kubeconfig=config-demo use-context exp-scratch
 ```
 
-これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`contextに設定されたユーザーの認証情報を使用します。
+これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`に設定されたユーザーの認証情報を使用します。
 
-新しく切り替えた`exp-scratch`contextの設定を確認してください。
+新しく切り替えた`exp-scratch`の設定を確認してください。
 
 ```shell
 kubectl config --kubeconfig=config-demo view --minify
@@ -197,13 +199,13 @@ kubectl config --kubeconfig=config-demo view --minify
 
 最後に、`development`クラスター内の`storage`namespaceでしばらく作業する場合を考えます。
 
-現在のcontextを`dev-storage`に切り替えてください:
+現在のコンテキストを`dev-storage`に切り替えてください:
 
 ```shell
 kubectl config --kubeconfig=config-demo use-context dev-storage
 ```
 
-新しく切り替えた`dev-storage`contextの設定を確認してください。
+新しく切り替えた`dev-storage`の設定を確認してください。
 
 ```shell
 kubectl config --kubeconfig=config-demo view --minify
@@ -226,7 +228,7 @@ contexts:
   name: dev-ramp-up
 ```
 
-上記の設定ファイルは、`dev-ramp-up`というcontextを表します。
+上記の設定ファイルは、`dev-ramp-up`というコンテキストを表します。
 
 ## KUBECONFIG環境変数を設定する
 
@@ -260,7 +262,7 @@ $Env:KUBECONFIG=("config-demo;config-demo-2")
 kubectl config view
 ```
 
-出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`contextの情報と、`config-demo`ファイルに設定された三つのcontextの情報がまとめてあることに注目してください:
+出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`の情報と、`config-demo`に設定された三つのコンテキストの情報がまとめてあることに注目してください:
 
 ```shell
 contexts:

content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md

@@ -36,7 +36,7 @@ weight: 70
 
 <!-- lessoncontent -->
 
-### Deploymentを使用したバックエンドの作成
+## Deploymentを使用したバックエンドの作成
 
 バックエンドは、単純な挨拶マイクロサービスです。
 バックエンドのDeploymentの構成ファイルは次のとおりです:
@@ -92,7 +92,7 @@ Events:
 ...
 ```
 
-### バックエンドServiceオブジェクトの作成
+## バックエンドServiceオブジェクトの作成
 
 フロントエンドをバックエンドに接続する鍵は、バックエンドServiceです。
 Serviceは、バックエンドマイクロサービスに常に到達できるように、永続的なIPアドレスとDNS名のエントリを作成します。
@@ -112,7 +112,7 @@ kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
 
 この時点で、バックエンドのDeploymentが実行され、そちらにトラフィックをルーティングできるServiceがあります。
 
-### フロントエンドの作成
+## フロントエンドの作成
 
 バックエンドができたので、バックエンドに接続するフロントエンドを作成できます。
 フロントエンドは、バックエンドServiceに指定されたDNS名を使用して、バックエンドワーカーPodに接続します。
@@ -146,7 +146,7 @@ nginxの構成は、[コンテナイメージ](/examples/service/access/Dockerfi
 これを行うためのより良い方法は、[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)を使用して、構成をより簡単に変更できるようにすることです。
 {{< /note >}}
 
-### フロントエンドServiceと対話
+## フロントエンドServiceと対話
 
 LoadBalancerタイプのServiceを作成したら、このコマンドを使用して外部IPを見つけることができます:
 
@@ -171,7 +171,7 @@ frontend   LoadBalancer   10.51.252.116   XXX.XXX.XXX.XXX    80/TCP   1m
 
 このIPを使用して、クラスターの外部から`frontend` Serviceとやり取りできるようになりました。
 
-### フロントエンドを介するトラフィック送信
+## フロントエンドを介するトラフィック送信
 
 フロントエンドとバックエンドが接続されました。
 フロントエンドServiceの外部IPに対してcurlコマンドを使用して、エンドポイントにアクセスできます。

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

@@ -34,9 +34,14 @@ weight: 60
 
 ## 2つのPodから成るアプリケーションのServiceを作成
 
+アプリケーションDeploymentの設定ファイルは以下の通りです:
+
+{{< codenew file="service/access/hello-application.yaml" >}}
+
 1. クラスタでHello Worldアプリケーションを稼働させます:
+   上記のファイルを使用し、アプリケーションのDeploymentを作成します:
    ```shell
-   kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080
+   kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
    ```
     このコマンドは
     [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)

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

@@ -0,0 +1,167 @@
+---
+title: Web UI (Dashboard)
+content_template: templates/concept
+weight: 10
+card:
+  name: tasks
+  weight: 30
+  title: Web UIダッシュボードを使用する
+---
+
+{{% capture overview %}}
+
+ダッシュボードは、WebベースのKubernetesユーザーインターフェイスです。ダッシュボードを使用して、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、コンテナ化されたアプリケーションをトラブルシューティングしたり、クラスターリソースを管理したりすることができます。ダッシュボードを使用して、クラスター上で実行されているアプリケーションの概要を把握したり、個々のKubernetesリソース(Deployments、Jobs、DaemonSetsなど)を作成または修正したりすることができます。たとえば、Deploymentのスケール、ローリングアップデートの開始、Podの再起動、デプロイウィザードを使用した新しいアプリケーションのデプロイなどが可能です。
+
+ダッシュボードでは、クラスター内のKubernetesリソースの状態や、発生した可能性のあるエラーに関する情報も提供されます。
+
+![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png)
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## ダッシュボードUIのデプロイ
+
+ダッシュボードUIはデフォルトではデプロイされていません。デプロイするには、以下のコマンドを実行します:
+
+```
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
+```
+
+## ダッシュボードUIへのアクセス
+
+
+クラスターデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。このデモ用のトークンを作成するには、[サンプルユーザーの作成](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md)ガイドに従ってください。
+
+{{< warning >}}
+チュートリアルで作成されたサンプルユーザーには管理者権限が与えられ、教育目的のみに使用されます。
+{{< /warning >}}
+
+### コマンドラインプロキシー
+以下のコマンドを実行することで、kubectlコマンドラインツールを使ってダッシュボードにアクセスすることができます:
+
+```
+kubectl proxy
+```
+
+kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。
+
+UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。
+
+{{< note >}}
+Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。
+{{< /note >}}
+
+## ウェルカムビュー
+
+空のクラスターでダッシュボードにアクセスすると、ウェルカムページが表示されます。このページには、このドキュメントへのリンクと、最初のアプリケーションをデプロイするためのボタンが含まれています。さらに、クラスターの`kube-system`[名前空間](/docs/tasks/administer-cluster/namespaces/)でデフォルトで実行されているシステムアプリケーション、たとえばダッシュボード自体を見ることができます。
+
+![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png)
+
+## コンテナ化されたアプリケーションのデプロイ
+
+ダッシュボードを使用すると、簡単なウィザードでコンテナ化されたアプリケーションをDeploymentとオプションのServiceとして作成してデプロイすることができます。アプリケーションの詳細を手動で指定するか、アプリケーションの設定を含むYAMLまたはJSONファイルをアップロードすることができます。
+
+任意のページの右上にある**CREATE**ボタンをクリックして開始します。
+
+### アプリケーションの詳細の指定
+
+デプロイウィザードでは、以下の情報を入力する必要があります:
+
+- **App name** (必須): アプリケーションの名前です。その名前の[label](/ja/docs/concepts/overview/working-with-objects/labels/)は、デプロイされるDeploymentとServiceに追加されます。
+
+  アプリケーション名は、選択したKubernetes[名前空間](/docs/tasks/administer-cluster/namespaces/)内で一意である必要があります。小文字で始まり、小文字または数字で終わり、小文字、数字、ダッシュ(-)のみを含む必要があります。文字数は24文字に制限されています。先頭と末尾のスペースは無視されます。
+
+- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。コンテナイメージの指定はコロンで終わらせる必要があります。
+
+- **Number of pods** (必須): アプリケーションをデプロイするPodの数です。値は正の整数である必要があります。
+
+  クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
+
+- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。外部サービスの場合は、そのために1つ以上のポートを開放する必要があるでしょう。詳細は[こちら](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)を参照してください。
+
+  クラスター内部からしか見えないその他のサービスは、内部サービスと呼ばれます。
+
+  サービスの種類にかかわらず、サービスを作成し、コンテナがポート(受信)をリッスンする場合は、2つのポートを指定する必要があります。サービスは、ポート(受信)をコンテナから見たターゲットポートにマッピングして作成されます。このサービスは、デプロイされたPodにルーティングされます。サポートされるプロトコルはTCPとUDPです。このサービスの内部DNS名は、上記のアプリケーション名として指定した値になります。
+
+必要に応じて、**高度なオプション**セクションを展開して、より多くの設定を指定することができます:
+
+- **Description**: ここで入力したテキストは、[アノテーション](/ja/docs/concepts/overview/working-with-with-objects/annotations/)としてDeploymentに追加され、アプリケーションの詳細に表示されます。
+
+- **Labels**: アプリケーションに使用するデフォルトの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)は、アプリケーション名とバージョンです。リリース、環境、ティア、パーティション、リリーストラックなど、Deployment、Service(存在する場合)、Podに適用する追加のラベルを指定できます。
+
+  例:
+
+  ```conf
+release=1.0
+tier=frontend
+environment=pod
+track=stable
+```
+
+- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。
+
+  ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。名前空間名には、最大63文字の英数字とダッシュ(-)を含めることができますが、大文字を含めることはできません。
+  名前空間名は数字だけで構成されるべきではありません。名前が10などの数値として設定されている場合、Podはデフォルトの名前空間に配置されます。
+
+  名前空間の作成に成功した場合は、デフォルトで選択されます。作成に失敗した場合は、最初の名前空間が選択されます。
+
+- **Image Pull Secret**: 指定されたDockerコンテナイメージが非公開の場合、[pull secret](/docs/concepts/configuration/secret/)の認証情報が必要になる場合があります。
+
+  ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。Secret名は DNSドメイン名の構文に従う必要があります。たとえば、`new.image-pull.secret`です。Secretの内容はbase64エンコードされ、[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。Secret名は最大253文字で構成されます。
+
+  イメージプルシークレットの作成に成功した場合は、デフォルトで選択されています。作成に失敗した場合は、シークレットは適用されません。
+
+- **CPU requirement (cores)**と**Memory requirement (MiB)**: コンテナの最小[リソース制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)を指定することができます。デフォルトでは、PodはCPUとメモリの制限がない状態で実行されます。
+
+- **Run command**と**Run command arguments**: デフォルトでは、コンテナは指定されたDockerイメージのデフォルトの[entrypointコマンド](/docs/tasks/inject-data-application/define-command-argument-container/)を実行します。コマンドのオプションと引数を使ってデフォルトを上書きすることができます。
+
+- **Run as privileged**: この設定は、[特権コンテナ](/ja/docs/concepts/workloads/pods/pod/#privileged-mode-for-pod-containers)内のプロセスが、ホスト上でrootとして実行されているプロセスと同等であるかどうかを決定します。特権コンテナは、ネットワークスタックの操作やデバイスへのアクセスなどの機能を利用できます。
+
+- **Environment variables**: Kubernetesは[環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)を介してServiceを公開しています。環境変数を作成したり、環境変数の値を使ってコマンドに引数を渡したりすることができます。環境変数の値はServiceを見つけるためにアプリケーションで利用できます。値は`$(VAR_NAME)`構文を使用して他の変数を参照できます。
+
+### YAMLまたはJSONファイルのアップロード
+
+Kubernetesは宣言的な設定をサポートしています。このスタイルでは、すべての設定は Kubernetes [API](/ja/docs/concepts/overview/kubernetes-api/)リソーススキーマを使用してYAMLまたは JSON設定ファイルに格納されます。
+
+デプロイウィザードでアプリケーションの詳細を指定する代わりに、YAMLまたはJSONファイルでアプリケーションを定義し、ダッシュボードを使用してファイルをアップロードできます。
+
+## ダッシュボードの使用
+以下のセクションでは、Kubernetes Dashboard UIのビュー、それらが提供するものとその使用方法について説明します。
+
+### ナビゲーション
+
+クラスターにKubernetesオブジェクトが定義されている場合、ダッシュボードではそれらのオブジェクトが初期表示されます。デフォルトでは_default_ 名前空間のオブジェクトのみが表示されますが、これはナビゲーションメニューにある名前空間セレクターで変更できます。
+
+ダッシュボードにはほとんどのKubernetesオブジェクトの種類が表示され、いくつかのメニューカテゴリーにグループ化されています。
+
+#### 管理者の概要
+クラスターと名前空間の管理者向けに、ダッシュボードにはノード、名前空間、永続ボリュームが一覧表示され、それらの詳細ビューが用意されています。ノードリストビューには、すべてのノードにわたって集計されたCPUとメモリーのメトリクスが表示されます。詳細ビューには、ノードのメトリクス、仕様、ステータス、割り当てられたリソース、イベント、ノード上で実行されているPodが表示されます。
+
+#### ワークロード
+選択した名前空間で実行されているすべてのアプリケーションを表示します。このビューでは、アプリケーションがワークロードの種類(例：Deployment、ReplicaSet、StatefulSetなど)ごとに一覧表示され、各ワークロードの種類を個別に表示することができます。リストには、ReplicaSetの準備ができたPodの数やPodの現在のメモリ使用量など、ワークロードに関する実用的な情報がまとめられています。
+
+ワークロードの詳細ビューには、ステータスや仕様情報、オブジェクト間の表面関係が表示されます。たとえば、ReplicaSetが制御しているPodや、新しいReplicaSet、DeploymentのためのHorizontal Pod Autoscalerなどです。
+
+#### Service
+外部の世界にサービスを公開し、クラスター内でサービスを発見できるようにするKubernetesリソースを表示します。そのため、ServiceとIngressのビューには、それらが対象とするPod、クラスター接続の内部エンドポイント、外部ユーザーの外部エンドポイントが表示されます。
+
+#### ストレージ
+ストレージビューには、アプリケーションがデータを保存するために使用するPersistentVolumeClaimリソースが表示されます。
+
+#### ConfigMapとSecret
+クラスターで実行されているアプリケーションのライブ設定に使用されているすべてのKubernetesリソースを表示します。このビューでは、設定オブジェクトの編集と管理が可能で、デフォルトで非表示になっているSecretを表示します。
+
+#### ログビューアー
+Podのリストと詳細ページは、ダッシュボードに組み込まれたログビューアーにリンクしています。このビューアーでは、単一のPodに属するコンテナからログをドリルダウンすることができます。
+
+![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+詳細については[Kubernetes Dashboardプロジェクトページ](https://github.com/kubernetes/dashboard)をご覧ください。
+
+{{% /capture %}}

content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md

@@ -13,7 +13,7 @@ content_type: concept
 独自のクラウドコントローラーマネージャーを構築する方法を説明する前に、クラウドコントローラーマネージャーがKubernetesの内部でどのように機能するかに関する背景を知っておくと役立ちます。
 クラウドコントローラーマネージャーはGoインターフェースを利用する`kube-controller-manager`のコードで、任意のクラウドの実装をプラグインとして利用できるようになっています。スキャフォールディングと汎用のコントローラー実装の大部分はKubernetesのコアになりますが、[クラウドプロバイダーのインターフェイス](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)が満たされていれば提供されているクラウドプロバイダーのインターフェイスが実行されるようになります。
 
-実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
+実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
 
 
 

content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md

@@ -216,7 +216,7 @@ kubectl delete namespace cpu-example
 
 ### アプリケーション開発者向け
 
-* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)
 
 * [PodのQuality of Serviceを設定する](/docs/tasks/configure-pod-container/quality-service-pod/)
 

content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md

@@ -63,7 +63,7 @@ Pod内で実行されているコンテナでシェルを実行します:
 ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。
 
 Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。
-コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#podの終了)を参照してください。
+コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)を参照してください。
 
 {{< note >}}
 Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。

content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -0,0 +1,337 @@
+---
+title: Liveness Probe、Readiness ProbeおよびStartup Probeを使用する
+content_template: templates/task
+weight: 110
+---
+
+{{% capture overview %}}
+
+このページでは、Liveness Probe、Readiness ProbeおよびStartup Probeの使用方法について説明します。
+
+[kubelet](/docs/admin/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。
+例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。
+このような状態のコンテナを再起動することで、バグがある場合でもアプリケーションの可用性を高めることができます。
+
+kubeletは、Readiness Probeを使用して、コンテナがトラフィックを受け入れられる状態であるかを認識します。
+Podが準備ができていると見なされるのは、Pod内の全てのコンテナの準備が整ったときです。
+一例として、このシグナルはServiceのバックエンドとして使用されるPodを制御するときに使用されます。
+Podの準備ができていない場合、そのPodはServiceのロードバランシングから切り離されます。
+
+kubeletは、Startup Probeを使用して、コンテナアプリケーションの起動が完了したかを認識します。
+Startup Probeを使用している場合、Startup Probeが成功するまでは、Liveness Probeと
+Readiness Probeによるチェックを無効にし、これらがアプリケーションの起動に干渉しないようにします。
+例えば、これを起動が遅いコンテナの起動チェックとして使用することで、起動する前にkubeletによって
+強制終了されることを防ぐことができます。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## コマンド実行によるLiveness Probeを定義する {#define-a-liveness-command}
+
+長期間実行されているアプリケーションの多くは、再起動されるまで回復できないような異常な状態になることがあります。
+Kubernetesはこのような状況を検知し、回復するためのLiveness Probeを提供します。
+
+この演習では、`k8s.gcr.io/busybox`イメージのコンテナを起動するPodを作成します。
+Podの構成ファイルは次の通りです。
+
+{{< codenew file="pods/probe/exec-liveness.yaml" >}}
+
+この構成ファイルでは、Podは一つの`Container`を起動します。
+`periodSeconds`フィールドは、kubeletがLiveness Probeを5秒おきに行うように指定しています。
+`initialDelaySeconds`フィールドは、kubeletが最初のProbeを実行する前に5秒間待機するように指示しています。
+Probeの動作としては、kubeletは`cat /tmp/healthy`を対象のコンテナ内で実行します。
+このコマンドが成功し、リターンコード0が返ると、kubeletはコンテナが問題なく動いていると判断します。
+リターンコードとして0以外の値が返ると、kubeletはコンテナを終了し、再起動を行います。
+
+このコンテナは、起動すると次のコマンドを実行します:
+
+```shell
+/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
+```
+
+コンテナが起動してから初めの30秒間は`/tmp/healthy`ファイルがコンテナ内に存在します。
+そのため初めの30秒間は`cat /tmp/healthy`コマンドは成功し、正常なリターンコードが返ります。
+その後30秒が経過すると、`cat /tmp/healthy`コマンドは異常なリターンコードを返します。
+
+このPodを起動してください:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
+```
+
+30秒間以内に、Podのイベントを確認します。
+
+```shell
+kubectl describe pod liveness-exec
+```
+
+この出力結果は、Liveness Probeがまだ失敗していないことを示しています。
+
+```
+FirstSeen    LastSeen    Count   From            SubobjectPath           Type        Reason      Message
+--------- --------    -----   ----            -------------           --------    ------      -------
+24s       24s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e
+```
+
+35秒後に、Podのイベントをもう一度確認します:
+
+```shell
+kubectl describe pod liveness-exec
+```
+
+出力結果の最後に、Liveness Probeが失敗していることを示すメッセージが表示されます。これによりコンテナは強制終了し、再作成されました。
+
+```
+FirstSeen LastSeen    Count   From            SubobjectPath           Type        Reason      Message
+--------- --------    -----   ----            -------------           --------    ------      -------
+37s       37s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e
+2s        2s      1   {kubelet worker0}   spec.containers{liveness}   Warning     Unhealthy   Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
+```
+
+さらに30秒後、コンテナが再起動していることを確認します:
+
+```shell
+kubectl get pod liveness-exec
+```
+
+出力結果から、`RESTARTS`がインクリメントされていることを確認します:
+
+```
+NAME            READY     STATUS    RESTARTS   AGE
+liveness-exec   1/1       Running   1          1m
+```
+
+## HTTPリクエストによるLiveness Probeを定義する {#define-a-liveness-http-request}
+
+別の種類のLiveness Probeでは、HTTP GETリクエストを使用します。
+次の構成ファイルは、`k8s.gcr.io/liveness`イメージを使用したコンテナを起動するPodを作成します。
+
+{{< codenew file="pods/probe/http-liveness.yaml" >}}
+
+この構成ファイルでは、Podは一つの`Container`を起動します。
+`periodSeconds`フィールドは、kubeletがLiveness Probeを3秒おきに行うように指定しています。
+`initialDelaySeconds`フィールドは、kubeletが最初のProbeを実行する前に3秒間待機するように指示しています。
+Probeの動作としては、kubeletは8080ポートをリッスンしているコンテナ内のサーバーに対してHTTP GETリクエストを送ります。
+サーバー内の`/healthz`パスに対するハンドラーが正常なリターンコードを応答した場合、
+kubeletはコンテナが問題なく動いていると判断します。
+異常なリターンコードを応答すると、kubeletはコンテナを終了し、再起動を行います。
+
+200以上400未満のコードは成功とみなされ、その他のコードは失敗とみなされます。
+
+[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go)
+にてサーバーのソースコードを確認することができます。
+
+コンテナが生きている初めの10秒間は、`/healthz`ハンドラーが200ステータスを返します。
+その後、ハンドラーは500ステータスを返します。
+
+```go
+http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
+    duration := time.Now().Sub(started)
+    if duration.Seconds() > 10 {
+        w.WriteHeader(500)
+        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
+    } else {
+        w.WriteHeader(200)
+        w.Write([]byte("ok"))
+    }
+})
+```
+
+kubeletは、コンテナが起動してから3秒後からヘルスチェックを行います。
+そのため、初めのいくつかのヘルスチェックは成功します。しかし、10秒経過するとヘルスチェックは失敗し、kubeletはコンテナを終了し、再起動します。
+
+HTTPリクエストのチェックによるLiveness Probeを試すには、以下のようにPodを作成します:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
+```
+
+10秒後、Podのイベントを表示して、Liveness Probeが失敗し、コンテナが再起動されていることを確認します。
+
+```shell
+kubectl describe pod liveness-http
+```
+
+v1.13以前(v1.13を含む)のリリースにおいては、Podが起動しているノードに環境変数`http_proxy`
+(または `HTTP_PROXY`)が設定されている場合、HTTPリクエストのLiveness Probeは設定されたプロキシを使用します。
+v1.13より後のリリースにおいては、ローカルHTTPプロキシ環境変数の設定はHTTPリクエストのLiveness Probeに影響しません。
+
+## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe}
+
+3つ目のLiveness ProbeはTCPソケットを使用するタイプです。
+この構成においては、kubeletは指定したコンテナのソケットを開くことを試みます。
+コネクションが確立できる場合はコンテナを正常とみなし、失敗する場合は異常とみなします。
+
+{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
+
+見ての通り、TCPによるチェックの構成はHTTPによるチェックと非常に似ています。
+この例では、Readiness ProbeとLiveness Probeを両方使用しています。
+kubeletは、コンテナが起動してから5秒後に最初のReadiness Probeを開始します。
+これは`goproxy`コンテナの8080ポートに対して接続を試みます。
+このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。
+
+この構成では、Readiness Probeに加えてLiveness Probeが含まれています。
+kubeletは、コンテナが起動してから15秒後に最初のLiveness Probeを実行します。
+Readiness Probeと同様に、これは`goproxy`コンテナの8080ポートに対して接続を試みます。
+Liveness Probeが失敗した場合、コンテナは再起動されます。
+
+TCPのチェックによるLiveness Probeを試すには、以下のようにPodを作成します:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
+```
+
+15秒後、Podのイベントを表示し、Liveness Probeが行われていることを確認します:
+
+```shell
+kubectl describe pod goproxy
+```
+
+## 名前付きポートを使用する {#use-a-named-port}
+
+HTTPまたはTCPによるProbeにおいて、[ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core)
+で定義した名前付きポートを使用することができます。
+
+```yaml
+ports:
+- name: liveness-port
+  containerPort: 8080
+  hostPort: 8080
+
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+```
+
+## Startup Probeを使用して、起動の遅いコンテナを保護する {#define-startup-probes}
+
+場合によっては、最初の初期化において追加の起動時間が必要になるようなレガシーアプリケーションを扱う必要があります。
+そのような場合、デッドロックに対する迅速な反応を損なうことなくLiveness Probeのパラメーターを設定することは難しい場合があります。
+
+これに対する解決策の一つは、Liveness Probeと同じ構成のコマンドを用いるか、HTTPまたはTCPによるチェックを使用したStartup Probeをセットアップすることです。
+その際、`failureThreshold * periodSeconds`で計算される時間を、起動時間として想定される最も遅いケースをカバーできる十分な長さに設定します。
+
+上記の例は、次のようになります:
+
+```yaml
+ports:
+- name: liveness-port
+  containerPort: 8080
+  hostPort: 8080
+
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+  failureThreshold: 1
+  periodSeconds: 10
+
+startupProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+  failureThreshold: 30
+  periodSeconds: 10
+```
+
+Startup Probeにより、アプリケーションは起動が完了するまでに最大5分間の猶予(30 * 10 = 300秒)が与えられます。
+Startup Probeに一度成功すると、その後はLiveness Probeが引き継ぎ、コンテナのデッドロックに対して迅速に反応します。
+Startup Probeが成功しない場合、コンテナは300秒後に終了し、その後はPodの`restartPolicy`に従います。
+
+## Readiness Probeを定義する {#define-readiness-probes}
+
+アプリケーションは一時的にトラフィックを処理できないことが起こり得ます。
+例えば、アプリケーションは起動時に大きなデータまたは構成ファイルを読み込む必要がある場合や、起動後に外部サービスに依存している場合があります。
+このような場合、アプリケーション自体を終了させたくはありませんが、このアプリケーションに対してリクエストも送信したくないと思います。
+Kubernetesは、これらの状況を検知して緩和するための機能としてReadiness Probeを提供します。
+これにより、準備ができていないことを報告するコンテナを含むPodは、KubernetesのServiceを通してトラフィックを受信しないようになります。
+
+{{< note >}}
+Readiness Probeは、コンテナの全てのライフサイクルにおいて実行されます。
+{{< /note >}}
+
+Readiness ProbeはLiveness Probeと同様に構成します。
+唯一の違いは`readinessProbe`フィールドを`livenessProbe`フィールドの代わりに利用することだけです。
+
+```yaml
+readinessProbe:
+  exec:
+    command:
+    - cat
+    - /tmp/healthy
+  initialDelaySeconds: 5
+  periodSeconds: 5
+```
+
+HTTPおよびTCPによるReadiness Probeの構成もLiveness Probeと同じです。
+
+Readiness ProbeとLiveness Probeは同じコンテナで同時に使用できます。
+両方使用することで、準備できていないコンテナへのトラフィックが到達しないようにし、コンテナが失敗したときに再起動することができます。
+
+## Probeの構成 {#configure-probes}
+
+{{< comment >}}
+Eventually, some of this section could be moved to a concept topic.
+{{< /comment >}}
+
+[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) には、
+Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制御するために使用できるフィールドがあります:
+
+* `initialDelaySeconds`: コンテナが起動してから、Liveness ProbeまたはReadiness Probeが開始されるまでの秒数。デフォルトは0秒。最小値は0。
+* `periodSeconds`: Probeが実行される頻度(秒数)。デフォルトは10秒。最小値は1。
+* `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。
+* `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。
+デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。
+* `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。
+Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。
+Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。
+
+[HTTPによるProbe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
+には、`httpGet`にて設定できる追加のフィールドがあります:
+
+* `host`: 接続先ホスト名。デフォルトはPod IP。おそらくはこのフィールドの代わりに`httpHeaders`内の"Host"を代わりに使用することになります。
+* `scheme`: ホストへの接続で使用するスキーマ（HTTP または HTTPS）。デフォルトは HTTP。
+* `path`: HTTPサーバーへアクセスする際のパス
+* `httpHeaders`: リクエスト内のカスタムヘッダー。HTTPでは重複したヘッダーが許可されています。
+* `port`: コンテナにアクセスする際のポートの名前または番号。ポート番号の場合、1から65535の範囲内である必要があります。
+
+HTTPによるProbeの場合、kubeletは指定したパスとポートに対するHTTPリクエストを送ることでチェックを行います。
+`httpGet`のオプションである`host`フィールドでアドレスが上書きされない限り、kubeletはPodのIPアドレスに対してProbeを送ります。
+`scheme`フィールドに`HTTPS`がセットされている場合、kubeletは証明書の検証を行わずにHTTPSリクエストを送ります。
+ほとんどのシナリオにおいては、`host`フィールドを使用する必要はありません。次のシナリオは使用する場合の一例です。
+仮にコンテナが127.0.0.1をリッスンしており、かつPodの`hostNetwork`フィールドがtrueだとします。
+その場合においては、`httpGet`フィールド内の`host`には127.0.0.1をセットする必要があります。
+より一般的なケースにおいてPodが仮想ホストに依存している場合は、おそらく`host`フィールドではなく、`httpHeaders`フィールド内の`Host`ヘッダーを使用する必要があります。
+
+TCPによるProbeの場合、kubeletはPodの中ではなく、ノードに対してコネクションを確立するProbeを実行します。
+kubeletはServiceの名前を解決できないため、`host`パラメーター内でServiceの名前を使用することはできません。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)についてもっと学ぶ
+
+また、次のAPIリファレンスも参考にしてください:
+
+* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
+
+{{% /capture %}}

content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md

@@ -0,0 +1,674 @@
+---
+title: Podを構成してConfigMapを使用する
+content_template: templates/task
+weight: 150
+card:
+  name: tasks
+  weight: 50
+---
+
+{{% capture overview %}}
+ConfigMapを使用すると、設定をイメージのコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+
+## ConfigMapを作成する
+`kubectl create configmap`または`kustomization.yaml`のConfigMap generatorを使用すると、ConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。
+
+### kubectl create configmapを使用してConfigMapを作成する
+
+`kubectl create configmap`を使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、[ファイル](#create-configmaps-from-files)、または[リテラル値](#create-configmaps-from-literal-values)から作成します:
+
+```shell
+kubectl create configmap <map-name> <data-source>
+```
+
+\<map-name>の部分はConfigMapに割り当てる名前で、\<data-source>はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
+
+ファイルをベースにConfigMapを作成する場合、\<data-source> のキーはデフォルトでファイル名になり、値はデフォルトでファイルの中身になります。
+
+[`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または
+[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用すると、ConfigMapに関する情報を取得できます。
+
+#### ディレクトリからConfigMapを作成する{#create-configmaps-from-directories}
+
+`kubectl create configmap`を使用すると、同一ディレクトリ内にある複数のファイルから1つのConfigMapを作成できます。ディレクトリをベースにConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。ディレクトリ内にある通常のファイルでないものは無視されます(例: サブディレクトリ、シンボリックリンク、デバイス、パイプなど)。
+
+例えば:
+
+```shell
+# ローカルディレクトリを作成します
+mkdir -p configure-pod-container/configmap/
+
+# `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします
+wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
+wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
+
+# ConfigMapを作成します
+kubectl create configmap game-config --from-file=configure-pod-container/configmap/
+```
+
+上記のコマンドは各ファイルをパッケージ化します。この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化します。 以下のコマンドを使用すると、ConfigMapの詳細を表示できます:
+
+```shell
+kubectl describe configmaps game-config
+```
+
+出力結果は以下のようになります:
+```
+Name:         game-config
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>
+
+Data
+====
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+ui.properties:
+----
+color.good=purple
+color.bad=yellow
+allow.textmode=true
+how.nice.to.look=fairlyNice
+```
+
+`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties` ファイルはConfigMapの`data`セクションに表示されます。
+
+```shell
+kubectl get configmaps game-config -o yaml
+```
+出力結果は以下のようになります:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2016-02-18T18:52:05Z
+  name: game-config
+  namespace: default
+  resourceVersion: "516"
+  uid: b4952dc3-d670-11e5-8cd0-68f728db1985
+data:
+  game.properties: |
+    enemies=aliens
+    lives=3
+    enemies.cheat=true
+    enemies.cheat.level=noGoodRotten
+    secret.code.passphrase=UUDDLRLRBABAS
+    secret.code.allowed=true
+    secret.code.lives=30
+  ui.properties: |
+    color.good=purple
+    color.bad=yellow
+    allow.textmode=true
+    how.nice.to.look=fairlyNice
+```
+
+#### ファイルからConfigMapを作成する{#create-configmaps-from-files}
+
+`kubectl create configmap`を使用して、個別のファイルまたは複数のファイルからConfigMapを作成できます。
+
+例えば、
+
+```shell
+kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties
+```
+
+は、以下のConfigMapを生成します:
+
+```shell
+kubectl describe configmaps game-config-2
+```
+
+出力結果は以下のようになります:
+
+```
+Name:         game-config-2
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>
+
+Data
+====
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+```
+
+`--from-file`引数を複数回渡し、ConfigMapを複数のデータソースから作成できます。
+
+```shell
+kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties
+```
+
+以下のコマンドを使用すると、ConfigMap`game-config-2`の詳細を表示できます:
+
+```shell
+kubectl describe configmaps game-config-2
+```
+
+出力結果は以下のようになります:
+
+```
+Name:         game-config-2
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>
+
+Data
+====
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+ui.properties:
+----
+color.good=purple
+color.bad=yellow
+allow.textmode=true
+how.nice.to.look=fairlyNice
+```
+
+`--from-env-file`オプションを利用してConfigMapをenv-fileから作成します。例えば:
+
+```shell
+# Env-filesは環境編集のリストを含んでいます。
+# 以下のシンタックスルールが適用されます:
+#   envファイルの各行はVAR=VALの形式である必要がある。
+#   #で始まる行 (例えばコメント)は無視される。
+#   空の行は無視される。
+#   クオーテーションマークは特別な扱いは処理をしない(例えばConfigMapの値の一部になる).
+
+# `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします
+wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
+
+# env-file `game-env-file.properties`は以下のようになります
+cat configure-pod-container/configmap/game-env-file.properties
+enemies=aliens
+lives=3
+allowed="true"
+
+# このコメントと上記の空の行は無視されます
+```
+
+```shell
+kubectl create configmap game-config-env-file \
+       --from-env-file=configure-pod-container/configmap/game-env-file.properties
+```
+
+は、以下のConfigMapを生成します:
+
+```shell
+kubectl get configmap game-config-env-file -o yaml
+```
+
+出力結果は以下のようになります:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2017-12-27T18:36:28Z
+  name: game-config-env-file
+  namespace: default
+  resourceVersion: "809965"
+  uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
+data:
+  allowed: '"true"'
+  enemies: aliens
+  lives: "3"
+```
+
+{{< caution >}}
+`--from-env-file`を複数回渡してConfigMapを複数のデータソースから作成する場合、最後のenv-fileのみが使用されます。
+{{< /caution >}}
+
+`--from-env-file`を複数回渡す場合の挙動は以下のように示されます:
+
+```shell
+# `configure-pod-container/configmap/`ディレクトリにサンブルファイルをダウンロードします
+wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
+
+# ConfigMapを作成します
+kubectl create configmap config-multi-env-files \
+        --from-env-file=configure-pod-container/configmap/game-env-file.properties \
+        --from-env-file=configure-pod-container/configmap/ui-env-file.properties
+```
+
+は、以下のConfigMapを生成します:
+
+```shell
+kubectl get configmap config-multi-env-files -o yaml
+```
+
+出力結果は以下のようになります:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2017-12-27T18:38:34Z
+  name: config-multi-env-files
+  namespace: default
+  resourceVersion: "810136"
+  uid: 252c4572-eb35-11e7-887b-42010a8002b8
+data:
+  color: purple
+  how: fairlyNice
+  textmode: "true"
+```
+
+#### ファイルからConfigMap作成する場合は使用するキーを定義する
+
+`--from-file`引数を使用する場合、ConfigMapの`data` セクションでキーにファイル名以外を定義できます:
+
+```shell
+kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
+```
+
+`<my-key-name>`の部分はConfigMapで使うキー、`<path-to-file>` はキーで表示したいデータソースファイルの場所です。
+
+例えば:
+
+```shell
+kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties
+```
+
+は、以下のConfigMapを生成します:
+```
+kubectl get configmaps game-config-3 -o yaml
+```
+
+出力結果は以下のようになります:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2016-02-18T18:54:22Z
+  name: game-config-3
+  namespace: default
+  resourceVersion: "530"
+  uid: 05f8da22-d671-11e5-8cd0-68f728db1985
+data:
+  game-special-key: |
+    enemies=aliens
+    lives=3
+    enemies.cheat=true
+    enemies.cheat.level=noGoodRotten
+    secret.code.passphrase=UUDDLRLRBABAS
+    secret.code.allowed=true
+    secret.code.lives=30
+```
+
+#### リテラル値からConfigMapを作成する{#create-configmaps-from-literal-values}
+
+`--from-literal`引数を指定して`kubectl create configmap`を使用すると、コマンドラインからリテラル値を定義できます:
+
+```shell
+kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
+```
+
+複数のキーバリューペアを渡せます。CLIに提供された各ペアは、ConfigMapの`data`セクションで別のエントリーとして表示されます。
+
+```shell
+kubectl get configmaps special-config -o yaml
+```
+
+出力結果は以下のようになります:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2016-02-18T19:14:38Z
+  name: special-config
+  namespace: default
+  resourceVersion: "651"
+  uid: dadce046-d673-11e5-8cd0-68f728db1985
+data:
+  special.how: very
+  special.type: charm
+```
+
+### ジェネレーターからConfigMapを作成する
+`kubectl`は`kustomization.yaml`を1.14からサポートしています。
+ジェネレーターからConfigMapを作成して適用すると、APIサーバー上でオブジェクトを作成できます。ジェネレーターはディレクトリ内の`kustomization.yaml`で指定する必要があリます。
+
+#### ファイルからConfigMapを生成する
+例えば、ファイル`configure-pod-container/configmap/game.properties`からConfigMapを生成するには、
+```shell
+# ConfigMapGeneratorを含むkustomization.yamlファイルを作成する
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: game-config-4
+  files:
+  - configure-pod-container/configmap/game.properties
+EOF
+```
+
+ConfigMapを作成するためにkustomizationディレクトリを適用します。
+```shell
+kubectl apply -k .
+configmap/game-config-4-m9dm2f92bt created
+```
+
+ConfigMapが作成されたことを以下のようにチェックできます:
+
+```shell
+kubectl get configmap
+NAME                       DATA   AGE
+game-config-4-m9dm2f92bt   1      37s
+
+
+kubectl describe configmaps/game-config-4-m9dm2f92bt
+Name:         game-config-4-m9dm2f92bt
+Namespace:    default
+Labels:       <none>
+Annotations:  kubectl.kubernetes.io/last-applied-configuration:
+                {"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...
+
+Data
+====
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+Events:  <none>
+```
+
+生成されたConfigMapの名前は、コンテンツをハッシュ化したサフィックスを持つことに注意してください。これにより、コンテンツが変更されるたびに新しいConfigMapが生成されます。
+
+#### ファイルからConfigMapを生成する場合に使用するキーを定義する
+ConfigMapジェネレーターで使用するキーはファイルの名前以外を定義できます。
+例えば、ファイル`configure-pod-container/configmap/game.properties`からキー`game-special-key`を持つConfigMapを作成する場合
+
+```shell
+# ConfigMapGeneratorを含むkustomization.yamlファイルを作成する
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: game-config-5
+  files:
+  - game-special-key=configure-pod-container/configmap/game.properties
+EOF
+```
+
+kustomizationディレクトリを適用してConfigMapを作成します。
+```shell
+kubectl apply -k .
+configmap/game-config-5-m67dt67794 created
+```
+
+#### リテラルからConfigMapを作成する
+リテラル`special.type=charm`と`special.how=very`からConfigMapを作成する場合は、
+以下のように`kustomization.yaml`のConfigMapジェネレーターで指定できます。
+```shell
+# ConfigMapGeneratorを含むkustomization.yamlファイルを作成します
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: special-config-2
+  literals:
+  - special.how=very
+  - special.type=charm
+EOF
+```
+kustomizationディレクトリを適用してConfigMapを作成します。
+```shell
+kubectl apply -k .
+configmap/special-config-2-c92b5mmcf2 created
+```
+
+## ConfigMapデータを使用してコンテナ環境変数を定義する
+
+### 単一のConfigMapのデータを使用してコンテナ環境変数を定義する
+
+1.  ConfigMapに環境変数をキーバリューペアとして定義します:
+
+    ```shell
+    kubectl create configmap special-config --from-literal=special.how=very
+    ```
+
+2.  ConfigMapに定義された値`special.how`をPod specificationの環境変数`SPECIAL_LEVEL_KEY`に割り当てます。
+
+   {{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}}
+
+   Podを作成します:
+
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
+ ```
+
+   すると、Podの出力結果に環境変数`SPECIAL_LEVEL_KEY=very`が含まれています。
+
+### 複数のConfigMapのデータを使用してコンテナ環境変数を定義する
+
+ * 先ほどの例の通り、まずはConfigMapを作成します。
+
+   {{< codenew file="configmap/configmaps.yaml" >}}
+
+   ConfigMapを作成します:
+
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
+ ```
+
+* Pod specificationの環境変数を定義します
+
+  {{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}}
+
+  Podを作成します:
+
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
+ ```
+   すると、Podの出力結果に環境変数`SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`が含まれています。
+
+## ConfigMapの全てのキーバリューペアをコンテナ環境変数として構成する
+
+{{< note >}}
+この機能はKubernetes v1.6以降で利用可能です。
+{{< /note >}}
+
+* 複数のキーバリューペアを含むConfigMapを作成します。
+
+  {{< codenew file="configmap/configmap-multikeys.yaml" >}}
+
+  ConfigMapを作成します:
+
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
+ ```
+
+* `envFrom`を利用して全てのConfigMapのデータをコンテナ環境変数として定義します。ConfigMapからのキーがPodの環境変数名になります。
+
+ {{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
+
+ Podを作成します:
+
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
+ ```
+
+ すると、Podの出力結果は環境変数`SPECIAL_LEVEL=very`と`SPECIAL_TYPE=charm`が含まれています。
+
+
+## PodのコマンドでConfigMapに定義した環境変数を使用する
+
+ConfigMapに環境変数を定義し、Pod specificationの`command` セクションで`$(VAR_NAME)`Kubernetes置換構文を介して使用できます。
+
+例えば以下のPod specificationは
+
+{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}}
+
+以下コマンドの実行で作成され、
+
+```shell
+kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml
+```
+
+`test-container`コンテナで以下の出力結果を表示します:
+
+```shell
+very charm
+```
+
+## ボリュームにConfigMapデータを追加する
+
+[ファイルからConfigMapを作成する](#create-configmaps-from-files)で説明したように、``--from-file``を使用してConfigMapを作成する場合は、ファイル名がConfigMapの`data`セクションに保存されるキーになり、ファイルのコンテンツがキーの値になります。
+
+このセクションの例は以下に示されているspecial-configと名付けれたConfigMapについて言及したものです。
+
+{{< codenew file="configmap/configmap-multikeys.yaml" >}}
+
+ConfigMapを作成します:
+
+```shell
+kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
+```
+
+### ConfigMapに保存されているデータをボリュームに入力する
+
+ConfigMap名をPod specificationの`volumes`セクション配下に追加します。  
+これによりConfigMapデータが`volumeMounts.mountPath`で指定されたディレクトリに追加されます (このケースでは、`/etc/config`に)。`command`セクションはConfigMapのキーに合致したディレクトリファイルを名前別でリスト表示します。
+
+{{< codenew file="pods/pod-configmap-volume.yaml" >}}
+
+Podを作成します:
+
+```shell
+kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
+```
+
+Podが稼働していると、`ls /etc/config/`は以下の出力結果を表示します:
+
+```shell
+SPECIAL_LEVEL
+SPECIAL_TYPE
+```
+
+{{< caution >}}
+`/etc/config/`ディレクトリに何かファイルがある場合、それらは削除されます。
+{{< /caution >}}
+
+### ConfigMapデータをボリュームの特定のパスに追加する
+
+`path`フィールドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。
+このケースでは`SPECIAL_LEVEL`アイテムが`/etc/config/keys`の`config-volume`ボリュームにマウントされます。
+
+{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
+
+Podを作成します:
+
+```shell
+kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml
+```
+
+Podが稼働していると、 `cat /etc/config/keys`は以下の出力結果を表示します:
+
+```shell
+very
+```
+
+{{< caution >}}
+先ほどのように、`/etc/config/` ディレクトリのこれまでのファイルは全て削除されます
+{{< /caution >}}
+
+### キーを特定のパスとファイルアクセス許可に投影する
+
+キーをファイル単位で特定のパスとアクセス許可に投影できます。[Secret](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)のユーザーガイドで構文が解説されています。
+
+### マウントされたConfigMapは自動的に更新される
+
+ボリュームで使用されているConfigMapが更新されている場合、投影されているキーも同じく結果的に更新されます。kubeletは定期的な同期ごとにマウントされているConfigMapが更新されているかチェックします。しかし、これはローカルのttlを基にしたキャッシュでConfigMapの現在の値を取得しています。その結果、新しいキーがPodに投影されてからConfigMapに更新されるまでのトータルの遅延はkubeletで、kubeletの同期期間(デフォルトで1分) + ConfigMapキャッシュのttl(デフォルトで1分)の長さになる可能性があります。Podのアノテーションを1つ更新すると即時のリフレッシュをトリガーできます。
+
+{{< note >}}
+ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュームとして利用するコンテナはConfigMapの更新を受け取りません。
+{{< /note >}}
+
+{{% /capture %}}
+
+{{% capture discussion %}}
+
+## ConfigMapとPodsを理解する
+
+ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secret](/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。
+
+{{< note >}}
+ConfigMapはプロパティーファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。
+{{< /note >}}
+
+ConfigMapの`data`フィールドは構成情報を含みます。下記の例のように、シンプルに個別のプロパティーを`--from-literal`で定義、または複雑に構成ファイルまたはJSON blobsを`--from-file`で定義できます。
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2016-02-18T19:14:38Z
+  name: example-config
+  namespace: default
+data:
+  # --from-literalを使用してシンプルにプロパティーを定義する例
+  example.property.1: hello
+  example.property.2: world
+  # --from-fileを使用して複雑にプロパティーを定義する例
+  example.property.file: |-
+    property.1=value-1
+    property.2=value-2
+    property.3=value-3
+```
+
+### 制限事項
+
+- ConfigMapはPod specificationを参照させる前に作成する必要があります(ConfigMapを"optional"として設定しない限り)。存在しないConfigMapを参照させた場合、Podは起動しません。同様にConfigMapに存在しないキーを参照させた場合も、Podは起動しません。
+
+- ConfigMapで`envFrom`を使用して環境変数を定義した場合、無効と判断されたキーはスキップされます。Podは起動されますが、無効な名前はイベントログに(`InvalidVariableNames`)と記録されます。ログメッセージはスキップされたキーごとにリスト表示されます。例えば:
+
+   ```shell
+   kubectl get events
+   ```
+
+   出力結果は以下のようになります:
+   ```
+   LASTSEEN FIRSTSEEN COUNT NAME          KIND  SUBOBJECT  TYPE      REASON                            SOURCE                MESSAGE
+   0s       0s        1     dapi-test-pod Pod              Warning   InvalidEnvironmentVariableNames   {kubelet, 127.0.0.1}  Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
+   ```
+
+- ConfigMapは特定の{{< glossary_tooltip term_id="namespace" >}}に属します。ConfigMapは同じ名前空間に属するPodからのみ参照できます。
+
+- {{< glossary_tooltip text="static pods" term_id="static-pod" >}}はKubeletがサポートしていないため、ConfigMapに使用できません。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+* 実践例[Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。
+
+{{% /capture %}}

content/ja/docs/tasks/configure-pod-container/quality-service-pod.md

@@ -231,9 +231,9 @@ kubectl delete namespace qos-example
 
 ### アプリケーション開発者向け
 
-* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)
 
-* [コンテナとPodにCPUリソースを割り当てる](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [コンテナとPodにCPUリソースを割り当てる](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/)
 
 ### クラスター管理者向け
 
@@ -251,6 +251,7 @@ kubectl delete namespace qos-example
 
 * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
 
+* [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
 
 
 

content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md

@@ -114,6 +114,8 @@ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${AR
 kubectl exec cassandra -- cat /var/log/cassandra/system.log
 ```
 
+クラスターで有効にしていれば、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) を既存のPodに追加することもできます。 新しい一時的なコンテナを利用して、たとえばPod内の問題の診断のために任意のコマンドを実行することができます。利用できる機能を含む詳細については、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) のページを参照してください。
+
 これらのアプローチがいずれも機能しない場合、Podが実行されているホストマシンを見つけて、そのホストにSSH接続することができます。
 
 ## ReplicationControllerのデバッグ

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

@@ -31,7 +31,7 @@ content_type: task
 Podを作成します:
 
 ```shell
-kubectl create -f https://k8s.io/examples/application/shell-demo.yaml
+kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml
 ```
 
 コンテナが実行中であることを確認します:

content/ja/docs/tasks/inject-data-application/_index.md

@@ -0,0 +1,4 @@
+---
+title: "アプリケーションへのデータ注入"
+weight: 30
+---

content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md

@@ -0,0 +1,113 @@
+---
+title: コンテナの環境変数の定義
+content_template: templates/task
+weight: 20
+---
+
+{{% capture overview %}}
+
+このページでは、Kubernetes Podでコンテナの環境変数を定義する方法を説明します。
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+
+{{% capture steps %}}
+
+## コンテナの環境変数を定義する {#define-an-environment-variable-for-a-container}
+
+Podを作成するとき、そのPodで実行するコンテナに環境変数を設定することができます。環境変数を設定するには、設定ファイルに `env` または `envFrom` フィールドを含めます。
+
+この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定ファイルを以下に示します:
+
+{{< codenew file="pods/inject/envars.yaml" >}}
+
+1. YAML設定ファイルに基づいてPodを作成します:
+
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
+    ```
+
+1. 実行中のPodを一覧表示します:
+
+    ```shell
+    kubectl get pods -l purpose=demonstrate-envars
+    ```
+
+    出力は以下のようになります:
+
+    ```
+    NAME            READY     STATUS    RESTARTS   AGE
+    envar-demo      1/1       Running   0          9s
+    ```
+
+1. Podで実行しているコンテナのシェルを取得します:
+
+    ```shell
+    kubectl exec -it envar-demo -- /bin/bash
+    ```
+
+1. シェルで`printenv`コマンドを実行すると、環境変数の一覧が表示されます。
+
+    ```shell
+    root@envar-demo:/# printenv
+    ```
+
+    出力は以下のようになります:
+
+    ```
+    NODE_VERSION=4.4.2
+    EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
+    HOSTNAME=envar-demo
+    ...
+    DEMO_GREETING=Hello from the environment
+    DEMO_FAREWELL=Such a sweet sorrow
+    ```
+
+1. シェルを終了するには、`exit`と入力します。
+
+{{< note >}}
+`env`または`envFrom`フィールドを使用して設定された環境変数は、コンテナイメージで指定された環境変数を上書きします。
+{{< /note >}}
+
+## 設定の中で環境変数を使用する {#using-environment-variables-inside-of-your-config}
+
+Podの設定で定義した環境変数は、Podのコンテナに設定したコマンドや引数など、設定の他の場所で使用することができます。以下の設定例では、環境変数`GREETING`、`HONORORIFIC`、`NAME`にそれぞれ `Warm greetings to`、`The Most Honorable`、`Kubernetes`を設定しています。これらの環境変数は、`env-print-demo`コンテナに渡されるCLI引数で使われます。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: print-greeting
+spec:
+  containers:
+  - name: env-print-demo
+    image: bash
+    env:
+    - name: GREETING
+      value: "Warm greetings to"
+    - name: HONORIFIC
+      value: "The Most Honorable"
+    - name: NAME
+      value: "Kubernetes"
+    command: ["echo"]
+    args: ["$(GREETING) $(HONORIFIC) $(NAME)"]
+```
+
+作成されると、コンテナ上で`echo Warm greetings to The Most Honorable Kubernetes`というコマンドが実行されます。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細
+* [Secretを環境変数として使用する](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)詳細
+* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)をご覧ください。
+
+{{% /capture %}}

content/ja/docs/tasks/run-application/delete-stateful-set.md

@@ -51,7 +51,7 @@ kubectl delete pods -l app=myapp
 
 ### 永続ボリューム
 
-StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#podの終了)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
+StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
 
 {{< note >}}
 データを損失する可能性があるため、PVCを削除するときは注意してください。
@@ -73,14 +73,14 @@ kubectl delete pvc -l app=myapp
 
 ### StatefulSet Podの強制削除
 
-StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
+StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
 
 
 
 ## {{% heading "whatsnext" %}}
 
 
-[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細
+[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細
 
 
 

content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md

@@ -31,7 +31,7 @@ StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する
 kubectl delete pods <pod>
 ```
 
-上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/docs/user-guide/pods/#termination-of-pods)ことを保証します。
+上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。
 
 Kubernetes（バージョン1.5以降）は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
 

content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

@@ -19,7 +19,7 @@ content_type: task
   * クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。
   * `hack/local-up-cluster.sh`を使用している場合は、環境変数`KUBE_ENABLE_CLUSTER_DNS`が設定されていることを確認し、インストールスクリプトを実行してください。
 * [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。
-* v2.7.0以降の[Helm](http://helm.sh/)をインストールしてください。
+* v2.7.0以降の[Helm](https://helm.sh/)をインストールしてください。
   * [Helm install instructions](https://helm.sh/docs/intro/install/)を参考にしてください。
   * 上記のバージョンのHelmをすでにインストールしている場合は、`helm init`を実行し、HelmのサーバーサイドコンポーネントであるTillerをインストールしてください。
 

content/ja/docs/tasks/tools/install-kubectl.md

@@ -52,7 +52,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと
 4. インストールしたバージョンが最新であることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 
 ### ネイティブなパッケージマネージャーを使用してインストールする
@@ -81,21 +81,24 @@ yum install -y kubectl
 
 ### 他のパッケージマネージャーを使用してインストールする
 
+{{< tabs name="other_kubectl_install" >}}
+{{% tab name="Snap" %}}
 Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマネージャーをサポートする別のLinuxディストリビューションを使用している場合、kubectlは[snap](https://snapcraft.io/)アプリケーションとして使用できます。
 
-Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。
+```shell
-
+snap install kubectl --classic
-{{< tabs name="other_kubectl_install" >}}
-{{< tab name="Snap" codelang="bash" >}}
-sudo snap install kubectl --classic
 
 kubectl version
-{{< /tab >}}
+```
-{{< tab name="Homebrew" codelang="bash" >}}
+{{% /tab %}}
+{{% tab name="Homebrew" %}}
+Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。
+```shell
 brew install kubectl
 
 kubectl version
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}
 
 ## macOSへkubectlをインストールする {#install-kubectl-on-macos}
@@ -130,7 +133,7 @@ kubectl version
 4. インストールしたバージョンが最新であることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 
 ### Homebrewを使用してmacOSへインストールする
@@ -151,7 +154,7 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用
 2. インストールしたバージョンが最新であることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 
 ### MacPortsを使用してmacOSへインストールする
@@ -168,7 +171,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
 2. インストールしたバージョンが最新であることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 
 ## Windowsへkubectlをインストールする {#install-kubectl-on-windows}
@@ -189,7 +192,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 {{< note >}}
 [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。
@@ -213,7 +216,7 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー
 2. インストールしたバージョンが最新であることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 
     {{< note >}}アップデートする際は、手順1に示した2つのコマンドを再実行してください。{{< /note >}}
@@ -236,7 +239,7 @@ Windowsへkubectlをインストールするために、[Chocolatey](https://cho
 2. インストールしたバージョンが最新であることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 
 3. ホームディレクトリへ移動してください:
@@ -278,7 +281,7 @@ Google Cloud SDKの一部として、kubectlをインストールすることも
 3. インストールしたバージョンが最新であることを確認してください:
 
     ```
-    kubectl version
+    kubectl version --client
     ```
 
 ## kubectlの設定を検証する
@@ -382,6 +385,27 @@ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コ
 bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2（macOSのデフォルト）用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降（Bashのバージョンが4.1またはそれより新しいことを指します）を使用することを前提とします。
 {{< /warning >}}
 
+### bashのアップグレード
+
+ここではBash 4.1以降の使用を前提としています。Bashのバージョンは下記のコマンドで調べることができます。
+
+```shell
+echo $BASH_VERSION
+```
+
+バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます。
+
+```shell
+brew install bash
+```
+
+シェルをリロードし、希望するバージョンを使用していることを確認してください。
+
+```shell
+echo $BASH_VERSION $SHELL
+```
+
+Homebrewは通常、`/usr/local/bin/bash`にインストールします。
 
 ### bash-completionをインストールする
 

content/ja/docs/tasks/tools/install-minikube.md

@@ -76,12 +76,22 @@ kubectlがインストールされていることを確認してください。
 
 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
 
-{{< note >}}
+Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。
-minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。
 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。
-noneドライバーを使用する場合は、[Docker](https://www.docker.com/products/docker-desktop)からdockerのaptインストールを使用することをおすすめします。
+
-dockerのsnapインストールは、minikubeでは機能しません。
+Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。
-{{< /note >}}
+[Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。
+
+{{< caution >}}
+`none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。
+`--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。
+{{< /caution >}}
+
+MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。
+
+{{< caution >}}
+`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。
+{{< /caution >}}
 
 ### パッケージを利用したMinikubeのインストール
 
@@ -106,6 +116,14 @@ sudo mkdir -p /usr/local/bin/
 sudo install minikube /usr/local/bin/
 ```
 
+### Homebrewを利用したMinikubeのインストール
+
+別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。
+
+```shell
+brew install minikube
+```
+
 {{% /tab %}}
 {{% tab name="macOS" %}}
 ### kubectlのインストール
@@ -185,6 +203,41 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window
 
 
 
+## インストールの確認
+
+ハイパーバイザーとMinikube両方のインストール成功を確認するため、以下のコマンドをローカルKubernetesクラスターを起動するために実行してください:
+
+{{< note >}}
+
+`minikube start`で`--vm-driver`の設定をするため、次の`<driver_name>`の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--vm-driver`値のすべてのリストは、[specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。
+
+{{< /note >}}
+
+```shell
+minikube start --vm-driver=<driver_name>
+```
+
+`minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。
+
+```shell
+minikube status
+```
+
+クラスターが起動していると、`minikube status`の出力はこのようになります。
+
+```
+host: Running
+kubelet: Running
+apiserver: Running
+kubeconfig: Configured
+```
+
+選択したハイパーバイザーでMinikubeが動作しているか確認した後は、そのままMinikubeを使い続けることもできます。また、クラスターを停止することもできます。クラスターを停止するためには、次を実行してください。
+
+```shell
+minikube stop
+```
+
 ## ローカル状態のクリーンアップ {#cleanup-local-state}
 
 もし以前に　Minikubeをインストールしていたら、以下のコマンドを実行します。

content/ja/docs/tutorials/_index.md

@@ -17,8 +17,6 @@ content_type: concept
 
 * [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)は、Kubernetesのシステムを理解し、基本的な機能を試すのに役立つ、詳細な対話式のチュートリアルです。
 
-* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-
 * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
 
 * [Hello Minikube](/ja/docs/tutorials/hello-minikube/)
@@ -29,7 +27,7 @@ content_type: concept
 
 ## ステートレスアプリケーション
 
-* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/docs/tutorials/stateless-application/expose-external-ip-address/)
+* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/ja/docs/tutorials/stateless-application/expose-external-ip-address/)
 
 * [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/docs/tutorials/stateless-application/guestbook/)
 

content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md

@@ -23,9 +23,10 @@ content_type: tutorial
 ## {{% heading "prerequisites" %}}
 
 
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
 * この例は、バージョン1.14以上での動作を確認しています。
-* [ConfigMapを使ったコンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。
+* [ConfigMapを使ったコンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。
 
 
 
@@ -70,7 +71,7 @@ kustomizationディレクトリを反映して、ConfigMapオブジェクトとP
 kubectl apply -k .
 ```
 
-Examine the created objects by
+作成されたオブジェクトを確認します
 ```shell
 > kubectl get -k .
 NAME                                        DATA   AGE
@@ -97,6 +98,11 @@ kubectl exec -it redis redis-cli
 2) "allkeys-lru"
 ```
 
+作成したPodを削除します:
+```shell
+kubectl delete pod redis
+```
+
 
 
 ## {{% heading "whatsnext" %}}
@@ -104,6 +110,3 @@ kubectl exec -it redis redis-cli
 
 * [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)について学ぶ
 
-
-
-

content/ja/docs/tutorials/hello-minikube.md

@@ -15,7 +15,7 @@ card:
 
 <!-- overview -->
 
-このチュートリアルでは、[Minikube](/docs/getting-started-guides/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。
+このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。
 
 {{< note >}}
 [Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。
@@ -81,11 +81,11 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
     kubectl get deployments
     ```
 
-    出力:
+    出力は下記のようになります:
 
-    ```shell
+    ```
-    NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
-    hello-node   1         1         1            1           1m
+    hello-node   1/1     1            1           1m
     ```
 
 3. Podを確認します:
@@ -93,9 +93,10 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
     ```shell
     kubectl get pods
     ```
-    出力:
 
-    ```shell
+    出力は下記のようになります:
+
+    ```
     NAME                          READY     STATUS    RESTARTS   AGE
     hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
     ```
@@ -116,7 +117,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
 
 ## Serviceの作成
 
-通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてポッドを公開する必要があります。
+通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。
 
 1. `kubectl expose` コマンドを使用してPodをインターネットに公開します:
 
@@ -132,9 +133,9 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
     kubectl get services
     ```
 
-    出力:
+    出力は下記のようになります:
 
-    ```shell
+    ```
     NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
     hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
     kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m
@@ -151,13 +152,13 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
 
 4. Katacoda環境のみ：ターミナル画面上部の+ボタンをクリックして **Select port to view on Host 1** をクリックしてください。
 
-5. Katacoda環境のみ：`30369`(Service出力に表示されている`8080`の反対側のポートを参照)を入力し、クリックしてください。
+5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。
 
     "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。
 
 ## アドオンの有効化
 
-Minikubeはビルトインのアドオンがあり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。
+Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="addons" >}}があり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。
 
 1. サポートされているアドオンをリストアップします:
 
@@ -165,39 +166,41 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ
     minikube addons list
     ```
 
-    出力:
+    出力は下記のようになります:
 
-    ```shell
+    ```
     addon-manager: enabled
-    coredns: disabled
     dashboard: enabled
     default-storageclass: enabled
     efk: disabled
     freshpod: disabled
-    heapster: disabled
+    gvisor: disabled
+    helm-tiller: disabled
     ingress: disabled
-    kube-dns: enabled
+    ingress-dns: disabled
+    logviewer: disabled
     metrics-server: disabled
     nvidia-driver-installer: disabled
     nvidia-gpu-device-plugin: disabled
     registry: disabled
     registry-creds: disabled
     storage-provisioner: enabled
+    storage-provisioner-gluster: disabled
     ```
 
-2. ここでは例として`heapster`のアドオンを有効化します:
+2. ここでは例として`metrics-server`のアドオンを有効化します:
 
     ```shell
-    minikube addons enable heapster
+    minikube addons enable metrics-server
     ```
 
-    出力:
+    出力は下記のようになります:
 
-    ```shell
+    ```
-    heapster was successfully enabled
+    metrics-server was successfully enabled
     ```
 
-3. 作成されたポッドとサービスを確認します:
+3. 作成されたPodとサービスを確認します:
 
     ```shell
     kubectl get pod,svc -n kube-system
@@ -205,33 +208,37 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ
 
     出力:
 
-    ```shell
+    ```
     NAME                                        READY     STATUS    RESTARTS   AGE
-    pod/heapster-9jttx                          1/1       Running   0          26s
+    pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
+    pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
+    pod/metrics-server-67fb648c5                1/1       Running   0          26s
+    pod/etcd-minikube                           1/1       Running   0          34m
     pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
     pod/kube-addon-manager-minikube             1/1       Running   0          34m
-    pod/kube-dns-6dcb57bcc8-gv7mw               3/3       Running   0          34m
+    pod/kube-apiserver-minikube                 1/1       Running   0          34m
-    pod/kubernetes-dashboard-5498ccf677-cgspw   1/1       Running   0          34m
+    pod/kube-controller-manager-minikube        1/1       Running   0          34m
+    pod/kube-proxy-rnlps                        1/1       Running   0          34m
+    pod/kube-scheduler-minikube                 1/1       Running   0          34m
     pod/storage-provisioner                     1/1       Running   0          34m
 
     NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
-    service/heapster               ClusterIP   10.96.241.45    <none>        80/TCP              26s
+    service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
     service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
-    service/kubernetes-dashboard   NodePort    10.109.29.1     <none>        80:30000/TCP        34m
     service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
     service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
     ```
 
-4. `heapster`を無効化します:
+4. `metrics-server`を無効化します:
 
     ```shell
-    minikube addons disable heapster
+    minikube addons disable metrics-server
     ```
 
-    出力:
+    出力は下記のようになります:
 
-    ```shell
+    ```
-    heapster was successfully disabled
+    metrics-server was successfully disabled
     ```
 
 ## クリーンアップ

content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html

@@ -77,14 +77,14 @@ weight: 10
 
             <div class="col-md-4">
                 <div class="content__box content__box_fill">
-                    <p><i>マスターはクラスターを管理するために、ノードは実行中のアプリケーションをホストするために使用されます。</i></p>
+                    <p><i>マスターは実行中のアプリケーションをホストするために使用されるノードとクラスターを管理します。</i></p>
                 </div>
             </div>
         </div>
 
         <div class="row">
             <div class="col-md-8">
-                <p>Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスターのノードで実行されるようにスケジュールします。<b>ノードは、マスターが公開しているKubernetes APIを使用してマスターと通信します。</b>エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。</p>
+                <p>Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスターのノードで実行されるようにスケジュールします。<b>ノードは、マスターが公開している<a href="/docs/concepts/overview/kubernetes-api/">Kubernetes API</a>を使用してマスターと通信します。</b>エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。</p>
 
                 <p>Kubernetesクラスターは、物理マシンまたは仮想マシンのどちらにも配置できます。Kubernetes開発を始めるためにMinikubeを使うことができます。Minikubeは、ローカルマシン上にVMを作成し、1つのノードのみを含む単純なクラスターをデプロイする軽量なKubernetes実装です。Minikubeは、Linux、macOS、およびWindowsシステムで利用可能です。Minikube CLIは、起動、停止、ステータス、削除など、クラスターを操作するための基本的なブートストラップ操作を提供します。ただし、このチュートリアルでは、Minikubeがプリインストールされた状態で提供されているオンラインのターミナルを使用します。</p>
 

content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html

@@ -17,6 +17,13 @@ weight: 20
 
     <main class="content katacoda-content">
 
+        <div class="row">
+            <div class="col-md-12">
+                <p>
+                    Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Podの詳細はこちらです。</a>。
+                </p>
+            </div>
+        </div>
         <br>
         <div class="katacoda">
             <div class="katacoda__alert">

content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html

@@ -79,14 +79,9 @@ weight: 10
 					<li>バージョンタグを埋め込む</li>
 					<li>タグを使用してオブジェクトを分類する</li>
 				</ul>
+			</div>
 
 		</div>
-			<div class="col-md-4">
-				<div class="content__box content__box_fill">
-					<p><i>kubectlの<br> <code> --expose </code>を使用して、Deploymentの作成と同時にServiceを作成できます。</i></p>
-				</div>
-			</div>
-		</div>
 
 		<br>
 

content/ja/docs/tutorials/kubernetes-basics/update/update-intro.html

@@ -10,7 +10,6 @@ weight: 10
 <body>
 
     <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
-<link href="https://fonts.googleapis.com/css?family=Roboto+Slab:300,400,700" rel="stylesheet">
 
 <div class="layout" id="top">
 

content/ja/examples/configmap/configmap-multikeys.yaml

@@ -0,0 +1,8 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: special-config
+  namespace: default
+data:
+  SPECIAL_LEVEL: very
+  SPECIAL_TYPE: charm

content/ja/examples/configmap/configmaps.yaml

@@ -0,0 +1,15 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: special-config
+  namespace: default
+data:
+  special.how: very
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: env-config
+  namespace: default
+data:
+  log_level: INFO

content/ja/examples/pods/pod-configmap-env-var-valueFrom.yaml

@@ -0,0 +1,21 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dapi-test-pod
+spec:
+  containers:
+    - name: test-container
+      image: k8s.gcr.io/busybox
+      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
+      env:
+        - name: SPECIAL_LEVEL_KEY
+          valueFrom:
+            configMapKeyRef:
+              name: special-config
+              key: SPECIAL_LEVEL
+        - name: SPECIAL_TYPE_KEY
+          valueFrom:
+            configMapKeyRef:
+              name: special-config
+              key: SPECIAL_TYPE
+  restartPolicy: Never

content/ja/examples/pods/pod-configmap-envFrom.yaml

@@ -0,0 +1,13 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dapi-test-pod
+spec:
+  containers:
+    - name: test-container
+      image: k8s.gcr.io/busybox
+      command: [ "/bin/sh", "-c", "env" ]
+      envFrom:
+      - configMapRef:
+          name: special-config
+  restartPolicy: Never

content/ja/examples/pods/pod-configmap-volume-specific-key.yaml

@@ -0,0 +1,20 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dapi-test-pod
+spec:
+  containers:
+    - name: test-container
+      image: k8s.gcr.io/busybox
+      command: [ "/bin/sh","-c","cat /etc/config/keys" ]
+      volumeMounts:
+      - name: config-volume
+        mountPath: /etc/config
+  volumes:
+    - name: config-volume
+      configMap:
+        name: special-config
+        items:
+        - key: SPECIAL_LEVEL
+          path: keys
+  restartPolicy: Never

content/ja/examples/pods/pod-configmap-volume.yaml

@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dapi-test-pod
+spec:
+  containers:
+    - name: test-container
+      image: k8s.gcr.io/busybox
+      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
+      volumeMounts:
+      - name: config-volume
+        mountPath: /etc/config
+  volumes:
+    - name: config-volume
+      configMap:
+        # コンテナに追加するファイルを含むConfigMapの名前を提供する
+        name: special-config
+  restartPolicy: Never