エッジコンピューティングシステムの構成とコンセプトについて、複数の図を使って詳しく説明します。まだ覚えていますか？

[[421799]]

この記事では、エッジ コンピューティング システムをコンポーネントと概念分析の 2 つの側面から説明します。

• コンポーネント: エッジ コンピューティング システムは、クラウド、エッジ、エンドの 3 つの部分で構成され、各部分に複数のソリューションが存在します。この記事では、クラウド コンポーネントとして Kubernetes、エッジ コンポーネントとして KubeEdge、エンド コンポーネントとして EdgeX Foundry を選択しています。
• 概念分析: エッジ コンピューティング システムを構成するクラウド、エッジ、エンド部分に関連する概念を説明します。

01 エッジコンピューティングシステムの構成

1. クラウド — Kubernetes

Kubernetes は、Google のオープンソースの大規模コンテナ オーケストレーション ソリューションです。ソリューション全体は、以下に示すように、コア コンポーネント、サードパーティ コンポーネント、およびコンテナー ランタイムで構成されます。

1) コアコンポーネント

• Kube-apiserver: Kubernetes 内部コンポーネントが相互に通信するためのメッセージ バスであり、クラスター API リソースを外部に公開するための唯一の出口です。
• Kube-controller: クラスター内のリソースの実際の状態が期待される状態と一致していることを確認します。
• Kube-scheduler: スケジュールする負荷と利用可能なリソースを最適に一致させます
• Kube-proxy: ノード内およびノー​​ド間の負荷アクセスのプロキシ
• Kubelet: Kube-schedulerのスケジューリング結果に従って対応する負荷を操作する

2) サードパーティコンポーネント

• Etcd: クラスターのメタデータとステータスデータを保存します
• フランネル

クラスター内のホスト間負荷ネットワーク通信のソリューション

元のデータ パケットをさらにカプセル化およびカプセル化解除する必要があり、その結果、パフォーマンスが大幅に低下します。

• カリコ

クラスター内のホスト間負荷ネットワーク通信のソリューション

純粋な3層ネットワークソリューション。追加のカプセル化やカプセル化解除は必要なく、パフォーマンスの低下も少ない

• CoreDNS: クラスタ内の負荷のドメイン名解決を担当します

3) コンテナランタイム

• Docker: 現在のデフォルトのコンテナランタイム
• Containerd: Docker よりも軽量で、Docker と同じくらい安定したコンテナ ランタイム
• クリオ

軽量コンテナランタイム

現時点では安定性は保証されていません

• フラクティ

ハイパーバイザーベースのコンテナランタイム

現時点では安定性は保証されていません

2. エッジ - KubeEdge

KubeEdge は、Huawei が開発したオープンソースの Kubernetes ベースのエッジ コンピューティング プラットフォームです。コンテナ化されたアプリケーションのオーケストレーション機能をクラウドからエッジノードやデバイスに拡張し、ネットワーク、アプリケーションの展開、クラウドとエッジ間のメタデータ同期のためのインフラストラクチャサポートを提供するために使用されます。 KubeEdge は Apache 2.0 ライセンスに基づいてライセンスされており、個人または商用での使用は無料です。

KubeEdge は、以下に示すように、クラウド部分、エッジ部分、およびコンテナ ランタイムで構成されています。

• クラウドコア
  • クラウドイベントと指示をエッジに送信し、エッジから報告されたステータス情報とイベント情報を受信する役割を担う
• エッジコア
  • クラウドからイベントと指示を受信し、関連する指示を実行し、エッジのステータスとイベント情報をクラウドに報告します。
• コンテナ ランタイム |ドッカー
  • 現在、KubeEdge はデフォルトで Docker をサポートしています。
  • 関係者は、将来的にはContainerdやCri-oなどのコンテナランタイムをサポートすると述べた。

3. 終了 - EdgeX Foundry

EdgeX Foundry は、Linux Foundation が運営するオープンソースのエッジ コンピューティング IoT ソフトウェア フレームワーク プロジェクトです。このプロジェクトの中核となるのは、ハードウェアやオペレーティング システムから完全に独立したリファレンス ソフトウェア プラットフォームに基づく相互運用性フレームワークであり、IoT ソリューションの導入を加速するためのプラグ アンド プレイ コンポーネント エコシステムを構築します。 EdgeX Foundry を使用すると、公開標準または独自のソリューションのどちらを使用しても、関心のある関係者がオープンで相互運用可能な IoT ソリューションを自由に共同で開発できます。

