Google Cloud Platform Service Broker

Sie erhalten auf dieser Seite einen Überblick über Google Cloud Platform Service Broker.

Einführung

Google Cloud Platform (GCP) Service Broker ist eine Implementierung der als Open-Source auf der GCP gehosteten Open Service Broker (OSB) API. Der Broker vereinfacht die Bereitstellung von GCP-Diensten für Anwendungen, die in Kubernetes ausgeführt werden. Sie können mit Service Broker GCP-Ressourcen erstellen und die entsprechenden Berechtigungen verwalten. Dies erleichtert die Verwendung von GCP-Diensten innerhalb eines Kubernetes-Clusters. Beispielsweise können Sie eine Instanz des Cloud Pub/Sub-Dienstes in Ihrem GKE-Cluster bereitstellen und für Ihre Anwendungen verfügbar machen.

Service Broker wird als Ergänzung zum GKE-Add-on Service Catalog registriert. Nachdem Sie Service Catalog in Ihrem Cluster installiert und Service Broker hinzugefügt haben, wird eine Liste mit verfügbaren Diensten und Plänen heruntergeladen. Sie können jetzt Instanzen von Plänen erstellen und diese Instanzen mit den erforderlichen Berechtigungen (Bindungen) zuweisen. Anwendungen in Ihrem Cluster können jetzt über ihre nativen APIs auf erstellte Dienstinstanzen zugreifen. Über Service Broker sind folgende GCP-Dienste verfügbar.

Beispiele zu jedem dieser Dienste finden Sie im GitHub-Repository auf der Google Cloud Platform.

Konzepte

Die Google Cloud Platform Service Broker API verwendet mehrere OSB-Konzepte:

  • Anwendung: Jede Software, die eine Dienstinstanz verwenden oder daran gebunden werden kann.
  • Plattform: Die Verwaltungssoftware für die Cloud-Umgebung, in der Anwendungen bereitgestellt und Service Broker registriert werden. Nutzer stellen Dienste nicht direkt von Service Brokern bereit. Die Dienste werden von der Plattform verwaltet. Diese interagiert im Namen der Nutzer mit den Service Brokern. Als Plattform für Google Cloud Platform Service Broker dient Kubernetes Service Catalog.
  • Dienst: Eine verwaltete Software wie Google Cloud Pub/Sub oder Spanner. GCP-Dienste stellen APIs für bestimmte Aktionen zur Verfügung.
  • Dienstbindung: Die Fähigkeit, eine Dienstinstanz zu verwenden. Die Anfrage kann von einer Anwendung oder einer anderen Entität kommen, die die Dienstinstanz verwenden möchte. In Kubernetes Service Catalog werden die in einem Bindungsaufruf zurückgegebenen Informationen in einem Kubernetes Secret für den verwendeten Namespace gespeichert. Service Broker legt in einem Bindungsaufruf in der Regel IAM-Berechtigungen für eine Dienstinstanz fest.
  • Service Broker: Sie verwalten den Lebenszyklus von Diensten. Kubernetes Service Catalog nutzt Service Broker für die Bereitstellung und Verwaltung von Dienstinstanzen und Dienstbindungen.
  • Dienstinstanz: Eine Instanziierung eines Dienstangebots.
  • Dienstangebot: Die von einem Service Broker unterstützte Dienstklasse.
  • Dienstplan: Die Darstellung der verschiedenen Optionen oder Stufen eines Dienstangebots. Dies kann sich auf die Kosten auswirken.

Architektur

Die folgenden Diagramme bieten eine Übersicht der OSB-Architektur. Sie zeigen den Fluss zwischen Service Catalog und Service Broker bei der Bereitstellung einer Dienstinstanz und einer Dienstbindung.

Übersicht

Das folgende Diagramm veranschaulicht die Service Broker-Architektur.

Service Catalog ist eine Erweiterungs-API von Kubernetes. In einem Kubernetes-Cluster ausgeführte Anwendungen können damit GCP-Dienste wie Cloud Pub/Sub verwenden. Service Catalog fordert von Service Broker eine Liste verfügbarer Dienste und Pläne an, die dann als Dienstinstanzen bereitgestellt werden können.

Informationen zu einer Serviceinstanz werden in den Ressourcen ServiceInstance und ServiceBinding gespeichert. Nach der Bereitstellung einer Dienstinstanz werden die Zugangsdaten über Kubernetes Secrets für die Anwendung freigegeben.

Dienste und Pläne auflisten

  1. Nachdem die GCP-Ressource ClusterServiceBroker in Service Catalog installiert wurde, stellt Service Catalog eine Verbindung zu Service Broker für die Liste der verfügbaren Dienste und Pläne her.
  2. Die Dienstdetails werden als Ressourcen vom Typ ClusterServiceClass und die zugehörigen Pläne als Ressourcen vom Typ ClusterServicePlan gespeichert.

Unter GCP-Dienste und -Pläne ermitteln wird beschrieben, wie Sie Dienste und Pläne auflisten.

Dienstkontoinstanz und Bindungsfluss

