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>pull/19999/head
inductor
bryan
parent
c4dc46b56f
commit
4b37fac15b
|
|
@ -31,7 +31,7 @@ Kubernetesには、デプロイ済みのコンテナ化されたアプリケー
|
|||
基本的なKubernetesのオブジェクトは次のとおりです。
|
||||
|
||||
* [Pod](/ja/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Service](/docs/concepts/services-networking/service/)
|
||||
* [Service](/ja/docs/concepts/services-networking/service/)
|
||||
* [Volume](/docs/concepts/storage/volumes/)
|
||||
* [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 10
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/docs/concepts/overview/components/#node-components)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。
|
||||
ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/ja/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ kubectl describe node <ノード名>
|
|||
|
||||
Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`Unknown`や`False`のままになっている場合、[kube-controller-manager](/docs/admin/kube-controller-manager/)に引数が渡され、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodたちは切り離されたノードの上で稼働を続けることになります。
|
||||
|
||||
バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
|
||||
バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
|
||||
|
||||
バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。
|
||||
同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。
|
||||
|
|
@ -98,7 +98,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で
|
|||
|
||||
## 管理 {#management}
|
||||
|
||||
[Pod](/docs/concepts/workloads/pods/pod/)や[Service](/docs/concepts/services-networking/service/)と違い、ノードは本質的にはKubernetesによって作成されません。GCPのようなクラウドプロバイダーによって外的に作成されるか、VMや物理マシンのプールに存在するものです。そのため、Kubernetesがノードを作成すると、そのノードを表すオブジェクトが作成されます。作成後、Kubernetesはそのノードが有効かどうかを確認します。 たとえば、次の内容からノードを作成しようとしたとします:
|
||||
[Pod](/ja/docs/concepts/workloads/pods/pod/)や[Service](/ja/docs/concepts/services-networking/service/)と違い、ノードは本質的にはKubernetesによって作成されません。GCPのようなクラウドプロバイダーによって外的に作成されるか、VMや物理マシンのプールに存在するものです。そのため、Kubernetesがノードを作成すると、そのノードを表すオブジェクトが作成されます。作成後、Kubernetesはそのノードが有効かどうかを確認します。 たとえば、次の内容からノードを作成しようとしたとします:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -209,7 +209,7 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ
|
|||
|
||||
Kubernetesスケジューラーは、ノード上のすべてのPodに十分なリソースがあることを確認します。
|
||||
ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
|
||||
これは、kubeletによって開始されたすべてのコンテナを含みますが、[コンテナランタイム](/docs/concepts/overview/components/#node-components)によって直接開始されたコンテナやコンテナの外で実行されているプロセスは含みません。
|
||||
これは、kubeletによって開始されたすべてのコンテナを含みますが、[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)によって直接開始されたコンテナやコンテナの外で実行されているプロセスは含みません。
|
||||
|
||||
Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
reviewers:
|
||||
title: クラスター管理の概要
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページはKubernetesクラスターの作成や管理者向けの内容です。Kubernetesのコア[コンセプト](/ja/docs/concepts/)についてある程度精通していることを前提とします。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## クラスターのプランニング
|
||||
|
||||
Kubernetesクラスターの計画、セットアップ、設定の例を知るには[設定](/ja/docs/setup/)のガイドを参照してください。この記事で列挙されているソリューションは*ディストリビューション* と呼ばれます。
|
||||
|
||||
ガイドを選択する前に、いくつかの考慮事項を挙げます。
|
||||
|
||||
- ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか? あなたのニーズにあったディストリビューションを選択してください。
|
||||
- **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。
|
||||
- [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**?
|
||||
- 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
|
||||
- Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させるますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
|
||||
- **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。
|
||||
- **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
|
||||
- クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。
|
||||
|
||||
注意: 全てのディストリビューションがアクティブにメンテナンスされている訳ではありません。最新バージョンのKubernetesでテストされたディストリビューションを選択してください。
|
||||
|
||||
## クラスターの管理
|
||||
|
||||
* [クラスターの管理](/docs/tasks/administer-cluster/cluster-management/)では、クラスターのライフサイクルに関するいくつかのトピックを紹介しています。例えば、新規クラスターの作成、クラスターのマスターやワーカーノードのアップグレード、ノードのメンテナンスの実施(例: カーネルのアップグレード)、稼働中のクラスターのKubernetes APIバージョンのアップグレードについてです。
|
||||
|
||||
* [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。
|
||||
|
||||
* 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
|
||||
|
||||
## クラスターをセキュアにする
|
||||
|
||||
* [Certificates](/docs/concepts/cluster-administration/certificates/)では、異なるツールチェインを使用して証明書を作成する方法を説明します。
|
||||
|
||||
* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment-variables/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
|
||||
|
||||
* [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。
|
||||
|
||||
* [認証](/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。
|
||||
|
||||
* [認可](/docs/reference/access-authn-authz/authorization/)では、認証とは別に、HTTPリクエストの処理方法を制御します。
|
||||
|
||||
* [アドミッションコントローラーの使用](/docs/reference/access-authn-authz/admission-controllers/)では、認証と認可の後にKubernetes APIに対するリクエストをインターセプトするプラグインについて説明します。
|
||||
|
||||
* [Kubernetesクラスターでのsysctlの使用](/docs/concepts/cluster-administration/sysctl-cluster/)では、管理者向けにカーネルパラメーターを設定するため`sysctl`コマンドラインツールの使用方法について解説します。
|
||||
|
||||
* [クラスターの監査](/docs/tasks/debug-application-cluster/audit/)では、Kubernetesの監査ログの扱い方について解説します。
|
||||
|
||||
### kubeletをセキュアにする
|
||||
* [マスターとノードのコミュニケーション](/ja/docs/concepts/architecture/master-node-communication/)
|
||||
* [TLSのブートストラップ](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubeletの認証/認可](/docs/admin/kubelet-authentication-authorization/)
|
||||
|
||||
## オプションのクラスターサービス
|
||||
|
||||
* [DNSのインテグレーション](/ja/docs/concepts/services-networking/dns-pod-service/)では、DNS名をKubernetes Serviceに直接名前解決する方法を解説します。
|
||||
|
||||
* [クラスターアクティビィのロギングと監視](/docs/concepts/cluster-administration/logging/)では、Kubernetesにおけるロギングがどのように行われ、どう実装されているかについて解説します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,291 @@
|
|||
---
|
||||
title: クラスターのネットワーク
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。
|
||||
Kubernetesには、4つの異なる対応すべきネットワークの問題があります:
|
||||
|
||||
1. 高度に結合されたコンテナ間の通信: これは、[Pod](/ja/docs/concepts/workloads/pods/pod/)および`localhost`通信によって解決されます。
|
||||
2. Pod間の通信: 本ドキュメントの主な焦点です。
|
||||
3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
|
||||
4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
Kubernetesは、言ってしまえばアプリケーション間でマシンを共有するためのものです。通常、マシンを共有するには、2つのアプリケーションが同じポートを使用しないようにする必要があります。
|
||||
複数の開発者間でポートを調整することは、大規模に行うことは非常に難しく、ユーザーが制御できないクラスターレベルの問題に見合うことがあります。
|
||||
|
||||
動的ポート割り当てはシステムに多くの複雑さをもたらします。すべてのアプリケーションはパラメータとしてポートを管理する必要があり、APIサーバーにて動的なポート番号を設定値として注入する方法が必要となり、各サービスはお互いにお互いを見つける方法が必要です。Kubernetesはこれに対処するのではなく、別のアプローチを取ります。
|
||||
|
||||
## Kubernetesのネットワークモデル
|
||||
|
||||
すべての`Pod`は独自のIPアドレスを持ちます。これは、`Pod`間のリンクを明示的に作成する必要がなく、コンテナポートをホストポートにマッピングする必要がほとんどないことを意味します。こうすることで、ポート割り当て、名前解決、サービスディスカバリー、負荷分散、アプリケーション設定、および移行の観点から、`Pod`をVMまたは物理ホストと同様に扱うことができる、クリーンで後方互換性のあるモデルを生み出しています。
|
||||
|
||||
Kubernetesは、ネットワークの実装に次の基本的な要件を課しています(意図的なネットワークセグメンテーションポリシーを除きます):
|
||||
|
||||
* ノード上のPodが、NATなしですべてのノード上のすべてのPodと通信できること
|
||||
* systemdやkubeletなどノード上にあるエージェントが、そのノード上のすべてのPodと通信できること
|
||||
|
||||
注: ホストネットワークで実行される`Pod`をサポートするプラットフォームの場合(Linuxなど):
|
||||
|
||||
* ノードのホストネットワーク内のPodは、NATなしですべてのノード上のすべてのPodと通信できます
|
||||
|
||||
このモデルは全体としてそれほど複雑ではないことに加え、KubernetesがVMからコンテナへのアプリへの移植を簡単にするという要望と基本的に互換性があります。ジョブがVMで実行されていた頃も、VMにはIPがあってプロジェクト内の他のVMと通信できました。これは同じ基本モデルです。
|
||||
|
||||
KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。
|
||||
|
||||
この実装方法は実際に使われているコンテナランタイムの詳細部分です。
|
||||
|
||||
`Pod`に転送する`ノード`自体のポート(ホストポートと呼ばれる)を要求することは可能ですが、これは非常にニッチな操作です。このポート転送の実装方法も、コンテナランタイムの詳細部分です。`Pod`自体は、ホストポートの有無を認識しません。
|
||||
|
||||
## Kubernetesネットワークモデルの実装方法
|
||||
|
||||
このネットワークモデルを実装する方法はいくつかあります。このドキュメントは、こうした方法を網羅的にはカバーしませんが、いくつかの技術の紹介として、また出発点として役立つことを願っています。
|
||||
|
||||
この一覧はアルファベット順にソートされており、順序は優先ステータスを意味するものではありません。
|
||||
|
||||
### ACI
|
||||
|
||||
[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers.
|
||||
[ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI.
|
||||
An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf).
|
||||
|
||||
### Antrea
|
||||
|
||||
Project [Antrea](https://github.com/vmware-tanzu/antrea) is an opensource Kubernetes networking solution intended to be Kubernetes native.
|
||||
It leverages Open vSwitch as the networking data plane.
|
||||
Open vSwitch is a high-performance programmable virtual switch that supports both Linux and Windows.
|
||||
Open vSwitch enables Antrea to implement Kubernetes Network Policies in a high-performance and efficient manner.
|
||||
Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to implement an extensive set of networking and security features and services on top of Open vSwitch.
|
||||
|
||||
### AOS from Apstra
|
||||
|
||||
[AOS](http://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs.
|
||||
|
||||
The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems. These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs). AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment.
|
||||
|
||||
AOS has a rich set of REST API endpoints that enable Kubernetes to quickly change the network policy based on application requirements. Further enhancements will integrate the AOS Graph model used for the network design with the workload provisioning, enabling an end to end management system for both private and public clouds.
|
||||
|
||||
AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux.
|
||||
|
||||
Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/
|
||||
|
||||
### AWS VPC CNI for Kubernetes
|
||||
|
||||
[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)は、Kubernetesクラスター向けの統合されたAWS Virtual Private Cloud(VPC)ネットワーキングを提供します。このCNIプラグインは、高いスループットと可用性、低遅延、および最小のネットワークジッタを提供します。さらに、ユーザーは、Kubernetesクラスターを構築するための既存のAWS VPCネットワーキングとセキュリティのベストプラクティスを適用できます。これには、ネットワークトラフィックの分離にVPCフローログ、VPCルーティングポリシー、およびセキュリティグループを使用する機能が含まれます。
|
||||
|
||||
このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interfaces（ENI）を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。
|
||||
|
||||
さらに、このCNIは[ネットワークポリシーの適用のためにCalico](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/calico.html)と一緒に実行できます。AWS VPC CNIプロジェクトは、[GitHubのドキュメント](https://github.com/aws/amazon-vpc-cni-k8s)とともにオープンソースで公開されています。
|
||||
|
||||
### Azure CNI for Kubernetes
|
||||
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node.
|
||||
|
||||
Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
|
||||
|
||||
|
||||
### Big Cloud Fabric from Big Switch Networks
|
||||
|
||||
[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premises environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring.
|
||||
|
||||
With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed.
|
||||
|
||||
BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
|
||||
|
||||
### Cilium
|
||||
|
||||
[Cilium](https://github.com/cilium/cilium) is open source software for
|
||||
providing and transparently securing network connectivity between application
|
||||
containers. Cilium is L7/HTTP aware and can enforce network policies on L3-L7
|
||||
using an identity based security model that is decoupled from network
|
||||
addressing, and it can be used in combination with other CNI plugins.
|
||||
|
||||
### CNI-Genie from Huawei
|
||||
|
||||
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
|
||||
|
||||
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
|
||||
|
||||
### cni-ipvlan-vpc-k8s
|
||||
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set
|
||||
of CNI and IPAM plugins to provide a simple, host-local, low latency, high
|
||||
throughput, and compliant networking stack for Kubernetes within Amazon Virtual
|
||||
Private Cloud (VPC) environments by making use of Amazon Elastic Network
|
||||
Interfaces (ENI) and binding AWS-managed IPs into Pods using the Linux kernel's
|
||||
IPvlan driver in L2 mode.
|
||||
|
||||
The plugins are designed to be straightforward to configure and deploy within a
|
||||
VPC. Kubelets boot and then self-configure and scale their IP usage as needed
|
||||
without requiring the often recommended complexities of administering overlay
|
||||
networks, BGP, disabling source/destination checks, or adjusting VPC route
|
||||
tables to provide per-instance subnets to each host (which is limited to 50-100
|
||||
entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the
|
||||
network complexity required to deploy Kubernetes at scale within AWS.
|
||||
|
||||
### Contiv
|
||||
|
||||
[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced.
|
||||
|
||||
### Contrail / Tungsten Fabric
|
||||
|
||||
[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
|
||||
|
||||
### DANM
|
||||
|
||||
[DANM](https://github.com/nokia/danm) is a networking solution for telco workloads running in a Kubernetes cluster. It's built up from the following components:
|
||||
|
||||
* A CNI plugin capable of provisioning IPVLAN interfaces with advanced features
|
||||
* An in-built IPAM module with the capability of managing multiple, cluster-wide, discontinuous L3 networks and provide a dynamic, static, or no IP allocation scheme on-demand
|
||||
* A CNI metaplugin capable of attaching multiple network interfaces to a container, either through its own CNI, or through delegating the job to any of the popular CNI solution like SRI-OV, or Flannel in parallel
|
||||
* A Kubernetes controller capable of centrally managing both VxLAN and VLAN interfaces of all Kubernetes hosts
|
||||
* Another Kubernetes controller extending Kubernetes' Service-based service discovery concept to work over all network interfaces of a Pod
|
||||
|
||||
With this toolset DANM is able to provide multiple separated network interfaces, the possibility to use different networking back ends and advanced IPAM features for the pods.
|
||||
|
||||
### Flannel
|
||||
|
||||
[Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay
|
||||
network that satisfies the Kubernetes requirements. Many
|
||||
people have reported success with Flannel and Kubernetes.
|
||||
|
||||
### Google Compute Engine (GCE)
|
||||
|
||||
For the Google Compute Engine cluster configuration scripts, [advanced
|
||||
routing](https://cloud.google.com/vpc/docs/routes) is used to
|
||||
assign each VM a subnet (default is `/24` - 254 IPs). Any traffic bound for that
|
||||
subnet will be routed directly to the VM by the GCE network fabric. This is in
|
||||
addition to the "main" IP address assigned to the VM, which is NAT'ed for
|
||||
outbound internet access. A linux bridge (called `cbr0`) is configured to exist
|
||||
on that subnet, and is passed to docker's `--bridge` flag.
|
||||
|
||||
Docker is started with:
|
||||
|
||||
```shell
|
||||
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
||||
```
|
||||
|
||||
This bridge is created by Kubelet (controlled by the `--network-plugin=kubenet`
|
||||
flag) according to the `Node`'s `.spec.podCIDR`.
|
||||
|
||||
Docker will now allocate IPs from the `cbr-cidr` block. Containers can reach
|
||||
each other and `Nodes` over the `cbr0` bridge. Those IPs are all routable
|
||||
within the GCE project network.
|
||||
|
||||
GCE itself does not know anything about these IPs, though, so it will not NAT
|
||||
them for outbound internet traffic. To achieve that an iptables rule is used
|
||||
to masquerade (aka SNAT - to make it seem as if packets came from the `Node`
|
||||
itself) traffic that is bound for IPs outside the GCE project network
|
||||
(10.0.0.0/8).
|
||||
|
||||
```shell
|
||||
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
|
||||
```
|
||||
|
||||
Lastly IP forwarding is enabled in the kernel (so the kernel will process
|
||||
packets for bridged containers):
|
||||
|
||||
```shell
|
||||
sysctl net.ipv4.ip_forward=1
|
||||
```
|
||||
|
||||
The result of all this is that all `Pods` can reach each other and can egress
|
||||
traffic to the internet.
|
||||
|
||||
### Jaguar
|
||||
|
||||
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
|
||||
|
||||
### k-vswitch
|
||||
|
||||
[k-vswitch](https://github.com/k-vswitch/k-vswitch) is a simple Kubernetes networking plugin based on [Open vSwitch](https://www.openvswitch.org/). It leverages existing functionality in Open vSwitch to provide a robust networking plugin that is easy-to-operate, performant and secure.
|
||||
|
||||
### Knitter
|
||||
|
||||
[Knitter](https://github.com/ZTE/Knitter/) is a network solution which supports multiple networking in Kubernetes. It provides the ability of tenant management and network management. Knitter includes a set of end-to-end NFV container networking solutions besides multiple network planes, such as keeping IP address for applications, IP address migration, etc.
|
||||
|
||||
### Kube-OVN
|
||||
|
||||
[Kube-OVN](https://github.com/alauda/kube-ovn) is an OVN-based kubernetes network fabric for enterprises. With the help of OVN/OVS, it provides some advanced overlay network features like subnet, QoS, static IP allocation, traffic mirroring, gateway, openflow-based network policy and service proxy.
|
||||
|
||||
### Kube-router
|
||||
|
||||
[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
|
||||
|
||||
### L2 networks and linux bridging
|
||||
|
||||
If you have a "dumb" L2 network, such as a simple switch in a "bare-metal"
|
||||
environment, you should be able to do something similar to the above GCE setup.
|
||||
Note that these instructions have only been tried very casually - it seems to
|
||||
work, but has not been thoroughly tested. If you use this technique and
|
||||
perfect the process, please let us know.
|
||||
|
||||
Follow the "With Linux Bridge devices" section of [this very nice
|
||||
tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
|
||||
Lars Kellogg-Stedman.
|
||||
|
||||
### Multus (a Multi Network plugin)
|
||||
|
||||
[Multus](https://github.com/Intel-Corp/multus-cni) is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
|
||||
|
||||
Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
|
||||
|
||||
### NSX-T
|
||||
|
||||
[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal.
|
||||
|
||||
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
|
||||
### Nuage Networks VCS (Virtualized Cloud Services)
|
||||
|
||||
[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
|
||||
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
|
||||
### OpenVSwitch
|
||||
|
||||
[OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also
|
||||
complicated way to build an overlay network. This is endorsed by several of the
|
||||
"Big Shops" for networking.
|
||||
|
||||
### OVN (Open Virtual Networking)
|
||||
|
||||
OVN is an opensource network virtualization solution developed by the
|
||||
Open vSwitch community. It lets one create logical switches, logical routers,
|
||||
stateful ACLs, load-balancers etc to build different virtual networking
|
||||
topologies. The project has a specific Kubernetes plugin and documentation
|
||||
at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
|
||||
|
||||
### Project Calico
|
||||
|
||||
[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
|
||||
|
||||
Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.
|
||||
|
||||
Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking.
|
||||
|
||||
### Romana
|
||||
|
||||
[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
|
||||
|
||||
### Weave Net from Weaveworks
|
||||
|
||||
[Weave Net](https://www.weave.works/products/weave-net/) is a
|
||||
resilient and simple to use network for Kubernetes and its hosted applications.
|
||||
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
|
||||
or stand-alone. In either version, it doesn't require any configuration or extra code
|
||||
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -7,7 +7,7 @@ weight: 30
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
[Pod](/docs/concepts/workloads/pods/pod/)が稼働する[Node](/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
|
||||
[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
|
||||
これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/docs/concepts/overview/working-with-objects/labels/)です。
|
||||
スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
|
||||
SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
|
||||
|
|
@ -83,7 +83,7 @@ nodeSelectorを以下のように追加します:
|
|||
|
||||
## Nodeの隔離や制限
|
||||
Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。
|
||||
これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。
|
||||
これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。
|
||||
この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。
|
||||
これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ Nodeの隔離にラベルのプレフィックスを使用するためには、
|
|||
3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
|
||||
例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。
|
||||
|
||||
## Affinity と Anti-Affinity
|
||||
## Affinity と Anti-Affinity {#affinity-and-anti-affinity}
|
||||
|
||||
`nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。
|
||||
Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。
|
||||
|
|
|
|||
|
|
@ -29,13 +29,13 @@ weight: 10
|
|||
|
||||
## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob
|
||||
|
||||
- 可能な限り、"真っ裸"のPod([ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
|
||||
- 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
|
||||
|
||||
明示的に[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
|
||||
|
||||
## Service
|
||||
|
||||
- 対応するバックエンドワークロード（DeploymentまたはReplicaSet）の前、およびそれにアクセスする必要があるワークロードの前に[Service](/docs/concepts/services-networking/service/)を作成します。Kubernetesがコンテナを起動すると、コンテナ起動時に実行されていたすべてのServiceを指す環境変数が提供されます。たとえば、fooという名前のServiceが存在する場合、すべてのコンテナは初期環境で次の変数を取得します。
|
||||
- 対応するバックエンドワークロード（DeploymentまたはReplicaSet）の前、およびそれにアクセスする必要があるワークロードの前に[Service](/ja/docs/concepts/services-networking/service/)を作成します。Kubernetesがコンテナを起動すると、コンテナ起動時に実行されていたすべてのServiceを指す環境変数が提供されます。たとえば、fooという名前のServiceが存在する場合、すべてのコンテナは初期環境で次の変数を取得します。
|
||||
|
||||
```shell
|
||||
FOO_SERVICE_HOST=<the host the Service is running on>
|
||||
|
|
@ -50,18 +50,17 @@ weight: 10
|
|||
|
||||
デバッグ目的でのみポートにアクセスする必要がある場合は、[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)または[`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)を使用できます。
|
||||
|
||||
ノード上でPodのポートを明示的に公開する必要がある場合は、hostPortに頼る前に[NodePort](/docs/concepts/services-networking/service/#nodeport)の使用を検討してください。
|
||||
ノード上でPodのポートを明示的に公開する必要がある場合は、hostPortに頼る前に[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)の使用を検討してください。
|
||||
|
||||
- `hostPort`の理由と同じくして、`hostNetwork`の使用はできるだけ避けてください。
|
||||
|
||||
- `kube-proxy`のロードバランシングが不要な場合は、[headless Service](/docs/concepts/services-networking/service/#headless-
|
||||
services)（`ClusterIP`が`None`）を使用してServiceを簡単に検出できます。
|
||||
- `kube-proxy`のロードバランシングが不要な場合は、[headless Service](/ja/docs/concepts/services-networking/service/#headless-service)（`ClusterIP`が`None`）を使用してServiceを簡単に検出できます。
|
||||
|
||||
## ラベルの使用
|
||||
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
|
||||
|
||||
セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
|
||||
セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
|
||||
|
||||
オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
|
|||
これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
|
||||
ハンドラーにパラメーターは渡されません。
|
||||
|
||||
終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。
|
||||
終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#podの終了)にあります。
|
||||
|
||||
### フックハンドラーの実装
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI
|
|||
|
||||
{{< note >}}
|
||||
RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。
|
||||
設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。
|
||||
設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/ja/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。
|
||||
{{< /note >}}
|
||||
|
||||
RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。
|
|||
## マスターコンポーネント
|
||||
|
||||
マスターコンポーネントは、クラスターのコントロールプレーンを提供します。
|
||||
マスターコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replica`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。
|
||||
マスターコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。
|
||||
|
||||
マスターコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのマスターコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。
|
||||
マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。
|
||||
|
|
@ -80,7 +80,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー
|
|||
|
||||
{{< glossary_definition term_id="kube-proxy" length="all" >}}
|
||||
|
||||
### コンテナランタイム
|
||||
### コンテナランタイム {#container-runtime}
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ card:
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/api-conventions.md)に記載されています。
|
||||
全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。
|
||||
|
||||
APIエンドポイント、リソースタイプ、そしてサンプルは[APIリファレンス](/docs/reference)に記載されています。
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Kubernetesが多くの機能を提供すると言いつつも、新しい機能
|
|||
|
||||
[ラベル](/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。
|
||||
|
||||
さらに、[Kubernetesコントロールプレーン](/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。
|
||||
さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。
|
||||
|
||||
この[デザイン](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)によって、他の多くのシステムがKubernetes上で構築できるようになりました。
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ Kubernetesは...
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
* [はじめる](/docs/setup/)準備はできましたか？
|
||||
* さらなる詳細については、[Kubernetesのドキュメント](/docs/home/)を御覧ください。
|
||||
* さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -67,6 +67,6 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/docs/concepts/workloads/pods/pod-overview/)です。
|
||||
* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ spec:
|
|||
|
||||
### *集合ベース(Set-based)* の要件(requirement)
|
||||
|
||||
*集合ベース(Set-based)* のラベルの要件は値のセットによってキーをフィルタリングします。
|
||||
*集合ベース(Set-based)* のラベルの要件は値のセットによってキーをフィルタリングします。
|
||||
`in`、`notin`、`exists`の3つのオペレーターをサポートしています(キーを特定するのみ)。
|
||||
|
||||
例えば:
|
||||
|
|
@ -198,7 +198,7 @@ selector:
|
|||
|
||||
#### *集合ベース* の要件指定をサポートするリソース
|
||||
|
||||
[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)や[`Deployment`](/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。
|
||||
[`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。
|
||||
```yaml
|
||||
selector:
|
||||
matchLabels:
|
||||
|
|
@ -214,6 +214,6 @@ selector:
|
|||
|
||||
#### Nodeのセットを選択する
|
||||
ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。
|
||||
さらなる情報に関しては、[Node選定](/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。
|
||||
さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
|
|||
|
||||
- `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なるPodが同じNode上で実行しないことを示唆できます。
|
||||
|
||||
- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/)にて確認できます。
|
||||
- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/)にて確認できます。
|
||||
|
||||
- `TaintTolerationPriority`: Node上における許容できないTaintsの数に基づいて、全てのNodeの優先順位リストを準備します。このポリシーでは優先順位リストを考慮してNodeのランクを調整します。
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
|
|||
|
||||
- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
|
||||
|
||||
- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
|
||||
- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
|
||||
|
||||
- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
|
||||
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ my-nginx ClusterIP 10.0.162.149 <none> 80/TCP 21s
|
|||
|
||||
前述のように、ServiceはPodのグループによってサポートされています。
|
||||
これらのPodはエンドポイントを通じて公開されます。
|
||||
Serviceのセレクターは継続的に評価され、結果は`my-nginx`という名前のEndpointオブジェクトにPOSTされます。
|
||||
Serviceのセレクターは継続的に評価され、結果は`my-nginx`という名前のEndpointsオブジェクトにPOSTされます。
|
||||
Podが終了すると、エンドポイントから自動的に削除され、Serviceのセレクターに一致する新しいPodが自動的にエンドポイントに追加されます。
|
||||
エンドポイントを確認し、IPが最初のステップで作成されたPodと同じであることを確認します:
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m
|
|||
|
||||
クラスター内の任意のノードから、`<CLUSTER-IP>:<PORT>`でnginx Serviceにcurl接続できるようになりました。
|
||||
Service IPは完全に仮想的なもので、ホスト側のネットワークには接続できないことに注意してください。
|
||||
この仕組みに興味がある場合は、[サービスプロキシー](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
|
||||
この仕組みに興味がある場合は、[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
|
||||
|
||||
## Serviceにアクセスする
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Kubernetesの`bar`というネームスペース内で`foo`という名前のSer
|
|||
### SRVレコード
|
||||
|
||||
SRVレコードは、通常のServiceもしくは[Headless
|
||||
Services](/docs/concepts/services-networking/service/#headless-services)の一部である名前付きポート向けに作成されます。それぞれの名前付きポートに対して、そのSRVレコードは`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`という形式となります。
|
||||
Services](/ja/docs/concepts/services-networking/service/#headless-service)の一部である名前付きポート向けに作成されます。それぞれの名前付きポートに対して、そのSRVレコードは`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`という形式となります。
|
||||
通常のServiceに対しては、このSRVレコードは`my-svc.my-namespace.svc.cluster.local`という形式のドメイン名とポート番号へ名前解決します。
|
||||
Headless Serviceに対しては、このSRVレコードは複数の結果を返します。それはServiceの背後にある各Podの1つを返すのと、`auto-generated-name.my-svc.my-namespace.svc.cluster.local`という形式のPodのドメイン名とポート番号を含んだ結果を返します。
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ weight: 40
|
|||
|
||||
## 用語
|
||||
|
||||
まずわかりやすくするために、このガイドでは次の用語を定義します。
|
||||
まずわかりやすくするために、このガイドでは次の用語を定義します。
|
||||
|
||||
- ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ weight: 40
|
|||
|
||||
## Ingressとは何か
|
||||
|
||||
Ingressはクラスター外からクラスター内{{< link text="Service" url="/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
|
||||
Ingressはクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
|
||||
|
||||
```none
|
||||
internet
|
||||
|
|
@ -39,7 +39,7 @@ Ingressはクラスター外からクラスター内{{< link text="Service" url=
|
|||
|
||||
IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように構成できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
|
||||
|
||||
Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開するときは、[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを使用することが多いです。
|
||||
Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開するときは、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを使用することが多いです。
|
||||
|
||||
## Ingressを使用する上での前提条件
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/
|
|||
|
||||
* オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
|
||||
* パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
|
||||
* [Serviceドキュメント](/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
|
||||
* [Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
|
||||
|
||||
Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
|
||||
|
||||
|
|
@ -183,7 +183,7 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
|
|||
構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。
|
||||
|
||||
{{< note >}}
|
||||
ユーザーが使用している[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、ユーザーはdefault-http-backend[Service](/docs/concepts/services-networking/service/)の作成が必要な場合があります。
|
||||
ユーザーが使用している[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、ユーザーはdefault-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
### 名前ベースの仮想ホスティング
|
||||
|
|
@ -392,8 +392,8 @@ Ingressと関連するリソースの今後の開発については[SIG Network]
|
|||
Ingressリソースに直接関与しない複数の方法でServiceを公開できます。
|
||||
|
||||
下記の2つの使用を検討してください。
|
||||
* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
|
||||
* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
|
||||
* [Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)
|
||||
* [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ spec:
|
|||
|
||||
Kubernetesは、このServiceに対してIPアドレス("clusterIP"とも呼ばれます)を割り当てます。これはServiceのプロキシーによって使用されます(下記の[仮想IPとServiceプロキシー](#virtual-ips-and-service-proxies)を参照ください)。
|
||||
|
||||
Serviceセレクターのコントローラーはセレクターに一致するPodを継続的にスキャンし、“my-service”という名前のEndpointオブジェクトに対して変更をPOSTします。
|
||||
Serviceセレクターのコントローラーはセレクターに一致するPodを継続的にスキャンし、“my-service”という名前のEndpointsオブジェクトに対して変更をPOSTします。
|
||||
|
||||
{{< note >}}
|
||||
Serviceは`port`から`targetPort`へのマッピングを行います。デフォルトでは、利便性のために`targetPort`フィールドは`port`フィールドと同じ値で設定されます。
|
||||
|
|
@ -108,8 +108,8 @@ spec:
|
|||
targetPort: 9376
|
||||
```
|
||||
|
||||
このServiceはセレクターがないため、対応するEndpointオブジェクトは自動的に作成されません。
|
||||
ユーザーはEndpointオブジェクトを手動で追加することにより、向き先のネットワークアドレスとポートを手動でマッピングできます。
|
||||
このServiceはセレクターがないため、対応するEndpointsオブジェクトは自動的に作成されません。
|
||||
ユーザーはEndpointsオブジェクトを手動で追加することにより、向き先のネットワークアドレスとポートを手動でマッピングできます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -124,10 +124,10 @@ subsets:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Endpointのipは、loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), や
|
||||
Endpointsのipは、loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), や
|
||||
link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設定することができません。
|
||||
|
||||
{{< glossary_tooltip term_id="kube-proxy" >}}が仮想IPを最終的な到達先に設定することをサポートしていないため、Endpointのipアドレスは他のKubernetes ServiceのClusterIPにすることができません。
|
||||
{{< glossary_tooltip term_id="kube-proxy" >}}が仮想IPを最終的な到達先に設定することをサポートしていないため、Endpointsのipアドレスは他のKubernetes ServiceのClusterIPにすることができません。
|
||||
{{< /note >}}
|
||||
|
||||
セレクターなしのServiceへのアクセスは、セレクターをもっているServiceと同じようにふるまいます。上記の例では、トラフィックはYAMLファイル内で`192.0.2.42:9376` (TCP)で定義された単一のエンドポイントにルーティングされます。
|
||||
|
|
@ -135,7 +135,7 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設
|
|||
ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。
|
||||
|
||||
### エンドポイントスライス
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。
|
||||
|
||||
|
|
@ -158,8 +158,8 @@ Serviceにおいてプロキシーを使う理由はいくつかあります。
|
|||
|
||||
### user-spaceプロキシーモード {#proxy-mode-userspace}
|
||||
|
||||
このモードでは、kube-proxyはServiceやEndpointオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。
|
||||
各Serviceは、ローカルのNode上でポート(ランダムに選ばれたもの)を公開します。この"プロキシーポート"に対するどのようなリクエストも、そのServiceのバックエンドPodのどれか1つにプロキシーされます(Endpointを介して通知されたPodに対して)。
|
||||
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。
|
||||
各Serviceは、ローカルのNode上でポート(ランダムに選ばれたもの)を公開します。この"プロキシーポート"に対するどのようなリクエストも、そのServiceのバックエンドPodのどれか1つにプロキシーされます(Endpointsを介して通知されたPodに対して)。
|
||||
kube-proxyは、どのバックエンドPodを使うかを決める際にServiceの`SessionAffinity`項目の設定を考慮に入れます。
|
||||
|
||||
最後に、user-spaceプロキシーはServiceの`clusterIP`(仮想IP)と`port`に対するトラフィックをキャプチャするiptablesルールをインストールします。
|
||||
|
|
@ -171,9 +171,9 @@ kube-proxyは、どのバックエンドPodを使うかを決める際にService
|
|||
|
||||
### `iptables`プロキシーモード {#proxy-mode-iptables}
|
||||
|
||||
このモードでは、kube-proxyはServiceやEndpointオブジェクトの追加・削除のチェックのためにKubernetesコントロールプレーンを監視します。
|
||||
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除のチェックのためにKubernetesコントロールプレーンを監視します。
|
||||
各Serviceでは、そのServiceの`clusterIP`と`port`に対するトラフィックをキャプチャするiptablesルールをインストールし、そのトラフィックをServiceのあるバックエンドのセットに対してリダイレクトします。
|
||||
各Endpointオブジェクトは、バックエンドのPodを選択するiptablesルールをインストールします。
|
||||
各Endpointsオブジェクトは、バックエンドのPodを選択するiptablesルールをインストールします。
|
||||
|
||||
デフォルトでは、iptablesモードにおけるkube-proxyはバックエンドPodをランダムで選択します。
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ iptablesモードのkube-proxyが正常なバックエンドPodのみをリダ
|
|||
|
||||
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
|
||||
|
||||
`ipvs`モードにおいて、kube-proxyはServiceとEndpointオブジェクトを監視し、IPVSルールを作成するために`netlink`インターフェースを呼び出し、定期的にKubernetesのServiceとEndpointとIPVSルールを同期させます。
|
||||
`ipvs`モードにおいて、kube-proxyはServiceとEndpointsオブジェクトを監視し、IPVSルールを作成するために`netlink`インターフェースを呼び出し、定期的にKubernetesのServiceとEndpointsとIPVSルールを同期させます。
|
||||
このコントロールループはIPVSのステータスが理想的な状態になることを保証します。
|
||||
Serviceにアクセスするとき、IPVSはトラフィックをバックエンドのPodに向けます。
|
||||
|
||||
|
|
@ -320,15 +320,15 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
|
|||
|
||||
### ラベルセレクターの利用
|
||||
|
||||
ラベルセレクターを定義したHeadless Serviceにおいて、EndpointコントローラーはAPIにおいて`Endpoints`レコードを作成し、`Service`のバックエンドにある`Pod`へのIPを直接指し示すためにDNS設定を修正します。
|
||||
ラベルセレクターを定義したHeadless Serviceにおいて、EndpointsコントローラーはAPIにおいて`Endpoints`レコードを作成し、`Service`のバックエンドにある`Pod`へのIPを直接指し示すためにDNS設定を修正します。
|
||||
|
||||
### ラベルセレクターなしの場合
|
||||
|
||||
ラベルセレクターを定義しないHeadless Serviceにおいては、Endpoint コントローラーは`Endpoint`レコードを作成しません。
|
||||
ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
|
||||
しかしDNSのシステムは下記の2つ両方を探索し、設定します。
|
||||
|
||||
* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
|
||||
* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoint`レコード
|
||||
* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード
|
||||
|
||||
## Serviceの公開 (Serviceのタイプ) {#publishing-services-service-types}
|
||||
|
||||
|
|
@ -659,9 +659,9 @@ NLBは特定のインスタンスクラスでのみ稼働します。サポー
|
|||
`.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。
|
||||
特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。
|
||||
|
||||
均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を設定します。
|
||||
均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を設定します。
|
||||
|
||||
また、[内部のロードバランサー](/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。
|
||||
また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。
|
||||
|
||||
NLBの背後にあるインスタンスに対してクライアントのトラフィックを転送するために、Nodeのセキュリティーグループは下記のようなIPルールに従って変更されます。
|
||||
|
||||
|
|
@ -742,7 +742,7 @@ IPアドレスをハードコードする場合、[Headless Service](#headless-s
|
|||
|
||||
`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`CNAME`レコードと`my.database.example.com`という値を返します。
|
||||
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
|
||||
後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointを追加し、Serviceの`type`を変更します。
|
||||
後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。
|
||||
|
||||
{{< warning >}}
|
||||
HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する際に問題が発生する場合があります。ExternalNameを使用する場合、クラスター内のクライアントが使用するホスト名は、ExternalNameが参照する名前とは異なります。
|
||||
|
|
@ -758,7 +758,7 @@ HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する
|
|||
### External IPs
|
||||
|
||||
もし1つ以上のクラスターNodeに転送するexternalIPが複数ある場合、Kubernetes Serviceは`externalIPs`に指定したIPで公開されます。
|
||||
そのexternalIP(到達先のIPとして扱われます)のServiceのポートからトラフィックがクラスターに入って来る場合、ServiceのEndpointのどれか1つに対して転送されます。
|
||||
そのexternalIP(到達先のIPとして扱われます)のServiceのポートからトラフィックがクラスターに入って来る場合、ServiceのEndpointsのどれか1つに対して転送されます。
|
||||
`externalIPs`はKubernetesによって管理されず、それを管理する責任はクラスターの管理者にあります。
|
||||
|
||||
Serviceのspecにおいて、`externalIPs`は他のどの`ServiceTypes`と併用して設定できます。
|
||||
|
|
@ -815,7 +815,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ
|
|||
|
||||
実際に固定された向き先であるPodのIPアドレスとは異なり、ServiceのIPは実際には単一のホストによって応答されません。
|
||||
その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。
|
||||
クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointに転送されます。
|
||||
クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointsに転送されます。
|
||||
Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。
|
||||
|
||||
kube-proxyは3つの微妙に異なった動作をするプロキシーモード— userspace、iptablesとIPVS — をサポートしています。
|
||||
|
|
@ -838,7 +838,7 @@ kube-proxyが新しいServiceを見つけた時、kube-proxyは新しいラン
|
|||
また画像処理のアプリケーションについて考えます。バックエンドServiceが作成された時、そのKubernetesコントロールプレーンは仮想IPアドレスを割り当てます。例えば10.0.0.1などです。
|
||||
Serviceのポートが1234で、そのServiceがクラスター内のすべてのkube-proxyインスタンスによって監視されていると仮定します。
|
||||
kube-proxyが新しいServiceを見つけた時、kube-proxyは仮想IPから各Serviceのルールにリダイレクトされるような、iptablesルールのセットをインストールします。
|
||||
Service毎のルールは、トラフィックをバックエンドにリダイレクト(Destination NATを使用)しているEndpoint毎のルールに対してリンクしています。
|
||||
Service毎のルールは、トラフィックをバックエンドにリダイレクト(Destination NATを使用)しているEndpoints毎のルールに対してリンクしています。
|
||||
|
||||
クライアントがServiceの仮想IPアドレスに対して接続しているとき、そのiptablesルールが有効になります。
|
||||
バックエンドのPodが選択され(SessionAffinityに基づくか、もしくはランダムで選択される)、パケットはバックエンドにリダイレクトされます。
|
||||
|
|
@ -874,7 +874,7 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
|
|||
|
||||
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
|
||||
|
||||
もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
|
||||
もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
|
||||
|
||||
{{< note >}}
|
||||
ユーザーはまた、HTTP / HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
|
||||
|
|
@ -898,9 +898,9 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
|
|||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
KubernetseはService、Endpoint、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
|
||||
KubernetseはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
|
||||
|
||||
そのFeature Gateが有効になった時、ユーザーはService、Endpoint、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
|
||||
そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
|
||||
Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。
|
||||
|
||||
#### 警告 {#caveat-sctp-overview}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,661 @@
|
|||
---
|
||||
title: 永続ボリューム
|
||||
feature:
|
||||
title: ストレージオーケストレーション
|
||||
description: >
|
||||
ローカルストレージや<a href="https://cloud.google.com/storage/">GCP</a>、<a href="https://aws.amazon.com/products/storage/">AWS</a>などのパブリッククラウドプロバイダー、もしくはNFS、iSCSI、Gluster、Ceph、Cinder、Flockerのようなネットワークストレージシステムの中から選択されたものを自動的にマウントします。
|
||||
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このドキュメントではKubernetesの`PersistentVolume`について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 概要
|
||||
|
||||
ストレージを管理することはインスタンスを管理することとは全くの別物です。`PersistentVolume`サブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するための`PersistentVolume`と`PersistentVolumeClaim`という2つの新しいAPIリソースを紹介します。
|
||||
|
||||
`PersistentVolume`(PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。
|
||||
|
||||
`PersistentVolumeClaim`(PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、1ノードからのみ読み書きマウントができるモードや、複数ノードから読み込み専用マウントができるモードなどです)を要求することができます。
|
||||
|
||||
`PersistentVolumeClaim`はユーザーに抽象化されたストレージリソースの消費を許可する一方、ユーザーは色々な問題に対処するためにパフォーマンスといった様々なプロパティを持った`PersistentVolume`を必要とすることは一般的なことです。クラスター管理者はユーザーに様々なボリュームがどのように実装されているかを表に出すことなく、サイズやアクセスモードだけではない色々な点で異なった、様々な`PersistentVolume`を提供できる必要があります。これらのニーズに応えるために`StorageClass`リソースがあります。
|
||||
|
||||
[実例を含む詳細なチュートリアル](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)を参照して下さい。
|
||||
|
||||
|
||||
## ボリュームと要求のライフサイクル
|
||||
|
||||
PVはクラスター内のリソースです。PVCはこれらのリソースの要求でありまた、クレームのチェックとしても機能します。PVとPVCの相互作用はこのライフサイクルに従います。
|
||||
|
||||
### プロビジョニング
|
||||
|
||||
PVは静的か動的どちらかでプロビジョニングされます。
|
||||
|
||||
#### 静的
|
||||
|
||||
クラスター管理者は多数のPVを作成します。それらはクラスターのユーザーが使うことのできる実際のストレージの詳細を保持します。それらはKubernetes APIに存在し、利用できます。
|
||||
|
||||
#### 動的
|
||||
|
||||
ユーザーの`PersistentVolumeClaim`が管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。
|
||||
このプロビジョニングは`StorageClass`に基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。
|
||||
|
||||
ストレージクラスに基づいたストレージの動的プロビジョニングを有効化するには、クラスター管理者が`DefaultStorageClass`[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)をAPIサーバーで有効化する必要があります。
|
||||
これは例えば、`DefaultStorageClass`がAPIサーバーコンポーネントの`--enable-admission-plugins`フラグのコンマ区切りの順序付きリストの中に含まれているかで確認できます。
|
||||
APIサーバーのコマンドラインフラグの詳細については[kube-apiserver](/docs/admin/kube-apiserver/)のドキュメントを参照してください。
|
||||
|
||||
### バインディング
|
||||
|
||||
ユーザは、特定のサイズのストレージとアクセスモードを指定した上で`PersistentVolumeClaim`を作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なく`PersistentVolumeClaim`の紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは1対1です。
|
||||
|
||||
一致するボリュームが存在しない場合、クレームはいつまでも紐付けされないままになります。一致するボリュームが利用可能になると、クレームがバインドされます。たとえば、50GiのPVがいくつもプロビジョニングされているクラスターだとしても、100Giを要求するPVCとは一致しません。100GiのPVがクラスターに追加されると、PVCを紐付けできます。
|
||||
|
||||
### 使用
|
||||
|
||||
Podは要求をボリュームとして使用します。クラスターは、要求を検査して紐付けられたボリュームを見つけそのボリュームをPodにマウントします。複数のアクセスモードをサポートするボリュームの場合、ユーザーはPodのボリュームとしてクレームを使う時にどのモードを希望するかを指定します。
|
||||
|
||||
ユーザーがクレームを取得し、そのクレームがバインドされると、バインドされたPVは必要な限りそのユーザーに属します。ユーザーはPodをスケジュールし、Podのvolumesブロックに`persistentVolumeClaim`を含めることで、バインドされたクレームのPVにアクセスします。
|
||||
[書式の詳細はこちらを確認して下さい。](#claims-as-volumes)
|
||||
|
||||
### 使用中のストレージオブジェクトの保護
|
||||
|
||||
使用中のストレージオブジェクト保護機能の目的はデータ損失を防ぐために、Podによって実際に使用されている永続ボリュームクレーム(PVC)と、PVCにバインドされている永続ボリューム(PV)がシステムから削除されないようにすることです。
|
||||
|
||||
{{< note >}}
|
||||
PVCを使用しているPodオブジェクトが存在する場合、PVCはPodによって実際に使用されています。
|
||||
{{< /note >}}
|
||||
|
||||
ユーザーがPodによって実際に使用されているPVCを削除しても、そのPVCはすぐには削除されません。PVCの削除は、PVCがPodで使用されなくなるまで延期されます。また、管理者がPVCに紐付けられているPVを削除しても、PVはすぐには削除されません。PVがPVCに紐付けられなくなるまで、PVの削除は延期されます。
|
||||
|
||||
PVCの削除が保護されているかは、PVCのステータスが`Terminating`になっていて、そして`Finalizers`のリストに`kubernetes.io/pvc-protection`が含まれているかで確認できます。
|
||||
|
||||
```shell
|
||||
kubectl describe pvc hostpath
|
||||
Name: hostpath
|
||||
Namespace: default
|
||||
StorageClass: example-hostpath
|
||||
Status: Terminating
|
||||
Volume:
|
||||
Labels: <none>
|
||||
Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath
|
||||
volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
|
||||
Finalizers: [kubernetes.io/pvc-protection]
|
||||
```
|
||||
|
||||
同様にPVの削除が保護されているかは、PVのステータスが`Terminating`になっていて、そして`Finalizers`のリストに`kubernetes.io/pv-protection`が含まれているかで確認できます。
|
||||
|
||||
```shell
|
||||
kubectl describe pv task-pv-volume
|
||||
Name: task-pv-volume
|
||||
Labels: type=local
|
||||
Annotations: <none>
|
||||
Finalizers: [kubernetes.io/pv-protection]
|
||||
StorageClass: standard
|
||||
Status: Available
|
||||
Claim:
|
||||
Reclaim Policy: Delete
|
||||
Access Modes: RWO
|
||||
Capacity: 1Gi
|
||||
Message:
|
||||
Source:
|
||||
Type: HostPath (bare host directory volume)
|
||||
Path: /tmp/data
|
||||
HostPathType:
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
### 再クレーム
|
||||
|
||||
ユーザーは、ボリュームの使用が完了したら、リソースの再クレームを許可するAPIからPVCオブジェクトを削除できます。`PersistentVolume`の再クレームポリシーはそのクレームが解放された後のボリュームの処理をクラスターに指示します。現在、ボリュームは保持、リサイクル、または削除できます。
|
||||
|
||||
#### 保持
|
||||
|
||||
`Retain`という再クレームポリシーはリソースを手動で再クレームすることができます。`PersistentVolumeClaim`が削除される時、`PersistentVolume`は依然として存在はしますが、ボリュームは解放済みです。ただし、以前のクレームデータはボリューム上に残っているため、別のクレームにはまだ使用できません。管理者は次の手順でボリュームを手動で再クレームできます。
|
||||
|
||||
1. `PersistentVolume`を削除します。PVが削除された後も、外部インフラストラクチャー(AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど)に関連付けられたストレージアセットは依然として残ります。
|
||||
1. ストレージアセットに関連するのデータを手動で適切にクリーンアップします。
|
||||
1. 関連するストレージアセットを手動で削除するか、同じストレージアセットを再利用したい場合、新しいストレージアセット定義と共に`PersistentVolume`を作成します。
|
||||
|
||||
#### 削除
|
||||
|
||||
`Delete`再クレームポリシーをサポートするボリュームプラグインの場合、削除すると`PersistentVolume`オブジェクトがKubernetesから削除されるだけでなく、AWS EBS、GCE PD、Azure Disk、Cinderボリュームなどの外部インフラストラクチャーの関連ストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、[`StorageClass`の再クレームポリシー](#reclaim-policy)を継承します。これはデフォルトで削除です。管理者は、ユーザーの需要に応じて`StorageClass`を構成する必要があります。そうでない場合、PVは作成後に編集またはパッチを適用する必要があります。[PersistentVolumeの再クレームポリシーの変更](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)を参照してください。
|
||||
|
||||
#### リサイクル
|
||||
|
||||
{{< warning >}}
|
||||
`Recycle`再クレームポリシーは廃止されました。代わりに、動的プロビジョニングを使用することをおすすめします。
|
||||
{{< /warning >}}
|
||||
|
||||
基盤となるボリュームプラグインでサポートされている場合、`Recycle`再クレームポリシーはボリュームに対して基本的な削除(`rm -rf /thevolume/*`)を実行し、新しいクレームに対して再び利用できるようにします。
|
||||
|
||||
管理者は[こちら](/docs/admin/kube-controller-manager/)で説明するように、Kubernetesコントローラーマネージャーのコマンドライン引数を使用して、カスタムリサイクラーPodテンプレートを構成できます。カスタムリサイクラーPodテンプレートには、次の例に示すように、`volumes`仕様が含まれている必要があります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pv-recycler
|
||||
namespace: default
|
||||
spec:
|
||||
restartPolicy: Never
|
||||
volumes:
|
||||
- name: vol
|
||||
hostPath:
|
||||
path: /any/path/it/will/be/replaced
|
||||
containers:
|
||||
- name: pv-recycler
|
||||
image: "k8s.gcr.io/busybox"
|
||||
command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"]
|
||||
volumeMounts:
|
||||
- name: vol
|
||||
mountPath: /scrub
|
||||
```
|
||||
ただし、カスタムリサイクラーPodテンプレートの`volumes`パート内で指定された特定のパスは、リサイクルされるボリュームの特定のパスに置き換えられます。
|
||||
|
||||
### 永続ボリュームクレームの拡大
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
|
||||
|
||||
PersistentVolumeClaim(PVC)の拡大はデフォルトで有効です。次のボリュームの種類で拡大できます。
|
||||
|
||||
* gcePersistentDisk
|
||||
* awsElasticBlockStore
|
||||
* Cinder
|
||||
* glusterfs
|
||||
* rbd
|
||||
* Azure File
|
||||
* Azure Disk
|
||||
* Portworx
|
||||
* FlexVolumes
|
||||
* CSI
|
||||
|
||||
そのストレージクラスの`allowVolumeExpansion`フィールドがtrueとなっている場合のみ、PVCを拡大できます。
|
||||
|
||||
|
||||
``` yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
name: gluster-vol-default
|
||||
provisioner: kubernetes.io/glusterfs
|
||||
parameters:
|
||||
resturl: "http://192.168.10.100:8080"
|
||||
restuser: ""
|
||||
secretNamespace: ""
|
||||
secretName: ""
|
||||
allowVolumeExpansion: true
|
||||
```
|
||||
|
||||
PVCに対してさらに大きなボリュームを要求するには、PVCオブジェクトを編集してより大きなサイズを指定します。これにより`PersistentVolume`を受け持つ基盤にボリュームの拡大がトリガーされます。クレームを満たすため新しく`PersistentVolume`が作成されることはありません。代わりに既存のボリュームがリサイズされます。
|
||||
|
||||
#### CSIボリュームの拡張
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
CSIボリュームの拡張のサポートはデフォルトで有効になっていますが、ボリューム拡張をサポートするにはボリューム拡張を利用できるCSIドライバーも必要です。詳細については、それぞれのCSIドライバーのドキュメントを参照してください。
|
||||
|
||||
#### ファイルシステムを含むボリュームのリサイズ
|
||||
|
||||
ファイルシステムがXFS、Ext3、またはExt4の場合にのみ、ファイルシステムを含むボリュームのサイズを変更できます。
|
||||
|
||||
ボリュームにファイルシステムが含まれる場合、新しいPodが`PersistentVolumeClaim`でReadWriteモードを使用している場合にのみ、ファイルシステムのサイズが変更されます。ファイルシステムの拡張は、Podの起動時、もしくはPodの実行時で基盤となるファイルシステムがオンラインの拡張をサポートする場合に行われます。
|
||||
|
||||
FlexVolumesでは、ドライバの`RequiresFSResize`機能がtrueに設定されている場合、サイズを変更できます。
|
||||
FlexVolumeは、Podの再起動時にサイズ変更できます。
|
||||
|
||||
#### 使用中の永続ボリュームクレームのリサイズ
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
使用中のPVCの拡張は、Kubernetes 1.15以降のベータ版と、1.11以降のアルファ版として利用可能です。`ExpandInUsePersistentVolume`機能を有効化する必要があります。これはベータ機能のため多くのクラスターで自動的に行われます。詳細については、[フィーチャーゲート](/docs/reference/command-line-tools-reference/feature-gates/)のドキュメントを参照してください。
|
||||
{{< /note >}}
|
||||
|
||||
この場合、既存のPVCを使用しているPodまたはDeploymentを削除して再作成する必要はありません。使用中のPVCは、ファイルシステムが拡張されるとすぐにPodで自動的に使用可能になります。この機能は、PodまたはDeploymentで使用されていないPVCには影響しません。拡張を完了する前に、PVCを使用するPodを作成する必要があります。
|
||||
|
||||
他のボリュームタイプと同様、FlexVolumeボリュームは、Podによって使用されている最中でも拡張できます。
|
||||
|
||||
{{< note >}}
|
||||
FlexVolumeのリサイズは、基盤となるドライバーがリサイズをサポートしている場合のみ可能です。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
EBSの拡張は時間がかかる操作です。また変更は、ボリュームごとに6時間に1回までというクォータもあります。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## 永続ボリュームの種類
|
||||
|
||||
`PersistentVolume`の種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
|
||||
|
||||
* GCEPersistentDisk
|
||||
* AWSElasticBlockStore
|
||||
* AzureFile
|
||||
* AzureDisk
|
||||
* CSI
|
||||
* FC (Fibre Channel)
|
||||
* FlexVolume
|
||||
* Flocker
|
||||
* NFS
|
||||
* iSCSI
|
||||
* RBD (Ceph Block Device)
|
||||
* CephFS
|
||||
* Cinder (OpenStack block storage)
|
||||
* Glusterfs
|
||||
* VsphereVolume
|
||||
* Quobyte Volumes
|
||||
* HostPath (テスト用の単一ノードのみ。ローカルストレージはどのような方法でもサポートされておらず、またマルチノードクラスターでは動作しません)
|
||||
* Portworx Volumes
|
||||
* ScaleIO Volumes
|
||||
* StorageOS
|
||||
|
||||
## 永続ボリューム
|
||||
|
||||
各PVには、仕様とボリュームのステータスが含まれているspecとstatusが含まれています。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: pv0003
|
||||
spec:
|
||||
capacity:
|
||||
storage: 5Gi
|
||||
volumeMode: Filesystem
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
persistentVolumeReclaimPolicy: Recycle
|
||||
storageClassName: slow
|
||||
mountOptions:
|
||||
- hard
|
||||
- nfsvers=4.1
|
||||
nfs:
|
||||
path: /tmp
|
||||
server: 172.17.0.2
|
||||
```
|
||||
|
||||
### 容量
|
||||
|
||||
通常、PVには特定のストレージ容量があります。これはPVの`capacity`属性を使用して設定されます。容量によって期待される単位を理解するためには、Kubernetesの[リソースモデル](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)を参照してください。
|
||||
|
||||
現在、設定または要求できるのはストレージサイズのみです。将来の属性には、IOPS、スループットなどが含まれます。
|
||||
|
||||
### ボリュームモード
|
||||
|
||||
{{< feature-state for_k8s_version="v1.13" state="beta" >}}
|
||||
|
||||
Kubernetes 1.9より前は、すべてのボリュームプラグインが永続ボリュームにファイルシステムを作成していました。現在はRawブロックデバイスを使うために`volumeMode`の値を`block`に設定するか、ファイルシステムを使うために`filesystem`を設定できます。値が省略された場合のデフォルトは`filesystem`です。これはオプションのAPIパラメーターです。
|
||||
|
||||
### アクセスモード
|
||||
|
||||
`PersistentVolume`は、リソースプロバイダーがサポートする方法でホストにマウントできます。次の表に示すように、プロバイダーにはさまざまな機能があり、各PVのアクセスモードは、その特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFSは複数の読み取り/書き込みクライアントをサポートできますが、特定のNFSのPVはサーバー上で読み取り専用としてエクスポートされる場合があります。各PVは、その特定のPVの機能を記述する独自のアクセスモードのセットを取得します。
|
||||
|
||||
アクセスモードは次の通りです。
|
||||
|
||||
* ReadWriteOnce –ボリュームは単一のNodeで読み取り/書き込みとしてマウントできます
|
||||
* ReadOnlyMany –ボリュームは多数のNodeで読み取り専用としてマウントできます
|
||||
* ReadWriteMany –ボリュームは多数のNodeで読み取り/書き込みとしてマウントできます
|
||||
|
||||
CLIではアクセスモードは次のように略されます。
|
||||
|
||||
* RWO - ReadWriteOnce
|
||||
* ROX - ReadOnlyMany
|
||||
* RWX - ReadWriteMany
|
||||
|
||||
|
||||
> __Important!__ ボリュームは、多数のモードをサポートしていても、一度に1つのアクセスモードでしかマウントできません。たとえば、GCEPersistentDiskは、単一NodeではReadWriteOnceとして、または多数のNodeではReadOnlyManyとしてマウントできますが、同時にマウントすることはできません。
|
||||
|
||||
|
||||
| ボリュームプラグイン | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
|
||||
| :--- | :---: | :---: | :---: |
|
||||
| AWSElasticBlockStore | ✓ | - | - |
|
||||
| AzureFile | ✓ | ✓ | ✓ |
|
||||
| AzureDisk | ✓ | - | - |
|
||||
| CephFS | ✓ | ✓ | ✓ |
|
||||
| Cinder | ✓ | - | - |
|
||||
| CSI | ドライバーに依存 | ドライバーに依存 | ドライバーに依存 |
|
||||
| FC | ✓ | ✓ | - |
|
||||
| FlexVolume | ✓ | ✓ | ドライバーに依存 |
|
||||
| Flocker | ✓ | - | - |
|
||||
| GCEPersistentDisk | ✓ | ✓ | - |
|
||||
| Glusterfs | ✓ | ✓ | ✓ |
|
||||
| HostPath | ✓ | - | - |
|
||||
| iSCSI | ✓ | ✓ | - |
|
||||
| Quobyte | ✓ | ✓ | ✓ |
|
||||
| NFS | ✓ | ✓ | ✓ |
|
||||
| RBD | ✓ | ✓ | - |
|
||||
| VsphereVolume | ✓ | - | - (Podが連結されている場合のみ) |
|
||||
| PortworxVolume | ✓ | - | ✓ |
|
||||
| ScaleIO | ✓ | ✓ | - |
|
||||
| StorageOS | ✓ | - | - |
|
||||
|
||||
### Class
|
||||
|
||||
PVはクラスを持つことができます。これは`storageClassName`属性を[ストレージクラス](/docs/concepts/storage/storage-classes/)の名前に設定することで指定されます。特定のクラスのPVは、そのクラスを要求するPVCにのみバインドできます。`storageClassName`にクラスがないPVは、特定のクラスを要求しないPVCにのみバインドできます。
|
||||
|
||||
以前`volume.beta.kubernetes.io/storage-class`アノテーションは、`storageClassName`属性の代わりに使用されていました。このアノテーションはまだ機能しています。ただし、将来のKubernetesリリースでは完全に非推奨です。
|
||||
|
||||
### 再クレームポリシー {#reclaim-policy}
|
||||
|
||||
現在の再クレームポリシーは次のとおりです。
|
||||
|
||||
* 保持 -- 手動再クレーム
|
||||
* リサイクル -- 基本的な削除 (`rm -rf /thevolume/*`)
|
||||
* 削除 -- AWS EBS、GCE PD、Azure Disk、もしくはOpenStack Cinderボリュームに関連するストレージアセットを削除
|
||||
|
||||
現在、NFSとHostPathのみがリサイクルをサポートしています。AWS EBS、GCE PD、Azure Disk、およびCinder volumeは削除をサポートしています。
|
||||
|
||||
### マウントオプション
|
||||
|
||||
Kubernets管理者は永続ボリュームがNodeにマウントされるときの追加マウントオプションを指定できます。
|
||||
|
||||
{{< note >}}
|
||||
すべての永続ボリュームタイプがすべてのマウントオプションをサポートするわけではありません。
|
||||
{{< /note >}}
|
||||
|
||||
次のボリュームタイプがマウントオプションをサポートしています。
|
||||
|
||||
* AWSElasticBlockStore
|
||||
* AzureDisk
|
||||
* AzureFile
|
||||
* CephFS
|
||||
* Cinder (OpenStackブロックストレージ)
|
||||
* GCEPersistentDisk
|
||||
* Glusterfs
|
||||
* NFS
|
||||
* Quobyte Volumes
|
||||
* RBD (Ceph Block Device)
|
||||
* StorageOS
|
||||
* VsphereVolume
|
||||
* iSCSI
|
||||
|
||||
マウントオプションは検証されないため、不正だった場合マウントは失敗します。
|
||||
|
||||
以前`volume.beta.kubernetes.io/mount-options`アノテーションが`mountOptions`属性の代わりに使われていました。このアノテーションはまだ機能しています。ただし、将来のKubernetesリリースでは完全に非推奨です。
|
||||
|
||||
### ノードアフィニティ
|
||||
|
||||
{{< note >}}
|
||||
ほとんどのボリュームタイプはこのフィールドを設定する必要がありません。[AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore)、[GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk)、もしくは[Azure Disk](/docs/concepts/storage/volumes/#azuredisk)ボリュームブロックタイプの場合自動的に設定されます。[local](/docs/concepts/storage/volumes/#local)ボリュームは明示的に設定する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
PVは[ノードアフィニティ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)を指定して、このボリュームにアクセスできるNodeを制限する制約を定義できます。PVを使用するPodは、ノードアフィニティによって選択されたNodeにのみスケジュールされます。
|
||||
|
||||
### フェーズ
|
||||
|
||||
ボリュームは次のフェーズのいずれかです。
|
||||
|
||||
* 利用可能 -- まだクレームに紐付いていない自由なリソース
|
||||
* バウンド -- クレームに紐付いている
|
||||
* リリース済み -- クレームが削除されたが、クラスターにまだクレームされている
|
||||
* 失敗 -- 自動再クレームに失敗
|
||||
|
||||
CLIにはPVに紐付いているPVCの名前が表示されます。
|
||||
|
||||
## 永続ボリューム要求
|
||||
|
||||
各PVCにはspecとステータスが含まれます。これは、仕様とクレームのステータスです。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: myclaim
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
volumeMode: Filesystem
|
||||
resources:
|
||||
requests:
|
||||
storage: 8Gi
|
||||
storageClassName: slow
|
||||
selector:
|
||||
matchLabels:
|
||||
release: "stable"
|
||||
matchExpressions:
|
||||
- {key: environment, operator: In, values: [dev]}
|
||||
```
|
||||
|
||||
### アクセスモード
|
||||
|
||||
クレームは、特定のアクセスモードでストレージを要求するときにボリュームと同じ規則を使用します。
|
||||
|
||||
### ボリュームモード
|
||||
|
||||
クレームは、ボリュームと同じ規則を使用して、ファイルシステムまたはブロックデバイスとしてのボリュームの消費を示します。
|
||||
|
||||
### リソース
|
||||
|
||||
Podと同様に、クレームは特定の量のリソースを要求できます。この場合、要求はストレージ用です。同じ[リソースモデル](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)がボリュームとクレームの両方に適用されます。
|
||||
|
||||
### セレクター
|
||||
|
||||
クレームでは、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を指定して、ボリュームセットをさらにフィルター処理できます。ラベルがセレクターに一致するボリュームのみがクレームにバインドできます。セレクターは2つのフィールドで構成できます。
|
||||
|
||||
* `matchLabels` - ボリュームはこの値のラベルが必要です
|
||||
* `matchExpressions` - キー、値のリスト、およびキーと値を関連付ける演算子を指定することによって作成された要件のリスト。有効な演算子は、In、NotIn、ExistsおよびDoesNotExistです。
|
||||
|
||||
`matchLabels`と`matchExpressions`の両方からのすべての要件はANDで結合されます。一致するには、すべてが一致する必要があります。
|
||||
|
||||
### クラス
|
||||
|
||||
クレームは、`storageClassName`属性を使用して[ストレージクラス](/docs/concepts/storage/storage-classes/)の名前を指定することにより、特定のクラスを要求できます。PVCにバインドできるのは、PVCと同じ`storageClassName`を持つ、要求されたクラスのPVのみです。
|
||||
|
||||
PVCは必ずしもクラスをリクエストする必要はありません。`storageClassName`が`""`に設定されているPVCは、クラスのないPVを要求していると常に解釈されるため、クラスのないPVにのみバインドできます（アノテーションがないか、`""`に等しい1つのセット）。`storageClassName`のないPVCはまったく同じではなく、[`DefaultStorageClass`アドミッションプラグイン](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)がオンになっているかどうかによって、クラスターによって異なる方法で処理されます。
|
||||
|
||||
* アドミッションプラグインがオンになっている場合、管理者はデフォルトの`StorageClass`を指定できます。`storageClassName`を持たないすべてのPVCは、そのデフォルトのPVにのみバインドできます。デフォルトの`StorageClass`の指定は、`StorageClass`オブジェクトで`storageclass.kubernetes.io/is-default-class`アノテーションを`true`に設定することにより行われます。管理者がデフォルトを指定しない場合、クラスターは、アドミッションプラグインがオフになっているかのようにPVC作成をレスポンスします。複数のデフォルトが指定されている場合、アドミッションプラグインはすべてのPVCの作成を禁止します。
|
||||
* アドミッションプラグインがオフになっている場合、デフォルトの`StorageClass`の概念はありません。`storageClassName`を持たないすべてのPVCは、クラスを持たないPVにのみバインドできます。この場合、storageClassNameを持たないPVCは、`storageClassName`が`""`に設定されているPVCと同じように扱われます。
|
||||
|
||||
インストール方法によっては、インストール時にアドオンマネージャーによってデフォルトのストレージクラスがKubernetesクラスターにデプロイされる場合があります。
|
||||
|
||||
PVCが`selector`を要求することに加えて`StorageClass`を指定する場合、要件はANDで一緒に結合されます。要求されたクラスのPVと要求されたラベルのみがPVCにバインドされます。
|
||||
|
||||
{{< note >}}
|
||||
現在、`selector`が空ではないPVCは、PVを動的にプロビジョニングできません。
|
||||
{{< /note >}}
|
||||
|
||||
以前は、`storageClassName`属性の代わりに`volume.beta.kubernetes.io/storage-class`アノテーションが使用されていました。このアノテーションはまだ機能しています。ただし、今後のKubernetesリリースではサポートされません。
|
||||
|
||||
## ボリュームとしてのクレーム
|
||||
|
||||
Podは、クレームをボリュームとして使用してストレージにアクセスします。クレームは、そのクレームを使用するPodと同じ名前空間に存在する必要があります。クラスターは、Podの名前空間でクレームを見つけ、それを使用してクレームを支援している`PersistentVolume`を取得します。次に、ボリュームがホストとPodにマウントされます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: myfrontend
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: "/var/www/html"
|
||||
name: mypd
|
||||
volumes:
|
||||
- name: mypd
|
||||
persistentVolumeClaim:
|
||||
claimName: myclaim
|
||||
```
|
||||
|
||||
### 名前空間に関する注意
|
||||
|
||||
`PersistentVolume`バインドは排他的であり、`PersistentVolumeClaim`は名前空間オブジェクトであるため、"多"モード(`ROX`、`RWX`)でクレームをマウントすることは1つの名前空間内でのみ可能です。
|
||||
|
||||
## Rawブロックボリュームのサポート
|
||||
|
||||
{{< feature-state for_k8s_version="v1.13" state="beta" >}}
|
||||
|
||||
次のボリュームプラグインは、必要に応じて動的プロビジョニングを含むrawブロックボリュームをサポートします。
|
||||
|
||||
* AWSElasticBlockStore
|
||||
* AzureDisk
|
||||
* FC (Fibre Channel)
|
||||
* GCEPersistentDisk
|
||||
* iSCSI
|
||||
* Local volume
|
||||
* RBD (Ceph Block Device)
|
||||
* VsphereVolume (alpha)
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes 1.9では、FCおよびiSCSIボリュームのみがrawブロックボリュームをサポートしていました。
|
||||
追加のプラグインのサポートは1.10で追加されました。
|
||||
{{< /note >}}
|
||||
|
||||
### Rawブロックボリュームを使用した永続ボリューム
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: block-pv
|
||||
spec:
|
||||
capacity:
|
||||
storage: 10Gi
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
volumeMode: Block
|
||||
persistentVolumeReclaimPolicy: Retain
|
||||
fc:
|
||||
targetWWNs: ["50060e801049cfd1"]
|
||||
lun: 0
|
||||
readOnly: false
|
||||
```
|
||||
|
||||
### Rawブロックボリュームを要求する永続ボリュームクレーム
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: block-pvc
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
volumeMode: Block
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
```
|
||||
|
||||
### コンテナにRawブロックデバイスパスを追加するPod仕様
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pod-with-block-volume
|
||||
spec:
|
||||
containers:
|
||||
- name: fc-container
|
||||
image: fedora:26
|
||||
command: ["/bin/sh", "-c"]
|
||||
args: [ "tail -f /dev/null" ]
|
||||
volumeDevices:
|
||||
- name: data
|
||||
devicePath: /dev/xvda
|
||||
volumes:
|
||||
- name: data
|
||||
persistentVolumeClaim:
|
||||
claimName: block-pvc
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Podにrawブロックデバイスを追加する場合は、マウントパスの代わりにコンテナーでデバイスパスを指定します。
|
||||
{{< /note >}}
|
||||
|
||||
### ブロックボリュームのバインド
|
||||
|
||||
ユーザーが`PersistentVolumeClaim`specの`volumeMode`フィールドを使用してrawブロックボリュームの要求を示す場合、バインディングルールは、このモードをspecの一部として考慮しなかった以前のリリースとわずかに異なります。表にリストされているのは、ユーザーと管理者がrawブロックデバイスを要求するために指定可能な組み合わせの表です。この表は、ボリュームがバインドされるか、組み合わせが与えられないかを示します。静的にプロビジョニングされたボリュームのボリュームバインディングマトリクスはこちらです。
|
||||
|
||||
| PVボリュームモード | PVCボリュームモード | 結果 |
|
||||
| -------------------|:-------------------:| ------------:|
|
||||
| 未定義 | 未定義 | バインド |
|
||||
| 未定義 | ブロック | バインドなし |
|
||||
| 未定義 | ファイルシステム | バインド |
|
||||
| ブロック | 未定義 | バインドなし |
|
||||
| ブロック | ブロック | バインド |
|
||||
| ブロック | ファイルシステム | バインドなし |
|
||||
| ファイルシステム | ファイルシステム | バインド |
|
||||
| ファイルシステム | ブロック | バインドなし |
|
||||
| ファイルシステム | 未定義 | バインド |
|
||||
|
||||
{{< note >}}
|
||||
アルファリリースでは、静的にプロビジョニングされたボリュームのみがサポートされます。管理者は、rawブロックデバイスを使用する場合、これらの値を考慮するように注意する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
## ボリュームのスナップショットとスナップショットからのボリュームの復元のサポート
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
ボリュームスナップショット機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームのスナップショット](/docs/concepts/storage/volume-snapshots/)を参照してください。
|
||||
|
||||
ボリュームスナップショットのデータソースからボリュームを復元する機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
|
||||
|
||||
### ボリュームスナップショットから永続ボリュームクレームを作成する
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: restore-pvc
|
||||
spec:
|
||||
storageClassName: csi-hostpath-sc
|
||||
dataSource:
|
||||
name: new-snapshot-test
|
||||
kind: VolumeSnapshot
|
||||
apiGroup: snapshot.storage.k8s.io
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
```
|
||||
|
||||
## ボリュームの複製
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
|
||||
|
||||
PVCデータソースからのボリューム複製機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
|
||||
|
||||
### 既存のPVCからの永続ボリュームクレーム作成
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: cloned-pvc
|
||||
spec:
|
||||
storageClassName: my-csi-plugin
|
||||
dataSource:
|
||||
name: existing-src-pvc-name
|
||||
kind: PersistentVolumeClaim
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
```
|
||||
|
||||
## 可搬性の高い設定の作成
|
||||
|
||||
もし幅広いクラスターで実行され、永続ボリュームが必要となる構成テンプレートやサンプルを作成している場合は、次のパターンを使用することをお勧めします。
|
||||
|
||||
- 構成にPersistentVolumeClaimオブジェクトを含める(DeploymentやConfigMapと共に)
|
||||
- ユーザーが設定をインスタンス化する際にPersistentVolumeを作成する権限がない場合があるため、設定にPersistentVolumeオブジェクトを含めない。
|
||||
- テンプレートをインスタンス化する時にストレージクラス名を指定する選択肢をユーザーに与える
|
||||
- ユーザーがストレージクラス名を指定する場合、`persistentVolumeClaim.storageClassName`フィールドにその値を入力する。これにより、クラスターが管理者によって有効にされたストレージクラスを持っている場合、PVCは正しいストレージクラスと一致する。
|
||||
- ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
|
||||
- ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -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がその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。
|
||||
* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ weight: 40
|
|||
{{% capture body %}}
|
||||
## Initコンテナを理解する
|
||||
|
||||
単一の[Pod](/docs/concepts/workloads/pods/pod-overview/)は、Pod内に複数のコンテナを稼働させることができますが、Initコンテナもまた、アプリケーションコンテナが稼働する前に1つまたは複数稼働できます。
|
||||
単一の[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)は、Pod内に複数のコンテナを稼働させることができますが、Initコンテナもまた、アプリケーションコンテナが稼働する前に1つまたは複数稼働できます。
|
||||
|
||||
Initコンテナは下記の項目をのぞいて、通常のコンテナと全く同じものとなります。
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Initコンテナはアプリケーションコンテナのイメージとは分
|
|||
* ボリュームにあるgitリポジトリをクローンします。
|
||||
* メインのアプリケーションコンテナのための設定ファイルを動的に生成するために、いくつかの値を設定ファイルに移してテンプレートツールを稼働させます。例えば、設定ファイルにそのPodのPOD_IPを移して、Jinjaを使ってメインのアプリケーションコンテナの設定ファイルを生成します。
|
||||
|
||||
さらに詳細な使用例は、[StatefulSetsのドキュメント](/docs/concepts/workloads/controllers/statefulset/)と[Production Pods guide](/docs/tasks/configure-pod-container/configure-pod-initialization/)にまとまっています。
|
||||
さらに詳細な使用例は、[StatefulSetsのドキュメント](/ja/docs/concepts/workloads/controllers/statefulset/)と[Production Pods guide](/docs/tasks/configure-pod-container/configure-pod-initialization/)にまとまっています。
|
||||
|
||||
### Initコンテナの使用
|
||||
|
||||
|
|
|
|||
|
|
@ -223,9 +223,9 @@ kubeletによって再起動される終了したコンテナは、5分後にキ
|
|||
- バッチ計算などのように終了が予想されるPodに対しては、[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用します。
|
||||
Jobは`restartPolicy`がOnFailureまたはNeverになるPodに対してのみ適切です。
|
||||
|
||||
- 停止することを期待しないPod（たとえばWebサーバーなど）には、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)、または[Deployment](/docs/concepts/workloads/controllers/deployment/)を使用します。ReplicationControllerは`restartPolicy`がAlwaysのPodに対してのみ適切です。
|
||||
- 停止することを期待しないPod（たとえばWebサーバーなど）には、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)、または[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)を使用します。ReplicationControllerは`restartPolicy`がAlwaysのPodに対してのみ適切です。
|
||||
|
||||
- マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodには[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)を使用します。
|
||||
- マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodには[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を使用します。
|
||||
|
||||
3種類のコントローラにはすべてPodTemplateが含まれます。
|
||||
Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
title: Podについての概観(Pod Overview)
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
|
|
@ -80,16 +78,16 @@ Podは、Podそれ自体によって自己修復しません。もし、稼働
|
|||
|
||||
1つまたはそれ以上のPodを含むコントローラーの例は下記の通りです。
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/ja/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の仕様となります。
|
||||
[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)のような他のオブジェクト内で含まれるPodの仕様となります。
|
||||
コントローラーは実際のPodを作成するためにPodテンプレートを使用します。
|
||||
下記のサンプルは、メッセージを表示する単一のコンテナを含んだ、シンプルなPodのマニフェストとなります。
|
||||
|
||||
|
|
|
|||
|
|
@ -110,9 +110,9 @@ Podは、耐久性のある存在として扱われることを意図してい
|
|||
リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。
|
||||
|
||||
一般に、ユーザーはPodを直接作成する必要はありません。
|
||||
ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。
|
||||
ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/ja/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。
|
||||
コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。
|
||||
[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)ようなコントローラーもステートフルなPodをサポートします。
|
||||
[StatefulSet](/ja/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)などのクラスタースケジューリングシステムで比較的一般的です。
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ PodはAPIから消え、クライアントからは見えなくなる
|
|||
|
||||
デフォルトでは、すべての削除は30秒以内に正常に行われます。
|
||||
`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=<seconds>` オプションをサポートします。
|
||||
値 `0` はPodを[強制的に削除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)します。
|
||||
値 `0` はPodを[強制的に削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)します。
|
||||
kubectlのバージョン1.5以降では、強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。
|
||||
|
||||
### Podの強制削除
|
||||
|
|
|
|||
|
|
@ -18,11 +18,11 @@ content_template: templates/concept
|
|||
|
||||
* [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。
|
||||
* Kubernetes APIバージョン
|
||||
* [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
|
||||
* [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
|
||||
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
|
||||
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
|
||||
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
|
||||
* [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
|
||||
|
||||
## APIクライアントライブラリー
|
||||
|
||||
|
|
|
|||
|
|
@ -37,10 +37,9 @@ content_template: templates/concept
|
|||
|---------|---------|-------|-------|-------|
|
||||
| `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `APIListChunking` | `true` | Beta | 1.9 | |
|
||||
| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | |
|
||||
| `APIResponseCompression` | `false` | Alpha | 1.7 | |
|
||||
| `AppArmor` | `true` | Beta | 1.4 | |
|
||||
| `AttachVolumeLimit` | `true` | Alpha | 1.11 | 1.11 |
|
||||
| `AttachVolumeLimit` | `true` | Beta | 1.12 | |
|
||||
| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
|
||||
| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
|
||||
| `BlockVolume` | `true` | Beta | 1.13 | - |
|
||||
|
|
@ -55,14 +54,20 @@ content_template: templates/concept
|
|||
| `CSIDriverRegistry` | `true` | Beta | 1.14 | |
|
||||
| `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `CSIInlineVolume` | `true` | Beta | 1.16 | - |
|
||||
| `CSIMigration` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
|
||||
| `CSIMigration` | `true` | Beta | 1.17 | |
|
||||
| `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationAWS` | `false` | Beta | 1.17 | |
|
||||
| `CSIMigrationAWSComplete` | `false` | Alpha | 1.17 | |
|
||||
| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | |
|
||||
| `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | |
|
||||
| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | |
|
||||
| `CSIMigrationGCE` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | |
|
||||
| `CSIMigrationGCE` | `false` | Alpha | 1.14 | 1.16 |
|
||||
| `CSIMigrationGCE` | `false` | Beta | 1.17 | |
|
||||
| `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | |
|
||||
| `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
|
||||
| `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `CSINodeInfo` | `true` | Beta | 1.14 | |
|
||||
| `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | |
|
||||
| `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
|
||||
| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
|
||||
| `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
|
||||
|
|
@ -73,7 +78,8 @@ content_template: templates/concept
|
|||
| `DynamicAuditing` | `false` | Alpha | 1.13 | |
|
||||
| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
|
||||
| `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
|
||||
| `EndpointSlice` | `false` | Alpha | 1.16 | |
|
||||
| `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
|
||||
| `EndpointSlice` | `false` | Beta | 1.17 | |
|
||||
| `EphemeralContainers` | `false` | Alpha | 1.16 | |
|
||||
| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
|
||||
|
|
@ -93,33 +99,23 @@ content_template: templates/concept
|
|||
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
|
||||
| `MountContainers` | `false` | Alpha | 1.9 | |
|
||||
| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
|
||||
| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `NodeLease` | `true` | Beta | 1.14 | |
|
||||
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
|
||||
| `PodOverhead` | `false` | Alpha | 1.16 | - |
|
||||
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | 1.11 |
|
||||
| `PodShareProcessNamespace` | `true` | Beta | 1.12 | |
|
||||
| `ProcMountType` | `false` | Alpha | 1.12 | |
|
||||
| `QOSReserved` | `false` | Alpha | 1.11 | |
|
||||
| `RemainingItemCount` | `false` | Alpha | 1.15 | |
|
||||
| `RequestManagement` | `false` | Alpha | 1.15 | |
|
||||
| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
|
||||
| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | |
|
||||
| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
|
||||
| `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
|
||||
| `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
|
||||
| `RunAsGroup` | `true` | Beta | 1.14 | |
|
||||
| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `RuntimeClass` | `true` | Beta | 1.14 | |
|
||||
| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
|
||||
| `SCTPSupport` | `false` | Alpha | 1.12 | |
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ServerSideApply` | `true` | Beta | 1.16 | |
|
||||
| `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | |
|
||||
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
|
||||
| `StartupProbe` | `false` | Alpha | 1.16 | |
|
||||
| `StartupProbe` | `true` | Beta | 1.17 | |
|
||||
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `StorageVersionHash` | `true` | Beta | 1.15 | |
|
||||
| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
|
||||
|
|
@ -131,8 +127,6 @@ content_template: templates/concept
|
|||
| `Sysctls` | `true` | Beta | 1.11 | |
|
||||
| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
|
||||
| `TaintBasedEvictions` | `true` | Beta | 1.13 | |
|
||||
| `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
|
||||
| `TaintNodesByCondition` | `true` | Beta | 1.12 | |
|
||||
| `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
|
||||
| `TokenRequest` | `true` | Beta | 1.12 | |
|
||||
| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
|
||||
|
|
@ -143,11 +137,8 @@ content_template: templates/concept
|
|||
| `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
|
||||
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `VolumePVCDataSource` | `true` | Beta | 1.16 | |
|
||||
| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | |
|
||||
| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | - |
|
||||
| `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `WatchBookmark` | `true` | Beta | 1.16 | |
|
||||
| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 |
|
||||
| `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | - |
|
||||
| `WindowsGMSA` | `false` | Alpha | 1.14 | |
|
||||
| `WindowsGMSA` | `true` | Beta | 1.16 | |
|
||||
| `WinDSR` | `false` | Alpha | 1.14 | |
|
||||
|
|
@ -169,6 +160,12 @@ content_template: templates/concept
|
|||
| `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
|
||||
| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
|
||||
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
|
||||
| `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 |
|
||||
| `CSINodeInfo` | `true` | GA | 1.17 | |
|
||||
| `AttachVolumeLimit` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `AttachVolumeLimit` | `true` | Beta | 1.12 | 1.16 |
|
||||
| `AttachVolumeLimit` | `true` | GA | 1.17 | - |
|
||||
| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
|
||||
|
|
@ -210,6 +207,9 @@ content_template: templates/concept
|
|||
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
|
||||
| `MountPropagation` | `true` | GA | 1.12 | - |
|
||||
| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `NodeLease` | `true` | Beta | 1.14 | 1.16 |
|
||||
| `NodeLease` | `true` | GA | 1.17 | - |
|
||||
| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
|
||||
| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
|
||||
|
|
@ -219,18 +219,40 @@ content_template: templates/concept
|
|||
| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
|
||||
| `PodReadinessGates` | `true` | GA | 1.14 | - |
|
||||
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | 1.11 |
|
||||
| `PodShareProcessNamespace` | `true` | Beta | 1.12 | 1.16 |
|
||||
| `PodShareProcessNamespace` | `true` | GA | 1.17 | - |
|
||||
| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `PVCProtection` | - | Deprecated | 1.10 | - |
|
||||
| `RequestManagement` | `false` | Alpha | 1.15 | 1.16 |
|
||||
| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | 1.16 |
|
||||
| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
|
||||
| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | 1.16 |
|
||||
| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
|
||||
| `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `ServiceLoadBalancerFinalizer` | `true` | Beta | 1.16 | 1.16 |
|
||||
| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
|
||||
| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
|
||||
| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
|
||||
| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
|
||||
| `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
|
||||
| `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 |
|
||||
| `TaintNodesByCondition` | `true` | GA | 1.17 | - |
|
||||
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `VolumeScheduling` | `true` | GA | 1.13 | - |
|
||||
| `VolumeSubpath` | `true` | GA | 1.13 | - |
|
||||
| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | 1.16 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |
|
||||
| `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `WatchBookmark` | `true` | Beta | 1.16 | 1.16 |
|
||||
| `WatchBookmark` | `true` | GA | 1.17 | - |
|
||||
{{< /table >}}
|
||||
|
||||
## 機能を使用する
|
||||
|
|
@ -270,9 +292,10 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
|
||||
- `Accelerators`: DockerでのNvidia GPUのサポートを有効にします。
|
||||
- `AdvancedAuditing`: [高度な監査機能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)を有効にします。
|
||||
- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を有効にします。
|
||||
- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を有効にします。
|
||||
- `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。
|
||||
- `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。
|
||||
`APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
|
||||
- `APIResponseCompression`:`LIST`や`GET`リクエストのAPIレスポンスを圧縮します。
|
||||
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/docs/tutorials/clusters/apparmor/)で確認できます。
|
||||
- `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。
|
||||
|
|
@ -285,11 +308,16 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `CSIDriverRegistry`: csi.storage.k8s.ioのCSIDriver APIオブジェクトに関連するすべてのロジックを有効にします。
|
||||
- `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。
|
||||
- `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。
|
||||
- `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。
|
||||
- `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。
|
||||
- `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。
|
||||
- `CSIMigrationGCE`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のGCE-PDプラグインからPD CSIプラグインにルーティングします。
|
||||
- `CSIMigrationOpenStack`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のCinderプラグインからCinder CSIプラグインにルーティングします。
|
||||
- `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。ノードにEBS CSIプラグインがインストールおよび設定されていない場合、ツリー内のEBSプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
|
||||
- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。 CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。
|
||||
- `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。ノードにAzureDisk CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureDiskプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
|
||||
- `CSIMigrationAzureDiskComplete`: Azure-Diskツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Diskツリー内プラグインからAzureDisk CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureDisk機能フラグを有効にし、クラスター内のすべてのノードにAzureDisk CSIプラグインをインストールおよび設定する必要があります。
|
||||
- `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。ノードにAzureFile CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureFileプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
|
||||
- `CSIMigrationAzureFileComplete`: Azure-Fileツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Fileツリー内プラグインからAzureFile CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureFile機能フラグを有効にし、クラスター内のすべてのノードにAzureFile CSIプラグインをインストールおよび設定する必要があります。
|
||||
- `CSIMigrationGCE`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のGCE-PDプラグインからPD CSIプラグインにルーティングします。ノードにPD CSIプラグインがインストールおよび設定されていない場合、ツリー内のGCEプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
|
||||
- `CSIMigrationGCEComplete`: GCE-PDのツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックがGCE-PDのツリー内プラグインからPD CSIプラグインにボリューム操作をルーティングできるようにします。CSIMigrationおよびCSIMigrationGCE機能フラグを有効にし、クラスター内のすべてのノードにPD CSIプラグインをインストールおよび設定する必要があります。
|
||||
- `CSIMigrationOpenStack`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のCinderプラグインからCinder CSIプラグインにルーティングします。ノードにCinder CSIプラグインがインストールおよび設定されていない場合、ツリー内のCinderプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
|
||||
- `CSIMigrationOpenStackComplete`: Cinderのツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックがCinderのツリー内プラグインからCinder CSIプラグインにボリューム操作をルーティングできるようにします。CSIMigrationおよびCSIMigrationOpenStack機能フラグを有効にし、クラスター内のすべてのノードにCinder CSIプラグインをインストールおよび設定する必要があります。
|
||||
- `CSINodeInfo`: csi.storage.k8s.ioのCSINodeInfo APIオブジェクトに関連するすべてのロジックを有効にします。
|
||||
- `CSIPersistentVolume`: [CSI(Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)互換のボリュームプラグインを通してプロビジョニングされたボリュームの検出とマウントを有効にします。
|
||||
詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。
|
||||
|
|
@ -314,7 +342,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。
|
||||
- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のpodへの *クリティカル* の注釈を加える設定を有効にします。
|
||||
- `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。
|
||||
- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。対応するAPIとコントローラーを有効にする必要があります。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices/)をご覧ください。
|
||||
- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。対応するAPIとコントローラーを有効にする必要があります。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
|
||||
- `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
|
||||
- `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
|
||||
- `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
|
||||
|
|
@ -339,28 +367,27 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。
|
||||
- `ResourceLimitsPriorityFunction`: 入力したPodのCPU制限とメモリ制限の少なくとも1つを満たすノードに対して最低スコアを1に割り当てるスケジューラー優先機能を有効にします。その目的は同じスコアを持つノード間の関係を断つことです。
|
||||
- `RequestManagement`: 各サーバーで優先順位付けと公平性を備えたリクエストの並行性の管理機能を有効にしました。
|
||||
- `ResourceQuotaScopeSelectors`: リソース割当のスコープセレクターを有効にします。
|
||||
- `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `RunAsGroup`: コンテナの初期化プロセスで設定されたプライマリグループIDの制御を有効にします。
|
||||
- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/docs/concepts/containers/runtime-class/)機能を有効にします。
|
||||
- `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。
|
||||
- `SCTPSupport`: `Service`、`Endpoint`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
|
||||
- `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
|
||||
- `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
|
||||
- `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
|
||||
- `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーでラベル付けされている場合ノードは除外の対象となります。
|
||||
- `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
|
||||
- `StartupProbe`: kubeletで[startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
|
||||
- `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
|
||||
- `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
|
||||
- `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。
|
||||
- `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシ](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
|
||||
- `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
|
||||
- `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。
|
||||
- `Sysctls`: 各podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
|
||||
- `TaintBasedEvictions`: ノードの汚染とpodの許容に基づいてノードからpodを排除できるようにします。。詳細は[汚染と許容](/docs/concepts/configuration/taint-and-toleration/)で確認できます。
|
||||
- `TaintNodesByCondition`: [ノードの条件](/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。
|
||||
- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。
|
||||
- `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。
|
||||
- `TokenRequestProjection`: [投影ボリューム](/docs/concepts/storage/volumes/#projected)を使用したpodへのサービスアカウントのトークンの注入を有効にします。
|
||||
- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したpodへのサービスアカウントのトークンの注入を有効にします。
|
||||
- `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
|
||||
- `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。
|
||||
- `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Deployment
|
||||
id: deployment
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/deployment/
|
||||
full_link: /ja/docs/concepts/workloads/controllers/deployment/
|
||||
short_description: >
|
||||
複製されたアプリケーションを管理するAPIオブジェクト。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: ノード
|
||||
id: node
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/nodes/
|
||||
full_link: /ja/docs/concepts/architecture/nodes/
|
||||
short_description: >
|
||||
ノードはKubernetesのワーカーマシンです。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Pod
|
||||
id: pod
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/pods/pod-overview/
|
||||
full_link: /ja/docs/concepts/workloads/pods/pod-overview/
|
||||
short_description: >
|
||||
一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
title: サービスカタログ
|
||||
id: service-catalog
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
Kubernetesクラスターで稼働するアプリケーションが、クラウドプロバイダーによって提供されるデータストアサービスのように、外部のマネージドソフトウェアを容易に使えるようにするための拡張APIです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- extension
|
||||
---
|
||||
Kubernetesクラスターで稼働するアプリケーションが、クラウドプロバイダーによって提供されるデータストアサービスのように、外部のマネージドソフトウェアを容易に使えるようにするための拡張APIです。
|
||||
|
||||
<!--more-->
|
||||
サービスカタログを使用することで{{< glossary_tooltip text="サービスブローカー" term_id="service-broker" >}}が提供する{{< glossary_tooltip text="マネージドサービス" term_id="managed-service" >}}を、それらのサービスがどのように作成されるか、また管理されるかについての知識を無しに、一覧表示したり、プロビジョニングや使用をすることができます。
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: Service
|
||||
id: service
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/services-networking/service/
|
||||
full_link: /ja/docs/concepts/services-networking/service/
|
||||
short_description: >
|
||||
Podの集合で実行されているアプリケーションをネットワークサービスとして公開する方法。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: StatefulSet
|
||||
id: statefulset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/statefulset/
|
||||
full_link: /ja/docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Minikubeはローカル環境でKubernetesを簡単に実行するためのツ
|
|||
|
||||
## インストール
|
||||
|
||||
[Minikubeのインストール](/docs/tasks/tools/install-minikube/) を参照
|
||||
[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/) を参照
|
||||
|
||||
## クイックスタート
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ a building block. kops builds on the kubeadm work.
|
|||
|
||||
#### 要件
|
||||
|
||||
You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
|
||||
You must have [kubectl](/ja/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
|
||||
|
||||
#### インストール
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ update-alternatives --set iptables /usr/sbin/iptables-legacy
|
|||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Services** | All |
|
||||
|
||||
** [NodePort Services](/docs/concepts/services-networking/service/)のデフォルトのポートの範囲
|
||||
** [NodePort Services](/ja/docs/concepts/services-networking/service/)のデフォルトのポートの範囲
|
||||
|
||||
\*の項目は書き換え可能です。そのため、あなたが指定したカスタムポートも開いていることを確認する必要があります。
|
||||
|
||||
|
|
@ -138,7 +138,7 @@ Linux以外のノードでは、デフォルトで使用されるコンテナラ
|
|||
|
||||
kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない**ため、kubeadmにインストールするKubernetesコントロールプレーンのバージョンと一致させる必要があります。そうしないと、予期しないバグのある動作につながる可能性のあるバージョン差異(version skew)が発生するリスクがあります。ただし、kubeletとコントロールプレーン間のマイナーバージョン差異(minor version skew)は_1つ_サポートされていますが、kubeletバージョンがAPIサーバーのバージョンを超えることはできません。たとえば、1.7.0を実行するkubeletは1.8.0 APIサーバーと完全に互換性がありますが、その逆はできません。
|
||||
|
||||
`kubectl`のインストールに関する詳細情報は、[kubectlのインストールおよびセットアップ](/docs/tasks/tools/install-kubectl/)を参照してください。
|
||||
`kubectl`のインストールに関する詳細情報は、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参照してください。
|
||||
|
||||
{{< warning >}}
|
||||
これらの手順はシステムアップグレードによるすべてのKubernetesパッケージの更新を除きます。これはkubeadmとKubernetesが[アップグレードにおける特別な注意](docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を必要とするからです。
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ weight: 100
|
|||
|
||||
As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control
|
||||
plane. This means that key components such as the API server, controller
|
||||
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
|
||||
manager, and scheduler run as [DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/)
|
||||
configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
|
||||
configured in the kubelet via static files.
|
||||
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ Calico, Canal, and Flannel CNI providers are verified to support HostPort.
|
|||
For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
|
||||
|
||||
If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of
|
||||
services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`.
|
||||
services](/ja/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`.
|
||||
|
||||
## サービスIP経由でPodにアクセスすることができない
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,4 @@
|
|||
---
|
||||
reviewers:
|
||||
- michmike
|
||||
- patricklang
|
||||
title: Intro to Windows support in Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 65
|
||||
|
|
|
|||
|
|
@ -1,7 +1,4 @@
|
|||
---
|
||||
reviewers:
|
||||
- michmike
|
||||
- patricklang
|
||||
title: Guide for scheduling Windows containers in Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 75
|
||||
|
|
|
|||
|
|
@ -1,7 +1,4 @@
|
|||
---
|
||||
reviewers:
|
||||
- michmike
|
||||
- patricklang
|
||||
title: Guide for adding Windows Nodes in Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
|
|
|
|||
|
|
@ -0,0 +1,335 @@
|
|||
---
|
||||
title: 複数のクラスターへのアクセスを設定する
|
||||
content_template: templates/task
|
||||
weight: 30
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、contextの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。
|
||||
|
||||
{{< note >}}
|
||||
クラスターへのアクセスを設定するファイルを、*kubeconfig* ファイルと呼ぶことがあります。これは設定ファイルの一般的な呼び方です。`kubeconfig`という名前のファイルが存在するわけではありません。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## クラスター、ユーザー、contextを設定する
|
||||
|
||||
例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。
|
||||
|
||||
`config-exercise`というディレクトリを作成してください。`config-exercise`ディレクトリ内に、以下を含む`config-demo`というファイルを作成してください:
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
clusters:
|
||||
- cluster:
|
||||
name: development
|
||||
- cluster:
|
||||
name: scratch
|
||||
|
||||
users:
|
||||
- name: developer
|
||||
- name: experimenter
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
name: dev-frontend
|
||||
- context:
|
||||
name: dev-storage
|
||||
- context:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
設定ファイルには、クラスター、ユーザー、contextの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのcontextの情報が含まれています。
|
||||
|
||||
`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
|
||||
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
```
|
||||
|
||||
ユーザー情報を設定ファイルに追加してください:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
|
||||
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl config unset users.<name>`を実行すると、ユーザーを削除することができます。
|
||||
{{< /note >}}
|
||||
|
||||
context情報を設定ファイルに追加してください:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
追加した情報を確認するために、`config-demo`ファイルを開いてください。`config-demo`ファイルを開く代わりに、`config view`のコマンドを使うこともできます。
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view
|
||||
```
|
||||
|
||||
出力には、二つのクラスター、二人のユーザー、三つのcontextが表示されます:
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://5.6.7.8
|
||||
name: scratch
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
current-context: ""
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
- name: experimenter
|
||||
user:
|
||||
password: some-password
|
||||
username: exp
|
||||
```
|
||||
|
||||
上記の`fake-ca-file`、`fake-cert-file`、`fake-key-file`は、証明書ファイルの実際のパスのプレースホルダーです。環境内にある証明書ファイルの実際のパスに変更してください。
|
||||
|
||||
証明書ファイルのパスの代わりにbase64にエンコードされたデータを使用したい場合は、キーに`-data`の接尾辞を加えてください。例えば、`certificate-authority-data`、`client-certificate-data`、`client-key-data`とできます。
|
||||
|
||||
それぞれのcontextは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`contextは、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。
|
||||
|
||||
現在のcontextを設定してください:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
```
|
||||
|
||||
これ以降実行される`kubectl`コマンドは、`dev-frontend`contextに設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`contextに設定されたユーザーの認証情報を使用します。
|
||||
|
||||
現在のcontextの設定情報のみを確認するには、`--minify`フラグを使用してください。
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
出力には、`dev-frontend`contextの設定情報が表示されます:
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
current-context: dev-frontend
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
```
|
||||
|
||||
今度は、実験用のクラスター内でしばらく作業する場合を考えます。
|
||||
|
||||
現在のcontextを`exp-scratch`に切り替えてください:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
```
|
||||
|
||||
これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`contextに設定されたユーザーの認証情報を使用します。
|
||||
|
||||
新しく切り替えた`exp-scratch`contextの設定を確認してください。
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
最後に、`development`クラスター内の`storage`namespaceでしばらく作業する場合を考えます。
|
||||
|
||||
現在のcontextを`dev-storage`に切り替えてください:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-storage
|
||||
```
|
||||
|
||||
新しく切り替えた`dev-storage`contextの設定を確認してください。
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
## 二つ目の設定ファイルを作成する
|
||||
|
||||
`config-exercise`ディレクトリ内に、以下を含む`config-demo-2`というファイルを作成してください:
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
```
|
||||
|
||||
上記の設定ファイルは、`dev-ramp-up`というcontextを表します。
|
||||
|
||||
## KUBECONFIG環境変数を設定する
|
||||
|
||||
`KUBECONFIG`という環境変数が存在するかを確認してください。もし存在する場合は、後で復元できるようにバックアップしてください。例えば:
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
|
||||
```
|
||||
|
||||
`KUBECONFIG`環境変数は、設定ファイルのパスのリストです。リスト内のパスはLinuxとMacではコロンで区切られ、Windowsではセミコロンで区切られます。`KUBECONFIG`環境変数が存在する場合は、リスト内の設定ファイルの内容を確認してください。
|
||||
|
||||
一時的に`KUBECONFIG`環境変数に以下の二つのパスを追加してください。例えば:<br>
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
```
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG=("config-demo;config-demo-2")
|
||||
```
|
||||
|
||||
`config-exercise`ディレクトリ内から、以下のコマンドを実行してください:
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`contextの情報と、`config-demo`ファイルに設定された三つのcontextの情報がまとめてあることに注目してください:
|
||||
|
||||
```shell
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
kubeconfigファイルに関するさらなる情報を参照するには、[kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)を参照してください。
|
||||
|
||||
## $HOME/.kubeディレクトリの内容を確認する
|
||||
|
||||
既にクラスターを所持していて、`kubectl`を使ってクラスターを操作できる場合は、`$HOME/.kube`ディレクトリ内に`config`というファイルが存在する可能性が高いです。
|
||||
|
||||
`$HOME/.kube`に移動して、そこに存在するファイルを確認してください。`config`という設定ファイルが存在するはずです。他の設定ファイルも存在する可能性があります。全てのファイルの中身を確認してください。
|
||||
|
||||
## $HOME/.kube/configをKUBECONFIG環境変数に追加する
|
||||
|
||||
もし`$HOME/.kube/config`ファイルが存在していて、既に`KUBECONFIG`環境変数に追加されていない場合は、`KUBECONFIG`環境変数に追加してください。例えば:
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
```
|
||||
### Windows Powershell
|
||||
```shell
|
||||
$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config)
|
||||
```
|
||||
|
||||
`KUBECONFIG`環境変数内のファイルからまとめられた設定情報を確認してください。`config-exercise`ディレクトリ内から、以下のコマンドを実行してください:
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
`KUBECONFIG`環境変数を元に戻してください。例えば:
|
||||
|
||||
Linux:
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
```
|
||||
Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -27,7 +27,7 @@ weight: 70
|
|||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。
|
||||
ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。
|
||||
ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -189,8 +189,8 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Services](/docs/concepts/services-networking/service/)の詳細
|
||||
* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)の詳細
|
||||
* [Service](/ja/docs/concepts/services-networking/service/)の詳細
|
||||
* [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ weight: 60
|
|||
kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080
|
||||
```
|
||||
このコマンドは
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
|
||||
オブジェクトとそれに紐付く
|
||||
[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
|
||||
オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの
|
||||
|
|
@ -115,7 +115,7 @@ weight: 60
|
|||
## service configuration fileの利用
|
||||
|
||||
`kubectl expose`コマンドの代わりに、
|
||||
[service configuration file](/docs/concepts/services-networking/service/)
|
||||
[service configuration file](/ja/docs/concepts/services-networking/service/)
|
||||
を使用してServiceを作成することもできます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
---
|
||||
title: EndpointSliceの有効化
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページはKubernetesのEndpointSliceの有効化の概要を説明します。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 概要
|
||||
|
||||
EndpointSliceは、KubernetesのEndpointsに対してスケーラブルで拡張可能な代替手段を提供します。Endpointsが提供する機能のベースの上に構築し、スケーラブルな方法で拡張します。Serviceが多数(100以上)のネットワークエンドポイントを持つ場合、それらは単一の大きなEndpointsリソースではなく、複数の小さなEndpointSliceに分割されます。
|
||||
|
||||
## EndpointSliceの有効化
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
EndpointSliceは、最終的には既存のEndpointsを置き換える可能性がありますが、多くのKubernetesコンポーネントはまだ既存のEndpointsに依存しています。現時点ではEndpointSliceを有効化することは、Endpointsの置き換えではなく、クラスター内のEndpointsへの追加とみなされる必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
EndpointSliceはベータ版の機能とみなされますが、デフォルトではAPIのみが有効です。kube-proxyによるEndpointSliceコントローラーとEndpointSliceの使用は、デフォルトでは有効になっていません。
|
||||
|
||||
EndpointSliceコントローラーはクラスター内にEndpointSliceを作成し、管理します。これは、{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}と{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}の`EndpointSlice`の[フィーチャーゲート](/docs/reference/command-line-tools-reference/feature-gates/)で有効にできます(`--feature-gates=EndpointSlice=true`)。
|
||||
|
||||
スケーラビリティ向上のため、{{<glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}でフィーチャーゲートを有効にして、Endpointsの代わりにEndpointSliceをデータソースとして使用することもできます。
|
||||
|
||||
## EndpointSliceの使用
|
||||
|
||||
クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含める必要があります。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
---
|
||||
title: ストレージにProjectedボリュームを使用するようPodを設定する
|
||||
content_template: templates/task
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
|
||||
現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。
|
||||
|
||||
{{< note >}}
|
||||
`serviceAccountToken`はボリュームタイプではありません。
|
||||
{{< /note >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
## ProjectedボリュームをPodに設定する
|
||||
|
||||
この課題では、ローカルファイルからユーザーネームおよびパスワードの{{< glossary_tooltip text="Secret" term_id="secret" >}}を作成します。
|
||||
次に、単一のコンテナを実行するPodを作成し、[`projected`](/docs/concepts/storage/volumes/#projected)ボリュームを使用してそれぞれのSecretを同じ共有ディレクトリにマウントします。
|
||||
|
||||
以下にPodの設定ファイルを示します:
|
||||
|
||||
{{< codenew file="pods/storage/projected.yaml" >}}
|
||||
|
||||
1. Secretを作成します:
|
||||
|
||||
```shell
|
||||
# ユーザーネームおよびパスワードを含むファイルを作成します:
|
||||
echo -n "admin" > ./username.txt
|
||||
echo -n "1f2d1e2e67df" > ./password.txt
|
||||
|
||||
# これらのファイルからSecretを作成します:
|
||||
kubectl create secret generic user --from-file=./username.txt
|
||||
kubectl create secret generic pass --from-file=./password.txt
|
||||
```
|
||||
1. Podを作成します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
|
||||
```
|
||||
1. Pod内のコンテナが実行されていることを確認するため、Podの変更を監視します:
|
||||
|
||||
```shell
|
||||
kubectl get --watch pod test-projected-volume
|
||||
```
|
||||
出力は次のようになります:
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
test-projected-volume 1/1 Running 0 14s
|
||||
```
|
||||
1. 別の端末にて、実行中のコンテナへのシェルを取得します:
|
||||
|
||||
```shell
|
||||
kubectl exec -it test-projected-volume -- /bin/sh
|
||||
```
|
||||
1. シェル内にて、投影されたソースを含む`projected-volume`ディレクトリが存在することを確認します:
|
||||
|
||||
```shell
|
||||
ls /projected-volume/
|
||||
```
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
PodおよびSecretを削除します:
|
||||
|
||||
```shell
|
||||
kubectl delete pod test-projected-volume
|
||||
kubectl delete secret user pass
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [`projected`](/docs/concepts/storage/volumes/#projected)ボリュームについてさらに学ぶ
|
||||
* [all-in-oneボリューム](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)のデザインドキュメントを読む
|
||||
{{% /capture %}}
|
||||
|
|
@ -7,7 +7,7 @@ weight: 160
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
|
||||
|
||||
このページでは、プロセス名前空間を共有するPodを構成する方法を示します。
|
||||
プロセス名前空間の共有が有効になっている場合、コンテナ内のプロセスは、そのPod内の他のすべてのコンテナに表示されます。
|
||||
|
|
@ -20,9 +20,6 @@ weight: 160
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
プロセス名前空間の共有は**ベータ**機能であり、デフォルトで有効になっています。
|
||||
`--feature-gates=PodShareProcessNamespace=false`を設定することで無効にできます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ content_template: templates/task
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* [Pod](/docs/concepts/workloads/pods/pod/)と[Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)の基本を理解している必要があります。
|
||||
* [Pod](/ja/docs/concepts/workloads/pods/pod/)と[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の基本を理解している必要があります。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -329,7 +329,7 @@ kubectl get service hostnames -o json
|
|||
* `targetPort`を名前で定義しようとしている場合、`Pod`は同じ名前でポートを公開していますか？
|
||||
* ポートの`protocol`は`Pod`のものと同じですか？
|
||||
|
||||
## ServiceにEndpointがあるか？
|
||||
## ServiceにEndpointsがあるか？
|
||||
|
||||
ここまで来たということは、`Service`は存在し、DNSによって名前解決できることが確認できているでしょう。
|
||||
ここでは、実行した`Pod`が`Service`によって実際に選択されていることを確認しましょう。
|
||||
|
|
@ -347,7 +347,7 @@ hostnames-yp2kp 1/1 Running 0 1h
|
|||
"AGE"列は、これらの`Pod`が約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
|
||||
|
||||
`-l app=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。
|
||||
Kubernetesシステム内には、すべての`Service`のセレクターを評価し、結果を`Endpoint`オブジェクトに保存するコントロールループがあります。
|
||||
Kubernetesシステム内には、すべての`Service`のセレクターを評価し、結果を`Endpoints`オブジェクトに保存するコントロールループがあります。
|
||||
|
||||
```shell
|
||||
kubectl get endpoints hostnames
|
||||
|
|
@ -355,7 +355,7 @@ NAME ENDPOINTS
|
|||
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
|
||||
```
|
||||
|
||||
これにより、Endpointコントローラーが`Service`の正しい`Pod`を見つけていることを確認できます。
|
||||
これにより、Endpointsコントローラーが`Service`の正しい`Pod`を見つけていることを確認できます。
|
||||
`hostnames`行が空白の場合、`Service`の`spec.selector`フィールドが実際に`Pod`の`metadata.labels`値を選択していることを確認する必要があります。
|
||||
よくある間違いは、タイプミスまたは他のエラー、たとえば`Service`が`run=hostnames`を選択しているのに`Deployment`が`app=hostnames`を指定していることです。
|
||||
|
||||
|
|
@ -379,7 +379,7 @@ u@pod$ wget -qO- 10.244.0.7:9376
|
|||
hostnames-yp2kp
|
||||
```
|
||||
|
||||
`Endpoint`リスト内の各`Pod`は、それぞれの自身のホスト名を返すはずです。
|
||||
`Endpoints`リスト内の各`Pod`は、それぞれの自身のホスト名を返すはずです。
|
||||
そうならない(または、あなた自身の`Pod`の正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
|
||||
`kubectl logs`が役立つかもしれません。あるいは、`kubectl exec`で直接`Pod`にアクセスし、そこでサービスをチェックしましょう。
|
||||
|
||||
|
|
@ -398,7 +398,7 @@ hostnames-632524106-tlaok 1/1 Running 0 2m
|
|||
|
||||
## kube-proxyは機能しているか？
|
||||
|
||||
ここに到達したのなら、`Service`は実行され、`Endpoint`があり、`Pod`が実際にサービスを提供しています。
|
||||
ここに到達したのなら、`Service`は実行され、`Endpoints`があり、`Pod`が実際にサービスを提供しています。
|
||||
この時点で、`Service`のプロキシーメカニズム全体が疑わしいです。
|
||||
ひとつひとつ確認しましょう。
|
||||
|
||||
|
|
@ -579,7 +579,7 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1
|
|||
## 助けを求める
|
||||
|
||||
ここまでたどり着いたということは、とてもおかしなことが起こっています。
|
||||
`Service`は実行中で、`Endpoint`があり、`Pod`は実際にサービスを提供しています。
|
||||
`Service`は実行中で、`Endpoints`があり、`Pod`は実際にサービスを提供しています。
|
||||
DNSは動作していて、`iptables`ルールがインストールされていて、`kube-proxy`も誤動作していないようです。
|
||||
それでも、あなたの`Service`は機能していません。
|
||||
おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 30
|
|||
|
||||
このページでは、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
コントローラーを使用して、レプリカを持つステートフルアプリケーションを実行する方法を説明します。
|
||||
ここでの例は、非同期レプリケーションを行う複数のスレーブを持つ、単一マスターのMySQLです。
|
||||
ここでの例は、非同期レプリケーションを行う複数のスレーブを持つ、単一マスターのMySQLです。
|
||||
|
||||
**この例は本番環境向けの構成ではない**ことに注意してください。
|
||||
具体的には、MySQLの設定が安全ではないデフォルトのままとなっています。
|
||||
|
|
@ -23,7 +23,7 @@ weight: 30
|
|||
* このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/)
|
||||
と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、
|
||||
さらには[Pod](/ja/docs/concepts/workloads/pods/pod/)、
|
||||
[Service](/docs/concepts/services-networking/service/)、
|
||||
[Service](/ja/docs/concepts/services-networking/service/)、
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの
|
||||
他のコアな概念に精通していることを前提としています。
|
||||
* MySQLに関する知識は記事の理解に役立ちますが、
|
||||
|
|
@ -76,7 +76,7 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
|
|||
{{< codenew file="application/mysql/mysql-services.yaml" >}}
|
||||
|
||||
ヘッドレスサービスは、StatefulSetコントローラーが
|
||||
StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
|
||||
StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
|
||||
この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスタの
|
||||
同じ名前空間内の他のPodは、`<pod-name>.mysql`を名前解決することでPodにアクセスできます。
|
||||
|
||||
|
|
|
|||
|
|
@ -168,9 +168,9 @@ PersistentVolumeを手動でプロビジョニングした場合は、Persistent
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Deploymentオブジェクト](/docs/concepts/workloads/controllers/deployment/)についてもっと学ぶ
|
||||
* [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)についてもっと学ぶ
|
||||
|
||||
* [アプリケーションのデプロイ](/docs/user-guide/deploying-applications/)についてもっと学ぶ
|
||||
* [アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)についてもっと学ぶ
|
||||
|
||||
* [kubectl runのドキュメント](/docs/reference/generated/kubectl/kubectl-commands/#run)
|
||||
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ Deploymentを名前を指定して削除します:
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Deploymentオブジェクト](/docs/concepts/workloads/controllers/deployment/)の詳細
|
||||
* [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,116 @@
|
|||
---
|
||||
title: Helmを使用したサービスカタログのインストール
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}}
|
||||
|
||||
[Helm](https://helm.sh/)を使用してKubernetesクラスターにサービスカタログをインストールします。手順の最新情報は[kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md)リポジトリーを参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。
|
||||
* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
|
||||
* KubernetesクラスターのクラスターDNSを有効化する必要があります。
|
||||
* クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。
|
||||
* `hack/local-up-cluster.sh`を使用している場合は、環境変数`KUBE_ENABLE_CLUSTER_DNS`が設定されていることを確認し、インストールスクリプトを実行してください。
|
||||
* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。
|
||||
* v2.7.0以降の[Helm](http://helm.sh/)をインストールしてください。
|
||||
* [Helm install instructions](https://helm.sh/docs/intro/install/)を参考にしてください。
|
||||
* 上記のバージョンのHelmをすでにインストールしている場合は、`helm init`を実行し、HelmのサーバーサイドコンポーネントであるTillerをインストールしてください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
## Helmリポジトリーにサービスカタログを追加
|
||||
|
||||
Helmをインストールし、以下のコマンドを実行することでローカルマシンに*service-catalog*のHelmリポジトリーを追加します。
|
||||
|
||||
|
||||
```shell
|
||||
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
|
||||
```
|
||||
|
||||
以下のコマンドを実行し、インストールに成功していることを確認します。
|
||||
|
||||
```shell
|
||||
helm search service-catalog
|
||||
```
|
||||
|
||||
インストールが成功していれば、出力は以下のようになります:
|
||||
|
||||
```
|
||||
NAME CHART VERSION APP VERSION DESCRIPTION
|
||||
svc-cat/catalog 0.2.1 service-catalog API server and controller-manager helm chart
|
||||
svc-cat/catalog-v0.2 0.2.2 service-catalog API server and controller-manager helm chart
|
||||
```
|
||||
|
||||
## RBACの有効化
|
||||
|
||||
KubernetesクラスターのRBACを有効化することで、Tiller Podに`cluster-admin`アクセスを持たせます。
|
||||
|
||||
v0.25以前のMinikubeを使用している場合は、明示的にRBACを有効化して起動する必要があります:
|
||||
|
||||
```shell
|
||||
minikube start --extra-config=apiserver.Authorization.Mode=RBAC
|
||||
```
|
||||
|
||||
v0.26以降のMinikubeを使用している場合は、以下のコマンドを実行してください。
|
||||
|
||||
```shell
|
||||
minikube start
|
||||
```
|
||||
|
||||
v0.26以降のMinikubeを使用している場合、`--extra-config`を指定しないでください。
|
||||
このフラグは--extra-config=apiserver.authorization-modeを指定するものに変更されており、現在MinikubeではデフォルトでRBACが有効化されています。
|
||||
古いフラグを指定すると、スタートコマンドが応答しなくなることがあります。
|
||||
|
||||
`hack/local-up-cluster.sh`を使用している場合、環境変数`AUTHORIZATION_MODE`を以下の値に設定してください:
|
||||
|
||||
```
|
||||
AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
|
||||
```
|
||||
|
||||
`helm init`は、デフォルトで`kube-system`のnamespaceにTiller Podをインストールし、Tillerは`default`のServiceAccountを使用するように設定されています。
|
||||
|
||||
{{< note >}}
|
||||
`helm init`を実行する際に`--tiller-namespace`または`--service-account`のフラグを使用する場合、以下のコマンドの`--serviceaccount`フラグには適切なnamespaceとServiceAccountを指定する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
Tillerに`cluster-admin`アクセスを設定する場合:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding tiller-cluster-admin \
|
||||
--clusterrole=cluster-admin \
|
||||
--serviceaccount=kube-system:default
|
||||
```
|
||||
|
||||
|
||||
## Kubernetesクラスターにサービスカタログをインストール
|
||||
|
||||
以下のコマンドを使用して、Helmリポジトリーのrootからサービスカタログをインストールします:
|
||||
|
||||
{{< tabs name="helm-versions" >}}
|
||||
{{% tab name="Helm バージョン3" %}}
|
||||
```shell
|
||||
helm install catalog svc-cat/catalog --namespace catalog
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Helm バージョン2" %}}
|
||||
```shell
|
||||
helm install svc-cat/catalog --name catalog --namespace catalog
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)
|
||||
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog)
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -18,7 +18,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと
|
|||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Linuxへkubectlをインストールする
|
||||
## Linuxへkubectlをインストールする {#install-kubectl-on-linux}
|
||||
|
||||
### curlを使用してLinuxへkubectlのバイナリをインストールする
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ kubectl version
|
|||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## macOSへkubectlをインストールする
|
||||
## macOSへkubectlをインストールする {#install-kubectl-on-macos}
|
||||
|
||||
### curlを使用してmacOSへkubectlのバイナリをインストールする
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
|
|||
kubectl version
|
||||
```
|
||||
|
||||
## Windowsへkubectlをインストールする
|
||||
## Windowsへkubectlをインストールする {#install-kubectl-on-windows}
|
||||
|
||||
### curlを使用してWindowsへkubectlのバイナリをインストールする
|
||||
|
||||
|
|
@ -467,7 +467,7 @@ compinit
|
|||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [Minikubeをインストールする](/docs/tasks/tools/install-minikube/)
|
||||
* [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/)
|
||||
* クラスターの作成に関する詳細を[スタートガイド](/docs/setup/)で確認する
|
||||
* [アプリケーションを起動して公開する方法を学ぶ](/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for
|
|||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)の指示に従ってkubectlをインストールできます。
|
||||
[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ sudo install minikube /usr/local/bin/
|
|||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)の指示に従ってkubectlをインストールできます。
|
||||
[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ sudo mv minikube /usr/local/bin
|
|||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)の指示に従ってkubectlをインストールできます。
|
||||
[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ content_template: templates/concept
|
|||
|
||||
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
|
||||
|
||||
* [Hello Minikube](/docs/tutorials/hello-minikube/)
|
||||
* [Hello Minikube](/ja/docs/tutorials/hello-minikube/)
|
||||
|
||||
## 設定
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ card:
|
|||
このチュートリアルでは、[Minikube](/docs/getting-started-guides/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。
|
||||
|
||||
{{< note >}}
|
||||
[Minikubeをローカルにインストール](/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。
|
||||
[Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -65,7 +65,7 @@ card:
|
|||
|
||||
## Deploymentの作成
|
||||
|
||||
Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。
|
||||
Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/ja/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。
|
||||
|
||||
1. `kubectl create` コマンドを使用してPodを管理するDeploymentを作成してください。Podは提供されたDockerイメージを元にコンテナを実行します。
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの
|
|||
|
||||
## Serviceの作成
|
||||
|
||||
通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/docs/concepts/services-networking/service/)としてポッドを公開する必要があります。
|
||||
通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてポッドを公開する必要があります。
|
||||
|
||||
1. `kubectl expose` コマンドを使用してPodをインターネットに公開します:
|
||||
|
||||
|
|
@ -257,8 +257,8 @@ minikube delete
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Deploymentオブジェクト](/docs/concepts/workloads/controllers/deployment/)について学ぶ.
|
||||
* [アプリケーションのデプロイ](/docs/user-guide/deploying-applications/)について学ぶ.
|
||||
* [Serviceオブジェクト](/docs/concepts/services-networking/service/)について学ぶ.
|
||||
* [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)について学ぶ.
|
||||
* [アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)について学ぶ.
|
||||
* [Serviceオブジェクト](/ja/docs/concepts/services-networking/service/)について学ぶ.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ weight: 10
|
|||
<div class="col-md-8">
|
||||
<h3>Kubernetes Serviceの概要</h3>
|
||||
|
||||
<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/docs/concepts/workloads/pods/pod-overview/">Pod</a>には<a href="/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
|
||||
<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod-overview/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
|
||||
|
||||
<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ weight: 10
|
|||
<div class="col-md-8">
|
||||
<h3>アプリケーションのスケーリング</h3>
|
||||
|
||||
<p>前回のモジュールでは、<a href="/docs/concepts/workloads/controllers/deployment/">Deployment</a>を作成し、それを<a href="/docs/concepts/services-networking/service/">Service</a>経由で公開しました。該当のDeploymentでは、アプリケーションを実行するためのPodを1つだけ作成しました。トラフィックが増加した場合、ユーザーの需要に対応するためにアプリケーションをスケールする必要があります。</p>
|
||||
<p>前回のモジュールでは、<a href="/ja/docs/concepts/workloads/controllers/deployment/">Deployment</a>を作成し、それを<a href="/ja/docs/concepts/services-networking/service/">Service</a>経由で公開しました。該当のDeploymentでは、アプリケーションを実行するためのPodを1つだけ作成しました。トラフィックが増加した場合、ユーザーの需要に対応するためにアプリケーションをスケールする必要があります。</p>
|
||||
|
||||
<p><b>スケーリング</b>は、Deploymentのレプリカの数を変更することによって実現可能です。</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ weight: 10
|
|||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* [kubectl](/docs/tasks/tools/install-kubectl/)をインストールしてください。
|
||||
* [kubectl](/ja/docs/tasks/tools/install-kubectl/)をインストールしてください。
|
||||
|
||||
* Kubernetesクラスターを作成する際に、Google Kubernetes EngineやAmazon Web Servicesのようなクラウドプロバイダーを使用します。このチュートリアルでは、クラウドプロバイダーを必要とする[外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を作成します。
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
|||
```
|
||||
|
||||
|
||||
上記のコマンドにより、[Deployment](/docs/concepts/workloads/controllers/deployment/)オブジェクトを作成し、[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)オブジェクトを関連づけます。ReplicaSetには5つの[Pod](/docs/concepts/workloads/pods/pod/)があり、それぞれHello Worldアプリケーションが起動しています。
|
||||
上記のコマンドにより、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)オブジェクトを作成し、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)オブジェクトを関連づけます。ReplicaSetには5つの[Pod](/ja/docs/concepts/workloads/pods/pod/)があり、それぞれHello Worldアプリケーションが起動しています。
|
||||
|
||||
1. Deploymentに関する情報を表示します:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue