さまざまなエッジ クラスタ管理ソリューションの比較と選択

[[429682]]

この記事は、Double_Dong&Huazi が執筆した WeChat パブリック アカウント「運用と保守の開発ストーリー」から転載したものです。この記事を転載する場合は、Operation and Maintenance Development Story のパブリック アカウントにお問い合わせください。

1. 背景

エッジ コンピューティング プラットフォームは、データ ソースに近いエッジのコンピューティング ユニットを中央クラウドに統合し、集中管理を実現し、その上にクラウド サービスを展開し、端末の要求にタイムリーに応答することを目的としています。しかし、銀行支店、車載ノード、ガソリンスタンドなど、数千のエッジノードが全国に散在しています。一部のエッジデバイス管理シナリオに基づくと、サーバーはさまざまな都市に散在しており、均一に管理することはできません。クラスターの展開と統合管理を最適化するために、エッジ コンピューティング シナリオ ソリューションを検討します。

2. エッジコンピューティングの課題

Kubernetes システムのエッジ コンピューティング フレームワークでは、次の問題を解決する必要があります。

• ネットワークが切断されたり、ノードが異常になったり、再起動したりすると、メモリ データが失われ、ビジネス コンテナを復元できなくなります。
• ネットワークが長時間切断され、クラウド コントローラーがビジネス コンテナーを排出します。
• 長期間の切断後にネットワークが復旧すると、エッジ データとクラウド データの一貫性が保証されます。
• ネットワークが不安定な場合、K8S クライアントの ListWatch メカニズムは、データの一貫性を確保するために、接続が再接続されるたびに ReList を 1 回同期する必要があります。多数のエッジ ノードと不安定なネットワークは、特に信頼性の低い長距離のパブリック ネットワーク間のシナリオでは、API サーバーに大きなネットワーク オーバーヘッドと CPU 負荷を引き起こします。

3. ソリューションの選択

• キューブエッジ
• スーパーエッジ
• オペニュート
• k3s

3.1.キューブエッジ

3.1.1 アーキテクチャの概要

KubeEdge は、クラウド エッジ コラボレーション機能を提供する Kubernetes 拡張機能に基づく初のオープン インテリジェント エッジ プラットフォームです。これは、インテリジェント エッジ分野における CNCF の最初の公式プロジェクトでもあります。 KubeEdge が解決することを目指す主な問題は次のとおりです。

• クラウドエッジコラボレーション
• リソースの異質性
• 大規模
• 軽量
• 一貫したデバイス管理とアクセスエクスペリエンス

KubeEdge のアーキテクチャは次のとおりです。

KubeEdge アーキテクチャは、クラウド レイヤー、エッジ レイヤー、デバイス レイヤーの 3 つのレイヤーに明確に分かれています。

雲

KubeEdge クラウド プロセスは、次の 2 つのコンポーネントで構成されます。

• Cloudhub はクラウドに展開され、edgehub によってクラウドに同期された情報を受信します。
• エッジ コントローラーはクラウドにデプロイされ、Kubernetes API サーバーとエッジ ノード、アプリケーション、構成間の状態同期を制御します。

Kubernetes マスターはクラウドで実行されます。ユーザーは、kubectl コマンドラインを通じてクラウド内のエッジノード、デバイス、アプリケーションを直接管理できます。使用方法は Kubernetes ネイティブとまったく同じなので、適応する必要はありません。

角

KubeEdge のエッジ プロセスは、次の 5 つのコンポーネントで構成されます。

• edged は、Pod、Volume、Node などの Kubernetes リソース オブジェクトのライフサイクル管理を実装する、新しく開発された軽量 Kubelet です。
• メタマネージャーはローカル メタデータの永続性を担当し、エッジ ノードの自律性の鍵となります。
• Edgehub は、信頼性が高く効率的なクラウドエッジ情報同期を提供する多重化メッセージ チャネルです。
• Devicetwin は物理デバイスを抽象化し、クラウド内にデバイス ステータス マップを生成するために使用されます。
• Eventbus は MQTT ブローカーからデバイス データをサブスクライブします。

