Google Cloud Platform Service Broker(ベータ版、非推奨)

このページでは、Google Cloud Platform Service Broker の概要を説明します。

はじめに

Google Cloud Service Broker は、Google Cloud でホストされるオープンソースの Open Service Broker(OSB)API の実装です。これにより、Kubernetes 上で実行されるアプリケーションへの Google Cloud サービスの配信が簡単になります。Google Cloud リソースを作成し、それに対応する権限を管理することで、Kubernetes クラスタ内から Google Cloud サービスを簡単に利用できます。たとえば、GKE クラスタ内から Cloud Pub/Sub サービスのインスタンスをプロビジョニングし、アプリケーションで使用できるようにすることが可能です。

Service Broker はサービス カタログ GKE アドオンの最上位に登録されています。クラスタにサービス カタログをインストールして Service Broker を追加すると、使用可能なサービスとプランのリストがダウンロードされ、プランのインスタンスを作成して必要な権限(割り当て)を適用できるようになります。以上で、クラスタ内のアプリケーションは、ネイティブ API を使用して作成されたサービス インスタンスにアクセスできるようになります。Service Broker から使用可能な Google Cloud サービスは次のとおりです。

これらのサービスのサンプルは、Google Cloud の GitHub リポジトリで確認できます。

コンセプト

Google Cloud Platform Service Broker API では、OSB のコンセプトがいくつか使用されています。

  • アプリケーション: サービス インスタンスを使用するかバインドする可能性のあるソフトウェア。
  • プラットフォーム: アプリケーションのプロビジョニング先およびサービス ブローカーの登録先となるクラウド環境を管理するソフトウェア。ユーザーがサービスをサービス ブローカーから直接プロビジョニングするのではなく、ユーザーがプラットフォームを使用し、サービス ブローカーがユーザーの代理としてサービスを管理します。Google Cloud Platform Service Broker では Kubernetes Service Catalog をプラットフォームとして使用します。
  • サービス: Pub/Sub や Cloud Spanner などのマネージド ソフトウェア。Google Cloud サービスにより、特定の操作を実行するために呼び出す API が公開されます。
  • サービス バインディング: サービス インスタンスを使用する機能。このリクエストは、サービス インスタンスを使用するアプリケーションやその他のエンティティを参照する場合があります。Kubernetes Service Catalog では、バインディング呼び出しで返された情報は、指定された名前空間の Kubernetes シークレットに配置されます。サービス ブローカーは通常、バインド呼び出しを作成してサービス インスタンスの Cloud IAM アクセス許可を設定します。
  • サービス ブローカー: サービス ブローカーは、サービスのライフサイクル管理を担当します。Kubernetes Service Catalog は、サービス ブローカーを操作してサービス インスタンスとサービス バインディングのプロビジョニングと管理を行います。
  • サービス インスタンス: サービス パッケージのインスタンス化。
  • サービス パッケージ: サービス ブローカーがサポートするサービスのクラス。
  • サービスプラン: 特定のサービス パッケージのさまざまなオプションや階層の表現。これにはコストがかかる場合があります。

アーキテクチャ

次の図は、OSB アーキテクチャの概要、およびサービス インスタンスとサービス バインディングをプロビジョニングするサービス カタログとサービス ブローカーの間のフローを示しています。

概要

次の図は、サービス ブローカーのアーキテクチャを示しています。

サービス カタログは Kubernetes の拡張 API であり、Kubernetes クラスタ上で実行されるアプリケーションで Pub/Sub などの Google Cloud サービスを使用できるようにします。サービス カタログはサービス ブローカーと通信して利用可能なサービスとプランのリストを取得し、サービス インスタンスとしてプロビジョニングできます。

サービス インスタンスに関する情報は、ServiceInstance リソースと ServiceBinding リソースに格納されます。サービス インスタンスがプロビジョニングされると、アクセス認証情報は Kubernetes シークレットを通じてアプリケーションと共有されます。

サービスとプランのリスト化

  1. Google Cloud の ClusterServiceBroker リソースがサービス カタログにインストールされると、サービス カタログはサービス ブローカーに接続し、使用可能なサービスとプランのリストをリクエストします。
  2. サービスの詳細は ClusterServiceClass リソースとして格納され、それに対応するプランは ClusterServicePlan リソースに格納されます。

サービスとプランをリスト化する方法については、Google Cloud のサービスとプランの検出をご覧ください。

サービス アカウント インスタンスとバインディング フロー

