First Japanese l10n work for release-1.14 (#16115)
* Translate concepts/workloads/pods/pod/ in Japanese (#13671) * [ja] Copy en/docs/concepts/workloads/pods/pod.md into ja/ * [ja] Translate docs/concepts/workloads/pods/pod/ * [ja] Modify translation of docs/concepts/workloads/pods/pod/ Reflect review - add trailing 'ー' to some technical terms * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * Translated cron-jobs.md in Japanese (#13937) * Translate cron-jobs.md in Japanese (#13392) * Update cron-jobs.md * Create automated-tasks-with-cron-jobs.md in Japanese directory * Fix translation (#13392) * Translate cron-jobs.md in Japanese (#13392) * Update cron-jobs.md * Create automated-tasks-with-cron-jobs.md in Japanese directory * Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory" This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d. * Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory" This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d. * Fix conflict (#13392) * Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory"" This reverts commit c5fc9d93d6d789a13a0a28ec4b85f9e7aeb81e38. * Revert "Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory""" This reverts commit 095e760c6deb620da548d06a851c8f7ade71a15d. * Fix that as it was pointed out (#13392) * Delete double same sesntence (#13392) * copy includes directory (#14020) * Translate docs/home/_index.md into Japanese (#14068) (#14074) * Translate concepts/overview/components.md into Japanese (#14067) * Translate glossaries used in concepts/overview/components.md into Japanese (#14044) * Translate concepts/overview/components.md into Japanese (#14044) * Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese (#13668) * Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese * Apply suggestions from code review Co-Authored-By: sotoiwa <sotoiwa@gmail.com> * Better translation from code review * Translate tasks/access-application-cluster/service-access-application-cluster/ in Japanese (#13701) * Update fluentd image (#13661) Signed-off-by: ialidzhikov <i.alidjikov@gmail.com> * update zh kubelet-config-file doc (#13495) * update zh kubelet-config-file doc * change kubelet config types address * add space between en words and zh words * revert en version change * correct container hyperlinks in init container (#12387) * correct container hyperlinks in init container * correct zh trans and update anchor inside page * Incorrect details about startingDeadlineSeconds.. (#13530) On this page, the default value of startingDeadlineSeconds is mentioned as 100 seconds which is not true. So removing this statement. * Fix typos (#13376) * add Nokia case study (#13676) * Fix typo in API page (#13687) Associated with #13686 * fix typo in pod-lifecycle (#13689) Asscociated with #13688 * issue 13383 * modify the link part * Revert "modify the link part" This reverts commit 2ae91dca574b54a14d255320721df4313346de28. * Revert "Revert "modify the link part"" This reverts commit e5b80b6258ce2210fc9a4b46e08fb8c000fe6330. * Revert "Revert "Revert "modify the link part""" This reverts commit 427916e7c6c4d6423222ff76b5fd8c12dc913ce1. * Revert "Merge remote-tracking branch 'origin/master' into issue_13383" This reverts commit 98099d805c7377826cb4d84bd0fece0f6362cb40, reversing changes made to 969e7f3f5cf63622e24137a2e374b0ab9e272514. * modify the link part * Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#14025) * Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#13952) * Apply suggestions to /concepts/overview/working-with-objects/kubernetes-objects/ from code review Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate concepts/overview/working-with-objects/names.md into Japanese (#14066) * Translate content/ja/docs/concepts/overview/working-with-objects/names.md into Japanese * Translate docs/reference/glossary/name.md into Japanese * Translate docs/reference/glossary/uid.md into Japanese * Apply suggestions to concepts/overview/working-with-objects/names.md from review comments * Translate concepts/overview/kubernetes-api.md into Japanese (#14343) * Translate concepts/overview/kubernetes-api.md into Japanese * Update translations for concepts/overview/kubernetes-api.md * Translate overview/working-with-objects/labels.md in Japanese (#14183) (#14319) * Translate overview/working-with-objects/labels.md in Japanese (#14183) * Update translations for concepts/overview/working-with-objects/labels.md. * Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426) (#14494) * Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426) * Update translation for concepts/workloads/pods/pod-overview.md. * Translate overview/working-with-objects/field-selectors.md in Japanese (#14350) (#14535) * Translate overview/working-with-objects/field-selectors.md in Japanese (#14350) * Update translations for concepts/overview/working-with-objects/field-selectors.md. * Update translation for concepts/overview/working-with-objects/field-selectors.md * Translate overview/working-with-objects/common-labels/ in Japanese (#14397) (#14403) * Translate overview/working-with-objects/common-labels/ in Japanese (#14397) * Update translation for concepts/overview/working-with-objects/common-labels.md * Translate concepts/storage/volume-snapshot-classes/ in Japanese (#14846) (#14849) * ja-trans: tasks/run-application/run-stateless-application-deployment/ (#14955) * ja-trans: tasks/run-application/run-stateless-application-deployment/ * modify "exploring" translation * ja-trans: concepts/containers/container-environment-variables/ (#14116) * ja-trans: concepts/containers/container-environment-variables/ * removed redundant expressions * ja-trans: Translate tasks/debug-application-cluster/get-shell-running… (#14146) * ja-trans: Translate tasks/debug-application-cluster/get-shell-running-container/ #13381 * Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md Fix typo Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * ja-trans: concepts/containers/container-lifecycle-hooks/ (#14169) * ja-trans: tasks/debug-application-cluster/debug-init-containers/ (#14488) * ja-trans: tasks/debug-application-cluster/debug-init-containers/ * modified traslation of should * Translate concepts/workloads/controllers/replicaset/ in Japanese (#14634) (#14641) * Translate concepts/workloads/controllers/replicaset.md in Japanese (#14634) * Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634) * Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634) * Translate concepts/overview/working-with-objects/annotations/ in Japanese (#13382) (#14396) * Translate overview/working-with-objects/annotations.md in Japanese (#13382) * Delete a empty line in concepts/overview/working-with-objects/annotations.md (#13382) * Update translation for concepts/overview/working-with-objects/anotations.md * ja-trans: tasks/run-application/scale-stateful-set/ (#15289) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/run-application/scale-stateful-set/ * Update content/ja/docs/tasks/run-application/scale-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/scale-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * added postpositional particle * ja-trans: tasks/debug-application-cluster/debug-stateful-set/ (#15282) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/debug-application-cluster/debug-stateful-set/ * ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/ (#14939) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/ * ja-trans: unify the ending of sentences * follow the master branch update * reflect a suggestion and modify translation of container * ja-trans: tasks/run-application/delete-stateful-set/ (#15293) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/run-application/delete-stateful-set/ * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * modified traslation of backing * ja-trans: tasks/configure-pod-container/attach-handler-lifecycle-event/ (#14328) * Translate overview/working-with-objects/namespaces.md in Japanese (#14045) (#14161) * Translate overview/working-with-objects/namespaces.md in Japanese (#14045) * Update translations for concepts/overview/working-with-objects/namespaces.md * ja-trans: fix Japanese Translation in concepts/overview/working-with-objects/namespaces.md (#14045) * ja-trans: includes/default-storage-class-prereqs.md (#15376) * ja-trans: includes/default-storage-class-prereqs.md * Update content/ja/includes/default-storage-class-prereqs.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate tasks/run-application/run-replicated-stateful-application/ in Japanese (#15368) * Translate tasks/run-application/run-replicated-stateful-application/ in Japanese * add a base document in english * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * small fixs 「複製」という言葉を使わず「レプリケーション」と「クローン」に使い分けるように変更。 「ステートフルなアプリケーション」を「ステートフルアプリケーション」に変更。 * small fix * Translate concepts/workloads/pods/init-containers.md in Japanese (#14543) (#14576) * Translate concepts/workloads/pods/init-containers.md in Japanese (#14543) * Improve japanese translation in concepts/workloads/pods/init-containers.md (#14543) * Add new line in ja/concepts/workloads/pods/init-containers.md (#14543) * Add new line in ja/concepts/workloads/pods/init-containers.md (#14543) * translate contribute/_index.md to japanese. (#15406) * translate contribute/_index.md to japanese. * trim spaces. * Add missing translation. * Translate concepts/workloads/controllers/daemonset/ in Japanese #14761 (#14767) * Translate concepts/workloads/controllers/daemonset/ in Japanese (#14761) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/daemonset.md (#14767) * Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718) (#14720) * Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/garbage-collection.md (#14718) * Translate concepts/workloads/pods/podpreset/ in Japanese (#14544) (#14581) * Translate concepts/workloads/pods/podpreset.md in Japanese (#14544) * Update translation for concepts/workloads/pods/podpreset.md. * ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544) * ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544) * ja-trans: Delete translated sentence in concepts/workloads/pods/podpreset (#14544) * ja-trans: Delete duplicated sentence in concepts/workloads/pods/podpreset (#14544) * Translate concepts/containers/runtime-class/ in Japanese (#14670) (#14673) * Translate concepts/containers/runtime-class.md in Japanese (#14670) * ja-trans: Improve Japanese translation in concepts/containers/runtime-class.md (#14670) * Translate concepts/services-networking/dns-pod-service/ in Japanese #14777 (#14805) * Translate concepts/services-networking/dns-pod-service/ in Japanese (#14777) * ja-trans: Improve Japanese translation in concepts/services-networking/dns-pod-service.md (#14777) * Translate concepts/workloads/controllers/statefulset/ in Japanese #14679 (#14696) * Translate concepts/workloads/controllers/statefulset.md in Japanese (#14679) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some Japanese translation in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some titles in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some Japanese translations in concepts/workloads/controllers/statefulset.md (#14679) * Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese #14734 (#14735) * Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese (#14734) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/ttlafterfinished.md (#14734) * ja-trans: Delete some Japanese words in concepts/workloads/controllers/ttlafterfinished.md (#14734) * ja-trans: Fix typo in concepts/workloads/controllers/ttlafterfinished.md (#14734) * Translate concepts/storage/dynamic-provisioning/ in Japanese #14847 (#14916) * Translate concepts/storage/dynamic-provisioning/ in Japanese (#14847) * ja-trans: Improve Japanese translation in concepts/storage/dynamic-provisioning.md (#14847) * ja-trans: Improve some Japanese translation in concepts/storage/dynamic-provisioning.md (#14847) * ja-trans: Improve some Japanese translations in concepts/storage/dynamic-provisioning.md (#14847)
This commit is contained in:
Takuya Tokuda
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
6c4a4d8152
commit
abde921399
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
@@ -0,0 +1,276 @@
|
||||
---
|
||||
title: Initコンテナ(Init Containers)
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページでは、Initコンテナについて概観します。Initコンテナとは、アプリケーションコンテナの前に実行され、アプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含んだ特別なコンテナです。
|
||||
{{% /capture %}}
|
||||
|
||||
この機能はKubernetes1.6からβ版の機能として存在しています。InitコンテナはPodSpec内で、アプリケーションの`containers`という配列と並べて指定されます。そのベータ版のアノテーション値はまだ扱われ、PodSpecのフィールド値を上書きします。しかしながら、それらはKubernetesバージョン1.6と1.7において廃止されました。Kubernetesバージョン1.8からはそのアノテーション値はサポートされず、PodSpecフィールドの値に変換する必要があります。
|
||||
|
||||
{{% capture body %}}
|
||||
## Initコンテナを理解する
|
||||
|
||||
単一の[Pod](/docs/concepts/workloads/pods/pod-overview/)は、Pod内に複数のコンテナを稼働させることができますが、Initコンテナもまた、アプリケーションコンテナが稼働する前に1つまたは複数稼働できます。
|
||||
|
||||
Initコンテナは下記の項目をのぞいて、通常のコンテナと全く同じものとなります。
|
||||
|
||||
* Initコンテナは常に完了するまで稼働します。
|
||||
* 各Initコンテナは、次のInitコンテナが稼働する前に正常に完了しなくてはなりません。
|
||||
|
||||
もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`が`Never`の場合、再起動されません。
|
||||
|
||||
単一のコンテナをInitコンテナとして指定するためには、PodSpecにそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトのJSON配列として指定してください。
|
||||
Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。
|
||||
|
||||
### 通常のコンテナとの違い
|
||||
|
||||
Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは微妙に異なり、下記の[Resources](#resources)にて説明します。また、InitコンテナはそのPodの準備ができ前に完了しなくてはならないため、`readinessProbe`をサポートしていません。
|
||||
|
||||
もし複数のInitコンテナが単一のPodに対して指定された場合、それらのInitコンテナは1つずつ順番に実行されます。各Initコンテナは次のコンテナが完了できる前に完了しなくてはなりません。全てのInitコンテナが実行完了した時、KubernetesはPodを初期化し、通常通りアプリケーションコンテナを稼働させます。
|
||||
|
||||
## Initコンテナは何に使用できるか?
|
||||
|
||||
Initコンテナはアプリケーションコンテナのイメージとは分離されているため、コンテナの起動に関連したコードにおいていくつかの利点があります。
|
||||
|
||||
* セキュリティの理由からアプリケーションコンテナのイメージに含めたくないユーティリティーを含んだり実行できます。
|
||||
* アプリケーションのイメージに存在していないセットアップ用のユーティリティーやカスタムコードを含むことができます。例えば、セットアップ中に`sed`、`awk`、`python`や、`dig`のようなツールを使うための他のイメージから、アプリケーションのイメージを作る必要がなくなります。
|
||||
* アプリケーションイメージをひとまとめにしてビルドすることなく、アプリケーションのイメージ作成と、デプロイ処理を独立して行うことができます。
|
||||
* アプリケーションコンテナと別のファイルシステムビューを持つために、Linuxの名前空間を使用します。その結果、アプリケーションコンテナがアクセスできない箇所へのシークレットなアクセス権限を得ることができます。
|
||||
* Initコンテナはアプリケーションコンテナの実行の前に完了しますが、その一方で、複数のアプリケーションコンテナは並列に実行されます。そのためInitコンテナはいくつかの前提条件をセットされるまで、アプリケーションコンテナの起動をブロックしたり遅らせることができます。
|
||||
|
||||
### 使用例
|
||||
|
||||
ここではInitコンテナの使用例を挙げます。
|
||||
|
||||
* シェルコマンドを使って単一のServiceが作成されるのを待機します。
|
||||
|
||||
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
|
||||
|
||||
* コマンドを使って下位のAPIからこのPodをリモートサーバに登録します。
|
||||
|
||||
`curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'`
|
||||
|
||||
* `sleep 60`のようなコマンドを使ってアプリケーションコンテナが起動する前に待機します。
|
||||
* ボリュームにあるgitリポジトリをクローンします。
|
||||
* メインのアプリケーションコンテナのための設定ファイルを動的に生成するために、いくつかの値を設定ファイルに移してテンプレートツールを稼働させます。例えば、設定ファイルにそのPodのPOD_IPを移して、Jinjaを使ってメインのアプリケーションコンテナの設定ファイルを生成します。
|
||||
|
||||
さらに詳細な使用例は、[StatefulSetsのドキュメント](/docs/concepts/workloads/controllers/statefulset/)と[Production Pods guide](/docs/tasks/configure-pod-container/configure-pod-initialization/)にまとまっています。
|
||||
|
||||
### Initコンテナの使用
|
||||
|
||||
下記のKubernetes1.5用のyamlファイルは、2つのInitコンテナを含む単一のシンプルなポッドの概要となります。
|
||||
最初のInitコンテナの例は、`myservies`、2つ目のInitコンテナは`mydb`の起動をそれぞれ待ちます。2つのコンテナの実行が完了するとPodの起動が始まります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
annotations:
|
||||
pod.beta.kubernetes.io/init-containers: '[
|
||||
{
|
||||
"name": "init-myservice",
|
||||
"image": "busybox:1.28",
|
||||
"command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
|
||||
},
|
||||
{
|
||||
"name": "init-mydb",
|
||||
"image": "busybox:1.28",
|
||||
"command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
|
||||
}
|
||||
]'
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox:1.28
|
||||
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
|
||||
```
|
||||
|
||||
古いアノテーション構文がKubernetes1.6と1.7において有効ですが、1.6では新しい構文にも対応しています。Kubernetes1.8以降では新しい構文はを使用する必要があります。KubernetesではInitコンテナの宣言を`spec`に移行させました。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox:1.28
|
||||
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
|
||||
initContainers:
|
||||
- name: init-myservice
|
||||
image: busybox:1.28
|
||||
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
|
||||
- name: init-mydb
|
||||
image: busybox:1.28
|
||||
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
|
||||
```
|
||||
|
||||
Kubernetes1.5での構文は1.6においても稼働しますが、1.6の構文の使用を推奨します。Kubernetes1.6において、API内でInitコンテナのフィールド作成されます。ベータ版のアノテーションはKubernetes1.6と1.7において有効ですが、1.8以降ではサポートされません。
|
||||
|
||||
下記のyamlファイルは`mydb`と`myservice`というServiceの概要です。
|
||||
|
||||
```yaml
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: myservice
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
---
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mydb
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9377
|
||||
```
|
||||
|
||||
このPodは、下記のコマンドによって起動とデバッグすることが可能です。
|
||||
|
||||
```shell
|
||||
kubectl apply -f myapp.yaml
|
||||
```
|
||||
```
|
||||
pod/myapp-pod created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get -f myapp.yaml
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 0/1 Init:0/2 0 6m
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl describe -f myapp.yaml
|
||||
```
|
||||
```
|
||||
Name: myapp-pod
|
||||
Namespace: default
|
||||
[...]
|
||||
Labels: app=myapp
|
||||
Status: Pending
|
||||
[...]
|
||||
Init Containers:
|
||||
init-myservice:
|
||||
[...]
|
||||
State: Running
|
||||
[...]
|
||||
init-mydb:
|
||||
[...]
|
||||
State: Waiting
|
||||
Reason: PodInitializing
|
||||
Ready: False
|
||||
[...]
|
||||
Containers:
|
||||
myapp-container:
|
||||
[...]
|
||||
State: Waiting
|
||||
Reason: PodInitializing
|
||||
Ready: False
|
||||
[...]
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201
|
||||
16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox"
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox"
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
|
||||
```
|
||||
```shell
|
||||
kubectl logs myapp-pod -c init-myservice # 1つ目のInitコンテナを調査する
|
||||
kubectl logs myapp-pod -c init-mydb # 2つ目のInitコンテナを調査する
|
||||
```
|
||||
|
||||
一度`mydq`と`myservice` Serviceを起動させると、Initコンテナが完了して`myapp-pod`が作成されるのを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl apply -f services.yaml
|
||||
```
|
||||
```
|
||||
service/myservice created
|
||||
service/mydb created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get -f myapp.yaml
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 1/1 Running 0 9m
|
||||
```
|
||||
|
||||
この例は非常にシンプルですが、ユーザー独自のInitコンテナを作成するためのインスピレーションを提供するでしょう。
|
||||
|
||||
## Initコンテナのふるまいに関する詳細
|
||||
|
||||
単一のPodが起動している間、ネットワークとボリュームが初期化されたのちに、Initコンテナは順番に起動されます。各Initコンテナは次のInitコンテナが起動する前に完了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値をもとにリトライされます。しかし、もしPodの`retartPolicy`が`Always`に設定されていた場合、そのInitコンテナの`restartPolicy`は`OnFailure`となります。
|
||||
|
||||
Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initializing`という値はtrueとなります。
|
||||
|
||||
もしそのPodが[再起動](#pod-restart-reasons)されたとき、全てのInitコンテナは再度実行されなくてはなりません。
|
||||
|
||||
Initコンテナのスペックに対する変更はコンテナのイメージフィールドのみに限定されます。
|
||||
Initコンテナのイメージフィールド値の変更は、そのPodの再起動することと等しいです。
|
||||
|
||||
Initコンテナは何度も再起動、リトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れるべきです。
|
||||
|
||||
Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に強要されます。
|
||||
|
||||
Initコンテナがずっと失敗し続けたままの状態を防ぐために、Podに`activeDeadlineSeconds`、コンテナに`livenessProbe`の設定をそれぞれ使用してください。`activeDeadlineSeconds`の設定はInitコンテナにも適用されます。
|
||||
|
||||
あるPod内の各アプリケーションコンテナとInitコンテナの名前はユニークである必要があります。他のコンテナと同じ名前を共有していた場合、バリデーションエラーが返されます。
|
||||
|
||||
### リソース
|
||||
|
||||
Initコンテナの順序と実行を考えるとき、リソースの使用に関して下記のルールが適用されます。
|
||||
|
||||
* 全てのInitコンテナの中で定義された最も高いリソースリクエストとリソースリミットが、*有効なInitリクエストとリミット* になります。
|
||||
* Podのリソースの*有効なリクエストとリミット* は、下記の2つの中のどちらか高い方となります。
|
||||
* そのリソースの全てのアプリケーションコンテナのリクエストとリミットの合計
|
||||
* そのリソースの有効なInitリクエストとリミット
|
||||
* スケジューリングは有効なリクエストとリミットに基づいて実行されます。これはInitコンテナがそのPodの生存中に使われない初期化のためのリソースを保持することができることを意味しています。
|
||||
* Podの*有効なQosティアー* は、Initコンテナとアプリケーションコンテナで同様です。
|
||||
|
||||
クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。
|
||||
|
||||
Podレベルのcgroupsは、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
|
||||
|
||||
### Podの再起動の理由
|
||||
|
||||
単一のPodは再起動可能で、Initコンテナの再実行も引き起こします。それらは下記の理由によるものです。
|
||||
|
||||
* あるユーザーが、そのPodのInitコンテナのイメージを変更するようにPodSpecを更新する場合。アプリケーションコンテナのイメージの変更はそのアプリケーションコンテナの再起動のみ行われます。
|
||||
* そのPodのインフラストラクチャーコンテナが再起動された場合。これはあまり起きるものでなく、Nodeに対するルート権限を持ったユーザーにより行われることがあります。
|
||||
* `restartPolicy`が`Always`と設定されているとき、単一Pod内の全てのコンテナが停止され、再起動が行われた時と、ガーベージコレクションによりInitコンテナの完了記録が失われた場合。
|
||||
|
||||
## サポートと互換性
|
||||
|
||||
ApiServerのバージョン1.6.0かそれ以上のバージョンのクラスターは、`.spec.initContainers`フィールドを使ったInitコンテナの機能をサポートしています。
|
||||
それ以前のバージョンでは、α版かβ版のアノテーションを使ってInitコンテナを使用できます。また、`.spec.initContainers`フィールドは、Kubernetes1.3.0かそれ以上のバージョンでInitコンテナを使用できるようにするためと、ApiServerバージョン1.6において、1.5.xなどの古いバージョンにロールバックできるようにするために、α版かβ版のアノテーションにミラーされ、存在するPodのInitコンテナの機能が失われることが無いように安全にロールバックできるようにします。
|
||||
|
||||
ApiServerとKubeletバージョン1.8.0かそれ以上のバージョンでは、α版とβ版のアノテーションは削除されており、廃止されたアノテーションは`.spec.initContainers`フィールドへの移行が必須となります。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Initコンテナを持っているPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
title: Podについての概観(Pod Overview)
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
## Podについて理解する
|
||||
|
||||
*Pod* は、Kubernetesの基本的なビルディングブロックとなります。Kubernetesオブジェクトモデルの中で、ユーザーが作成し、デプロイ可能なシンプルで最も最小のユニットです。単一のPodはクラスター上で稼働する単一のプロセスを表現します。
|
||||
|
||||
単一のPodは、アプリケーションコンテナ（いくつかの場合においては複数のコンテナ）や、ストレージリソース、ユニークなネットワークIPや、コンテナがどのように稼働すべきか統制するためのオプションをカプセル化します。単一のPodは、ある単一のDeploymentのユニット(単一のコンテナもしくはリソースを共有する、密接に連携された少数のコンテナ群を含むような*Kubernetes内でのアプリケーションの単一のインスタンス*) を表現します。
|
||||
|
||||
> [Docker](https://www.docker.com)はKubernetesのPod内で使われる最も一般的なコンテナランタイムですが、Podは他のコンテナランタイムも同様にサポートしています。
|
||||
|
||||
Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。
|
||||
|
||||
* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。
|
||||
このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができ、Kubernetesはコンテナを直接扱うというよりは、Podを管理することになります。
|
||||
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
|
||||
-- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。
|
||||
|
||||
[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。
|
||||
さらなる情報を得たい場合は、下記のページを参照ください。
|
||||
|
||||
* [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は、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。
|
||||
さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。
|
||||
|
||||
### Podがどのように複数のコンテナを管理しているか
|
||||
|
||||
Podは凝集性の高いサービスのユニットを構成するような複数の協調プロセス(コンテナ）をサポートするためにデザインされました。
|
||||
単一のPod内のコンテナ群は、クラスター内において同一の物理マシンもしくは仮想マシン上において自動で同じ環境に配備され、スケジュールされます。コンテナはリソースや依存関係を共有し、お互いにコミュニケートし、それらがいつ、どのように削除されるかを調整できます。
|
||||
|
||||
注意点として、単一のPod内で同じ環境に配備され、同時管理される複数のコンテナをグルーピングするのは、比較的に発展的なユースケースとなります。
|
||||
ユーザーは、コンテナ群が密接に連携するような、特定のインスタンスにおいてのみこのパターンを使用するべきです。
|
||||
例えば、ユーザーが共有ボリューム内にあるファイル用のWebサーバとして稼働するコンテナと、下記のダイアグラムにあるような、リモートのソースからファイルを更新するような分離された*サイドカー* コンテナを持っているような場合です。
|
||||
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="Podのダイアグラム" width="50%" >}}
|
||||
|
||||
Podは、Podによって構成されたコンテナ群のために2種類の共有リソースを提供します。 *ネットワーキング* と*ストレージ* です。
|
||||
|
||||
#### ネットワーキング
|
||||
|
||||
各Podは固有のIPアドレスを割り当てられます。単一のPod内の各コンテナは、IPアドレスやネットワークポートを含む、そのネットワークの名前空間を共有します。*Pod内の* コンテナは`localhost`を使用してお互いに疎通できます。単一のPod内のコンテナが*Pod外* のエンティティと疎通する場合、共有されたネットワークリソース(ポートなど）をどのように使うかに関して調整しなければなりません。
|
||||
|
||||
#### ストレージ
|
||||
|
||||
単一のPodは共有されたストレージ*ボリューム* のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。
|
||||
単一のPod内での共有ストレージをKubernetesがどう実装しているかについてのさらなる情報については、[Volumes](/docs/concepts/storage/volumes/)を参照してください。
|
||||
|
||||
## Podを利用する
|
||||
|
||||
ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。
|
||||
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一のNode上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、Nodeが故障するまでNode上に残り続けます。
|
||||
|
||||
{{< note >}}
|
||||
単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
|
||||
{{< /note >}}
|
||||
|
||||
Podは、Podそれ自体によって自己修復しません。もし、稼働されていないNode上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、Nodeのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。
|
||||
このように、Podを直接使うのは可能ですが、コントローラーを使用したPodを管理する方がより一般的です。KubernetesがPodのスケーリングと修復機能を実現するためにコントローラーをどのように使うかに関する情報は[Podとコントローラー](#pods-and-controllers)を参照してください。
|
||||
|
||||
### Podとコントローラー
|
||||
|
||||
単一のコントローラーは、ユーザーのために複数のPodを作成・管理し、レプリケーションやロールアウト、クラスターのスコープ内で自己修復の機能をハンドリングします。例えば、もしNodeが故障した場合、コントローラーは異なるNode上にPodを置き換えるようにスケジューリングすることで、自動的にリプレース可能となります。
|
||||
|
||||
1つまたはそれ以上のPodを含むコントローラーの例は下記の通りです。
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
通常は、コントローラーはユーザーが作成したPodテンプレートを使用して、担当するPodを作成します。
|
||||
|
||||
## Podテンプレート
|
||||
|
||||
Podテンプレートは、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)や、
|
||||
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のような他のオブジェクト内で含まれるPodの仕様となります。
|
||||
コントローラーは実際のPodを作成するためにPodテンプレートを使用します。
|
||||
下記のサンプルは、メッセージを表示する単一のコンテナを含んだ、シンプルなPodのマニフェストとなります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
|
||||
```
|
||||
|
||||
全てのレプリカの現在の理想的な状態を指定するというよりも、Podテンプレートはクッキーの抜き型のようなものです。一度クッキーがカットされると、そのクッキーは抜き型から離れて関係が無くなります。そこにはいわゆる”量子もつれ”といったものはありません。テンプレートに対するその後の変更や新しいテンプレートへの切り替えは、すでに作成されたPod上には直接的な影響はありません。
|
||||
同様に、ReplicationControllerによって作成されたPodは、変更後に直接更新されます。これはPodとの意図的な違いとなり、そのPodに属する全てのコンテナの現在の理想的な状態を指定します。このアプローチは根本的にシステムのセマンティクスを単純化し、機能の柔軟性を高めます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Podの振る舞いに関して学ぶには下記を参照してください。
|
||||
* [Podの停止](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,190 @@
|
||||
---
|
||||
reviewers:
|
||||
title: Pod
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Podとは
|
||||
|
||||
_Pod_ は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
|
||||
|
||||
Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。
|
||||
|
||||
Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離する一連の要素と同じものがコンテキストとして共有されます。
|
||||
Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。
|
||||
|
||||
Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。
|
||||
また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。
|
||||
異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。
|
||||
これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。
|
||||
|
||||
Pod内のアプリケーションからアクセスできる共有ボリュームを、Podの一部として定義できます。
|
||||
このボリュームは個々のアプリケーションのファイルシステムにマウント可能です。
|
||||
|
||||
[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
|
||||
|
||||
個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。
|
||||
[Podのライフサイクル](/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を持つ）Podが存在する限り存在することを意味します。
|
||||
そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
|
||||
|
||||
*file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
|
||||
|
||||
## Podを用いる動機
|
||||
|
||||
### 管理
|
||||
|
||||
Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。
|
||||
構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。
|
||||
Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。
|
||||
Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
|
||||
|
||||
### リソース共有と通信
|
||||
|
||||
Podは、構成要素間でのデータ共有および通信を可能にします。
|
||||
|
||||
Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
|
||||
このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。
|
||||
各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。
|
||||
|
||||
Pod内のアプリケーションコンテナのホスト名には、Podの名前が設定されます。
|
||||
詳細は[クラスターネットワーク](/docs/concepts/cluster-administration/networking/)をご覧ください。
|
||||
|
||||
Podで実行されるアプリケーションコンテナの定義に加えて、Podによって共有ストレージであるボリュームを複数設定することも可能です。
|
||||
ボリュームを使用すると、データはコンテナの再起動後も存続し、Pod内のアプリケーション間で共有できます。
|
||||
|
||||
## Podの用途
|
||||
|
||||
Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。
|
||||
しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。
|
||||
|
||||
* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
|
||||
* ログとチェックポイントのバックアップ、圧縮、ローテーション、スナップショットなど
|
||||
* データの変更を監視するもの、ログをtailするもの、ロギングおよび監視の補助プログラム、イベントを発行するものなど
|
||||
* プロキシ、ブリッジ、およびアダプタ
|
||||
* コントローラー、マネージャー、コンフィギュレーター、およびアップデーター
|
||||
|
||||
個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。
|
||||
|
||||
詳細については、[The Distributed System ToolKit: Patterns for
|
||||
Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)（分散システムツールキット：複合コンテナのパターン）を参照してください。
|
||||
|
||||
## 考えられる代替案
|
||||
|
||||
_単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？_
|
||||
|
||||
1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。
|
||||
これは、ユーザーに多くの便益を提供します。
|
||||
1. ソフトウェアの依存関係を減らすため。
|
||||
個々のコンテナは、独立してバージョン管理、再構築、および再デプロイできます。
|
||||
Kubernetesはいつか個々のコンテナのライブアップデートをサポートするかもしれません。
|
||||
1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
|
||||
1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。
|
||||
|
||||
_アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
|
||||
|
||||
このアプローチによって、コンテナの共同配置は提供されるでしょう。
|
||||
しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。
|
||||
|
||||
|
||||
## Podの耐久性（またはその欠如）
|
||||
|
||||
Podは、耐久性のある存在として扱われることを意図していません。
|
||||
スケジューリングの失敗や、Nodeの故障には耐えられません。
|
||||
リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。
|
||||
|
||||
一般に、ユーザーはPodを直接作成する必要はありません。
|
||||
ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。
|
||||
コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。
|
||||
[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)ようなコントローラーもステートフルなPodをサポートします。
|
||||
|
||||
主要なユーザー向けのプリミティブとして集合APIを使用することは、[Borg](https://research.google.com/pubs/pub43438.html)、 [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、[Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)などのクラスタースケジューリングシステムで比較的一般的です。
|
||||
|
||||
Podは、以下のことを容易にするためにプリミティブとして公開されています。
|
||||
|
||||
* スケジューラーとコントローラーをプラガブルにする
|
||||
* コントローラーAPIを介して「プロキシ」の必要なしに、Podレベルの操作をサポートする
|
||||
* ブートストラップなどのために、コントローラーの寿命からPodの寿命を切り離す
|
||||
* コントローラーとサービスを分離する――エンドポイントコントローラーはPodのみを監視する
|
||||
* Kubeletレベルの機能とクラスターレベルの機能をきれいに組み合わせる――Kubeletは事実上「Podコントローラー」となる
|
||||
* アプリケーションの可用性を高める。
|
||||
即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する
|
||||
|
||||
## Podの終了
|
||||
|
||||
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。
|
||||
ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
|
||||
ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。
|
||||
猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。
|
||||
プロセスの終了を待っている間にKubeletかコンテナマネージャーが再起動されると、終了処理は猶予期間の後にリトライされます。
|
||||
|
||||
フローの例は下のようになります。
|
||||
|
||||
1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する
|
||||
1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
|
||||
1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
|
||||
1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
|
||||
1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
|
||||
猶予期間が終了した後も `preStop` フックがまだ実行されている場合は、次に、短い延長された猶予期間（2秒）でステップ2が呼び出される
|
||||
1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
|
||||
1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
|
||||
ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
|
||||
1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
|
||||
1. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。
|
||||
PodはAPIから消え、クライアントからは見えなくなる
|
||||
|
||||
デフォルトでは、すべての削除は30秒以内に正常に行われます。
|
||||
`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=<seconds>` オプションをサポートします。
|
||||
値 `0` はPodを[強制的に削除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)します。
|
||||
kubectlのバージョン1.5以降では、強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。
|
||||
|
||||
### Podの強制削除
|
||||
|
||||
Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。
|
||||
強制削除が実行されると、apiserverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。
|
||||
API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。
|
||||
Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。
|
||||
|
||||
強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。
|
||||
StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
|
||||
|
||||
## Podコンテナの特権モード
|
||||
|
||||
Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。
|
||||
これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。
|
||||
コンテナ内のプロセスは、コンテナ外のプロセスで利用できるものとほぼ同じ特権を獲得します。
|
||||
特権モードでは、ネットワークプラグインとボリュームプラグインを別々のPodとして作成する方が簡単なはずです。それらをkubeletにコンパイルする必要はありません。
|
||||
|
||||
マスターがKubernetes v1.1以降を実行しており、Nodeがv1.1より前のバージョンを実行している場合、新しい特権付きのPodはAPIサーバーに受け入れられますが、起動されません。
|
||||
それらは保留状態になります。
|
||||
ユーザーが `kubectl describe pod FooPodName` を実行すると、Podが保留状態になっている理由を確認できます。
|
||||
describeコマンド出力のイベントテーブルには、次のように表示されます。
|
||||
`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
|
||||
|
||||
マスターがv1.1より前のバージョンを実行している場合、特権を持つPodは作成できません。
|
||||
ユーザーが特権付きのコンテナを含むPodを作成しようとすると、次のエラーを受け取ります。
|
||||
`The Pod "FooPodName" is invalid.
|
||||
spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
|
||||
|
||||
## APIオブジェクト
|
||||
|
||||
PodはKubernetes REST APIのトップレベルのリソースです。
|
||||
APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
reviewers:
|
||||
title: Pod Preset
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
## PodPresetを理解する
|
||||
|
||||
`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
|
||||
ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
|
||||
|
||||
PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。
|
||||
この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
|
||||
|
||||
PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。
|
||||
|
||||
## PodPresetはどのように動くか
|
||||
|
||||
Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。
|
||||
Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。
|
||||
|
||||
1. 使用可能な全ての`PodPreset`を取得する。
|
||||
1. それらの`PodPreset`のラベルセレクターが、作成されたPod上のラベルと一致するかチェックする。
|
||||
1. `PodPreset`によって定義された様々なリソースを、作成されたPodにマージしようと試みる。
|
||||
1. エラーが起きた時、そのPod上でマージエラーが起きたことを説明するイベントをスローし、`PodPreset`からリソースを1つも注入されていないPodを作成します。
|
||||
1. `PodPreset`によって修正されたことを示すために、マージ後の修正されたPodにアノテーションをつけます。そのアノテーションは`podpreset.admission.kubernetes.io/podpreset-<PodPreset名>: "<リソースのバージョン>"`という形式になります。
|
||||
|
||||
各Podは0以上のPodPresetにマッチすることができます。そして各`PodPreset`は0以上のPodに適用されます。単一の`PodPreset`が1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`Env`、`EnvFrom`、`VolumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`Volume`への変更があった場合、KubernetesはそのPodのSpecを修正します。
|
||||
|
||||
{{< note >}}
|
||||
単一のPodPresetは必要に応じてPodのSpec内の`.spec.containers`を修正することができます。PodPresetからのリソース定義は`initContainers`フィールドに対して1つも適用されません。
|
||||
{{< /note >}}
|
||||
|
||||
### 特定のPodに対するPodPresetを無効にする
|
||||
|
||||
PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。
|
||||
`podpreset.admission.kubernetes.io/exclude: "true"`
|
||||
|
||||
## PodPresetを有効にする
|
||||
|
||||
ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
|
||||
|
||||
1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
|
||||
1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`を追加することで可能になります。
|
||||
1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user