Table of Contents
Kubernetesは特にクラウドやオンプレミス環境でますます人気になっています。一方で、エッジデバイスやIoTデバイスをKubernetes上で動かすためのソリューションも出現しています。エッジコンピューティングは低遅延、低コスト、省スペースなどの様々なメリットがあります。エッジユースケースにKubernetesなどのクラウドネイティブ技術を導入することで、数多くのメリットを享受できます。
- 管理性の向上
- 管理や展開、更新の自動化
- クラウドネイティブな開発方式の適用 (GitOps, DevOpsなど)
- 可観測性
- レジリエンス (耐障害性、自己回復性)
- スケーラビリティ
Avintonでは、様々なユースケースに対してエッジAIカメラソリューションを提供しています。省スペース、低消費電力稼働、低遅延などの条件が求められる環境で、カメラからの映像をもとにリアルタイムで推論を行うことができます。
例えば3台のデバイスをエッジにデプロイする際には問題ありませんが、もし100台以上のデバイスを大規模にデプロイしたい場合は何が起こるでしょうか？100台と言わずとも20台のデバイスでさえ、(プロビジョニングや自動化ツールがあったとしても)、デバイスを設定していくことは大変な作業になると思います。また、デプロイ後の管理コストもデバイスの数とともに増えていきます。途中からデバイス数を増やすことも大変な作業です。Kubernetesをエッジワークロードに取り入れることで、たくさんの手動で行っている面倒な作業を削減しスケーラブルにエッジデバイスを管理、運用できます。デバイスの数が増えるほど、Kubernetesによってより多くのコスト削減を行うことができます。
エッジやIoT向けにデザインされたいくつかのオープンソースのKubernetesディストリビューションがあります。今回は、これらのディストリビューションの機能や特徴、パフォーマンス、展開コストなどをテストし比較しました。
- k0s: The Simple, Solid & Certified Kubernetes Distribution
- k3s: The certified Kubernetes distribution built for IoT & Edge computing
- microk8s: Low-ops, minimal production Kubernetes, for devs, cloud, clusters, workstations, Edge and IoT.
- KubeEdge: A Kubernetes Native Edge Computing Framework
テスト環境
テストに使用した機器は以下のとおりです。
- ワーカーノードとしてMini PC 3台
- マスターノードとしてMini PC 1台
- AIカメラアプリケーション用のIPカメラ 3台
- ノード間接続用のネットワークスイッチ
- IPカメラ用のPoEスイッチ
- 管理VM – デバイスのモニタリングやロギングなどを行う外部サーバー (Prometheus, Grafana, ELK stackなど)
Mini PCのスペックは以下です。
- 4 core CPU
- 4GB Memory
- 60GB Storage
- イーサネット用LANポート
- Wifi インターフェース
各ディストリビューションの比較と分析
次の5つの観点から分析と比較を行いました。
- デプロイと管理のコスト
- エッジネットワーク
- カスタマイズ性
- リソース使用量とパフォーマンス
- ドキュメントとコミュニティ
デプロイと管理のコスト
k0sとk3sは、少ないコマンドで、非常に簡単かつ迅速にデプロイできます。
どちらもすべてのパッケージ（kubelet、runc、k8s-apiなど）が含まれている単一のバイナリで実行されます。
クラスターの設定変更や構成、アンインストールの手順も非常に簡単です。
microk8sも単一のsnapパッケージですが、プロセスはsystemdサービスとして個別に実行されます。
コンポーネントごとに構成を適用し、それぞれのsystemdサービスを再起動する必要があります。
アンインストールコマンドには非常に時間がかかり、Githubでも同様の問題が報告されています。
kubeedgeは、まずコントロールプレーンとしてネイティブなKubernetesクラスターが必要です。
kubeadmと似ているkeadmコマンドを使用して、cloudcoreまたはedgecoreをインストールできます。
cloudcoreまたはedgecoreは、それぞれコントロールプレーンまたはエッジノード上でsystemdプロセスとして実行されます。
最新バージョンでは、Kubernetesリソースとしてcloudcoreの実行をサポートしています。 （ここを参照）
管理コストは大きく、インストール手順は他のディストリビューションほど単純ではありません。
エッジネットワーク
ほとんどのディストリビューションで様々なCNIがサポートされています。
Calicoなど一部のCNIではワーカーノードからKubernetes APIにアクセスできる必要があります。
各ノードを異なるネットワークで稼働する場合(例えばLTEなどのダイナミックなIPアドレスを使用する)は、konnectivityが適切な選択肢のようです。
konnectivityはサーバー/クライアント型の構成で、エッジノードがコントロールプレーンノードにアクセスします。
k0sはデフォルトで、ワーカー/コントロールプレーン間の接続にkonnectivityをサポートしています。(こちら)
また、こちらのKubernetes公式ドキュメントでもkonnectivityについて説明しています。konnectivityは任意のKubernetesクラスター上で手動でインストールできます。
kubeedgeは、cloudhubとedgehubという独自のネットワークの仕組みを実装しています。
これもサーバー/クライアント型の仕組みで、ノードをそれぞれ異なるネットワーク間で稼働させることができます。
リソース使用量とパフォーマンス
k0sとk3sのワーカーノードのリソース使用量は、アイドル状態で440MB以下です。
microk8sのワーカーノードのリソース使用量は、アイドル状態で700MB以下です。
kubeedgeのワーカーノードのリソース使用量は、アイドル状態で300MB以下です。
cluster loaderスクリプトを使用して、簡単な負荷テストを行いました。
エッジデバイスでは大規模なアプリケーションのデプロイは行わないため、podを10個程度デプロイするサンプルテストケースを実行しました。
| テストケース | kubeedge | k0s | k3s | microk8s |
|---|---|---|---|---|
| Start measurements | 0.101133 s | 0.10159 s | 0.101366 s | 0.101339 s |
| Cluster API | 0.000221 s | 0.000172 s | 0.000165s | 0.000239 s |
| Cluster performance | 0.000419 s | 0.000317 s | 0.000313 s | 0.000267 s |
| Create deployment | 1.002712 s | 1.003559 s | 1.001963 s | 1.008023 s |
| Wait for pods to be running | 14.079484 s | 5.013258 s | 5.01466 s | |
| Measure pod startup latency | 0.019507 s | 0.018685 s | 0.029368 s | 0.021512 s |
| test overall (including clean up duration) | 35.261 s | 21.188928 s | 21.231549 s | 21.256 s |
結果から、kubeedgeでpodのデプロイに遅延があることが分かりました。
カスタマイズ性
それぞれのディストリビューションでは、ほとんどのメジャーなCRI, CNI, CSIをサポートしています。
CRI
containerdは、4つのディストリビューションすべてのデフォルトとしてサポートされています。
cri-oはmicrok8s以外では公式にサポートされていますが、いくつかの手動の作業が必要です。
GPU用のnvidia-container-runtimeは k0sとkubeegeで利用できます。
microk8sはGPU用のアドオンを提供しています。
k3sでは公式にはGPUをサポートしていないようですが、Web上ではいくつかの例を見つけることができます。
CNI
ほとんどのCNIが利用できます。
k0s は Calico と kube-router をデフォルトでサポートしています。
k3s はFlannel をデフォルトでサポートしています。
microk8s ではHAモードではCalicoで、スタンドアロンモードではFlannel をサポートしています。
kubeedgeはedgemeshをデフォルトで提供しています。
CSI
ほとんどのCSIを利用できます。
k0sはアドオンとしてOpenEBSを提供しています。例えば、ホストパスを使用してPVCを利用できます。
k3sは同じくRancher製のLonghornをサポートしています。
HA
HAモードはすべてのディストリビューションで利用できます。
ドキュメントとコミュニティ
k0sとk3sでは、ドキュメントは適切に構成され、完成しています。
また、Githubのコミュニティはアクティブであり、リリースサイクルも頻繁です。
microk8sのドキュメントも優れています。
kubeedgeのドキュメントを理解するのが少し難しいです。
一部のページは古く、最新の情報を反映していません。
比較表
（2022年4月 現在）
| kubeedge | k3s | k0s | microk8s | |
|---|---|---|---|---|
| デプロイのコスト | 複雑 | 簡単 | 簡単 | 簡単 |
| 設定 | 複雑 | 簡単 | 簡単 | 普通 |
| ドキュメント | やや不十分 | 良い | 良い | 良い |
| ネットワークの分離 | cloudhub – edgehub | – | konnectivity | – |
| アイドル時のリソース使用量 | ~300MB | ~440MB | ~440MB | ~700MB |
| パフォーマンス | Podのスケジュールに遅延がある | 良い | 良い | 良いがクラスターの停止に時間がかかる |
まとめ
Kubernetesは、リソースの少ないエッジデバイスで実行できるようになりました。エッジソリューションの場合、Kubernetesはデバイスが増える場合に備えて、管理と導入のコストを削減するのに役立ちます。
エッジユースケースでは、現時点（2022年4月）で、シンプルさと機能の点でk0sが最適のようです。
展開と管理は簡単で、バイナリは1つだけです。そのため、Kubernetesの経験があまりないアプリケーション開発者でも、自分でクラスターを簡単に操作できます。
k0sを使用すると、デフォルトのkonnectivityを使用して、分離されたネットワーク上のコントロールプレーンからクラスターを管理できます。
操作とドキュメントは複雑ですが、kubeedgeも別のネットワークでのノードの実行をサポートし、エッジのユースケース（デバイスCRD、キューイングシステムなど）に多くの柔軟な機能を提供します。
kubeedgeはネイティブKubernetesの拡張であるため、既存のKubernetesベースのソリューション/アプリケーションと簡単に統合できます。 一方で、専門的なKubernetesのエンジニアが必要であり、k0sなどの他のソリューションよりも多くの作業が必要です。
このテストを通じて、コミュニティがエッジでより多くのワークロードを実行しようとしていることがわかります。
この分野は急速に成長し、今後数年間で新しい興味深いソリューションが出現することが予想されます。
References
- The Future of Edge AI is Cloud-Native by Nvidia
- Small footprint, big impact: running cloud-connected Kubernetes at the edge by GCP
- Kubernetes at the Edge: Organizations are using edge technologies, but there is room to grow by CNCF
あなたも、Avintonでこのような最先端技術を習得し活用してみませんか？
社員の成長を導きながら、AIやビッグデータなどの最先端技術をプロジェクトに活用していくことが私たちのビジョンです。Avintonの充実した技術研修でスキルアップを図り、あなたのキャリア目標を一緒に達成しませんか？
