Netzwerk für Managed Service for Apache Kafka konfigurieren

Clients können von jedem VPC-Netzwerk (Virtual Private Cloud) in Ihren Google Cloud Projekten aus eine Verbindung zu einem Google Cloud Managed Service for Apache Kafka-Cluster herstellen. Sie können auch den Zugriff von vertrauenswürdigen IP-Bereichen über das öffentliche Internet aktivieren.

Auf dieser Seite wird erläutert, wie die Netzwerkkonfiguration in Managed Service for Apache Kafka eingerichtet wird, wie Sie Verbindungen zwischen Kafka-Clients und Ihrem Cluster aktivieren und wie Sie Clients und Cluster in verschiedenen Projekten privat verbinden.

Ein VPC-Netzwerk ist eine virtuelle Version eines physischen Netzwerks, das in implementiert ist Google Cloud. Es bietet eine sichere, private Netzwerkverbindung für Ihre VM-Instanzen, Containerarbeitslasten und andere Ressourcen. Weitere Informationen finden Sie in der Übersicht zu VPC-Netzwerken.

Übersicht

Wenn Sie einen Cluster erstellen, platziert der Dienst die Clusterbroker und Netzwerkendpunkte in einem VPC-Netzwerk in einem von Google verwalteten Projekt. Dieses Projekt wird als Mandantenprojekt und das Netzwerk als Mandantennetzwerk bezeichnet. Ihre Ressourcen, Clientanwendungen und Client-VPC-Netzwerke befinden sich dagegen in Ihrem eigenen Projekt, das als Nutzerprojekt bezeichnet wird. Jeder Managed Service for Apache Kafka-Cluster hat ein eigenes isoliertes Mandantennetzwerk.

VPC-Netzwerke sind in Partitionen unterteilt, die als Subnetzwerke (Subnetze) bezeichnet werden. Jedes Subnetz definiert einen Bereich von IP-Adressen in einer bestimmten Region Ihres Cloud-Netzwerks. Damit Clientanwendungen mit dem Cluster kommunizieren können, verbinden Sie Subnetze in Ihren VPC-Netzwerken mit dem Mandantennetzwerk oder aktivieren optional den öffentlichen Clusterzugriff, um eine Verbindung über das öffentliche Internet herzustellen.

Das folgende Diagramm zeigt zwei Google Cloud Projekte: project-1 und project-2. Ein Managed Service for Apache Kafka-Cluster befindet sich in project-1.

Ein Managed Service for Apache Kafka-Cluster mit drei verbundenen Subnetzen

Die folgenden Subnetze sind mit dem Cluster verbunden:

  • subnet-1 im VPC-Netzwerk vpc-1 in project-1.
  • subnet-2 im VPC-Netzwerk vpc-2 in project-1.
  • subnet-3 im VPC-Netzwerk vpc-3 in project-2.

Subnetze mit einem Cluster verbinden

Wenn Sie zum ersten Mal einen Managed Service for Apache Kafka-Cluster erstellen, müssen Sie mindestens ein Subnetz angeben. Später können Sie den Cluster aktualisieren, um Subnetze hinzuzufügen oder zu entfernen.

Verbundene Subnetze können demselben Nutzerprojekt wie der Cluster oder einem anderen Nutzerprojekt angehören. Clientanwendungen in jeder Region innerhalb verbundener VPC-Netzwerke können eine Verbindung zum Cluster herstellen. Weitere Informationen zu Subnetzstandorten und ‑anzahlen finden Sie unter Beschränkungen.

Weitere Informationen zum Ansehen verbundener Subnetzwerke finden Sie unter Cluster ansehen.

DNS-Einträge für Cluster

Wenn Sie ein Subnetz mit einem Cluster verbinden, erstellt der Dienst DNS-Einträge in diesem Subnetzwerk für die Bootstrap-Adresse und die Broker des Clusters. Kafka-Clients verwenden die Bootstrap-Adresse, um die Broker zu finden und eine Verbindung herzustellen. Wenn der Bootstrap-Server einen Client zu einem bestimmten Broker weiterleitet, verwendet er die Broker-URL anstelle einer IP-Adresse.

Die Bootstrap- und Broker-URLs sind für die Lebensdauer eines Clusters festgelegt. Das Format der URLs kann jedoch für verschiedene Cluster unterschiedlich sein. Informationen zum Abrufen der Bootstrap-Adresse eines Clusters finden Sie unter Bootstrap-Adresse eines Clusters ansehen.

