🧑‍💻

【mNi Cloud】5月~10月の開発状況【国産クラウド】

に公開
クラウド
IaaS
国産クラウド
mni
tech

はじめに

こんにちは。mNi Cloud開発チームです。
2024年7月に開発を開始した国産クラウドプラットフォーム「mNi Cloud」は、開始から1年が経過し、今も開発を続けております。
2025年5月から10月にかけては、主にバックエンドアーキテクチャのリファクタリングを中心に改修を行いました。
本記事では、その内容を中心に最近の進捗をご報告します。

mNi Cloudとは

mNi Cloudの概要については、以下の記事に詳しくまとめています。
https://zenn.dev/mnicloud/articles/7144cc817d7aa4

1月〜4月の開発状況

以前の開発経過は以下の記事をご参照ください。

Operator（バックエンド）の開発状況

mNi Cloudでは、Kubernetes Operatorを活用する設計へ移行しました（詳細は1〜3月の進捗記事を参照）。
以下では、各Operatorの概要と開発進捗を紹介します。

概要図

以下は、現在開発中のmNi Cloudバックエンドアーキテクチャ図です。

API Gateway（新規作成）

概要

今回のリファクタリングに合わせて新たに開発したコンポーネントです。
各種Controllerへの統一的な入り口として機能し、mNiリソースをYAMLによる宣言的管理で操作できるようになりました。

リソース例

以下はVPCリソースのYAML例です。

apiVersion: vpc/v1alpha
kind: Vpc
metadata:
  name: demo-vpc
  namespace: tenant-a
  displayName: "Tenant A Shared VPC"
  description: "VPC for tenant-a workloads"
  labels:
    env: dev
    owner: platform-team
spec:
  cidr: 10.42.0.0/16

このようにYAMLでリソースを管理できるため、Gitなどによるバージョン管理や再デプロイ、コピーも容易になりました。

機能詳細

  • *.mnicloud.jp配下の全CRDを自動検出し、動的クライアントを構築。
  • OpenAPIを自動生成し、フロントエンドやCLIからアクセス可能に。

Dependency Controller（新規作成）

概要

これまでのmNi Cloudでは、リソース間の依存関係が管理できない問題がありました。
たとえば、VMが存在するVPCを削除しようとすると、削除処理が完了しないケースが発生していました。
今回新たに導入したDependency Controllerによって、このような依存関係を適切に管理できるようになりました。

機能詳細

  • 各リソースはspec.dependsOnを通じて依存関係を明示可能。
  • 削除時にはファイナライザを付与し、依存リソースが削除完了するまで待機。
  • カスケード削除・逆参照を同期し、孤立リソースを防止。

VPC Controller

概要

以前から存在していたmNi VPC機能を再設計し、Controllerとして正式に独立させました。
Kube-OVNのCRDを直接操作していた旧構成から、VPC ControllerがKube-OVNを抽象化して管理する構成へ変更。
これにより、Kube-OVN側のエラーを吸収しつつ、不要な設定項目をユーザに露出させない安全な仕組みとなりました。

機能詳細

  • VpcリソースをKube-OVNのVpcオブジェクトへ同期。
  • CIDRを論理ルーターへ変換し、結果をステータスに反映。
  • 親VpcがReadyになった後にSubnetを調整。
  • 状態（Pending, Provisioning, Readyなど）を更新し、他Controllerと共有。

CTR Controller

概要

CTR（Container）機能も従来から存在していましたが、今回のリファクタリングでControllerとして再構築しました。
これにより、DeploymentやStatefulSetの管理が自動化され、Stateless／Stateful両モードに対応。
さらに、プライベートレジストリ認証にも対応しました。

機能詳細

  • Containerリソースを監視し、VPC/Subnet情報を付与したPodを生成。
  • ContainerPoolを管理し、スケーラブルなDeploymentを生成。
  • RegistrySecretリソースからDocker認証シークレットを自動作成。
  • Dependency Controllerと連携し、依存ネットワークがReadyになるまでワークロード起動を待機。

VM Controller

概要

mNi Cloudには以前から仮想マシン（VM）機能が存在していましたが、当時はControllerとして実装されていませんでした。
今回のリファクタリングで、このVM機能を正式にController化し、KubeVirtをベースとした自動化・統合管理を実現しました。
これにより、VPCやDependency Controllerとの連携が容易になり、信頼性・拡張性が大きく向上しました。

