KubeCon NA 2018に先立って，Kubernetes用のRookストレージオーケストレータを開発したUpboundがCrossplaneをリリースした。"クラウドコンピューティングのユニバーサルAPI"の提供を目指す，オープンソースのマルチクラウドコントロールプレーンだ。Crossplaneは，Kuberenetesおよび既存のクラウドベースのマネージド・サービス上で，ワークロードとリソースを抽象化して公開することにより，クラウドプロバイダ間の高度なワークロードポータビリティの実現を目指している。
Upbound開発チームのBassam Tabbara，Illya Chekrygin，Jared Watts各氏の執筆による，総合的な"Crossplane紹介"資料では，クラウドコンピューティングモデルは広く普及はしたものの，"いまだ少数のクラウドプロバイダのコントロール下にある"，と論じている。InfoQで以前に報じたように、筆者らは、"これらクラウドプロバイダ自身がオープンソーステクノロジのヘビーユーザであるにも関わらず、クラウドコンピューティングは圧倒的にプロプライエタリでクローズソースのまま"である，とも述べている。そのため、さまざまなAPIやSDKを持った複数のクラウド上でアプリケーションを運用するには、膨大なエンジニアリング作業が必要なのだ。
資料では、失敗を重ねてきたマルチクラウドAPIの均質化と統合の試みには，しかしながら例外がある、としている。それが"ワークロードのポータビリティを常に重視し、コンテナとそれに関連するネットワークやストレージのための，可搬性のある抽象化セットを定義"したKubernetesだ。最近のKubernetesコミュニティでは、フレームワークの拡張ポイントの提供に注目が集まっている。Custom Resource Definitions(CRDs)や、デプロイや運用上のメンテナンスをサポートするオペレータの開発などがその例だ。しかし、これは同時に、企業が独自にデータストアやミドルウェアのインスタンスを運用しなければならない、という意味でもある。さらにKubernetesは、クラウドで運用されているワークロードのごく一部を占めているに過ぎないのだ。
UpboundはCrossplaneを、"既存のマネージドサービスやクラウドサービスの上に配置された、新たなポータビリティ層"である、と紹介している。Crossplaneは、同プロジェクトの宣言型リソース管理アーキテクチャを基盤として、Kubernetesが提供するこれらの上にワークロードとリソースの抽象化を導入する。Crossplaneでは，無修正のKubernetes APIサーバ(kube-apiserver)とetcdに加えて、いくつかのコアコントローラを使用している。資料では、Crossplaneは既存のKubernetesクラスタにまったく手を加えることなく、その上で直接実行可能である、とされている。現時点でサポートされるクラウドサーバは、Google Cloud Platform、Microsoft Azure、Amazon Web Servicesである。
Kubernetesのリソース定義に慣れていれば、Crossplaneのワークロード定義は難しくはないだろう。さらに(最初に実行するクラウド固有の環境設定以外の)例として、Kubernetesの’kubectl' CLIツールによるワークロードのデプロイ方法が紹介されている。以下のYAML定義例はCrossplaneの資料から引用したもので、MySQLの"依存リソース"とWordPress "ワークロード"からの抜粋を示している。
## MySQL Database Instance
apiVersion: storage.crossplane.io/v1alpha1
kind: MySQLInstance
metadata:
name: demo
namespace: default
spec:
classReference:
name: standard-mysql
namespace: crossplane-system
engineVersion: "5.7"
## WordPress workload
apiVersion: compute.crossplane.io/v1alpha1
kind: Workload
metadata:
name: demo
namespace: default
spec:
resources:
- name: demo
secretName: demo
targetCluster:
name: demo-gke-cluster
namespace: crossplane-system
targetDeployment:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: wordpress
labels:
app: wordpress
spec:
selector:
app: wordpress
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
spec:
containers:
- name: wordpress
image: wordpress:4.6.1-apache
[...]
Crossplaneの資料では，明確な類似点を認めながらも、Kubernetesと混同しないように注意を促している。この2つは異なるレイヤで動作し、異なる問題を解決するものなのだ。
Kubernetesはコンテナオーケストレータで、コンテナ(pod)とそれらがコンシュームするリソース(ストレージボリュームやネットワーク)を、一連のノードにわたって管理する責務を持っています。Crossplaneはマルチクラウドを対象とするワークロードとリソースのオーケストレータで、ワークロード(コンテナ、サーバレスなど)とそれらがコンシュームするリソース(データベース、メッセージキュー、バケット、データパイプラインなど)を、クラウドプロバイダあるいはおんプロミス環境にわたって管理します。
Crossplaneが目指すのは、クラウドプロバイダを越えた"高次のオーケストレータ"になることだ。Kubernetesの連携プロジェクトに近いようにも見えるが、コンテナやクラスタに限定されない点が異なる。
プロジェクトのドキュメントには、目標とするもの，しないものに対する考え方が表明されている。目標とするのは、
- 管理者と開発者の関心事の明確な区別を定義すること。
- クラウドプロバイダの既存のマネージドサービスを使用すること。
- CockroachDBやMongo、Confluent、Elasticなど、クラウドプロバイダとの結び付きを必ずしも持たない独立企業による、新たなサービスを利用すること。
- コントローラを通じて、リソースの完全なライフサイクル管理を実現すること。
- Crossplane上に他のユーザが開発可能なように、リッチな拡張ポイントを公開すること。
目標としないのは、
- ノード上のコンテナワークロードを直接オーケストレーションすること(これはKubernetesがすでに行っていることだ)。
- クラウドプロバイダのマネージドサービスを置き換えること。
- アプリケーションを開発し、パッケージングし、デプロイするワークフローを改善すること(SkaffoldやGarden.ioなど、これに重点を置くプロジェクトがすでに存在する)。
- ワークロードやアプリケーションのパッケージング形式を定義すること(これに関するものとしては、新たにDockerやMicrosoftが先日提案した"CNAB"フォーマットがすでにある)。
プロジェクトの資料には、これが早期アクセスリリースであり、運用対応については保証されないことが明確に述べられている。プロジェクトでは、コミュニティからのコントリビューションを積極的にもとめている。興味のある読者は、プロジェクトのGitHubリポジトリを覗いてみるか、Crossplaneチームにコンタクトをとるとよいだろう。