Die DNS-Namen sind in allen verbundenen Subnetzen gleich, obwohl sie in jedem Subnetz unterschiedlichen IP-Adressen entsprechen. Da die DNS-Namen einheitlich sind, können alle Ihre Kafka-Clientanwendungen dieselbe Bootstrap-Adresse verwenden.

Beispiele für Clientanwendungen, die eine Verbindung zu Managed Service for Apache Kafka herstellen, finden Sie in den folgenden Anleitungen:

Subnetzgröße

Wenn Sie einem Cluster ein Subnetz hinzufügen, muss das Subnetz genügend IP Adressen haben. Jedes Subnetz benötigt eine IP-Adresse für jeden Kafka-Broker sowie eine IP-Adresse für die Bootstrap-Adresse. Die Mindestclustergröße für Managed Service for Apache Kafka beträgt drei Broker. Daher benötigt jedes Subnetz mindestens vier nutzbare IP-Adressen, einschließlich der Bootstrap-Adresse.

Wenn Ihr Cluster mehr als 45 vCPUs hat, hat der Cluster einen Broker für jeweils 15 vCPUs. In diesem Fall berechnen Sie die Mindestanzahl der IP-Adressen für jedes Subnetz so:

  1. Teilen Sie die Anzahl der vCPUs durch 15.
  2. Runden Sie auf die nächste ganze Zahl auf.
  3. Addieren Sie 1 für die Bootstrap-Adresse.

Ein Cluster mit 60 vCPUs benötigt beispielsweise mindestens (60/15 + 1) = 5 nutzbare IP-Adressen.

Google kann das Verhältnis von Brokern zu vCPUs ändern. Um Änderungen zu berücksichtigen, empfehlen wir, die dreifache Anzahl der im vorherigen Schritt berechneten IP-Adressen zuzuweisen.

Wenn Sie die Subnetzgröße planen, basieren Sie Ihre Berechnungen auf der maximalen Größe, auf die Sie Ihren Cluster skalieren möchten.

Wenn Sie Kafka Connect verwenden möchten, berücksichtigen Sie auch die Subnetzanforderungen für den Connect-Cluster. Weitere Informationen finden Sie unter Worker Subnetz.

Privat verwendete öffentliche IP-Bereiche

Sie können Ihren Cluster mit Subnetzen verbinden, die den Adressraum außerhalb von RFC 1918 verwenden. Solche IP-Adressbereiche werden als privat verwendete öffentliche IP-Bereiche (Privately Used Public IP, PUPI) bezeichnet.

Für die Verbindung zu PUPI-Subnetzen ist keine zusätzliche Konfiguration erforderlich. Die PUPI Subnetze müssen einen gültigen IPv4-Bereich verwenden, der kein verbotener IPv4-Subnetzbereich ist.

Clients und Cluster in verschiedenen Projekten privat verbinden

Wenn Sie Kafka-Clients in verschiedenen Google Cloud Projekten privat mit Ihrem Cluster verbinden möchten, haben Sie folgende Möglichkeiten:

In den folgenden Abschnitten werden diese Optionen beschrieben.

Cluster projektübergreifend verbinden

Sie können Subnetze aus anderen Projekten mit Ihrem Cluster verbinden. Um den projektübergreifenden Zugriff zu aktivieren, müssen Sie dem von Google verwalteten Dienstkonto, das mit dem Cluster verknüpft ist, Berechtigungen erteilen. Für jedes Projekt, in dem Kafka-Clients auf den Cluster zugreifen sollen, muss das Dienstkonto die Managed Kafka Service Agent IAM-Rolle für dieses Projekt haben. Mit dieser Rolle kann der Cluster auf Google Cloud Ressourcen zugreifen, sodass er Netzwerkressourcen und DNS Einträge erstellen kann.

Wenn project-1 beispielsweise den Cluster enthält und Clients in project-2 auf den Cluster zugreifen sollen, erteilen Sie dem Managed Kafka-Dienstkonto für project-1 die Rolle „Managed Kafka Service Agent“ für project-2. Verbinden Sie dann ein Subnetz aus project-2 mit dem Cluster, wie unter Subnetze mit einem Cluster verbinden beschrieben.

So erteilen Sie die erforderlichen Rollen:

