whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

First Japanese l10n work for release-1.14 (#16115)

Browse Source 
* 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
2019-08-28 15:05:11 +09:00
committed by Kubernetes Prow Robot
parent 6c4a4d8152
commit abde921399
66 changed files with 6944 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/docs/concepts/workloads/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "Workloads"
weight: 50
---
content/ja/docs/concepts/workloads/controllers/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "Controllers"
weight: 20
---
content/ja/docs/concepts/workloads/controllers/cron-jobs.md
+46
View File
@@ -0,0 +1,46 @@
---
title: CronJob
content_template: templates/concept
weight: 80
---
{{% capture overview %}}
_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。
_CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。
[Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。
{{< note >}}
すべての**CronJob**`スケジュール`: 時刻はジョブが開始されたマスタータイムゾーンに基づいています。
{{< /note >}}
cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。
{{% /capture %}}
{{% capture body %}}
## CronJobの制限
cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1つのジョブオブジェクトを作成します。ここで _おおよそ_ と言っているのは、ある状況下では2つのジョブが作成される、もしくは1つも作成されない場合があるためです。通常、このようなことが起こらないようになっていますが、完全に防ぐことはできません。したがって、ジョブは _冪等_ であるべきです。
`startingDeadlineSeconds`が大きな値、もしくは設定されていない(デフォルト)、そして、`concurrencyPolicy`を`Allow`に設定している場合には、少なくとも一度、ジョブが実行されることを保証します。
最後にスケジュールされた時刻から現在までの間に、CronJobコントローラーはどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。
````
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
````
`startingDeadlineSeconds`フィールドが設定されると(`nil`ではない)、最後に実行された時刻から現在までではなく、`startingDeadlineSeconds`の値から現在までで、どれだけジョブを逃したのかをコントローラーが数えます。 `startingDeadlineSeconds`が`200`の場合、過去200秒間にジョブが失敗した回数を記録します。
スケジュールされた時間にCronJobが作成できないと、失敗したとみなされます。たとえば、`concurrencyPolicy`が`Forbid`に設定されている場合、前回のスケジュールがまだ実行中にCronJobをスケジュールしようとすると、CronJobは作成されません。
例として、CronJobが`08:30:00`を開始時刻として1分ごとに新しいJobをスケジュールするように設定され、`startingDeadlineSeconds`フィールドが設定されていない場合を想定します。`startingDeadlineSeconds`のデフォルト値は`100`秒です。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はスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/daemonset.md
+180
View File
@@ -0,0 +1,180 @@
---
reviewers:
title: DaemonSet
content_template: templates/concept
weight: 50
---
{{% capture overview %}}
_DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピーを稼働させることを保証します。Nodeがクラスターに追加されるとき、PodがNode上に追加されます。Nodeがクラスターから削除されたとき、それらのPodはガーベージコレクターにより除去されます。DaemonSetの削除により、DaemonSetが作成したPodもクリーンアップします。
DaemonSetのいくつかの典型的な使用例は以下の通りです。
- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。
- `fluentd`や`logstash`のようなログ集計デーモンを各Node上で稼働させる。
- [Prometheus Node Exporter](
https://github.com/prometheus/node_exporter)や`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`やInstana agentなどのようなNodeのモニタリングデーモンを各Node上で稼働させる。
シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
{{% /capture %}}
{{% capture body %}}
## DaemonSet Specの記述
### DaemonSetの作成
ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。
例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。
{{< codenew file="controllers/daemonset.yaml" >}}
* YAMLファイルに基づいてDaemonSetを作成します。
```
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
```
### 必須のフィールド
他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。
設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/docs/user-guide/deploying-applications/)、[コンテナの設定](/docs/tasks/)、[kuberctlを用いたオブジェクトの管理](/docs/concepts/overview/object-management-kubectl/overview/)といったドキュメントを参照ください。
また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)セクションも必須となります。
### Podテンプレート
`.spec.template`は`.spec`内での必須のフィールドの1つです。
`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/pod-overview/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、[Pod](/docs/concepts/workloads/pods/pod/)のテンプレートと同じスキーマとなります。
Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。
DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/docs/user-guide/pod-states)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
### Podセレクター
`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)の`.spec.selector`と同じものです。
Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。
`.spec.selector`は2つのフィールドからなるオブジェクトです。
* `matchLabels` - [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)の`.spec.selector`と同じように機能します。
* `matchExpressions` - キーと、値のリストとさらにはそれらのキーとバリューに関連したオペレーターを指定することにより、より洗練された形式のセレクターを構成できます。
上記の2つが指定された場合は、2つの条件をANDでどちらも満たすものを結果として返します。
もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。
また、ユーザーは通常、DaemonSetやReplicaSetのような他のコントローラーを使用するか直接かによらず、このセレクターとマッチするラベルを持つPodを作成すべきではありません。
さもないと、DaemonSetコントローラーが、それらのPodがDaemonSetによって作成されたものと扱われてしまいます。Kubernetesはユーザーがこれを行うことを止めることはありません。ユーザーがこれを行いたい1つのケースとしては、テストのためにNode上に異なる値をもったPodを手動で作成するような場合があります。
### 特定のいくつかのNode上のみにPodを稼働させる
もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node
selector](/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。
同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/docs/concepts/configuration/assign-pod-node/)マッチするPodをNode上に作成します。
もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。
## Daemon Podがどのようにスケジューリングされるか
### DaemonSetコントローラーによってスケジューリングされる場合(Kubernetes1.12からデフォルトで無効)
通常、Podが稼働するマシンはKubernetesスケジューラーによって選択されます。
しかし、DaemonSetコントローラーによって作成されたPodは既に選択されたマシンを持っています(`.spec.nodeName`はPodの作成時に指定され、Kubernetesスケジューラーによって無視されます）。
従って:
- Nodeの[`unschedulable`](/docs/admin/node/#manual-node-administration)フィールドはDaemonSetコントローラーによって尊重されません。
- DaemonSetコントローラーは、スケジューラーが起動していないときでも稼働でき、これはクラスターの自力での起動を助けます。
### デフォルトスケジューラーによってスケジューリングされる場合(Kubernetes1.12からデフォルトで有効)
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働させることを保証します。通常、Podが稼働するNodeはKubernetesスケジューラーによって選択されます。しかし、DaemonSetのPodは代わりにDaemonSetコントローラーによって作成され、スケジューリングされます。
下記の問題について説明します:
* 矛盾するPodのふるまい: スケジューリングされるのを待っている通常のPodは、作成されているが`Pending`状態となりますが、DaemonSetのPodは`Pending`状態で作成されません。これはユーザーにとって困惑するものです。
* [Podプリエンプション(Pod preemption)](/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。
`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。
```yaml
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchFields:
- key: metadata.name
operator: In
values:
- target-host-name
```
さらに、`node.kubernetes.io/unschedulable:NoSchedule`というtolarationがDaemonSetのPodに自動的に追加されます。デフォルトスケジューラーは、DaemonSetのPodのスケジューリングのときに、`unschedulable`なNodeを無視します。
### TaintsとTolerations
DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。
下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
| Toleration Key | Effect | Version | Description |
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 |
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。
## Daemon Podとのコミュニケーション
DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです。:
- **Push**: DaemonSet内のPodは他のサービスに対して更新情報を送信するように設定されます。
- **NodeIPとKnown Port**: PodがNodeIPを介して疎通できるようにするため、DaemonSet内のPodは`hostPort`を使用できます。慣例により、クライアントはNodeIPのリストとポートを知っています。
- **DNS**: 同じPodセレクターを持つ[HeadlessService](/docs/concepts/services-networking/service/#headless-services)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。
- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。
## DaemonSetの更新
もしNodeラベルが変更されたとき、そのDaemonSetは直ちに新しくマッチしたNodeにPodを追加し、マッチしなくなったNodeからPodを削除します。
ユーザーはDaemonSetが作成したPodを修正可能です。しかし、Podは全てのフィールドの更新を許可していません。また、DaemonSetコントローラーは次のNode(同じ名前でも)が作成されたときにオリジナルのテンプレートを使ってPodを作成します。
ユーザーはDaemonSetを削除可能です。もし`kubectl`コマンドで`--cascade=false`を指定したとき、DaemonSetのPodはNode上で残り続けます。そしてユーザーは異なるテンプレートを使って新しいDaemonSetを作成可能です。
異なるテンプレートを使った新しいDaemonSetは、マッチしたラベルを持っている全ての存在しているPodを認識します。DaemonSetはPodのテンプレートがミスマッチしていたとしても、それらのPodを修正もしくは削除をしません。
ユーザーはPodもしくはNodeの削除によって新しいPodの作成を強制する必要があります。
Kubernetes1.6とそれ以降のバージョンでは、ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。
## DaemonSetの代替案
### Initスクリプト
Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`を使用する)、デーモンプロセスを稼働することが可能です。この方法は非常に良いですが、このようなプロセスをDaemonSetを介して起動することはいくつかの利点があります。
- アプリケーションと同じ方法でデーモンの監視とログの管理ができる。
- デーモンとアプリケーションで同じ設定用の言語とツール(例: Podテンプレート、`kubectl`)を使える。
- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離を促進します。しかし、これはPod内でなく、コンテナ内でデーモンを稼働させることにより可能です(Dockerを介して直接起動する)。
### ベアPod
特定のNode上で稼働するように指定したPodを直接作成することは可能です。しかし、DaemonSetはNodeの故障やNodeの破壊的なメンテナンスやカーネルのアップグレードなど、どのような理由に限らず、削除されたもしくは停止されたPodを置き換えます。このような理由で、ユーザーはPod単体を作成するよりもむしろDaemonSetを使うべきです。
### 静的Pod Pods
Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/concepts/cluster-administration/static-pod/)と呼ばれます。
DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
### Deployment
DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。
フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/garbage-collection.md
+149
View File
@@ -0,0 +1,149 @@
---
title: ガベージコレクション
content_template: templates/concept
weight: 60
---
{{% capture overview %}}
Kubernetesのガベージコレクターの役割は、かつてオーナーがいたが、現時点でもはやオーナーがいないようなオブジェクトの削除を行うことです。
{{% /capture %}}
{{% capture body %}}
## オーナーとその従属オブジェクト
いくつかのKubernetesオブジェクトは他のオブジェクトのオーナーとなります。例えば、ReplicaSetはPodのセットに対するオーナーです。オーナーによって所有されたオブジェクトは、オーナーオブジェクトの*従属オブジェクト(Dependents)* と呼ばれます。全ての従属オブジェクトは、オーナーオブジェクトを指し示す`metadata.ownerReferences`というフィールドを持ちます。
時々、Kubernetesは`ownerReference`フィールドに値を自動的にセットします。例えば、ユーザーがReplicaSetを作成したとき、KubernetesはReplicaSet内の各Podの`ownerReference`フィールドに自動的に値をセットします。Kubernetes1.8において、KubernetesはReplicaController、ReplicaSet、StatefulSet、DaemonSet、Deployment、Job、CronJobによって作成され、適用されたオブジェクトの`ownerReference`フィールドに自動的にその値をセットします。
ユーザーはまた`ownerReference`フィールドに手動で値をセットすることにより、オーナーと従属オブジェクト間の関係を指定することができます。
下記の例は、3つのPodを持つReplicaSetの設定ファイルとなります。
{{< codenew file="controllers/replicaset.yaml" >}}
もしユーザーがReplicaSetを作成し、Podのメタデータを見る時、`ownerReference`フィールドの値を確認できます。
```shell
kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
kubectl get pods --output=yaml
```
その出力結果によると、そのPodのオーナーは`my-repset`という名前のReplicaSetです。
```shell
apiVersion: v1
kind: Pod
metadata:
...
ownerReferences:
- apiVersion: apps/v1
controller: true
blockOwnerDeletion: true
kind: ReplicaSet
name: my-repset
uid: d9607e19-f88f-11e6-a518-42010a800195
...
```
{{< note >}}
ネームスペースをまたいだownerReferenceは意図的に許可されていません。これは以下のことを意味します。
1) ネームスペース内のスコープの従属オブジェクトは、同一のネームスペース内のオーナーと、クラスターのスコープ内のオーナーのみ指定できます。
2) クラスターのスコープ内の従属オブジェクトは、クラスターのスコープ内のオーナーオブジェクトのみ指定でき、ネームスペース内のスコープのオーナーオブジェクトは指定できません。
{{< /note >}}
## ガベージコレクターがどのように従属オブジェクトの削除をするかを制御する
ユーザーがオブジェクトを削除するとき、それに紐づく従属オブジェクトも自動で削除するか指定できます。従属オブジェクトの自動削除は、*カスケード削除(Cascading deletion)* と呼ばれます。*カスケード削除* には2つのモードがあり、*バックグラウンド* と*フォアグラウンド* があります。
もしユーザーが、従属オブジェクトの自動削除なしにあるオブジェクトを削除する場合、その従属オブジェクトは*みなしご(orphaned)* と呼ばれます。
### フォアグラウンドのカスケード削除
*フォアグラウンドのカスケード削除* において、そのルートオブジェクトは最初に"削除処理中"という状態に遷移します。その*削除処理中* 状態において、下記の項目は正となります。
* そのオブジェクトはREST APIを介して確認可能です。
* そのオブジェクトの`deletionTimestamp`がセットされます。
* そのオブジェクトの`metadata.finalizers`フィールドは、`foregroundDeletion`という値を含みます。
一度"削除処理中"状態に遷移すると、そのガベージコレクターはオブジェクトの従属オブジェクトを削除します。一度そのガベージコレクターが全ての”ブロッキングしている”従属オブジェクトを削除すると(`ownerReference.blockOwnerDeletion=true`という値を持つオブジェクト)、それはオーナーのオブジェクトも削除します。
注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。
Kubernetes1.7では、認証されていない従属オブジェクトがオーナーオブジェクトの削除を遅らせることができないようにするために[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)が追加され、それは、オーナーオブジェクトの削除パーミッションに基づいて`blockOwnerDeletion`の値がtrueに設定してユーザーアクセスをコントロールします。
もしオブジェクトの`ownerReferences`フィールドがコントローラー(DeploymentやReplicaSetなど)によってセットされている場合、`blockOwnerDeletion`は自動的にセットされ、ユーザーはこのフィールドを手動で修正する必要はありません。
### バックグラウンドのカスケード削除
*バックグラウンドのカスケード削除* において、Kubernetesはそのオーナーオブジェクトを即座に削除し、ガベージコレクションはその従属オブジェクトをバックグラウンドで削除します。
### カスケード削除ポリシーの設定
カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。
Kubernetes1.9以前では多くのコントローラーにおけるデフォルトのガベージコレクションポリシーは`orphan`でした。
この対象のコントローラーはReplicationController、ReplicaSet、StatefulSet、DaemonSetとDeploymentを含みます。`extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2`のグループバージョンに含まれるオブジェクト種においては、もしユーザーがガベージコレクションに他の値を設定しない限り、デフォルトで従属オブジェクトはみなしご(orphaned)になります。
Kubernetes1.9において、`apps/v1`というグループバージョンにおいて、従属オブジェクトはデフォルトで削除されます。
下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
```
下記のコマンドは従属オブジェクトをフォアグラウンドで削除する例です。
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
```
下記のコマンドは従属オブジェクトをみなしご状態になった従属オブジェクトの例です。
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
```
kubectlもまたカスケード削除をサポートしています。
kubectlを使って従属オブジェクトを自動的に削除するためには、`--cascade`をtrueにセットしてください。
従属オブジェクトを削除せず、みなしご状態にするには`--cascade`をfalseにセットしてください。
`--cascade`オプションのデフォルト値はtrueになります。
下記のコマンドは、ReplicaSetを削除し、その従属オブジェクトをみなしご状態にします。
```shell
kubectl delete replicaset my-repset --cascade=false
```
### Deploymentsに関する追記事項
Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの_propagationPolicy_ が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。
さらなる詳細に関しては[kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)を参照してください。
## 既知の問題について
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)にてイシューがトラックされています。
{{% /capture %}}
{{% capture whatsnext %}}
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/replicaset.md
+315
View File
@@ -0,0 +1,315 @@
---
reviewers:
title: ReplicaSet
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。
{{% /capture %}}
{{% capture body %}}
## ReplicaSetがどのように動くか
ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示すためのセレクターや、稼働させたいPodのレプリカ数、Podテンプレート(理想のレプリカ数の条件を満たすために作成される新しいPodのデータを指定するために用意されるもの)といったフィールドとともに定義されます。ReplicaSetは、指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成します。ReplicaSetが新しいPodを作成するとき、ReplicaSetはそのPodテンプレートを使用します。
ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。
ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値がコントローラーでないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。
## ReplicaSetを使うとき
ReplicaSetはどんな時でも指定された数のPodのレプリカが稼働することを保証します。しかし、DeploymentはReplicaSetを管理する、より上位レベルの概念で、Deploymentはその他の多くの有益な機能と共に、宣言的なPodのアップデート機能を提供します。それゆえ、我々はユーザーが独自のアップデートオーケストレーションを必要としたり、アップデートを全く必要としないような場合を除いて、ReplicaSetを直接使うよりも代わりにDeploymentを使うことを推奨します。
これは、ユーザーがReplicaSetのオブジェクトを操作する必要が全く無いことを意味します。
代わりにDeploymentを使用して、`spec`セクションにユーザーのアプリケーションを定義してください。
## ReplicaSetの使用例
{{< codenew file="controllers/frontend.yaml" >}}
上記のマニフェストを`frontend.yaml`ファイルに保存しKubernetesクラスターに適用すると、マニフェストに定義されたReplicaSetとそれが管理するPod群を作成します。
```shell
kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
```
ユーザーはデプロイされた現在のReplicaSetの情報も取得できます。
```shell
kubectl get rs
```
そして、ユーザーが作成したfrontendリソースについての情報も取得できます。
```shell
NAME DESIRED CURRENT READY AGE
frontend 3 3 3 6s
```
ユーザーはまたReplicaSetの状態も確認できます。
```shell
kubectl describe rs/frontend
```
その結果は以下のようになります。
```shell
Name: frontend
Namespace: default
Selector: tier=frontend,tier in (frontend)
Labels: app=guestbook
tier=frontend
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=guestbook
tier=frontend
Containers:
php-redis:
Image: gcr.io/google_samples/gb-frontend:v3
Port: 80/TCP
Requests:
cpu: 100m
memory: 100Mi
Environment:
GET_HOSTS_FROM: dns
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
```
そして最後に、ユーザーはReplicaSetによって作成されたPodもチェックできます。
```shell
kubectl get Pods
```
表示されるPodに関する情報は以下のようになります。
```shell
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
```
ユーザーはまた、それらのPodの`ownerReferences`が`frontend`ReplicaSetに設定されていることも確認できます。
これを確認するためには、稼働しているPodの中のどれかのyamlファイルを取得します。
```shell
kubectl get pods frontend-9si5l -o yaml
```
その表示結果は、以下のようになります。その`frontend`ReplicaSetの情報が`metadata`の`ownerReferences`フィールドにセットされています。
```shell
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: 2019-01-31T17:20:41Z
generateName: frontend-
labels:
tier: frontend
name: frontend-9si5l
namespace: default
ownerReferences:
- apiVersion: extensions/v1beta1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: frontend
uid: 892a2330-257c-11e9-aecd-025000000001
...
```
## テンプレートなしのPodの所有
ユーザーが問題なくベアPod(Bare Pod: ここではPodテンプレート無しのPodのこと)を作成しているとき、そのベアPodがユーザーのReplicaSetの中のいずれのセレクターともマッチしないことを確認することを強く推奨します。
この理由として、ReplicaSetは、所有対象のPodがReplicaSetのテンプレートによって指定されたPodのみに限定されていないからです(ReplicaSetは前のセクションで説明した方法によって他のPodも所有できます)。
前のセクションで取り上げた`frontend`ReplicaSetと、下記のマニフェストのPodをみてみます。
{{< codenew file="pods/pod-rs.yaml" >}}
これらのPodは`ownerReferences`に何のコントローラー(もしくはオブジェクト)も指定されておらず、そして`frontend`ReplicaSetにマッチするセレクターをもっており、これらのPodは即座に`frontend`ReplicaSetによって所有されます。
この`frontend`ReplicaSetがデプロイされ、初期のPodレプリカがレプリカ数の要求を満たすためにセットアップされた後で、ユーザーがそのPodを作成することを考えます。
```shell
kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
```
新しいPodはそのReplicaSetによって所有され、そのReplicaSetのレプリカ数が、設定された理想のレプリカ数を超えた場合すぐにそれらのPodは削除されます。
下記のコマンドでPodを取得できます。
```shell
kubectl get Pods
```
その表示結果で、新しいPodがすでに削除済みか、削除中のステータスになっているのを確認できます。
```shell
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
pod2 0/1 Terminating 0 4s
```
もしユーザーがそのPodを最初に作成する場合
```shell
kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
```
そしてその後に`frontend`ReplicaSetを作成すると、
```shell
kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
```
ユーザーはそのReplicaSetが作成したPodを所有し、さらにもともと存在していたPodと今回新たに作成されたPodの数が、理想のレプリカ数になるまでPodを作成するのを確認できます。
ここでまたPodの状態を取得します。
```shell
kubectl get Pods
```
取得結果は下記のようになります。
```shell
NAME READY STATUS RESTARTS AGE
frontend-pxj4r 1/1 Running 0 5s
pod1 1/1 Running 0 13s
pod2 1/1 Running 0 13s
```
この方法で、ReplicaSetはテンプレートで指定されたもの以外のPodを所有することができます。
## ReplicaSetのマニフェストを記述する。
他の全てのKubernetes APIオブジェクトのように、ReplicaSetは`apiVersion`、`kind`と`metadata`フィールドを必要とします。
ReplicaSetでは、`kind`フィールドの値は`ReplicaSet`です。
Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが現在のバージョンで、デフォルトで有効です。`apps/v1beta2`というAPIバージョンは廃止されています。先ほど作成した`frontend.yaml`ファイルの最初の行を参考にしてください。
また、ReplicaSetは[`.spec` セクション](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)も必須です。
### Pod テンプレート
`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。
テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。
### Pod セレクター
`.spec.selector`フィールドは[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)です。
[先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。
先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました
```shell
matchLabels:
tier: frontend
```
そのReplicaSetにおいて、`.spec.template.metadata.labels`フィールドの値は`spec.selector`と一致しなくてはならず、一致しない場合はAPIによって拒否されます。
{{< note >}}
2つのReplicaSetが同じ`.spec.selector`の値を設定しているが、それぞれ異なる`.spec.template.metadata.labels`と`.spec.template.spec`フィールドの値を持っていたとき、それぞれのReplicaSetはもう一方のReplicaSetによって作成されたPodを無視します。
{{< /note >}}
### レプリカ数について
ユーザーは`.spec.replicas`フィールドの値を設定することにより、いくつのPodを同時に稼働させるか指定できます。そのときReplicaSetはレプリカ数がこの値に達するまでPodを作成、または削除します。
もしユーザーが`.spec.replicas`を指定しない場合、デフォルト値として1がセットされます。
## ReplicaSetを利用する
### ReplicaSetとPodの削除
ReplicaSetとそれが所有する全てのPod削除したいときは、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドを使ってください。
[ガーベージコレクター](/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。
REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。
例えば下記のように実行します。
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
> -H "Content-Type: application/json"
```
### ReplicaSetのみを削除する
ユーザーは[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドで`--cascade=false`オプションを付けることにより、所有するPodに影響を与えることなくReplicaSetを削除できます。
REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Orphan`と指定しなくてはなりません。
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
> -H "Content-Type: application/json"
```
一度元のReplicaSetが削除されると、ユーザーは新しいものに置き換えるため新しいReplicaSetを作ることができます。新旧のReplicaSetの`.spec.selector`の値が同じである間、新しいReplicaSetは古いReplicaSetで稼働していたPodを取り入れます。
しかし、存在するPodが新しく異なるPodテンプレートとマッチさせようとするとき、この仕組みは機能しません。
ユーザーのコントロール下において新しいspecのPodをアップデートしたい場合は、[ローリングアップデート](#rolling-updates)を使用してください。
### PodをReplicaSetから分離させる
ユーザーはPodのラベルを変更することにより、ReplicaSetからそのPodを削除できます。この手法はデバッグや、データ修復などのためにサービスからPodを削除したいときに使用できます。
この方法で削除されたPodは自動的に新しいものに置き換えられます。(レプリカ数は変更されないものと仮定します。)
### ReplicaSetのスケーリング
ReplicaSetは、ただ`.spec.replicas`フィールドを更新することによって簡単にスケールアップまたはスケールダウンできます。ReplicaSetコントローラーは、ラベルセレクターにマッチするような指定した数のPodが利用可能であり、操作可能であることを保証します。
### HorizontalPodAutoscaler(HPA)のターゲットとしてのReplicaSet
ReplicaSetはまた、[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/)のターゲットにもなることができます。
これはつまりReplicaSetがHPAによってオートスケールされうることを意味します。
ここではHPAが、前の例で作成したReplicaSetをターゲットにする例を示します。
{{< codenew file="controllers/hpa-rs.yaml" >}}
このマニフェストを`hpa-rs.yaml`に保存し、Kubernetesクラスターに適用すると、レプリケートされたPodのCPU使用量にもとづいてターゲットのReplicaSetをオートスケールするHPAを作成します。
```shell
kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
```
同様のことを行うための代替案として、`kubectl autoscale`コマンドも使用できます。(こちらの方がより簡単です。)
```shell
kubectl autoscale rs frontend --max=10
```
## ReplicaSetの代替案
### Deployment (推奨)
[`Deployment`](/docs/concepts/workloads/controllers/deployment/)はReplicaSetを所有することのできるオブジェクトで、宣言的なサーバサイドのローリングアップデートを介してReplicaSetとPodをアップデートできます。
ReplicaSetは単独で使用可能ですが、現在では、ReplicaSetは主にPodの作成、削除とアップデートを司るためのメカニズムとしてDeploymentによって使用されています。ユーザーがDeploymentを使用するとき、Deploymentによって作成されるReplicaSetの管理について心配する必要はありません。DeploymentはReplicaSetを所有し、管理します。
このため、もしユーザーがReplicaSetを必要とするとき、Deploymentの使用を推奨します。
### ベアPod(Bare Pods)
ユーザーがPodを直接作成するケースとは異なり、ReplicaSetはNodeの故障やカーネルのアップグレードといった破壊的なNodeのメンテナンスなど、どのような理由に限らず削除または停止されたPodを置き換えます。
このため、我々はもしユーザーのアプリケーションが単一のPodのみ必要とする場合でもReplicaSetを使用することを推奨します。プロセスのスーパーバイザーについても同様に考えると、それは単一Node上での独立したプロセスの代わりに複数のNodeにまたがった複数のPodを監視します。
ReplicaSetは、Node上のいくつかのエージェント(例えば、KubeletやDocker）に対して、ローカルのコンテナ再起動を移譲します。
### Job
PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用してください。
### DaemonSet
マシンの監視やロギングなど、マシンレベルの機能を提供したい場合は、ReplicaSetの代わりに[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/)を使用してください。
これらのPodはマシン自体のライフタイムに紐づいています: そのPodは他のPodが起動する前に、そのマシン上で稼働される必要があり、マシンが再起動またはシャットダウンされるときには、安全に停止されます。
### ReplicationController
ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/)の後継となるものです。
この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。
このように、ReplicaSetはReplicationControllerよりも好まれます。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/statefulset.md
+202
View File
@@ -0,0 +1,202 @@
---
reviewers:
title: StatefulSet
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。
{{< note >}}
StatefulSetはKubernetes1.9において利用可能(GA)です。
{{< /note >}}
{{< glossary_definition term_id="statefulset" length="all" >}}
{{% /capture %}}
{{% capture body %}}
## StatefulSetの使用
StatefulSetは下記の1つ以上の項目を要求するアプリケーションにおいて最適です。
* 安定した一意のネットワーク識別子
* 安定した永続ストレージ
* 規則的で安全なデプロイとスケーリング
* 規則的で自動化されたローリングアップデート
上記において安定とは、Podのスケジュール(または再スケジュール)をまたいでも永続的であることと同義です。
もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するコントローラーを使ってアプリケーションをデプロイするべきです。
[Deployment](/docs/concepts/workloads/controllers/deployment/)や[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)のようなコントローラーはこのようなステートレスな要求に対して最適です。
## 制限事項
* StatefuleSetはKubernetes1.9より以前のバージョンではβ版のリソースであり、1.5より前のバージョンでは利用できません。
* 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。
* StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除*されません* 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。
* StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/docs/concepts/services-networking/service/#headless-services)を要求します。ユーザーはこのServiceを作成する責任があります。
* StatefulSetは、StatefulSetが削除されたときにPodの停止を行うことを保証していません。StatefulSetにおいて、規則的で安全なPodの停止を行う場合、削除のために事前にそのStatefulSetの数を0にスケールダウンさせることが可能です。
* デフォルト設定の[Pod管理ポリシー](#pod-management-policies) (`OrderedReady`)によって[ローリングアップデート](#rolling-updates)を行う場合、[修復のための手動介入](#forced-rollback)を要求するようなブロークンな状態に遷移させることが可能です。
## コンポーネント
下記の例は、StatefulSetのコンポーネントのデモンストレーションとなります。
* nginxという名前のHeadlessServiceは、ネットワークドメインをコントロールするために使われます。
* webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。
* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。
```yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # .spec.template.metadata.labelsの値と一致する必要があります
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # .spec.selector.matchLabelsの値と一致する必要があります
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
```
## Podセレクター
ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。
## Podアイデンティティー
StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。
そのアイデンティティーはどのNode上にスケジュール(もしくは再スケジュール)されるかに関わらず、そのPodに紐付きます。
### 順序インデックス
N個のレプリカをもったStatefulSetにおいて、StatefulSet内の各Podは、0からはじまりN-1までの整数値を順番に割り当てられ、そのStatefulSetにおいては一意となります。
### 安定したネットワークID
StatefulSet内の各Podは、そのStatefulSet名とPodの順序番号から派生してホストネームが割り当てられます。
作成されたホストネームの形式は`$(StatefulSet名)-$(順序番号)`となります。先ほどの上記の例では、`web-0,web-1,web-2`という3つのPodが作成されます。
StatefulSetは、Podのドメインをコントロールするために[Headless Service](/docs/concepts/services-networking/service/#headless-services)を使うことができます。
このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。
各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。
[制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/docs/concepts/services-networking/service/#headless-services)を作成する責任があります。
ここで、クラスタードメイン、Service名、StatefulSet名の選択と、それらがStatefulSetのPodのDNS名にどう影響するかの例をあげます。
Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname |
-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
{{< note >}}
クラスタードメインは[その他の設定](/docs/concepts/services-networking/dns-pod-service/#how-it-works)がされない限り、`cluster.local`にセットされます。
{{< /note >}}
### 安定したストレージ
Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1Gibのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。
注意点として、PodのPersistentVolume Claimと関連したPersistentVolumeは、PodやStatefulSetが削除されたときに削除されません。
削除する場合は手動で行わなければなりません。
### Podのネームラベル
StatefulSetのコントローラーがPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。
## デプロイとスケーリングの保証
* N個のレプリカをもつStatefulSetにおいて、Podがデプロイされるとき、それらのPodは{0..N-1}の番号で順番に作成されます。
* Podが削除されるとき、それらのPodは{N-1..0}の番号で降順に削除されます。
* Podに対してスケーリングオプションが適用される前に、そのPodの前の順番の全てのPodがRunningかつReady状態になっていなくてはなりません。
* Podが停止される前に、そのPodの番号より大きい番号を持つの全てのPodは完全にシャットダウンされていなくてはなりません。
StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。
### Podの管理ポリシー
Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podManagementPolicy`フィールドを介して、Podの一意性とアイデンティティーを保証します。
#### OrderedReadyなPod管理
`OrderedReady`なPod管理はStatefulSetにおいてデフォルトです。これは[デプロイとスケーリングの保証](#deployment-and-scaling-guarantees)に記載されている項目の振る舞いを実装します。
#### 並行なPod管理Parallel Pod Management
`並行`なPod管理は、StatefulSetコントローラーに対して、他のPodが起動や停止される前にそのPodが完全に起動し準備完了になるか停止するのを待つことなく、Podが並行に起動もしくは停止するように指示します。
## アップデートストラテジー
Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStarategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。
### OnDelete
`OnDelete`というアップデートストラテジーは、レガシーな(Kubernetes1.6以前)振る舞いとなります。StatefulSetの`.spec.updateStrategy.type`が`OnDelete`にセットされていたとき、そのStatefulSetコントローラーはStatefulSet内でPodを自動的に更新しません。StatefulSetの`.spec.template`項目の修正を反映した新しいPodの作成をコントローラーに支持するためには、ユーザーは手動でPodを削除しなければなりません。
### RollinUpdate
`RollinUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。
#### パーティション
`RollingUpdate`というアップデートストラテジーは、`.spec.updateStrategy.rollingUpdate.partition`を指定することにより、パーティションに分けることができます。もしパーティションが指定されていたとき、そのパーティションの値と等しいか、大きい番号を持つPodが更新されます。パーティションの値より小さい番号を持つPodは更新されず、たとえそれらのPodが削除されたとしても、それらのPodは以前のバージョンで再作成されます。もしStatefulSetの`.spec.updateStrategy.rollingUpdate.partition`が、`.spec.replicas`より大きい場合、`.spec.template`への更新はPodに反映されません。
多くのケースの場合、ユーザーはパーティションを使う必要はありませんが、もし一部の更新を行う場合や、カナリー版のバージョンをロールアウトする場合や、段階的ロールアウトを行う場合に最適です。
#### 強制ロールバック
デフォルトの[Pod管理ポリシー](#pod-management-policies)(`OrderedReady`)による[ローリングアップデート](#rolling-updates)を行う際、修復のために手作業が必要な状態にすることが可能です。
もしユーザーが、決してRunningかつReady状態にならないような設定になるようにPodテンプレートを更新した場合(例えば、不正なバイナリや、アプリケーションレベルの設定エラーなど)、StatefulSetはロールアウトを停止し、待機します。
この状態では、Podテンプレートを正常な状態に戻すだけでは不十分です。[既知の問題](https://github.com/kubernetes/kubernetes/issues/67250)によって、StatefulSetは元の正常な状態へ戻す前に、壊れたPodがReady状態(決して起こりえない)に戻るのを待ち続けます。
そのテンプレートを戻したあと、ユーザーはまたStatefulSetが異常状態で稼働しようとしていたPodをすべて削除する必要があります。StatefulSetはその戻されたテンプレートを使ってPodの再作成を始めます。
{{% /capture %}}
{{% capture whatsnext %}}
* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+56
View File
@@ -0,0 +1,56 @@
---
reviewers:
title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources)
content_template: templates/concept
weight: 65
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL機構を提供します。
TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。
α版の免責事項: この機能は現在α版の機能で、[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
{{% /capture %}}
{{% capture body %}}
## TTLコントローラー
TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。
TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、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)をさせます。
## 注意
### TTL秒の更新
注意点として、Jobの`.spec.ttlSecondsAfterFinished`フィールドといったTTL期間はリソースが作成された後、もしくは終了した後に変更できます。しかし、一度Jobが削除可能(TTLの期限が切れたとき)になると、それがたとえTTLを伸ばすような更新に対してAPIのレスポンスで成功したと返されたとしても、そのシステムはJobが稼働し続けることをもはや保証しません。
### タイムスキュー(Time Skew)
TTLコントローラーが、TTL値が期限切れかそうでないかを決定するためにKubernetesリソース内に保存されたタイムスタンプを使うため、この機能はクラスター内のタイムスキュー(時刻のずれ)に対してセンシティブとなります。タイムスキューは、誤った時間にTTLコントローラーに対してリソースオブジェクトのクリーンアップしてしまうことを引き起こすものです。
Kubernetesにおいてタイムスキューを避けるために、全てのNode上でNTPの稼働を必須とします([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)を参照してください)。クロックは常に正しいものではありませんが、Node間におけるその差はとても小さいものとなります。TTLに0でない値をセットするときにこのリスクに対して注意してください。
{{% /capture %}}
{{% capture whatsnext %}}
[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[設計ドキュメント](https://github.com/kubernetes/community/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}
content/ja/docs/concepts/workloads/pods/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "Pods"
weight: 10
---
content/ja/docs/concepts/workloads/pods/init-containers.md
+276
View File
@@ -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 %}}
content/ja/docs/concepts/workloads/pods/pod-overview.md
+121
View File
@@ -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 %}}
content/ja/docs/concepts/workloads/pods/pod.md
+190
View File
@@ -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 %}}
content/ja/docs/concepts/workloads/pods/podpreset.md
+60
View File
@@ -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 %}}