Kubernetes クラウド コントローラー マネージャー

この投稿はもともと私が Medium.com に投稿したものであることに注意してください。その後、代わりに dev.to に移動することにしました!

この投稿は、Kubernetes の操作/実行と Go プログラミング言語の概念の両方についてある程度の経験があることを前提としています。

過去 1 年半の間、私たちは Etraveli Group で OpenStack と Kubernetes をたくさん使ってきました。私たちは独自のクラウドプロバイダーであり、エンドユーザーは開発者と開発組織の周囲のチームです。

OpenStack 上で Kubernetes を実行するための重要なコンポーネントの 1 つは、Cloud Controller Manager です。これは 2 つのプラットフォームを接着する部分の 1 つです。パブリック クラウド (さらに言えばプライベート) のどこかでマネージド Kubernetes サービスを使用している人にとっては、この問題はすでに解決されているでしょう。 Kubernetes コントロール プレーンは多かれ少なかれ手の届かないところにあります。

それでは、なぜクラウド コントローラー マネージャーについて何か書くのでしょうか?主な要因は、同僚の 1 人が尋ねた最も単純な質問です。

「(OpenStack) クラウド コントローラー マネージャーは一体何をするのですか?」

質問に答えようとしましたが、基本的に何を言っているのか分かりませんでした。タイプLoadBalancerのServiceオブジェクトが作成されるときに、基礎となるクラウドにロードバランサーを作成する役割があることは知っていました。

私はすぐにこれを少し掘り下げてみることにしました。そして、パズルのあらゆる部分を理解しようとして、かなり深く掘り下げることになりました。この投稿では、私の発見を要約します。

この投稿全体で以下を参照します:

• クラウド コントローラー マネージャー ("CCM"

)

• 「k/k」としての Kubernetes メイン ソース コード リポジトリ

• Kubernetes として "k8s"

この投稿を書き始めたときに、私は小さなプロジェクトとリポジトリを作成しました。そこでは、独自のクラウド コントローラー マネージャーを既定で構築し、2 つの小さな Kubernetes (v1.18.2) クラスターを相互に比較しました。 CCM とそうでないもの。これは概念実証であり、独自の CCM を実行するために正確に何が必要かを示すことを目的としています。 CCM を構成するコードから k8s マニフェストまで、すべてをデプロイする必要があります。

始める前に、この投稿は k8s ソース コード リポジトリのさまざまな部分にリンクしていることを知っておいてください。私は v1.18.0 タグを使用しました。

すべてのイラストは私自身のものです。

お楽しみください!

1 つか 2 つ (!) コメントを残してください。フィードバックは大歓迎です!

クラウドコントローラーマネージャー

クラウド コントローラー マネージャーは、高レベルの観点から見ると、次の 3 つの異なるものとして説明できます。

• バイナリ

• 多数の制御ループ

• k8s とクラウドの間の接着剤の一部

コード的には、CCM は k/k リポジトリの一部です。ここを見てください。公式の k8s ドキュメントで述べられているように、k/k の CCM のコードは独自の実装のスケルトンとして使用できます。違いは、クラウドと対話するために提供およびインポートするコード (パッケージ) です。

CCM は、ほとんどの場合、k8s マニフェストと、よく知られたコンテナー レジストリから取得された (Docker) コンテナーに組み込まれたバイナリを通じてデプロイされます。

注目に値するのは、CCM にはポート 10258 が割り当てられ、必要に応じてそれを公開する必要があることです。すぐに使用できる状態では、CCM は /healthz エンドポイントを公開して、サービスの健全性をチェックします。

GitHub の k8s 組織を見ると、さまざまな CCM 実装が見つかります。これらは、k/k リポジトリの外に存在し、次のようによく作られた Golang インターフェイスのセットで構成されているため、外部 CCM とも呼ばれます。また、誰もが独自の CCM を作成するための最低限の機能も備えています。

これについては後ほど詳しく説明します。

CCM のコアは、制御ループを実行する 4 つの (クラウド) コントローラーで構成されます。オプションで、独自のコントローラーを他のコントローラーと並行して実行できます。

次のセクションでは、CCM で実行されている各クラウド コントローラーについてさらに詳しく見ていきます。

ノードコントローラー

ノード コントローラーは、クラウド ノード (VM など) がラベル付けされ、汚染され、クラウド プロバイダーからのその他の関連情報で更新されていることを確認します。コントローラーは、順序なしリストで定期的に次の処理を実行します:

• 次のテイントを使用して、クラウド プロバイダーに追加された新しいノードを初期化します:node.cloudprovider.kubernetes.io/uninitialized を true に設定し、テイント効果を NoSchedule に設定します。ノード コントローラーによってノードが初期化されると、この汚染が削除され、ノード上でワークロードをスケジュールできるようになります。たとえば、重要なポッド。クラスターを実行すると、すでに汚染されたノードでスケジュールするために必要な許容範囲が当然確保されます。

