Configura il networking per Managed Service per Apache Kafka

I client possono connettersi a un cluster Google Cloud Managed Service per Apache Kafka da qualsiasi rete Virtual Private Cloud (VPC) nei tuoi progetti Google Cloud . Puoi anche attivare l'accesso da intervalli IP attendibili tramite internet pubblico.

Questa pagina spiega come viene configurato il networking in Managed Service per Apache Kafka, come attivare le connessioni tra i client Kafka e il cluster e come connettere privatamente client e cluster in progetti diversi.

Una rete VPC è una versione virtuale di una rete fisica, implementata all'interno di Google Cloud. Fornisce connettività di rete sicura e privata per le istanze VM, i workload dei container e altre risorse. Per saperne di più, consulta la panoramica delle reti VPC.

Panoramica

Quando crei un cluster, il servizio inserisce i broker del cluster e gli endpoint di rete in una rete VPC all'interno di un progetto gestito da Google. Questo progetto è chiamato progetto tenant e la rete è chiamata rete tenant. Al contrario, le tue risorse, le applicazioni client e le reti VPC client risiedono nel tuo progetto, chiamato progetto consumer. Ogni cluster Managed Service per Apache Kafka ha la propria rete tenant isolata.

Le reti VPC sono suddivise in partizioni chiamate subnet. Ogni subnet definisce un intervallo di indirizzi IP in una regione specifica della rete cloud. Per consentire alle applicazioni client di comunicare con il cluster, connetti le subnet all'interno delle reti VPC alla rete tenant oppure, facoltativamente, attiva l'accesso pubblico al cluster per connetterti tramite la rete internet pubblica.

Il seguente diagramma mostra due progetti Google Cloud , project-1 e project-2. Un cluster Managed Service per Apache Kafka si trova in project-1.

Un cluster Managed Service per Apache Kafka con tre subnet connesse

Al cluster sono connesse le seguenti subnet:

  • subnet-1, nella rete VPC vpc-1 in project-1.
  • subnet-2, nella rete VPC vpc-2 in project-1.
  • subnet-3, nella rete VPC vpc-3 in project-2.

Connettere le subnet a un cluster

Quando crei un cluster Managed Service per Apache Kafka per la prima volta, devi specificare almeno una subnet. In un secondo momento, puoi aggiornare il cluster per aggiungere o rimuovere le subnet.

Le subnet connesse possono appartenere allo stesso progetto consumer del cluster o a un progetto consumer diverso. Le applicazioni client in qualsiasi regione all'interno delle reti VPC connesse possono connettersi al cluster. Per saperne di più sulle posizioni e sui conteggi delle subnet, consulta Limitazioni.

Per saperne di più su come visualizzare le subnet connesse, vedi Visualizzare un cluster.

Voci DNS del cluster

Quando connetti una subnet a un cluster, il servizio crea voci DNS all'interno della rete di subnet per l'indirizzo di bootstrap e i broker del cluster. I client Kafka utilizzano l'indirizzo di bootstrap per individuare i broker e stabilire una connessione. Quando il server di bootstrap reindirizza un client a un determinato broker, utilizza l'URL del broker anziché un indirizzo IP.

Gli URL di bootstrap e broker sono fissi per la durata di un cluster, ma il formato degli URL potrebbe essere diverso per cluster diversi. Per ottenere l'indirizzo bootstrap di un cluster, consulta Visualizzare l'indirizzo bootstrap di un cluster.

I nomi DNS sono gli stessi in tutte le subnet connesse, anche se corrispondono a indirizzi IP diversi in ogni subnet. Poiché i nomi DNS sono coerenti, tutte le applicazioni client Kafka possono utilizzare lo stesso indirizzo di bootstrap.

Per esempi di applicazioni client che si connettono a Managed Service per Apache Kafka, consulta i seguenti tutorial:

Dimensionamento della subnet

Quando aggiungi una subnet a un cluster, la subnet deve avere un numero sufficiente di indirizzi IP disponibili. Ogni subnet richiede un indirizzo IP per ogni broker Kafka, più un indirizzo IP per l'indirizzo di bootstrap. La dimensione minima del cluster per Managed Service per Apache Kafka è di tre broker, quindi ogni subnet ha bisogno di almeno quattro indirizzi IP utilizzabili, incluso l'indirizzo di bootstrap.

Se il cluster ha più di 45 vCPU, ha un broker per ogni 15 vCPU. In questo caso, calcola il numero minimo di indirizzi IP per ogni subnet come segue:

  1. Dividi il numero di vCPU per 15.
  2. Arrotonda per eccesso al numero intero più vicino.
  3. Aggiungi 1 per tenere conto dell'indirizzo di bootstrap.

Ad esempio, un cluster con 60 vCPU richiede almeno (60/15 + 1) = 5 indirizzi IP utilizzabili.

Google potrebbe modificare il rapporto tra broker e vCPU. Per tenere conto di eventuali modifiche, ti consigliamo di allocare un numero di indirizzi IP tre volte superiore a quello calcolato nel passaggio precedente.

Quando pianifichi le dimensioni della subnet, basa i calcoli sulle dimensioni massime a cui prevedi di scalare il cluster.

Se prevedi di utilizzare Kafka Connect, tieni in considerazione anche i requisiti della subnet per il cluster di connessione. Per saperne di più, vedi subnet worker.

Intervalli IP pubblici utilizzati privatamente

Puoi connettere il cluster a subnet che utilizzano lo spazio di indirizzi non RFC 1918. Questi intervalli di indirizzi IP sono chiamati intervalli di IP pubblici utilizzati privatamente (PUPI).

Non è necessaria alcuna configurazione aggiuntiva per connettersi alle subnet PUPI. Le subnet PUPI devono utilizzare un intervallo IPv4 valido che non sia un intervallo di subnet IPv4 vietato.

Connetti privatamente client e cluster tra i progetti

Se vuoi connettere privatamente i client Kafka in progetti Google Cloud diversi al tuo cluster, puoi utilizzare uno dei seguenti metodi:

Le sezioni seguenti descrivono queste opzioni.

Connettere un cluster tra progetti

Puoi connettere le subnet di altri progetti al tuo cluster. Per attivare l'accesso tra progetti, devi concedere le autorizzazioni al service account gestito da Google associato al cluster. Per ogni progetto in cui vuoi che i client Kafka accedano al cluster, il account di servizio deve disporre del ruolo IAM Agente di servizio Kafka gestito per quel progetto. Questo ruolo consente al cluster di accedere alle risorseGoogle Cloud , in modo che possa creare risorse di rete e voci DNS.

Ad esempio, se project-1 contiene il cluster e vuoi che i client in project-2 accedano al cluster, concedi alaccount di serviziot gestito Kafka per project-1 il ruolo di service agent Kafka gestito su project-2. Poi collega una subnet da project-2 al cluster, come descritto in Connetti le subnet al cluster.

Per concedere i ruoli necessari, segui questi passaggi:

Console

  1. Determina i Google Cloud progetti in cui vuoi che i client Kafka accedano al cluster Managed Service per Apache Kafka.

  2. Per ogni progetto, nella console Google Cloud , vai alla pagina IAM per quel progetto:

    Vai a IAM

  3. Fai clic su Concedi l'accesso.

  4. Nel campo Nuove entità, inserisci quanto segue:

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

    Sostituisci CLUSTER_PROJECT_NUMBER con il numero di progetto del progetto che contiene il cluster Managed Service per Apache Kafka.

  5. Fai clic su Aggiungi ruoli.

  6. Nel campo Cerca ruoli, inserisci Managed Kafka Service Agent. Il nome dell'agente di servizio viene visualizzato nei risultati di ricerca.

  7. Nei risultati di ricerca, seleziona Agente di servizio Kafka gestito.

  8. Fai clic su Applica.

  9. Fai clic su Salva.

gcloud

  1. Determina i Google Cloud progetti in cui vuoi che i client Kafka accedano al cluster Managed Service per Apache Kafka.

  2. Per ogni progetto, esegui il comando gcloud projects add-iam-policy-binding:

    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

    Sostituisci quanto segue:

    • CLIENT_PROJECT_ID: il nome del progetto che contiene la rete VPC da connettere
    • CLUSTER_PROJECT_NUMBER: il numero di progetto del progetto che contiene il cluster Managed Service per Apache Kafka

Utilizzare il VPC condiviso per connettere i progetti

VPC condivisa consente a un'organizzazione di connettere risorse di più progetti a una rete VPC comune. Per utilizzare VPC condivisoC con Managed Service per Apache Kafka, segui questi passaggi:

  1. Crea un cluster Managed Service per Apache Kafka.

  2. Provisioning del VPC condiviso.

  3. Concedi al account di servizio Kafka gestito i ruoli richiesti nel progetto host del VPC condiviso, come descritto nella sezione precedente.

  4. Collega il cluster Managed Service per Apache Kafka a una subnet nella rete VPC condiviso.

I client nel progetto host del VPC condiviso o nei progetti di servizio possono connettersi al cluster.

