エッジコンピューティングクラウドネイティブオープンソースソリューションの比較

Kubernetes はコンテナオーケストレーションとスケジューリングの事実上の標準となっているため、主要なパブリッククラウドベンダーはすでに Kubernetes をベースにした包括的な Kubernetes クラウドホスティングサービスを提供しています。同時に、ますます多くの企業や業界が Kubernetes を本番環境で使用し始め、クラウドネイティブを採用し始めていることもわかります。さまざまな業界でデジタル変革とクラウド移行が進む中、パブリッククラウドベンダーも従来のオフライン環境を積極的に取り入れ、クラウド機能をエッジ (またはオフライン) に拡張するためのさまざまなソリューションを検討しています。

[[384045]]

Kubernetes は基盤となるアーキテクチャの違いを隠すため、さまざまなインフラストラクチャ上でアプリケーションをスムーズに実行できるようになります。クラウド上の Kubernetes サービスも、サービス境界の拡大を検討しています。クラウドネイティブとエッジコンピューティングを組み合わせるというアイデアが自然に生まれています。

現在、国内のさまざまなパブリッククラウドベンダーも、Kubernetes をベースとした独自のエッジコンピューティングクラウドネイティブプロジェクトをオープンソース化しています。 Huawei Cloud の KubeEdge、Alibaba Cloud の OpenYurt、Tencent Cloud の SuperEdge など。現在、インターネット上では、これらのプロジェクトの長所と短所を技術的な観点から紹介する記事はほとんどありません。この記事では、これらのプロジェクトを技術的な観点とオープンソースの観点から分析し、プロジェクトを選択する際に参考となる情報を提供したいと考えています。

01比較思考

これらのプロジェクトはすべて、クラウドエッジ統合とクラウドエッジ共同アーキテクチャを備えており、Kubernetes とエッジコンピューティングを組み合わせています。そこで、以下の点から比較することにしました。

（１）各プロジェクトのオープンソース状況：オープンソースプロジェクトの背景、オープンソース化された時期、CNCFへの参加の有無など。

（２）Kubernetesアーキテクチャ：

まず、Kubernetes とのアーキテクチャの違いを比較します。Kubernetes を変更するかどうか、Kubernetes のワンクリック変換などに焦点を当てます。
アーキテクチャの違いと Kubernetes の機能強化に基づいて、エッジの自律性、エッジのユニット化、軽量機能に主に焦点を当てています。
最後に、アーキテクチャの違いが及ぼす可能性のある影響について、主に運用・保守監視機能、クラウドネイティブエコシステムの互換性、システムの安定性などに焦点を当てて見ていきます。

（３）エッジコンピューティングシナリオのサポート機能：

端末機器管理機能が利用可能かどうかに主に焦点を当てる

次に、上記の観点から各プロジェクトをプロジェクトのオープンソース順に紹介します。

02エッジクラウドネイティブオープンソースプロジェクトの比較

2.1キューブエッジ

（１）オープンソースの状況

KubeEdge は 2018 年 11 月に Huawei Cloud によってオープンソース化され、現在は CNCF インキュベーションプロジェクトとなっています。その構造は次のとおりです。

（２）Kubernetesとのアーキテクチャの違い

まず、アーキテクチャ図から、クラウド（k8s マスター）には Cloud Hub コンポーネントと各種コントローラーが追加されているのに対し、エッジ（k8s ワーカー）にはネイティブ kubelet と kube-proxy はなく、ネイティブコンポーネントを書き換える EdgeCore コンポーネントがあることがわかります。

アーキテクチャ図から、EdgeCore が kubelet に基づいて再構築されていることがわかります。軽量性を確保するために、ネイティブ kubelet の一部の機能が削減され、同時にエッジシナリオに適応するための多くの機能が追加されます。詳細は以下の通りです。

Cloud Hub+EdgeHub モジュール: ネイティブの Kubernetes コンポーネント間データ同期リスト/ウォッチメカニズムを廃止し、Websocket/Quic プロトコルに基づくクラウドからエッジへのプッシュモードに変更しました。
ノードメタデータキャッシュモジュール (MetaManager): ノードディメンションデータをローカル SQLite データベースに保持します。クラウドエッジネットワークが不安定な場合、Edged モジュールはビジネスライフサイクル管理のためにローカルデータベースからデータを取得します。
DeviceController+デバイス管理モジュール (DeviceTwin): デバイス管理機能を EdgeCore に直接統合し、ユーザーにネイティブのデバイス管理機能を提供します。

