osm-edgeについて

osm-edge は Open Service Mesh v1.1.0 コードベースの上に構築されており、エッジ コンピューティングを目的として構築されており、軽量で高い- パフォーマンスが高く、クラウド ネイティブで、プログラム可能なプロキシ Pipy をデータ プレーンおよびサイドカー プロキシとして使用。

osm-edge は、シンプルで完全なスタンドアロンの service mesh であり、完全なサービス メッシュをデプロイするために必要なすべてのコンポーネントが付属しています。 .軽量で SMI 互換のサービス メッシュとして、osm-edge は直感的でスケーラブルになるように設計されています。

osm-edge 1.1 には Flomesh Service Mesh (FSM) がバンドルされており、Kubernetes の North-South トラフィック マネージャーであり、イングレス コントローラー、ゲートウェイ API、ロード バランサー、およびクロスを提供します。 -クラスター サービスの登録とサービスの検出。

FSM の助けを借りて、osm-edge は、安全で、アプリケーションに対して完全に透過的で、ネットワーク トポロジーから独立した方法で、クラスターの境界を越えて Kubernetes サービスを接続できるようになりました。障害のあるサービスまたはアクセスできないサービスからのすべてのトラフィックを、そのサービスの 1 つ以上のレプリカ (他のクラスター上のレプリカを含む) に自動的にリダイレクトする自動フェイルオーバー機能。

なぜosm-edge?

実際には、サービス メッシュに対する同様の要件を持つさまざまな業界のユーザーに遭遇しました。 これらの業界ユーザーとシナリオは次のとおりです:

  • エネルギーおよび電力会社。彼らは、各変電所またはガソリン スタンドにシンプルなサーバー ルームを構築して、その場所のカバレッジ エリア内のデバイスによって生成されたデータを処理するためのコンピューティングおよびストレージ容量を展開したいと考えています。従来のデータセンター アプリケーションをこれらのシンプルな部屋にプッシュし、データセンター アプリケーションの管理および運用機能を最大限に活用したいと考えています。
  • テレマティクス サービス プロバイダー。彼らは、データ収集と自動車や車両所有者へのサービス提供のために、データセンター以外の環境にシンプルなコンピューティング環境を構築したいと考えています。これらの環境は、高速道路の場所、駐車場、または交通量の多いエリアの近くにある可能性があります
  • 小売業者。各店舗に最小限のコンピューティング環境を構築したいと考えており、在庫、販売、支払いの収集などの従来の機能をサポートすることに加えて、データの収集、処理、送信の新しい機能を導入したいと考えています。 ※医療機関。彼らは、すべての病院または単純な診療所にネットワーク機能を提供したいと考えています。これにより、患者にデジタル サービス機能を提供するだけでなく、データ収集と上位管理部門とのデータ リンケージを同時に完了することができます。 *教育機関、病院、キャンパスなど。これらのキャンパスは、比較的規則的で密度の高い人の流れが特徴です。彼らは、デジタル サービスを提供し、リアルタイムでデータを収集して処理するために、より多くの人が集まる場所の近くにコンピューティング リソースを配置したいと考えています。

これらは典型的なエッジ コンピューティング シナリオであり、同様のニーズがあります:

  • ユーザーは、従来のデータ センター コンピューティング モデル、特にマイクロサービスと、関連するアプリケーションの配信、管理操作、およびメンテナンス機能をエッジ側に持ち込むことを望んでいます
  • 作業環境に関しては、ユーザーは電源供給、限られた計算能力、不安定なネットワークなどの要因に対処する必要があります。したがって、コンピューティング プラットフォームは、より堅牢であり、迅速に展開したり、極端な状況でコンピューティング環境を完全に復旧したりできる必要があります。
  • 通常展開する必要があるロケーション (POP =Point of Presence と呼びます) の数は膨大で、常に進化し、拡大しています。 POP ポイントのコスト、メンテナンスのコスト、および拡張のコストはすべて重要なコスト考慮事項です。
  • 一般的な、またはローエンドの PC サーバーは、これらのシナリオでクラウド標準サーバーを置き換えるために使用されることが多くなります。 ARM などの低電力テクノロジ ベースのコンピューティング パワーは、ローエンドの PC サーバーに取って代わりつつあります。これらのハードウェア プラットフォームは、クラウド標準サーバーに匹敵するものではありませんが、ユーザーは依然として、機能とデータ量の増加に対処するのに十分なコンピューティング パワーを必要としています。データが生成される場所にコンピューティングを近づけるという相反する要求、エッジでのデータ量と機能要件の増加、およびエッジでの限られたコンピューティング リソースにより、エッジ側のコンピューティング プラットフォームはより優れたコンピューティング電力効率比、つまり、最小限の電力と最小限のサーバーで、より多くのアプリケーションを実行し、より多くのデータ ボリュームをサポートします。
  • 脆弱性と多数の POP ポイントにより、マルチクラスター、クロス POP フェールオーバーのためのより優れたアプリケーション サポートが必要になります。たとえば、POP ポイントに障害が発生した場合、近隣の POP ポイントがコンピューティング タスクをすばやく共有したり、一時的に引き継いだりすることさえできます。

