Crossplaneによるコントロールプレーン型IaC

クラウドリソースをKubernetesの世界に持ち込む

Crossplaneは、AWSのRDSやGCPのCloud SQLといったクラウドリソースそのものをKubernetesのカスタムリソースとして表現するOSSです。kubectl applyでRDSInstanceというCRDを作成すると、Crossplaneのコントローラがそれを観測し、対応するクラウドAPIを呼んで実体を作成、以後は望ましい状態へ収束させ続けます。これは/devops/operator-pattern-crd/で解説したOperatorパターンそのものの応用です。CRDでAPIを拡張し、カスタムコントローラが差分を埋める、という骨格は同一です。

違いは何を管理対象にするかです。汎用のOperatorパターンは「PostgreSQLクラスタの運用知識」のようにクラスタ内部のアプリ運用を自動化する道具として説明されることが多い一方、Crossplaneのコントローラ（プロバイダ）が管理するのはクラスタの外にあるクラウドインフラそのものです。対象はPodやPVCではなく、VPC・RDS・IAMロール・S3バケットといった、本来Terraform的なツールが扱ってきた資材です。

apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
  name: orders-db
spec:
  forProvider:
    region: ap-northeast-1
    dbInstanceClass: db.t3.medium
    engine: postgres
  writeConnectionSecretToRef:
    name: orders-db-conn   # 接続情報をSecretとして払い出す

reconcileの中身は/devops/reconciliation-control-loop/で述べたlevel-triggeredな収束ループと同じです。プロバイダはspec.forProvider（望ましい状態）とクラウドAPIから観測した実際の状態を突き合わせ、差分があればクラウドAPI呼び出しで埋めます。取りこぼしても次の周回で収束するため、Terraformのstateファイルのような外部の真実の源を別途持つ必要がありません。Kubernetes APIオブジェクトそのものがstateを兼ねるのがCrossplaneの一次的な特徴です。

Terraformの依存グラフモデルとの違い

/devops/iac-dependency-graph/で見た通り、Terraformは設定全体を一度読み込み、属性参照から依存グラフ（DAG）を構築し、トポロジカルソートで適用順を決めて一括applyします。apply完了後、実行プロセスは終了し、次にplanを実行するまでドリフトは検知されません。

Crossplaneはこの実行モデルを根本的に変えます。依存グラフを事前に構築して一度きり適用するのではなく、各リソースが独立したコントローラとして常駐し、24時間365日reconcileを回し続けます。あるリソースが他のリソースの出力値（例えばVPC IDなど）を必要とする場合も、依存グラフの辺として静的に解決するのではなく、参照先のstatusフィールドが埋まるまで単に待機し、埋まった時点のイベントで自身のreconcileが再トリガーされる、という個々のコントローラ同士の疎な協調で順序を実現します。

つまりTerraformが「計画を立てて実行する」バッチ指向なのに対し、Crossplaneは「常にあるべき姿を見張り続ける」プロセス指向です。ドリフト是正のために/devops/iac-state-drift-locking/で述べたような定期的な再apply運用やstateロックの設計をユーザー側で組む必要がなく、reconcileループ自体がそれを常時代行します。ただし裏を返せば、Crossplaneには「変更前にdiffを人間がレビューする」というplanフェーズに相当する標準の一時停止点がなく、承認フローは別途Composition側やGitOpsツール側で作り込む必要があります。

Compositionによるプラットフォーム抽象化

Crossplaneが単なる「CRD化されたTerraform」で終わらない核心がCompositionです。Compositionは、複数のマネージドリソース（VPC・サブネット・RDS・セキュリティグループなど）を束ね、利用者には1つの抽象APIだけを見せる仕組みです。

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xdatabases.platform.example.com
spec:
  group: platform.example.com
  names:
    kind: XDatabase
  versions:
    - name: v1
      schema:
        openAPIV3Schema:
          properties:
            spec:
              properties:
                size: { type: string, enum: ["small", "large"] }
                # ここに現れないフィールド(リージョン、暗号化設定等)は
                # プラットフォーム側が固定し、利用者は変更できない

利用者が触れるのはsize: smallのような数個の入力だけで、Compositionテンプレートがそれを実際のVPC・サブネット・RDSインスタンス群へ展開します。暗号化設定・タグ付け・ネットワーク配置といった組織のガードレールはCompositionの中に固定され、利用者のAPIサーフェスから隠蔽されます。

Compositionはさらに**関数（Composition Functions）**でロジックを差し込めるため、単なるテンプレート展開を超えて条件分岐やループを伴う動的な合成も可能です。これはTerraformのモジュールがHCL内の変数展開に留まるのと比べ、抽象化の単位そのものをKubernetes APIオブジェクトとして再利用・バージョニング・RBAC管理できる点で異なります。

GitOpsとの関係：何が違うか

/devops/gitops-reconciliation/のArgo CDやFluxも「望ましい状態と観測状態を突き合わせて収束させる」調整ループですが、対象と主従関係が異なります。GitOpsツールはKubernetesの外にあるGitリポジトリを事実の源とし、その内容をクラスタ内リソース（Deployment等）へ同期する係です。Crossplaneはそもそも事実の源がクラスタ内のCRD自体であり、対象もクラウドインフラです。

両者は競合するのではなく重ねて使うのが実務上の定石です。GitOpsツールがGit上のRDSInstanceやXDatabaseマニフェストをクラスタへ同期し、CrossplaneのコントローラがそのマニフェストをクラウドAPIへ収束させる、という二段構えです。GitOpsが「Kubernetes APIオブジェクトを正しく保つ係」、Crossplaneが「そのオブジェクトから外部世界を正しく保つ係」という分業になります。

まとめ

• CrossplaneはOperatorパターンの枠組みをそのまま流用しつつ、対象をクラウドリソース自体に広げたコントロールプレーンである。
• Terraformのような事前計算された依存グラフではなく、常駐コントローラ同士のstatus参照待ちによる疎な協調で順序を実現し、reconcileループがドリフトを常時是正する。
• Compositionは複数リソースを束ねて狭い抽象APIとして公開し、プラットフォームチームのガバナンス単位をコードレビューからAPIスキーマ設計へ移す。
• GitOpsとは競合せず補完関係にあり、GitOpsがCRDをクラスタへ届け、Crossplaneがそこから外部クラウドを収束させるという分業が現実的な組み合わせである。