Kubernetes と比較すると、上記のアーキテクチャ設計には次の機能強化があります。

エッジの自律性: ノードメタデータキャッシュを追加することで、クラウドとエッジの切断状態を回避できます。エッジビジネスまたはノードが再起動されると、エッジコンポーネントはローカルキャッシュデータを使用してビジネスを復元できるため、エッジの自律性の利点がもたらされます。
軽量: 一部の kubelet 機能 (CSI、CNI など) が削減され、エッジ EdgeCore コンポーネントはネイティブ kubelet コンポーネントよりも軽量になります。同時に、ノードに SQLite データベースが追加されるため、ノードのディメンションがネイティブノードよりも軽量であるかどうかはまだ確認されていません。詳しい学生はデータの提供を歓迎します。

アーキテクチャの違いによる影響は次のようになります。

クラウドネイティブエコシステムの互換性が不十分:

コミュニティと同期して進化するのは非常に困難です。Kubernetes システムへの侵入的な変更により、Kubernetes コミュニティの進化に追従するのは非常に困難になります。
エッジノードはオペレーターを実行できません。クラウドとエッジ間の通信メカニズムの変更により、Cloud Hub は限られた数のリソース (Pod、ConfigMap など) のみをエッジにプッシュできます。 Operator には、カスタム CRD リソースと、関連リソースへのクラウドベースのアクセスのリスト/監視の両方が必要です。したがって、コミュニティ Operator は KubeEdge のエッジノード上で実行できません。
エッジノードは、クラウドをリスト/監視する必要があるアプリケーションの実行には適していません。クラウドとエッジ間の通信メカニズムが変更されたため、元々リスト/監視メカニズムを使用して kube-apiserver にアクセスする必要があったアプリケーションは、ハブトンネルチャネルを介して kube-apiserver にアクセスできなくなり、エッジ側のクラウドネイティブ機能が大幅に低下します。

運用および保守監視機能の限定サポート:

現在のクラウドとエッジ間の通信リンクは、kube-apiserver --> コントローラー --> Cloud Hub --> EdgeHub --> MetaManager などとなっており、ネイティブ Kubernetes の運用・保守操作 (kubectl proxy/logs/exec/port-forward/attch など) は、kube-apiserver が直接 kubelet に要求しているためです。現在、KubeEdge コミュニティの最新バージョンでは、kubectl logs/exec/metric のみがサポートされており、その他の運用および保守操作はまだサポートされていません。

システム安定性の改善は未定です:

増分データに基づくクラウドエッジプッシュモードは、エッジウォッチが失敗したときに全額を再リストすることによって発生する kube-apiserver の負荷問題を解決し、ネイティブ Kubernetes アーキテクチャと比較してシステムの安定性を向上させることができます。
インフラ制御データと業務制御データの結合: Kubernetes クラスターの制御データ (Pod、ConfigMap データなど) とエッジ業務データ (デバイス制御データ) は同じ Websocket リンクを使用します。エッジが多数のデバイスを管理している場合や、デバイスの更新頻度が高すぎる場合、大量の業務データがクラスターの正常な制御に影響を与え、システムの安定性が低下する可能性があります。

エッジコンピューティングシナリオサポート機能

デバイス管理機能: この機能はエッジに直接統合されており、IoT ユーザーに特定のネイティブデバイス管理機能を提供します。

2.2オープンユルト

（１）オープンソースの状況

OpenYurt は 2020 年 5 月に Alibaba Cloud によってオープンソース化され、現在は CNCF サンドボックスプロジェクトとなっています。アーキテクチャは次のとおりです。

（２）Kubernetesとのアーキテクチャの違い

OpenYurt のアーキテクチャ設計は比較的シンプルで、Kubernetes を強化するために非侵襲的なアプローチを採用しています。クラウド (K8s マスター) に Yurt コントローラーマネージャー、Yurt アプリマネージャー、およびトンネルサーバーコンポーネントを追加します。エッジ側 (K8s Worker) には、YurtHub および Tunnel Agent コンポーネントが追加されます。アーキテクチャの観点から、エッジシナリオに適応するために次の機能が追加されました。

