Merge upstream work for release-1.19

2021-05-26 10:16:04 +00:00
parent d0903bdfa0
commit c60df272cb
178 changed files with 6179 additions and 4158 deletions
@@ -8,7 +8,7 @@ weight: 80

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

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

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

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



 <!-- body -->

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

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

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

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

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

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

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

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

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

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



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

 ### DaemonSetの作成

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

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

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

 ### 必須のフィールド

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

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

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

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

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

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

 ### Podセレクター

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

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

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

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

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

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

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

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

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

 ### TaintsとTolerations

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

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

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

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

 ### 静的Pod Pods

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

 ### Deployment

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

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

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

 <!-- overview -->

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 ## Deployment Specの記述

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

 ### Podテンプレート

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 ### paused

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 ### OnDelete

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

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

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

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

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

 ## TTLコントローラー

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

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


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

+* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
@@ -0,0 +1,147 @@
+---
+title: エフェメラルコンテナ
+content_type: concept
+weight: 80
+---
+
+<!-- overview -->
+
+{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
+
+このページでは、特別な種類のコンテナであるエフェメラルコンテナの概要を説明します。エフェメラルコンテナは、トラブルシューティングなどのユーザーが開始するアクションを実行するために、すでに存在する{{< glossary_tooltip term_id="pod" >}}内で一時的に実行するコンテナです。エフェメラルコンテナは、アプリケーションの構築ではなく、serviceの調査のために利用します。
+
+{{< warning >}}
+エフェメラルコンテナは初期のアルファ状態であり、本番クラスタには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。
+{{< /warning >}}
+
+<!-- body -->
+
+## エフェメラルコンテナを理解する
+
+{{< glossary_tooltip text="Pod" term_id="pod" >}}は、Kubernetesのアプリケーションの基本的なビルディングブロックです。Podは破棄可能かつ置き換え可能であることが想定されているため、一度Podが作成されると新しいコンテナを追加することはできません。その代わりに、通常は{{< glossary_tooltip text="Deployment" term_id="deployment" >}}を使用してPodを削除して置き換えます。
+
+たとえば、再現困難なバグのトラブルシューティングなどのために、すでに存在するPodの状態を調査する必要が出てくることがあります。このような場合、既存のPod内でエフェメラルコンテナを実行することで、Podの状態を調査したり、任意のコマンドを実行したりできます。
+
+### エフェメラルコンテナとは何か？
+
+エフェメラルコンテナは、他のコンテナと異なり、リソースや実行が保証されず、自動的に再起動されることも決してないため、アプリケーションを構築する目的には適しません。エフェメラルコンテナは、通常のコンテナと同じ`ContainerSpec`で記述されますが、多くのフィールドに互換性がなかったり、使用できなくなっています。
+
+- エフェメラルコンテナはポートを持つことができないため、`ports`、`livenessProbe`、`readinessProbe`などは使えなくなっています。
+- Podリソースの割り当てはイミュータブルであるため、`resources`の設定が禁止されています。
+- 利用が許可されているフィールドの一覧については、[EphemeralContainerのリファレンスドキュメント](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)を参照してください。
+
+エフェメラルコンテナは、直接`pod.spec`に追加するのではなく、API内の特別な`ephemeralcontainers`ハンドラを使用して作成します。そのため、エフェメラルコンテナを`kubectl edit`を使用して追加することはできません。
+
+エフェメラルコンテナをPodに追加した後は、通常のコンテナのようにエフェメラルコンテナを変更または削除することはできません。
+
+## エフェメラルコンテナの用途
+
+エフェメラルコンテナは、コンテナがクラッシュしてしまったり、コンテナイメージにデバッグ用ユーティリティが同梱されていない場合など、`kubectl exec`では不十分なときにインタラクティブなトラブルシューティングを行うために役立ちます。
+
+特に、[distrolessイメージ](https://github.com/GoogleContainerTools/distroless)を利用すると、攻撃対象領域を減らし、バグや脆弱性を露出する可能性を減らせる最小のコンテナイメージをデプロイできるようになります。distrolessイメージにはシェルもデバッグ用のユーティリティも含まれないため、`kubectl exec`のみを使用してdistrolessイメージのトラブルシューティングを行うのは困難です。
+
+エフェメラルコンテナを利用する場合には、他のコンテナ内のプロセスにアクセスできるように、[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にすると便利です。
+
+エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)を参照してください。
+
+## Ephemeral containers API
+
+{{< note >}}
+このセクションの例を実行するには、`EphemeralContainers`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、Kubernetesクライアントとサーバーのバージョンをv1.16以上にする必要があります。
+{{< /note >}}
+
+このセクションの例では、API内でエフェメラルコンテナを表示する方法を示します。通常は、APIを直接呼び出すのではなく、`kubectl alpha debug`やその他の`kubectl`[プラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)を使用して、これらのステップを自動化します。
+
+エフェメラルコンテナは、Podの`ephemeralcontainers`サブリソースを使用して作成されます。このサブリソースは、`kubectl --raw`を使用して確認できます。まずはじめに、以下に`EphemeralContainers`リストとして追加するためのエフェメラルコンテナを示します。
+
+```json
+{
+    "apiVersion": "v1",
+    "kind": "EphemeralContainers",
+    "metadata": {
+            "name": "example-pod"
+    },
+    "ephemeralContainers": [{
+        "command": [
+            "sh"
+        ],
+        "image": "busybox",
+        "imagePullPolicy": "IfNotPresent",
+        "name": "debugger",
+        "stdin": true,
+        "tty": true,
+        "terminationMessagePolicy": "File"
+    }]
+}
+```
+
+すでに実行中の`example-pod`のエフェメラルコンテナを更新するには、次のコマンドを実行します。
+
+```shell
+kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
+```
+
+このコマンドを実行すると、新しいエフェメラルコンテナのリストが返されます。
+
+```json
+{
+   "kind":"EphemeralContainers",
+   "apiVersion":"v1",
+   "metadata":{
+      "name":"example-pod",
+      "namespace":"default",
+      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
+      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
+      "resourceVersion":"15886",
+      "creationTimestamp":"2019-08-29T06:41:42Z"
+   },
+   "ephemeralContainers":[
+      {
+         "name":"debugger",
+         "image":"busybox",
+         "command":[
+            "sh"
+         ],
+         "resources":{
+
+         },
+         "terminationMessagePolicy":"File",
+         "imagePullPolicy":"IfNotPresent",
+         "stdin":true,
+         "tty":true
+      }
+   ]
+}
+```
+
+新しく作成されたエフェメラルコンテナの状態を確認するには、`kubectl describe`を使用します。
+
+```shell
+kubectl describe pod example-pod
+```
+
+```
+...
+Ephemeral Containers:
+  debugger:
+    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
+    Image:         busybox
+    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
+    Port:          <none>
+    Host Port:     <none>
+    Command:
+      sh
+    State:          Running
+      Started:      Thu, 29 Aug 2019 06:42:21 +0000
+    Ready:          False
+    Restart Count:  0
+    Environment:    <none>
+    Mounts:         <none>
+...
+```
+
+新しいエフェメラルコンテナとやりとりをするには、他のコンテナと同じように、`kubectl attach`、`kubectl exec`、`kubectl logs`などのコマンドが利用できます。例えば、次のようなコマンドが実行できます。
+
+```shell
+kubectl attach -it example-pod -c debugger
+```
@@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー

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

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

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

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

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

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

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

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

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

 <!-- overview -->

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

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

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


 <!-- body -->

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

-* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
-
-
+PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。