EdgeX Foundry マイクロサービス コレクションは、4 つのマイクロサービス レイヤーと 2 つの拡張基本システム サービスで構成されています。 4 つのマイクロサービス レイヤーには、物理​​ドメイン データの収集から情報ドメイン データ処理までの一連のサービスが含まれており、2 つの拡張基本システム サービスは 4 つのマイクロサービス レイヤーにサービス サポートを提供します。

物理層からアプリケーション層までの 4 つのマイクロサービス層は、デバイス サービス層、コア サービス層、サポート サービス層、エクスポート サービス層です。強化された 2 つの基本システム サービスには、セキュリティ サービスとシステム管理サービスが含まれます。具体的な内容は以下のとおりです。

1) デバイスサービス層

• Device-modbus-go: GoはModbusプロトコルを使用してデバイスに接続するサービスを実装します
• Device-camera-go: Go はカメラデバイスをドッキングするためのサービスを実装します
• Device-snmp-go: Go は SNMP サービス接続を実装します
• Device-mqtt-go: GoはMQTTプロトコルを使用してデバイスに接続するためのサービスを実装します
• デバイス SDK Go

Goは他のデバイスに接続するためのSDKを実装

SDKはデバイスアクセスの柔軟性を高めます

2) コアサービス層

• コアコマンド: サウスバウンドデバイスへのコマンド送信を担当
• コアメタデータ: デバイス自体の機能を記述し、新しいデバイスを構成して独自のデバイスサービスとペアリングする機能を提供します。
• コアデータ: 南方向のデバイス層データを収集し、北方向のサービスにデータサービスを提供する役割を担う
• レジストリと構成: サービスの登録と検出を担当し、マイクロサービス構成プロパティを含む EdgeX Foundry 関連サービスに関する情報を他の EdgeX Foundry マイクロサービスに提供します。

3) サポートサービス層

• サポートログ: ログ記録を担当
• サポート通知: イベント通知を担当
• サポートスケジューラ: データのスケジュールを担当

4) サービスレイヤーをエクスポートする

• エクスポートクライアント: データをエクスポートするためのクライアント
• エクスポートディストリビューション: データをエクスポートするためのアプリケーション

5) 強化された2つの基本システムサービス

• System-mgmt-agent: すべてのマイクロサービスを開始および停止するためのAPIを提供します
• Sys-mgmt-executor: すべてのマイクロサービスの最終的な実行の開始と停止を担当します。

02 コンセプト分析

エッジコンピューティングシステムを構成するクラウド、エッジ、エンドの関連概念は次のとおりです。

• クラウド: 関連する概念には、コンテナ、ポッド、レプリカセット、サービス、デプロイメント、デーモンセット、ジョブ、ボリューム、ConfigMap、ネームスペース、イングレスなどがあります。
• エッジ: 現在、エッジ システムはクラウドの元のコンポーネントを切り取ってエッジに沈める形で実装されているため、エッジに含まれる概念はクラウドのサブセットであり、クラウドと一致しています。
• 終了: エッジにデプロイされたマイクロサービスのセット。現在、新しい概念は導入されていません。

現在、エッジとエンドの両方でクラウドの概念が使用されているため、このセクションでは主にクラウドの概念を分析します。以下は、クラウドに関連する関連概念の図解です。図 1-1 に示すように、コンテナはオペレーティング システムに基づく新しい環境分離テクノロジです。コンテナによって分離された独立したスペースには、アプリケーションに必要なランタイム環境と依存ライブラリが含まれます。同じホスト上で、コンテナはオペレーティング システム カーネルを共有します。

▲図1-1 コンテナ分析

図 1-2 に示すように、Pod はコンテナのグループで構成され、同じ Pod 内のコンテナはストレージとネットワークの名前空間を共有します。エッジ コンピューティング システムでは、Pod はスケジュール可能な最小単位であり、アプリケーション負荷の最終的なキャリアです。

