KubeEdge の概要
KubeEdge は、エッジ コンピューティング シナリオを指向し、エッジとクラウドのコラボレーションに特化して設計された業界初のクラウド ネイティブ エッジ コンピューティング フレームワークであり、ネイティブ コンテナ オーケストレーションとエッジ クラウド間のアプリケーション コラボレーション、リソース コラボレーション、およびデータ コラボレーションを実現します。 Kubernetes のスケジューリング機能: デバイスとのコラボレーションなどの機能により、エッジ コンピューティングにおけるクラウド、エッジ、デバイスのコラボレーションのシナリオが完全に開かれます。
KubeEdge アーキテクチャは、主にクラウドとエッジの 3 つの部分で構成されます。クラウドは、ネイティブ Kubernetes 管理コンポーネントと、クラウド リソースの変更を監視し、信頼性が高く効率的なクラウドを提供する KubeEdge の自社開発 CloudCore コンポーネントを含む統合コントロール プレーンです。エッジメッセージの同期。サイドは主に Edged、MetaManager、EdgeHub などのモジュールを含む EdgeCore コンポーネントであり、クラウドからメッセージを受信してコンテナーのライフサイクル管理を担当します。エンド側は主にデバイス マッパーとイベントバスであり、エンドサイド デバイスへのアクセスを担当します。
クベエッジアーチ
KubeEdge は、Kubernetes コントロール プレーンをベースとして使用し、ノードを分離することで、エッジ クラウド間のアプリケーション コラボレーション、リソース コラボレーション、データ コラボレーション、およびデバイス コラボレーションの機能を拡張します。現在、Kubernetes コミュニティによって正式にサポートされている規模は 5,000 ノードと 150,000 ポッドですが、Internet of Everything 時代の到来により、エッジ コンピューティングのシナリオでは、この規模は十分とは言えません。大規模なエッジ デバイスへのアクセスに伴い、エッジ コンピューティング プラットフォームのスケーラビリティと一元管理の需要が高まり、できるだけ少ないクラウド リソースとクラスターを使用して、できるだけ多くのエッジ デバイスを管理し、インフラストラクチャの管理と運用を簡素化する方法が求められます。メンテナンス。KubeEdge は、Kubernetes のネイティブ機能との完全な互換性に基づいて、クラウド エッジ メッセージ チャネルと送信メカニズムを最適化し、ネイティブ Kubernetes の管理規模を突破し、大規模なエッジ ノードのアクセスと管理をサポートします。
SLI/
スケーラビリティとパフォーマンスは Kubernetes クラスタの重要な機能であり、K8s クラスタのユーザーとして、上記 2 つの側面におけるサービス品質の保証を期待しています。Kubernetes + KubeEdge の大規模なパフォーマンス テストを実施する前に、大規模なクラスター シナリオでサービス指標を測定する方法を定義する必要があります。Kubernetes コミュニティでは、次の SLI (サービス レベル インジケーター)/SLO (サービス レベル目標) 指標が定義されており、これらの指標を使用してクラスターのサービス品質を測定します。
API 呼び出しレイテンシ
ステータス SLI SLO
公式単一オブジェクト変更 API 集約 API と CRD を除く過去 5 分間の P99 レイテンシ、P99 <= 1s 集約 API と CRD を除く過去 5 分間の公式
非ストリーミング読み取り専用 P99 API レイテンシ Scope= resource、P99 <= 1s Scope=namespace、P99 <= 5s Scope=cluster、P99 <= 30s
Pod Startup Latency
Status SLI SLO
公式ステートレス Pod 起動時間 (イメージのプルと Init Container を除く)、pod createTimestamp からすべての P99 時間まですべてのコンテナはウォッチ P99 によって開始および観察されたことが報告されます <= 5 秒
WIP ステートフル ポッドの起動時間 (イメージのプルと初期化コンテナを除く)、pod createTimestamp からすべてのコンテナが開始および観察されたことがウォッチ P99 によって報告された時点まで (時間未定)
コミュニティはまた、クラスター内ネットワーク プログラミング レイテンシー (Ready Pod でのサービスの更新または変更が最終的に Iptables/IPVS ルールに反映されるまでの遅延)、クラスター内ネットワーク レイテンシー、および DNS プログラミング レイテンシー (サービスが更新または変更されるとき) も定義します。 Ready Pod は DNS サーバー遅延、DNS 遅延、その他の指標に反映されますが、これらの指標はまだ定量化されていません。大規模なクラスター テストの目標はすべての SLO を満たすことであるため、このレポートでは主に公式ステータスの SLI/SLO をテストします。
Kubernetes のスケーラビリティの次元としきい値
Kubernetes のスケーラビリティの特性は、ノード サイズ、つまり Scalability != #nodes だけを指すわけではありません。実際、Kubernetes のスケーラビリティには、名前空間の数、ポッドの数、サービスの数、シークレット/configmap の数など。次の図は、クラスターのスケーラビリティを説明するために Kubernetes コミュニティによって定義された重要な要素です (現在も継続的に更新されています)。
k8s-スケーラビリティ
Kubernetes クラスターがリソース オブジェクトを無制限に拡張し、すべての SLI/SLO 指標を満たすことは明らかに不可能であるため、業界では Kubernetes リソースの上限を多面的に定義しています。
- ポッド/ノード 30
- バックエンド <= 50k & サービス <= 10k & バックエンド/サービス <= 250
- ポッド チャーン 20/秒
- シークレットと構成マップ/ノード 30
- 名前空間 <= 10k、ポッド <= 150k、ポッド/名前空間 <= 3k
- …
各次元は完全に独立しているわけではなく、1 つの次元が伸びると他の次元は圧縮されるため、使用シナリオに応じて調整できます。たとえば、5,000 ノードが 10,000 ノードに拡張された場合、他の次元の仕様は必然的に影響を受けます。すべてのシナリオをテストして分析すると作業負荷が非常に膨大になるため、このテストでは、テストと分析に使用する典型的なシナリオ構成を選択することに重点を置きます。SLI/SLO を満たすことに基づいて、単一クラスターは 100k エッジ ノードと 1000k ポッド スケール管理をサポートできます。
テスト ツール
ClusterLoader2
ClusterLoader2 は、オープン ソースの Kubernetes クラスター負荷テスト ツールであり、Kubernetes によって定義された SLI/SLO 指標をテストし、クラスターがさまざまなサービス品質基準を満たしているかどうかを検証できます。さらに、Clusterloader2 は、クラスターの問題の場所とクラスターのパフォーマンスの最適化のための視覚的なデータを提供します。ClusterLoader2 は最終的に、一連のパフォーマンス インデックス テスト結果を示す Kubernetes クラスター パフォーマンス レポートを出力します。
Clusterloader2 のパフォーマンス指標:
APIResponsivenessPrometheusSimple
APIResponsivenessPrometheus
CPUProfile
EtcdMetrics
MemoryProfile
MetricsForE2E
PodStartupLatency
ResourceUsage Summary
SchedulingMetrics
SchedulingThroughput
WaitForControlledPodsRunning
WaitForRunningPods
Edgemark Edgemark
は Kubemark に似たパフォーマンス テスト ツールで、主に KubeEdge クラスターのスケーラビリティ テストで Ku をシミュレートするために使用されます。 beEdge エッジ ノード。限られたリソースで超大規模なノードを構築するという目標Kubernetes+KubeEdge クラスターは、大規模クラスターでのみ発生するクラスター管理の問題を明らかにします。Edgemark の導入方法は次のとおりです。
エッジマークのデプロイ
k8s マスター - Kubernetes 物理クラスター マスター ノード
エッジマーク マスター - Kubernetes シミュレートされたクラスター マスター ノード
CloudCore - KubeEdge クラウド管理コンポーネント、エッジ ノード アクセスを担当します
中空ポッド - 物理クラスター上で開始されたポッド、ポッド内でエッジマークを開始することによってエッジマーク マスターに登録されます。仮想エッジ ノード、およびエッジマーク マスターは仮想エッジ ノードにポッドをスケジュールできます。
中空エッジノード - 仮想ノードであり、中空ポッドによって登録されているクラスター内の可視ノードをシミュレートします。
テスト クラスター デプロイメント プラン
デプロイ
Kubernetes の基本管理プレーンは 1 つのマスターでデプロイされます。ETCD、Kube-apiserver、Kube-Scheduler、および Kube-Controller はすべて 1 つのインスタンスでデプロイされます。KubeEdge 管理プレーン CloudCore は 5 つのインスタンスでデプロイされます。Kube-apiserver は接続されていますマスター ノード IP とサウスバウンド パスを介してロード バランサーはサービスを外部に公開し、エッジ ノードはロード バランサー ポーリング ポリシーを通じて CloudCore インスタンスにランダムに接続します。