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 VPC (Virtual Private Cloud) nei tuoi Google Cloud progetti. 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 privata e sicura per le istanze VM, i carichi di lavoro 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 e gli endpoint di rete del cluster 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 internet pubblico.

Il seguente diagramma mostra due Google Cloud progetti, 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

Le seguenti subnet sono connesse al cluster:

  • 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 per la prima volta un cluster Managed Service per Apache Kafka, devi specificare almeno una subnet. In un secondo momento, puoi aggiornare il cluster per aggiungere o rimuovere 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 sul numero di subnet, vedi 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 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 broker specifico, 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 di bootstrap di un cluster, vedi Visualizzare l'indirizzo di 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 nel seguente modo:

  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 ha bisogno di almeno (60/15 + 1) = 5 indirizzi IP utilizzabili.

Google potrebbe modificare il rapporto tra broker e vCPU. Per adattarti a eventuali modifiche, ti consigliamo di allocare il triplo del numero di indirizzi IP calcolato nel passaggio precedente.

Quando pianifichi la dimensione della subnet, basa i calcoli sulla dimensione massima a cui prevedi di scalare il cluster.

Se prevedi di utilizzare Kafka Connect, allora tieni conto anche dei 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 IP pubblici utilizzati privatamente (PUPI).

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

Connettere privatamente client e cluster tra progetti

Se vuoi connettere privatamente i client Kafka in diversi Google Cloud progetti 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 avere il ruolo IAM Managed Kafka Service Agent in quel progetto. Questo ruolo consente al cluster di accedere alle Google Cloud risorse, 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 al account di servizio Managed Kafka per project-1 il ruolo Service Agent Managed Kafka in project-2. Quindi connetti una subnet da project-2 al cluster, come descritto in Connettere 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 Google Cloud console, vai alla pagina IAM per quel progetto:

    Vai a IAM

  3. Fai clic su Concedi l'accesso.

  4. Nel campo Nuovi principal, 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 del service agent viene visualizzato nei risultati di ricerca.

  7. Nei risultati di ricerca, seleziona Service Agent Managed Kafka.

  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 gcloud projects add-iam-policy-binding comando:

    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

Il VPC condiviso consente a un'organizzazione di connettere risorse di più progetti a una rete VPC comune. Per utilizzare il VPC condiviso 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 Managed Kafka i ruoli richiesti nel progetto host del VPC condiviso, come descritto nella sezione precedente.

  4. Connetti 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, vedi Best practice e architetture di riferimento per la progettazione di VPC.

Connettere i client a un cluster pubblico

Se hai applicazioni client esterne alla rete VPC, puoi attivare l'accesso pubblico al cluster. Un cluster pubblico richiede comunque una subnet connessa. Tuttavia, non è necessario inviare traffico tramite questa subnet.

Quando attivi la funzionalità del cluster pubblico, il servizio esegue il provisioning degli indirizzi IPv4 esterni per gli endpoint di bootstrap e broker del cluster. Il servizio rende anche le voci DNS del cluster risolvibili pubblicamente a questi indirizzi IP pubblici. Ciò significa che i client esterni possono utilizzare lo stesso indirizzo di 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 progetto consumer.

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

Puoi aggiungere o rimuovere intervalli IP di origine consentiti aggiornando il 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 gli effetti sul traffico esistente).

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

Gli amministratori della sicurezza possono vietare i cluster pubblici nel tuo progetto con un vincolo di policy dell'organizzazione personalizzato. Per saperne di più sulle policy dell'organizzazione, vedi Creare vincoli personalizzati.

Configurare i firewall in uscita dalle reti esterne

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

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 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, in gcloud e in Terraform.

Tieni presente quanto segue quando utilizzi gli indirizzi IP pubblici associati al 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 o definisci una procedura per tenere conto dei nuovi record DNS di rilevamento quando esegui lo scale up del cluster. Le modifiche possono verificarsi quando:

    • Esegui lo scale up del 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 numero di vCPU influisce sul numero di broker, vedi Dimensionamento della subnet.

    • Disattivi e poi riattivi la funzionalità del 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 valore rientra nei limiti comuni applicati 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 numero di vCPU influisce sul numero di broker, vedi Dimensionamento della subnet.

  3. Non configurare i client Kafka in modo che si connettano ai record DNS di rilevamento; configura invece i client in modo che si connettano all'indirizzo di bootstrap. Per saperne di più, 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 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 del cluster. Ogni broker può anche fungere da server di bootstrap, ma ti consigliamo di utilizzare l'indirizzo di bootstrap per l'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 alla 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 dei broker. Questi URL vengono risolti in indirizzi IP locali per ogni rete VPC. Puoi trovare gli indirizzi IP e gli URL dei 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. In questo modo si garantisce l'alta affidabilità e la tolleranza agli errori regionali, perché l'indirizzo di bootstrap non è limitato a un singolo broker o zona.

Limitazioni

Le seguenti limitazioni si applicano alle connessioni VPC e ai cluster pubblici:

  • Regione della 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.

  • Dimensione 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ù, vedi Dimensionamento della subnet.

  • Subnet connesse per cluster pubblici. Per attivare l'accesso pubblico, il cluster deve comunque avere almeno una subnet connessa, anche se non è necessario 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. La dimensione di ogni 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 dei record di rilevamento. I record DNS di rilevamento sono progettati solo per configurare i firewall in uscita basati su FQDN. Non configurare i client Kafka in modo che si connettano a questi record di rilevamento; configura invece i client in modo che si connettano all'indirizzo di bootstrap.

Risoluzione dei problemi

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

Passaggi successivi