本記事は「TUNA-JP Advent Calendar 2022」の15日目のエントリとして、VMwareのエッジソリューション(Edge Compute Stack)でマルチK8s管理のTanzu Mission Controlが使われている件について紹介します。
筆者がエッジコンピューティングに興味があるので、Tanzuよりもエッジソリューションについての記述が多めですがご了承下さい。
ちなみに一部情報はVMware Explore2022 JPを参照しておりますが、オンデマンド配信/資料ダウンロードが2022年12月23日(金)17:00までなので、興味を持った方は期限前に資料ダウンロードすることをおすすめします。
本記事のサマリ
- VMware Edge Compute Stackはエッジに配置したコンピュートリソース上でTanzu Kubernetes Grid(TKG)というKubernetes(k8s)クラスタを構築してコンテナアプリケーションをデプロイできるようにするトータルソリューション。
- VMwareのインフラ製品で基盤を作って、k8sおよびコンテナアプリのデプロイ部分はTanzu製品が担当するという組み合わせ。
- Edge Compute Stack上で動作するKubernetesクラスタは、マルチk8sクラスタ管理のSaaSであるTanzu Mission Controlが管理する。
- VMwareのR&D部門のOffice of the CTO(OCTO)ではエッジコンピューティングのプロジェクトであるProject Santa CruzとProject Keswickに取り組んでいる。
- Project Santa Cruz(SD-WANのEdgeデバイスをTanzu Kubernetes GridのNodeとして動作させるプロジェクト)
- Project Keswick(Edgeには軽量のKubernetesを使い、GitOpsでインフラとワークロードを宣言的に管理するプロジェクト)
VMwareの定義するエッジコンピューティングについて
エッジコンピューティングは大きく「拠点にコンピュートリソースを置くもの」と、「通信キャリアの局舎にコンピュートリソースを置くもの(MEC)」に分かれますが、VMwareは前者をFar Edge、後者をNear Edgeと読んでいます。
今回紹介するEdge Compute StackはFar Edgeをメインターゲットにしたものです。
余談その1:フォグコンピューティングという用語もありましたが流行りませんでしたね。Edge ⇔ Fog ⇔ Cloudという位置づけです。
IT Leaders:“雲”より近くの「フォグコンピューティング」(2018年4月10日)
VMware Edge Compute Stackとは
エッジコンピューティングの領域をターゲットに、Kubernetesを構築してコンテナアプリケーションをデプロイできるようにするトータルソリューションという理解です。vCenter、vSphere/ESXi、vSAN、Tanzu Kubernetes Grid(TKG)、Tanzu Mission Control(TMC)が必須で、オプションでVMware SD-WAN、vROpsなどが組み合わせられます。
- Tanzu Kubernetes Grid(TKG)はVMware提供のKubernetesディストリビューションです。
- Tanzu Mission Control(TMC)は複数のKubernetesクラスタを管理するSaaS製品で、昨日のTUNA-JPのアドベントカレンダーにて紹介しておりますので初見の方はぜひ。
VMware Edge Compute StackはVMwareのインフラ製品で基盤を作って、k8sおよびコンテナアプリのデプロイ部分はTanzuが担当するという陣形ですね。ハードウェアは後述しますが、現在はDELLやLenovoのエッジ用サーバで動作実績があるようです。
余談その2:VMwareのFlings(実験的なプロジェクト)ではESXi Armエディションも公開されており、上記画像の一番右は主にESXi Armエディションが動くことになりそうです。
余談その3:ESXi ArmエディションはSmartNICのProject Montereyでも使われています。
本項目の情報ソースは下記になります。
- VMware Explore2022 JP:あなたの知らない VMware Edge Compute Stack の世界
- VMware Explore2022 JP:誰でもわかる 通信業界の Cloud Native プラットフォーム
- VMware SASE and Edge:VMware Edge Compute Stack: What’s New in 2022?
- VMware Explore2022US:VMware Edge Compute Stack Reference Architecture Deep Dive
Enterprise Edgeのハードウェア
Edge Compute Stackの図の一番左に記載されていたEnterprise Edgeについて、ハードウェア要件のまとまった情報は見つけられなかったのですが、ざっと調べたところDELLとLenovoのサーバで動作するようです。Far Edgeはデータセンタと違って温度条件などの環境が劣悪なこともあるので、耐久性の高いRugged認定のもので動かしているようです。
- DELL PowerEdge XR11(おそらくXR12でも動作)
- DELL PowerEdge XR4000
- Lenovo ThinkSystem SE 350
次はEdge Compute Stackのアーキテクチャを記載します。
VMware Edge Compute Stackのアーキテクチャ
VMware Explore2022USのReference Architecture Deep Diveのセッションよりアーキテクチャの図を持ってきました。
右下に注目するとTanzu Mission Control(TMC)が書かれています。左下の各Edge SiteのサーバではVMwareのk8sディストリビューションであるTanzu Kubernetes GridのWorkloadクラスタが動いており、これらのk8sクラスタの管理をTMCが担当するようです。
TMCは各k8sクラスタでどのようなPodが動いているのか可視化できたり、CPUなどのリソースの使用状況の把握やOpen Policy Agent(OPA)を使用したポリシー適用ができるので、多数のエッジ拠点に分散しているk8sクラスタを一元的に管理する役割を担うと思われます。
次はk8sクラスタにどうやってコンテナアプリケーションをデプロイするかという紹介になります。
VMware Edge Compute Stackにアプリケーションをデプロイする
こちらもVMware Explore2022USのReference Architecture Deep Diveのセッションより図を2つ持ってきました。
Edge Compute StackではVMwareのコンテナアプリケーションデプロイのプラットフォームであるTanzu Application Platform(TAP)を組み合わせることが出来るようです。
TAPについては @hirosat さんの記事をご参照ください。
TUNA-JP Advent Calendar 2022 2日目:VMware Tanzu Application Platform のOSSを一挙ご紹介!
TUNA-JP Advent Calendar 2022 3日目:逆引き!TAPではこんなことができるよ
下記の通り具体的なアプリケーションのデプロイの図もありましたが、GitOpsツールのFluxとコンテナレジストリのHarborを組み合わせてCI/CDの仕組みを作っていました。
エッジのサーバはえてしてリソースが潤沢ではないので、コンテナイメージをいかに軽量に作るかもポイントになりそうです。
以上がVMware Edge Compute StackについてVMware Explore2022USのReference Architecture Deep Diveで触れられていた内容です。
Office of the CTOで取り組まれているエッジコンピューティングに関するプロジェクト
次はVMwareのR&D部門のOffice of the CTO(OCTO)のブログでも言及されている、エッジコンピューティングのプロジェクトであるProject Santa CruzとProject Keswickについて紹介します。これらについては過去のVMwareの年次カンファレンス(VMworld2021およびVMware Explore2022)でもいくつかのセッションが見つかりました。
※ちなみにまだVMware内の実験的なプロジェクトのため、今回紹介するかたちでGAになるかは分かりませんのでご注意ください。
情報ソースは下記になります。
- Project Santa Cruz(おそらくEdge Compute Stackの図の真ん中にあったNetwork Edgeのモデルに該当するプロジェクト)
- Project Keswick(Edgeには軽量のKubernetesを使い、GitOpsでインフラとワークロードを宣言的に管理するプロジェクト)
Project Santa Cruz
これは情報ソースを見た限り、VMware SD-WAN(旧VeloCloud)のEdgeデバイスをTanzu Kubernetes GridのWorkload Nodeとして動作させるというものです。これにより、エッジでコンテナアプリを動かす候補にEdgeデバイスを含めることが出来ます。ブログではカメラを使った画像解析の事例が出ていました。
※VMware SD-WANはNW機器ですが、ハードウェアはx86アーキテクチャで動いておりOSはおそらくLinuxベースです。
Office of the CTO Blog:Announcing Project Santa Cruz (and more)!の冒頭部分を翻訳したものを貼ります。
VMworld2021のセッション内ではSD-WANのEdgeデバイスにSSHでログインして、Tanzu Mission Control(TMC)のエージェントをインストールしています。
※VMware SD-WANは旧称がVeloCloudで、CLIに名称が出ています。
セッション内ではTMCで管理しているClusterを確認しており、SD-WANのEdgeデバイス(vc-edge)がk8sクラスタのNodeとして認識されています。
まだVMwareの実験的なプロジェクトの段階ですが、将来的にはVMware SD-WANのEdgeデバイスをk8sクラスタの1Nodeとして動作させて、その上にコンテナアプリケーションを動作させることも出来るかもしれません。ネットワークの機能についてはVirtual Network Function(VNF)からCloud-Native Network Function(CNF)で実装する動向もあるので、コンテナアプリとして動作するかもしれません。
次はProject Keswickについての紹介です。
Project Keswick
こちらはVMware Explore2022 JPでVMwareの進藤さんから紹介されていました。
Office of the CTO Blog:Let’s Go Over the Edge: What’s Next for VMware Edge Computeでは下記の記述があり、インフラとワークロードともにFluxによるGitOpsを用いて宣言的な設定をするようです。
YAMLファイルがソース管理 (git) にコミットされると、Project Keswick は、git リポジトリに接続された各 ESXi デバイスでこの構成の更新を利用できるようにします。エンドポイントを更新する準備ができると、変更をプルダウンして更新します。
このアーキテクチャ図は、Project Keswick のレイヤーの概要を示しています。git リポジトリに格納された YAML ファイルである Kubernetes マニフェストは、インフラストラクチャとワークロードのレイヤーを定義するために使用されます。マニフェストが変更されると、Project Keswick は git リポジトリのリスナーを使用してこれらの変更を検出し、ノードの更新準備が整ったときに更新された命令を実行します。
Project Keswick は、断続的な接続のユース ケースを念頭に置いて開発されました。ノードは常に準備ができていたり、更新するのに適したスペースにあるとは限りませんが、準備ができたら、最新バージョンをプルダウンして自分自身を更新できます。
Tanzu Mission Controlでも、Fluxを用いたGitOpsによりk8sクラスタ自体を宣言的にデプロイできるようにするアップデートをしており、宣言的にインフラを構築していく流れになっています。
VMware Tanzu:Drive Tanzu Mission Control Cluster Configuration and Add-ons with Flux CD
まとめ
筆者がエッジコンピューティングに興味があることもあり、思っていたよりも長くなってしまいました。
Edge Compute Stackは現在はサーバのEnterprise Edgeのパターンで動作するようですが、将来的にはSD-WAN EdgeやARMプロセッサのデバイスでも動作させることを目指して開発されています。
k8sを抽象化のレイヤーとして使うことでアプリケーションの可搬性も確保されており、Tanzu製品との組み合わせもあるので今後も注目していきたいと思います。
エッジコンピューティングまわりの面白い記事
エッジデバイス × Kubernetesのネタは@ydo さんも書かれており、どのようなユースケースがあるのか、最新の技術動向が詳細に述べられています。
また、さくらインターネット研究所のゆううきさんがエッジコンピューティングについていくつか記事を書かれています。後者の記事ではウェブサーバ、アプリケーションサーバ、データベースサーバの3-tier構造をどのように配置するのかが書かれており非常に面白い内容です。