From 9244f9e4aa8fe790e6fa2d30729cffb2ffd5f7b2 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 21 Aug 2020 15:29:14 +0900 Subject: [PATCH] translate cloud-controller.md --- .../concepts/architecture/cloud-controller.md | 140 ++++++------------ .../glossary/cloud-controller-manager.md | 18 +++ 2 files changed, 61 insertions(+), 97 deletions(-) create mode 100755 content/ja/docs/reference/glossary/cloud-controller-manager.md diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 8cf85db09b..0bff2a504e 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -1,21 +1,18 @@ --- -title: クラウドコントローラーマネージャーとそのコンセプト +title: クラウドコントローラーマネージャー content_type: concept weight: 40 --- -クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 +{{< feature-state state="beta" for_k8s_version="v1.11" >}} -クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 +クラウドインフラストラクチャ技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 -このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。 - -これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。 - -![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} +cloud-controller-managerは、プラグインメカニズムを用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。 @@ -23,91 +20,49 @@ weight: 40 ## 設計 -上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します: +![Kubernetes components](/images/docs/components-of-kubernetes.png) -* Kubelet -* Kubernetesコントローラーマネージャー -* Kubernetes APIサーバー +クラウドコントローラーマネージャーは、複製されたプロセスのセットとしてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 -CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります: - -![CCM Kube Arch](/images/docs/post-ccm-arch.png) - -## CCMのコンポーネント - -CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつかの機能群を切り離し、別のプロセスとして動かします。具体的には、KCMに含まれるクラウド依存のコントローラーを分離します。KCMは、下記に示すクラウド依存のコントローラーループを持っています: - - * ノードコントローラー - * ボリュームコントローラー - * ルートコントローラー - * サービスコントローラー - -バージョン1.9では、CCMは前述のリスト内の下記コントローラーを動かします: - -* ノードコントローラー -* ルートコントローラー -* サービスコントローラー {{< note >}} -ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。 +コントロールプレーンの一部ではなく、Kubernetesの{{< glossary_tooltip text="addon" term_id="addons" >}}としてクラウドコントローラーマネージャーを実行することもできます。 {{< /note >}} -CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。 +## クラウドコントローラーマネージャーの機能 {#functions-of-the-ccm} -これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。 - -## CCMの機能群 - -CCMは、クラウドに依存しているKubernetesのコンポーネントから機能を継承しています。このセクションはそれらのコンポーネントをベースに構造化されています。 - -### 1. Kubernetesコントローラーマネージャー - -CCMの大半の機能は、KCMから派生しています。前セクションで説明したとおり、CCMは下記のコントロールループを動かします: - -* ノードコントローラー -* ルートコントローラー -* サービスコントローラー +クラウドコントローラーマネージャーのコントローラーは以下を含んでいます。 #### ノードコントローラー -ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責務を持ちます。ノードコントローラーは下記に示す機能を実行します: +ノードコントローラーは、クラウドインフラストラクチャーで新しいサーバーが作成された際に、{{< glossary_tooltip text="Node" term_id="node" >}}オブジェクトを作成する責務を持ちます。ノードコントローラーは、クラウドプロバイダーのテナント内で動作しているホストの情報を取得します。ノードコントローラーは下記に示す機能を実行します: -1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する -2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する -3. ノードのネットワークアドレスとホスト名を取得する -4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する +1. Nodeオブジェクトを、コントローラーがクラウドプロバイダーAPIを通じて見つけた各サーバーで初期化する +2. Nodeオブジェクトに、ノードがデプロイされているリージョンや利用可能なリソース（CPU、メモリなど）のようなクラウド特有な情報を注釈付けやラベル付けをする +3. ノードのホスト名とネットワークアドレスを取得する +4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する + +いくつかのクラウドプロバイダーは、これをノードコントローラーと分離ノードライフサイクルコントローラーに分けて実装しています。 #### ルートコントローラー -ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 +ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。 + +クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。 #### サービスコントローラー -サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。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/)を参照してください。 +{{< glossary_tooltip text="Services" term_id="service" >}}は、マネージドロードバランサー、IPアドレスネットワークパケットフィルタや対象のヘルスチェックのようなクラウドインフラストラクチャーコンポーネントのインテグレーションを行います。サービスコントローラーは、ロードバランサーや他のインフラストラクチャーコンポーネントを必要とするServiceリソースを宣言する際にそれらのコンポーネントを設定するため、クラウドプロバイダーのAPIと対話します。 ## 認可 -このセクションでは、CCMが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。 +このセクションでは、クラウドコントローラーマネージャーが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。 -### ノードコントローラー +### ノードコントローラー {#authorization-node-controller} -ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 +ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、readとmodifyの全権限が必要です。 -v1/Node: +`v1/Node`: - Get - List @@ -117,23 +72,23 @@ v1/Node: - Watch - Delete -### ルートコントローラー +### ルートコントローラー {#authorization-route-controller} ルートコントローラーは、Nodeオブジェクトの作成を待ち受け、ルートを適切に設定します。Nodeオブジェクトについて、get権限が必要です。 -v1/Node: +`v1/Node`: - Get -### サービスコントローラー +### サービスコントローラー {#authorization-service-controller} -サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 +サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのEndpointを適切に設定します。 サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。 -サービスのエンドポイントを設定するため、create、list、get、watchそしてupdateの権限が必要です。 +サービスのEndpointリソースを設定するため、create、list、get、watchそしてupdateの権限が必要です。 -v1/Service: +`v1/Service`: - List - Get @@ -141,21 +96,21 @@ v1/Service: - Patch - Update -### その他 +### その他 {#authorization-miscellaneous} -CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。 +クラウドコントローラーマネージャーのコア機能の実装は、Eventオブジェクトのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。 -v1/Event: +`v1/Event`: - Create - Patch - Update -v1/ServiceAccount: +`v1/ServiceAccount`: - Create -CCMのRBAC ClusterRoleはこのようになります: +クラウドコントローラーマネージャーの{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRoleはこのようになります: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -219,25 +174,16 @@ rules: - update ``` -## ベンダー実装 -下記のクラウドプロバイダーがCCMを実装しています: +## {{% heading "whatsnext" %}} -* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) -* [AWS](https://github.com/kubernetes/cloud-provider-aws) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) -* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) -* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) -* [Linode](https://github.com/linode/linode-cloud-controller-manager) -* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) +[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +はクラウドコントラーマネージャーの実行と管理を説明しています。 +どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -## クラスター管理 - -CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。 +クラウドコントローラーマネージェーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 +プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。 diff --git a/content/ja/docs/reference/glossary/cloud-controller-manager.md b/content/ja/docs/reference/glossary/cloud-controller-manager.md new file mode 100755 index 0000000000..6e9c9104da --- /dev/null +++ b/content/ja/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,18 @@ +--- +title: クラウドコントローラーマネージャー +id: cloud-controller-manager +date: 2018-04-12 +full_link: /ja/docs/concepts/architecture/cloud-controller/ +short_description: > + サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント +aka: +tags: +- core-object +- architecture +- operation +--- + クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。 + + + +Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。