kro で Kubernetes のデベロッパー エクスペリエンスをシンプルに

※この投稿は米国時間 2025 年 1 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Kube Resource Orchestrator（kro、発音は crow と同じ）に関する Google Cloud、AWS、Azure のコラボレーションを発表できることを嬉しく思います。kro は、クラウドに依存しない Kubernetes ネイティブな方法で Kubernetes リソースのグループ化を定義するものです。kro を使用すると、アプリケーションとその依存関係を単一のリソースとしてグループ化でき、エンドユーザーが簡単に利用できるようなります。

Kubernetes リソースのオーケストレーションにおける課題

プラットフォーム チームや DevOps チームは、アプリケーション チームによるワークロードのデプロイ方法を定義することを望んでおり、こうした基準を作成し、適用するためのプラットフォームとして Kubernetes を使用したいと考えています。各サービスは、リソースの作成、セキュリティの構成、モニタリングの設定、エンドユーザー インターフェースの定義など、あらゆることを処理する必要があります。クライアントサイドのテンプレート ツール（Helm、Kustomize など）を利用することもできますが、エンドユーザーが利用するリソースのカスタム グループを作成する場合、Kubernetes にはプラットフォーム チームが利用できるネイティブな方法がありません。

そのため、プラットフォーム チームは、Kubernetes カスタム コントローラの構築や、Helm のようなパッケージング ツールを使用するカスタム ソリューションに投資する必要がありましたが、いずれも Kubernetes のカスタム リソース定義（CRD）のメリットを活用できないものでした。こうしたアプローチは構築、維持、トラブルシューティングに費用がかかり、Kubernetes の専門家以外にとっては扱いが困難でした。これは多くの Kubernetes ユーザーが直面する問題です。Google Cloud は、すべての Kubernetes ユーザーが K8s API をよりシンプルに利用できるように、ベンダー固有のソリューションを開発するのではなく、Amazon および Microsoft と協力することを選択しました。

kro がデベロッパー エクスペリエンスを簡素化する仕組み

kro は、Kubernetes ネイティブなフレームワークであり、複数のリソースを単一のユニットとしてデプロイするための再利用可能な API を作成できます。Kubernetes Deployment とその依存関係をカプセル化し、単一の API にまとめることで、Kubernetes に詳しくないアプリケーション チームでも利用できるようになります。kro を使用すると、エンドユーザーが参照するパラメータのみを公開するカスタムのインターフェースを作成できるため、エンドユーザーは Kubernetes やクラウド プロバイダの API の複雑さを感じずに利用できます。

kro は、ResourceGraphDefinition というコンセプトを導入することでこれを実現しています。ResourceGraphDefinition は、標準的な Kubernetes のカスタム リソース定義（CRD）を Kubernetes リソースのセットに拡張する方法を指定します。エンドユーザーは単一のリソースを定義し、kro はそれを CRD で定義されたカスタム リソースに拡張します。

kro は、Kubernetes リソースのグループ化や管理のために使用できます。ACK、KCC、ASO などのツールは、Kubernetes からクラウド プロバイダのリソースを管理するための CRD を定義します（これらのツールにより、ストレージ バケットなどのクラウド プロバイダのリソースを Kubernetes リソースとして作成および管理できるようになります）。kro は、これらのツールのリソースを他の Kubernetes リソースとともにグループ化でき、アプリケーションのデプロイ全体と、それに依存するクラウド プロバイダのリソースを定義するためにも使用できます。

サンプル ユースケース

以下では、Google Cloud での kro の使用例をいくつか紹介します。その他の例については、kro のウェブサイトをご覧ください。

例 1: GKE クラスタの定義

この例では、プラットフォーム管理者が、組織内のエンドユーザーに GKE クラスタの作成をセルフサービスで許可するとします。プラットフォーム管理者は、必要な Kubernetes リソースを定義する GKEclusterRGD という名前の kro ResourceGraphDefinition と、エンドユーザーが構成できるオプションのみを公開する GKEcluster という名前の CRD を作成します。クラスタの作成に加えて、プラットフォームチームは、ポリシーやエージェントなどの管理ワークロードをクラスタがデプロイすることも望んでいます。ResourceGraphDefinition は以下のリソースを定義し、KCC を使用して K8s CRD から Google Cloud API へのマッピングを提供します。

• GKE クラスタ、コンテナ ノードプール、IAM サービス アカウント、IAM ポリシー メンバー、サービス、ポリシー

次に、プラットフォーム管理者は、エンドユーザー インターフェースを定義し、CRD のインスタンスを作成することで新しいクラスタを作成できるようにします。CRD では以下のことを定義します。

• クラスタ名、ノードプール名、最大ノード数、ロケーション（us-east1 など）、ネットワーク（省略可）

ポリシー、サービス アカウント、サービス アクティベーション（および、これらのリソース間の関係）に関連する情報はいずれもエンドユーザーに表示されないため、エクスペリエンスが簡素化されます。

例 2: ウェブ アプリケーションの定義

この例では、DevOps エンジニアがウェブ アプリケーションとその依存関係の再利用可能な定義を作成するとします。WebAppRGD という名前の ResourceGraphDefinition を作成し、WebApp という名前の新しい Kubernetes CRD を定義します。この新しいリソースは、ウェブ アプリケーション環境に必要なすべてのリソースをカプセル化します。リソースには以下のものが含まれます。

• デプロイ、サービス、サービス アカウント、モニタリング エージェント、クラウド リソース（オブジェクト ストレージ バケットなど）

WebAppRGD ResourceGraphDefinition は、デフォルト構成を設定できるほか、デプロイ時にエンドユーザーが設定できるパラメータを定義することもできます（kro を使用することで、変更不可とするものと、エンドユーザーが構成できるものを柔軟に決定できます）。次に、開発者はユーザー向けのパラメータを入力して、WebApp CRD のインスタンスを作成します。その後、kro が必要な Kubernetes リソースをデプロイします。

kro の主なメリット

kro は、プラットフォーム エンジニアリング チームにとって大きな前進であり、以下のような多くのメリットをもたらします。

• Kubernetes ネイティブ: Kubernetes カスタム リソース定義（CRD）を活用して Kubernetes を拡張でき、あらゆる Kubernetes リソースと連携して、既存の Kubernetes ツールやワークフローと統合できます。

• シンプルなエンドユーザー エクスペリエンスを実現: Kubernetes リソースの複雑なグループに対してエンドユーザー インターフェースを簡単に定義できるため、Kubernetes の専門家でなくても Kubernetes に構築されたサービスを利用しやすくなります。

• アプリケーション チーム向けに標準化されたサービスを実現: kro のテンプレートは、さまざまなプロジェクトや環境で再利用できるため、整合性が促進され、作業の重複を軽減できます。

kro を使ってみる

kro は、GitHub のオープン ソース プロジェクトとして利用できます。GitHub の組織は現在、Google、AWS、Microsoft の各チームが共同で所有しており、コミュニティからの貢献を歓迎しています。また、こちらのウェブサイトでは、kro のインストールや使用に関するドキュメント、使用例、ユースケースなどを提供しています。kro は初期段階のプロジェクトであるため、まだ本番環境での使用には適していませんが、ぜひお客様の Kubernetes 開発環境でテストしてみてください。

-シニア クラウド デベロッパー アドボケイト、Abdelfettah Sghiouar
-プロダクト マネージャー、Nic Slattery