commit first work from 1.19 milestone

This commit is contained in:
inductor
2021-05-26 10:10:10 +00:00
parent 6866260642
commit 73b3cf8784
134 changed files with 4305 additions and 2983 deletions
@@ -21,7 +21,7 @@ no_list: true
## コンテナイメージ
[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
## コンテナランタイム
@@ -30,11 +30,11 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
`PreStop`
このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
このフックは、APIからの要求、またはliveness probeの失敗、プリエンプション、リソース競合などの管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
これはブロッキング、つまり同期的であるため、コンテナを停止する信号が送信される前に完了する必要があります。
ハンドラーにパラメーターは渡されません。
終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
### フックハンドラーの実装
@@ -47,27 +47,32 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
### フックハンドラーの実行
コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはそのフック用に登録されたコンテナ内のハンドラーを実行します。
コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはフックアクションにしたがってハンドラーを実行します。
`exec``tcpSocket`はコンテナの中で実行され、`httpGet`はkubeletプロセスによって実行されます。
フックハンドラーの呼び出しは、コンテナを含むPodのコンテキスト内で同期しています。
これは、`PostStart`フックの場合、コンテナのENTRYPOINTとフックは非同期に起動することを意味します。
しかし、フックの実行に時間がかかりすぎたりハングしたりすると、コンテナは`running`状態になることができません。
その振る舞いは `PreStop`フックに似ています。
実行中にフックがハングした場合、Podフェーズ`Terminating`状態に留まり、Podの`terminationGracePeriodSeconds`が終了した後に終了します。
`PostStart`または`PreStop`フックが失敗した場合、コンテナを強制終了します。
`PreStop`フックはコンテナを停止する信号から非同期で実行されるのではなく、信号が送られる前に実行を完了する必要があります。
もし`PreStop`フックが実行中にハングした場合、Podは`Terminating`状態になり、
`terminationGracePeriodSeconds`の時間切れで強制終了されるまで続きます。
この猶予時間は、`PreStop`フックが実行され正常にコンテナを停止できるまでの合計時間に適用されます。
例えば`terminationGracePeriodSeconds`が60で、フックの終了に55秒かかり、シグナルを受信した後にコンテナを正常に停止させるのに10秒かかる場合、コンテナは正常に停止する前に終了されてしまいます。`terminationGracePeriodSeconds`が、これら2つの実行にかかる合計時間(55+10)よりも短いからです。
`PostStart`または`PreStop`フックが失敗した場合、コンテナは強制終了します。
ユーザーはフックハンドラーをできるだけ軽量にするべきです。
ただし、コンテナを停止する前に状態を保存する場合など、長時間実行されるコマンドが意味をなす場合があります。
ただし、コンテナを停止する前に状態を保存するなどの場合は、長時間のコマンド実行が必要なケースもあります。
### フック配保証
### フック配保証
フックの配*少なくとも1回* を意図しています。これはフックが`PostStart``PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。
フックの配*少なくとも1回* を意図しています。これはフックが`PostStart``PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。
これを正しく処理するのはフックの実装次第です。
通常、単一の配のみが行われます。
通常、1回の配のみが行われます。
たとえば、HTTPフックレシーバーがダウンしていてトラフィックを受け取れない場合、再送信は試みられません。
ただし、まれに二重配が発生することがあります。
ただし、まれに二重配が発生することがあります。
たとえば、フックの送信中にkubeletが再起動した場合、kubeletが起動した後にフックが再送信される可能性があります。
### フックハンドラーのデバッグ
@@ -101,4 +106,3 @@ Events:
* [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
@@ -48,10 +48,9 @@ weight: 10
`imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。
## マニフェストを使ったマルチアーキテクチャイメージ
## イメージインデックスを使ったマルチアーキテクチャイメージ
コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。
マニフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニフェストを参照できます。マニフェストの目的はイメージの名前(例:`pause``example/mycontainer``kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。
コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージインデックス](https://github.com/opencontainers/image-spec/blob/master/image-index.md)も提供する事ができます。イメージインデックスはコンテナのアーキテクチャ固有バージョンに関する複数の[イメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を指すことができます。イメージインデックスの目的はイメージの名前(例:`pause``example/mycontainer``kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。
Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つ名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。
@@ -179,7 +178,7 @@ Node構成を制御できる場合、この方法が適しています。
すべてのPodは事前にPullしたイメージへの読み取りアクセス権をもちます。
### PodでImagePullSecretsを指定する
### PodでimagePullSecretsを指定する
{{< note >}}
この方法がプライベートレジストリのイメージに基づいてコンテナを実行するための推奨の方法です。
@@ -187,7 +186,7 @@ Node構成を制御できる場合、この方法が適しています。
KubernetesはPodでのコンテナイメージレジストリキーの指定をサポートしています。
#### Docker Configを利用してSecretを作成する。
#### Dockerの設定を利用してSecretを作成する。
適切な大文字の値を置き換えて、次のコマンドを実行します。
@@ -149,7 +149,7 @@ PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによ
## {{% heading "whatsnext" %}}
- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む
- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- [Podオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)のコンセプトを読む
- [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)