KubeEdge に基づくエッジノードグループ化管理の設計と実装

KubeEdge 1.11 バージョンでは、クロスリージョン アプリケーション デプロイメント モデルを抽象化する「エッジ ノード グループ管理」という新しい機能が提供されます。このモデルは、エッジノードをリージョンごとにノードグループに分割し、アプリケーションに必要なリソースをまとめてパッケージ化してノードグループに展開することで、エッジアプリケーションのライフサイクル管理の複雑さを軽減し、運用・保守コストを効果的に削減します。

1. エッジアプリケーションの地域間展開の課題

図1 エッジアプリケーションのクロスリージョン展開の概略図

エッジ コンピューティングのシナリオでは、エッジ ノードは通常、さまざまな地理的領域に分散されており、これらの領域内のノードはコンピューティング リソース、ネットワーク構造、ハードウェア プラットフォームなどのさまざまな属性を持ちます。図 1 に示すように、エッジ ノードは杭州、北京、上海などの地域に展開されています。異なるリージョンのエッジノードの規模は異なり、異なるリージョンのネットワークは相互運用可能ではなく、異なるリージョンのイメージリポジトリも異なります。たとえば、北京のノードは IP を介して他の地域のノードに直接アクセスすることはできません。したがって、エッジ アプリケーションを展開する場合、通常は、このような地理的領域ごとに展開を維持する必要があります。リソースが少ない領域では、レプリカの数を減らす必要があります。ローカル エリア ネットワーク内のノードの場合、イメージ アドレスをローカル イメージ リポジトリのアドレスに変更する必要があります。また、地域間ノード間のアクセス問題を解決するには、地域ごとに個別のサービス リソースを管理する必要もあります。ただし、地理的領域とアプリケーションの数が増えるにつれて、アプリケーションの管理はますます複雑になり、運用と保守のコストも増加します。上記の背景に基づいて、KubeEdge はエッジ ノード グループ管理機能を提供し、地域をまたいだアプリケーション展開における運用と保守の複雑さの問題を解決します。

2. エッジノードグループ管理の設計と実装

図2 エッジノードのグループ化の概要

図 2 に示すように、エッジ ノード グループ化機能の全体的な設計は、主にノード グループ化、エッジ アプリケーション、トラフィック クローズド ループの 3 つの部分で構成されます。以下では、上記の各部分について詳しく説明します。

2.1 ノードグループ

図3 ノードのグループ化の例

エッジ ノードの地理的な分布特性に応じて、同じエリア内のエッジ ノードをグループ化し、ノード グループの形式で編成できます。同じノードは一度に 1 つのノード グループにのみ属することができます。ノードのグループ化は、matchLabels フィールドでノード名またはノード ラベルを指定してノードを選択することで実行できます。ノードがグループに追加されると、ラベル apps.kubeedge.io/belonging-to:nodegroup が追加されます。

2.2 エッジアプリケーション

図4: エッジアプリケーションEdgeApplicationの構成

エッジ アプリケーションは、アプリケーション リソースをパッケージ化し、ノード グループに従ってデプロイし、異なるノード グループ間の差別化されたデプロイ要件を満たすために使用されます。このセクションでは、主に 2 つの部分で構成される新しい CRD: EdgeApplication を紹介します。

1. ワークロード テンプレート。主に、デプロイメント テンプレート、サービス テンプレート、ConfigMap テンプレートなど、エッジ アプリケーションに必要なリソース テンプレートが含まれます。
2. ワークロードスコープ。これは主に、レプリカ数の差別化構成 (レプリカ オーバーライド) やイメージの差別化構成 (イメージ オーバーライド) など、さまざまなノード グループのニーズを満たすためにリソース テンプレートの差別化構成に使用されます。イメージ オーバーライドには、イメージ ウェアハウスのアドレス、ウェアハウス名、ラベルが含まれます。

アプリケーション本体であるデプロイメントでは、デプロイメント テンプレートと差別化された構成 Overrider に従って、各グループに必要なデプロイメント バージョンが生成され、nodeSelector を調整することで指定されたグループにデプロイされます。 ConfigMap や Service など、アプリケーションが依存するその他のリソースについては、テンプレートを通じてクラスター内に対応するリソースが 1 つだけ作成されます。エッジ アプリケーションは、作成されたリソースのライフサイクル管理を実行します。エッジ アプリケーションが削除されると、作成されたすべてのリソースが削除されます。

2.3 フロー閉ループ

図5 フロー閉ループ図

クローズドループ トラフィック機能により、サービス トラフィックは同じノード グループに制限されます。ノード グループ内のサービスにアクセスする場合、バックエンドは常に同じノード グループ内にあります。 EdgeApplication でサービス テンプレートを使用してサービスを作成すると、service-topology:range-nodegroup アノテーションがサービスに追加されます。 KubeEdge クラウド コンポーネント CloudCore は、アノテーションに基づいてエンドポイントとエンドポイントスライスをフィルタリングし、同じノード グループにないバックエンドを削除して、エッジ ノードに送信します。