• クラウドプロバイダーの IP アドレスと、k8s API の Node オブジェクトに保存されている IP アドレスを比較して、ノードの IP アドレスを更新します。

• クラウドから提供される情報を使用してノード ラベルを追加または更新します。これらには、インスタンス タイプ、ゾーン障害ドメイン、および ゾーン リージョンが含まれます。後で説明するように、ゾーン固有の情報は必須ではありません。

ノード ラベルと、上記のインスタンスに関する情報がフェッチされ、Node オブジェクトに追加される方法について。例を挙げると、OpenStack 外部 CCM は、ディスク (構成ディスク) からメタデータを読み取るか、各ノード内で到達可能なメタデータ サービス エンドポイントを使用することによってこれを実行します。

サービスコントローラー

サービス コントローラーは、クラウド内に作成されたサービス オブジェクト ベースのロード バランサーのライフ サイクルに関連するすべてを処理します。サービスは、k8s クラスターの観点からアプリケーションを内部および/または外部に公開する方法を提供します。

この特定のコントローラーは、LoadBalancer タイプの Service オブジェクトのみを処理します。これは、クラウド プロバイダーの観点から見ると、クラウド内で何らかのロード バランサーが作成、削除、更新されることを保証することを意味します。

CCM がサービス コントローラー ロジックをどのように実装したかに応じて、クラウド内のネットワーク トラフィックを内部で負荷分散のみするクラウド ロード バランサーを作成できます。これは通常、Service オブジェクトのメタデータ セクションで一連の注釈を定義することによって行われます。

例で述べたように、デフォルトの動作には注意してください。 OpenStack では、単純な Service オブジェクト (LoadBalancer タイプ) マニフェストを適用すると、次のオブジェクトが作成されます:

• トラフィックのロード バランシング先となるノードの入力済みリストを含むクラウド ロード バランサー。ロード バランサーは、生成されたランダムな NodePort

を使用してすべてのノードを指します。

• NodePort タイプの Service オブジェクト

上で見てきたように、実際には、k8s とクラウド プロバイダーの両方で Service オブジェクトを構成するものが多数あります。ユーザーにとって、これは、EXTERNAL-IP 列にクラウド ロード バランサーのクラウド プロバイダー IP が入力されることを意味します。 kubectl :

を使用して Service オブジェクトをリストするときに表示されます。

$> kubectl get service my-app-svc
NAME       TYPE         CLUSTER-IP    EXTERNAL-IP     PORT(S)
my-app-svc LoadBalancer 172.20.10.100 123.123.123.123 80:31147/TCP

ルートコントローラー

4 つのコントローラーのうち、少し特殊なものが 1 つあり、それは (クラウド) ルート コントローラーです。これは、 --allocate-node-cidrs または --configure-cloud-routes フラグを指定しない限り開始されません。 CCM。また、ルート処理ロジックを実装していない場合、このコントローラーは起動しません。これについては後ほど説明します。

このコントローラーは定期的に次のことを試行します:

• k8s クラスターに関連付けられたすべてのルートをリストします。これは、クラウド プロバイダー API をクエリすることによって行われます。

• k8s API をクエリして、すべてのノードをリストします。

• すべてのノードとノード仕様のpodCIDRsフィールドをループします。ポッド CIDR とノード名は、クラウド プロバイダー API 経由でルートを作成するために使用されます。

また、制御ループ中に、コントローラーは未使用のルートを削除します。すべてのルートが作成されると、ノードは準備完了とみなされます。これは、 NetworkUnavailable のノード条件フィールドが false に設定されることを意味します。ノードにルートが関連付けられていない場合、 NetworkUnavailable フィールドは true に設定されます。これらの状態は NodeLifeCycle コントローラーによってテイントに変換されますが、CCM が担当するものと混同しないようにしてください。

ライフサイクルコントローラー

(クラウド ノード)ライフサイクル コントローラーは、ノードがクラウドから削除された場合、Kubernetes API ノード オブジェクトとして表されるノードが確実に削除されるようにします。

また、ノードがクラウドプロバイダー指定のシャットダウン状態にある場合、ノードはそれに応じて、node.cloudprovider.kubernetes.io/shutdown と NoSchedule のテイント効果によって汚染されます。

これが CCM から得られる機能のほぼすべてです。ほとんどの場合、クラウドには Ingress タイプの k8s オブジェクトを処理するための独自のコントローラー (別のリポジトリから別のバイナリで提供される) が用意されている場合があります。基盤となるネットワーク インフラストラクチャとネイティブに統合します。

