Merge branch 'master' into dev-1.17-ja.3

2020-08-11 00:41:43 +09:00
parent 00808bf43c d5cc23c0d3
commit e1d84efeca
1675 changed files with 66347 additions and 33478 deletions
@@ -19,14 +19,14 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使

 一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。

-* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
+* **Kubernetes Master**: [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
 * クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。
-  * **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。
-  * **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。
+  * **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。
+  * **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。

-## Kubernetesオブジェクト
+## Kubernetesオブジェクト {#kubernetes-objects}

-Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
+Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)をご覧ください。

 基本的なKubernetesのオブジェクトは次のとおりです。

@@ -43,7 +43,7 @@ Kubernetesには、[コントローラー](/docs/concepts/architecture/controlle
 * [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
 * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)

-## Kubernetesコントロールプレーン
+## Kubernetesコントロールプレーン {#kubernetes-control-plane}

 Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。

@@ -1,4 +1,4 @@
 ---
-title: "Kubernetesのアーキテクチャ"
+title: "クラスターのアーキテクチャ"
 weight: 30
 ---
@@ -1,14 +1,14 @@
 ---
 title: クラウドコントローラーマネージャーとそのコンセプト
 content_type: concept
-weight: 30
+weight: 40
 ---

 <!-- overview -->

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

-クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
+クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。

 このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。

@@ -52,7 +52,7 @@ CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつ
 ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。
 {{< /note >}}

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

 これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。

@@ -79,11 +79,11 @@ CCMの大半の機能は、KCMから派生しています。前セクション

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

-ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
+ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。

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

-サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
+サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。

 ### 2. Kubelet

@@ -93,7 +93,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション

 ## プラグインメカニズム

-クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
+クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。

 上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。

@@ -223,13 +223,18 @@ rules:

 下記のクラウドプロバイダーがCCMを実装しています:

-* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)
 * [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager)
 * [Linode](https://github.com/linode/linode-cloud-controller-manager)
+* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
+* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)
+

 ## クラスター管理

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

 <!-- overview -->

-本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
-この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
+本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。
+この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。



@@ -16,8 +16,8 @@ weight: 20

 ## クラスターからマスターへの通信

-クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。
-一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。
+クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。
+一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
 特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。

 ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
@@ -26,15 +26,15 @@ kubeletのクライアント証明書を自動プロビジョニングする方

 APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。

-`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。
+`kubernetes`サービスには(すべてのネームスペースで)、APIサーバー上のHTTPSエンドポイントに(kube-proxy経由で)リダイレクトされる仮想IPアドレスが設定されています。

 マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。

-その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
+その結果、クラスター(ノードとそのノードで実行されているPod)からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。

 ## マスターからクラスターへの通信

-マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。
+マスター(APIサーバー)からクラスターへの通信には、2つの主要な通信経路があります。
 1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。
 2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。

@@ -43,7 +43,7 @@ APIサーバーに接続したいPodは、サービスアカウントを利用
 APIサーバーからkubeletへの接続は以下の目的で使用されます:

  * Podのログを取得する
-  * 実行中のPodに（kubectlを通して）接続する
+  * 実行中のPodに(kubectlを通して)接続する
  * kubeletのポート転送機能を提供する

 これらの接続は、kubeletのHTTPSエンドポイントで終了します。
@@ -64,7 +64,7 @@ API URL内のノード、Pod、またはサービス名に`https:`を付ける
 ### SSHトンネル

 Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。
-この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
+この設定では、APIサーバーはクラスター内の各ノード(ポート22でlistenしているsshサーバーに接続)へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
 このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。

 SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
@@ -43,7 +43,6 @@ kubectl describe node <ノード名>

 | ノードのCondition | 概要 |
 |----------------|-------------|
-| `OutOfDisk`    | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 |
 | `Ready`        | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
 | `MemoryPressure`    | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
 | `PIDPressure`    | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
@@ -69,18 +68,9 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`

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

-バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。
-同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。
+ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。

-ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。
-上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。
-
-{{< caution >}}
-
-この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。
-この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。
-
-{{< /caution >}}
+スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。

 ### CapacityとAllocatable {#capacity}

@@ -91,7 +81,7 @@ allocatableブロックは、通常のPodによって消費されるノード上

 CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。

-### Info
+### Info {#info}

 カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。
 この情報はノードからkubeletを通じて取得されます。
@@ -114,6 +104,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で
 ```

 Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
+Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。

 {{< note >}}
 Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。
@@ -136,9 +127,19 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ
 ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。
 ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。

-バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。
+#### ハートビート
+ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
+２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
+各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
+Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
+
+kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
+
+- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです）
+- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
+
+#### 信頼性

-NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。

 Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため）
 バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。
@@ -201,6 +202,11 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ
 これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。
 {{< /note >}}

+{{< caution >}}
+`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
+サービスコントローラーの副次的な効果をもたらします。これにより、ロードバランサトラフィックの流入をcordonされたノードから効率的に除去する事ができます。
+{{< /caution >}}
+
 ### ノードのキャパシティ

 ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。
@@ -213,6 +219,11 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な

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

+## ノードのトポロジー
+
+{{< feature-state state="alpha" >}}
+`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、
+kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。

 ## APIオブジェクト

@@ -220,3 +231,7 @@ NodeはKubernetesのREST APIにおけるトップレベルのリソースです
 [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).


+## {{% heading "whatsnext" %}}
+
+* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。
+* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
@@ -16,13 +16,13 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る

 ガイドを選択する前に、いくつかの考慮事項を挙げます。

- - ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか? あなたのニーズにあったディストリビューションを選択してください。
+ - ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか？あなたのニーズにあったディストリビューションを選択してください。
 - **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。
- - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**?
- - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
- - Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
+ - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**？
+ - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド(IaaS)** でしょうか？Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
+ - Kubernetesを **「ベアメタル」なハードウェア**上で稼働させますか？それとも**仮想マシン(VMs)** 上で稼働させますか？
 - **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。
- - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
+ - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか？もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
 - クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。

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

 [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)は、Kubernetesクラスター向けの統合されたAWS Virtual Private Cloud(VPC)ネットワーキングを提供します。このCNIプラグインは、高いスループットと可用性、低遅延、および最小のネットワークジッタを提供します。さらに、ユーザーは、Kubernetesクラスターを構築するための既存のAWS VPCネットワーキングとセキュリティのベストプラクティスを適用できます。これには、ネットワークトラフィックの分離にVPCフローログ、VPCルーティングポリシー、およびセキュリティグループを使用する機能が含まれます。

-このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interfaces（ENI）を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。
+このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interface(ENI)を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。

 さらに、このCNIは[ネットワークポリシーの適用のためにCalico](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/calico.html)と一緒に実行できます。AWS VPC CNIプロジェクトは、[GitHubのドキュメント](https://github.com/aws/amazon-vpc-cni-k8s)とともにオープンソースで公開されています。

@@ -89,7 +89,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/
 [Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node.

 Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
- 
+

 ### Big Cloud Fabric from Big Switch Networks

@@ -289,4 +289,3 @@ to run, and in both cases, the network provides one IP address per pod - as is s

 ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。

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

 <!-- overview -->

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

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

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

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

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

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

 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。
 以下のようなラベルが該当します。

-* `kubernetes.io/hostname`
-* `failure-domain.beta.kubernetes.io/zone`
-* `failure-domain.beta.kubernetes.io/region`
-* `beta.kubernetes.io/instance-type`
-* `kubernetes.io/os`
-* `kubernetes.io/arch`
+* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
+* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
+* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
+* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
+* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
+* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
+* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
+* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
+* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)

 {{< note >}}
 これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。
@@ -88,131 +91,127 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー
 これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。

 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
-Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。
+Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。

-1. NodeRestrictionを使用するため、Kubernetesのバージョンがv1.11以上であること。
-2. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっていること。
-3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
+1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。
+2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。

-## Affinity と Anti-Affinity {#affinity-and-anti-affinity}
+## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity}

 `nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。
-Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。
+アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。
 拡張機能は以下の通りです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

 {{< note >}}
-Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。
-例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
+Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。
+言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
 それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。
 {{< /note >}}

-Node Affinityと同様に、Pod AffinityとPod Anti-Affinityにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
-前述のNode Affinityのセクションを参照してください。
-`requiredDuringSchedulingIgnoredDuringExecution`を指定するAffinityの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。
-また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するAnti-Affinityの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。
+Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
+前述のNodeアフィニティのセクションを参照してください。
+`requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。
+また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。

-Inter-Pod Affinityは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Inter-Pod Anti-Affinityは、`podAntiAffinity`で指定します。
+Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。

-#### Pod Affinityを使用したPodの例
+#### Podアフィニティを使用したPodの例

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

-このPodのAffifnityは、Pod AffinityとPod Anti-Affinityを1つずつ定義しています。
+このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。
 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。
-Pod Affinityは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
+Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
 Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
-Pod Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
+Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
 (`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
-Pod AffinityとPod Anti-Affinityや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
+PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。

-Pod AffinityとPod Anti-Affinityで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
+PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。

 原則として、`topologyKey`には任意のラベルとキーが使用できます。
 しかし、パフォーマンスやセキュリティの観点から、以下の制約があります:

-1. Affinityと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しないことは許可されていません。
-2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
+1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。
+2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。
-3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しなかった場合、"全てのトポロジー"と解釈されます("全てのトポロジー"とは、ここでは`kubernetes.io/hostname`、`failure-domain.beta.kubernetes.io/zone`、`failure-domain.beta.kubernetes.io/region`を合わせたものを意味します)。
+3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。
 4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。

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

