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

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

はじめに

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

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

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

コンセプト

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

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

アーキテクチャ

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

概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Kubernetes Engine のドキュメント