YurtHub: 各エッジコンポーネントからの通信要求を K8s マスターにプロキシし、要求によって返されたメタデータをノードディスクに保持します。クラウドエッジネットワークが不安定な場合、エッジサービスのライフサイクル管理にはローカルディスクデータが使用されます。同時に、クラウド側の Yurt コントローラーマネージャーは、エッジビジネスポッドの削除ポリシーを制御します。
トンネルサーバー/トンネルエージェント: 各エッジノード上のトンネルエージェントは、クラウドトンネルサーバーとの双方向の認証済み暗号化 gRPC 接続をアクティブに確立します。同時に、クラウドはこの接続を通じてエッジノードとそのリソースにアクセスします。
Yurt App Manager: 2 つの CRD リソースが導入されました: NodePool と UnitedDeployment。前者は、同じリージョンにあるノードのバッチ管理方法を提供します。後者は、ノードプールディメンションでワークロードを管理するための新しいエッジアプリケーションモデルを定義します。

Kubernetes と比較すると、上記のアーキテクチャ設計には次の機能強化があります。

エッジのユニット化: Yurt App Manager コンポーネントを通じて、異なるリージョンに分散されたエッジリソースがユニット化された観点から管理され、各リージョンユニットのサービスに対して独立したライフサイクル管理、アップグレード、拡張と縮小、トラフィックのクローズドループ機能が提供されます。そして、ビジネスにはいかなる適応や変革も必要ありません。
エッジの自律性: 各エッジノードにキャッシュ機能を備えた透過プロキシ YurtHub が追加されているため、クラウドエッジネットワークが切断されていることを確認できます。ノードまたはビジネスが再起動された場合、ローカルキャッシュデータを使用してビジネスを復元できます。
クラウドエッジ連携（運用保守監視）：トンネルサーバー/トンネルエージェントの連携により、ファイアウォール内のエッジノードに安全なクラウドエッジ双方向認証暗号化チャネルが提供されます。エッジからクラウドネットワークへの一方向接続を備えたエッジコンピューティングシナリオでも、ユーザーはネイティブ Kubernetes 操作およびメンテナンスコマンド (kubectl proxy/logs/exec/port-forward/attach など) を実行できます。同時に、集中型の運用・保守監視システム（Prometheus、Metrics-Server など）も、クラウドエッジチャネルを通じてエッジ監視データを取得できます。
クラウドネイティブエコシステムの互換性:

すべての機能はアドオンまたはコントローラーの形で強化され、Kubernetes を強化します。これにより、Kubernetes およびクラウドネイティブコミュニティエコシステムとの 100% の互換性が保証されます。
OpenYurt プロジェクトでは、ネイティブ Kubernetes と OpenYurt クラスター間のワンクリック変換に使用できる YurtCtl ツールも提供されていることも注目に値します。

アーキテクチャの違いによる影響の可能性

ネイティブ Kubernetes によってもたらされるシステム安定性の課題: OpenYurt は Kubernetes を変更しないため、この問題はエッジシナリオにおけるネイティブ Kubernetes の問題でもあります。クラウドエッジが長時間切断された後に復旧すると、エッジからクラウドへの完全なリスト要求が大量に生成され、kube-apiserver に大きな負荷がかかります。エッジノードが多すぎると、システムの安定性に大きな問題が生じます。
エッジでの軽量ソリューションなし: OpenYurt は Kubernetes を変更しませんが、エッジノードに YurtHub および Tunnel Agent コンポーネントを追加します。現時点では最小の1C1Gシステムで正常に動作しており、より小型の仕様のマシンではまだ検証されていません。

エッジコンピューティングのシナリオ

デバイス管理機能なし: OpenYurt は現在、デバイス管理機能を提供していません。ユーザーは、ワークロードの形式で独自のデバイス管理ソリューションを実行する必要があります。これはアーキテクチャ設計の欠点ではありませんが、エッジシナリオでは依然として欠点となります。

2.3スーパーエッジ

（１）オープンソースの状況

SuperEdge は、2020 年 12 月末に Tencent Cloud によってオープンソース化されましたが、まだオープンソースの初期段階にあります。そのアーキテクチャは次のとおりです。

（２）Kubernetesとのアーキテクチャの違い

SuperEdge のアーキテクチャ設計は比較的シンプルで、Kubernetes を強化するために非侵襲的なアプローチも採用しています。クラウド (K8s マスター) に、Application-Grid Controller、Edge-Health Admission、および Tunnel Cloud コンポーネントを追加します。エッジ側 (K8s Worker) には、Lite-Apiserver、Tunnel Edge、Application-Grid Wrapper コンポーネントが追加されます。アーキテクチャの観点から、エッジシナリオに適応するために次の機能が追加されました。