Console

  1. Bestimmen Sie die Google Cloud Projekte, in denen Ihre Kafka Clients auf den Managed Service for Apache Kafka-Cluster zugreifen sollen.

  2. Rufen Sie für jedes Projekt in der Google Cloud Console die Seite IAM für dieses Projekt auf:

    IAM aufrufen

  3. Klicken Sie auf Zugriffsrechte erteilen.

  4. Geben Sie im Feld Neue Hauptkonten Folgendes ein:

    service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com

    Ersetzen Sie CLUSTER_PROJECT_NUMBER durch die Projektnummer des Projekts, das den Managed Service for Apache Kafka Cluster enthält.

  5. Klicken Sie auf Rollen hinzufügen.

  6. Geben Sie im Feld Nach Rollen suchen Managed Kafka Service Agent ein. Der Name des Dienst-Agents wird in den Suchergebnissen angezeigt.

  7. Wählen Sie in den Suchergebnissen Managed Kafka Service Agent aus.

  8. Klicken Sie auf Übernehmen.

  9. Klicken Sie auf Speichern.

gcloud

  1. Bestimmen Sie die Google Cloud Projekte, in denen Ihre Kafka Clients auf den Managed Service for Apache Kafka-Cluster zugreifen sollen.

  2. Führen Sie für jedes Projekt den gcloud projects add-iam-policy-binding Befehl aus:

    gcloud projects add-iam-policy-binding CLIENT_PROJECT_ID \
    --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \
    --role=roles/managedkafka.serviceAgent

    Ersetzen Sie Folgendes:

    • CLIENT_PROJECT_ID: der Name des Projekts, das das zu verbindende VPC-Netzwerk enthält
    • CLUSTER_PROJECT_NUMBER: die Projekt nummer des Projekts, das den Managed Service for Apache Kafka-Cluster enthält

Gemeinsam genutzte VPC verwenden, um Projekte zu verbinden

Mit einer gemeinsam genutzten VPC können Unternehmen Ressourcen aus mehreren Projekten in einem gemeinsamen VPC-Netzwerk zusammenführen. So verwenden Sie eine freigegebene VPC mit Managed Service for Apache Kafka:

  1. Erstellen Sie einen Managed Service for Apache Kafka-Cluster.

  2. Stellen Sie eine gemeinsam genutzte VPC bereit.

  3. Erteilen Sie dem Managed Kafka-Dienstkonto die erforderlichen Rollen im Hostprojekt der freigegebene VPC, wie im vorherigen Abschnitt beschrieben.

  4. Verbinden Sie den Managed Service for Apache Kafka-Cluster mit einem Subnetz im freigegebene VPC-Netzwerk.

Clients im Hostprojekt der freigegebene VPC oder in den Dienstprojekten können eine Verbindung zum Cluster herstellen.

Informationen dazu, wann Sie eine freigegebene VPC in Ihren Netzwerk architekturen verwenden sollten, finden Sie unter Best Practices und Referenzarchitekturen für das VPC-Design.

Clients mit einem öffentlichen Cluster verbinden

Wenn Sie Clientanwendungen außerhalb Ihres VPC-Netzwerk haben, können Sie den öffentlichen Zugriff auf Ihren Cluster aktivieren. Für einen öffentlichen Cluster ist weiterhin ein verbundenes Subnetz erforderlich. Sie müssen jedoch keinen Traffic darüber senden.

Wenn Sie das Feature für öffentliche Cluster aktivieren, stellt der Dienst externe IPv4-Adressen für die Broker- und Bootstrap-Endpunkte des Clusters bereit. Außerdem werden die DNS-Einträge des Clusters öffentlich in diese öffentlichen IP-Adressen aufgelöst. Das bedeutet, dass externe Clients dieselbe Bootstrap-Adresse verwenden können, um die Broker zu finden und eine Verbindung herzustellen. Bei dieser Implementierung wird Split-Horizon-DNS verwendet. Clients in VPC-Netzwerken, die ein verbundenes Subnetz enthalten, lösen weiterhin die privaten Endpunkte auf, während Clients in anderen Netzwerken die öffentlichen Endpunkte auflösen. Wenn Sie das Feature für öffentliche Cluster aktivieren, werden keine zusätzlichen Ressourcen in Ihrem Nutzerprojekt erstellt.

Wenn Sie das Feature für öffentliche Cluster aktivieren, müssen Sie einen oder mehrere zulässige Quell-IP-Bereiche angeben. Weitere Informationen zu zulässigen Bereichsgrößen und Limits finden Sie unter Öffentliche Cluster oder Beschränkungen.

Sie können zulässige Quell-IP-Bereiche hinzufügen oder entfernen, indem Sie Ihren Cluster aktualisieren. Managed Service for Apache Kafka verwendet die Cloud Next Generation Firewall, um den Zugriff auf öffentliche Cluster einzuschränken. Das Entfernen zulässiger Quell-IP-Bereiche gilt nur für neue Verbindungen (siehe Auswirkungen auf vorhandenen Traffic).

