First Japanese l10n work for release-1.17 (#19871)

* update reference to 1.17 (#18791)

* update endpoint slices to beta (#18794)

* update feature gate to 1.17 (#18799)

* update feature gate to 1.17

* Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md

Co-Authored-By: inductor <kohei.ota@zozo.com>

Co-authored-by: inductor <kohei.ota@zozo.com>

* Update links to ja docs (home/, tasks/tools/install-kubectl/, concepts/services-networking/service/) (#18930)

* update link to /ja/docs/home/

* update link to /ja/docs/tasks/tools/install-kubectl/

* update link to /ja/docs/concepts/services-networking/service/

* Translate tasks/administer-cluster/enabling-endpointslices.md in Japanese (#18140) (#18873)

* Translate tasks/administer-cluster/enabling-endpointslices.md in Japanese (#18140)

* Update enabling-endpointslices.md

* Update content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update enabling-endpointslices.md

* Update enabling-endpointslices.md

* Update content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md

Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com>

* Update content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md

Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com>

* Update enabling-endpointslices.md

Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: Takuya Tokuda <cs.toku.mail@gmail.com>

* update share process namespace (#19011)

* Revert trailing whitespaces (#18988)

* Correct a wrong resource name: Endpoint (#18954)

* Correct a wrong resource name: Endpoint

* Revert spaces at end of line

* Update links to ja docs (concepts/workloads/) (#18959)

* update link to /ja/docs/concepts/workloads/controllers/deployment/

* update link to /ja/docs/concepts/workloads/controllers/replicaset/

* update link to /ja/docs/concepts/workloads/controllers/statefulset/

* update link to /ja/docs/concepts/workloads/controllers/daemonset/

* update link to /ja/docs/concepts/workloads/pods/pod-overview/

* update link to /ja/docs/concepts/workloads/pods/pod/

* revert spaces at end of line

* revert spaces at end of line

* Replace links with redirect destination

* partially update link to /ja/docs/concepts/workloads/pods/pod-lifecycle/

* Update daemonset to 1.17 (#18793)

* update daemonset to 1.17

* Update content/ja/docs/concepts/workloads/controllers/daemonset.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/workloads/controllers/daemonset.md

Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>

* apply review

Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>

* remove ctrl-h (#19067)

* remove reviewers block (#19091)

* update link to /ja/docs/tasks/tools/install-minikube/ (#19147)

* translate networking (#19134)

* translate networking

* apply review

* apply review

* Update content/ja/docs/concepts/cluster-administration/networking.md

Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>

* nit

Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>

* update link to /ja/docs/concepts/overview/components/ (#19194)

* fix a wrong field name (#19256)

* update link to /ja/docs/concepts/configuration/assign-pod-node/ (#19324)

* Translate docs/concepts/storage/persistent-volumes.md into Japanese (#19074)

* translate content/ja/docs/concepts/storage/persistent-volumes.md into Japanese

* Update content/ja/docs/concepts/storage/persistent-volumes.md

translate title

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

fix missing translation

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

conform to translation style guide

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* conform to translation style guide

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* fix translation refer: https://github.com/kubernetes/website/pull/19074/files#r378950194

* fix translation

* fix translation ref: https://github.com/kubernetes/website/pull/19074#discussion_r378931787

* fix translation ref: https://github.com/kubernetes/website/pull/19074#discussion_r378829190

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* fix translation

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* fix translation follow https://github.com/kubernetes/website/pull/19074#discussion_r382130660

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* fix translation https://github.com/kubernetes/website/pull/19074#discussion_r378811021

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: bells17 <bells171@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/concepts/storage/persistent-volumes.md

Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>

* fix translation https://github.com/kubernetes/website/pull/19074/files#r380769175

* fix translation https://github.com/kubernetes/website/pull/19074#discussion_r380745506

* fix translation https://github.com/kubernetes/website/pull/19074#discussion_r381264848

Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: bells17 <bells171@gmail.com>
Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>

* update link to /ja/docs/tutorials/hello-minikube/ and /ja/docs/concepts/architecture/nodes/ (#19515)

* Translate tasks/configure-pod-container/configure-projected-volume-storage.md into Japanese (#19240)

* copy from content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md

Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com>

* Translate content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md into Japanese

Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com>

* fix translation

https://kubernetes.io/ja/docs/tasks/debug-application-cluster/get-shell-running-container/
にて、「シェルを取得する」という表現が用いられているため、そちらに合わせる

Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com>

* fix terminology 投影 -> Projected (#19641)

* translate configure-access-multiple-clusters into Japanese (#19563)

* translate configure-access-multiple-clusters into Japanese

* reflect PR feedback

* Translate concepts/cluster-administration/cluster-administration-overview.md into Japanese #18829 (#19258)

* ja-trans: translate concepts/cluster-administration/cluster-administration-overview.md into Japanese (#18829)

* ja-trans: Improve Japanese translation in concepts/cluster-administration/cluster-administration-overview.md  (#18829)

* ja-trans: Improve Japanese translation in concepts/cluster-administration/cluster-administration-overview.md  (#18829)

* Translate tasks/service-catalog/install-service-catalog-using-helm/ in Japanese (#19776)

* issue 18957

* translate a reference file

* Update content/ja/docs/reference/glossary/service-catalog.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/reference/glossary/service-catalog.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Update content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>

* Apply suggestions from code review

Co-Authored-By: Tim Bannister <tim@scalefactory.com>

* Apply suggestions from code review

Co-Authored-By: Tim Bannister <tim@scalefactory.com>

Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: inductor <kohei.ota@zozo.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>

* Fix dead link of api-conventions doc (#19801)

Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: Jin Hase <hase.jin@jp.fujitsu.com>
Co-authored-by: Takuya Tokuda <cs.toku.mail@gmail.com>
Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
Co-authored-by: Takahashi Tomohiko <takahashi@tomohiko.io>
Co-authored-by: bells17 <bells171@gmail.com>
Co-authored-by: Takuma Hashimoto <takumaxd+github@gmail.com>
Co-authored-by: Joe Kamibeppu <joekamibeppu@gmail.com>
Co-authored-by: Keita Akutsu <kakts.git@gmail.com>
Co-authored-by: SatoruItaya <44042909+SatoruItaya@users.noreply.github.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: KoyamaSohei <koyamaso0309@gmail.com>
This commit is contained in:
inductor
2020-03-27 15:08:22 +09:00
committed by bryan
parent c4dc46b56f
commit 4b37fac15b
63 changed files with 1823 additions and 211 deletions
@@ -13,8 +13,7 @@ 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上で稼働させる。
- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`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を使用するケースもあります。
@@ -41,19 +40,19 @@ 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/)といったドキュメントを参照ください。
設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。
また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)セクションも必須となります。
また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/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/)のテンプレートと同じスキーマとなります。
`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion``kind`をもたないことを除いては、[Pod](/ja/docs/concepts/workloads/pods/pod/)のテンプレートと同じスキーマとなります。
Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。
DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/docs/user-guide/pod-states)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
### Podセレクター
@@ -70,30 +69,20 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ
もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。
また、ユーザーは通常、DaemonSetやReplicaSetのような他のコントローラーを使用するか直接かによらず、このセレクターマッチするラベルを持つPodを作成すべきではありません。
さもないと、DaemonSetコントローラーが、それらのPodがDaemonSetによって作成されたものと扱われてしまいます。Kubernetesはユーザーがこれを行うことを止めることはありません。ユーザーがこれを行いたい1つのケースとしては、テストのためにNode上に異なる値をもったPodを手動で作成するような場合があります。
また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{<glossary_tooltip term_id = "controller">}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つ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上に作成します。
selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。
同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/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" >}}
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働させることを保証します。通常、Podが稼働するNodeはKubernetesスケジューラーによって選択されます。しかし、DaemonSetのPodは代わりにDaemonSetコントローラーによって作成され、スケジューリングされます。
下記の問題について説明します:
@@ -116,7 +105,7 @@ nodeAffinity:
さらに、`node.kubernetes.io/unschedulable:NoSchedule`というtolarationがDaemonSetのPodに自動的に追加されます。デフォルトスケジューラーは、DaemonSetのPodのスケジューリングのときに、`unschedulable`なNodeを無視します。
### TaintsとTolerations
### TaintsとTolerations
DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。
下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
@@ -136,7 +125,7 @@ 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レコードを取得します。
- **DNS**: 同じPodセレクターを持つ[HeadlessService](/ja/docs/concepts/services-networking/service/#headless-service)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。
- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。
## DaemonSetの更新
@@ -145,11 +134,9 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ
ユーザーはDaemonSetが作成したPodを修正可能です。しかし、Podは全てのフィールドの更新を許可していません。また、DaemonSetコントローラーは次のNode(同じ名前でも)が作成されたときにオリジナルのテンプレートを使ってPodを作成します。
ユーザーはDaemonSetを削除可能です。もし`kubectl`コマンドで`--cascade=false`を指定したとき、DaemonSetのPodはNode上残り続けます。そしてユーザーは異なるテンプレートを使って新しいDaemonSetを作成可能です。
異なるテンプレートを使った新しいDaemonSetは、マッチしたラベルを持っている全ての存在しているPodを認識します。DaemonSetはPodのテンプレートがミスマッチしていたとしても、それらのPodを修正もしくは削除をしません。
ユーザーはPodもしくはNodeの削除によって新しいPodの作成を強制する必要があります。
ユーザーはDaemonSetを削除可能です。`kubectl`コマンドで`--cascade=false`を指定するとDaemonSetのPodはNode上残り続けます。その後、同じセレクターで新しいDaemonSetを作成すると、新しいDaemonSetは既存のPodを再利用します。PodでDaemonSetを置き換える必要がある場合は、`updateStrategy`に従ってそれらを置き換えます。
Kubernetes1.6とそれ以降のバージョンでは、ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。
ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。
## DaemonSetの代替案
@@ -172,7 +159,7 @@ DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアン
### Deployment
DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。
DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。
フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。
@@ -11,7 +11,7 @@ weight: 30
{{% capture overview %}}
_Deployment_ コントローラーは[Pod](/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
_Deployment_ コントローラーは[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
ユーザーはDeploymentにおいて_理想的な状態_ を定義し、Deploymentコントローラーは指定された頻度で現在の状態を理想的な状態に変更させます。ユーザーはDeploymentを定義して、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。
@@ -28,7 +28,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
下記の項目はDeploymentの典型的なユースケースです。
* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。
* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。
* DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
* Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する
@@ -915,7 +915,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/
`.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。
`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/pod-overview/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては[Pod](/docs/concepts/workloads/pods/pod/)と同じスキーマとなります。
`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては[Pod](/ja/docs/concepts/workloads/pods/pod/)と同じスキーマとなります。
Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
@@ -192,11 +192,11 @@ pod2 1/1 Running 0 13s
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)も必須です。
また、ReplicaSetは[`.spec` セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必須です。
### Pod テンプレート
`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。
テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy``Always`のみ許可されていて、そしてそれがデフォルト値です。
@@ -287,7 +287,7 @@ kubectl autoscale rs frontend --max=10
### Deployment (推奨)
[`Deployment`](/docs/concepts/workloads/controllers/deployment/)はReplicaSetを所有することのできるオブジェクトで、宣言的なサーバサイドのローリングアップデートを介してReplicaSetとPodをアップデートできます。
[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)はReplicaSetを所有することのできるオブジェクトで、宣言的なサーバサイドのローリングアップデートを介してReplicaSetとPodをアップデートできます。
ReplicaSetは単独で使用可能ですが、現在では、ReplicaSetは主にPodの作成、削除とアップデートを司るためのメカニズムとしてDeploymentによって使用されています。ユーザーがDeploymentを使用するとき、Deploymentによって作成されるReplicaSetの管理について心配する必要はありません。DeploymentはReplicaSetを所有し、管理します。
このため、もしユーザーがReplicaSetを必要とするとき、Deploymentの使用を推奨します。
@@ -303,7 +303,7 @@ PodをPodそれ自身で停止させたいような場合(例えば、バッチ
### DaemonSet
マシンの監視やロギングなど、マシンレベルの機能を提供したい場合は、ReplicaSetの代わりに[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/)を使用してください。
マシンの監視やロギングなど、マシンレベルの機能を提供したい場合は、ReplicaSetの代わりに[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)を使用してください。
これらのPodはマシン自体のライフタイムに紐づいています: そのPodは他のPodが起動する前に、そのマシン上で稼働される必要があり、マシンが再起動またはシャットダウンされるときには、安全に停止されます。
### ReplicationController
@@ -29,14 +29,14 @@ StatefulSetは下記の1つ以上の項目を要求するアプリケーショ
上記において安定とは、Podのスケジュール(または再スケジュール)をまたいでも永続的であることと同義です。
もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するコントローラーを使ってアプリケーションをデプロイするべきです。
[Deployment](/docs/concepts/workloads/controllers/deployment/)や[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)のようなコントローラーはこのようなステートレスな要求に対して最適です。
[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)や[ReplicaSet](/ja/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は現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を要求します。ユーザーはこのServiceを作成する責任があります。
* StatefulSetは、StatefulSetが削除されたときにPodの停止を行うことを保証していません。StatefulSetにおいて、規則的で安全なPodの停止を行う場合、削除のために事前にそのStatefulSetの数を0にスケールダウンさせることが可能です。
* デフォルト設定の[Pod管理ポリシー](#pod-management-policies) (`OrderedReady`)によって[ローリングアップデート](#rolling-updates)を行う場合、[修復のための手動介入](#forced-rollback)を要求するようなブロークンな状態に遷移させることが可能です。
@@ -116,11 +116,11 @@ N個のレプリカをもったStatefulSetにおいて、StatefulSet内の各Pod
StatefulSet内の各Podは、そのStatefulSet名とPodの順序番号から派生してホストネームが割り当てられます。
作成されたホストネームの形式は`$(StatefulSet名)-$(順序番号)`となります。先ほどの上記の例では、`web-0,web-1,web-2`という3つのPodが作成されます。
StatefulSetは、Podのドメインをコントロールするために[Headless Service](/docs/concepts/services-networking/service/#headless-services)を使うことができます。
StatefulSetは、Podのドメインをコントロールするために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を使うことができます。
この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)を作成する責任があります。
[制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。
ここで、クラスタードメイン、Service名、StatefulSet名の選択と、それらがStatefulSetのPodのDNS名にどう影響するかの例をあげます。
@@ -26,7 +26,7 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs
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`フィールドのセットに関するいくつかの例です。
TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
* Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。
* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。