Crossplaneで築くプラットフォームエンジニアリング 基盤を支えるリソース抽象化のアプローチ

YAPC::Fukuoka 2025
有働開

1. Last Update 2022.03.16 Crossplaneで築くプラットフォームエンジニアリング 基盤を支えるリソース抽象化のアプローチ YAPC::Fukuoka2025
2. 2 目次 1. 自己紹介 2. Crossplane概要 3. Crossplaneで築くプラットフォームエンジニアリング a. プラットフォームエンジニアリング概要 b. Kubernetes概要 c. Crossplaneによるプラットフォームエンジニアリング 4. Crossplaneの利用手順とその裏側 5. Crossplane 利用の懸念点 6. hacomonoでの事例 7. まとめ
3. section 1 自己紹介
4. 4 自己紹介 有働 開(Kai Udo) • 社歴 ◦ 2020/4 ~ 2024/6 某製造業 ◦ 2024/7 ~ 株式会社hacomono プラットフォーム部所属 • X, GitHub: u-kai • YPAC初参加です！ よろしくお願いいたします！
5. section 2 Crossplane概要
6. 6 Crossplane概要 • CNCFのプロジェクトで先週Graduated Stageに🎉 • Upbound社が提供している商用版も(本日はOSS版の話) • 名前の通り横断的(Cross)なControl planeが実現可能 出典: https://www.crossplane.io/
7. 7 Crossplaneで達成できることの概要 あらゆるリソース構成を Kubernetesの抽象で管理できるように ! プラットフォームエンジニアリングの達成に大きく貢献できる
8. section 3 Crossplaneで築く プラットフォームエンジニアリング
9. section 3.a プラットフォームエンジニアリング概要
10. 10 昨今のソフトウェア開発について CloudNative ManagedService Containerization Microservices IaC CI/CD Observability 高速かつ柔軟にプロダクトを開発 /提供できるようになった！！！！ (うまく扱えれば ) MultiCloud
11. 11 昨今の開発環境における課題 • プロダクトに関係のない複雑性や認知負荷の増大 • セキュリティリスクやコスト増大の可能性 • プロダクト数に比例した運用負荷 • 人材確保 • etc… プラットフォームエンジニアリングによる解決
12. 12 プラットフォームエンジニアリングによる解決 プロダクトチームのやるべきことを減らして開発速度 /品質を向上させる
13. section 3.b Kubernetes概要
14. 14 Kubernetesとは • コンテナオーケストレーションツールとして広く利用されている OSS • CNCF の Graduated stage に属する成熟したプロジェクト • プラットフォームエンジニアリング基盤のスタンダード的な存在
15. 15 Kubernetes がプラットフォームエンジニアリングを実現する基盤として適している理由 多種なリソースを一貫した抽象で管理可能 • コンテナスケジューリング/サービスディスカバリ/ネットワーキング/ストレージ管理/権 限分離/機密情報管理/設定情報管理 etc • 宣言的 API とそれを実現する回復力 Kubernetes の抽象を利用して (ほぼ)全てのリソースを提供 /管理可能 拡張性が高い • Custom Resource Definition(CRD)による独自リソースを定義可能 • Mutating/Validating Admission Webhook によるリクエスト制御 拡張性の高さによるエコシステムの豊富さ などなど...
16. 16 Kubernetes を使ってプラットフォームエンジニアリングを実現する際の考慮ポイント Kubernetes 自体の運用負荷 • 専門チームが頑張るしかない!? イケてる仕組みでも開発者の負荷が高いと意味がない ... 開発者にmanifest を書いてもらう場合... • 開発者に生じる manifest の認知負荷 • ガバナンス担保が難しい • 基盤変更の適用が難しい 他のマネージドサービスと連携する場合... • Kubernetesとの連携が必要 • マネージドサービスの設定/管理が大変 などなど...
17. 17 Kubernetes を使ってプラットフォームエンジニアリングを実現する際の考慮ポイント • Kubernetes 自体の運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest の認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更の適用が難しい • 他のマネージドサービスと連携する場合... ◦ Kubernetesとの連携が難しい ◦ マネージドサービスの設定/管理が大変 イケてる仕組みでも開発者の負荷が高いと意味がない... Crossplane による解決!
18. 18 (再掲)Crossplaneで達成できることの概要 あらゆるリソース構成を Kubernetesの抽象で管理できるように ! プラットフォームエンジニアリングの達成に大きく貢献できる
19. 19 複雑な構成を独自の抽象 (manifest)で提供可能 • 開発者は数行の manifest で必要な全てのリソースを要求可能 • 抽象の裏側で環境差分の吸収/ガバナンス担保/基盤の進化などが可能 manifestをインターフェイスとした Self-Serviceが実現
20. 20 Kubernetesの抽象であらゆるリソースを一括管理可能 • Reconciliation Loopによってあらゆるリソースの回復力が向上 • Kubernetesの抽象に対する一貫した運用が可能
21. 21 Crossplane によるプラットフォームエンジニアリングの実現 ロジックの実装なしに独自プラットフォームを構築可能 • Crossplaneのインストール/設定でSelf-Service基盤を実現 • 本来であれば多くの独自ロジックを開発/運用するなどが必要 Crossplane によって プラットフォームエンジニアリングがさらに加速 Kubernetesの抽象であらゆるリソースを一括管理可能 複雑な構成を独自の抽象 (manifest)で提供可能
22. section 4 Crossplaneの利用手順とその裏側
23. 23 Crossplaneの主要コンポーネント その他:Crossplane RBAC,CompositionRevision,FunctionRevision,DeploymentRuntimeConfig etc… XRの構成リソース生成の定義 Functionを呼び出すような設定 が可能 Composition 外部リソース用のCRDをインストール 外部リソースを管理 AWS/GCP/Azureなど複数存在 Provider 複数コントローラーを稼働 CrossplaneのCRDインストール などなど... Crossplane Core XRの構成リソース等を Coreに responseするgRPCサーバー 複数種類あり Function XRのスキーマ定義 Composite Resource Definition (XRD)
24. 24 題材の紹介 AWS IAM Role を被ることのできる※ KubernetesのDeploymentが展開されるXRを利用可能にして適用するまで ※実際はIRSAやPodIdentityといったソリューションを組み合わせる必要がありますが、割愛しています
25. 25 helmによるCrossplaneのインストール helmを使ってCrossplaneをインストール →コントローラーの起動とCRDのインストールが自動実行
26. 26 Functionのデプロイ manifest を記述して Functionリソースをデプロイ → Function コントローラーが Function image を起動
27. 27 Providerのデプロイ manifestを記述してProviderリソースをデプロイ & 権限設定 → Provider コントローラーが Provider image を起動
28. 28 XRD の定義 apiVersion: apiextensions.crossplane.io/v2 kind: CompositeResourceDefinition metadata: name: accessibledeployments.platform.example.org spec: group: platform.example.org names: kind: AccessibleDeployment plural: accessibledeployments scope: Namespaced versions: - name: v1alpha1 schema: openAPIV3Schema: # OpenAPI形式による定義 type: object properties: spec: type: object … XRDを定義してComposite Resource(XR)のスキーマを指定
29. 29 XRD の適用 定義したXRDをKubernetes に適用 → XRDがXR用のCRDに変換 & XR用のコントローラーが起動
30. 30 Composition の定義と適用 Composition を定義して XR がどのように構築されるのかを指定 - step: deployment-go-templating functionRef: name: function-go-templating input: # Function固有のinputを定義 apiVersion: gotemplating.fn.crossplane.io/v1beta1 kind: GoTemplate source: Inline inline: template: | apiVersion: v1 kind: ServiceAccount metadata: name: {{ $serviceAccountName }} namespace: {{ $namespace }} --- apiVersion: apps/v1 kind: Deployment metadata: name: {{ $appName }} ... apiVersion: apiextensions.crossplane.io/v1 kind: Composition metadata: name: accessibledeployment.platform.example.com spec: compositeTypeRef: apiVersion: platform.example.com/v1alpha1 kind: AccessibleDeployment mode: Pipeline pipeline: ...
31. 31 XR の適用 開発者がmanifestでXRを記述してKubernetesに適用 → XRのリソースが構築 🎉
32. section 5 Crossplaneの懸念点
33. 33 Crossplane の懸念点 • 実装の裏側が複雑で学習コストが高い • Kubernetes が前提かつ、Kubernetes の知識が必要 • Crossplane コンポーネントの運用管理が必要 • 他の IaC ツールと比べてエコシステムが発展途上 • 一度導入すると抜け出しづらい
34. 34 実装の裏側が複雑で学習コストが高い 利用する分にはいいけど。。。裏側の仕組みが複雑。。。💦 動かなくなったらどこが悪いんだ？？ 💦
35. 35 Kubernetes が前提かつ、 Kubernetes の知識が必要 Crossplane は Kubernetes 上で動作し、Kubernetes の拡張を行う • Kubernetes Clusterの構築/運用が必要 • Crossplaneに加えてKubernetesの知識も必要 ◦ CRD,Controller,Reconciliation Loop etc… Terraform などのIaC ツールは CLIベースによる実行がメイン • 実行環境構築/運用の手間が小さい • IaCツールの知識がメイン 組織全体が他のツールに成熟している場合やKubernetesを利用しない場合 オーバースペックかも...
36. 36 Crossplane コンポーネントの運用管理が必要 他IaC ツールはCLIベースのoneshot実行なので楽。。。 複数コンポーネントの運用管理が必要 適切な権限 設定 API RateLimitの考慮 インフラコストの発生 💸 インフラモニタリング バージョン管理 インフラ起因のエラー
37. 37 他の IaC ツールと比べてエコシステムが発展途上 • Terraformのplanのような機能がない • Testツールがない ◦ 商用版には存在する模様(今後OSS版に追加されるかも!?※) • XRの構成リソースをレンダリングする機能はあるが... ◦ 現在の構成との差分がわからない ◦ それが正しいか、稼働するかどうかはわからない 運用管理には独自ツールの作成やマインドチェンジが必要 ※: https://github.com/crossplane/crossplane/issues/6810
38. 38 一度導入すると抜け出しづらい Crossplaneを導入すると提供する抽象(manifest)に強く依存 他ツールへの移行が難しく、移行には莫大な作業が … 一つの抽象で構築するリソースを細分化して部分的な移行に備える 　　　　　　　　　　　　　　　OR 一つの抽象で開発者の要求を満たせるようにする(Crossplaneのメリットを優先) • Crossplaneの魅力と依存のトレードオフをよく検討すること • Crossplaneの利用領域や提供する抽象の責務を考慮する必要あり
39. section 6 hacomono における Crossplane 利用事例
40. 40 hacomonoの現状 hacomonoというWellness業界向けSaaSを提供中
41. 41 hacomonoのこれから 各プロダクトは独立して開発/提供してマイクロサービスの恩恵を受けたい これからはマルチプロダクト戦略を推進予定
42. 42 マルチプロダクト基盤に求められる要件と技術選定 1. 多くの機能をSelf-Service 化して開発者/運用者の負担軽減 2. プロダクト数に比例しない運用負荷 3. 少人数チームによる基盤構築/運用 4. 適切な AWS サービス利用 5. 環境毎/プロダクト毎の分離 6. ガバナンスの担保 プラットフォームエンジニアリング ✖ Kubernetes ✖ Crossplaneを選択
43. 43 Crossplane を使った Kubernetes ベースのマルチプロダクト基盤 多くの価値を構築中!
44. 44 要求の多いリソース構成を抽象化 /提供 プロダクト開発で利用要望の多いリソースをCrossplaneを使って提供中 開発者は数行の manifestを記述するだけで OK
45. 45 抽象の裏側でガバナンスを担保 開発者が触る「数行の抽象（XR）」 の裏側では… • コスト・セキュリティ・冗長性などのベストプラクティスや 組織固有のポリシーなどをComposition内で定義 • タグ付け・命名の自動適用によるプロダクト/環境毎の分離 ◦ 条件付きポリシーの強制適用でプロダクト分離を達成 ◦ プロダクト名や環境名をリソース名に自動付与しバッティングを阻止 プロダクト 開発者は余計なことを考えずに安心して 開発可能
46. 46 GitOps を組み合わせた Self-Service 化 Crossplane✖GitOps • manifest を記述して merge/revert するだけで あらゆるリソースが適用 • Git リポジトリを見れば全リソースの適用状況や変更履歴が把握可能 • 開発者には Git リポジトリへの書き込み権限のみを付与すれば OK 開発者体験 /セキュリティ /監査などが最高 !!
47. 47 AI を活用した XR 開発支援 AIが参照するファイルに指示を与え、自然言語で manifestを生成可能に • XRD の ディレクトリパスを指示 • XRD のプロパティ毎に description を整備 • バリデーションツールを用意し、AI に実行するように指示 manifest記述の負担を大幅に軽減 できる(はず) S3を操作できる コンテナがほしい
48. 48 運用の工夫について 対策を実施し、一部懸念を払拭 学習コストの高さ Kubernetes前提 発展途上な エコシステム コンポーネントの運 用管理 抜け出しづらさ Crossplaneの 理解/ナレッジ共有 ✅ ✅ 独自ツールの作成 ✅ AIを使った XRD/Composition の自動生成 ✅
49. 49 Crossplane/Kubernetes の理解とナレッジ共有 運用にはチーム内で共通認識を持つことが必須 • Crossplane のドキュメント/コードリーディングによる理解 ◦ https://docs.crossplane.io/latest/whats-crossplane/ ◦ internal/controller/apiextensions/definition/reconciler.go ◦ internal/controller/apiextensions/composite/reconciler.go ◦ internal/controller/apiextensions/composite/composition_functions.go • Kubernetes の Controller,CRD,Reconcilation Loop などの基礎理解 • チームで運用できるようにナレッジや決定を共有 ◦ 勉強会 ◦ ADRによるコンテキストや決定の保存
50. 50 独自ツールの作成 Crossplane CLI を利用して独自ツールを作成 • Makefile を使ってXR のレンダリングとバリデーションを実施 ◦ XRD/Composition 開発時に高速にフィードバックを得られる ◦ AI の曖昧さを補完するのにも有効 • XR レンダリングの diff を確認するツールを作成 ◦ terraform plan のように manifest の差分を確認できる ◦ XR の変更やリファクタリング時に適切にレビュー可能 高速かつ正確に XRD/Composition を開発・運用可能に
51. 51 AI による XRD/Composition 自動生成 AI によってそこそこの精度で XRD/Composition が生成可能 → 複雑なXRD/Compositionを楽に開発できる Tips • 最新のドキュメントや GitHub リポジトリの URL を参照させる • 独自ツールと組み合わせて簡単な誤りを検出させる • 仕組みの理解無しに AI を利用するとハマる可能性アリ • CrossplaneやFunctionの仕組みを理解して利用するのがおすすめ
52. 52 今後の展望 • Crossplane 適用範囲の拡大 ◦ GitHub リポジトリ ◦ Monitoring 設定 ◦ ニーズの多いリソースの抽象化 • 抽象化 アプローチの改善 ◦ 開発者からのフィードバックを元に抽象を改善 ◦ 同じ抽象で local 開発環境やマルチクラウド対応も検討 • マルチプロダクト基盤の効果測定 ◦ 開発者体験/開発速度 ◦ 運用体験/工数 • Kubernetesクラスターの最適化検討
53. section 7 まとめ
54. 54 まとめ • CrossplaneはKubernetesの抽象からあらゆるリソースを管理できる ようになるOSSのツール • Crossplaneを利用することで、Kubernetesを利用した プラットフォームエンジニアリングをさらに推進できる ようになる • Crossplaneは強力な抽象化を実現するために複雑な仕組みが裏で動いている • Crossplaneは強力な分、考慮するべきポイント もある • hacomonoでは、マルチプロダクト展開に向けて Crossplaneを用いた基盤を構築し、開発者への価値提供と運用を進行中
55. https://www.hacomono.jp/
56. section 8 おまけ
57. 57 Crossplaneの今後の展望 • 今年の8月からv2がGA,11月6日からCNCF Graduated stageへ🎉 ◦ v2からNamespace ScopeなXRも定義可能に • Upbound版で提供しているツールがOSS版に移植されるかも ◦ コントリビュートしていきます！
58. 58 対抗馬として今後現れるかもしれない kro 出典: https://kro.run/docs/overview/ Crossplaneのような機能を提供する kro(Kubernetes Resource Orchestrator)がkubernetes-sigsで開発されている
59. 59 kroについて • kubernetes-sigsで開発されているOSSで、まだ開発段階 • できることはCrossplaneと似ていて、カスタムリソースを簡単に構築でき るようになる • Crossplane自体のコードが8万行以上+ProviderやFunctionのコードが 存在するが、kroは3万行ほど • kroはCrossplaneに比べて責務が小さい
60. 60 kroの責務や挙動について • kroはResourceGraphDefinitionというカスタムリソースを提供 • RGDにカスタムリソースの定義+作成されるリソース+どのように作成す るかを記述 • kroの責務はRGDに沿ってCRDを適用し、カスタムリソースのコントロー ラーを作成すること • カスタムリソースのコントローラーはRGDに沿ってmanifestを展開して Apply • 「ApplyされたmanifestがK8sで利用可能かどうか」は別の手段 (CrossplaneではProvider)で担保する必要がある • Crossplaneは手段(Provider)の管理も責務の一つ