ネットワーク

KubeEdge エッジ クラウド ネットワーク アクセスは EdgeMes​​h に依存します。

クラウドは標準の Kubernetes クラスターであり、Flannel や Calico などの任意の CNI ネットワーク プラグインを使用できます。 Kubelet や KubeProxy などの Kubernetes ネイティブ コンポーネントをデプロイできます。同時に、KubeEdge クラウド コンポーネント CloudCore がクラウド上にデプロイされ、KubeEdge エッジ コンポーネント EdgeCore がエッジ ノード上で実行され、エッジ ノードのクラウド クラスターへの登録が完了します。

EdgeMes​​h は、各ノード上の EdgeMes​​h-Server と EdgeMes​​h-Agent の 2 つのコンポーネントで構成されます。

EdgeMes​​h-Serverの動作原理:

• EdgeMes​​h-Server はクラウド ノード上で実行され、パブリック IP を持ち、EdgeMes​​h-Agent からの接続要求をリッスンし、EdgeMes​​h-Agent が UDP ホール パンチを完了して P2P 接続を確立するのを支援します。
• EdgeMes​​h エージェント間のホール ドリルが失敗した場合、EdgeMes​​h エージェント間のトラフィックを中継して、100% のトラフィック転送成功率を保証します。

EdgeMes​​h-Agentの動作原理:

• EdgeMes​​h-Agent の DNS モジュールは、サービス ドメイン名を ClusterIP に変換する組み込みの軽量 DNS サーバーです。
• EdgeMes​​h-Agent のプロキシ モジュールは、クラスター サービスの検出と ClusterIP トラフィックのハイジャックを担当します。
• EdgeMes​​h エージェントのトンネル モジュールが起動すると、EdgeMes​​h サーバーとの長い接続が確立されます。 2 つのエッジ ノード上のアプリケーションが通信する必要がある場合、EdgeMes​​h サーバーを介して UDP ホール パンチングを実行し、P2P 接続を確立しようとします。接続が正常に確立されると、2 つのエッジ ノード上の後続のトラフィックは EdgeMes​​h サーバー経由で転送する必要がなくなり、ネットワークの遅延が短縮されます。

3.1.2 実践

公式ドキュメント「Keadm を使用したデプロイ | KubeEdge」に従ったデプロイテスト

実用的な結論:

公式ドキュメントのデプロイメントによれば、エッジノードは正常にクラスターに参加でき、サービスは正常にエッジノードにデプロイでき、エッジメッシュはサービスアクセスをテストするためにデプロイされます。エッジは SVC を介してクラウド サービスにアクセスできますが、クラウドは SVC を介してエッジにアクセスできず、エッジ ノード サービスには SVC を介してアクセスできません。

3.2.スーパーエッジ

3.2.1 アーキテクチャの概要

SuperEdge は、Tencent が立ち上げた Kubernetes ネイティブのエッジ コンピューティング管理フレームワークです。 SuperEdge は、openyurt や kubeedge と比較して、Kubernetes のゼロ侵入機能やエッジ自律機能を備えているだけでなく、独自の分散ヘルスチェックやエッジ サービス アクセス制御などの高度な機能もサポートしており、不安定なクラウド エッジ ネットワークがサービスに与える影響を大幅に軽減します。

全体的なアーキテクチャ:

コンポーネントの機能は次のようにまとめられます。

クラウドコンポーネント

エッジ クラスターにデプロイされたネイティブ Kubernetes マスター コンポーネント (cloud-kube-APIServer、cloud-kube-controller、cloud-kube-scheduler) に加えて、クラウド内の主な制御コンポーネントには次のものが含まれます。

