エッジコンピューティング向け統合スケジューリングソリューションの検討

パート01エッジコンピューティングソリューションの概念的定義

図1

上図1に示すように、「AIエッジコンピューティング技術白書」 ^[5]で提案されているエッジコンピューティングシステムの定義では、クラウドデータセンターを中核として、エッジコンピューティングは3つのレベルに分かれています。

• クラウド エッジ:クラウド サービスの CDN ノードまたはさまざまな都市や郡の分散データ センターに展開されたクラウド コンピューティング リソース。既存のクラウドコンピューティングサービスに最も近いエッジコンピューティング形式です。機能コンピューティング、AI インテリジェント サービス、クラウド レンダリングなどのエッジ クラウド サービスを提供できます。
• モバイル エッジ: 5G 通信の発展とともに登場したエッジ コンピューティングの新しい形態。 5G ネットワークは帯域幅が広く、遅延が少ないという特徴があるため、5G 基地局 + 端末を通じて最適なエッジ ロケーションを実現できます。しかし、5G基地局にクラウドコンピューティング機能を導入するには、基地局に大幅な改修が必要になります。さらに、基地局のスペースと電力配分の制限により、大規模なコンピューティング機能を展開することができません。
• Edge of Things:スマートフォン、VR ヘッドセット、スマート カメラなど、端末自体にコンピューティング機能が備わっています。コンピューティング要求は端末上でローカルに処理されるため、応答遅延は低く、安定したパフォーマンスは最適化されますが、電力消費や物理リソースなどの要因によって制限され、通常は単純なコンピューティング タスクしか完了しません。

上記の 3 つのエッジ コンピューティング レベルの特徴を総合的に比較すると、エッジ オブ シングスはユーザー端末のコンピューティング能力を使用して単純なトランザクションを処理し、クラウド レンダリング、ビッグ データ分析、AI スマート サービスなどの重いコンピューティング シナリオのニーズを満たすためにコンピューティング能力を拡張できないことがわかります。また、モバイル エッジには、スペースと電力配分の面で固有の制限があり、ユーザー端末に高負荷のコンピューティング クラウド コンピューティング サービスを提供するために、あまり多くのコンピューティング能力を拡張することはできません。クラウド エッジは、クラウド コンピューティング センターの強力なコンピューティング パワー リザーブ特性を備えており、ユーザー端末の近くに展開されます。これは、ユーザー端末の計算能力を拡張するための推奨ソリューションとなるはずです。

パート02エッジコンピューティング統合スケジューリングの主な技術ルート

単一のクラウド センター ノードに基づいて複数のエッジ クラウド ノードを追加すると (下の図 2 を参照)、アプリケーション サービスの運用と保守管理の複雑さが飛躍的に増加し、複数のエッジ ノード間の負荷分散と要求転送も複雑になります。上記の問題を解決するために、Kubernetes、Openstack、Microsoft、Huaweiなどの国内外のオープンソースコミュニティやソフトウェアベンダーが独自のエッジクラウドアーキテクチャソリューションを立ち上げています。

図2

主要ベンダーが提案するクラウド エッジ ソリューションを包括的に比較した結果、次の 2 つの異なる技術的ルートをまとめることができます。

クラウドネイティブ ソリューション: Kubernetes や K3s などの広く使用されているクラウドネイティブ コンテナ管理アーキテクチャに基づいて、パブリック ネットワークを介したコンテナ化されたアプリケーションの配信、統合監視、負荷分散、インターフェイス転送などの機能を拡張し、エッジ クラウド アーキテクチャに適合させます。代表的なソリューションとしてはKubeEdge ^[1]やKubernetes Federation ^[2]などがあげられる。

クラウド コンピューティング IAAS に基づくソリューション: Openstack などのクラウド コンピューティング管理プラットフォームに依存し、エッジ クラウド リソース管理、アプリケーションのパッケージ化と配布、負荷分散などの機能をクラウド コンピューティング インフラストラクチャ レベルで拡張します。その機能範囲は、物理ハードウェア管理、仮想化、コンテナ化のプロセス全体をカバーします。代表的なツールとしてはStarlingX ^[3]やEdgeGallery ^[4]などがあげられる。

パート 03 Nacos サービス検出

3.1 キューブエッジ

KubeEdge は Kubernetes をベースとしており、コンテナ化されたアプリケーションのオーケストレーション機能をエッジ ホストまたはエッジ デバイスに拡張し、クラウドとエッジ上でネットワーク通信、アプリケーションの展開、メタデータの同期などの機能を提供します。これは最初に Huawei によってオープンソース化され、Kubernetes コミュニティに寄贈されました。

KubeEdge の利点は次のとおりです。