CCM はワンストップショップのソリューションではなく、より大きなパズルのピースの上にあるだけです。

これまでの説明を読み、CCM が処理するさまざまなコントローラーのソース コードを確認したことがある方は、クラウド プロバイダー固有のコードがどこにも見当たらないことに気付いたかもしれません。さまざまなオブジェクトに対して、やや謎めいたメソッドが多数呼び出されているだけです。

クラウド プロバイダー固有のコードとその配線は、この CCM パズルの欠けている部分になります。

バックミラーを見てください

CCM パズルの欠けているピースであるクラウド プロバイダー パッケージ (k8s.io/cloud-provider) に進む前に、CCM とクラウド プロバイダーの背後にある歴史の一部を確認します。彼らが長年にわたってどのように進化し、すべてがどのようにして生まれたのか。

明らかな理由から、当初からクラウド統合は k8s の一部の基礎でした。 2015 年 7 月にリリースされた v1.0 の k8s リポジトリ (k/k) 内に特定のプロバイダー コードを持つクラウド プロバイダーを見てみましょう。

• AWS
• GCE
• メソス
• OpenStack
• オヴィルト
• ラックスペース
• 浮浪者

上記の「クラウド プロバイダー」はすべてご存知かと思いますが、その一部は仮想化テクノロジであり、一般的にクラウド プロバイダーとして認識されているものに正確には当てはまりません。控えめに言っても。

2015 年 7 月に遡ると、クラウド プロバイダー固有のコードはすべてインポートされ、k8s クラスター ノードを構成する重要なノード コンポーネントの 1 つである kubelet によって使用されました。

k8s のコミュニティが認識し、現在まで取り組んでいるクラウド プロバイダー固有のコードの元の実装には多くの問題があります。

ここ数年の間に表面化した問題の一部を以下に示します。

• kubelet はクラウド プロバイダー固有の制御ループを実行しません。これは CCM に移動されました。

• クラウド プロバイダーは k/k (ツリー内) の一部であってはなりません。その理由は、クラウド プロバイダーのコードが k8s リリース サイクルに拘束され、k/k にコードをコミットすることができるためです。退屈な作業です。

• クラウドと k8s を統合するプラグ可能な方法を備えた別個のパッケージを提供することで、外部 (ツリー外) クラウド プロバイダーをサポートします。これは k8s.io/cloud-provider パッケージになりました。

• CCM によって使用されるすべてのクラウド コントローラー コードは、k8s.io/cloud-provider パッケージに移動されます。ツリー内には、移動されるコードの残りがまだ残っています。

下位互換性の理由から、ツリー内にあったコードはしばらく存在しますが、現在は独自のパッケージ (k8s.io/legacy-cloud-providers) になっています。

私は、まるでデジタル考古学のように、k8s 組織内のさまざまなリポジトリを調べて、CCM と k8s.io/cloud-provider がどのように誕生したかを追ってみました。ハイライトの一部を以下に示します:

• 2016 年 9 月に、ツリー外のクラウド プロバイダー (プラグ可能) をサポートするために拡張 #88 (KEP) 問題が作成されました。

• 2016 年 10 月、(kube) コントローラー マネージャーを 2 つの部分に分割し始めました。この PR では volumeController について言及していることに注意してください。これは CSI より前の時点です。それ以来、そのコントローラーは CCM から削除されました。

• クラウド コントローラー マネージャーのディスカッション 2017 年 7 月。v1.11 でベータ版になりました。

• ここでは、kubelet とクラウド プロバイダーがかつてどれほど密接に結びついていたかをよく説明しています。 kubelet とクラウドプロバイダーを分離する方法には 3 つのアプローチがあります。

クラウドプロバイダーパッケージ

クラウド プロバイダー パッケージは、CCM に k8s.io/cloud-provider としてインポートされ、多数の (Golang) インターフェイスを定義します。主なものは、このパッケージをクラウド プロバイダーにプラグイン可能にするインターフェイス インターフェイスです。

インターフェイスは一連のメソッドを定義し、これらの一部は他のインターフェイスを返します。これらの返されたインターフェイスは、クラウド プロバイダー パッケージのcloud.go ファイルでも定義されます。

$> kubectl get service my-app-svc
NAME       TYPE         CLUSTER-IP    EXTERNAL-IP     PORT(S)
my-app-svc LoadBalancer 172.20.10.100 123.123.123.123 80:31147/TCP

上記のとおり、メソッド シグネチャでは、返されるインターフェイスとともに bool 戻り値が指定されています。これは、CCM で実装できない、または実装すべきでない機能を有効/無効にできることを意味します。これは、インターフェイスによって定義された機能を実装するコントローラーの初期化中にチェックされるものです。