• tunnel-cloud: エッジ ノード tunnel-edge とのネットワーク トンネルの維持を担当し、現在は TCP/HTTP/HTTPS プロトコルをサポートしています。
• アプリケーション グリッド コントローラー: サービス アクセス制御 ServiceGroup に対応する Kubernetes コントローラーは、DeploymentGrids および ServiceGrids CRD を管理し、これら 2 つの CR から対応する Kubernetes デプロイメントとサービスを生成する役割を担います。同時に、自己開発を通じてサービス トポロジ認識を実装し、サービスへのクローズド ループ アクセスを可能にします。
• edge-admission: エッジ ノードの分散ヘルス チェックのステータス レポートに基づいてノードが正常かどうかを判断し、cloud-kube-controller が関連する処理アクション (taint) を実行するのを支援します。

エッジコンポーネント

ネイティブ Kubernetes ワーカー ノードにデプロイする必要がある kubelet と kube-proxy に加えて、次のエッジ コンピューティング コンポーネントもエッジに追加されます。

• lite-apiserver: エッジ自律性のコア コンポーネントであり、cloud-kube-apiserver のプロキシ サービスです。エッジ ノード コンポーネントから APIServer への一部のリクエストをキャッシュし、これらのリクエストが発生して cloud-kube-apiserver ネットワークに問題がある場合は、それらをクライアントに直接返します。
• edge-health: エッジ分散ヘルスチェック サービス。特定の監視および検出操作を実行し、ノードが正常かどうかを判断するための投票を行います。
• tunnel-edge: クラウド エッジ クラスター tunnel-cloud とのネットワーク トンネルを確立し、API リクエストを受け入れて、エッジ ノード コンポーネント (kubelet) に転送する役割を担います。
• アプリケーション グリッド ラッパー: アプリケーション グリッド コントローラーと組み合わせて、ServiceGrid 内で閉ループ サービス アクセス (サービス トポロジ認識) を完了します。

3.2.2 実践

公式ドキュメント「superedge/README_CN.md at main · superedge/superedge (github.com)」に従ってデプロイおよびテストします。

実用的な結論:

公式ドキュメントによると、エッジノードは正常にクラスターに参加できますが、サービスをエッジノードにデプロイすることはできません。この問題は提起されましたが、回答はなく、他のテストも実行されませんでした。

3.3.オペニュート

3.3.1.アーキテクチャの概要

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

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

3.3.2 実践

私は公式ドキュメントに基づいてそのアーキテクチャを理解しただけで、展開テストは実施しませんでした。

3.4. K3s

3.4.1 アーキテクチャの概要

K3S は CNCF によって公式に認定された Kubernetes ディストリビューションであり、オープンソース化されたのは KubeEdge より少し後です。 K3S は、リソースが限られた環境で Kubernetes を実行する開発者およびオペレーター向けに設計されています。これは、x86、ARM64、および ARMv7D アーキテクチャのエッジ ノード上で小規模な Kubernetes クラスターを実行するように設計されています。 K3S の全体的なアーキテクチャは次のとおりです。

実際、K3S は特定のバージョンの Kubernetes (例: 1.13) に基づいており、コードを直接変更します。 K3S はサーバーとエージェントに分かれています。サーバーは Kubernetes 管理プレーン コンポーネント + SQLite およびトンネル プロキシであり、エージェントは Kubernetes データ プレーン + トンネル プロキシです。

Kubernetes の実行に必要なリソースを削減するために、K3S はネイティブ Kubernetes コードに次の変更を加えました。

• 古くて不要なコードを削除します。 K3S には、デフォルト以外の機能、アルファ版の機能、または非推奨の Kubernetes 機能は含まれていません。さらに、K3S は、デフォルト以外のすべてのアドミッション コントローラー、ツリー内クラウド プロバイダー、およびストレージ プラグインも削除します。
• パッケージングプロセスを統合します。メモリを節約するために、K3S は、もともと複数のプロセスで実行されていた Kubernetes 管理プレーンとデータ プレーンの複数のプロセスを 1 つに統合します。
• Docker の代わりに containerd を使用して、ランタイム フットプリントを大幅に削減します。
• 管理データストレージとして etcd の代わりに SQLite が導入され、リスト/ウォッチ インターフェイスは SQLite で実装され、Tunnel Proxy と呼ばれます。
• シンプルなインストーラーを追加しました。 K3S のすべてのコンポーネント (サーバーおよびエージェントを含む) はエッジで実行されるため、クラウドとエッジの連携は必要ありません。 K3S を本番環境に導入する場合は、クラスター間のアプリケーション管理、監視、アラーム、ログ、セキュリティ、ポリシーを管理するクラスター管理ソリューションを K3S 上に導入する必要があります。