Der Dienst ergreift mehrere Maßnahmen, um die Sicherheit Ihrer öffentlichen Cluster zu gewährleisten. Alle Verbindungen werden während der Übertragung mit TLS verschlüsselt und alle Verbindungen erfordern eine Authentifizierung. Sie müssen sich mit einer IAM-Identität mit SASL oder einem Clientzertifikat mit mTLS authentifizieren. Anonymer Zugriff ist nicht zulässig. Weitere Informationen finden Sie unter Authentifizierungstypen für Kafka-Broker.

Sicherheitsadministratoren können öffentliche Cluster in Ihrem Projekt mit einer benutzerdefinierten Einschränkung für Organisationsrichtlinien verbieten. Weitere Informationen zu Organisations richtlinien finden Sie unter Benutzerdefinierte Einschränkungen erstellen.

Firewalls für ausgehenden Traffic von externen Netzwerken konfigurieren

In einigen Fällen müssen Sie möglicherweise die externen IPv4-Adressen Ihrer Broker- und Bootstrap-Endpunkte ermitteln. Eine Anleitung zum Abrufen dieser Werte finden Sie unter Details zu öffentlichen Clustern.

Der Dienst stellt diese Informationen auf folgende Weise zur Verfügung:

  1. Die externen IPv4-Adressen, die mit Ihrem Cluster verknüpft sind, sind in der Managed Service for Apache Kafka API, gcloud und Terraform verfügbar.

  2. Der Dienst verwaltet einen oder mehrere Discovery-DNS-Einträge. Das sind DNS-A-Einträge, die alle externen IPv4-Adressen enthalten, die mit Ihrem Cluster verknüpft sind. Sie können diese Einträge in FQDN-basierten Firewalls wie Cloud NGFW verwenden, die Regeln automatisch aktualisieren, wenn sich die Liste der Endpunkte ändert. Die Liste der Discovery-Endpunkte ist in der API, gcloud und Terraform verfügbar.

Beachten Sie Folgendes, wenn Sie die öffentlichen IP-Adressen verwenden, die mit Ihrem Cluster verknüpft sind:

  1. Die Liste der öffentlichen IPv4-Adressen, die mit Ihrem Cluster verknüpft sind, kann sich ändern oder wachsen. Automatisieren Sie daher die Verwendung dieser Informationen oder definieren Sie einen Prozess, um neue Discovery-DNS-Einträge beim Hochskalieren Ihres Clusters zu berücksichtigen. Änderungen können auftreten, wenn:

    • Sie Ihren Cluster skalieren. Beim Hochskalieren können eine oder mehrere externe IPv4-Adressen hinzugefügt werden, wenn neue Broker hinzugefügt werden. Informationen dazu, wie sich die Anzahl der vCPUs auf die Anzahl der Broker auswirkt, finden Sie unter Subnetz größe.

    • Sie das Feature für öffentliche Cluster deaktivieren und dann wieder aktivieren. Durch diese Aktion wird dem Cluster ein neuer Satz externer IPv4-Adressen zugewiesen.

  2. Jeder Discovery-DNS-Eintrag enthält maximal 30 IP-Adressen. Dies liegt innerhalb der üblichen Limits, die von FQDN-Firewalls erzwungen werden. Cluster mit 29 oder weniger Brokern haben einen Discovery-DNS-Eintrag, der 30 externe IPv4-Adressen enthält (einschließlich des Bootstrap-Eintrags). Der Dienst fügt für jeweils 30 zusätzliche Broker einen Discovery-DNS-Eintrag hinzu. Informationen dazu, wie sich die Anzahl der vCPUs auf die Anzahl der Broker auswirkt, finden Sie unter Subnetzgröße.

  3. Konfigurieren Sie Ihre Kafka-Clients nicht so, dass sie eine Verbindung zu Discovery-DNS-Einträgen herstellen. Konfigurieren Sie stattdessen Clients so, dass sie eine Verbindung zur Bootstrap-Adresse herstellen. Weitere Informationen finden Sie unter Beschränkungen.

  4. Wenn Sie diese Informationen zum Konfigurieren von Firewalls für ausgehenden Traffic verwenden, lassen Sie Verbindungen zu den TCP-Ports 9092 (SASL) und 9192 (mTLS) zu.

Netzwerkarchitektur eines Clusters

