Merge pull request #40034 from s-kawamura-w664/revise_pod_concept

[ja] remove pod-overview.md and update links

Author: k8s-ci-robot

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

@@ -49,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な
 
 `.spec.template`は`.spec`内での必須のフィールドの1つです。
 
-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。
+`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。
 
 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。
 

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

@@ -946,7 +946,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/
 
 `.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。
 
-`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては{{< glossary_tooltip text="Pod" term_id="pod" >}}と同じスキーマとなります。
+`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては{{< glossary_tooltip text="Pod" term_id="pod" >}}と同じスキーマとなります。
 
 Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
 

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

@@ -173,7 +173,7 @@ Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/deve
 
 `.spec.template`は`.spec`の唯一の必須フィールドです。
 
-`.spec.template`は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)です。ネストされていることと`apiVersion`や`kind`フィールドが不要になったことを除いて、仕様の定義が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
+`.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)を参照)と適切な再起動ポリシーを指定する必要があります。
 

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

@@ -193,7 +193,7 @@ ReplicaSetオブジェクトの名前は、有効な
 
 ### Pod テンプレート
 
-`.spec.template`はラベルを持つことが必要な[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
+`.spec.template`はラベルを持つことが必要な[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
 他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。
 
 テンプレートの[再起動ポリシー](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。

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

@@ -98,7 +98,7 @@ Kubernetes v{{< skew currentVersion >}}では、このフィールドに設定
 * {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
 * {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
 
-### Podテンプレート {#pod-template}
+### Podテンプレート {#pod-templates}
 
 {{< glossary_tooltip text="workload" term_id="workload" >}}リソース向けのコントローラーは、Podを*Podテンプレート*を元に作成し、あなたの代わりにPodを管理してくれます。
 

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

@@ -2,7 +2,7 @@
 title: Pod
 id: pod
 date: 2018-04-12
-full_link: /ja/docs/concepts/workloads/pods/pod-overview/
+full_link: /ja/docs/concepts/workloads/pods/
 short_description: >
   一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。
 

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

@@ -28,7 +28,7 @@ <h3>目標</h3>
 			<div class="col-md-8">
 			<h3>Kubernetes Serviceの概要</h3>
 
-			<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
+			<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
 
 			<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/ja/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>