次の図は、Cloud IAM API のコンテキストにおける Kubernetes Service Catalog とサービス ブローカーの間のインタラクションの順序を示しています。サービス アカウントは、Google Cloud リソースの認証で必要となります。

  1. Cloud IAM サービス アカウントのサービス インスタンスをプロビジョニングします。
  2. Google Cloud が新しいサービス アカウントをプロビジョニングします。この時点ではアクセス権限はありません。
  3. サービス ブローカーが ServiceInstance リソースに格納されているインスタンス プロビジョニング レスポンスを返します。
  4. Cloud IAM サービス アカウント インスタンスのサービス バインディングをプロビジョニングします。
  5. Google Cloud がサービス アカウントの秘密鍵を生成し、これを Cloud IAM サービス アカウント インスタンスに返します。
  6. サービス ブローカーが Cloud IAM サービス アカウントの秘密鍵を返します。ServiceBinding リソースが作成されます。
  7. サービス カタログがサービス アカウントの秘密鍵を指定された名前空間のシークレットに格納します。
  8. このサービス アカウントを使用して、バインディング呼び出しへの入力として新しいバインディングを作成し、他の Google Cloud リソースに役割を割り当てることができます。

Google Cloud サービス インスタンスとバインディング フロー

次の図は、サービス ブローカーが提供する Pub/Sub などの他の Google Cloud サービスのコンテキストにおけるサービス カタログとサービス ブローカーのインタラクションの順序を示しています。

  1. サービスプランを含むサービス インスタンスをプロビジョニングします。たとえば、プラン 1 を含む Pub/Sub サービスをプロビジョニングできます。
  2. Google Cloud がプロジェクト内のリソースの新しいインスタンスをプロビジョニングします。Pub/Sub の場合、Google Cloud は新しい Pub/Sub トピックをプロビジョニングします。
  3. サービス ブローカーが ServiceInstance リソースに格納されているインスタンス プロビジョニング レスポンスを返します。
  4. サービスプランで定義されたパラメータを使用して、サービス インスタンスのサービス バインディングをプロビジョニングします。Pub/Sub の場合、これには IAM パブリッシャーや Cloud IAM サブスクライバーのアクセス権限が含まれます。

    • 使用するサービス アカウントを指定します。

    • サービス アカウントに割り当てる Cloud IAM 役割を指定します。

  5. サービス アカウントの Cloud IAM 権限を設定します。これはリソースの種類によって次のように異なります。

    • リソース自体に対する Cloud IAM アクセス権限。Cloud Spanner サービス インスタンスの場合と同様です。

    • リソース固有のアクセス権限をサポートしていないリソースのプロジェクト レベルでの Cloud IAM アクセス権限。

  6. サービス ブローカーがサービスの接続情報を返し、ServiceBinding リソースが作成されます。

  7. サービス カタログが名前空間で指定されたシークレットにサービスの接続情報を格納します。

  8. 接続認証情報を含むサービス バインディングの情報は、Kubernetes シークレットを使用してアプリケーションと共有されます。

  9. アプリケーションは、Pub/Sub などのサービスとの接続やアクセスにこのバインディング情報を使用します。

省略可: 複数のサービス アカウントと役割のセットを使用して、同じサービス インスタンスの同じ名前空間内に追加のバインディングを作成できます。これにより、同じ Kubernetes 名前空間の複数のアプリケーションで同じ Pub/Sub トピックを使用できるようになります。

サービス インスタンスのプロビジョニングとバインドの方法については、Google Cloud サービスの使用をご覧ください。

プロビジョニングの解除とクリーンアップのフロー

次の図は、不要になったサービスのプロビジョニングを解除する方法を示しています。使用しなくなったサービスの料金が Google Cloud アカウントに課金されないようにするには、この操作を行う必要があります。

  1. サービス バインディングを削除します。サービス カタログがサービス ブローカーにサービス バインディング解除リクエストを送信します。
  2. サービス インスタンスの Cloud IAM 権限が削除されます。
  3. サービス ブローカーがバインディング削除レスポンスを返します。
  4. サービス バインディングと接続情報を含む Kubernetes シークレットを削除します。
  5. サービス インスタンスを削除します。サービス カタログがサービスのプロビジョニング解除リクエストをサービス ブローカーに送信します。
  6. サービス インスタンスが削除されます。Pub/Sub の場合は、Pub/Sub トピックが削除されます。
  7. サービス ブローカーがプロビジョニング解除レスポンスを返します。

サービス インスタンスとサービス バインディングを削除する方法については、サービス カタログのクリーンアップをご覧ください。

次のステップ