【CNDW2025】Crossplane導入で見えたKubernetesプラットフォーム運用の課題とCompositionが切り拓く次の可能性

CloudNative Days Winter 2025で行われたセッション「Crossplane導入で拓くKubernetesプラットフォーム開発の新たな可能性」では、パナソニックコネクト クラウドスペシャリストの中島 悠里花氏が、SaaS事業を支えるKubernetesプラットフォームの実装と運用の実態を語った。本セッションは、Crossplane導入前に直面した人手運用の限界から、Compositionを活用した変革、さらに導入後に見えた現実的な課題と今後の展望までを、実践者の視点で丁寧に紐解く内容である。

AzureとKubernetesで構築する
マルチテナント型SaaSプラットフォーム

AzureとKubernetesを使ったマルチテナント型のプラットフォームを提供しているパナソニックコネクトの中島氏は、セッションの冒頭で自身が所属するチームがSaaS事業拡大を支える共通基盤の開発を担っていることを説明した。ハードウェア事業に強みを持つ一方、持続的な成長に向けてソフトウェア、特にSaaS事業への注力を進めており、その基盤としてプラットフォーム開発が位置付けられている。

中島氏が紹介したプラットフォームはAzure上のAKSを中心に構成され、同一のKubernetesクラスター上で複数のSaaSアプリケーションを安全に稼働させるマルチテナント型の設計を採用している。構成は「1階」と「2階」に分けられ、1階にはArgo CDやGatekeeperといったテナント間で共通利用するKubernetesリソースやFront Door、WAFなどのAzure共通サービスを配置する。一方、2階にはテナント固有のリソースが配置され、SaaSアプリケーションは「ランタイム」と呼ばれる標準リソースセットの上に構築される。

このランタイムにはNamespaceやNetworkPolicyなどのKubernetesリソースに加え、データベースといったAzureマネージドリソースが含まれる。コンピューティングリソースは共有しつつ、データはテナントごとに分離することで効率性とセキュリティの両立を図っている点が特徴である。こうした構成について中島氏は、次のように語っている。

「プロダクトチームがよりビジネスロジックの開発に専念できるように、共通で使う部分やセキュリティに関わる部分はプラットフォームチームがすべて管理する構成を取っています」。

プラットフォームチームが共通基盤を一元的に管理し、プロダクトチームはアプリケーション開発に集中する。この明確な役割分担こそがSaaSを継続的に増やしていくための前提条件であり、後に語られるGolden Path構想の出発点となっている。

Crossplane導入前に直面していた「人手運用」の限界

設計上は理想的だったマルチテナント型プラットフォームだが、その運用は人手に強く依存していた。特に負荷となっていたのがSaaSアプリケーションの基盤となる「ランタイム」の作成と更新作業である。

Crossplane導入前、ランタイムの作成には4つの手順が必要だった。AzureリソースをBicepで定義し、コマンドを実行してデプロイする。その後、Kubernetesリソースを定義するためにHelmチャートのパラメータを入力し、GitHubへプッシュしてArgo CDによるGitOpsを成立させる。これらは順番通りに実行する必要があり、途中で抜け漏れが生じる余地が大きかった。

この運用フローではヒューマンエラーが頻発していた。BicepとHelmの双方に同じパラメータを入力することで変更漏れが起き、Bicepのデプロイコマンドを実行し忘れるとコードと実体が乖離する。また、複数のプロダクトや環境が存在する中で誤ったリソースIDをコピー＆ペーストしてしまうといった事故も避けられなかった。

こうした問題が表面化したのは、プラットフォームの利用が本格化してからである。2025年に入ると利用プロダクトが急増し、ランタイム数は30にまで増加した。作業量は単純に増え割り込み対応も重なり、チームは次第に運用に追われる状況に陥っていった。当時を振り返り、中島氏は「本来やりたかった自動化のタスクが全然進まなくなってしまって、正直、もうお手上げだなという状況でした」と語る。

