Merge pull request #22111 from shuuji3/fix-markdown-format
Fix Markdown syntax, rewrite some kanji to hiragana, and several minor errors
This commit is contained in:
Kubernetes Prow Robot
@@ -46,7 +46,7 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
|
||||
|
||||
例として、CronJobが`08:30:00`を開始時刻として1分ごとに新しいJobをスケジュールするように設定され、`startingDeadlineSeconds`フィールドが設定されていない場合を想定します。CronJobコントローラーが`08:29:00` から`10:21:00`の間にダウンしていた場合、スケジューリングを逃したジョブの数が100を超えているため、ジョブは開始されません。
|
||||
|
||||
このコンセプトを更に掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。
|
||||
このコンセプトをさらに掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。
|
||||
|
||||
CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ TTLコントローラーは、そのリソースが終了したあと指定し
|
||||
TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
|
||||
|
||||
* Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。
|
||||
* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。
|
||||
* この新しい機能を適用させるために、存在していてすでに終了したリソースに対してこのフィールドをセットします。
|
||||
* リソース作成時に、このフィールドを動的にセットするために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。クラスター管理者は、終了したリソースに対して、このTTLポリシーを強制するために使うことができます。
|
||||
* リソースが終了した後に、このフィールドを動的にセットしたり、リソースステータスやラベルなどの値に基づいて異なるTTL値を選択するために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 40
|
||||
このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。
|
||||
Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。
|
||||
|
||||
Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。
|
||||
Initコンテナは、Podの仕様のうち`containers`という配列(これがアプリケーションコンテナを示します)と並べて指定します。
|
||||
|
||||
<!-- body -->
|
||||
## Initコンテナを理解する {#understanding-init-containers}
|
||||
@@ -213,7 +213,7 @@ Podは全てのInitコンテナが完了するまで`Ready`状態となりませ
|
||||
Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。
|
||||
Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。
|
||||
|
||||
Initコンテナは何度も再起動およびリトライ可能なため、べき等（Idempotent）である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
|
||||
Initコンテナは何度も再起動およびリトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
|
||||
|
||||
Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。
|
||||
|
||||
@@ -230,11 +230,11 @@ Initコンテナの順序と実行を考えるとき、リソースの使用に
|
||||
* リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計
|
||||
* リソースに対する有効なinitリクエスト／リミット
|
||||
* スケジューリングは有効なリクエスト／リミットに基づいて実行されます。つまり、InitコンテナはPodの生存中には使用されない初期化用のリソースを確保することができます。
|
||||
* Podの*有効なQos（quality of service）ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
|
||||
* Podの*有効なQoS(quality of service)ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
|
||||
|
||||
クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。
|
||||
|
||||
Podレベルのコントロールグループ（cgroups）は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
|
||||
Podレベルのコントロールグループ(cgroups)は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
|
||||
|
||||
### Podの再起動の理由 {#pod-restart-reasons}
|
||||
|
||||
@@ -250,4 +250,3 @@ Podレベルのコントロールグループ（cgroups）は、スケジュー
|
||||
* [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。
|
||||
* [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。
|
||||
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共
|
||||
## Podを利用する
|
||||
|
||||
ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。
|
||||
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。
|
||||
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。
|
||||
|
||||
{{< note >}}
|
||||
単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
|
||||
@@ -111,7 +111,7 @@ spec:
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
|
||||
* [Pod](/ja/docs/concepts/workloads/pods/pod/)についてさらに学びましょう
|
||||
* Podの振る舞いに関して学ぶには下記を参照してください
|
||||
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
@@ -16,7 +16,7 @@ _Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な
|
||||
|
||||
## Podとは
|
||||
|
||||
_Pod_ は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
|
||||
_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
|
||||
|
||||
Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。
|
||||
|
||||
@@ -24,7 +24,7 @@ Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離す
|
||||
Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。
|
||||
|
||||
Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。
|
||||
また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。
|
||||
また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。
|
||||
異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。
|
||||
これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。
|
||||
|
||||
@@ -33,18 +33,18 @@ Pod内のアプリケーションからアクセスできる共有ボリュー
|
||||
|
||||
[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
|
||||
|
||||
個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。
|
||||
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
|
||||
個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。
|
||||
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。
|
||||
Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
|
||||
特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。
|
||||
代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。
|
||||
特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。
|
||||
代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。
|
||||
|
||||
ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは（そのUIDを持つ）Podが存在する限り存在することを意味します。
|
||||
そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。
|
||||
ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。
|
||||
そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
|
||||
|
||||
*file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
|
||||
*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
|
||||
|
||||
## Podを用いる動機
|
||||
|
||||
@@ -53,13 +53,13 @@ Nodeが停止した場合、そのNodeにスケジュールされたPodは、タ
|
||||
Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。
|
||||
構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。
|
||||
Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。
|
||||
Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
|
||||
Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
|
||||
|
||||
### リソース共有と通信
|
||||
|
||||
Podは、構成要素間でのデータ共有および通信を可能にします。
|
||||
|
||||
Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
|
||||
Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
|
||||
このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。
|
||||
各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。
|
||||
|
||||
@@ -71,7 +71,7 @@ Podで実行されるアプリケーションコンテナの定義に加えて
|
||||
|
||||
## Podの用途
|
||||
|
||||
Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。
|
||||
Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。
|
||||
しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。
|
||||
|
||||
* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
|
||||
@@ -83,11 +83,11 @@ Podは、垂直に統合されたアプリケーションスタック（例：LA
|
||||
個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。
|
||||
|
||||
詳細については、[The Distributed System ToolKit: Patterns for
|
||||
Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)（分散システムツールキット：複合コンテナのパターン）を参照してください。
|
||||
Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。
|
||||
|
||||
## 考えられる代替案
|
||||
|
||||
_単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？_
|
||||
_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_
|
||||
|
||||
1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。
|
||||
これは、ユーザーに多くの便益を提供します。
|
||||
@@ -97,13 +97,13 @@ Kubernetesはいつか個々のコンテナのライブアップデートをサ
|
||||
1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
|
||||
1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。
|
||||
|
||||
_アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
|
||||
_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
|
||||
|
||||
このアプローチによって、コンテナの共同配置は提供されるでしょう。
|
||||
しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。
|
||||
|
||||
|
||||
## Podの耐久性（またはその欠如）
|
||||
## Podの耐久性(またはその欠如) {#pod-durability}
|
||||
|
||||
Podは、耐久性のある存在として扱われることを意図していません。
|
||||
スケジューリングの失敗や、Nodeの故障には耐えられません。
|
||||
@@ -128,7 +128,7 @@ Podは、以下のことを容易にするためにプリミティブとして
|
||||
|
||||
## Podの終了 {#termination-of-pods}
|
||||
|
||||
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。
|
||||
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
|
||||
ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
|
||||
ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。
|
||||
猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。
|
||||
@@ -136,17 +136,17 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
|
||||
|
||||
フローの例は下のようになります。
|
||||
|
||||
1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する
|
||||
1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する
|
||||
1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
|
||||
1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
|
||||
1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
|
||||
1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
|
||||
1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
|
||||
猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
|
||||
猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
|
||||
1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
|
||||
1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
|
||||
ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
|
||||
1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
|
||||
ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
|
||||
1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
|
||||
1. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。
|
||||
1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。
|
||||
PodはAPIから消え、クライアントからは見えなくなる
|
||||
|
||||
デフォルトでは、すべての削除は30秒以内に正常に行われます。
|
||||
@@ -186,5 +186,3 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
|
||||
|
||||
PodはKubernetes REST APIのトップレベルのリソースです。
|
||||
APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user