Fix markdown. Rewrite some kanji to hiragana. Make parentheses half-width.
This commit is contained in:
TAKAHASHI Shuuji
@@ -16,7 +16,7 @@ _Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な
|
||||
|
||||
## Podとは
|
||||
|
||||
_Pod_ は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
|
||||
_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
|
||||
|
||||
Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。
|
||||
|
||||
@@ -24,7 +24,7 @@ Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離す
|
||||
Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。
|
||||
|
||||
Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。
|
||||
また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。
|
||||
また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。
|
||||
異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。
|
||||
これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。
|
||||
|
||||
@@ -33,18 +33,18 @@ Pod内のアプリケーションからアクセスできる共有ボリュー
|
||||
|
||||
[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
|
||||
|
||||
個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。
|
||||
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
|
||||
個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。
|
||||
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。
|
||||
Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
|
||||
特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。
|
||||
代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。
|
||||
特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。
|
||||
代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。
|
||||
|
||||
ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは（そのUIDを持つ）Podが存在する限り存在することを意味します。
|
||||
そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。
|
||||
ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。
|
||||
そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
|
||||
|
||||
*file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
|
||||
*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
|
||||
|
||||
## Podを用いる動機
|
||||
|
||||
@@ -53,13 +53,13 @@ Nodeが停止した場合、そのNodeにスケジュールされたPodは、タ
|
||||
Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。
|
||||
構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。
|
||||
Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。
|
||||
Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
|
||||
Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
|
||||
|
||||
### リソース共有と通信
|
||||
|
||||
Podは、構成要素間でのデータ共有および通信を可能にします。
|
||||
|
||||
Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
|
||||
Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
|
||||
このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。
|
||||
各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。
|
||||
|
||||
@@ -71,7 +71,7 @@ Podで実行されるアプリケーションコンテナの定義に加えて
|
||||
|
||||
## Podの用途
|
||||
|
||||
Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。
|
||||
Podは、垂直に統合されたアプリケーションスタック(例：LAMP)をホストするために使用できます。
|
||||
しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。
|
||||
|
||||
* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
|
||||
@@ -83,11 +83,11 @@ Podは、垂直に統合されたアプリケーションスタック（例：LA
|
||||
個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。
|
||||
|
||||
詳細については、[The Distributed System ToolKit: Patterns for
|
||||
Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)（分散システムツールキット：複合コンテナのパターン）を参照してください。
|
||||
Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。
|
||||
|
||||
## 考えられる代替案
|
||||
|
||||
_単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？_
|
||||
_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_
|
||||
|
||||
1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。
|
||||
これは、ユーザーに多くの便益を提供します。
|
||||
@@ -97,13 +97,13 @@ Kubernetesはいつか個々のコンテナのライブアップデートをサ
|
||||
1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
|
||||
1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。
|
||||
|
||||
_アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
|
||||
_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
|
||||
|
||||
このアプローチによって、コンテナの共同配置は提供されるでしょう。
|
||||
しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。
|
||||
|
||||
|
||||
## Podの耐久性（またはその欠如）
|
||||
## Podの耐久性(またはその欠如)
|
||||
|
||||
Podは、耐久性のある存在として扱われることを意図していません。
|
||||
スケジューリングの失敗や、Nodeの故障には耐えられません。
|
||||
@@ -128,7 +128,7 @@ Podは、以下のことを容易にするためにプリミティブとして
|
||||
|
||||
## Podの終了 {#termination-of-pods}
|
||||
|
||||
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。
|
||||
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
|
||||
ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
|
||||
ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。
|
||||
猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。
|
||||
@@ -136,17 +136,17 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
|
||||
|
||||
フローの例は下のようになります。
|
||||
|
||||
1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する
|
||||
1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する
|
||||
1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
|
||||
1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
|
||||
1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
|
||||
1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
|
||||
1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
|
||||
猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
|
||||
猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
|
||||
1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
|
||||
1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
|
||||
ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
|
||||
1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
|
||||
ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
|
||||
1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
|
||||
1. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。
|
||||
1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。
|
||||
PodはAPIから消え、クライアントからは見えなくなる
|
||||
|
||||
デフォルトでは、すべての削除は30秒以内に正常に行われます。
|
||||
|
||||
Reference in New Issue
Block a user