IaCやGitOpsを採用していても、運用の要所が人手に依存している限りスケールには限界がある。この「人手運用の限界」に直面したことが、Crossplane導入を検討する直接のきっかけとなった。

Crossplaneがもたらした変化とCompositionの力

人手運用の限界に直面した中島氏のチームが選択したのがCrossplaneであった。Crossplaneとは、Kubernetes以外のリソースをKubernetesのリソースとして扱えるようにする仕組みである。Azureをはじめとしたクラウドサービスのリソースを、Kubernetesのマニフェストとして宣言的に管理できる点が大きな特徴だ。

この特性だけでもAzureリソースをGitOpsの管理下に置けるという効果は期待できる。しかし、中島氏が特に価値を感じたのはCrossplaneの中核機能であるCompositionにあった。Compositionは種類の異なるリソースを1つのセットとして定義し、抽象化できる仕組みである。さらに、これらのリソース間で情報を自動的に伝搬させることができる点が、従来の運用を大きく変えた。

具体的には、AzureのマネージドIDとKubernetesのServiceAccountといった本来は別々に作成・設定していたリソースを1つの複合リソースとして定義した。これにより、マネージドID作成時に自動生成されるリソースIDやclientIdを人手でコピー＆ペーストすることなく、必要なリソースへ自動的に反映できるようになった。中島氏はこの点について、次のように語っている。「IDを間違えて貼り付ける、という事故が構造的に起きなくなったのが一番助かりました」。

こうしたCompositionを活用した結果、従来4段階に分かれていたランタイム作成の手順は1つのHelmチャートへのプッシュに集約された。パラメータは1か所で管理され、すべてのリソースはGitと同期される。リソースIDの手動入力も不要となり、変更漏れや設定ミスが発生しにくい運用へと転換された。

Crossplaneの導入により実現したのは、単なる作業削減ではない。インフラ管理を完全に宣言的なモデルへ移行し、人手に依存していた運用のボトルネックを構造的に解消した点にこそ、本質的な価値があったと言える。

Crossplane導入後に見えた課題と次の一手

Crossplaneの導入により運用は大きく改善したが、新たな課題も浮き彫りになった。その代表例がKubernetesのAPI Serverへの負荷である。検証の結果、Crossplaneをインストールしたクラスターではメモリ使用率が顕著に増加する傾向が確認された。

まず取り組んだのが、Reconciliationのレート調整である。ポーリング間隔や同期頻度を変更して負荷軽減を試みたものの、目立った効果は得られなかった。一方、明確な改善につながったのが「不要なManaged Resourceの無効化」である。デフォルト設定では大量のCRDが有効化されるため、利用するManaged Resourceを限定したところメモリ使用率は大きく改善した。

ただし、この対応には重要な注意点がある。Managed Resourceは一度有効化すると後から無効にできない。そのため、Crossplane導入時点での設定がその後の運用負荷に大きく影響する。この点について中島氏は「後から調整するのが難しいので、最初のインストール時の設定は本当に大事だと感じました」と語る。

こうした試行錯誤を経てプラットフォームはほぼすべてをIaCとして管理できる状態となり、セルフサービス化に向けて大きく前進した。一方で、ユーザーの抽象的な要求をIaCのパラメータに変換する作業は依然として人手に頼っている。現在はユーザーにGolden Pathを提示し、選択からデプロイまでを自動化する仕組みの開発が進められている。

セッションを通じて示されたポイントは明確だ。Crossplaneは、Kubernetes以外のリソースをKubernetesのリソースとして扱うことでKubernetesの宣言的管理という強みをインフラ全体へ拡張する。中でもCompositionは、その価値を最大限に引き出す中核的な仕組みである。

一方で、実運用においては導入初期の設計や設定が、その後の運用負荷に大きく影響することも明らかになった。provider.defaultActivations: []の指定はその一例であり、Crossplaneを「便利に使い続けられるかどうか」を左右する判断ポイントの1つだと言える。