KubeSphere 4.x を導入前に読む: LuBan マイクロカーネル構成の実像

KubeSphere が埋めようとしている穴は何か

素の Kubernetes はリソースの API とコントローラの集合であって、運用の入口は kubectl と YAML になる。クラスタが一つなら問題にならない。クラスタが三つ、五つと増え、それぞれ別のクラウドやデータセンター、ときにはエッジ拠点に置かれると、認証、権限、監査ログ、監視、アプリ配布の経路がクラスタごとにバラバラになる。KubeSphere が対象にしているのはこの状態である。README は自身を「distributed operating system for cloud-native application management」と説明し、Kubernetes をカーネルとして位置づけている。利用者として想定されているのは、プラットフォームチームと、その上でアプリを動かす開発者の両方だ。開発者向けにはウィザード形式の Web UI が用意され、プラットフォーム側にはマルチテナントの分離とクォータ管理が用意される。つまり kubectl を置き換えるツールではなく、組織の複数クラスタを一つの管理面に束ねる層である。

LuBan と呼ぶマイクロカーネル構成の意味

KubeSphere 4.x の最大の設計変更は、アーキテクチャの節に書かれている「microkernel + extension components architecture」への移行である。コードネームは LuBan。3.x 系では DevOps、監視、サービスメッシュ、アプリストアといった機能が本体に組み込まれていたのに対し、4.x ではこれらが拡張コンポーネントとして切り出され、必要なものだけを有効化する前提になった。README の Feature List は、Extensible Architecture を最初の項目に置き、各機能の見出しに Learn more としてドキュメントへのリンクを並べる構成をとっている。これは機能一覧というより、有効化できる拡張のカタログとして読んだほうが実態に近い。利点は明白で、監視もサービスメッシュも使わない組織がそれらのコンポーネントを抱え込まずに済む。代償は、インストールが「全部入りを一度入れる」作業から「必要な拡張を選んで有効化し、その組み合わせを保守する」作業に変わることだ。この点は後述する。

マルチクラスタ管理とアプリ伝播の仕組み

マルチクラスタ管理は KubeSphere の中核機能の一つで、README は「centralized control plane to manage multiple Kubernetes clusters」と説明し、異なるクラウド事業者にまたがる複数の K8s クラスタへアプリを伝播させる機能に触れている。データの流れとしては、各クラスタ側に何らかのエージェントが入り、中央のコントロールプレーンがそれを集約する形になる。ただし、この記事で扱える材料にはエージェントの名前や登録手順、伝播のためのカスタムリソースの具体名までは含まれていない。ここは推測で埋めず、実際に採用を検討する段階で公式ドキュメントの該当ページを確認してほしい。確認できる範囲で言えるのは、KubeSphere が単一クラスタの管理画面ではなく、複数クラスタを一つのテナントモデルに載せることを設計の中心に置いているという点である。マルチテナントは「Isolated workspaces with role-based access control」と記述され、ワークスペースという単位でリソースを分離し、ロールベースの権限とクォータを組み合わせる。クラスタをまたいだ権限設計をどうするかは、この製品を選ぶかどうかを分ける論点になる。

DevOps と可観測性は何に乗っているか

DevOps の項目は、GitOps ベースの CD を Argo CD が下支えし、CD のステータス情報をリアルタイムに収集すると説明している。CI 側は Jenkins を統合する。つまり KubeSphere はパイプラインエンジンを自前で持たず、既存の Argo CD と Jenkins をコンソールに接続する立場をとる。可観測性の項目では、多次元の監視、イベントと監査ログ、マルチテナントのログ検索と収集、アラートと通知が組み込みで提供されるとされる。サービスメッシュは Istio ベースで、トラフィック管理、可観測性、トレーシング、トラフィックトポロジの可視化を提供する。ここで注意したいのは、これらがすべて拡張として提供されるという 4.x の前提である。監視スタックや Istio をすでに独自に運用している組織にとっては、KubeSphere の拡張を有効化することが既存スタックとの二重管理を生む可能性がある。逆に、まだ何も整備できていない組織にとっては、選択肢を一から比較する手間を省ける。どちらに転ぶかは、既存の運用体制の厚さで決まる。

インストールの入口: Helm チャートと ks-installer