技術詳細

  • VirtualMachineリソースをKubeVirtのVirtualMachineに投影し、CDIでブロックストレージをクローン。
  • VirtualMachinePoolを監視し、指定されたレプリカ数のVMをスケーラブルに生成。
  • Imageリソースを処理し、停止中のVMディスクやHTTPソースから再利用可能なイメージを作成。
  • 依存するSubnet/VPCがReadyであることを検証し、安定稼働まで起動を待機。

BS Controller

概要

mNi Cloudのボリューム管理を担うBS（Block Storage）機能も、今回のリファクタリングでControllerとして整理しました。
Kubernetes標準のPVCをベースに、Volumeリソースとの整合性を確保しています。

技術詳細

  • Volumeリソースを監視し、指定サイズのPVCを作成・更新。
  • ファイナライザを利用して削除処理の整合性を確保し、孤立ボリュームを防止。

VPN Controller（新規作成）

概要

新機能として、VPC内部リソースへ安全にアクセス可能なクライアントVPN機能を追加しました。
実装にはTailscaleおよびそのOSS版Ionscaleを採用。
Kubernetes向けOperatorが存在しなかったため、自作Operator「kodiak」を開発し、Ionscaleをクラスタ内に自動展開できるようにしました。

技術詳細

  • VpnリソースをKodiak（Tailscale自動化）リソース群に投影。
  • ControlServer、Tailnet、AuthKey、Connectorを自動生成。
  • クライアント認証用シークレットを管理し、安全にTailnetへ参加可能に。
  • 参照するVpcのCIDRを取得し、Tailscale経由で広告。
  • ステータスに接続状態・Tailscale IP・コントロールプレーンURLを反映。

フロントエンドの開発状況

バックエンドの大幅な構造変更に合わせ、フロントエンドも全面的にリファクタリングしました。

フレームワークの再選定

従来はNext.jsを採用していましたが、以下の課題がありました。

  • ビルド時間が長い
  • メジャーアップデート時の破壊的変更
  • Vercel依存によるベンダーロックイン

これらを踏まえ、Tanstack Startを新たに採用。
SSRを廃止してSPA構成へ移行し、Monorepo構成も廃止してPolyrepo方式へ転換しました。

選定理由

  • Viteによる高速ビルド
  • Reactの標準的な思想に近い設計
  • SSR不要のためデプロイが容易

ShadCN Registryの活用

UIフレームワークとして引き続きShadCNを利用しています。
Registry機能を活用し、独自のUIコンポーネント群をShadCN形式で配布可能にしました。
これにより、各アプリケーションで必要なUIを柔軟に取り込めるようになりました。

UIの更新

デザインも一新し、より現代的で一貫性のあるUIを目指しています。

Kube-OVN依存からの脱却 ― 自作CNIの開発

背景

mNi Cloudのネットワーク機能はKube-OVNに依存していましたが、以下のような問題が発生していました。

  • VPC, Subnetの削除が完了しない不具合
  • EIP割り当ての不具合
  • SGの制約
  • kube-proxyとの連携が不十分

Kube-OVNは活発に開発されていますが、OVSベースであるため柔軟性に制約がありました。
そこで、自作CNIの開発を進めています。

自作CNIの方針

CNIの中核には eBPF（TC, XDP） を採用します。

採用理由

  • Linuxカーネル上で高速動作
  • iptablesに依存しない柔軟なパケット処理

VPCによるテナント分離、BGPによるアンダーレイIPの広報などを実現し、
SDN的な設計思想を維持しつつ、eBPFによる高性能・軽量なCNIを目指しています。

今後のmNi Cloudの予定

  • リファクタリングの完了
  • mNi Monitoringの開発とモニタリング機能の提供
  • mNi VPNを活用したリモート勉強会の開催
  • mNi Cloud上に自社製品を載せてリリース

おわりに

ここまでお読みいただきありがとうございます。
mNi Cloudはインフラ層からUI層まで一貫した改善を続けています。

今後は自作CNIの実装、監視・メトリクス基盤の整備、クラスタ管理機能の拡張などを予定しています。

引き続きmNi Cloudをよろしくお願いいたします。

Discussion