• 便利な展開:開発者は HTTP または MQTT プロトコル アプリケーションを開発し、クラウドとエッジで実行できます。
• Kubernetes ネイティブ サポート:エッジ デバイスとエッジ ノードは Kubernetes を通じて管理および監視でき、元のさまざまなアプリケーション オーケストレーションは KubeEdge にシームレスに移植できます。

クラウドエッジ統合スケジューリングのオープンソース ソリューションである KubeEdge は、コア モジュールをクラウド側とエッジ側の 2 つのカテゴリに分割し、それぞれ中央クラウド ノードとエッジ クラウド ノードに展開します。そのコアモジュールを表 1 に示します。

表1

上記の表から、KubeEdge に多くの新しいモジュールが追加され、これらのモジュールはコマンドラインを介してクラスターのホストマシン上で多くのコマンドラインを実行してインストールする必要があることが簡単にわかります。インストールと構成の複雑さは、純粋なクラウドネイティブ アプリケーションよりもはるかに高くなります。

3.2 Kubernetesフェデレーション

Kubernetes Federation は、K8s Federation とも呼ばれます。バージョン 1.3 以降、Kubernetes には「クラスター フェデレーション」機能が追加されました。この機能により、企業は複数の地域やドメイン、さらには異なるクラウド プラットフォーム上でも、クラスターを迅速かつ効率的かつコスト効率よく実行できるようになります。また、地理的な場所に基づいてレプリケーション メカニズムを作成し、複数の Kubernetes クラスターを複製することで、地域の接続が中断されたり、データ センターに障害が発生したりした場合でも、最も重要なサービスを実行し続けることができます。

このプログラムの主な利点は次のとおりです。

• ネイティブ Kubernetes に基づいて、拡張された各基本モジュールはクラスターの元の API を再利用し、コミュニティからより優れた技術サポートを受けることができます。
• インフラストラクチャから完全に独立しており、関連する拡張ツールのインストールはコンテナ化によって実現されます。
• 前述の KubeEdge と比較すると、Kubernetes Federation は、表 2 に示すように、主に Type Configuration、Schedule、MutiClusterDNS の 3 つのコンポーネントを拡張します。

表2

パブリック ネットワークを介した Kubernetes Federation のマルチレベル グループ フェデレーション スケジューリング メカニズムは、実際には、MultiClusterDNS マルチレベル グループ サービス検出に基づく分散 Kubernetes クラスター スケジューリング システムです (下の図 3 を参照)。

図3

3.3 スターリングX

StarlingX は、より正確には、パッケージ化、コンパイル、インストール、構成、Openstack、WindRiver の MTCE プラットフォーム、WindRiver がテレコム クラウド向けに開発した VIM などを含むソフトウェア スタックです。StarlinX のデプロイメント アプリケーションでは、物理マシンの仮想化から始めて関連ツールを 1 つずつインストールする必要があるため、エッジ ノード リソースのスケジューリング機能が非常に強力です。ただし、基盤となるハードウェアと仮想化ソフトウェアとの結合が比較的検証されているため、業界では主に Jiuzhou や Wind River などのクラウド サービス プロバイダーによって使用されています。一般的なアプリケーション システム開発者がこのソフトウェア スタックを適用するための開発および変換コストは非常に高くなります。

3.4 エッジギャラリー

また、仮想化からコンテナ化までの完全なソフトウェア スタックを提供し、エッジ コンピューティングの統合スケジューリングをサポートし、APP 開発、テスト、認証、オンライン起動の技術プロセスを接続します。 StartlingX とは異なり、このオープン ソース プロジェクトのさまざまなモジュールは分割して、必要に応じて展開できます。このオープンソース プロジェクトは比較的遅れて登場し、リリースされたバージョンもわずかであるため、現時点ではメーカーがこれを適用している例はありません。

現在の主要なエッジ コンピューティング ソリューションのいくつかを包括的に比較すると、一般的なアプリケーション サービス プロバイダーにとって、クラウド ネイティブ ルートに基づく KubeEdge と Kubernetes Federation は、クラウド コンピューティングに基づく StartlingX と EdgeGallery よりも使いやすく、実装コストも低いことがわかります。 Kubernetes を通じてすでにコンテナを導入しているベンダーの場合、Kubernetes Federation プラットフォームを選択すると、切り替えコストが最も低くなります (下の表 3 を参照)。

写真

パート04 Kubernetesフェデレーションの使用

4.1 環境の初期化

1) kubefedctlコマンドラインをダウンロードしてダウンロードします

https://github.com/kubernetes-sigs/kubefed/releases/tag/v0.3.1

2) kubefed-0.3.1.tgz と kubefedctl-0.3.1-linux-amd64.tgz の 2 つのファイルをホスト グループのマスター ノードにアップロードし、次のコマンドを実行します。

 tar -xvf kubefedctl-0.3.1-linux-amd64.tgz mv kubefedctl /usr/local/bin/ tar -xvf kubefed-0.3.1.tgz kubectl create namespace kube-federation-system helm install --name kubefed --namespace kube federation-system kubefed

