Google Cloud Platform Service Broker (Beta, Deprecated)

This page provides an overview of the Google Cloud Platform Service Broker.

Introduction

Google Cloud Service Broker is an implementation of the open-source Open Service Broker (OSB) API hosted on Google Cloud. It simplifies the delivery of Google Cloud services to applications that run on Kubernetes. By creating Google Cloud resources and managing their corresponding permissions, Service Broker makes it easy to consume Google Cloud services from within a Kubernetes cluster. For example, you can provision an instance of the Cloud Pub/Sub service from within your GKE cluster and make it available to your application(s).

Service Broker is registered on top of the Service Catalog GKE add-on. Once you install Service Catalog in your cluster and add Service Broker, it downloads a list of available services and plans. You can now create instances of plans and assign those instances with required permissions (bindings). Applications in your cluster can now access created service instances via their native APIs. Google Cloud services available via Service Broker are:

You can find samples for each of these services in the Google Cloud GitHub repository.

Concepts

The Google Cloud Platform Service Broker API uses several OSB concepts:

  • Application: Any piece of software that might use or bind to a service instance.
  • Platform: The software that manages the cloud environment into which applications are provisioned and service brokers are registered. Users do not directly provision services from service brokers; rather, they rely on the Platform to manage the services and interact with the service brokers on their behalf. The platform for Google Cloud Platform Service Broker is the Kubernetes Service Catalog.
  • Service: A managed software offering such as Pub/Sub or Cloud Spanner. Google Cloud services expose APIs that can be invoked to perform certain actions.
  • Service binding: The ability to use a service instance. This request might refer to an application or some other entity that may wish to use the service instance. In the Kubernetes Service Catalog, information returned in a binding call is placed in a Kubernetes Secret for the specified namespace. Service Broker typically uses a create binding call to set Cloud IAM permissions on a service instance.
  • Service broker: Service brokers manage the lifecycle of services. The Kubernetes Service Catalog interacts with service brokers to provision and manage service instances and service bindings.
  • Service instance: An instantiation of a service offering.
  • Service offering: The class of a service that a service broker supports.
  • Service plan: The representation of different options or tiers for a given service offering. This may impact cost.

Architecture

The following diagrams provide a visual overview of the OSB architecture and the flow between Service Catalog and Service Broker for provisioning a service instance and a service binding.

Overview

The following diagram illustrates the architecture of Service Broker.

Service Catalog is a Kubernetes extension API that enables applications running on a Kubernetes cluster to use Google Cloud services, such as Pub/Sub. Service Catalog communicates with Service Broker to get a list of available services and plans, which can then be provisioned as service instances.

Information about a service instance is stored in the ServiceInstance and ServiceBinding resources. Once a service instance has been provisioned, the access credentials are shared with the application through Kubernetes Secrets.

Listing services and plans

  1. Once the Google Cloud ClusterServiceBroker resource has been installed in the Service Catalog, Service Catalog connects to Service Broker to request the list of available services and plans.
  2. The service details are stored as ClusterServiceClass resources, and their corresponding plans are stored in ClusterServicePlan resources.

See Discovering Google Cloud services and plans for instructions on how to list services and plans.

Service account instance and binding flow

The diagram below illustrates the order of interactions between the Kubernetes Service Catalog and Service Broker in the context of the Cloud IAM API. Service accounts are necessary to authenticate to Google Cloud resources.

  1. Provision a service instance of a Cloud IAM service account.
  2. Google Cloud provisions a new service account. It has no permissions at this point.
  3. Service Broker returns an instance provisioning response, which is stored in a ServiceInstance resource.
  4. Provision the service binding for the Cloud IAM service account instance.
  5. Google Cloud generates a private key for the service account and returns it to the Cloud IAM service account instance.
  6. Service Broker returns the private key for the Cloud IAM service account, and a ServiceBinding resource is created.
  7. Service Catalog stores the private key for the service account in a Secret in a specified namespace.
  8. You can use the service account to assign roles to other Google Cloud resources by creating new bindings using this service account as input to the binding call.

Google Cloud service instance and binding flow

The diagram below illustrates the order of interactions between Service Catalog and Service Broker in the context of another Google Cloud service offered by Service Broker, such as Pub/Sub.

  1. Provision a service instance with a service plan. For example, you can provision the Pub/Sub service with Plan 1.
  2. Google Cloud provisions a new instance of the resource in the project. For Pub/Sub, Google Cloud provisions a new Pub/Sub Topic.
  3. Service Broker returns an instance provisioning response, which is stored in a ServiceInstance resource.
  4. Provision the service binding for the service instance with parameters defined by the service plan. For Pub/Sub, this includes Cloud IAM publisher or subscriber permissions.

    • Specify the service account to use.

    • Specify the Cloud IAM roles to assign to the service account.

  5. Set the Cloud IAM permissions for the service account. Depending on the resource type, this might be:

    • Cloud IAM permissions on the resource itself, as would be the case for a Cloud Spanner service instance.

    • Cloud IAM permissions at the project level for those resources that don't support resource-specific permissions

  6. Service Broker returns the connection information for the service, and a ServiceBinding resource is created.

  7. Service Catalog stores the connection information for the service in a Secret specified in a namespace.

  8. The service binding information, which includes the connection credentials, is shared with the application using a Kubernetes Secret.

  9. The application uses the binding information to connect with and access the service, such as Pub/Sub.

Optional: You can create additional bindings, using different service accounts and different sets of roles, within the same namespace to the same service instance. This can help different applications in the same Kubernetes namespace use the same Pub/Sub topic.

See Using a Google Cloud service for instructions on how to provision and bind to a service instance.

Deprovisioning and cleanup flow

The diagram below illustrates how to deprovision a service when it is no longer needed. This should be done to avoid incurring charges to your Google Cloud account for a service that is no longer in use.

  1. Delete the Service Binding. Service Catalog sends a request to Service Broker to unbind the service.
  2. Google Cloud deletes the Cloud IAM permissions for the service instance.
  3. Service Broker returns a binding deletion response.
  4. Delete the Kubernetes Secret containing the service binding and connection information.
  5. Delete the Service Instance. Service Catalog sends a request to Service Broker to deprovision the service.
  6. Google Cloud deletes the service instance. For Pub/Sub, it deletes the Pub/Sub Topic.
  7. Service Broker returns a deprovisioning response.

See Service Catalog clean up for instructions on how to delete the service instance and binding.

What's next

Оцените, насколько информация на этой странице была вам полезна:

Оставить отзыв о...

Текущей странице
Kubernetes Engine Documentation