From 1b61cff84ed4785c3e9bb228974b0308a8ebf310 Mon Sep 17 00:00:00 2001 From: Kozzy Hasebe Date: Wed, 28 Aug 2019 01:22:53 +0900 Subject: [PATCH 1/4] Translate concepts/architecture/cloud-controller/ into Japanese --- .../concepts/architecture/cloud-controller.md | 239 ++++++++++++++++++ 1 file changed, 239 insertions(+) create mode 100644 content/ja/docs/concepts/architecture/cloud-controller.md diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md new file mode 100644 index 0000000000000..63441b326b01b --- /dev/null +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -0,0 +1,239 @@ +--- +title: クラウドコントローラーマネージャーとそのコンセプト +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 + +クラウドコントローラーマネージャーの設計は、新しいクラウドプロバイダーがプラグインを使うことでKubernetesと簡単に統合を出来るようにする、プラグイン機構をベースにしています。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングをする、また古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させる計画があります。 + +このドキュメントでは、クラウドコントローラーマネージャーの裏にあるコンセプトと、それに関連する機能の詳細について話します。 + +これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。 + +![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) + +{{% /capture %}} + + +{{% capture body %}} + +## 設計 + +上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します: + +* Kubelet +* Kubernetesコントローラーマネージャー +* KubernetesAPIサーバー + +CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります: + +![CCM Kube Arch](/images/docs/post-ccm-arch.png) + +## CCMのコンポーネント + +CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつかの機能群を切り離し、別のプロセスとして動かします。具体的には、KCMに含まれるクラウド依存のコントローラーを分離します。KCMは、下記に示すクラウド依存のコントローラーループを持っています: + + * ノードコントローラー + * ボリュームコントローラー + * ルートコントローラー + * サービスコントローラー + +バージョン1.9では、CCMは前述のリスト内の下記コントローラーを動かします: + +* ノードコントローラー +* ルートコントローラー +* サービスコントローラー + +{{< note >}} +ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。 +{{< /note >}} + +CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、Flexボリュームを使うことでした。しかし、競合しているCSIとして知られている機能が、Flexを置き換える予定です。 + +これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。 + +## CCMの機能群 + +CCMは、クラウドに依存しているKubernetesのコンポーネントから機能を継承しています。このセクションはそれらのコンポーネントをベースに構造化されています。 + +### 1. Kubernetesコントローラーマネージャー + +CCMの大半の機能は、KCMから派生しています。前セクションで説明したとおり、CCMは下記のコントロールループを動かします: + +* ノードコントローラー +* ルートコントローラー +* サービスコントローラー + +#### ノードコントローラー + +ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責任があります。ノードコントローラーは下記に示す機能を実行します: + +1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する +2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する +3. ノードのネットワークアドレスとホスト名を取得する +4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、Kubernetesからノードオブジェクトを削除する + +#### ルートコントローラー + +ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責任があります。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 + +#### サービスコントローラー + +サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責任があります。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するため、設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 + +### 2. Kubelet + +ノードコントローラーは、kubeletのクラウドに依存している機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責任がありました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。 + +この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。 + +## プラグイン機構 + +クラウドコントローラーマネージャーは、Goインターフェースを利用してクラウドの実装をプラグイン出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 + +上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。 + +プラグインを開発するためのさらなる情報は、[クラウドコントローラーマネージャーを開発する](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を参照してください。 + +## 認可 + +このセクションでは、CCMが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。 + +### ノードコントローラー + +ノードコントローラーはノードオブジェクトのみを処理します。ノードオブジェクトについて、get、list、create、update、patch、watch、そしてdeleteのフル権限が必要です。 + + +v1/Node: + +- Get +- List +- Create +- Update +- Patch +- Watch +- Delete + +### ルートコントローラー + +ルートコントローラーは、ノードオブジェクトの作成を待ち受け、ルートを適切に設定します。ノードオブジェクトについて、get権限が必要です。 + +v1/Node: + +- Get + +### サービスコントローラー + +サービスコントローラーは、サービスオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 + +サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。 + +サービスのエンドポイントを設定するため、create、list、get、watchそしてupdateの権限が必要です。 + +v1/Service: + +- List +- Get +- Watch +- Patch +- Update + +### その他 + +CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、サービスアカウントのcreate権限が必要です。 + +v1/Event: + +- Create +- Patch +- Update + +v1/ServiceAccount: + +- Create + +CCMのRBAC ClusterRoleはこのようになります: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: cloud-controller-manager +rules: +- apiGroups: + - "" + resources: + - events + verbs: + - create + - patch + - update +- apiGroups: + - "" + resources: + - nodes + verbs: + - '*' +- apiGroups: + - "" + resources: + - nodes/status + verbs: + - patch +- apiGroups: + - "" + resources: + - services + verbs: + - list + - patch + - update + - watch +- apiGroups: + - "" + resources: + - serviceaccounts + verbs: + - create +- apiGroups: + - "" + resources: + - persistentvolumes + verbs: + - get + - list + - update + - watch +- apiGroups: + - "" + resources: + - endpoints + verbs: + - create + - get + - list + - watch + - update +``` + +## ベンダー実装 + +下記のクラウドプロバイダーがCCMを実装しています: + +* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [Linode](https://github.com/linode/linode-cloud-controller-manager) + +## クラスター管理 + +CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。 + +{{% /capture %}} From fb963e0a762c7cd1b65e7e1820167717b0dade4f Mon Sep 17 00:00:00 2001 From: Kozzy Hasebe Date: Wed, 28 Aug 2019 10:15:47 +0900 Subject: [PATCH 2/4] Revise sentences based on suggestion by reviewers --- .../concepts/architecture/cloud-controller.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 63441b326b01b..afdaab833bcd3 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -8,9 +8,9 @@ weight: 30 クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 -クラウドコントローラーマネージャーの設計は、新しいクラウドプロバイダーがプラグインを使うことでKubernetesと簡単に統合を出来るようにする、プラグイン機構をベースにしています。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングをする、また古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させる計画があります。 +クラウドコントローラーマネージャーの設計は「プラグイン機構」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 -このドキュメントでは、クラウドコントローラーマネージャーの裏にあるコンセプトと、それに関連する機能の詳細について話します。 +このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。 これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。 @@ -27,7 +27,7 @@ weight: 30 * Kubelet * Kubernetesコントローラーマネージャー -* KubernetesAPIサーバー +* Kubernetes APIサーバー CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります: @@ -70,30 +70,30 @@ CCMの大半の機能は、KCMから派生しています。前セクション #### ノードコントローラー -ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責任があります。ノードコントローラーは下記に示す機能を実行します: +ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責務を持ちます。ノードコントローラーは下記に示す機能を実行します: 1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する 2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する 3. ノードのネットワークアドレスとホスト名を取得する -4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、Kubernetesからノードオブジェクトを削除する +4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNode objectを削除する #### ルートコントローラー -ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責任があります。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 +ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 #### サービスコントローラー -サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責任があります。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するため、設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 +サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 ### 2. Kubelet -ノードコントローラーは、kubeletのクラウドに依存している機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責任がありました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。 +ノードコントローラーは、kubeletのクラウドに依存した機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責務を持っていました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。 この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。 ## プラグイン機構 -クラウドコントローラーマネージャーは、Goインターフェースを利用してクラウドの実装をプラグイン出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 +クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。 @@ -105,7 +105,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション ### ノードコントローラー -ノードコントローラーはノードオブジェクトのみを処理します。ノードオブジェクトについて、get、list、create、update、patch、watch、そしてdeleteのフル権限が必要です。 +ノードコントローラーはNode objectのみを処理します。Node objectについて、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 v1/Node: @@ -120,7 +120,7 @@ v1/Node: ### ルートコントローラー -ルートコントローラーは、ノードオブジェクトの作成を待ち受け、ルートを適切に設定します。ノードオブジェクトについて、get権限が必要です。 +ルートコントローラーは、Node objectの作成を待ち受け、ルートを適切に設定します。Node objectについて、get権限が必要です。 v1/Node: @@ -128,7 +128,7 @@ v1/Node: ### サービスコントローラー -サービスコントローラーは、サービスオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 +サービスコントローラーは、Service objectの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。 @@ -144,7 +144,7 @@ v1/Service: ### その他 -CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、サービスアカウントのcreate権限が必要です。 +CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。 v1/Event: From 1730a13575221eb76a87da2f7804523638e054b1 Mon Sep 17 00:00:00 2001 From: Kozzy Hasebe Date: Wed, 28 Aug 2019 10:51:17 +0900 Subject: [PATCH 3/4] Revise a sentence based on suggestion by a reviewer --- content/ja/docs/concepts/architecture/cloud-controller.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index afdaab833bcd3..5473ee5bc757d 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -105,8 +105,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション ### ノードコントローラー -ノードコントローラーはNode objectのみを処理します。Node objectについて、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 - +ノードコントローラーはNode objectのみに対して働きます。Node objectに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 v1/Node: From 37027e82b793771923b072b545ba36217331f5d0 Mon Sep 17 00:00:00 2001 From: Kozzy Hasebe Date: Wed, 28 Aug 2019 11:16:50 +0900 Subject: [PATCH 4/4] Fix wording to distinguish Kubernetes related resources from others --- content/ja/docs/concepts/architecture/cloud-controller.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 5473ee5bc757d..1e3e607d8b44e 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -75,7 +75,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション 1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する 2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する 3. ノードのネットワークアドレスとホスト名を取得する -4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNode objectを削除する +4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する #### ルートコントローラー @@ -105,7 +105,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション ### ノードコントローラー -ノードコントローラーはNode objectのみに対して働きます。Node objectに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 +ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 v1/Node: @@ -119,7 +119,7 @@ v1/Node: ### ルートコントローラー -ルートコントローラーは、Node objectの作成を待ち受け、ルートを適切に設定します。Node objectについて、get権限が必要です。 +ルートコントローラーは、Nodeオブジェクトの作成を待ち受け、ルートを適切に設定します。Nodeオブジェクトについて、get権限が必要です。 v1/Node: @@ -127,7 +127,7 @@ v1/Node: ### サービスコントローラー -サービスコントローラーは、Service objectの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 +サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。