ここでは、どのコントローラーでどの k8s.io/cloud-provider インターフェイス メソッドが使用されているかを簡単に説明します。

• インスタンス インターフェイス メソッドは、ノードおよびライフサイクル コントローラーから呼び出されます。

• ゾーン インターフェイス メソッドは、ノードとライフサイクル コントローラーから呼び出されます。

• Route インターフェイスのメソッドは、Route コントローラーから呼び出されます。

• LoadBalancer インターフェースのメソッドは Service コントローラーから呼び出されます。

• クラスタ インターフェースは、GCP 外部クラウド プロバイダーによってのみ使用されます。

k/k リポジトリには、上記のインターフェイスのさまざまなメソッドへのコールアウトがある場所が多数あることに注意してください。 kubelet と API サーバーの両方にあります。

k8s.io/cloud-provider パッケージ上のインターフェイスに加えて、CCM でクラウド プロバイダーを登録および初期化するために必要なすべてのものが含まれています。

LoadBalancer インターフェースを見てみましょう。実装する必要があるメソッドが多数表示されます。

LoadBalancer() (LoadBalancer, bool)
Instances() (Instances, bool)
Zones() (Zones, bool)
Clusters() (Clusters, bool)
Routes() (Routes, bool)

これらのメソッドは、CCM で実行されるサービス コントローラーによって呼び出されます。これらのメソッドは、サービス コントローラーのソース コードで呼び出されていることがわかるため、例として示しています。

実際に CCM 全体に渡されるのは、クラウド プロバイダーとして動作する (すべてのクラウド プロバイダー インターフェイスを満たす) インスタンス化されたオブジェクトです。

これは、CCM が管理するクラウド コントローラーがクラウド内のリソースを作成、更新、削除できる方法です。

k8s.io/cloud-provider パッケージは接続方法を定義しません。クラウドに対して認証します。この種のロジックは、CCM に組み込む必要があります。

k8s.io/cloud-provider パッケージで定義されているすべてのインターフェイスを満たし、すべてを接続すると、クラウド プロバイダーになることができます。残っている唯一のことは、CCM バイナリをビルドしてコンテナにパッケージ化し、それを k8s にデプロイすることです!

今後に向けて、k/k リポジトリのクラウド プロバイダー部分を見ると実際に多くのことが起こっています。これを書いている時点では、k8s.io/cloud-provider を多かれ少なかれ再構築して作成するための取り組みが進行中です。独立した。つまり、例えばクラウド コントローラーは k8s.io/cloud-provider パッケージの一部になります。これは、最終的にクラウド プロバイダーとして 1 つのパッケージをインポートして、独自の CCM と外部クラウド プロバイダーを構築および実装できることを意味します。

Kubernetes の観点から見ると

新しく組み立てられ Docker パッケージ化された CCM を実行できるようにするには、k8s コントロール プレーンを起動するときにいくつかの設定を行う必要があります。

• kubelet は --cloud-provider=external フラグで開始されます。これは、ノードを初期化している別のコントローラーがあることを kubelet に通知します。

この投稿の冒頭で述べたように、独自の外部クラウド プロバイダー CCM を実行する際の技術的な側面を示して説明するリポジトリがあります。

たとえば、現在 AWS を使用して EC2 インスタンス上で独自の k8s クラスターを起動していて、AWS へのよりネイティブな統合を望んでいる場合は、クラウド プロバイダーの AWS CCM をデプロイしたでしょう。推奨されませんが、kubelet で --cloud-provider=aws を指定することもできます。これは、ツリー内クラウド プロバイダー を使用したいことを k8s に通知する方法です。実装されているプロバイダーはほんの一握りです。世の中の「新しい」プライベート/パブリック クラウドには、外部のクラウド プロバイダー CCM が存在します。

ツリー内クラウド プロバイダーのコードは、 k8s.io/legacy-cloud-providers を通じてインポートされます。k/k の CCM スケルトン コードを使用する場合は、このパッケージを最初からインポートすることになることに注意してください。 .

リソース

k8s のコンテキストにおけるクラウド プロバイダーに関連するすべてに関して何が起こっているのかを知るには、次のリソースを参照してください:

• SIG クラウドプロバイダー

• k8s Slack スペースのチャネル sig-cloud-provider

• sig/cloud-provider でラベル付けされたすべての k8s 拡張問題

ここに外部クラウド プロバイダーのリストを示します。参考として使用したり、他のプロバイダーがどのように行っているか知りたいだけの場合に最適です。

• OpenStack

• デジタルオーシャン

• AWS

• GCP

• アリババクラウド

• Huawei クラウド

• 百度クラウド

• vSphere

• アズール

以上がKubernetes クラウド コントローラー マネージャーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。