In diesem Abschnitt werden die Details der Netzwerkarchitektur beschrieben, die in Managed Service for Apache Kafka verwendet wird.

  • Ein Kafka-Cluster umfasst ein Mandantennetzwerk und ein oder mehrere Nutzernetzwerke.

  • Im Mandantennetzwerk hat der Cluster eine einzelne Bootstrap-IP-Adresse und ‑URL. Diese Bootstrap-Adresse entspricht einem Load-Balancer, der mit allen Brokern im Cluster verbunden ist. Jeder Broker kann auch einzeln als Bootstrap-Server fungieren. Wir empfehlen jedoch, aus Zuverlässigkeitsgründen die Bootstrap-Adresse zu verwenden.

  • In jedem Nutzernetzwerk erstellt der Dienst einen Private Service Connect Endpunkt für die Bootstrap-Adresse und einen Endpunkt für jeden Broker.

  • Die URL für die Bootstrap-Adresse ist in allen VPC-Netzwerken gleich, mit denen ein Cluster verbunden ist. Die IP-Adresse ist lokal für das Nutzernetzwerk.

  • Clients stellen über DNS-Namen eine Verbindung zu Kafka-Brokern her. Diese Namen werden automatisch in jedem VPC-Netzwerk registriert, mit dem ein Kafka-Cluster verbunden ist. Die Bootstrap-Adresse und die zugehörige Portnummer sind als Eigenschaft des Clusters verfügbar.

  • Clients verwenden die Bootstrap-Adresse, um Broker-URLs abzurufen. Diese URLs werden in IP-Adressen aufgelöst, die für jedes VPC-Netzwerk lokal sind. Die tatsächlichen Broker-IP-Adressen und ‑URLs finden Sie in Cloud DNS.

Das folgende Diagramm zeigt eine Beispielarchitektur eines Managed Service for Apache Kafka-Clusternetzwerks.

Ein Managed Service for Apache Kafka-Netzwerk * In diesem Beispiel hat der Cluster drei Broker und befindet sich in der VPC des Mandanten.

  • Broker kommunizieren über den Standard-Kafka-Port (9092) mit Clients und haben eindeutige IP-Adressen. In diesem Beispiel haben die drei Broker die IP-Adressen 10.128.10.2, 10.128.10.3 und 10.128.10.4.

  • Alle drei Broker stellen eine Verbindung zum Bootstrap-Load-Balancer her. Dies sorgt für Hochverfügbarkeit und regionale Fehlertoleranz, da die Bootstrap-Adresse nicht auf einen einzelnen Broker oder eine einzelne Zone beschränkt ist.

Beschränkungen

Die folgenden Beschränkungen gelten für VPC-Verbindungen und öffentliche Cluster:

  • Subnetzregion Verbundene Subnetze müssen sich in derselben Region wie Ihr Cluster befinden.

  • Anzahl der Subnetze Sie können mindestens ein und maximal zehn Subnetze mit einem Cluster verbinden.

  • Subnetze pro Netzwerk Sie können maximal ein Subnetz pro VPC-Netzwerk mit einem Cluster verbinden.

  • Subnetzgröße Jedes verbundene Subnetz benötigt mindestens eine IP-Adresse für jeden Broker sowie eine IP-Adresse für die Bootstrap-Adresse. Es sind mindestens vier nutzbare IP-Adressen erforderlich. Weitere Informationen finden Sie unter Subnetz größe.

  • Verbundene Subnetze für öffentliche Cluster Um den öffentlichen Zugriff zu aktivieren, muss Ihr Cluster weiterhin mindestens ein verbundenes Subnetz haben. Sie müssen jedoch keinen Traffic darüber senden.

  • Zulässige Quell-IP-Bereiche Jeder zulässige Quell-IP-Bereich für einen öffentlichen Cluster muss in IPv4-CIDR-Notation angegeben werden. Jede CIDR-Subnetzgröße muss zwischen /16 und /32 liegen. CIDR-Bereiche dürfen sich nicht überschneiden. IPv6-Adressen werden nicht unterstützt. Sie können maximal 500 zulässige Quell-IP-Bereiche angeben.

  • DNS-Auflösung von Discovery-Einträgen Discovery-DNS-Einträge sind nur für die Konfiguration von FQDN-basierten Firewalls für ausgehenden Traffic vorgesehen. Konfigurieren Sie Ihre Kafka-Clients nicht so, dass sie eine Verbindung zu diesen Discovery-Einträgen herstellen. Konfigurieren Sie stattdessen Clients so, dass sie eine Verbindung zur Bootstrap-Adresse herstellen.

Fehlerbehebung

Informationen zur Fehlerbehebung bei Netzwerkproblemen finden Sie unter Networking errors.

Nächste Schritte