導入手順の全体像は README からは読み取れないが、リポジトリの構造とリリースから入口は特定できる。リリースには v4.1.3 のようなバージョン番号の系列と、helm-chart-1.1.5 というチャートの系列が並行して存在する。README のバッジには hub.docker.com/r/kubesphere/ks-installer への参照があり、インストーラがコンテナイメージとして配布されていることがわかる。インストールおよびアップグレードのドキュメントは v4.1 のツリー配下に置かれている。したがって実際の作業は、KubeSphere のドキュメントにあるインストール手順に従って ks-installer を対象クラスタへ適用し、その後 Web コンソールから必要な拡張を有効化する、という二段構えになると考えられる。エアギャップ環境へのインストールが Feature List で明示的に挙げられている点は、閉域網を前提とする組織にとっては判断材料になる。ただし、具体的な helm install のコマンドや values.yaml のキー名は、この記事が参照できる材料には含まれていない。バージョンを固定して導入する際は、v4.1.3 と helm-chart-1.1.5 のどちらの系統を基準にするのかを先に決めておかないと、後から整合を取る作業が発生する。

向かないケースと、拡張構成が生む保守コスト

KubeSphere が過剰になる場面ははっきりしている。クラスタが一つしかなく、デプロイは Helm と kubectl で完結し、監視は既存の Prometheus で足りている。この条件なら、コントロールプレーンを一つ増やす意味はほぼない。障害点が増え、アップグレード時に KubeSphere 本体と各拡張のバージョン整合を取る作業が加わる。4.x の拡張構成はこのコストを正面から受け入れる設計であり、有効化した拡張の数だけ、本体のアップグレード時に追随を確認する対象が増える。もう一つの注意点はライセンス表示である。リポジトリのメタデータでは NOASSERTION となっており、自動判定が SPDX 識別子に落ちなかったことを意味する。KubeSphere 本体と、Argo CD、Jenkins、Istio、KubeEdge といった統合先コンポーネントのライセンスはそれぞれ別である。導入前に LICENSE ファイルと、有効化する予定の拡張それぞれのライセンスを個別に確認する必要がある。ここは法務判断の領域なので、この記事では条件を提示するにとどめる。

比較対象としての Rancher と OpenShift

同じ問題領域には Rancher と Red Hat OpenShift がある。Rancher は複数の Kubernetes ディストリビューションを取り込み、クラスタのプロビジョニングと管理を一つの UI に集約する方向で作られている。KubeSphere との違いは、Rancher が下流のディストリビューションの選択を広く許すのに対し、KubeSphere は自前のコンソールと拡張モデルを中心に据え、その上でマルチテナントと DevOps を一体化しようとする点にある。OpenShift はさらに踏み込み、OS レベルの要素まで含めた統合製品として提供される代わりに、対応プラットフォームとバージョンの自由度が小さくなる。KubeSphere はこの中間に位置する。Kubernetes そのものは素のまま使い、管理面とテナントモデルだけを被せたい場合に、KubeSphere の拡張構成は OpenShift より軽く、Rancher よりコンソールの統合度が高い。逆に、ディストリビューションの選択を最優先するなら Rancher のほうが素直だ。

採用を決める前に確かめる三つのこと

第一に、Feature List に並ぶ拡張のうち、実際に有効化するものを書き出す。DevOps、可観測性、サービスメッシュ、App Store、KubeEdge のうち使うものだけを選び、それぞれのドキュメントを読む。第二に、リリース系統を決める。v4.1.3 系と helm-chart-1.1.5 系のどちらを基準にアップグレードを追うのかを先に決めておかないと、後で整合を取る作業が発生する。第三に、マルチクラスタの権限モデルを、ワークスペースとロールベースアクセス制御の実際の挙動で確認する。ドキュメントの記述だけでは、クラスタをまたいだときにどこまで分離されるかは判断できない。KubeSphere Lite のマネージドクラスタが無料で提供されているので、本番のクラスタを用意する前に、拡張の有効化とコンソールの操作感をそこで確かめるのが現実的である。この順序で進めれば、導入後に「使わない拡張まで抱えていた」という事態は避けられる。

編集部の結論

採用を検討すべきなのは、複数の Kubernetes クラスタを一つのコンソールで運用し、ワークスペース単位のテナント分離と監査・ログをまとめて必要とする組織である。単一クラスタで標準の kubectl と Helm だけで足りている場合や、コントロールプレーンの依存を増やしたくない場合は向かない。導入前に確認すべきは、README が示す Feature List のうち実際に使う拡張がどれか、そして v4.1.3 と helm-chart-1.1.5 という別系統のリリースのどちらを基準にするかである。ライセンスはリポジトリのメタデータ上 NOASSERTION と表示されており、SPDX 識別子が自動判定できていない。法務判断の前に必ず LICENSE ファイルと各拡張のライセンスを直接読むこと。

公式情報源

1. Issues
2. kubesphere/kubesphere on GitHub
3. Project website
4. README
5. Releases