Per informazioni su quando utilizzare il VPC condiviso nelle architetture di rete, consulta Best practice e architetture di riferimento per la progettazione di VPC.

Connettere i client a un cluster pubblico

Se hai applicazioni client al di fuori della rete VPC, puoi attivare l'accesso pubblico al cluster. Un cluster pubblico richiede comunque una subnet connessa. Tuttavia, non è necessario inviare traffico tramite questo proxy.

Quando attivi la funzionalità del cluster pubblico, il servizio esegue il provisioning di indirizzi IPv4 esterni per gli endpoint di bootstrap e del broker del cluster. Il servizio rende anche le voci DNS del cluster risolvibili pubblicamente in questi indirizzi IP pubblici. Ciò significa che i client esterni possono utilizzare lo stesso indirizzo bootstrap per individuare i broker e stabilire una connessione. Questa implementazione utilizza il DNS split horizon. I client nelle reti VPC che contengono una subnet connessa continuano a risolvere gli endpoint privati, mentre i client in altre reti risolvono gli endpoint pubblici. L'attivazione della funzionalità del cluster pubblico non crea risorse aggiuntive nel tuo progetto consumer.

Quando attivi la funzionalità del cluster pubblico, devi fornire uno o più intervalli IP di origine consentiti. Per ulteriori informazioni sulle dimensioni e sui limiti degli intervalli consentiti, consulta Cluster pubblici o Limitazioni.

Puoi aggiungere o rimuovere intervalli IP di origine consentiti aggiornando il tuo cluster. Managed Service per Apache Kafka utilizza Cloud Next Generation Firewall per limitare l'accesso ai cluster pubblici. La rimozione degli intervalli IP di origine consentiti si applica solo alle nuove connessioni (vedi effetti sul traffico esistente).

Il servizio adotta diverse precauzioni per garantire la sicurezza dei tuoi cluster pubblici. Tutte le connessioni vengono criptate durante il transito utilizzando TLS e tutte richiedono l'autenticazione. Devi autenticarti utilizzando un'identità IAM con SASL o un certificato client con mTLS. L'accesso anonimo non è consentito. Per saperne di più, consulta Tipi di autenticazione per i broker Kafka.

Gli amministratori della sicurezza possono vietare i cluster pubblici attivando il vincolo della policy dell'organizzazione gestita Limitare i cluster Kafka gestiti pubblici (constraints/managedkafka.managed.restrictPublicClusters). Per saperne di più sui vincoli gestiti, vedi Vincoli gestiti.

Configura i firewall in uscita dalle reti esterne

In alcuni scenari, potrebbe essere necessario determinare gli indirizzi IPv4 esterni dei tuoi endpoint di bootstrap e broker. Per istruzioni su come recuperare questi valori, consulta Dettagli del cluster pubblico.

Il servizio rende disponibili queste informazioni nei seguenti modi:

  1. Gli indirizzi IPv4 esterni associati al cluster sono disponibili nell'API Managed Service per Apache Kafka, in gcloud e in Terraform.

  2. Il servizio gestisce uno o più record DNS di rilevamento. Si tratta di record DNS A che contengono tutti gli indirizzi IPv4 esterni associati al tuo cluster. Puoi utilizzare questi record nei firewall basati su FQDN, come Cloud NGFW, che aggiornano automaticamente le regole quando l'elenco degli endpoint cambia. L'elenco degli endpoint di rilevamento è disponibile nell'API, gcloud e Terraform.

Tieni presente quanto segue quando utilizzi gli indirizzi IP pubblici associati al tuo cluster:

  1. L'elenco degli indirizzi IPv4 pubblici associati al cluster potrebbe cambiare o aumentare. Per questo motivo, automatizza il modo in cui utilizzi queste informazioni oppure definisci una procedura per tenere conto dei nuovi record DNS di rilevamento durante lo scale up del cluster. Le modifiche possono verificarsi quando:

    • Scali il cluster. Lo scale up potrebbe aggiungere uno o più indirizzi IPv4 esterni man mano che vengono aggiunti nuovi broker. Per capire in che modo il conteggio delle vCPU influisce sul numero di broker, consulta la sezione Dimensionamento della subnet.

    • Disattivi e poi riattivi la funzionalità cluster pubblico. Questa azione assegna un nuovo insieme di indirizzi IPv4 esterni al cluster.

  2. Ogni record DNS di rilevamento contiene un massimo di 30 indirizzi IP. Questo rientra nei limiti comuni imposti dai firewall FQDN. I cluster con 29 o meno broker hanno un record DNS di rilevamento che contiene 30 indirizzi IPv4 esterni (incluso il record di bootstrap). Il servizio aggiunge un record DNS di rilevamento per ogni 30 broker aggiuntivi. Per capire in che modo il conteggio delle vCPU influisce sul numero di broker, consulta la sezione Dimensionamento delle subnet.

  3. Non configurare i client Kafka per la connessione ai record DNS di rilevamento; configura invece i client per la connessione all'indirizzo di bootstrap. Per ulteriori informazioni, vedi Limitazioni.

  4. Se utilizzi queste informazioni per configurare i firewall in uscita, consenti la connettività alle porte TCP 9092 (SASL) e 9192 (mTLS).

