CrossplaneによるCloud Native Control Plane

Oracle Cloud Hangout Café Season 11 #5

Transcript

1. XIN ZHANG 日本オラクル June 10, 2026 Crossplaneによる Cloud Native Control Plane OCI リソースを Kubernetes API から Platform API へつなぐ実践ガイド
2. 今日のゴールは、Crossplane の使いどころを判断できる状態にする 判断軸、デモ観点、導入観点を持ち帰る。 2 Copyright © 2026, Oracle and/or its affiliates Why 必要になる場面 Platform API が必要にな る境界 How 動作原理 Kubernetes API と Reconcile OCI 落とし込み ProviderConfig（認証設 定）と Bucket Decide 導入判断 向くケース / 向かないケ ース
3. 今日の流れは、判断しやすい順番で進む 3 Copyright © 2026, Oracle and/or its affiliates 1 2 3 4 5 6 7 導入：Platform API と Crossplane 概要 動作：API Server、Reconcile、status 抽象 API：XRD、XR、Composition Composition 実装：Patch & Transform、Functions OCI Provider：構成・認証、Bucket demo 既存 OCI：Observe-only、Platform API、GitOps 連携 判断：Terraform 分担、責任境界、Lifecycle、Q&A
4. XIN ZHANG 4 Copyright © 2026, Oracle and/or its affiliates 仕事で特に関心があるテーマ： • Cloud Native • RAG/NL2SQL/Agents • LLM Finetuning • など 趣味： • コーディング • スポーツ（バドミントンなど） • 日本ドラマとアニメ • 娘と会話すること
5. 導入： Platform API とCrossplane 概要 ここまで：ゴールと全体像 ここから：Platform API と Crossplane 概要
6. Platform Engineering は、利用者向け API を作る話として捉える Internal Developer Platform は、クラウドの細部を隠しながら標準化された利用面を提供する。 6 Copyright © 2026, Oracle and/or its affiliates 開発チーム 必要な能力を API として要求する Platform API 標準・権限・命名を抽象化する Control Plane 宣言を観察し外部状態へ反映する OCI 実際のクラウドリソースを保持する
7. Crossplaneの概要 公式定義、核心理念、採用理由を一枚で押さえる。 7 Copyright © 2026, Oracle and/or its affiliates i 公式定義 Crossplaneは、コードを書かずにクラウドネイティブなコント ロールプレーンを構築するためのフレームワークです。 高度に拡張可能なバックエンドと、高度に設定可能なフロント エンドを備え、どこで実行されてもアプリケーションやインフ ラストラクチャをオーケストレーションできるコントロールプ レーンの構築を可能にします。 3 核心理念 Kubernetes as a Universal Control Plane Kubernetesをユニバーサルコントロールプレーンとして使用 Declarative Infrastructure Management 宣言的なインフラ管理の実現 Continuous Reconciliation 継続的リコンシリエーションによる状態の自動維持 ? なぜCrossplaneなのか? 1 統一された管理インターフェース クラウド、オンプレ、SaaSを一つのAPI（Kubernetes）で管理 2 継続的な状態監視 設定ドリフトを自動検出・修復（Self-healing） 3 カスタム抽象化の作成 組織固有のインフラ抽象化（CompositeResourceDefinition (XRD)） を簡単に定義 4 既存エコシステムの活用 RBAC、Argo CD などの GitOps ツール、モニタリングを活用 C CNCF Graduated Project 2025年10月にGraduated maturity levelへ移行したCNCFプロジェクト
8. Crossplaneアーキテクチャ概観 8 Copyright © 2026, Oracle and/or its affiliates アーキテクチャ図 ユーザー / 開発者 kubectl / Argo CD など Kubernetes API Server etcd, CRD, Validation, RBAC Crossplane Core Composite / XRD / XRC Controllers Providers OCI / AWS / GCP / Azure Providers 外部クラウドサービス OCI, AWS, GCP, Azure, etc.
9. Crossplane のアーキテクチャは、Kubernetes API Server を中心に読む 9 Copyright © 2026, Oracle and/or its affiliates ユーザー / 開発者 kubectl / Argo CD などが宣言を apply する Kubernetes API Server CRD、Validation、RBAC、etcd で望ましい状態を保持する Crossplane Core + Providers Core が Composite Resource (XR) / CompositeResourceDefinition (XRD) / Composition を扱い、Provider が Managed Resource (MR) と外部 API を同期する 外部クラウドサービス OCI / AWS / GCP / Azure などの実リソースへ反映する
10. Section 1 まとめ：導入：Platform API と Crossplane 概要 10 Copyright © 2026, Oracle and/or its affiliates 1 2 3 Platform Engineering は利用者向け API の設計 Kubernetes API で control plane を作る Provider が desired state を OCI と同期
11. 動作： API Server、Reconcile、status ここまで：Platform API と全体像 ここから：API Server、Reconcile、status
12. Observe / Diff / Act / Report が Crossplane の動作を決める 望ましい状態と外部状態の差分を コントローラー が継続的に埋め、結果を status に返す。 12 Copyright © 2026, Oracle and/or its affiliates Observe OCI の現状を 読む Diff spec と実際 の状態を比べ る Act 作成・更新・ 削除を実行 Report status と Conditions に反映 Reconcile
13. Desired / Observed / Actual を分けると status の意味が読める YAML、Provider の観察、OCI の実体を混同しないことがデモ理解の近道になる。 13 Copyright © 2026, Oracle and/or its affiliates 状態 どこにあるか 読むポイント Desired Kubernetes spec 利用者が望む状態。spec.forProvider に入る Observed status.atProvider Provider が OCI API から読んだ観察結果 Actual OCI resource Bucket / Vault などクラウド側に実在するもの Gap Conditions / Events 差分や失敗理由が READY / SYNCED に出る
14. Provider は、外部 API と連携するためのプラグインとして動く Provider は CRD、コントローラー、ProviderConfig（認証設定） を追加し、外部リソースの lifecycle を管理する。 Provider は外部 API と連携するためのプラグイン。 • CRDs: Managed Resource (MR) の スキーマを Kubernetes API に追加する。 • Controllers: resource の lifecycle と 状態合わせ を管理する 。 • ProviderConfig（認証設定）: 認証設定と接続境界を与える。 14 Copyright © 2026, Oracle and/or its affiliates インストール Provider パッケージ を導入 CRD 作成 Managed Resource (MR) 用 スキーマを追加 Controller 起動 状態合わせ loop を開始 利用可能 認証設定と API 同期が可能
15. ProviderConfig（認証設定）は、リソースではなく認証と接続の境界を表す 同じ Bucket 定義でも、参照する ProviderConfig（認証設定） によって使う資格情報と責任境界が変わる。 ProviderConfig（認証設定）はクラウド資格情報の入口。 • namespaced ProviderConfig / ClusterProviderConfig の置き 場所も運用設計になる。 15 Copyright © 2026, Oracle and/or its affiliates Managed Resource (MR) - Bucket YAML - 認証参照 認証設定 - 資格情報 - Region / Principal 参照 OCI API
16. Managed Resource (MR) は、外部リソースを Kubernetes オブジェクトとして扱う入口で ある Managed Resource (MR) は Provider が追加する CRD で、spec / status / Conditions から外部状態を読む。 Provider 内の外部サービスを表現する Kubernetes リソース。 • Desired は `spec.forProvider`、Observed は `status.atProvider` と Conditions で読む。 • 外部リソースは OCI / AWS / GCP などクラウド側の実体。 16 Copyright © 2026, Oracle and/or its affiliates Pending 作成要求を受ける Creating Provider が外部 API を呼ぶ Ready 利用可能な状態 Deleting 削除と finalizer 処理
17. READY / SYNCED は、どこで詰まったかを切り分ける信号として読む 17 Copyright © 2026, Oracle and/or its affiliates 見る場所 正常時の意味 異常時に次に見る場所 SYNCED OCI API との 状態合わせ が通った ProviderConfig（認証設定） / Secret / IAM ポ リシー READY 外部リソースが利用可能と判断された OCI 側の状態 / compartment / lifecycle status.atProvider OCI から返った実体情報が入る external-name / namespace / OCID / region Events / Reason 直近の失敗理由を読む入口 kubectl describe / Provider コントローラー log
18. Section 2 まとめ：動作：API Server、Reconcile、status 18 Copyright © 2026, Oracle and/or its affiliates 1 2 3 Reconcile は継続的な状態合わせ READY / SYNCED / status は原因を見る信号 ProviderConfig と MR で認証境界を読む
19. 抽象 API： XRD、XR、Composition ここまで：状態合わせと Managed Resource ここから：XRD、XR、Composition
20. 主要コンポーネントの役割と関係性を一枚で把握する 20 Copyright © 2026, Oracle and/or its affiliates P Providers OCI など外部 API と同期するコントローラー / CRD pkg.crossplane.io/v1 MR Managed Resources (MR) OCI Bucket など外部リソースの Kubernetes 表現 *.oci.upbound.io XR Composite Resources (XR) 利用者向けの高レベル抽象化 example.org/v1alpha1 C Compositions Composite Resource (XR) から Managed Resource (MR) をどう作るかを定義する テ ンプレート apiextensions.crossplane.io/v1 XRC Composite Resource Claims (XRC) namespace スコープの Composite Resource (XR) 要求。利用者の入口 Namespaced スコープ XRD CompositeResourceDefinitions (XRD) CompositeResourceDefinition (XRD)。カス タム API スキーマ apiextensions.crossplane.io/v2 コンポーネント間の関係性 Composite Resource Claim (XRC) namespace スコープ Composite Resource (XR) クラスター スコープ Composition テンプレート Managed Resources (MR) 外部リソース表現 External Resources 実際のクラウドリソース OCI を先頭に据えて外部 API 同期を読む
21. CompositeResourceDefinition (XRD) は、利用者向け Composite Resource (XR) API の型 とスキーマを定義する CompositeResourceDefinition (XRD) を適用すると、Crossplane は新しい Composite Resource (XR) 型を登録する。 CompositeResourceDefinition (XRD) は、Composite Resource (XR) のスキーマを定義し、API エンドポイントを作成する。 • `group` と `names` は immutable。変更する時は削除・再 作成が必要。 • Crossplane v2 API の CompositeResourceDefinition (XRD) スコープは `Namespaced` / `Cluster`。新規設計では Namespaced を優先する。 21 Copyright © 2026, Oracle and/or its affiliates group API グループを固定 names kind / 複数形 を固定 versions OpenAPI v3 スキーマを定義 スコープ v2: Namespaced / Cluster
22. Composite Resource (XR) は、複数の Kubernetes リソースを一つの利用者 API に束ねる XR は XRD が定義した API で、Composition により複数リソースへ展開される。 Composite Resource (XR) は、複数リソースを一つの Kubernetes オブジェクトとして扱う。 • 利用者は クラウドの細部ではなく、プラットフォームチーム が定義した API に要求を書く。 • CompositeResourceDefinition (XRD) は API の型、 Composition はその要求をどう実装するかを担う。 22 Copyright © 2026, Oracle and/or its affiliates CompositeResourceDefinition (XRD) スキーマと API エンドポイントを定義 Composite Resource (XR) 利用者が作成するカスタム API Composition 実装テンプレートを選ぶ Composed Resources Managed Resource (MR) / Secret / 任意の K8s リソ ース
23. Composition は、Composite Resource (XR) から Managed Resource (MR) 群を作る実装 テンプレートである Composite Resource (XR) の入力を受け取り、必要な Managed Resource (MR) をどのように作るかを Composition が決め る。 Composition は、複数の Kubernetes リソースを一つの Composite Resource (XR) の実装として束ねるテンプレート。 • `compositeTypeRef` は、この Composition を使える Composite Resource (XR) の apiVersion / kind を指定する。 • 現在の Crossplane では、Composition は Pipeline mode で Function step を並べる。desired resources が適用対象にな る。 23 Copyright © 2026, Oracle and/or its affiliates compositeTypeRef 対象 Composite Resource (XR) の apiVersion / kind mode: パイプライン Function（関数） pipeline を使う 関数 step Patch / Transform などで生成 desired リソース群 Crossplane が適用する resource 群
24. CompositeResourceDefinition (XRD)、Composite Resource (XR)、Composition は、ク ラウド部品を Platform API に変える中核である XRD が API 型、XR が要求、Composition が実装への写像を担う。 24 Copyright © 2026, Oracle and/or its affiliates i 基本概念 CompositeResourceDefinition (XRD)、Composite Resource (XR)、Composition は、利用者 API を Managed Resource (MR) 群へ 変換するための三層である。 CompositeResourceDefinition (XRD) が API 定義、Composite Resource (XR) が利用者の要求、Composition が実装への写像を担う 。 責任の分担 • CompositeResourceDefinition (XRD): Composite Resource (XR) の API 型とスキーマを定義 • Composite Resource (XR): 利用者が作る抽象リソース • Composition: Composite Resource (XR) から Managed Resource (MR) 群を作る レシピ • Managed Resource (MR): OCI Bucket などの外部実体へ展開
25. 利用者入口は、抽象 API を誰に見せるかを決める設計点である 次のページでは、その入口を namespace、RBAC、platform-owned API に分解して見る。 25 Copyright © 2026, Oracle and/or its affiliates 入口 誰が触るか 設計で見ること Namespaced Composite Resource (XR) 利用チーム / GitOps namespace 境界と API スキーマ Composite Resource Claim (XRC) v1 互換や既存設計の利用者 Composite Resource (XR) との対応と resourceRef CompositeResourceDefinition (XRD) プラットフォームチーム スコープ、version、validation Composition プラットフォームチーム 標準、ポリシー、Managed Resource (MR) 生成
26. namespace と RBAC は、利用者入口をチーム境界に落とす具体策である Composite Resource Claim (XRC) / namespaced Composite Resource (XR) を、platform-owned API と provider boundary から分けて読む。 26 Copyright © 2026, Oracle and/or its affiliates Team namespace Composite Resource Claim (XRC) または namespace スコープの Composite Resource (XR) を作成・参照 RBAC 入口 resource への最小権限を付与 Platform-owned API CompositeResourceDefinition (XRD) / Composition / ポリシー を管理 Provider boundary ProviderConfig（認証設定） / Secret / OCI IAM を保護
27. Section 3 まとめ：抽象 API：XRD、XR、Composition 27 Copyright © 2026, Oracle and/or its affiliates 1 2 3 XRD は API 型とスキーマを定義 XR は利用者の要求を表す Composition は実装へのレシピ
28. Composition 実装： Patch & Transform、Functions ここまで：XRD、XR、Composition の基本 ここから：Patch & Transform、Functions
29. Patch / Transform は Composite Resource (XR) の少ない入力を Managed Resource (MR) の具体値へ写す道具である 29 Copyright © 2026, Oracle and/or its affiliates Composite Resource (XR) spec team / tier / region Patch field path で値を渡す Transform map / format / combine Managed Resource (MR) spec / status Bucket / ポリシー / outputs
30. Functions は Patch & Transform を巨大な DSL にしないための逃がし先である 条件分岐、繰り返し、多段合成が増える場面では、pipeline に処理を分ける。 P&T は単純な写像に強い。 • 複雑な logic は pipeline step として外に出すと、core を肥大 化させにくい。 30 Copyright © 2026, Oracle and/or its affiliates P&T が得意 - field path で値を渡す - map / format / combine で値を整える - スキーマ 化しやすく validation しやすい Functions を考える兆候 - conditionals が増える - iteration / fan-out が必 要になる - core API の拡張だけでは 重くなる
31. Composition Functions と Pipeline mode は Composition を処理パイプラインとして拡張 する 31 Copyright © 2026, Oracle and/or its affiliates Composite Resource (XR) 入力 XRC / spec desired resources Function（関数） 観察済み / 望ましい状態 リソース群 パイプライン 複数の関数 生成された望ましい状態 Managed Resource (MR) 状態合わせ リソース群 OCI 側の状態
32. 多リソース構成では Reference / Selector / Connection Details まで設計する Bucket 単体を超えると、Managed Resource (MR) 同士の参照、既存リソースの識別、利用者への出力が重要になる。 32 Copyright © 2026, Oracle and/or its affiliates 設計対象 何を解決するか 見るポイント Reference 明示的な resource 参照 名前と依存関係が読めるか Selector label で参照先を選ぶ 複数候補を誤選択しないか External name 既存 OCI 実体との対応 取り込み時の識別子が合うか Connection Details 接続先 / credential の受け渡し 必要な secret key だけ出すか
33. Section 4 まとめ：Composition 実装：Patch & Transform、Functions 33 Copyright © 2026, Oracle and/or its affiliates 1 2 3 Patch & Transform は単純な写像に強い Functions は複雑な生成ロジックを分離 v2 では namespace と Functions を先に確認
34. OCI Provider： 構成・認証、Bucket demo ここまで：Composition 実装 ここから：構成・認証、Bucket demo
35. この section は、Bucket を作る一周で OCI Provider を理解する 何を apply し、どこで READY / SYNCED を見るかに集中する。 35 Copyright © 2026, Oracle and/or its affiliates 1 Core Crossplane 2 Provider family + service 3 Secret OCI credentials 4 Config ProviderConfig 5 Bucket Managed Resource 6 Observe status / OCI 覚える順番 install → 認証 → Bucket YAML → READY/SYNCED → OCI Console
36. OCI Provider は family を先に入れ、Object Storage を後から入れる apiVersion: pkg.crossplane.io/v1 kind: Provider metadata: name: oracle-provider-family-oci spec: package: ghcr.io/oracle/provider-family-oci:<tag> --- kind: Provider metadata: name: provider-oci-objectstorage spec: package: ghcr.io/oracle/provider-oci-objectstorage:<tag> 順番が大事 1. family provider 2. service provider sub-provider 先行は依存関係のずれを 生みやすい 36 Copyright © 2026, Oracle and/or its affiliates
37. Provider が HEALTHY になるまで、次の YAML へ進まない command kubectl get providers family provider oracle-provider-family-oci INSTALLED=True HEALTHY=True service provider provider-oci-objectstorage INSTALLED=True HEALTHY=True 次へ進む条件 両方の Provider が HEALTHY=True になってから、ProviderConfig と Bucket YAML へ進む 37 Copyright © 2026, Oracle and/or its affiliates
38. 認証情報は Secret に閉じ込め、ProviderConfig から参照する API Key demo では、tenancy、user、key、fingerprint、region を credentials にまとめる。 38 Copyright © 2026, Oracle and/or its affiliates kubectl create secret generic oci-creds ¥ --namespace=crossplane-system ¥ --from-literal=credentials='{ "tenancy_ocid": "...", "user_ocid": "...", "private_key": "-----BEGIN...¥¥n", "fingerprint": "...", "region": "...", "auth": "ApiKey" }' 初学者の注意点 • Secret は crossplane-system に置く • private_key の改行を崩さない • IAM policy は OCI 側で別途必要
39. ProviderConfig は「どの資格情報で OCI API を呼ぶか」を決める legacy *.oci.upbound.io ProviderConfig.oci.upbound.io cluster-scoped resource の入口 modern default *.oci.m.upbound.io ClusterProviderConfig.oci.m.upbound.io namespaced Managed Resource の既定 namespace isolation ProviderConfig.oci.m.upbound.io Secret も namespace local に置く team ごとの認証分離に使う 39 Copyright © 2026, Oracle and/or its affiliates
40. Bucket YAML は apiVersion、forProvider、providerConfigRef の三点で読む 最初は Object Storage の最小項目だけに絞る。 40 Copyright © 2026, Oracle and/or its affiliates apiVersion: objectstorage.oci.m.upbound.io/v1alpha1 kind: Bucket metadata: name: bucket1 namespace: namespace1 spec: forProvider: compartmentId: <COMPARTMENT_OCID> name: bucket1 namespace: <OBJECTSTORAGE_NAMESPACE> providerConfigRef: kind: ProviderConfig name: default 三点だけ読む 1. apiVersion / kind 2. spec.forProvider 3. providerConfigRef 公式 example は selector を使う場合もあ る
41. apply 後の動きは、Bucket YAML が OCI API 呼び出しに変わること kubectl apply は入口で、実際の作成は Provider の reconcile が行う。 41 Copyright © 2026, Oracle and/or its affiliates YAML apply Bucket spec → API Server CRD / etcd → Provider reconcile → OCI API Bucket 作成 → status 観察結果 覚えること apply は開始点。READY / SYNCED は Provider が OCI API と状態合わせした結果として読む。
42. 成功判定は READY / SYNCED / EXTERNAL-NAME の三点 command kubectl get managed --all-namespaces 出力で見る列 NAME / READY / SYNCED / EXTERNAL-NAME を横に見て、状態の詰まりを切り分ける 成功例 Bucket が READY=True / SYNCED=True になり、EXTERNAL-NAME に OCI 側の名前が入る 次に見る場所 READY=False、SYNCED=False、空欄の場合は kubectl describe で conditions と event を確認する 42 Copyright © 2026, Oracle and/or its affiliates
43. 失敗時は describe で ProviderConfig 参照エラーまで読む kubectl describe bucket... bucket1 Status: Conditions: - Type: Synced Status: False Reason: ReconcileError Message: cannot get referenced ProviderConfig: ProviderConfig.oci.upbound.io "default" not found Events: Warning CannotConnectToProvider ... ここで分かること • Bucket spec の問題か • ProviderConfig 参照の問題か • Secret / IAM に進むべきか 43 Copyright © 2026, Oracle and/or its affiliates
44. OCI Console では Bucket 名だけでなく namespace と compartment を合わせる Kubernetes 名、external-name、OCI の配置先を対応づける。 44 Copyright © 2026, Oracle and/or its affiliates Kubernetes metadata.name bucket1 kubectl で見る名前 Managed Resource spec.forProvider name / namespace / compartmentId OCI API へ渡す値 EXTERNAL-NAME n/<namespace>/b/<bucket> Kubernetes と OCI の対応 OCI Console Bucket name Object Storage namespace compartment / region
45. Demo：Bucket 作成を録画で一周する ここでは説明を止めて、apply から OCI Console 確認までを実際に見る。 45 Copyright © 2026, Oracle and/or its affiliates 録画をここに配置 kubectl apply → READY / SYNCED → OCI Console 録画で見せる順番 1. Provider が HEALTHY 2. Secret / ProviderConfig 3. Bucket apply 4. READY / SYNCED 5. OCI Console
46. デモの締めは READY / SYNCED と OCI Console の対応を確認する # 1. Kubernetes 側の状態を確認 kubectl get managed --all-namespaces kubectl describe bucket... bucket1 # 2. OCI 側の実体を確認 OCI Console で bucket name を確認 namespace / compartment を確認 status.atProvider と対応づける 覚える順番 Bucket / MR → READY / SYNCED → status.atProvider → OCI Console 46 Copyright © 2026, Oracle and/or its affiliates
47. Section 5 まとめ：OCI Provider：構成・認証、Bucket demo 47 Copyright © 2026, Oracle and/or its affiliates 1 install は family → service provider → HEALTHY 2 認証は Secret → ProviderConfig → providerConfigRef 3 demo は Bucket YAML → READY/SYNCED → OCI Console
48. 既存 OCI： Observe-only、Platform API、 GitOps 連携 ここまで：OCI Provider の導入と demo ここから：Observe-only、Platform API、GitOps 連携
49. Observe-only の全体像は、既存 OCI を壊さず Kubernetes に観察値を載せることにある ここでは作成・更新・削除ではなく、既存実体と Kubernetes 状態の対応づけを先に見る。 49 Copyright © 2026, Oracle and/or its affiliates 既存OCI K8s状態 観察
50. managementPolicies は、Observe-only の操作範囲を明示するスイッチである Observe / Create / Update / Delete / LateInitialize を分けると、所有権移行のリスクを説明しやすい。 50 Copyright © 2026, Oracle and/or its affiliates i 定義 managementPolicies の Observe は、Crossplane が外部状態を読むだけに操作範囲を絞る宣言である。 既存リソースを壊さず Kubernetes 側に載せ、所有権を整理してから管理へ進める。 扱う操作を分ける • Observe: 外部状態を読む • Create / Update: 差分を埋める • Delete: 外部削除まで扱う • LateInitialize: 観察値で spec を補完
51. external-name annotation は、Kubernetes 名と OCI 実体名をつなぐ鍵である Observe-only では、既存 Bucket を指すために外部名の扱いが特に重要になる。 metadata.name は Kubernetes 側の名前。 • external-name は外部リソース識別子として扱う。 51 Copyright © 2026, Oracle and/or its affiliates Kubernetes - K8s 名 - 外部名 OCI - existing bucket - namespace 外部名 status
52. 所有権を曖昧にしたまま管理へ移ると、削除と変更の責任が衝突する Observe から管理へ進む前に、誰が変更し、誰が削除するかを合意する。 52 Copyright © 2026, Oracle and/or its affiliates Observe から開始 • 既存運用が強い • 状態だけ共有 段階移行 • 変更責任を整理 • 権限を限定 新規のみ管理 • 影響を限定 • 標準化しやすい 完全管理 • 削除まで所有 • ガードレール必須 Crossplane の操作範囲 既存運用の依存度
53. Platform API 設計：Bucket ではなく、チームが必要とする保存能力として切り出す このページでは、利用者から隠す OCI 部品と標準化する実装要素を整理する。 53 Copyright © 2026, Oracle and/or its affiliates Bucket Object Storage Policy IAM 境界 Naming 命名規約 Compartment 配置先 Outputs 接続情報 TeamStorage Platform API
54. GitOps 連携では、Argo CD が同期し Crossplane が reconcile する 54 Copyright © 2026, Oracle and/or its affiliates Pull request YAML change review Git merge approved desired state Sync Argo CD Kubernetes resources Reconcile Crossplane OCI 側の状態
55. Section 6 まとめ：既存 OCI：Observe-only、Platform API、GitOps 連携 55 Copyright © 2026, Oracle and/or its affiliates 1 2 3 Observe-only は既存 OCI を壊さず観察 managementPolicies は所有権移行の安全装置 AppBucket は利用者判断だけを残す
56. 判断： Terraform 分担、責任境界、 Lifecycle、Q&A ここまで：Platform API 化 ここから：Terraform 分担、責任境界、Lifecycle、Q&A
57. Terraform と Crossplane は、変更の時間軸が根本的に違う Terraform は plan / apply の実行単位、Crossplane は コントローラー による継続 状態合わせ が中心になる。 比較は優劣ではなく時間軸。 • 一回の変更か、継続する制 御面かを分ける。 57 Copyright © 2026, Oracle and/or its affiliates Terraform Crossplane
58. Crossplane OCI Provider は、チーム向け API と GitOps 連携を重視する場面に向く 単発構築、少数リソース、Kubernetes 運用がない環境では過剰になることがある。 58 Copyright © 2026, Oracle and/or its affiliates 向いているケース - Kubernetes と GitOps ツールを運用の中心にしている - 共通 API と標準設定をチームに配りたい - 既存リソースの観察から段階移行したい 向きにくいケース - 単発作成だけが目的 - Kubernetes control plane を運用したくない - Provider 対応範囲が要件を満たさない
59. 責任境界 1/2：namespace 分離は認証情報と利用者リソースをチーム境界に合わせる Provider は共通でも、ProviderConfig、Secret、利用者 API はチーム責任に合わせて分けて読む。 59 Copyright © 2026, Oracle and/or its affiliates namespace 置くもの 責任境界 team-a ProviderConfig（認証設定）: team-a-oci / Secret / Bucket or Composite Resource Claim (XRC) team-a の認証と要求 team-b ProviderConfig（認証設定）: team-b-oci / Secret / Bucket or Composite Resource Claim (XRC) team-b の認証と要求 platform Provider / CompositeResourceDefinition (XRD) / Composition / 共通ポリシー 標準 API と実装を管理 OCI IAM compartment ポリシー / dynamic group 各チームに必要な最小権限
60. 責任境界 2/2：RBAC、Secret、ProviderConfig は権限を分けるために設計する Secret を読める人、Composite Resource (XR) を作れる人、ProviderConfig を触れる人を分ける。 Secret を読める人と API を使う人を分ける。 • ProviderConfig（認証設定） の変更権限は広げすぎない。 60 Copyright © 2026, Oracle and/or its affiliates 利用者 namespace Composite Resource (XR) / claim を作成 Platform namespace Compositionと ポリシー を管理 Provider namespace ProviderConfig（認証設定）と Secret を保護 OCI IAM compartment ごとに最小権限
61. Lifecycle ownership：削除順序と責任境界を先に決める Provider を最後に外し、誰が消すか・誰が確認するかを決める。 Provider は controller でもある。 ・先に消すと deletion / 状態合わせが止まる可能性がある。 ・作成前に、承認・利用・削除・確認の責任者を決める。 61 Copyright © 2026, Oracle and/or its affiliates Managed Resource (MR) を棚卸し finalizer と owner を確認 削除方針を決定 外部を残すか消すか conditions / 残存を確認 利用者と責任境界を見る Provider を最後に削除 package は最後に外す
62. 全体まとめ：OCI リソースを Platform API として渡す 62 Copyright © 2026, Oracle and/or its affiliates Platform API チームが使う抽象化 Composition 標準と実装を接続 Managed Resources (MR) OCI リソースを宣言 ProviderConfig（認証設定） 認証と責任境界
63. 最後は、Platform API 化すべきかを四つの観点で判断する 継続的な状態合わせ、責任境界、抽象化、運用との相性がそろうかを見る。 63 Copyright © 2026, Oracle and/or its affiliates Reconcile 継続制御 desired state と外部観察 Boundary 認証境界 ProviderConfig（認証設定） / IAM Abstraction Platform API CompositeResourceDefinition (XRD) / Composition Fit 導入判断 過剰導入を避ける
64. ありがとうございました Q&A Crossplane と OCI Provider を、Platform API の設計材料として議論しましょう。 Copyright © 2026, Oracle and/or its affiliates 64