初めに

この記事では、Crossplane をいきなり OCI Provider のインストール手順から見るのではなく、まず Platform API という観点から整理します。

Crossplane の公式 GitHub README では、Crossplane は cloud native control plane を構築するための framework と説明されています。重要なのは、Crossplane を単なる IaC 実行ツールとして見るのではなく、Kubernetes API を使って自分たち向けの宣言的 API を作る仕組みとして見ることです。

また、Oracle の crossplane-provider-oci は OCI 向けの Crossplane Provider です。公式 README では、この Provider は Upjet によって生成され、OCI Terraform Resources をベースに XRM に準拠した managed resources を作ると説明されています。

つまり、Crossplane と OCI Provider を組み合わせると、OCI リソースを Kubernetes manifest として扱うだけでなく、チーム向けの Platform API に近づけることができます。

この記事では、その最初の入口として、次の内容を整理します。

Platform Engineering
  -> Platform API
    -> Kubernetes API Server
      -> Crossplane Core
        -> OCI Provider
          -> OCI Resource

この記事のゴール

この記事のゴールは、細かい YAML や ProviderConfig の設定に入る前に、次のことを自分の言葉で説明できるようになることです。

Platform API とは何か
Crossplane は何をするものか
Kubernetes API Server はどこに入るのか
Provider は何を担当するのか
OCI リソースはどのように Kubernetes API とつながるのか

ここではまだ Object Storage Bucket を作りません。

まずは、Crossplane を「OCI リソースを作るツール」としてではなく、「利用者向け API と外部クラウドをつなぐ control plane」として見るための準備をします。

Platform Engineering は「利用者向け API」を作る話

Platform Engineering という言葉を聞くと、CI/CD、Kubernetes、Terraform、Observability など、いろいろな技術要素を思い浮かべます。

ただし、ここで大事にしたいのは、Platform Engineering を クラウドの細かい設定を全部利用者に渡す話 として見ないことです。

たとえば、開発チームが本当に欲しいものは、次のような能力かもしれません。

オブジェクトを保存できる場所がほしい
チームごとに安全に分離したい
命名規則やタグは標準化したい
接続情報だけ受け取りたい
削除や変更の責任範囲を明確にしたい

一方で、OCI 側には Bucket、compartment、namespace、IAM policy、tag、Secret など、複数の実装要素があります。

Platform API の考え方では、利用者に OCI の全 field を見せるのではなく、利用者が判断すべき項目だけを API として公開します。

イメージとしては、以下のような分担です。

開発チーム
  必要な能力を API として要求する

Platform API
  命名、権限、配置先、標準設定を抽象化する

Control Plane
  宣言を観察し、外部リソースの状態へ反映する

OCI
  実際のクラウドリソースを保持する

ここで Crossplane が候補になります。

Crossplane は Kubernetes 上で動く Control Plane

Crossplane は、Kubernetes cluster にインストールして使います。

利用者は kubectl や Argo CD などを使って Kubernetes API Server に YAML を apply します。Kubernetes API Server は CRD、validation、RBAC、etcd を使って desired state を保持します。

Crossplane は、その Kubernetes API を拡張し、controller として desired state を見続けます。

全体像は以下のように見ると分かりやすいです。

ユーザー / GitOps ツール
  |
  v
Kubernetes API Server
  |
  v
Crossplane Core
  |
  v
Provider
  |
  v
OCI API
  |
  v
OCI Resource

ここでのポイントは、Crossplane が Kubernetes の外側で一回だけ実行される CLI ではないことです。

Crossplane は Kubernetes 上で動き、Kubernetes API に保存された desired state と外部クラウドの actual state を継続的に近づけます。

Crossplane Core と Provider の役割

Crossplane を読むときは、まず Core と Provider を分けると理解しやすくなります。

Crossplane Core
  XRD、XR、Composition、package などを扱う

Provider
  外部 API と接続し、Managed Resource を reconcile する

Core は、Crossplane の抽象 API を扱います。

たとえば、後続で出てくる CompositeResourceDefinition、Composite Resource、Composition は、利用者向け API を作るための部品です。

Provider は、外部クラウド API と接続します。

OCI Provider の場合は、OCI API を呼び出し、OCI の Object Storage、Networking、Compute などのリソースを Kubernetes resource として扱えるようにします。