Architettura di rete di un cluster

Questa sezione descrive i dettagli dell'architettura di rete utilizzata in Managed Service per Apache Kafka.

  • Un cluster Kafka si estende su una rete tenant e su una o più reti consumer.

  • Nella rete tenant, il cluster ha un singolo indirizzo IP e URL di bootstrap. Questo indirizzo di bootstrap corrisponde a un bilanciatore del carico connesso a tutti i broker nel cluster. Ogni broker può anche fungere da server di bootstrap, ma ti consigliamo di utilizzare l'indirizzo di bootstrap per affidabilità.

  • All'interno di ogni rete consumer, il servizio crea un endpoint Private Service Connect per l'indirizzo di bootstrap e un endpoint per ogni broker.

  • L'URL dell'indirizzo di bootstrap è lo stesso in tutte le reti VPC a cui è connesso un cluster. L'indirizzo IP è locale per la rete consumer.

  • I client si connettono ai broker Kafka utilizzando i nomi DNS. Questi nomi vengono registrati automaticamente in ogni rete VPC a cui è connesso un cluster Kafka. L'indirizzo di bootstrap e il relativo numero di porta sono disponibili come proprietà del cluster.

  • I client utilizzano l'indirizzo di bootstrap per recuperare gli URL del broker. Questi URL vengono risolti in indirizzi IP locali per ogni rete VPC. Puoi trovare gli indirizzi IP e gli URL del broker effettivi in Cloud DNS.

Il seguente diagramma mostra un'architettura di esempio di una rete di cluster Managed Service per Apache Kafka.

Una rete Managed Service per Apache Kafka * In questo esempio, il cluster ha tre broker e si trova nel VPC tenant.

  • I broker comunicano con i client tramite la porta Kafka predefinita (9092) e hanno indirizzi IP univoci. In questo esempio, i tre broker hanno rispettivamente gli indirizzi IP 10.128.10.2, 10.128.10.3 e 10.128.10.4.

  • Tutti e tre i broker si connettono al bilanciatore del carico di bootstrap. Ciò garantisce alta disponibilità e tolleranza agli errori regionali, perché l'indirizzo di bootstrap non è limitato a un singolo broker o zona.

Limitazioni

Alle connessioni VPC e ai cluster pubblici si applicano le seguenti limitazioni:

  • Regione subnet. Le subnet connesse devono trovarsi nella stessa regione del cluster.

  • Numero di subnet. Puoi connettere un minimo di una e un massimo di dieci subnet a un cluster.

  • Subnet per rete. Puoi connettere al massimo una subnet per rete VPC a un cluster.

  • Dimensioni della subnet. Ogni subnet connessa richiede almeno un indirizzo IP per ogni broker più un indirizzo IP per l'indirizzo di bootstrap. Sono necessari almeno quattro indirizzi IP utilizzabili. Per saperne di più, consulta Dimensionamento delle subnet.

  • Subnet connesse per i cluster pubblici. Per attivare l'accesso pubblico, il tuo cluster deve comunque avere almeno una subnet connessa, anche se non devi inviare traffico tramite questa subnet.

  • Intervalli IP di origine consentiti. Ogni intervallo IP di origine consentito per un cluster pubblico deve essere specificato in notazione CIDR IPv4. Ogni dimensione della subnet CIDR deve essere compresa tra /16 e /32. Gli intervalli CIDR non devono sovrapporsi. Gli indirizzi IPv6 non sono supportati. Puoi specificare un massimo di 500 intervalli IP di origine consentiti.

  • Risoluzione DNS del record di rilevamento. I record DNS di rilevamento sono progettati solo per configurare i firewall di uscita basati su FQDN. Non configurare i client Kafka per connettersi a questi record di rilevamento; configura invece i client per connettersi all'indirizzo di bootstrap.

Risoluzione dei problemi

Per informazioni su come risolvere i problemi di rete, vedi Errori di rete.

Passaggi successivi