-`requiredDuringSchedulingIgnoredDuringExecution`が指定されたAffinityとAnti-Affinityでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 
+`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。


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

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


@@ -325,7 +324,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
 ##### 同じNodeに共存させない場合

 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。
-同様の方法で、Anti-Affinityを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。
+同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。


 ## nodeName
@@ -338,7 +337,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
 `nodeName`を使用することによる制約は以下の通りです:

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

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

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

-[Node Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
-[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
-には、Taintsの要点に関して様々な背景が紹介されています。
-
+[Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
+[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
+のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。

+一度PodがNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。
+[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。
@@ -0,0 +1,191 @@
+---
+title: ConfigMap
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+{{< glossary_definition term_id="configmap" prepend="ConfigMapは、" length="all" >}}
+
+{{< caution >}}
+ConfigMapは機密性や暗号化を提供しません。保存したいデータが機密情報である場合は、ConfigMapの代わりに{{< glossary_tooltip text="Secret" term_id="secret" >}}を使用するか、追加の(サードパーティー)ツールを使用してデータが非公開になるようにしてください。
+{{< /caution >}}
+
+<!-- body -->
+
+## 動機
+
+アプリケーションのコードとは別に設定データを設定するには、ConfigMapを使用します。
+
+たとえば、アプリケーションを開発していて、(開発用時には)自分のコンピューター上と、(実際のトラフィックをハンドルするときは)クラウド上とで実行することを想像してみてください。あなたは、`DATABASE_HOST`という名前の環境変数を使用するコードを書きます。ローカルでは、この変数を`localhost`に設定します。クラウド上では、データベースコンポーネントをクラスター内に公開するKubernetesの{{< glossary_tooltip text="Service" term_id="service" >}}を指すように設定します。
+
+こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。
+
+## ConfigMapオブジェクト
+
+ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapにはアイテム(キー)と値を保存するための`data`セクションがあります。
+
+ConfigMapの名前は、有効な[DNSのサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
+
+## ConfigMapとPod
+
+ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodの`spec`を書くことができます。このとき、PodとConfigMapは同じ{{< glossary_tooltip text="名前空間" term_id="namespace" >}}内に存在する必要があります。
+
+以下に、ConfigMapの例を示します。単一の値を持つキーと、Configuration形式のデータ片のような値を持つキーがあります。
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: game-demo
+data:
+  # プロパティーに似たキー。各キーは単純な値にマッピングされている
+  player_initial_lives: "3"
+  ui_properties_file_name: "user-interface.properties"
+  #
+  # ファイルに似たキー
+  game.properties: |
+    enemy.types=aliens,monsters
+    player.maximum-lives=5
+  user-interface.properties: |
+    color.good=purple
+    color.bad=yellow
+    allow.textmode=true
+```
+
+ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。
+
+1. コマンドライン引数をコンテナのエントリーポイントに渡す
+1. 環境変数をコンテナに渡す
+1. 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る
+1. Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する
+
+これらのさまざまな方法は、利用するデータをモデル化するのに役立ちます。最初の3つの方法では、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}がPodのコンテナを起動する時にConfigMapのデータを使用します。
+
+4番目の方法では、ConfigMapとそのデータを読み込むためのコードを自分自身で書く必要があります。しかし、Kubernetes APIを直接使用するため、アプリケーションはConfigMapがいつ変更されても更新イベントを受信でき、変更が発生したときにすぐに反応できます。この手法では、Kubernetes APIに直接アクセスすることで、別の名前空間にあるConfigMapにもアクセスできます。
+
+以下に、Podを設定するために`game-demo`から値を使用するPodの例を示します。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: configmap-demo-pod
+spec:
+  containers:
+    - name: demo
+      image: game.example/demo-game
+      env:
+        # 環境変数を定義します。
+        - name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い
+                                     # 大文字が使われていることに着目してください。
+          valueFrom:
+            configMapKeyRef:
+              name: game-demo           # この値を取得するConfigMap。
+              key: player_initial_lives # 取得するキー。
+        - name: UI_PROPERTIES_FILE_NAME
+          valueFrom:
+            configMapKeyRef:
+              name: game-demo
+              key: ui_properties_file_name
+      volumeMounts:
+      - name: config
+        mountPath: "/config"
+        readOnly: true
+  volumes:
+    # Podレベルでボリュームを設定し、Pod内のコンテナにマウントします。
+    - name: config
+      configMap:
+        # マウントしたいConfigMapの名前を指定します。
+        name: game-demo
+        # ファイルとして作成するConfigMapのキーの配列
+        items:
+        - key: "game.properties"
+          path: "game.properties"
+        - key: "user-interface.properties"
+          path: "user-interface.properties"
+```
+
+ConfigMapは1行のプロパティの値と複数行のファイルに似た形式の値を区別しません。問題となるのは、Podや他のオブジェクトによる値の使用方法です。
+
+この例では、ボリュームを定義して、`demo`コンテナの内部で`/config`にマウントしています。これにより、ConfigMap内には4つのキーがあるにもかかわらず、2つのファイル`/config/game.properties`および`/config/user-interface.properties`だけが作成されます。
+
+これは、Podの定義が`volumes`セクションで`items`という配列を指定しているためです。もし`items`の配列を完全に省略すれば、ConfigMap内の各キーがキーと同じ名前のファイルになり、4つのファイルが作成されます。
+
+## ConfigMapを使う
+
+ConfigMapは、データボリュームとしてマウントできます。ConfigMapは、Podへ直接公開せずにシステムの他の部品として使うこともできます。たとえば、ConfigMapには、システムの他の一部が設定のために使用するデータを保存できます。
+
+{{< note >}}
+ConfigMapの最も一般的な使い方では、同じ名前空間にあるPod内で実行されているコンテナに設定を構成します。ConfigMapを独立して使用することもできます。
+
+たとえば、ConfigMapに基づいて動作を調整する{{< glossary_tooltip text="アドオン" term_id="addons" >}}や{{< glossary_tooltip text="オペレーター" term_id="operator-pattern" >}}を見かけることがあるかもしれません。
+{{< /note >}}
+
+### ConfigMapをPodからファイルとして使う
+
+ConfigMapをPod内のボリュームで使用するには、次のようにします。
+
+1. ConfigMapを作成するか、既存のConfigMapを使用します。複数のPodから同じConfigMapを参照することもできます。
+1. Podの定義を修正して、`.spec.volumes[]`以下にボリュームを追加します。ボリュームに任意の名前を付け、`.spec.volumes[].configMap.name`フィールドにConfigMapオブジェクトへの参照を設定します。
+1. ConfigMapが必要な各コンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して、`.spec.containers[].volumeMounts[].mountPath`には、ConfigMapのデータを表示したい未使用のディレクトリ名を指定します。
+1. イメージまたはコマンドラインを修正して、プログラムがそのディレクトリ内のファイルを読み込むように設定します。ConfigMapの`data`マップ内の各キーが、`mountPath`以下のファイル名になります。
+
+以下は、ボリューム内にConfigMapをマウントするPodの例です。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+  - name: mypod
+    image: redis
+    volumeMounts:
+    - name: foo
+      mountPath: "/etc/foo"
+      readOnly: true
+  volumes:
+  - name: foo
+    configMap:
+      name: myconfigmap
+```
+
+使用したいそれぞれのConfigMapごとに、`.spec.volumes`内で参照する必要があります。
+
+Pod内に複数のコンテナが存在する場合、各コンテナにそれぞれ別の`volumeMounts`のブロックが必要ですが、`.spec.volumes`はConfigMapごとに1つしか必要ありません。
+
+#### マウントしたConfigMapの自動的な更新
+
+ボリューム内で現在使用中のConfigMapが更新されると、射影されたキーも最終的に(eventually)更新されます。kubeletは定期的な同期のたびにマウントされたConfigMapが新しいかどうか確認します。しかし、kubeletが現在のConfigMapの値を取得するときにはローカルキャッシュを使用します。キャッシュの種類は、[KubeletConfiguration構造体](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)の中の`ConfigMapAndSecretChangeDetectionStrategy`フィールドで設定可能です。ConfigMapは、監視(デフォルト)、ttlベース、またはすべてのリクエストを直接APIサーバーへ単純にリダイレクトする方法のいずれかによって伝搬されます。その結果、ConfigMapが更新された瞬間から、新しいキーがPodに射影されるまでの遅延の合計は、最長でkubeletの同期期間+キャッシュの伝搬遅延になります。ここで、キャッシュの伝搬遅延は選択したキャッシュの種類に依存します(監視の伝搬遅延、キャッシュのttl、または0に等しくなります)。
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+Kubernetesのアルファ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。
+
+- アプリケーションの停止を引き起こす可能性のある予想外の(または望まない)変更を防ぐことができる
+- ConfigMapをイミュータブルにマークして監視を停止することにより、kube-apiserverへの負荷を大幅に削減し、クラスターの性能が向上する
+
+この機能を使用するには、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretやConfigMapの`immutable`フィールドを`true`に設定してください。次に例を示します。
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+{{< note >}}
+一度ConfigMapやSecretがイミュータブルに設定すると、この変更を元に戻したり、`data`フィールドのコンテンツを変更することは*できません*。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。
+{{< /note >}}
+
+## {{% heading "whatsnext" %}}
+
+* [Secret](/docs/concepts/configuration/secret/)について読む。
+* [Podを構成してConfigMapを使用する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読む。
+* コードを設定から分離する動機を理解するために[The Twelve-Factor App](https://12factor.net/ja/)を読む。
@@ -27,11 +27,11 @@ weight: 10
 - よりよいイントロスペクションのために、オブジェクトの説明をアノテーションに入れましょう。


-## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob
+## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob {#naked-pods-vs-replicasets-deployments-and-jobs}

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

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

 ## Service

@@ -81,7 +81,7 @@ weight: 10
 - `imagePullPolicy: Never`: 常にローカルでイメージを探そうとします。ない場合にもイメージはpullしません。

 {{< note >}}
-コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます(例:`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。
+コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます。`<image-name>:<tag>`を`<image-name>@<digest>`で置き換えます(例:`image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。
 {{< /note >}}

 {{< note >}}
@@ -89,7 +89,7 @@ weight: 10
 {{< /note >}}

 {{< note >}}
-ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージが既に存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。
+ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージがすでに存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。
 {{< /note >}}

 ## kubectlの使い方
@@ -30,7 +30,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多

 `PreStop`

-このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナが既に終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
+このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
 ハンドラーにパラメーターは渡されません。

@@ -26,11 +26,10 @@ RuntimeClassはコンテナランタイムの設定を選択するための機

 ### セットアップ

-RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、[Feature
-Gates](/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
-その`RuntimeClass`のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。
+RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
+その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。

-1. ノード上でCRI実装を設定する。（ランタイムに依存）
+1. ノード上でCRI実装を設定する。(ランタイムに依存)
 2. 対応するRuntimeClassリソースを作成する。

 #### 1. ノード上でCRI実装を設定する。
@@ -39,8 +38,8 @@ RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI
 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。

 {{< note >}}
-RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。
-設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/ja/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。
+RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのノードがコンテナランタイムに関して同じ方法で構成されていることを意味します)。
+設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。
 {{< /note >}}

 RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。
@@ -60,6 +59,9 @@ metadata:
 handler: myconfiguration  # 対応するCRI設定
 ```

+RuntimeClassオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)に従う必要があります。
+
+
 {{< note >}}
 RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター管理者のみに制限されることを推奨します。
 これはたいていデフォルトで有効となっています。さらなる詳細に関しては[Authorization
@@ -94,7 +96,7 @@ CRIランタイムのセットアップに関するさらなる詳細は、[CRI

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

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

 ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。
 正しいハンドラーは、その`runtime`セクションで設定されます。
@@ -106,20 +108,49 @@ Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラ
 containerdの設定に関する詳細なドキュメントは下記を参照してください。  
 https://github.com/containerd/cri/blob/master/docs/config.md

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

-ランタイムハンドラーは、`/etc/crio/crio.conf`にあるcri-oの設定ファイルにより設定されます。
+ランタイムハンドラーは、`/etc/crio/crio.conf`にあるCRI-Oの設定ファイルにより設定されます。
 正しいハンドラーは[crio.runtime
-table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。
+table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。

 ```
 [crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"
 ```

-cri-oの設定に関する詳細なドキュメントは下記を参照してください。  
-https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
+CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。

+[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
+
+### スケジューリング {#scheduling}
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。
+このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。
+スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです)
+
+特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。
+RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。
+もし設定が衝突した場合は、Pod作成は拒否されるでしょう。
+
+もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。
+`nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。
+
+ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。
+
+[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/
+
+### Podオーバーヘッド
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。
+`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです)
+
+PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。
+このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。

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

@@ -140,3 +171,9 @@ RuntimeClassのβ版の機能は、下記の変更点を含みます。
 - `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。


+### 参考文献
+
+- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
+- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む
+- [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
@@ -1,7 +1,7 @@
 ---
 title: カスタムリソース
 content_type: concept
-weight: 20
+weight: 10
 ---

 <!-- overview -->
@@ -24,7 +24,7 @@ weight: 20

 カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供します。カスタムリソースを *カスタムコントローラー* と組み合わせることで、カスタムリソースは真の _宣言的API_ を提供します。

-[宣言的API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesオブジェクトを理解する)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。
+[宣言的API](/ja/docs/concepts/overview/kubernetes-api/)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。
 コントローラーは、構造化データをユーザーが指定したあるべき状態と解釈し、その状態を管理し続けます。

 稼働しているクラスターのライフサイクルとは無関係に、カスタムコントローラーをデプロイ、更新することが可能です。カスタムコントローラーはあらゆるリソースと連携できますが、カスタムリソースと組み合わせると特に効果を発揮します。[オペレーターパターン](https://coreos.com/blog/introducing-operators.html)は、カスタムリソースとカスタムコントローラーの組み合わせです。カスタムコントローラーにより、特定アプリケーションのドメイン知識を、Kubernetes APIの拡張に変換することができます。
@@ -67,7 +67,7 @@ APIが宣言的ではない兆候として、次のものがあります:
 - APIをオブジェクトとして簡単に表現できない
 - 停止している処理を処理ID、もしくは処理オブジェクトで表現することを選択している

-## ConfigMapとカスタムリソースのどちらを使うべきか?
+## ConfigMapとカスタムリソースのどちらを使うべきか？

 下記のいずれかに該当する場合は、ConfigMapを使ってください:

@@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの

 Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。

-アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
+アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。

 CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。

@@ -108,6 +108,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類
 ## CustomResourceDefinition

 [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。
+CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。

 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。

@@ -115,7 +116,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類

 ## APIサーバーアグリゲーション

-通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、また[CRD](#customresourcedefinition)を通じて、同じ方法でカスタムリソースも管理できます。
+通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。

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

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

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

 ### 一般的な機能

@@ -174,7 +175,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
 | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック |
 | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 |
 | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 |
-| 未設定 vs 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる |
+| 未設定 対 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる |
 | クライアントライブラリーの生成 | Kubernetesは、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 |
 | ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 |

@@ -184,7 +185,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ

 ### サードパーティのコードと新しい障害点

-CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが（たとえば、サードパーティのコードをAPIサーバーで実行することによって）、パッケージ（たとえば、チャート）またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。
+CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが(たとえば、サードパーティのコードをAPIサーバーで実行することによって)、パッケージ(たとえば、Chart)またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。

 アグリゲートAPIサーバーのインストールすると、常に新しいDeploymentが付いてきます。

@@ -220,5 +221,3 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl

 * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ
 * [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ
-
-
@@ -32,7 +32,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています

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

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

 ## エクステンション

@@ -42,7 +42,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
 ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。
 結果として、ほとんどのKubernetesユーザーは既存のエクステンションを使えばよいため、新しいエクステンションを書く必要は無いと言えます。

-## エクステンションパターン
+## エクステンションパターン {#extension-patterns}

 Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。
 Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。
@@ -57,8 +57,8 @@ Kubernetes上でうまく動くクライアントプログラムを書くため
 呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。

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

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

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

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

-カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI（例、Pod）の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。
+カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。

 ### APIアクセスエクステンション

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

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

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

 ### 認証

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

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

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

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

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

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

-スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
+スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラーエクステンション)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。



@@ -24,7 +24,7 @@ Kubernetes上でワークロードを稼働させている人は、しばしば
 ## Kubernetesにおけるオペレーター

 Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。
-ワークロードのデプロイ及び稼働を自動化するためにKubernetesを使うことができます。 *更に* Kubernetesがそれをどのように行うかの自動化も可能です。
+ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。

 Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。
 オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
@@ -67,7 +67,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー
  * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
  * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。

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

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

@@ -116,6 +116,6 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ

 * [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ
 * [コントローラー](/docs/concepts/architecture/controller/)について学ぶ
-* [kube-scheduler](/ja/docs/concepts/scheduling/kube-scheduler/)について学ぶ
+* [kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ
 * etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む

@@ -3,7 +3,7 @@ reviewers:
 title: Kubernetes API
 content_type: concept
 weight: 30
-card: 
+card:
  name: concepts
  weight: 30
 ---
@@ -16,7 +16,7 @@ APIエンドポイント、リソースタイプ、そしてサンプルは[API

 APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。

-Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することが出来ます。 
+Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。

 また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。

@@ -30,7 +30,7 @@ Kubernetesそれ自身は複数のコンポーネントから構成されてお

 我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。

-何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md)に詳解されています。
+何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。

 ## OpenAPIとSwaggerの定義

@@ -41,10 +41,10 @@ Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポ

 ヘッダ | 設定可能な値
 ------ | ---------------
-Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` （デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません）
-Accept-Encoding | `gzip` （このヘッダーを送信しないことも許容されています）
+Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません)
+Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています)

-1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
+1.14より前のバージョンでは、フォーマット分離エンドポイント(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。

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

@@ -57,7 +57,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
 Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。

 また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。
-このエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
+このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。

 ## APIバージョニング

@@ -67,16 +67,16 @@ APIが、システムリソースと動作について明確かつ一貫した

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

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

- アルファレベル（版）:
-  - バージョン名に`alpha`を含みます（例、`v1alpha1`）。
+- アルファレベル(版):
+  - バージョン名に`alpha`を含みます(例、`v1alpha1`)。
  - バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。
  - アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。
  - ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。
  - バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。
- ベータレベル（版）:
-  - バージョン名に`beta`を含みます（例、`v2beta3`）。
+- ベータレベル(版):
+  - バージョン名に`beta`を含みます(例、`v2beta3`)。
  - コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。
  - 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。
  - オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。
@@ -93,24 +93,24 @@ APIグループは、RESTのパスとシリアライズされたオブジェク

 現在、いくつかのAPIグループが利用されています:

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

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

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

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

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

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

-重要: APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。
+{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}}

-## APIグループのリソースの有効化
-
-DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。
-その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。
+## APIグループextensions/v1beta1に含まれる特定のリソースの有効化

+APIグループ`extensions/v1beta1`に含まれるDaemonSets、Deployments、StatefulSet、NetworkPolicies、PodSecurityPolicies、ReplicaSetsはデフォルトで無効にされています。
+例えば、deploymentとdaemonsetを有効にするには、`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`と設定します。

+{{< note >}}リソースを個別に有効化、無効化することは歴史的な理由によりAPIグループ`extensions/v1beta1`に含まれるリソースに限りサポートされています。{{< /note >}}
@@ -1,8 +1,11 @@
 ---
+reviewers:
 title: Kubernetesとは何か？
+description: >
+  Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
 content_type: concept
 weight: 10
-card: 
+card:
  name: concepts
  weight: 10
 ---
@@ -12,94 +15,76 @@ card:


 <!-- body -->
-Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースプラットホームです。
+Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。

-Kubernetesは膨大で、急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
+Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。

-Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは[Googleが大規模な本番ワークロードを動かしてきた10年半の経験](https://research.google.com/pubs/pub43438.html)と、コミュニティから得られた最善のアイデア、知見に基づいています。
+## 過去を振り返ってみると

-## なぜKubernetesが必要で、どんなことができるのか？
+過去を振り返って、Kubernetesがなぜこんなに便利なのかを見てみましょう。

-Kubernetesには多くの機能があります。考えられるものとしては
+![Deployment evolution](/images/docs/Container_Evolution.svg)

- コンテナ基盤
- マイクロサービス基盤
- ポータブルなクラウド基盤
+**仮想化ができる前の時代におけるデプロイ (Traditional deployment):** 初期の頃は、組織は物理サーバー上にアプリケーションを実行させていました。物理サーバー上でアプリケーションのリソース制限を設定する方法がなかったため、リソースの割当問題が発生していました。例えば、複数のアプリケーションを実行させた場合、ひとつのアプリケーションがリソースの大半を消費してしまうと、他のアプリケーションのパフォーマンスが低下してしまうことがありました。この解決方法は、それぞれのアプリケーションを別々の物理サーバーで動かすことでした。しかし、リソースが十分に活用できなかったため、拡大しませんでした。また組織にとって多くの物理サーバーを維持することは費用がかかりました。

-など、他にもいろいろ
+**仮想化を使ったデプロイ (Virtualized deployment):** ひとつの解決方法として、仮想化が導入されました。1台の物理サーバーのCPU上で、複数の仮想マシン(VM)を実行させることができるようになりました。仮想化によりアプリケーションをVM毎に隔離する事ができ、ひとつのアプリケーションの情報が他のアプリケーションから自由にアクセスさせないといったセキュリティレベルを提供することができます。

-Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザーワークロードの代表格であるコンピューティング、ネットワーキング、ストレージインフラストラクチャのオーケストレーションを行います。それによって、Platform as a Service(PaaS)の簡単さの大部分を、Infrastructure as a Service(IaaS)の柔軟さとともに提供し、インフラストラクチャプロバイダの垣根を超えたポータビリティを実現します。
+仮想化により、物理サーバー内のリソース使用率が向上し、アプリケーションの追加や更新が容易になり、ハードウェアコストの削減などスケーラビリティが向上します。仮想化を利用すると、物理リソースのセットを使い捨て可能な仮想マシンのクラスターとして提示することができます。

-## Kubernetesが基盤になるってどういうこと？
+各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。

-Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。
+**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPU、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。

-[ラベル](/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/)を持たせて作成することができます。
+* アジャイルアプリケーションの作成とデプロイ: VMイメージの利用時と比較して、コンテナイメージ作成の容易さと効率性が向上します。
+* 継続的な開発、インテグレーションとデプロイ: 信頼できる頻繁なコンテナイメージのビルドと、素早く簡単にロールバックすることが可能なデプロイを提供します。(イメージが不変であれば)
+* 開発者と運用者の関心を分離: アプリケーションコンテナイメージの作成は、デプロイ時ではなく、ビルド/リリース時に行います。それによって、インフラストラクチャとアプリケーションを分離します。
+* 可観測性はOSレベルの情報とメトリクスだけではなく、アプリケーションの稼働状態やその他の警告も表示します。
+* 開発、テスト、本番環境を越えた環境の一貫性: クラウドで実行させるのと同じようにノートPCでも実行させる事ができます。
+* クラウドとOSディストリビューションの可搬性: Ubuntu、RHEL、CoreOS上でも、オンプレミスも、主要なパブリッククラウドでも、それ以外のどんな環境でも、実行できます。
+* アプリケーション中心の管理: 仮想マシン上でOSを実行するから、論理リソースを使用してOS上でアプリケーションを実行するへと抽象度のレベルを向上させます。
+* 疎結合、分散化、拡張性、柔軟性のあるマイクロサービス: アプリケーションを小さく、同時にデプロイと管理が可能な独立した部品に分割されます。1台の大きな単一目的のマシン上に実行するモノリシックなスタックではありません。
+* リソースの分割: アプリケーションのパフォーマンスが予測可能です。
+* リソースの効率的な利用: 高い効率性と集約性が可能です。

-この[デザイン](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)によって、他の多くのシステムがKubernetes上で構築できるようになりました。
+## Kubernetesが必要な理由と提供する機能 {#why-you-need-kubernetes-and-what-can-it-do}

-## Kubernetesにないこと
+コンテナは、アプリケーションを集約して実行する良い方法です。本番環境では、アプリケーションを実行しダウンタイムが発生しないように、コンテナを管理する必要があります。例えば、コンテナがダウンした場合、他のコンテナを起動する必要があります。このような動作がシステムに組込まれていると、管理が簡単になるのではないでしょうか？

-Kubernetesは伝統的な何でも入りのPaaSシステムではありません。Kubernetesはハードウェアレベルではなくコンテナレベルで動作するため、PaaS製品が提供するような、共通のいくつかの一般的に適用可能な機能(デプロイ、拡張、負荷分散、ログ記録、監視など)を提供します。ただし、Kubernetesはモノリシックではなく、これらのデフォルトのソリューションは任意に脱着可能です。Kubernetesは開発者の基盤を構築するための構成要素を提供しますが、重要な場合はユーザーの選択と柔軟性を維持します。
+そこを助けてくれるのがKubernetesです! Kubernetesは分散システムを弾力的に実行するフレームワークを提供してくれます。あなたのアプリケーションのためにスケーリングとフェイルオーバーの面倒を見てくれて、デプロイのパターンなどを提供します。例えば、Kubernetesはシステムにカナリアデプロイを簡単に管理することができます。
+
+Kubernetesは以下を提供します。
+
+* **サービスディスカバリーと負荷分散**  
+Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。
+* **ストレージ オーケストレーション**  
+Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。
+* **自動化されたロールアウトとロールバック**  
+Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。
+* **自動ビンパッキング**  
+コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。
+* **自己修復**  
+Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。
+* **機密情報と構成管理**  
+Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。
+
+## Kubernetesにないもの
+
+Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。

 Kubernetesは...

-* サポートするアプリケーションの種類を限定しません。Kubernetesはステートレス、ステートフル、およびデータ処理ワークロードなど、非常に多様なワークロードをサポートするように作られています。アプリケーションをコンテナ内で実行できる場合は、Kubernetes上でもうまく動作するはずです。
-* ソースコードのデプロイやアプリケーションのビルドを行いません。継続的インテグレーション、デリバリー、デプロイ(CI/CD)ワークフローは、技術選定がそうであるように、組織の文化や好みによって決まるからです。
-* ミドルウェア(例: message buses)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。
-* ロギング、モニタリング、アラーティングソリューションへの指示は行いません。概念実証(PoC)としていくつかのインテグレーション、およびメトリックを収集およびエクスポートするためのメカニズムを提供します。
-* 設定言語/システム(例： jsonnet)を提供も強制もしません。任意の形式の宣言仕様の対象となる可能性がある宣言APIを提供します。
-* 包括的なインフラ構成、保守、管理、またはセルフヒーリングシステムを提供、導入しません。
-
-さらに、Kubernetesは単なる *オーケストレーションシステム* ではありません。実際、オーケストレーションは不要です。*オーケストレーション* の技術的定義は、定義されたワークフローの実行です。最初にA、次にB、次にCを実行します。対照的に、Kubernetesは現在の状態を提供された望ましい状態に向かって継続的に推進する一連の独立した構成可能な制御プロセスで構成されます。AからCへのアクセス方法は関係ありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、回復力があり、そして拡張性のあるシステムが得られます。
-
-## なぜコンテナなのか？
-
-なぜコンテナを使うべきかの理由をお探しですか？
-
-![なぜコンテナなのか？](/images/docs/why_containers.svg)
-
-アプリケーションをデプロイするための古い方法は、オペレーティングシステムのパッケージマネージャを使用してアプリケーションをホストにインストールすることでした。これには、アプリケーションの実行ファイル、構成、ライブラリ、ライフサイクルがそれぞれ、またホストOS自身と絡み合うというデメリットがありました。予測可能なロールアウトとロールバックを実現するために、不変の仮想マシンイメージを作成することもできますが、VMは重く、移植性がありません。
-
-新しい方法は、ハードウェア仮想化ではなく、オペレーティングシステムレベルの仮想化に基づいてコンテナを展開することです。各コンテナは互いに、そしてホストから隔離されています。また、独自のファイルシステムを持ち、お互いのプロセスを見ることができず、計算リソースの使用量を制限することができます。これはVMよりも構築が簡単で、基盤となるインフラストラクチャとホストのファイルシステムから分離されているため、クラウドやOSのディストリビューション間で移植性があります。
-
-コンテナは小さくて速いので、1つのアプリケーションを各コンテナイメージにまとめることができます。この1対1のアプリケーションとイメージの関係により、コンテナの利点が完全に引き出されます。コンテナを使用すると、各アプリケーションを残りのアプリケーションスタックと合成したり、本番インフラストラクチャ環境と結合したりする必要がないため、不変のコンテナイメージをデプロイ時ではなく、ビルド時またはリリース時に作成できます。ビルド/リリース時にコンテナイメージを生成することで、開発から運用に一貫した環境を持ち込むことができます。同様に、コンテナはVMよりもはるかに透過的であるため、監視と管理が容易になります。これは、コンテナのプロセスライフサイクルがコンテナ内のプロセススーパーバイザによって隠されるのではなく、インフラストラクチャによって管理される場合に特に当てはまります。最後に、コンテナごとに1つのアプリケーションを使用すると、コンテナの管理はアプリケーションのデプロイ管理と同等になります。
-
-コンテナの利点をまとめると:
-
-* **アジャイルなアプリケーション作成とデプロイ**:
-    VMイメージの使用と比べ、コンテナイメージ作成は容易で効率も高いです。
-* **継続的な開発、インテグレーション、デプロイ**:
-    迅速で簡単なロールバックで、信頼性の高い頻繁なコンテナイメージのビルドとデプロイを提供します(イメージの不変性にもよります)。
-* **開発と運用の懸念を分離**:
-    デプロイ時ではなくビルド時またはリリース時にアプリケーションのコンテナイメージを作成することで、アプリケーションをインフラストラクチャから切り離します。
-* **可観測性**
-    OSレベルの情報や測定基準だけでなく、アプリケーションの正常性やその他のシグナルも明確にします。
-* **開発、テスト、本番環境に跨った環境の一貫性**:
-    手元のノートPC上でも、クラウド上と同じように動作します。
-* **クラウドとOSディストリビューションの移植性**:
-    Ubuntu、RHEL、CoreOS、オンプレミス、Google Kubernetes Engine、その他のどこでも動作します。
-* **アプリケーション中心の管理**:
-    仮想ハードウェア上でのOS実行から、論理リソースを使用したOS上でのアプリケーション実行へと、抽象度のレベルを上げます。
-* **疎結合で、分散された、伸縮自在の遊離した[マイクロサービス](https://martinfowler.com/articles/microservices.html)**:
-    アプリケーションは小さな独立した欠片に分割され、動的に配置および管理できます。1つの大きな単一目的のマシンで実行されるモノリシックなスタックではありません。
-* **リソース分割**:
-    アプリケーションパフォーマンスが予測可能です。
-* **リソースの効率利用**:
-    高効率で高密度です。
-
-## Kubernetesってどういう意味？K8sって何？
-
-**Kubernetes** という名前はギリシャ語で *操舵手* や *パイロット* という意味があり、*知事* や[サイバネティックス](http://www.etymonline.com/index.php?term=cybernetics)の語源にもなっています。*K8s* は、8文字の「ubernete」を「8」に置き換えた略語です。
-
+* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
+* ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。
+* ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。
+* ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。
+* 構成言語/システム(例:Jsonnet)の提供も指示もしません。任意の形式の宣言型仕様の対象となる可能性のある宣言型APIを提供します。
+* 統合的なマシンの構成、メンテナンス、管理、または自己修復を行うシステムは提供も採用も行いません。
+* さらに、Kubernetesは単なるオーケストレーションシステムではありません。実際には、オーケストレーションの必要性はありません。オーケストレーションの技術的な定義は、「最初にAを実行し、次にB、その次にCを実行」のような定義されたワークフローの実行です。対照的にKubernetesは、現在の状態から提示されたあるべき状態にあわせて継続的に維持するといった、独立していて構成可能な制御プロセスのセットを提供します。AからCへどのように移行するかは問題ではありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、弾力性と拡張性があるシステムが実現します。


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

-*   [はじめる](/docs/setup/)準備はできましたか？
-*   さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。
-
-
-
+*   [Kubernetesのコンポーネント](/ja/docs/concepts/overview/components/)を御覧ください。
+*   [はじめる](/ja/docs/setup/)準備はできましたか？
@@ -2,7 +2,7 @@
 title: Kubernetesオブジェクトを理解する
 content_type: concept
 weight: 10
-card: 
+card:
  name: concepts
  weight: 40
 ---
@@ -12,31 +12,31 @@ card:


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

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

-* どのようなコンテナ化されたアプリケーションが稼働しているか（またそれらはどのノード上で動いているか）
+* どのようなコンテナ化されたアプリケーションが稼働しているか(またそれらはどのノード上で動いているか)
 * それらのアプリケーションから利用可能なリソース
 * アプリケーションがどのように振る舞うかのポリシー、例えば再起動、アップグレード、耐障害性ポリシーなど

-Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。
+Kubernetesオブジェクトは「意図の記録」です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。

 Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。

-### オブジェクトのspec（仕様）とstatus（状態）
+### オブジェクトのspec(仕様)とstatus(状態)

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

 spec、status、metadataに関するさらなる情報は、[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)をご確認ください。

 ### Kubernetesオブジェクトを記述する

-Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報（例えば名前）と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合（直接APIを呼ぶか、`kubectl`を利用するかに関わらず）、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。
+Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報(例えば名前)と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合(直接APIを呼ぶか、`kubectl`を利用するかに関わらず)、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。

 ここで、KubernetesのDeploymentに必要なフィールドとオブジェクトのspecを記載した`.yaml`ファイルの例を示します:

@@ -63,7 +63,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
 * `metadata` - オブジェクトを一意に特定するための情報、文字列の`name`、`UID`、また任意の`namespace`が該当する
 * `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`のフォーマットは[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。


@@ -185,7 +185,7 @@ kubectl get pods -l 'environment in (production),tier in (frontend)'
 ```

 すでに言及したように、*集合ベース* の要件は、*等価ベース* の要件より表現力があります。  
-例えば、値に対する_OR_ オペレーターを実装して以下のように書けます。  
+例えば、値に対する _OR_ オペレーターを実装して以下のように書けます。  

 ```shell
 kubectl get pods -l 'environment in (production, qa)'
@@ -78,7 +78,7 @@ kubectl config view --minify | grep namespace:
 ## NamespaceとDNS

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

@@ -63,7 +63,7 @@ kubectl create deployment nginx --image nginx

 ## 命令型オブジェクト設定

-命令型オブジェクト設定では、kubectlコマンドに処理内容（create、replaceなど）、任意のフラグ、そして最低1つのファイル名を指定します。
+命令型オブジェクト設定では、kubectlコマンドに処理内容(create、replaceなど)、任意のフラグ、そして最低1つのファイル名を指定します。
 指定されたファイルは、YAMLまたはJSON形式でオブジェクトの全ての定義情報を含んでいなければいけません。

 オブジェクト定義の詳細は、[APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)を参照してください。
@@ -150,7 +150,7 @@ kubectl apply -R -f configs/
 命令型オブジェクト設定手法に対する長所:

 - 現行オブジェクトに直接行われた変更が、それらが設定ファイルに反映されていなかったとしても、保持されます
- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ（作成、パッチ、削除）を検出します
+- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ(作成、パッチ、削除)を検出します

 命令型オブジェクト設定手法に対する短所:

@@ -163,9 +163,9 @@ kubectl apply -R -f configs/


 - [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [オブジェクト設定（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Kustomize（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [オブジェクト設定(命令型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [オブジェクト設定(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [Kustomize(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)
 - [Kubectlコマンドリファレンス](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
@@ -0,0 +1,57 @@
+---
+title: Limit Range
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。
+
+<!-- body -->
+
+*LimitRange*を利用すると、次のような制約を課せるようになります。
+
+- 名前空間内のPodまたはコンテナごとに、計算リソースの使用量の最小値と最大値を強制する。
+- 名前空間内のPersistentVolumeClaimごとに、ストレージリクエストの最小値と最大値を強制する。
+- 名前空間内で、リソースのrequestとlimitの割合を強制する。
+- 名前空間内の計算リソースのデフォルトのrequest/limitの値を設定して、実行時にコンテナに自動的に注入する。
+
+## LimitRangeを有効にする
+
+Kubernetes 1.10以降では、LimitRangeのサポートはデフォルトで有効になりました。
+
+LimitRangeが特定の名前空間内で強制されるのは、その名前空間内にLimitRangeオブジェクトが存在する場合です。
+
+LimitRangeオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
+
+### Limit Rangeの概要
+
+- 管理者は、1つの名前空間に1つのLimitRangeを作成します。
+- ユーザーは、Pod、コンテナ、PersistentVolumeClaimのようなリソースを名前空間内に作成します。
+- `LimitRanger`アドミッションコントローラーは、計算リソース要求が設定されていないすべてのPodとコンテナに対して、デフォルト値と制限値を強制します。そして、リソースの使用量を追跡し、名前空間内に存在するすべてのLimitRangeで定義された最小値、最大値、割合を外れないことを保証します。
+- LimitRangeの制約を破るようなリソース(Pod、コンテナ、PersistentVolumeClaim)の作成や更新を行うと、APIサーバーへのリクエストがHTTPステータスコード`403 FORBIDDEN`で失敗し、破られた制約を説明するメッセージが返されます。
+- 名前空間内でLimitRangeが`cpu`や`memory`などの計算リソースに対して有効になっている場合、ユーザーはrequestsやlimitsに値を指定しなければなりません。指定しなかった場合、システムはPodの作成を拒否する可能性があります。
+- LimitRangeの検証は、Podのアドミッションステージでのみ発生し、実行中のPodでは発生しません。
+
+以下は、LimitRangeを使用して作成できるポリシーの例です。
+
+- 8GiBのRAMと16コアのCPUの容量がある2ノードのクラスター上で、名前空間内のPodに対して、CPUには100mのrequestと最大500mのlimitの制約を課し、メモリーには200Miのrequestと600Miのlimitの制約を課す。
+- Spec内のrequestsにcpuやmemoryを指定せずに起動したコンテナに対して、CPUにはデフォルトで150mのlimitとrequestを、メモリーにはデフォルトで300Miのrequestをそれぞれ定義する。
+
+名前空間のlimitの合計が、Podやコンテナのlimitの合計よりも小さくなる場合、リソースの競合が起こる可能性があります。その場合、コンテナやPodは作成されません。
+
+LimitRangeに対する競合や変更は、すでに作成済みのリソースに対しては影響しません。
+
+## {{% heading "whatsnext" %}}
+
+より詳しい情報は、[LimitRangerの設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)を参照してください。
+
+制限の使用例については、以下のページを読んでください。
+
+- [名前空間ごとにCPUの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
+- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
+- [名前空間ごとにCPUのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
+- [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
+- [名前空間ごとにストレージ消費量の最小値と最大値を設定する方法](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。
+- [名前空間ごとのクォータを設定する詳細な例](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。
@@ -0,0 +1,8 @@
+---
+title: "スケジューリングと退避"
+weight: 90
+description: >
+  Kubernetesにおいてスケジューリングとは、稼働させたいPodをNodeにマッチさせ、kubeletが実行できるようにすることを指します。
+  退避とは、リソース不足のNodeで1つ以上のPodを積極的に停止させるプロセスです。
+---
+
@@ -104,7 +104,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン

 - `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。

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

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

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

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

-* [スケジューラーのパフォーマンスチューニング](/docs/concepts/scheduling/scheduler-perf-tuning/)を参照してください。
+* [スケジューラーのパフォーマンスチューニング](/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)を参照してください。
 * [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。
 * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
 * [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
@@ -8,9 +8,9 @@ weight: 70

 {{< feature-state for_k8s_version="1.14" state="beta" >}}

-[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。
+[kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。

-クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。
+クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して*割り当て可能*なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは*Binding*と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。

 このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。

@@ -35,11 +35,11 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```

-{{< note >}} 
+{{< note >}}
 割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。
 {{< /note >}}

-**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。  
+**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。


 ### percentageOfNodesToScoreのチューニング
@@ -0,0 +1,221 @@
+---
+title: TaintとToleration
+content_type: concept
+weight: 40
+---
+
+
+<!-- overview -->
+[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は
+{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はNodeがある種のPodを排除できるようにします。
+
+_toleration_ はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。
+
+taintとtolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。taintはNodeに一つまたは複数個付与することができます。これはそのNodeがtaintを許容しないPodを受け入れるべきではないことを示します。
+
+
+<!-- body -->
+
+## コンセプト
+
+Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。
+例えば、次のコマンドは
+
+```shell
+kubectl taint nodes node1 key=value:NoSchedule
+```
+
+`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。
+これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。
+
+上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。
+```shell
+kubectl taint nodes node1 key:NoSchedule-
+```
+
+PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。
+
+```yaml
+tolerations:
+- key: "key"
+  operator: "Equal"
+  value: "value"
+  effect: "NoSchedule"
+```
+
+```yaml
+tolerations:
+- key: "key"
+  operator: "Exists"
+  effect: "NoSchedule"
+```
+
+tolerationを設定したPodの例を示します。
+
+{{< codenew file="pods/pod-with-toleration.yaml" >}}
+
+`operator`のデフォルトは`Equal`です。
+
+tolerationがtaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。
+
+* `operator`が`Exists`（`value`を指定すべきでない場合）
+* `operator`が`Equal`であり、かつ`value`が同一である場合
+
+{{< note >}}
+
+2つ特殊な場合があります。
+
+空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。
+
+空の`effect`は`key`が一致する全てのeffectと合致します。
+
+{{< /note >}}
+
+上記の例では`effect`に`NoSchedule`を指定しました。代わりに、`effect`に`PreferNoSchedule`を指定することができます。
+これは`NoSchedule`の「ソフトな」バージョンであり、システムはtaintに対応するtolerationが設定されていないPodがNodeへ配置されることを避けようとしますが、必須の条件とはしません。3つ目の`effect`の値として`NoExecute`がありますが、これについては後述します。
+
+同一のNodeに複数のtaintを付与することや、同一のPodに複数のtolerationを設定することができます。
+複数のtaintやtolerationが設定されている場合、Kubernetesはフィルタのように扱います。最初はNodeの全てのtaintがある状態から始め、Podが対応するtolerationを持っているtaintは無視され外されていきます。無視されずに残ったtaintが効果を及ぼします。
+具体的には、
+
+* effect `NoSchedule`のtaintが無視されず残った場合、KubernetesはそのPodをNodeへスケジューリングしません。
+* effect `NoSchedule`のtaintは残らず、effect `PreferNoSchedule`のtaintは残った場合、KubernetesはそのNodeへのスケジューリングをしないように試みます。
+* effect `NoExecute`のtaintが残った場合、既に稼働中のPodはそのNodeから排除され、まだ稼働していないPodはスケジューリングされないようになります。
+
+例として、下記のようなtaintが付与されたNodeを考えます。
+
+```shell
+kubectl taint nodes node1 key1=value1:NoSchedule
+kubectl taint nodes node1 key1=value1:NoExecute
+kubectl taint nodes node1 key2=value2:NoSchedule
+```
+
+Podには2つのtolerationが設定されています。
+
+```yaml
+tolerations:
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoSchedule"
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoExecute"
+```
+
+この例では、3つ目のtaintと合致するtolerationがないため、PodはNodeへはスケジューリングされません。
+しかし、これらのtaintが追加された時点で、そのNodeでPodが稼働していれば続けて稼働することが可能です。 これは、Podのtolerationと合致しないtaintは3つあるtaintのうちの3つ目のtaintのみであり、それが`NoSchedule`であるためです。
+
+一般に、effect `NoExecute`のtaintがNodeに追加されると、合致するtolerationが設定されていないPodは即時にNodeから排除され、合致するtolerationが設定されたPodが排除されることは決してありません。
+しかし、effect`NoExecute`に対するtolerationは`tolerationSeconds`フィールドを任意で指定することができ、これはtaintが追加された後にそのNodeにPodが残る時間を示します。例えば、
+
+```yaml
+tolerations:
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoExecute"
+  tolerationSeconds: 3600
+```
+
+この例のPodが稼働中で、対応するtaintがNodeへ追加された場合、PodはそのNodeに3600秒残り、その後排除されます。仮にtaintがそれよりも前に外された場合、Podは排除されません。
+
+## ユースケースの例
+
+taintとtolerationは、実行されるべきではないNodeからPodを遠ざけたり、排除したりするための柔軟な方法です。いくつかのユースケースを示します。
+
+* **専有Node**: あるNode群を特定のユーザーに専有させたい場合、そのNode群へtaintを追加し(`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) 対応するtolerationをPodへ追加します（これを実現する最も容易な方法はカスタム
+[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を書くことです）。
+tolerationが設定されたPodはtaintの設定された（専有の）Nodeと、クラスターにあるその他のNodeの使用が認められます。もしPodが必ず専有Node*のみ*を使うようにしたい場合は、taintと同様のラベルをそのNode群に設定し(例: `dedicated=groupName`)、アドミッションコントローラーはNodeアフィニティを使ってPodが`dedicated=groupName`のラベルの付いたNodeへスケジューリングすることが必要であるということも設定する必要があります。
+
+* **特殊なハードウェアを備えるNode**: クラスターの中の少数のNodeが特殊なハードウェア（例えばGPU）を備える場合、そのハードウェアを必要としないPodがスケジューリングされないようにして、後でハードウェアを必要とするPodができたときの余裕を確保したいことがあります。
+これは特殊なハードウェアを持つNodeにtaintを追加(例えば `kubectl taint nodes nodename special=true:NoSchedule` または
+`kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するtolerationを追加することで可能です。
+専有Nodeのユースケースと同様に、tolerationを容易に適用する方法はカスタム
+[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を使うことです。
+例えば、特殊なハードウェアを表すために[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+を使い、ハードウェアを備えるNodeに拡張リソースの名称のtaintを追加して、
+[拡張リソースtoleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
+アドミッションコントローラーを実行することが推奨されます。Nodeにはtaintが付与されているため、tolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースtoleration` アドミッションコントローラーはPodに自動的に適切なtolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。
+これは特殊なハードウェアを備えたNodeではそれを必要とするPodのみが稼働し、Podに対して手作業でtolerationを追加しなくて済むようにします。
+
+* **taintを基にした排除**: Nodeに問題が起きたときにPodごとに排除する設定を行うことができます。次のセクションにて説明します。
+
+## taintを基にした排除
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+上述したように、effect `NoExecute`のtaintはNodeで実行中のPodに次のような影響を与えます。
+
+ * 対応するtolerationのないPodは即座に除外される
+ * 対応するtolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける
+ * 対応するtolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される
+
+Nodeコントローラーは特定の条件を満たす場合に自動的にtaintを追加します。
+組み込まれているtaintは下記の通りです。
+
+ * `node.kubernetes.io/not-ready`: Nodeの準備ができていない場合。これはNodeCondition `Ready`が`False`である場合に対応します。
+ * `node.kubernetes.io/unreachable`: NodeがNodeコントローラーから到達できない場合。これはNodeCondition`Ready`が`Unknown`の場合に対応します。
+ * `node.kubernetes.io/out-of-disk`: Nodeのディスクの空きがない場合。
+ * `node.kubernetes.io/memory-pressure`: Nodeのメモリーが不足している場合。
+ * `node.kubernetes.io/disk-pressure`: Nodeのディスクが不足している場合。
+ * `node.kubernetes.io/network-unavailable`: Nodeのネットワークが利用できない場合。
+ * `node.kubernetes.io/unschedulable`: Nodeがスケジューリングできない場合。
+ * `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるtaintで、このNodeは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのNodeを初期化した後にkubeletはこのtaintを外します。
+
+Nodeから追い出すときには、Nodeコントローラーまたはkubeletは関連するtaintを`NoExecute`効果の状態で追加します。
+不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはNodeコントローラーは関連するtaintを外すことができます。
+
+{{< note >}}
+コントロールプレーンは新しいtaintをNodeに加えるレートを制限しています。
+このレート制限は一度に多くのNodeが到達不可能になった場合（例えばネットワークの断絶）に、退役させられるNodeの数を制御します。
+{{< /note >}}
+
+Podに`tolerationSeconds`を指定することで不具合があるか応答のないNodeに残る時間を指定することができます。
+
+例えば、ローカルの状態を多数持つアプリケーションとネットワークが分断された場合を考えます。ネットワークが復旧して、Podを排除しなくて済むことを見込んで、長時間Nodeから排除されないようにしたいこともあるでしょう。
+この場合Podに設定するtolerationは次のようになります。
+
+```yaml
+tolerations:
+- key: "node.kubernetes.io/unreachable"
+  operator: "Exists"
+  effect: "NoExecute"
+  tolerationSeconds: 6000
+```
+
+{{< note >}}
+Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的に`node.kubernetes.io/not-ready`と`node.kubernetes.io/unreachable`に対するtolerationを`tolerationSeconds=300`にて設定します。
+
+自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。
+{{< /note >}}
+
+[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。
+
+  * `node.kubernetes.io/unreachable`
+  * `node.kubernetes.io/not-ready`
+
+これはDaemonSetのPodはこれらの問題によって排除されないことを保証します。
+
+## 条件によるtaintの付与
+
+NodeのライフサイクルコントローラーはNodeの状態に応じて`NoSchedule`効果のtaintを付与します。
+スケジューラーはNodeの状態ではなく、taintを確認します。
+Nodeに何がスケジューリングされるかは、そのNodeの状態に影響されないことを保証します。ユーザーは適切なtolerationをPodに付与することで、どの種類のNodeの問題を無視するかを選ぶことができます。
+
+DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐために自動的に次の`NoSchedule`tolerationを全てのDaemonSetに付与します。
+
+  * `node.kubernetes.io/memory-pressure`
+  * `node.kubernetes.io/disk-pressure`
+  * `node.kubernetes.io/out-of-disk` (*重要なPodのみ*)
+  * `node.kubernetes.io/unschedulable` (1.10またはそれ以降)
+  * `node.kubernetes.io/network-unavailable` (*ホストネットワークのみ*)
+
+これらのtolerationを追加することは後方互換性を保証します。DaemonSetに任意のtolerationを加えることもできます。
+
+
+## {{% heading "whatsnext" %}}
+
+* [リソース枯渇の対処](/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む
+* [Podの優先度](/docs/concepts/configuration/pod-priority-preemption/)を読む
@@ -1,5 +0,0 @@
---
-title: "スケジューリング"
-weight: 90
---
-
@@ -0,0 +1,118 @@
+---
+title: HostAliasesを使用してPodの/etc/hostsにエントリーを追加する
+content_type: concept
+weight: 60
+min-kubernetes-server-version: 1.7
+---
+
+
+<!-- overview -->
+
+Podの`/etc/hosts`ファイルにエントリーを追加すると、DNSやその他の選択肢を利用できない場合に、Podレベルでホスト名の名前解決を上書きできるようになります。このようなカスタムエントリーは、PodSpecのHostAliasesフィールドに追加できます。
+
+HostAliasesを使用せずにファイルを修正することはおすすめできません。このファイルはkubeletが管理しており、Podの作成や再起動時に上書きされる可能性があるためです。
+
+
+<!-- body -->
+
+## デフォルトのhostsファイルの内容
+
+Nginx Podを実行すると、Pod IPが割り当てられます。
+
+```shell
+kubectl run nginx --image nginx
+```
+
+```
+pod/nginx created
+```
+
+Pod IPを確認します。
+
+```shell
+kubectl get pods --output=wide
+```
+
+```
+NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+nginx    1/1       Running   0          13s    10.200.0.4   worker0
+```
+
+hostsファイルの内容は次のようになります。
+
+```shell
+kubectl exec nginx -- cat /etc/hosts
+```
+
+```
+# Kubernetes-managed hosts file.
+127.0.0.1	localhost
+::1	localhost ip6-localhost ip6-loopback
+fe00::0	ip6-localnet
+fe00::0	ip6-mcastprefix
+fe00::1	ip6-allnodes
+fe00::2	ip6-allrouters
+10.200.0.4	nginx
+```
+
+デフォルトでは、`hosts`ファイルには、`localhost`やPod自身のホスト名などのIPv4とIPv6のボイラープレートだけが含まれています。
+
+## 追加エントリーをhostAliasesに追加する
+
+デフォルトのボイラープレートに加えて、`hosts`ファイルに追加エントリーを追加できます。たとえば、`foo.local`と`bar.local`を`127.0.0.1`に、`foo.remote`と`bar.remote`を`10.1.2.3`にそれぞれ解決するためには、PodのHostAliasesを`.spec.hostAliases`以下に設定します。
+
+{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
+
+この設定を使用したPodを開始するには、次のコマンドを実行します。
+
+```shell
+kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml
+```
+
+```
+pod/hostaliases-pod created
+```
+
+Podの詳細情報を表示して、IPv4アドレスと状態を確認します。
+
+```shell
+kubectl get pod --output=wide
+```
+
+```
+NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE
+hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0
+```
+
+`hosts`ファイルの内容は次のようになります。
+
+```shell
+kubectl logs hostaliases-pod
+```
+
+```
+# Kubernetes-managed hosts file.
+127.0.0.1	localhost
+::1	localhost ip6-localhost ip6-loopback
+fe00::0	ip6-localnet
+fe00::0	ip6-mcastprefix
+fe00::1	ip6-allnodes
+fe00::2	ip6-allrouters
+10.200.0.5	hostaliases-pod
+
+# Entries added by HostAliases.
+127.0.0.1	foo.local	bar.local
+10.1.2.3	foo.remote	bar.remote
+```
+
+ファイルの最後に追加エントリーが指定されています。
+
+## kubeletがhostsファイルを管理するのはなぜですか？ {#why-does-kubelet-manage-the-hosts-file}
+
+kubeletがPodの各コンテナの`hosts`ファイルを[管理する](https://github.com/kubernetes/kubernetes/issues/14633)のは、コンテナ起動後にDockerがファイルを[編集する](https://github.com/moby/moby/issues/17190)のを防ぐためです。
+
+{{< caution >}}
+コンテナ内部でhostsファイルを手動で変更するのは控えてください。
+
+hostsファイルを手動で変更すると、コンテナが終了したときに変更が失われてしまいます。
+{{< /caution >}}
@@ -0,0 +1,100 @@
+---
+title: IPv4/IPv6デュアルスタック
+feature:
+  title: IPv4/IPv6デュアルスタック
+  description: >
+    IPv4およびIPv6のアドレスをPodとServiceに割り当てる
+content_type: concept
+weight: 70
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+ IPv4/IPv6デュアルスタックを利用すると、IPv4とIPv6のアドレスの両方を{{< glossary_tooltip text="Pod" term_id="pod" >}}および{{< glossary_tooltip text="Service" term_id="service" >}}に指定できるようになります。
+
+ KubernetesクラスターでIPv4/IPv6デュアルスタックのネットワークを有効にすれば、クラスターはIPv4とIPv6のアドレスの両方を同時に割り当てることをサポートするようになります。
+
+<!-- body -->
+
+## サポートされている機能
+
+KubernetesクラスターでIPv4/IPv6デュアルスタックを有効にすると、以下の機能が提供されます。
+
+   * デュアルスタックのPodネットワーク(PodごとにIPv4とIPv6のアドレスが1つずつ割り当てられます)
+   * IPv4およびIPv6が有効化されたService(各Serviceは1つのアドレスファミリーでなければなりません)
+   * IPv4およびIPv6インターフェイスを経由したPodのクラスター外向きの(たとえば、インターネットへの)ルーティング
+
+## 前提条件
+
+IPv4/IPv6デュアルスタックのKubernetesクラスターを利用するには、以下の前提条件を満たす必要があります。
+
+   * Kubernetesのバージョンが1.16以降である
+   * プロバイダーがデュアルスタックのネットワークをサポートしている(クラウドプロバイダーなどが、ルーティング可能なIPv4/IPv6ネットワークインターフェイスが搭載されたKubernetesを提供可能である)
+   * ネットワークプラグインがデュアルスタックに対応している(KubenetやCalicoなど)
+
+## IPv4/IPv6デュアルスタックを有効にする
+
+IPv4/IPv6デュアルスタックを有効にするには、クラスターの関連コンポーネントで`IPv6DualStack`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、デュアルスタックのクラスターネットワークの割り当てを以下のように設定します。
+
+   * kube-apiserver:
+      * `--feature-gates="IPv6DualStack=true"`
+   * kube-controller-manager:
+      * `--feature-gates="IPv6DualStack=true"`
+      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
+      * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` デフォルトのサイズは、IPv4では/24、IPv6では/64です
+   * kubelet:
+      * `--feature-gates="IPv6DualStack=true"`
+   * kube-proxy:
+      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
+      * `--feature-gates="IPv6DualStack=true"`
+
+{{< note >}}
+IPv4 CIDRの例: `10.244.0.0/16` (自分のクラスターのアドレス範囲を指定してください)
+
+IPv6 CIDRの例: `fdXY:IJKL:MNOP:15::/64` (これはフォーマットを示すための例であり、有効なアドレスではありません。詳しくは[RFC 4193](https://tools.ietf.org/html/rfc4193)を参照してください)
+
+{{< /note >}}
+
+## Service
+
+クラスターでIPv4/IPv6デュアルスタックのネットワークを有効にした場合、IPv4またはIPv6のいずれかのアドレスを持つ{{< glossary_tooltip text="Service" term_id="service" >}}を作成できます。Serviceのcluster IPのアドレスファミリーは、Service上に`.spec.ipFamily`フィールドを設定することで選択できます。このフィールドを設定できるのは、新しいServiceの作成時のみです。`.spec.ipFamily`フィールドの指定はオプションであり、{{< glossary_tooltip text="Service" term_id="service" >}}と{{< glossary_tooltip text="Ingress" term_id="ingress" >}}でIPv4とIPv6を有効にする予定がある場合にのみ使用するべきです。このフィールドの設定は、[外向きのトラフィック](#egress-traffic)に対する要件には含まれません。
+
+{{< note >}}
+クラスターのデフォルトのアドレスファミリーは、kube-controller-managerに`--service-cluster-ip-range`フラグで設定した、最初のservice cluster IPの範囲のアドレスファミリーです。
+{{< /note >}}
+
+`.spec.ipFamily`は、次のいずれかに設定できます。
+
+   * `IPv4`: APIサーバーは`ipv4`の`service-cluster-ip-range`の範囲からIPアドレスを割り当てます
+   * `IPv6`: APIサーバーは`ipv6`の`service-cluster-ip-range`の範囲からIPアドレスを割り当てます
+
+次のServiceのspecには`ipFamily`フィールドが含まれていません。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPアドレス(別名「cluster IP」)を割り当てます。
+
+{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+
+次のServiceのspecには`ipFamily`フィールドが含まれています。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPv6のアドレス(別名「cluster IP」)を割り当てます。
+
+{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
+
+比較として次のServiceのspecを見ると、このServiceには最初に設定した`service-cluster-ip-range`の範囲からIPv4のアドレス(別名「cluster IP」)が割り当てられます。
+
+{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
+
+### Type LoadBalancer
+
+IPv6が有効になった外部ロードバランサーをサポートしているクラウドプロバイダーでは、`type`フィールドに`LoadBalancer`を指定し、`ipFamily`フィールドに`IPv6`を指定することにより、クラウドロードバランサーをService向けにプロビジョニングできます。
+
+## 外向きのトラフィック {#egress-traffic}
+
+パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。
+
+## 既知の問題
+
+   * Kubenetは、IPv4,IPv6の順番にIPを報告することを強制します(--cluster-cidr)
+
+## {{% heading "whatsnext" %}}
+
+* [IPv4/IPv6デュアルスタックのネットワークを検証する](/docs/tasks/network/validate-dual-stack)
@@ -0,0 +1,57 @@
+---
+title: Ingressコントローラー
+reviewers:
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+Ingressリソースが動作するためには、クラスターでIngressコントローラーが実行されている必要があります。
+
+`kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。
+
+プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。
+
+
+
+<!-- body -->
+
+## 追加のコントローラー {#additional-controllers}
+
+* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。
+* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。
+* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](http://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
+* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。
+* [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
+* Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。
+* F5 Networksは[F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
+* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。
+* [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。
+* [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。
+* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。
+* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。
+* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
+* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。
+
+## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers}
+
+[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。
+
+クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。
+
+理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。
+
+
+{{< note >}}
+Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。
+{{< /note >}}
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細
+* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
@@ -0,0 +1,144 @@
+---
+title: Serviceトポロジー
+feature:
+  title: Serviceトポロジー
+  description: >
+    Serviceのトラフィックをクラスタートポロジーに基づいてルーティングします。
+content_type: concept
+weight: 10
+---
+
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
+
+*Serviceトポロジー*を利用すると、Serviceのトラフィックをクラスターのノードトポロジーに基づいてルーティングできるようになります。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。
+
+<!-- body -->
+
+## はじめに
+
+デフォルトでは、`ClusterIP`や`NodePort`Serviceに送信されたトラフィックは、Serviceに対応する任意のバックエンドのアドレスにルーティングされる可能性があります。しかし、Kubernetes 1.7以降では、「外部の」トラフィックをそのトラフィックを受信したノード上のPodにルーティングすることが可能になりました。しかし、この機能は`ClusterIP`Serviceでは対応しておらず、ゾーン内ルーティングなどのより複雑なトポロジーは実現不可能でした。*Serviceトポロジー*の機能を利用すれば、Serviceの作者が送信元ノードと送信先ノードのNodeのラベルに基づいてトラフィックをルーティングするためのポリシーを定義できるようになるため、この問題を解決できます。
+
+送信元と送信先の間のNodeラベルのマッチングを使用することにより、オペレーターは、そのオペレーターの要件に適したメトリクスを使用して、お互いに「より近い」または「より遠い」ノードのグループを指定できます。たとえば、パブリッククラウド上のさまざまなオペレーターでは、Serviceのトラフィックを同一ゾーン内に留めようとする傾向があります。パブリッククラウドでは、ゾーンをまたぐトラフィックでは関連するコストがかかる一方、ゾーン内のトラフィックにはコストがかからない場合があるからです。その他のニーズとしては、DaemonSetが管理するローカルのPodにトラフィックをルーティングできるようにしたり、レイテンシーを低く抑えるために同じラック上のスイッチに接続されたノードにトラフィックを限定したいというものがあります。
+
+## Serviceトポロジーを利用する
+
+クラスターのServiceトポロジーが有効になっていれば、Serviceのspecに`topologyKeys`フィールドを指定することで、Serviceのトラフィックのルーティングを制御できます。このフィールドは、Nodeラベルの優先順位リストで、このServiceにアクセスするときにエンドポイントをソートするために使われます。トラフィックは、最初のラベルの値が送信元Nodeのものと一致するNodeに送信されます。一致したノード上にServiceに対応するバックエンドが存在しなかった場合は、2つ目のラベルについて検討が行われ、同様に、残っているラベルが順番に検討されまます。
+
+一致するキーが1つも見つからなかった場合、トラフィックは、Serviceに対応するバックエンドが存在しなかったかのように拒否されます。言い換えると、エンドポイントは、利用可能なバックエンドが存在する最初のトポロジーキーに基づいて選択されます。このフィールドが指定され、すべてのエントリーでクライアントのトポロジーに一致するバックエンドが存在しない場合、そのクライアントに対するバックエンドが存在しないものとしてコネクションが失敗します。「任意のトポロジー」を意味する特別な値`"*"`を指定することもできます。任意の値にマッチするこの値に意味があるのは、リストの最後の値として使った場合だけです。
+
+`topologyKeys`が未指定または空の場合、トポロジーの制約は適用されません。
+
+ホスト名、ゾーン名、リージョン名のラベルが付いたNodeを持つクラスターについて考えてみましょう。このとき、Serviceの`topologyKeys`の値を設定することで、トラフィックの向きを以下のように制御できます。
+
+* トラフィックを同じノード上のエンドポイントのみに向け、同じノード上にエンドポイントが1つも存在しない場合には失敗するようにする: `["kubernetes.io/hostname"]`。
+* 同一ノード上のエンドポイントを優先し、失敗した場合には同一ゾーン上のエンドポイント、同一リージョンゾーンのエンドポイントへとフォールバックし、それ以外の場合には失敗する: `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。これは、たとえばデータのローカリティが非常に重要である場合などに役に立ちます。
+* 同一ゾーンを優先しますが、ゾーン内に利用可能なノードが存在しない場合は、利用可能な任意のエンドポイントにフォールバックする: `["topology.kubernetes.io/zone", "*"]`。
+
+## 制約
+
+* Serviceトポロジーは`externalTrafficPolicy=Local`と互換性がないため、Serviceは2つの機能を同時に利用できません。2つの機能を同じクラスター上の異なるServiceでそれぞれ利用することは可能ですが、同一のService上では利用できません。
+
+* 有効なトポロジーキーは、現在は`kubernetes.io/hostname`、`topology.kubernetes.io/zone`、および`topology.kubernetes.io/region`に限定されています。しかし、将来は一般化され、他のノードラベルも使用できるようになる予定です。
+
+* トポロジーキーは有効なラベルのキーでなければならず、最大で16個のキーまで指定できます。
+
+* すべての値をキャッチする`"*"`を使用する場合は、トポロジーキーの最後の値として指定しなければなりません。
+
+## 例
+
+以下では、Serviceトポロジーの機能を利用したよくある例を紹介します。
+
+### ノードローカルのエンドポイントだけを使用する
+
+ノードローカルのエンドポイントのみにルーティングするServiceの例です。もし同一ノード上にエンドポイントが存在しない場合、トラフィックは損失します。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+```
+
+### ノードローカルのエンドポイントを優先して使用する
+
+ノードローカルのエンドポイントを優先して使用しますが、ノードローカルのエンドポイントが存在しない場合にはクラスター全体のエンドポイントにフォールバックするServiceの例です。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+    - "*"
+```
+
+
+### 同一ゾーンや同一リージョンのエンドポイントだけを使用する
+
+同一リージョンのエンドポイントより同一ゾーンのエンドポイントを優先するServiceの例です。もしいずれのエンドポイントも存在しない場合、トラフィックは損失します。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "topology.kubernetes.io/zone"
+    - "topology.kubernetes.io/region"
+```
+
+### ノードローカル、同一ゾーン、同一リーションのエンドポイントを優先して使用する
+
+ノードローカル、同一ゾーン、同一リージョンのエンドポイントを順番に優先し、クラスター全体のエンドポイントにフォールバックするServiceの例です。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+    - "topology.kubernetes.io/zone"
+    - "topology.kubernetes.io/region"
+    - "*"
+```
+
+## {{% heading "whatsnext" %}}
+
+* [Serviceトポトジーを有効にする](/docs/tasks/administer-cluster/enabling-service-topology)を読む。
+* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。
+
@@ -46,7 +46,7 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).

 例として、CronJobが`08:30:00`を開始時刻として1分ごとに新しいJobをスケジュールするように設定され、`startingDeadlineSeconds`フィールドが設定されていない場合を想定します。CronJobコントローラーが`08:29:00` から`10:21:00`の間にダウンしていた場合、スケジューリングを逃したジョブの数が100を超えているため、ジョブは開始されません。

-このコンセプトを更に掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。
+このコンセプトをさらに掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。

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

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

 content_type: concept
 weight: 30
@@ -1001,7 +1001,7 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成

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

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

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

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

 * Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。
-* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。
+* この新しい機能を適用させるために、存在していてすでに終了したリソースに対してこのフィールドをセットします。
 * リソース作成時に、このフィールドを動的にセットするために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。クラスター管理者は、終了したリソースに対して、このTTLポリシーを強制するために使うことができます。
 * リソースが終了した後に、このフィールドを動的にセットしたり、リソースステータスやラベルなどの値に基づいて異なるTTL値を選択するために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。

@@ -8,7 +8,7 @@ weight: 40
 このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。
 Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。

-Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。
+Initコンテナは、Podの仕様のうち`containers`という配列(これがアプリケーションコンテナを示します)と並べて指定します。

 <!-- body -->
 ## Initコンテナを理解する {#understanding-init-containers}
@@ -202,7 +202,7 @@ myapp-pod   1/1       Running   0          9m

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

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

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

@@ -213,7 +213,7 @@ Podは全てのInitコンテナが完了するまで`Ready`状態となりませ
 Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。
 Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。

-Initコンテナは何度も再起動およびリトライ可能なため、べき等（Idempotent）である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
+Initコンテナは何度も再起動およびリトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。

 Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。

@@ -230,11 +230,11 @@ Initコンテナの順序と実行を考えるとき、リソースの使用に
  * リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計
  * リソースに対する有効なinitリクエスト／リミット
 * スケジューリングは有効なリクエスト／リミットに基づいて実行されます。つまり、InitコンテナはPodの生存中には使用されない初期化用のリソースを確保することができます。
-* Podの*有効なQos（quality of service）ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
+* Podの*有効なQoS(quality of service)ティアー* は、Initコンテナとアプリケーションコンテナで同様です。

 クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。

-Podレベルのコントロールグループ（cgroups）は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
+Podレベルのコントロールグループ(cgroups)は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。

 ### Podの再起動の理由 {#pod-restart-reasons}

@@ -250,4 +250,3 @@ Podレベルのコントロールグループ（cgroups）は、スケジュー
 * [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。
 * [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。

-
@@ -1,5 +1,5 @@
 ---
-title: Podについての概観(Pod Overview)
+title: Podの概観
 content_type: concept
 weight: 10
 card:
@@ -8,7 +8,7 @@ card:
 ---

 <!-- overview -->
-このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。
+このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して説明します。


 <!-- body -->
@@ -62,7 +62,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共
 ## Podを利用する

 ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。
-これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。
+これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。

 {{< note >}}
 単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
@@ -111,7 +111,7 @@ spec:

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

-* [Pod](/ja/docs/concepts/workloads/pods/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/)
@@ -16,7 +16,7 @@ _Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な

 ## Podとは

-_Pod_ は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
+_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。

 Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。

@@ -24,7 +24,7 @@ Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離す
 Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。

 Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。
-また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。
+また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。
 異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。
 これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。

@@ -33,18 +33,18 @@ Pod内のアプリケーションからアクセスできる共有ボリュー

 [Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。

-個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。
-[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
+個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。
+[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。
 Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
-特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。
-代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。
+特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。
+代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。

-ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは（そのUIDを持つ）Podが存在する限り存在することを意味します。
-そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。
+ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。
+そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。

 {{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}

-*file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
+*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*

 ## Podを用いる動機

@@ -53,13 +53,13 @@ Nodeが停止した場合、そのNodeにスケジュールされたPodは、タ
 Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。
 構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。
 Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。
-Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
+Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。

 ### リソース共有と通信

 Podは、構成要素間でのデータ共有および通信を可能にします。

-Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
+Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
 このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。
 各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。

@@ -71,7 +71,7 @@ Podで実行されるアプリケーションコンテナの定義に加えて

 ## Podの用途

-Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。
+Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。
 しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。

 * コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
@@ -83,11 +83,11 @@ Podは、垂直に統合されたアプリケーションスタック（例：LA
 個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。

 詳細については、[The Distributed System ToolKit: Patterns for
-Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)（分散システムツールキット：複合コンテナのパターン）を参照してください。
+Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。

 ## 考えられる代替案

-_単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？_
+_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_

 1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。
 これは、ユーザーに多くの便益を提供します。
@@ -97,13 +97,13 @@ Kubernetesはいつか個々のコンテナのライブアップデートをサ
 1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
 1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。

-_アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
+_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_

 このアプローチによって、コンテナの共同配置は提供されるでしょう。
 しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。


-## Podの耐久性（またはその欠如）
+## Podの耐久性(またはその欠如) {#pod-durability}

 Podは、耐久性のある存在として扱われることを意図していません。
 スケジューリングの失敗や、Nodeの故障には耐えられません。
@@ -128,7 +128,7 @@ Podは、以下のことを容易にするためにプリミティブとして

 ## Podの終了 {#termination-of-pods}

-Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。
+Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
 ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。
 猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。
@@ -136,17 +136,17 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、

 フローの例は下のようになります。

-1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する
+1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する
 1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
 1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
-1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
+1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
    1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
-    猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
+    猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
    1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
-1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
-ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
+1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
+ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
 1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
-1. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。
+1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。
 PodはAPIから消え、クライアントからは見えなくなる

 デフォルトでは、すべての削除は30秒以内に正常に行われます。
@@ -186,5 +186,3 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'

 PodはKubernetes REST APIのトップレベルのリソースです。
 APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
-
-