3.4.2 実践

公式ドキュメント: https://docs.rancher.cn/docs/k3s/installation/install-options/_index

運用保守アーキテクチャ図

ノード情報

k3s サーバー - 192.168.15.252

k3s エージェント - 192.168.15.251

注意: サーバーには、パスワードなしでエージェントにログインする権限が必要です。

全体的なアイデア

K3S を使用して Kubernetes クラスターをデプロイし、クラスターの https 証明書を作成し、Helm を使用して Rancher をデプロイし、Rancher の UI インターフェイスを通じて Kubernetes クラスターを手動でインポートし、Kubernetes クラスターを使用します。

スクリプトを使用してDockerをインストールする

GPG証明書のインストール
curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-キー 追加-
 #ソフトウェアソース情報を書き込む
sudo add -apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"  
 sudo apt-get -yアップデート 
 #Docker-CEをインストールする
sudo apt-get -y をインストール docker-ce

Kubernetes のデプロイメント

Rancher の中国語ドキュメントでは、Kubernetes クラスターを構築するためのより軽量な方法である K3S が推奨されています。インストールプロセスは非常に簡単です。インターネットにアクセスし、対応するコマンドを実行するには、サーバーだけが必要です。

k3s サーバー ホストがコマンドを実行します。実行が完了すると、エージェント ノードのインストール用にマスター ホストの K3S_TOKEN が取得されます (デフォルト パス: /var/lib/rancher/k3s/server/node-token)。

 curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC= "--docker" sh -s - サーバー

k3s エージェント ホストはコマンドを実行し、K3S クラスターに参加します。

 curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC= "--docker" K3S_URL=https://192.168.15.252:6443 K3S_TOKEN=K10bb35019b1669197e06f97b6c14bb3b3c7c7076cd20afe1f550d6793d02b9eed8::server:9599c8b3ffbbd38b7721207183cd6a62 sh -

http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh は国内の高速化アドレスであり、正常に実行できます。

実行が完了したら、サーバー上で K3S クラスターが正常にインストールされているかどうかを確認します。

4. コントラスト

KubeEdge、SuperEdge、OpenYurt を含む上記の 4 つのオープン ソース ソリューションは、次のデプロイメント モデルに従います。

完全に分散化された展開モードです。管理プレーンはクラウドに展開されます。エッジ ノードは Kubernetes エージェントを実行するためにそれほど多くのリソースを必要とせず、クラウドとエッジはメッセージを通じて連携します。 Kubernetes の観点から見ると、エッジ ノード + クラウドは完全な Kubernetes クラスターです。この展開モデルは、「デバイス エッジ」と「インフラストラクチャ エッジ」の両方のシナリオの展開要件を満たすことができます。

まず、次の 3 つのソリューションを比較します。

予備的な結論:

これら 3 つのソリューションを比較すると、KubeEdge と OpenYurt/SuperEdge のアーキテクチャ設計はまったく異なります。それに比べると、OpenYurt/SuperEdge のアーキテクチャ設計はよりエレガントです。 OpenYurt と SuperEdge は類似したアーキテクチャ設計を備えています。 SuperEdge は OpenYurt よりも後にオープンソース化されたため、成熟度がまだ低いです。ただし、業界で実装されている実稼働ソリューションによると、KubeEdge は使用率が高く、成熟度も高いことがわかります。同時に、OpenYurt/SuperEdge は比較的遅れてオープンソース化され、まだ CNCF インキュベーション プロジェクトに参加していません。同時に、実際のテスト結果と組み合わせて、KubeEdge を検討します。

次に、KubeEdge と K3s を比較してみましょう。