Das folgende Diagramm zeigt die Reihenfolge der Interaktionen zwischen Kubernetes Service Catalog und Service Broker in Verbindung mit einem Cloud IAM-Dienstkonto. Dienstkonten sind für die Authentifizierung bei GCP-Ressourcen erforderlich.

  1. Stellen Sie eine Dienstinstanz eines Cloud IAM-Dienstkontos bereit.
  2. GCP stellt ein neues Dienstkonto bereit. Dieses hat zu dem Zeitpunkt keine Berechtigungen.
  3. Service Broker gibt eine in der Ressource ServiceInstance gespeicherte Instanzbereitstellungsantwort zurück.
  4. Legen Sie die Dienstbindung für die IAM-Dienstkontoinstanz fest.
  5. GCP generiert einen privaten Schlüssel für das Dienstkonto und gibt diesen an die IAM-Dienstkontoinstanz zurück.
  6. Service Broker gibt den privaten Schlüssel für das IAM-Dienstkonto zurück und die Ressource ServiceBinding wird erstellt.
  7. Service Catalog speichert den privaten Schlüssel für das Dienstkonto in einem Secret in einem angegebenen Namespace.
  8. Sie können mit dem Dienstkonto anderen GCP-Ressourcen Rollen zuweisen. Dabei erstellen Sie neue Bindungen und verwenden das Dienstkonto als Eingabe für den Bindungsaufruf.

GCP-Dienstinstanz und Bindungsfluss

Das folgende Diagramm veranschaulicht die Reihenfolge der Interaktionen zwischen Service Catalog und Service Broker in Verbindung mit einem anderen von Service Broker angebotenen GCP-Dienst, in diesem Fall Cloud Pub/Sub.

  1. Stellen Sie eine Dienstinstanz mit einem Dienstplan bereit. Sie können beispielsweise den Cloud Pub/Sub-Dienst mit Plan 1 bereitstellen.
  2. GCP stellt im Projekt eine neue Instanz der Ressource bereit. Für Cloud Pub/Sub stellt GCP ein neues Pub/Sub-Thema bereit.
  3. Service Broker gibt eine in der Ressource ServiceInstance gespeicherte Instanzbereitstellungsantwort zurück.
  4. Legen Sie die Dienstbindung für die Dienstinstanz mit den im Dienstplan definierten Parametern fest. Für Cloud Pub/Sub beinhaltet dies Berechtigungen als IAM-Publisher oder -Abonnent.

    • Geben Sie das zu verwendende Dienstkonto an.

    • Geben Sie die IAM-Rollen an, die dem Dienstkonto zugewiesen werden sollen.

  5. Legen Sie die IAM-Berechtigungen für das Dienstkonto fest. Abhängig vom Ressourcentyp könnten das folgende Berechtigungen sein:

    • IAM-Berechtigungen für die Ressource an sich, beispielsweise bei einer Spanner-Dienstinstanz

    • IAM-Berechtigungen auf Projektebene für Ressourcen, die keine ressourcenspezifischen Berechtigungen unterstützen

  6. Service Broker gibt die Verbindungsinformationen für den Dienst zurück und die Ressource ServiceBinding wird erstellt.

  7. Service Catalog speichert die Verbindungsinformationen für den Dienst in einem Secret in einem angegebenen Namespace.

  8. Die Dienstbindungsinformationen einschließlich der Anmeldedaten für die Verbindung werden in einem Kubernetes Secret für die Anwendung freigegeben.

  9. Die Anwendung greift mit den Bindungsinformationen auf den Dienst zu, beispielsweise Cloud Pub/Sub.

Optional: Sie haben die Möglichkeit, in einem Namespace für dieselbe Dienstinstanz weitere Bindungen mit unterschiedlichen Dienstkonten und Rollen zu erstellen. Auf diese Weise können verschiedene Anwendungen im selben Kubernetes Namespace dasselbe Pub/Sub-Thema verwenden.

Wie Sie eine Dienstinstanz bereitstellen und binden, erfahren Sie unter Google Cloud Platform-Dienst verwenden.

Bereitstellung aufheben und bereinigen

Das folgende Diagramm zeigt, wie Sie die Bereitstellung eines nicht mehr benötigten Dienstes aufheben. Sie vermeiden dadurch, dass Ihrem GCP-Konto ein nicht mehr verwendeter Dienst in Rechnung gestellt werden.

  1. Löschen Sie die Dienstbindung. Service Catalog sendet eine Anfrage zum Aufheben der Bindung an Service Broker.
  2. GCP löscht die IAM-Berechtigungen für die Dienstinstanz.
  3. Service Broker bestätigt, dass die Bindung gelöscht wurde.
  4. Löschen Sie das Kubernetes Secret mit der Dienstbindung und den Verbindungsinformationen.
  5. Löschen Sie die Dienstinstanz. Service Catalog sendet eine Anfrage zum Aufheben der Dienstbereitstellung an Service Broker.
  6. GCP löscht die Dienstinstanz. Bei Cloud Pub/Sub wird das Pub/Sub-Thema gelöscht.
  7. Service Broker bestätigt, dass die Bereitstellung aufgehoben wurde.

Unter Service Catalog bereinigen wird beschrieben, wie Sie die Dienstinstanz und die Bindung löschen und bereinigen.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Dokumentation zu Kubernetes Engine