クラウド データ センター コンピューティング シナリオと比較して、エッジ コンピューティングの 3 つの主な相違点と難点は次のとおりです:

  • エッジ コンピューティングには、異種ハードウェア アーキテクチャのサポートが必要です。 x86 以外のコンピューティング能力がエッジで広く使用されており、多くの場合、低消費電力と低コストという利点があります。
  • エッジ コンピューティングの POP ポイントは脆弱です。 この脆弱性は、非常に信頼性の高い電源がないか、電源がデータセンターほど強力ではないという事実に反映されています。 データセンターの一定の温度と換気よりも悪い環境で動作する可能性があります。 彼らのネットワークは狭帯域で不安定かもしれません
  • エッジ コンピューティングは当然のことながら分散コンピューティングです。 ほとんどすべてのエッジ コンピューティング シナリオでは、複数の POP ポイントが存在し、POP ポイントの数は継続的に増加しています。 POP ポイントは相互に障害を防ぎ、障害が発生した場合に隣接する POP ポイントに移行できます。これは、エッジ コンピューティングの基本的な機能です。

エッジ サイドへの Kubernetes の進化は、エッジ コンピューティングの問題、特に脆弱性に対する問題をある程度解決します。 一方、エッジ側へのサービス メッシュの開発では、エッジ コンピューティングにおけるネットワークの問題に焦点を当て、ネットワークの脆弱性に対処し、障害移行などの分散型ネットワークの基本的なサポートを提供します。 実際には、コンテナ プラットフォームは、今日の事実上の準標準的なアプリケーション配信手段として急速にエッジ側に進化しており、k3s などのエッジ機能をターゲットにした多数のリリースが行われています。 ; しかし、コンテナ プラットフォームの重要なネットワーク拡張であるサービス メッシュは、この傾向にすぐには追いついていません。 現在、ユーザーがエッジ コンピューティング シナリオのサービス メッシュを見つけることは困難であるため、[osm-edge][1] というオープン ソース プロジェクトをいくつかの重要な考慮事項と目標とともに開始しました。

  • SMI仕様のサポートと互換性により、サービスメッシュ管理の標準化に対するユーザーのニーズを満たすことができます
  • 「一流市民」またはエッジ コンピューティングの優先コンピューティング プラットフォームである ARM エコシステムの完全なサポート。サービス メッシュは、この傾向に完全に適合する必要があります。 [osm-edge][1] は ARM First 戦略に従います。これは、すべての機能が最初に ARM プラットフォームで開発、テスト、提供されることを意味します
  • 高性能で低リソース。 インフラストラクチャとしてのサービス メッシュは、エッジでより高いパフォーマンス (TPS/レイテンシ) を提供しながら、より少ないリソース (CPU/MEM) を使用する必要があります。

特徴

  • 軽量、高性能、クラウドネイティブ、拡張可能
  • 追加設定なしで x86、ARM アーキテクチャをサポート
  • 展開用のトラフィック シフティングを簡単かつ透過的に構成する
  • 相互 TLS を有効にしてサービス間の通信を保護する
  • サービスのきめ細かいアクセス制御ポリシーを定義して実行する
  • デバッグおよび監視サービスのためのアプリケーション メトリックに対する可観測性と洞察
  • プラグイン可能なインターフェイスを使用して、外部の証明書管理サービス/ソリューションと統合する
  • Pipy プロキシの自動サイドカー インジェクションを有効にして、アプリケーションをメッシュにオンボードします。
  • fsm を使用して、Kubernetes の方法でマルチクラスター Kubernetes をサポートします。
  • イングレス/イーグレスおよびゲートウェイ API をサポート
  • MQTT などのプロトコルをサポート

Architecture diagram

Pipy の密結合を解消し、サード パーティがデータ プレーンまたはサイドカー プロキシを開発または利用できるようにするために、「OSM v1.1.0」コードベースをリファクタリングして汎用化し、拡張ポイントを提供しました。 私たちはオープンソースを強く信じてサポートしており、このリファクタリングのproposalは、レビュー、議論、および/または利用のためにアップストリームに提出されています。