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
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Controllers"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -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 %}}
|
||||
@@ -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 %}}
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
@@ -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 %}}
|
||||
|
||||
@@ -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 %}}
|
||||
Reference in New Issue
Block a user