Lite-Apiserver: 各エッジコンポーネントからの通信要求を K8s マスターにプロキシし、要求によって返されたメタデータをノードディスクに保持します。クラウドエッジネットワークが不安定な場合、エッジサービスのライフサイクル管理にはローカルディスクデータが使用されます。同時に、エッジ Edge-Health レポート情報に基づいて、クラウド Edge-Health Admission がエッジビジネス Pod の削除戦略を制御します。
トンネルクラウド/トンネルエッジ: 各エッジノードのトンネルエッジは、クラウドトンネルクラウドとの双方向の認証済み暗号化 gRPC 接続をアクティブに確立します。同時に、クラウドはこの接続を通じてエッジノードとそのリソースにアクセスします。
アプリケーショングリッドコントローラー: 2 つの CRD リソース (ServiceGrids と DeploymentGrids) が導入されました。前者は、同じエリアにあるビジネストラフィックのクローズドループ管理を提供します。後者は、ノードプールの観点からワークロードを管理するための新しいエッジアプリケーションモデルを定義します。

OpenYurtとの比較

SuperEdge のアーキテクチャと機能を分析した結果、SuperEdge はアーキテクチャと機能の面で基本的に OpenYurt と同じであることがわかりました。これは、大手メーカーがエッジコンピューティングやクラウドネイティブの分野に本格的に投資していることを間接的に裏付けるものでもあります。
SuperEdge と Kubernetes の比較分析については、OpenYurt の分析を参照してください。ここでは、コードの観点から SuperEdge と OpenYurt の違いを分析します。
YurtHub と Lite-Apiserver: YurtHub は完全な証明書管理メカニズムとローカルデータキャッシュ設計を採用していますが、Lite-Apiserver はノード kubelet 証明書とシンプルなデータキャッシュを使用します。
トンネルコンポーネント: OpenYurt のトンネルコンポーネントは、Kubernetes コミュニティのオープンソースプロジェクト ANP (github.com/kubernetes-s) に基づいており、完全な証明書管理メカニズムも実装しています。 SuperEdge のトンネルコンポーネントもノード証明書を使用し、要求の転送は自己カプセル化された gRPC 接続に基づいています。ネイティブ gRPC と比較すると、OpenYurt の最下層にある ANP は、kube-apiserver の進化によりよく適応します。
ユニット化された管理コンポーネント: OpenYurt ユニット化された管理はデプロイメントと StatefulSet をサポートしますが、SuperEdge ユニット化された管理はデプロイメントのみをサポートします。さらに、OpenYurt の NodePool と UnitedDeployment の API 定義は標準的なクラウドネイティブ設計のアイデアですが、SuperEdge の ServiceGrids と DeploymentGrids の API 定義はよりカジュアルに見えます。
エッジステータス検出: この機能は OpenYurt には実装されていません。 SuperEdge の設計では、ノード間の相互アクセスのために kubelet がノードアドレスを監視する必要があり、これには一定のセキュリティリスクが伴います。同時に、ヘルスチェックによって東西トラフィックが大量に消費されます。この部分の今後の最適化にご期待ください。

2.4 比較結果の概要

上記の比較分析によると、結果は次の表にまとめられます。

03 結論

さまざまなオープンソースプロジェクトを比較した結果、次のような感想を持ちました。

KubeEdge と OpenYurt/SuperEdge のアーキテクチャ設計はまったく異なります。それに比べると、OpenYurt/SuperEdge のアーキテクチャ設計はよりエレガントです。 OpenYurt と SuperEdge は類似したアーキテクチャ設計を備えています。 SuperEdge は OpenYurt よりも後にオープンソース化されたため、成熟度がまだ低いです。

本番環境でエッジコンピューティングクラウドネイティブプロジェクトを選択する場合は、次の点を考慮します。

組み込みのデバイス管理機能が必要で、クラウドネイティブエコシステムの互換性を気にしない場合は、KubeEdge をお勧めします。
クラウドネイティブエコシステムの互換性とプロジェクトの成熟度を考慮し、デバイス管理機能が必要ないか、独自のデバイス管理機能を構築できる場合は、OpenYurt をお勧めします。

<<: [Sticky JVM] 5年ぶりにJVMのロードメカニズムを知る時が来ました！

>>: ハイブリッドクラウドの将来はどうなるのでしょうか? 3つのキーワード: エッジコンピューティング、自動化、クラウドネイティブ