また、クラスター内のデフォルトのマスターサービス「Kubernetes」に関連付けられたエンドポイントとエンドポイントスライスが発行されると、それらが保持する IP アドレスがエッジノードの MetaServer アドレスに変更されます。ユーザーがエッジ アプリケーションでクラスター リソースを一覧表示/監視する場合、K8s トラフィック アクセス メソッドと互換性があり、シームレスな移行とドッキングを実現できます。

3. 実装原則と設計コンセプト

このセクションでは、エッジ ノード グループ管理機能の設計コンセプトを共有し、それを KubeEdge アーキテクチャ全体と組み合わせて、実装の原則を詳しく紹介します。

図6 設計コンセプト

ユーザーに統一された運用・保守ポータルを提供したいと考えています。本来は、各リージョンでデプロイメントを維持する必要がありました。操作を追加、削除、変更、またはクエリする必要がある場合、各リージョンのデプロイメントで同じ操作を実行する必要があり、運用および保守コストが増加するだけでなく、人為的エラーが発生しやすくなりました。エッジノードグループ管理機能は、EdgeApplication CRD を導入することで、Deployment などのリソースの運用・保守入口を統一します。

さらに、より大きな拡張の可能性を提供する必要があります。内部実装では、特定のリソースとの結合を減らし、その後の他のリソースの追加を容易にするために、非構造化構造を均一に使用します。また、ネイティブのリソースやプロセスに干渉しないように、Kubernetes Reconciliationとの結合を減らし、Deploymentなどのリソース操作プロセスのネイティブ性を確保しています。

図7 ノードグループとエッジアプリケーションの実装

エッジ ノード グループ管理機能では、ノード グループ NodeGroup とエッジ アプリケーション EdgeApplication という 2 つの CRD を導入しました。 NodeGroup 調整では、NodeGroup コントローラーを使用して NodeGroup CRD の変更を監視し、ノードの apps.kubeedge.io/belonging-to:nodegroup ラベルの追加、削除、変更などの操作を実行します。同時に、ノード グループに参加するノードは、そのステータスを NodeGroup CRD に報告します。 NodeGroup をクエリすることで、ノード グループ内のすべてのノードのステータスを直接表示できます。

EdgeApplication 調整は NodeGroup 調整に似ています。 EdgeApplication コントローラーは、EdgeApplication CRD の変更を監視し、対応するリソースを追加、削除、変更します。同時に、対応するリソースは EdgeApplication CRD にステータスを報告します。

図8 全体的なアーキテクチャ

図 8 に示すように、これは最終的な全体的なアーキテクチャ図です。エッジ ノード グループ管理機能では、先ほど導入した NodeGroup Controller と EdgeApplication Controller を含む新しいコンポーネント ControllerManager を導入しました。 CloudCore では、クローズドループ トラフィック機能を実現するために、新しいモジュール EndpointSlice Filter を導入しました。

図の青い領域は、先ほど紹介したノードのグループ化とエッジ アプリケーションの内容を表しています。ここでは、トラフィック クローズド ループ機能を実装するサービス テンプレートのプロセスに焦点を当てます。まず、EdgeApplication CRD にサービス テンプレートを追加します。エッジ アプリケーションを作成すると、Service range-nodegroup リソースも生成され、コントロール プレーンによって自動的に EndpointSlice が作成されます。 EndpointSlice は、KubeEdge のクラウド エッジ チャネルを介してエッジ ノードに送信されます。 CloudCore の EndpointSlice フィルターは、同じノード グループ内のエッジ ノードに送信されるようフィルター処理します。これにより、エッジ上のクライアント アクセスが常に同じノード グループ内で行われることが保証されます。

ユーザーにとって、図 8 の紫色の線は、ユーザーが維持する必要があるリソースを表します。まず、ユーザーはノード グループ内のノードを管理するために NodeGroup を維持する必要があります。 2 番目に、ユーザーは EdgeApplication リソースを維持し、EdgeApplication を使用してさまざまなリージョンのエッジ アプリケーションのライフサイクル管理を実装する必要があります。

4. 開発計画

現在、KubeEdge コミュニティは、Deployment、Service、ConfigMap などのリソースのパッケージ化とトラフィック ループを閉じる機能を実現し、リソースの部分的なステータス収集をサポートしています。今後は、エッジノードのグループ化機能の拡張、エッジゲートウェイの実装、StatefulSet などのリソースのサポート、アプリケーションステータス収集の段階的な改善、Kubectl でのよりわかりやすいリソース表示のサポートを継続していきます。 KubeEdge エッジ ノードのグループ化機能を改善および強化するために、誰でも KubeEdge コミュニティに参加できます。