K3S の展開モデルは次のとおりです。

K3S はエッジで完全な Kubernetes クラスターを実行します。つまり、K3S は分散型デプロイメント モデルではありません。各エッジには追加の Kubernetes 管理プレーンを展開する必要があります。したがって、この展開モデルは、十分なリソースがある「インフラストラクチャ エッジ」シナリオにのみ適しており、リソースが少ない「デバイス エッジ」シナリオには適していません。同時に、クラスター間のネットワークを接続する必要があります。エッジ Kubernetes クラスターを管理するには、マルチクラスター管理コンポーネントを重ねる必要があります。

関連する比較は次のとおりです。

5. 全体的な結論

KubeEdge の主な特徴は、クラウドとエッジのコラボレーションです。 KubeEdge は、Kubernetes 標準 API を通じて、クラウド内のエッジ ノード、デバイス、ワークロードの追加、削除、変更、クエリを管理します。エッジノードのシステムアップグレードやアプリケーションアップデートをクラウドから直接送信できるため、エッジの運用と保守の効率が向上します。ただし、クラウド エッジの共同アクセスには、サーバー側とエージェント側を含む EdgeMes​​h コンポーネントの使用が必要であり、転送のために DNS アクセス トラフィックがハイジャックされ、ネットワークの複雑さが増します。一方で、実際のテストでは、SVC 経由でエッジ サービスにアクセスできないことが判明しました。 K3s にはクラウドとエッジのコラボレーション機能は含まれていませんが、ガソリンスタンドのビジネス シナリオでは、ビジネスを中央エンドとエッジエンドに分割できます。中央側は複雑な処理を実行し、デコード タスクを送信しますが、エッジ側は生成されたイベントをデコードして分析し、表示する役割のみを担います。また、クラウドとエッジのコラボレーションをさらに別のレベルに引き上げることもできます。 KubeEdge クラウド エッジ共同アクセス ソリューションと比較すると、追加のコンポーネントを展開する必要がないため、ネットワークの複雑さが軽減され、問題のトラブルシューティングが容易になります。

KubeEdge のもう 1 つのハイライトは、エッジ ノードのオフライン自律性です。 KubeEdge は、メッセージ バスとメタデータ ローカル ストレージを通じてノードのオフライン自律性を実現します。ユーザーが期待するコントロール プレーンの構成とリアルタイムのデバイス ステータス更新は、メッセージを通じてローカル ストレージに同期されるため、ノードがオフラインで再起動された場合でも管理メタデータが失われず、ノード デバイスとアプリケーションの管理機能が維持されます。 K3s はエッジノードで完全なクラスターを構成しているため、時間的に中央ネットワークから切断されても、現在の業務の運用に影響はありません。

軽量の観点から見ると、k3s バイナリ ファイルのサイズは 50 MB、edgecore は 80 MB です。リソース消費: k3s はエッジの完全なクラスターであるため、リソース消費は KubeEdge よりも高くなります。ただし、ガソリンスタンドのシナリオでは、エッジ サーバーのメモリ構成がより高くなるため、これは許容範囲です。

運用と保守の観点から見ると、k3s の保守は、追加のコンポーネントを追加することなく、ネイティブ k8s と同様です。唯一の難点は、マルチクラスターの管理です。このためには、Rancher やその他のマルチクラスター管理ソリューションを検討してください。同時に、golive2.0 は、1 つのデプロイメントを複数のクラスターに同時に展開することもサポートします。 KubeEdge が複数のガソリンスタンドに接続する場合、名前空間の分離が必要であり、デプロイメントには汚染と許容度の追加が含まれます。同時に、1 つのデプロイメント パッケージで複数の名前空間のデプロイメントをサポートする必要があります。さらに、クラウドエッジ アクセスの場合、KubeEdge はトラフィックを転送するために EdgeMes​​h コンポーネントを追加します。これにより、ネットワークの複雑さが増し、問題が発生した場合のトラブルシューティングが困難になります。

したがって、総合的な比較に基づいて、k3s を使用することをお勧めします。