公式の crossplane-provider-oci リポジトリでは、この Provider は Upjet で生成され、OCI Terraform Resources をもとに XRM に準拠した managed resources を提供すると説明されています。

ここから分かるのは、OCI Provider は「OCI 専用の controller 群」として見ると理解しやすいということです。

Managed Resource は外部リソースの Kubernetes 表現

Crossplane では、外部クラウド上の実リソースに対応する Kubernetes object を Managed Resource として扱います。

たとえば OCI Object Storage Bucket を考えると、概念的には以下の関係になります。

Kubernetes object
  Bucket Managed Resource

OCI external resource
  Object Storage Bucket

利用者が Kubernetes に Bucket の manifest を apply すると、Provider が OCI API を呼び出し、実際の Bucket を作成または更新します。

このとき、Kubernetes 側の spec は「こうなってほしい」という desired state です。

Provider は OCI 側の状態を読み、必要に応じて差分を埋め、結果を Kubernetes 側の status に返します。

この流れを覚えておくと、後で READY、SYNCED、status.atProvider を読むときに迷いにくくなります。

なぜ Platform API が必要なのか

Managed Resource をそのまま利用者に渡すこともできます。

ただし、それだけだと利用者は OCI の細かい field、compartment、namespace、IAM、削除方針などを直接意識する必要があります。

Platform API の目的は、ここを整理することです。

たとえば、利用者には以下のような API だけを見せたいかもしれません。

apiVersion: platform.example.org/v1alpha1
kind: AppBucket
metadata:
  name: demo
spec:
  team: payments
  tier: standard
  region: ap-tokyo-1

裏側では、Composition が OCI Bucket、IAM policy、tag、connection details などを作ることができます。

利用者は細かい OCI 部品を意識せず、一つのまとまった要求として扱えます。

この考え方が、Crossplane を単なる Terraform 代替ではなく、Platform API を作る仕組みとして見る理由です。

OCI Provider はこの構造のどこに入るのか

OCI Provider は、Crossplane と OCI API の間に入ります。

Platform API
  |
  v
Crossplane Core
  |
  v
OCI Provider
  |
  v
OCI API
  |
  v
OCI Resource

OCI Provider の Quick Start では、provider-family を使い、provider-oci-objectstorage によって Object Storage Bucket を作る流れが紹介されています。

ただし、この記事の段階では、まだ細かいインストール手順よりも、以下の理解が重要です。

Crossplane Core は抽象 API を扱う
OCI Provider は OCI API を呼ぶ
Managed Resource は OCI リソースの Kubernetes 表現になる
Platform API は利用者に見せる入口になる

この分担が分かると、OCI Provider の構成、認証、Bucket demo に進んだときに、どの YAML が何の責任を持つのかを読みやすくなります。

この段階で覚えておきたいこと

この section では、細かい YAML よりも、次の三点を押さえるのが大事です。

1. Platform Engineering は利用者向け API の設計として見る

2. Crossplane は Kubernetes API を使って control plane を作る framework

3. Provider が Kubernetes の desired state と OCI の実リソースをつなぐ

言い換えると、Crossplane は OCI リソースを直接作るだけの道具ではありません。

Kubernetes API を使って、チーム向けの Platform API と外部クラウドをつなぐための control plane として見ると理解しやすくなります。

まとめ

この記事では、Crossplane と OCI Provider を細かい設定に入る前の入口として整理しました。

ポイントは以下です。

Platform API は、利用者が触る抽象化
Crossplane は、Kubernetes API を拡張する control plane framework
Provider は、外部クラウド API と同期する controller
Managed Resource は、外部リソースの Kubernetes 表現
OCI Provider は、OCI リソースを Kubernetes API から扱うための Provider

次に学ぶべきことは、Crossplane が実際にどのように状態を合わせるかです。

つまり、API Server に保存された desired state が、Provider の reconcile によって OCI 側へどのように反映され、結果が status にどう戻るのかを見ていきます。

参考

Crossplane GitHub
https://github.com/crossplane/crossplane
Oracle Crossplane Provider for OCI GitHub
https://github.com/oracle/crossplane-provider-oci
Crossplane Provider for Oracle Cloud Infrastructure (OCI) 入門
https://qiita.com/engchina/items/3188e3d88665c81d151c
ローカルKubernetesから始める Crossplane と OCI Provider 学習計画
https://qiita.com/engchina/items/59645196f86566b79cd0