キーポイント
- Many organisations are aiming to assemble their own cloud platform, often consisting of a combination of on-premises infrastructure and cloud vendors.
- Although Kubernetes does not provide a full platform-as-a-service (PaaS)-like experience out of the box, the combination of a well-defined API, clear abstractions, and comprehensive extension points make this a perfect foundational component on which to build upon.
- Crossplane is an open source cloud control plane that enables engineers to manage any infrastructure or cloud services directly from Kubernetes. This control plane provides a single entry point for user interaction where policy can be enforced, guardrails applied, and auditing conducted.
- Infrastructure can be configured using K8s custom resource definitions (CRDs) and YAML. It can also be managed via well established tools like kubectl or via the Kubernetes API itself, and take advantage of workflow best practices, such as GitOps.
- The Open Application Model (OAM) specification describes a model where core software delivery personas are defined and prescribed clear areas of responsibility: developers, application operators, and infrastructure operators. Crossplane is the Kubernetes implementation of the specification.
InfoQは先頃、Upboundの創業者兼CEOのBasam Tabbara氏と会って、複数のクラウドベンダやオンプレミスインフラストラクチャにまたがるアプリケーションプラットフォームの構築について話すことができました。
氏との会話は、ソフトウェアを提供するすべての組織が、意図的に選択したものかどうかは別として、ひとつのプラットフォームを対象にアプリケーションを展開する理由を検討することから始まりました。最近はKubernetesが、"クラウドネイティブ"なプラットフォームの基盤として使用されることが多くなっています。Kubernetesが完全なプラットフォーム・アズ・ア・サービス(PaaS)的エクスペリエンスをアウトオブボックスで提供してくれる、という事ではないのですが、それでも十分に定義されたAPI、明確な抽象化、包括的な拡張ポイントといったものを揃えれば、PaaSを構築する上で完璧な基盤コンポーネントが出来上がります。
Tabbara氏はCrossplaneについても論じました。Crossplaneは、任意のインフラストラクチャあるいはクラウドサービスを、Kubernetesから直接管理できるようにするオープンソースプロジェクトです。この"クロスクラウドなコントロールプレーン"は、Kubernetesの宣言型コンフィギュレーションプリミティブ上に構築されていて、既存のK8sツールチェーンを活用したインフラストラクチャ定義を可能にしてくれます。さらに話題はOpen Application Model (OAM)に及び、クラウドネイティブなアプリケーションを構築する上で、Crossplaneをこのチームセントリックな標準のKubernetes実装にする方法を検討しました。
エンジニアリングチームにはプラットフォームが必要である
独自のクラウドプラットフォームを構築しようとする組織はたくさんありますが、その多くはオンプレミスなインフラストラクチャとクラウドベンダを組み合わせたものです。このような組織のリーダたちは、デプロイフリクションの最小化とデリバリのリードタイム削減が、安全性やセキュリティを伴うことによって、総合的なアドバンテージを提供できるものであることを理解しています。これらのチームはまた、成功を収めたあらゆるビジネスが、プラットフォームに関わらず必要な既存の"遺産(heritage)"アプリケーションやインフラストラクチャを持っていることも認識しています。ロックインの回避やコストの調整、障害回復手段の実装などを目的として、複数のクラウドベンダをサポートしようとする組織もたくさんあります。
組織内のプラットフォームチームは通常、アプリケーション開発者や運用担当者によるセルフサービス利用を可能にしたいと考えますが、同時に適切なセキュリティ、コンプライアンス、法的要求事項もプラットフォームに組み込んでおきたいと思っています。Amazon Web Service (AWS)やMicrosoft Azure、Google Cloud Platform (GCP)といった大手パブリッククラウドベンダは、単一のコントロールプレーン経由でサービスを提供しています。このコントロールプレーンはユーザインタフェース(UI)、コマンドラインインターフェース(CLI)、アプリケーションプログラミングインターフェース(API)で構成されていて、プラットフォームチームや運用担当者は、これらを通じてインフラストラクチャサービスの基盤にある"データプレーン"を設定ないしデプロイするためのインタラクションを行います。クラウドのコントロールプレーンは、実際には世界規模で分散しているのですが、エンドユーザには一点に集中しているように見えます。このコントロールプレーンがユーザインターフェースの唯一のエントリポイントとして、ポリシの施行やガードレールの提供、監査などを行うのです。
ZimkiやHeroku、あるいはCloud Foudryなどが先鞭をつけたように、アプリケーション開発者は一般的に、アプリケーションの定義とデプロイのためのプラットフォーム・アズ・ア・サービス(PaaS)的なエクスペリエンスを望んでいます。"git push heroku master"だけで新しいアプリケーションをデプロイできるというのは、極めてパワフル、かつフリクションのないアプローチです。アプリケーションの運用担当者やサイト信頼性エンジニアリング(SRE)チームは、アプリケーションの構成、実行、メンテナンスや個々のコンフィギュレーションが容易であることを望みます。
このような要件から導入されたPaaSは、選択が適切でないと、維持コストが高くなる可能性がある、とTabbara氏は警告します。
"最近の商用PaaSは、多くの場合において、組織のユースケース要件の80パーセントを満足しています。一方でこれは、要件の残り20パーセントについては結局インフラストラクチャチームがプラットフォームリソースを追加しなければならない、という意味でもあるのです。"
PaaS(的なエクスペリエンス)を構築する
PaaSの構築は容易ではありません。時間とスキルが必要ですし、すべての関係者の要件を満足するような技術的抽象化を定義し、実装するのは難しい作業です。Googleでは高度にトレーニングされた数千人のエンジニアが社内プラットフォームに携わっている、というのは有名な話です。また、Netflixには社内PaaSの開発とメンテナンスに特化した大規模な専門家チームがありますし、Shopifyのようなもう少し小規模な組織にも専門のプラットフォームチームがいます。技術面での抽象化は、LibcloudやOpenStackによるもののような"最低限の共通項"に近いレベルから、共通ワークフローの提供、さらにはHashiCorpのTerraformやPulumiのようにクラウドに完全特化したコンフィギュレーションに至るまで、幅広いものになっています。従来のPaaS抽象化もクラウドの分野では一般的ですが、GCP App EngineやAWS Elastic Beanstalk、Azure Service Fabricといったように、通常はベンダに固有のものです。
たくさんの組織が、プラットフォーム構築の基盤としてKubernetesを選択しています。しかしながら、Tabbara氏のツイートによると、これには非常に大きな事前投資が必要になります。先程のユースケース80パーセントの問題と合わせると、これが"PaaSジレンマ"につながる可能性があるのです。
"PaaSジレンマ — 提供されるPaaSは欲しいものの80パーセントしか提供してくれず、独自のPaaSは時間の80パーセントを #kubernetes のメンテナンスに費やさなければならない"
オープンソースのCrossplaneプロジェクトは、オーダーメードのPaaS風エクスペリエンス構築のためのユニバーサルなマルチクラウドコントロールプレーンになることを目指している、とTabbara氏は述べています。
Crossplaneが注目するのは"クロス"クラウドなコントロール"プレーン"です。さまざまなクラウドプロバイダを接続する役割を果たし、それら全体のコントロールプレーンとして振る舞うエンティティを指す名詞を使いたかったのです。名称の"Cross"はクロスクラウドを、"plane"はコントロールプレーンを表現しています。
広く受け入れられているKubernetesスタイルの構成プリミティブの上に構築し、既製インフラストラクチャコンポーネントに加えて、付加的リソースを共有するためのレジストリを提供することで、インフラストラクチャとアプリケーション両方の運用負担を軽減します。同時に、重要なインフラストラクチャ抽象化をカプセル化する、明確に定義されたAPIを提供することにより、プラットフォーム運用担当者("APIラインの下"で作業する)と、アプリケーション開発者および運用担当者("APIラインの上"で作業する)の関心事の分離が可能になります。
"開発者は、実装の詳細や環境による制約、あるいはポリシなどを心配する必要なく、ワークロードを定義することが可能です。管理者(administrator)は環境の特性やポリシを定義できます。これにより、高度な再利用性と複雑性の軽減が可能になるのです。"
Crossplane: Kubernetesからインフラストラクチャをコントロールする
CrossplaneはKubernetes add-onとして実装されていて、クラウドインフラストラクチャ、サービス、アプリケーションのプロビジョンと管理を実行可能な任意のクラスタを拡張します。Crossplaneは、Kubernetesスタイルの宣言型でAPI駆動のコンフィギュレーションと管理を使用して、インフラストラクチャやオンプレミス、あるいはクラウド内の任意のパーツをコントロールします。このアプローチにより、インフラストラクチャをCRD(Custom Resource Definitions)とYAMLを使ってコンフィギュレーションすることが可能になります。kubectlなどの使いなれたツールや、Kubernetes APIそれ自体を通じて管理することもできます。Kubernetesを使用したことにより、RBACや、あるいはGatekeeperを通じて実装されたOPA(Open Policy Agent)を使って、セキュリテイ管理を定義することも可能になっています。
Crossplaneのインストールの一部として、Kubernetesリソースコントローラがリソースライフサイクル全体(プロビジョニング、ヘルスチェック、スケーリング、フェールオーバ)を管理し、必要なコンフィギュレーションから逸脱した外部変更にアクティブに対応するように設定されます。Crossplaneは継続的デリバリ(CD)パイプラインに統合されているので、アプリケーションインフラストラクチャのコンフィギュレーションは単一のコントロールクラスタ内に格納されます。これにより、GitOpsなどのクラウドネイティブなCDのベストプラクティスを使って、変更の生成、追跡、承認を行うことが可能になっています。アプリケーションとインフラストラクチャのコンフィギュレーションを同じKubernetesクラスタに共存させることもできるので、ツールチェーンやデプロイメントパイプラインの複雑さが低減されます。
明確な抽象化、ペルソナの使用、"線の上と下"アプローチは、Open Application Modelで行われた開発を強く意識したものです。
OAM: チームを中心としたクラウドネイティブアプリ開発の標準
Microsoft、Alibaba、Upboundが立ち上げたOpen Application Model (OAM)仕様では、開発者がアプリケーションコンポーネントの定義を、アプリケーション運用担当者がコンポーネントのインスタンス生成とアプリケーション構成へのアサインを、インフラストラクチャ運用者がプラットホームを実現する下位サービスの宣言、インストール、メンテナンスを、それぞれ責務として持つモデルについて述べています。Crossplaneはこの仕様をKubernetesで実装したものなのです。
OAMでは、プラットホームビルダがComponent、Trait、Scopeの形式で、再利用可能なモジュールを提供することができます。このためプラットフォームでは、それらを事前定義されたアプリケーションプロファイルにパッケージするようなことが可能になっています。ユーザは、高SLO(Service Level Objective)のマイクロサービス、永続的なボリュームを備えたステートフルアプリ、水平自動スケールの可能なイベント起動関数、といったように、プロファイルを選択することでアプリケーションの実行方法を決定します。
OAM仕様概要の資料には、一般的なアプリケーションデリバリのライフサイクルについて検討したストーリが記載されています。
- 開発者がWebアプリケーションを作成する。
- アプリケーション運用担当者がそのアプリケーションのインスタンスをデプロイし、自動スケーリングなどの運用特性を設定する。
- インフラストラクチャ運用担当者がデプロイメントとオペレーションの処理に使用する基盤テクノロジを決定する。
アプリケーションをデリバリするアプリケーション開発者は、プログラムの個々のコンポーネントをComponent YAMLとして記述します。このファイルによって、ワークロードとその実行に必要な情報がカプセル化されるのです。
アプリケーションを実行し運用する運用担当者は、開発者のコンポーネントにパラメータ値を設定すると同時に、レプリカサイズや自動スケールポリシ、接続ポイント、トラフィックのルーティングルールといった運用特性をApplicationConfiguratiol YAMLに記載します。このような運用特性を、OAMではトレイト(trait)と呼んでいます。ApplicationConfigurationの記述とデプロイは、アプリケーションのデプロイと等価です。基盤プラットフォームは定義されたワークロードのインスタンスを生成し、ApplicationConfigurationのスペックに従って運用トレイトをワークロードにアタッチします。
ここでのインフラストラクチャ運用担当者の責務は、プラットフォーム上で有効な基盤サービスの定義とインストールを行うことです。例えば、サービスを公開するためのロードバランサを選択したり、あるいはデータの暗号化と世界規模のレプリケーションを実現するようなデータベース設定を行ったりします。
一般的なCrossplaneワークフロー
具体的な議論をするために、プロジェクトのインストールから利用まで、一般的なCrossplaneのワークフローを検討してみましょう。
最初にCrossplaneをインストールして、Kubernetesクラスタを生成します。次にプロバイダをインストールし、認証情報を設定します。インフラストラクチャのプリミティブは任意のプロバイダ(GCP、AWS、Azure、Aribaba)、および(独自開発の)オンプレミスからプロビジョンすることができます。
プラットフォーム運用担当者が宣言型(declarative)YAMLを使ってインフラストラクチャリソースの定義、構成、公開を行います。これにより、Kubernetes APIに自身のインフラストラクチャCRDが追加され、アプリケーションから利用可能になります。
アプリケーション開発者はアプリケーションコンポーネントを公開して、サービスの基本的、推奨、オプションの各プロパティと、インフラストラクチャ要件を伝えます。
アプリケーション運用担当者がインフラストラクチャコンポーネントとアプリケーションコンポーネントを結びつけ、コンフィギュレーションを指定してアプリケーションを実行します。
まとめ
Kubernetesは多くの"クラウドネイティブ"なプラットフォームの基盤として使用されています。そのため、プラットフォームの運用モデルとしてだけでなく、下位コンポーネントの構成モデルとしての投資も非常に重要であり、組織に競合優位性をもたらす可能性を持っています。AccelerateでNicole Forsgren博士らが述べているように、リードタイムの最小化(アイデアから価値提供まで)とデプロイ頻度の向上は、ハイパフォーマンスな組織と相関関係にあります。ここでプラットフォームが非常に大きな役割を果たすのです。
Crossplaneは発展を続けるプロジェクトなので、コミュニティもますます大きくなり、フィードバックも増えています。Crossplane Webサイトを参考にこのオープンソースプロジェクトを導入し、Crossplane Slackでフィードバックを公開してください。
著者について
Daniel BryantはDatawireのプロダクトアーキテクトです。InfoQではニュースマネージャであり、QCon Londonではチェアを務めました。現在の専門技術は、"DevOps"ツーリング、クラウド/コンテナプラットフォーム、マイクロサービス実装などが中心です。London Java Community(LJC)のリーダとして、オープンソースプロジェクトへのコントリビューション、InfoQやO'Reily、DZoneなど著名な技術Webサイトで記事の執筆を行う他、QConやJavaOne、Devoxxなど国際的なカンファレンスでも常に講演しています。