3) すべてのkubefed poが正常に起動されていることを確認します。

写真

4.2 フェデレーションへのエッジノードのクラスタの追加

1) 各エッジクラスタの構成情報を表示する

cat $HOME/.kube/config

2) 各クラスターの情報を中央クラスターの$HOME/.kube/config設定ファイルに追加します。

 vi $HOME/.kube/config

3) kubefedctlコマンドラインツールを使用してグループをフェデレーションに追加します。

 kubefedctl join clusterName --cluster-context clusterName --host-cluster-context local --v=2 kubectl -n kube-federation-system get kubefedclusters

フェデレーションから脱退したい場合は、次のコマンドを実行します。

 kubefedctl unjoin zj --host-cluster-cnotallow=host

4.3 フェデレーション名前空間とyaml構成ファイルを構成する

1) フェデレーション名前空間を作成する

kubectl create namespace vrfederation vi vrfederation.yaml

次のコンテンツを追加します。

 apiVersion: types.kubefed.io/v1beta1 kind: FederatedNamespace metadata: name: vrfederation namespace: vrfederation spec: placement: clusters: - name: local - name: cddev

App Store 経由でデプロイする場合は、ログインしたアカウントが属するプロジェクトの名前空間のみが表示されるため、各クラスターで projectid も指定する必要があります。

 overrides: - clusterName: cddev clusterOverrides: - path: "/metadata/labels" op: "add" value: field.cattle.io/projectId: p-64g94 - path: "/metadata/annotations" op: "add" value: field.cattle.io/projectId: local:p-64g94 - clusterName: local clusterOverrides: - path: "/metadata/labels" op: "add" value: field.cattle.io/projectId: p-6rt82 - path: "/metadata/annotations" op: "add" value: field.cattle.io/projectId: local:p-6rt82

2) フェデレーション展開を作成する

vi test.yaml

次のコンテンツを追加します。

 apiVersion: types.kubefed.io/v1beta1 kind: FederatedDeployment metadata: name: test-deployment namespace: vrfederation spec: template: metadata: labels: app: nginx-test spec: replicas: 1 selector: matchLabels: app: nginx-test template: metadata: labels: app: nginx-test spec: containers: - image: nginx:1.17 name: nginx-test placement: clusters: - name: local - name: cddev overrides: - clusterName: cddev clusterOverrides: - path: "/spec/replicas" value: 3 - path: "/spec/template/spec/containers/0/image" value: "nginx:1.14.0-alpine" - path: "/metadata/annotations" op: "add" value: foo: bar - path: "/metadata/annotations/foo" op: "remove"

3) 各クラスタのコンテナの展開状況を確認する

ubectl --context cddev -n vrfederation get deployments

4.4 クラスタ間サービスとイングレス構成

1) フェデレーションサービスを作成する

apiVersion: types.kubefed.io/v1beta1 kind: FederatedService metadata: labels: app: federated-svc name: federated-svc namespace: vrfederation spec: template: spec: type: LoadBalancer ports: - name: http port: 80 selector: app: nginx placement: clusters: - name: cddev - name: local kubectl --context cddev -n vrfederation get svc

2) フェデレーションイングレスを作成する

apiVersion: types.kubefed.io/v1beta1 kind: FederatedIngress metadata: name: test-ingress namespace: vrfederation spec: template: spec: backend: serviceName: federated-svc servicePort: 80 placement: cluster: - name: local - name: cddev --- apiVersion: multiclusterdns.kubefed.io/v1alpha1 kind: IngressDNSRecord metadata: name: test-ingress namespace: vrfederation spec: hosts: - www.vr.wellmaxwang.top recordTTL: 600

上記の構成を完了すると、イントラネット環境で検証可能な Kubernetes フェデレーション クラスターを構成できます。パブリック ネットワーク全体のフェデレーションの場合、パブリック ネットワーク間のサービス検出を実行するために、パブリック ネットワーク DNS と外部 DNS サービスをさらに構成する必要があります。

パート05要約

私が取り組んでいる分散ライブ ブロードキャスト プロジェクトの実践経験から判断すると、Kubernetes コミュニティが推進するクラウドネイティブ エッジ コンピューティング統合スケジューリング ソリューションである Kubernetes Federation は、一般的なアプリケーション サービス ベンダーが単一センター アプリケーションをクラウド エッジ コラボレーション アプリケーションに変換するための効率的で低コストのソリューションです。しかし、クラウド サービス プロバイダーにとって、StarlingX はさまざまなノード間でクラウド コンピューティング能力をより適切に割り当てることができる可能性があるため、統合エッジ コンピューティング スケジューリング ソリューションの具体的な選択は、各自のプロジェクトの実際の状況に基づいて決定する必要があります。