図1-2 ポッド分析

図 1-3 に示すように、ReplicaSet は Pod を管理するために使用され、予想される Pod の数と実際の Pod の数とが一致するようにする役割を担います。エッジ コンピューティング システムでは、ReplicaSet はアプリケーションの複数のインスタンスを維持し、障害から自己修復する役割を担います。

図1-3 レプリカセット分析

図 1-4 に示すように、サービスは Pod グループのアクセス プロキシとして機能し、複数の Pod 間で負荷分散を実行します。 Pod のライフサイクルは比較的短く、頻繁に変化します。サービスは、関連付けられているポッドのアクセス プロキシおよび負荷分散として機能するだけでなく、ポッドとの対応する関係も維持します。

▲図1-4 サービス分析

図 1-5 に示すように、Deployment は ReplicaSet を抽象化したものであって、ReplicaSet に基づいていくつかの高度な機能を追加します。機能と適用シナリオはReplicaSetと同じです。

図1-5 展開分析

図 1-6 に示すように、DaemonSet は各ノードで指定された Pod のインスタンスを起動する役割を担います。この機能は、通常、ネットワーク プラグイン、監視プラグイン、およびログ プラグインが展開されるシナリオで使用されます。

図1-6 DaemonSet分析

図 1-7 に示すように、ジョブはバッチで実行されるポッドを管理するために使用されます。このタイプの管理のポッドは、定期的にバッチでトリガーされます。 Deployment によって管理される Pod とは異なり、Job によって管理される Pod は、対応するタスクを完了すると終了し、システム内に残りません。エッジ コンピューティング システムでは、通常、ジョブによって管理されるポッドが AI モデルのトレーニングに使用されます。

▲図1-7 職務分析

図 1-8 に示すように、ボリュームは Pod にストレージを提供するために使用され、マウントによって対応する Pod に関連付けられます。ボリュームは一時ストレージと永続ストレージに分かれています。ポッドが削除されると一時ストレージ ボリュームは削除されますが、永続ストレージ ボリュームはポッドが削除されても削除されません。

▲図1-8 ボリューム分析

図 1-9 に示すように、ConfigMap は Pod が構成ファイルを保存するためのキャリアとして使用され、環境変数 (env) とファイル ボリュームを通じて Pod に関連付けられます。エッジ コンピューティング システムでは、ConfigMap モードで構成情報を管理する方が便利です。 ConfigMap は、構成情報をより安全にするために、構成内の機密情報を暗号化することもできます。

▲図1-9 ConfigMapの解析

図 1-10 に示すように、NameSpace は Pod、Service、ConfigMap、Deployment、DaemonSet などのリソースを分離するためのメカニズムです。これは通常、同じ会社内の異なるチーム間でリソースを分離するために使用されます。エッジ コンピューティング システムは、NameSpace を使用して、チームが使用できるリソース (CPU、メモリ) と、作成された負荷に必要なリソースを制限します。

▲図1-10 名前空間分析

図 1-11 に示すように、Ingress はクラスターとクラスター外部間の通信のブリッジとして機能し、クラスター内のサービスをクラスター外部に公開すると同時に、クラスターに入るトラフィックを適切に制御できます。エッジ コンピューティング システムでは、Ingress は Ingress コントローラーおよびリバース プロキシと連携する必要があるリソース オブジェクトです。

▲図1-11 侵入解析

著者について: Cui Guangzhang、Zhijiang Laboratory の上級研究スペシャリストであり、上級クラウド コンピューティングおよびエッジ コンピューティング技術エンジニア。 2014年にクラウドコンピューティングに携わり始めて以来、複数のクラウドコンピューティング制作プロジェクトに参加してきました。代表的なプロジェクトとしては、OpenStackをベースにカスタマイズされたオペレータプライベートクラウドやガバメントクラウド、オープンソースコンテナクラウドソリューションをベースにカスタマイズされたオペレータ向けデータセンターオペレーティングシステム（DCOS）などがあります。 2018年よりエッジコンピューティング関連の研究開発に着手。

この記事は「エッジコンピューティングの深い理解：クラウド、エッジ、エンドの動作原理とソースコード分析」から抜粋したもので、発行元によって承認されています。