【mNi Cloud】1月～3月の開発状況【国産クラウド】
はじめに
こんにちは。mNi Cloud開発チームです。
2024年7月に開発を開始した国産クラウドプラットフォーム「mNi Cloud」は、引き続き開発を進めております。7月～12月は機能の開発をメインに進めてきましたが、1月~3月は大規模展開に向けた下地作りやメンテナンスを行えるような設計をメインに行いました。
mNi Cloudとは
mNi Cloudについては以下の記事にまとめてあります。
7月～12月の開発状況
ベアメタルサーバへのKubernetesクラスタの展開
mNi CloudはKubernetesをベースとしたクラウド基盤となります。
KubernetesはCluster APIと呼ばれる, クラスタを宣言管理できるツールを使用することで、リモートのノードに対しクラスタを構築することが可能となります。
Cluster APIはAWSやAzureといった主要なクラウドだけでなく、VMware vSphereやProxmoxのようなオンプレミスな仮想基盤にも対応しています。
また、ベアメタルなサーバにもクラスタを展開するProviderが存在します。
以下がベアメタルに対する主要なProviderです。
- Bring Your Own Host (BYOH)
- Tinkerbell
- Metal3
我々はTinkerbellとMetal3の検証を行い、Metal3を採用することとしました。
Tinkerbell
Tinkerbellは、Equinixが主導する比較的新しいオープンソースのプロビジョニングエンジンです。CNCFのサンドボックスプロジェクトとして開発が進められており、ベアメタルサーバの自動化に特化しています。
主な特徴
- ワークフローベースのアーキテクチャ: 「Hook」と呼ばれるコンテナベースのアクションを組み合わせて、サーバのプロビジョニングを定義できます
- 宣言的な設定: YAMLを使用してハードウェア構成とワークフローを定義
- PXEブート対応: ネットワークブートを活用したゼロタッチプロビジョニング
- Kubernetesとの統合: CAPIプロバイダとしての機能を提供
メリット
- シンプルなワークフローモデルにより、理解しやすい設計
- コンテナベースのアクションにより拡張性が高い
- ネットワークブートをサポートするほとんどのx86ハードウェアで動作
デメリット
- 比較的新しいプロジェクトのため、成熟度と実績が限られている
- BMC（ベースボード管理コントローラ）との統合が限定的
- ドキュメントやコミュニティサポートが発展途上
Metal3
Metal3（Metal Kubed）は、OpenStackのIronicプロジェクトを基盤としたベアメタルプロビジョニングシステムです。Red HatとOpenStackコミュニティによって積極的に開発されています。
主な特徴
- BMCベースの管理: IPMI、Redfish、iLO、iDRACなどのBMCプロトコルを使用して直接ハードウェアを制御
- OpenStack Ironicの活用: ベアメタル管理技術を基盤として採用
- 包括的なハードウェアサポート: 様々なベンダーやハードウェアタイプに対応
- 堅牢なライフサイクル管理: ノードの検出、電源制御、OSプロビジョニング、更新などを一元管理
メリット
- BMCを使用したアウトオブバンド管理により、障害復旧能力が高い
- OpenStack Ironicの実績ある技術基盤を活用
- 幅広いハードウェアベンダーとモデルをサポート
- 大規模環境での実績と信頼性
- 活発なコミュニティとOpenShiftによる商用サポート
デメリット
- 設定の複雑さがTinkerbellと比較して高い
- BMC対応ハードウェアが必要
- リソース要件が比較的高い
比較と選定理由
| 機能 | Tinkerbell | Metal3 |
|---|---|---|
| 成熟度 | 中（開発中） | 高（Ironicベース） |
| ハードウェア互換性 | PXE対応x86 | 幅広いBMC対応機器 |
| 障害復旧能力 | 限定的 | 高（BMC制御） |
| スケーラビリティ | 中 | 高 |
| 設定の複雑さ | 低〜中 | 中〜高 |
| コミュニティサポート | 発展途上 | 活発 |
| エンタープライズ採用 | 限定的 | 広範 |
我々がMetal3を選択した主な理由は以下の通りです：
- Redfish APIの採用: Metal3はRedfishなどの最新BMC管理プロトコルをサポートしており、従来のPXEブート方式よりも多くの利点があります
-
PXEに対するRedfishの優位性:
- 双方向通信によるサーバーの詳細な状態監視と制御
- セキュリティの強化（認証、暗号化など）
- RESTful APIによる標準化された管理インターフェース
- リモートからのハードウェア診断や詳細設定
- 電源管理や起動順序の高度な制御
- 完全なライフサイクル管理: ハードウェア検出から廃止までの一貫した管理
- エンタープライズ導入実績: 大規模環境での運用事例の豊富さ
- 活発なコミュニティ: OpenStackとKubernetesの両コミュニティからのサポート
Tinkerbell、Metal3の両方の検証、比較検討を行いましたが、Redfishベースの管理機能と実績を持つMetal3が当社のエンタープライズ要件により適していると判断しました。
現状、TinkerbellおよびMetal3の展開手順記事が少ないため、今後執筆予定でございます。
各サービスのOperator化
今まではバックエンドアプリを作成し、client-goからKubernetesのAPIを操作する設計となっていました。しかし、Kubernetes基盤を利用するうえでより密な連携を行うためにKubebuilderを利用したKubernertes Operatorを作成することに決定しました。
Kubernetes Operatorとは
Kubernetes Operatorとは、Kubernetesの拡張機能として、アプリケーション固有のドメイン知識をプログラム化し、Kubernetesの宣言型APIを通じて操作できるようにする仕組みです。Operatorは特定のアプリケーションやサービスのライフサイクル（デプロイ、更新、バックアップなど）を自動化するための専用コントローラーとカスタムリソースで構成されます。
Operatorのコア概念は「カスタムリソース（CR）」と「カスタムコントローラー」です：
- カスタムリソース：Kubernetesのネイティブリソースに加えて、独自のリソース型を定義できます
- カスタムコントローラー：定義したカスタムリソースの状態を監視し、指定された状態になるよう調整するロジックを実装します
client-goベースのアプローチとOperatorの違い
これまでのアプローチと比較すると、以下のような違いがあります：
| 項目 | client-goアプローチ | Operator |
|---|---|---|
| アーキテクチャ | 外部アプリからKubernetes APIを呼び出す | Kubernetes内部でCRDとコントローラーを実装 |
| 自動調整 | 手動または外部から定期的に実行 | コントローラーが常に状態を監視・調整 |
| デプロイモデル | 独立したアプリケーション | Kubernetesリソースとして管理 |
| スケーラビリティ | アプリケーション側で実装 | Kubernetes標準の仕組みで対応 |
| 他リソースとの連携 | 個別に実装 | Kubernetes標準の仕組みで連携 |
Operatorによる設計アーキテクチャ
Kubernetes Operator設計では、複数のOperatorが連携する階層型アーキテクチャを採用しています。
複数Operatorによる責務分担
各サービスドメイン別に独立したOperatorを実装しています：
- mNi Operator：サービスを統合管理するOperator
- VM Operator：仮想マシン管理専用のOperator
- VPC Operator：Virtual Private Cloud管理専用のOperator
- Other Operator：そのほかのサービス管理を担当
各Operatorは独自の責務を持ち、FrontendとBackendの両方のデプロイメントを管理することで、UIとバックエンドロジックの明確な分離を実現しています。
Operator Lifecycle Manager（OLM）の活用
設計の中核となるのが、Operator Lifecycle Manager（OLM）です。OLMは複数のOperatorのライフサイクル全体を一元管理し、以下の機能を提供します：
- Operatorのバージョン管理
- Operator間の依存関係の解決
- インストール/アップグレードの自動化
- サブスクリプションを通じた更新管理
これにより、多数のOperatorが連携するシステムでも、一貫性のある管理が可能になります。
階層型設計
この設計では、各コンポーネントが明確な階層構造を形成しています：
- OLM：全体のライフサイクル管理を担当
- 各種Operator：ドメイン固有の管理（VM、VPC、その他）を実施
- Deployment管理：Frontend/Backend分離による関心事の分離
- Pod管理：実際のワークロード実行
この階層型アプローチにより、関心事の分離と責務の明確化が実現できます。
Kubernetes APIとの統合
各Operatorのバックエンドは、それぞれ適切なKubernetes APIと連携しています：
- KubeVirt API：VM Operatorが仮想マシン管理用に使用
- Kube-OVN API：VPC Operatorが仮想ネットワーク管理用に使用
mNi Operatorによる共通機能の提供
右上のmNi Operatorは、「機能の容器化」を提供し、他のOperatorから利用される共通機能を管理しています。シンプルなCRDとControllerの構成で、再利用可能なコンポーネントとして設計されています。
Kubebuilderのプラグイン機能の活用
Kubebuilderには強力なプラグイン機能が備わっており、フレームワークの拡張が可能です。このプラグイン機構を活用することで、ベースとなる機能に独自の拡張を加えることができます。
プラグイン機能の概要
Kubebuilderのプラグインシステムは、以下の特徴を持っています：
- プラグイン型アーキテクチャ: コアフレームワークと機能拡張を分離
- カスタムスキャフォールド: 特定ユースケース向けにプロジェクト生成をカスタマイズ可能
- 独自のコード生成ロジック: 特定パターンに適したコードテンプレートを提供
- 設定のカスタマイズ: 独自のプロジェクト設定やオプションの追加
OSS版でのプラグイン活用計画
今後展開するOSS版では、このプラグイン機能を積極的に活用し、コミュニティが新たなサービスを容易に構築できる環境を整備する計画です：
- 独自Operatorテンプレート: 当社のOperatorパターンに基づいたプラグイン提供
- サービスモジュール化: 各種サービスコンポーネントをプラグインとして提供
コミュニティによる拡張性
プラグイン機能を通じて、コミュニティメンバーは以下のようなメリットを得ることができます：
- 統一された開発体験: 共通のフレームワークとパターンによる学習コストの低減
- 再利用可能なコンポーネント: 既存のプラグインを組み合わせた迅速な開発
- 簡易デプロイメント: 標準的なデプロイメントプロセスの自動化
- ベストプラクティスの共有: 業界標準のパターンを組み込んだプラグインの利用
今後の展望
Metal3を活用したシステムインテグレーション
今後は、Metal3をベースとした基盤技術を活用し、お客様の既存環境へのシステムインテグレーションを積極的に進めていく予定です。Metal3の持つBMC管理機能とOpenStack Ironicの技術基盤により、様々なハードウェア環境に対応したmNi Cloudの導入が可能となります。
具体的には以下のような対応を予定しています：
- 既存インフラへの適応: お客様が保有する多様なベアメタル環境に合わせたカスタマイズ導入
- カスタムワークフロー: お客様固有の要件に応じたプロビジョニングワークフローの提供
- 移行支援ツール: 既存システムからのスムーズな移行を支援する機能の開発
このシステムインテグレーションにより、単なるクラウドプラットフォームの提供にとどまらず、お客様のビジネス要件に合わせた柔軟なソリューション展開が可能となります。RedfishやIPMIなどの標準プロトコルをサポートすることで、様々なベンダーの機器に対応し、お客様の既存資産を最大限に活用したクラウド基盤の構築を実現します。
OSSとしての展開基盤の整備
もう一つの重要な展望として、mNi CloudをOSSとして広く展開できる基盤の整備を進めています。Kubebuilderのプラグイン機能を活用することで、コミュニティベースでの拡張性と再利用性の高いエコシステムを構築していきます。
OSS展開における主な取り組みとして：
- モジュラーアーキテクチャの強化: 各コンポーネントの疎結合化とプラグインベースの拡張機能
- カスタマイズフレームワークの提供: 独自要件に合わせた機能拡張を容易にする仕組み
- 標準インターフェースの定義: サードパーティ製品との連携を促進する標準API
- リファレンス実装の公開: 主要ユースケースに対する参照実装の提供
- 開発者ポータルの整備: ドキュメント、チュートリアル、APIリファレンスの充実
これらの取り組みにより、企業や開発者が独自にカスタマイズしたmNi Cloud環境を構築できるようになります。特に、Kubernetes Operatorの階層型設計アプローチを活かし、コア機能を維持しながらも、独自サービスの追加や既存サービスの拡張が容易なフレームワークを目指しています。
将来的には、コミュニティ主導での機能拡張やプラグイン開発が活発に行われる、オープンなクラウド基盤エコシステムの形成を構想しています。これにより、国産クラウドプラットフォームとしての独自性を保ちながらも、グローバルな標準技術との互換性を確保した柔軟な環境を提供していきます。
おわりに
本記事では、mNi Cloudの開発状況と今後の方向性について紹介しました。ベアメタルサーバへのKubernetesクラスタ展開においてはMetal3を採用し、各サービスのOperator化によりKubernetes基盤との連携を強化しています。
これまでのclient-goベースのアプローチからKubernetes Operatorへの移行により、サービスの自動化とライフサイクル管理が大幅に改善されます。また、複数のOperatorが連携する階層型アーキテクチャを採用することで、各サービスドメインの責務を明確に分離しながらも統合的な管理を実現できます。
今後はKubebuilderのプラグイン機能を活用し、OSS版での展開も視野に入れています。コミュニティメンバーが容易に新たなサービスを構築できる環境を整備することで、mNi Cloudのエコシステムをさらに拡大していく予定です。
引き続きmNi Cloudの開発状況については随時情報を発信してまいります。皆様のフィードバックやご意見をお待ちしております。今後ともmNi Cloudをよろしくお願いいたします。
Discussion