Google Cloud、AWS、Microsoft AzureはKube Resource Orchestrator(kro、「クロウ」と発音)と呼ばれる新しいオープンソースプロジェクトを共同で発表した。このプロジェクトはKubernetesリソースのグループ化とデプロイ方法を標準化する試みで、プラットフォームチームがワークロードをデプロイしやすくすることを目指している。
発表によると、Kubernetesには開発チームが使用できるリソースのカスタムグループを、プラットフォームチームが作成するためのネイティブな方法が欠けており、多くの組織がHelmやKustomizeのようなクライアントサイドのテンプレートツールを使用したり、独自のカスタムKubernetesコントローラを構築したりしているという。これらのアプローチは保守にコストがかかり、専門家以外が効果的に使用するのが難しいことが多いと判明した。
kroを使えばアプリケーションとその依存関係を、エンドユーザーが簡単に利用できる単一のリソースとしてグループ化できます。
- Abdelfettah Sghiouar氏とNic Slattery氏
kroの中核となるイノベーションはResourceGraphDefinition カスタムリソースの導入だ。kroはKubernetesデプロイメントとその依存関係を単一のAPIにカプセル化し、非プラットフォームエンジニアに適用可能なパラメータのみを公開するカスタムエンドユーザーインターフェイスを可能にする。このマスキングによってデプロイメントコンテキストでは役に立たないKubernetesとクラウドプロバイダーのためのAPIエンドポイントの複雑さが隠蔽される。
この投稿ではkroのアプリケーションの2つの実用的な例を概説している。最初のシナリオではプラットフォームエンジニアがkroを使用して、組織のメンバーに事前設定された管理ワークロード、ポリシー、セキュリティ設定を持つGoogle Kubernetes Engine(GKE)クラスターを作成するためのセルフサービスアクセスを提供する。2つ目の例ではDevOpsエンジニアがWebアプリケーションの再利用可能な定義を作成し、デプロイメントやサービスから監視エージェントやクラウドストレージまで、必要なリソースをすべてカプセル化する方法を示している。
KroはKubernetesからクラウドリソースを管理するために利用可能な、既存のクラウドプロバイダーのKubernetes拡張機能とシームレスに動作する。これらはAWS Controllers for Kubernetes(ACK)、Google Config Connector(KCC)、Azure Service Operator(ASO)である。
kroは異なるプロジェクトや環境間での一貫性を促進する標準化された再利用可能なサービステンプレートを可能にし、完全にKubernetesネイティブであるという利点がある。kroはまだ開発の初期段階にある。「初期段階のプロジェクトであるため、kroはまだ本番環境での使用には対応していませんが、各自のKubernetes開発環境でテストすることをお勧めします」と投稿に書かれている。
AKS Engineering Blogの投稿ではBridget Kromhout氏とMatthew Christopher氏が、マイクロソフトの視点からkroプロジェクトの概要を説明している。この投稿ではリソース管理を簡素化するために設計されたこのKubernetesネイティブツールについて、Microsoft AzureがAWSおよびGoogle Cloudと協力していることを強調している。Kromhout氏とChristopher氏はAzure固有の実装例も提供し、コミュニティ参加の機会を強調している。
私たちはお客さまとクラウドネイティブコミュニティのニーズを中心に据え、K8sクラスターをどこで稼動させてもシームレスに動作するツールを提供します。
- Matthew Christopher氏とBridget Kromhout氏
kroのWebサイト上のウォークスルーではkroがどのように動作するかを詳しく説明しており、まず有向非巡回グラフ(DAG)を生成して定義の依存関係を理解し、それを検証して正しいデプロイメント順序を確立することによりResourceGraphDefinitionを作成する方法を解説している。その後、Kubernetesクラスター内にリソース用の新しいCustomResourceDefinition(CRD)を作成する。
一部のコミュニティのコメントではkroがCrossplane - Kubernetesを使用してクラウドリソースをオーケストレーションすることができるオープンソースのCNCFプロジェクトや、Kubernetesアプリケーションの定義、インストール、アップグレードを行うパッケージマネージャーHelmなどの他の確立されたツールを補完または置き換える能力について考察されている。
DevOps ToolkitチャンネルのYouTubeビデオではViktor Farcic氏がkroのローンチについて議論している。彼はCrossplaneへの影響についても考察している。Farcic氏は当初、クラウドリソースの構成を簡素化するkroの可能性に興奮し、正しいKubernetesリソースを生成するシンプルなアプリケーション定義の作成に成功した。しかしFarcic氏は条件付きリソース作成やデータベース統合を含むより複雑なシナリオではデフォルト値や所有者の参照が欠落し、ResourceGroupsからの変更が既存リソースに適切に伝播しないなど、多くの問題が発生することに気付いた。
彼はまた、命令型構造にYAMLを使用するのは理想的ではなく、そのために設計されていないフォーマットにさらにロジックを追加すると「忌まわしいもの」になりかねないとも指摘している。Crossplaneコミュニティにとってもっとも重要なこととして、Farcic氏は、既存ツールと機能がオーバーラップするkroの目的に疑問を呈した。「kroは以前に作られた他のツールと多かれ少なかれ同じ機能を果たしており、特に目立った改善点は見受けられません」と彼は気付きを述べた。kroはより定型文が少ないよりシンプルな構文を提供しているように見える一方で、現在のところCrossplaneの機能のほんの一部しか提供しておらず、特にCrossplaneが複数の言語をサポートしているため、まだ実用的な代替品とは言えないと彼は述べている。
Parity社のWilson Spearman氏は「Helmキラーはついに登場したのか?」と題したブログ投稿の中で、Helmのアーキテクチャは依存関係の管理、CRDアップグレードのハンドリング、ライフサイクルの適切な管理において基本的な制約があり、kroはより人間的で読みやすい構文を持つことに成功していると指摘している。Spearman氏は最後にHelmはオープンソースや小規模な組織で使われ続け、kroは企業での認知度を高めるだろうと予測している。
kroプロジェクトはGoogle、AWS、Microsoftのチームによる共同所有のもとGitHubで公開されており、コミュニティはその開発に貢献するよう招待されている。包括的なドキュメントと使用例はプロジェクトのウェブサイトに掲載されている。