resolve conflict

2020-06-15 02:59:15 +09:00
parent c9472ad4b6 ce768c84b7
commit 298382169c
2451 changed files with 127381 additions and 564546 deletions
@@ -1,6 +1,6 @@
 ---
 title: Initコンテナ
-content_template: templates/concept
+content_type: concept
 weight: 40
 ---

@@ -11,7 +11,7 @@ Initコンテナにはアプリケーションコンテナのイメージに存
 Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。
 {{% /capture %}}

-{{% capture body %}}
+<!-- body -->
 ## Initコンテナを理解する {#understanding-init-containers}

 単一の{{< glossary_tooltip text="Pod" term_id="pod" >}}は、Pod内にアプリケーションを実行している複数のコンテナを持つことができますが、同様に、アプリケーションコンテナが起動する前に実行されるInitコンテナも1つ以上持つことができます。
@@ -245,11 +245,10 @@ Podレベルのコントロールグループ（cgroups）は、スケジュー
 * そのPodのインフラストラクチャーコンテナが再起動された場合。これはあまり起きるものでなく、Nodeに対するルート権限を持ったユーザーにより行われることがあります。
 * `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、再起動が行われた場合。およびガーベージコレクションによりInitコンテナの完了記録が失われた場合。

-{{% /capture %}}

 {{% capture whatsnext %}}

 * [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。
 * [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。

-{{% /capture %}}
+
@@ -1,17 +1,17 @@
 ---
 title: Podのライフサイクル
-content_template: templates/concept
+content_type: concept
 weight: 30
 ---

-{{% capture overview %}}
+<!-- overview -->

 このページではPodのライフサイクルについて説明します。

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## PodのPhase {#pod-phase}

@@ -332,10 +332,11 @@ spec:
     * NodeコントローラがPodの`phase`をFailedにします。
     * Podがコントローラで作成されていた場合は、別の場所で再作成されます。

-{{% /capture %}}


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

 * [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる

@@ -343,4 +344,4 @@ spec:

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

-{{% /capture %}}
+
@@ -1,18 +1,17 @@
 ---
 title: Podについての概観(Pod Overview)
-content_template: templates/concept
+content_type: concept
 weight: 10
-card: 
+card:
  name: concepts
  weight: 60
 ---

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


-{{% capture body %}}
+<!-- body -->
 ## Podについて理解する {#understanding-pods}

 *Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。
@@ -23,19 +22,19 @@ Podは、アプリケーションのコンテナ(いくつかの場合におい

 Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。

-* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。  
+* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。
 このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができ、Kubernetesはコンテナを直接扱うというよりは、Podを管理することになります。
-* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。  これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。  
+* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。  これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
 -- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。

-[Kubernetes Blog](https://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。  
+[Kubernetes Blog](https://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。

-  * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)  
+  * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
  * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)

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

 ### Podがどのように複数のコンテナを管理しているか
@@ -57,7 +56,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共

 #### ストレージ

-単一のPodは共有されたストレージ{{< glossary_tooltip term_id="volume" >}}のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。  
+単一のPodは共有されたストレージ{{< glossary_tooltip term_id="volume" >}}のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。
 単一のPod内での共有ストレージをKubernetesがどう実装しているかについてのさらなる情報については、[Volumes](/docs/concepts/storage/volumes/)を参照してください。

 ## Podを利用する
@@ -69,7 +68,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共
 単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
 {{< /note >}}

-Podは、Podそれ自体によって自己修復しません。もし、稼働されていないノード上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、ノードのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。  
+Podは、Podそれ自体によって自己修復しません。もし、稼働されていないノード上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、ノードのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。
 このように、Podを直接使うのは可能ですが、コントローラーを使用したPodを管理する方がより一般的です。KubernetesがPodのスケーリングと修復機能を実現するためにコントローラーをどのように使うかに関する情報は[Podとコントローラー](#pods-and-controllers)を参照してください。

 ### Podとコントローラー
@@ -88,7 +87,7 @@ Podは、Podそれ自体によって自己修復しません。もし、稼働

 Podテンプレートは、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)や、
 [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)のような他のオブジェクト内で含まれるPodの仕様となります。
-コントローラーは実際のPodを作成するためにPodテンプレートを使用します。  
+コントローラーは実際のPodを作成するためにPodテンプレートを使用します。
 下記のサンプルは、メッセージを表示する単一のコンテナを含んだ、シンプルなPodのマニフェストとなります。

 ```yaml
@@ -108,11 +107,12 @@ spec:
 全てのレプリカの現在の理想的な状態を指定するというよりも、Podテンプレートはクッキーの抜き型のようなものです。一度クッキーがカットされると、そのクッキーは抜き型から離れて関係が無くなります。そこにはいわゆる”量子もつれ”といったものはありません。テンプレートに対するその後の変更や新しいテンプレートへの切り替えは、すでに作成されたPod上には直接的な影響はありません。
 同様に、ReplicationControllerによって作成されたPodは、変更後に直接更新されます。これはPodとの意図的な違いとなり、そのPodに属する全てのコンテナの現在の理想的な状態を指定します。このアプローチは根本的にシステムのセマンティクスを単純化し、機能の柔軟性を高めます。

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 * [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
 * Podの振る舞いに関して学ぶには下記を参照してください
   * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)
   * [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
-{{% /capture %}}
+
@@ -1,18 +1,18 @@
 ---
 reviewers:
 title: Pod
-content_template: templates/concept
+content_type: concept
 weight: 20
 ---

-{{% capture overview %}}
+<!-- overview -->

 _Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## Podとは

@@ -187,4 +187,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
 PodはKubernetes REST APIのトップレベルのリソースです。
 APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。

-{{% /capture %}}
+
@@ -1,16 +1,16 @@
 ---
 reviewers:
 title: Pod Preset
-content_template: templates/concept
+content_type: concept
 weight: 50
 ---

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


-{{% capture body %}}
+
+<!-- body -->
 ## PodPresetを理解する

 `PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
@@ -57,10 +57,11 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ
  を追加することで可能になります。
 1.  ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。

-{{% /capture %}}

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

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

-{{% /capture %}}
+