Configurer la mise en réseau pour Managed Service pour Apache Kafka

Les clients peuvent se connecter à un cluster Google Cloud Managed Service pour Apache Kafka à partir de n'importe quel réseau cloud privé virtuel (VPC) de vos Google Cloud projets. Vous pouvez également activer l'accès à partir de plages d'adresses IP approuvées sur l'Internet public.

Cette page explique comment la mise en réseau est configurée dans Managed Service pour Apache Kafka, comment activer les connexions entre les clients Kafka et votre cluster, et comment connecter des clients et des clusters de manière privée dans différents projets.

Un réseau VPC est une version virtuelle d'un réseau physique, mise en œuvre en interne Google Cloud. Il fournit une connectivité réseau privée et sécurisée pour vos instances de VM, vos charges de travail de conteneur et d'autres ressources. Pour en savoir plus, consultez la présentation des réseaux VPC.

Présentation

Lorsque vous créez un cluster, le service place les agents de cluster et les points de terminaison réseau dans un réseau VPC au sein d'un projet géré par Google. Ce projet est appelé projet locataire et le réseau est appelé réseau locataire. En revanche, vos ressources, vos applications clientes et vos réseaux VPC clients résident dans votre propre projet, appelé projet consommateur. Chaque cluster Managed Service pour Apache Kafka possède son propre réseau locataire isolé.

Les réseaux VPC sont divisés en partitions appelées sous-réseaux. Chaque sous-réseau définit une plage d'adresses IP dans une région spécifique de votre réseau cloud. Pour permettre aux applications clientes de communiquer avec le cluster, vous connectez des sous-réseaux au sein de vos réseaux VPC au réseau locataire ou, si vous le souhaitez, vous activez l'accès public au cluster pour vous connecter via l'Internet public.

Le schéma suivant présente deux Google Cloud projets, project-1 et project-2. Un cluster Managed Service pour Apache Kafka se trouve dans project-1.

Cluster Managed Service pour Apache Kafka avec trois sous-réseaux connectés

Les sous-réseaux suivants sont connectés au cluster :

  • subnet-1, dans le réseau VPC vpc-1 de project-1.
  • subnet-2, dans le réseau VPC vpc-2 de project-1.
  • subnet-3, dans le réseau VPC vpc-3 de project-2.

Connecter des sous-réseaux à un cluster

Lorsque vous créez un cluster Managed Service pour Apache Kafka, vous devez spécifier au moins un sous-réseau. Vous pouvez ensuite mettre à jour le cluster pour ajouter ou supprimer des sous-réseaux.

Les sous-réseaux connectés peuvent appartenir au même projet consommateur que le cluster ou à un autre projet consommateur. Les applications clientes de n'importe quelle région au sein des réseaux VPC connectés peuvent se connecter au cluster. Pour en savoir plus sur les emplacements et le nombre de sous-réseaux, consultez la section Limites.

Pour en savoir plus sur l'affichage des sous-réseaux connectés, consultez la section Afficher un cluster.

Entrées DNS du cluster

Lorsque vous connectez un sous-réseau à un cluster, le service crée des entrées DNS dans ce réseau de sous-réseau pour l'adresse d'amorçage et les agents du cluster. Les clients Kafka utilisent l'adresse d'amorçage pour localiser les agents et établir une connexion. Lorsque le serveur d'amorçage redirige un client vers un agent particulier, il utilise l'URL de l'agent plutôt qu'une adresse IP.

Les URL d'amorçage et d'agent sont fixes pendant toute la durée de vie d'un cluster, mais leur format peut varier d'un cluster à l'autre. Pour obtenir l'adresse d'amorçage d'un cluster, consultez la section Afficher l'adresse d'amorçage d'un cluster.

Les noms DNS sont les mêmes dans tous les sous-réseaux connectés, bien qu'ils correspondent à des adresses IP différentes dans chaque sous-réseau. Étant donné que les noms DNS sont cohérents, toutes vos applications clientes Kafka peuvent utiliser la même adresse d'amorçage.

Pour obtenir des exemples d'applications clientes qui se connectent à Managed Service pour Apache Kafka, consultez les tutoriels suivants :

Dimensionnement du sous-réseau

Lorsque vous ajoutez un sous-réseau à un cluster, il doit disposer de suffisamment d'adresses IP disponibles. Chaque sous-réseau nécessite une adresse IP pour chaque agent Kafka, plus une adresse IP pour l'adresse d'amorçage. La taille minimale du cluster pour Managed Service pour Apache Kafka est de trois agents. Chaque sous-réseau a donc besoin d'au moins quatre adresses IP utilisables, y compris l'adresse d'amorçage.

Si votre cluster comporte plus de 45 processeurs virtuels, il dispose d'un agent pour 15 processeurs virtuels. Dans ce cas, calculez le nombre minimal d'adresses IP pour chaque sous-réseau comme suit :

  1. Divisez le nombre de processeurs virtuels par 15.
  2. Arrondissez à l'entier supérieur le plus proche.
  3. Ajoutez 1 pour tenir compte de l'adresse d'amorçage.

Par exemple, un cluster avec 60 processeurs virtuels a besoin d'au moins (60/15 + 1) = 5 adresses IP utilisables.

Google peut modifier le rapport entre les agents et les processeurs virtuels. Pour tenir compte de ces modifications, nous vous recommandons d'allouer trois fois le nombre d'adresses IP calculé à l'étape précédente.

Lorsque vous planifiez la taille du sous-réseau, basez vos calculs sur la taille maximale à laquelle vous prévoyez de faire évoluer votre cluster.

Si vous prévoyez d'utiliser Kafka Connect, tenez également compte des exigences de sous-réseau pour le cluster Connect. Pour en savoir plus, consultez la section Sous-réseau de nœud de calcul.

Plages d'adresses IP publiques utilisées en mode privé

Vous pouvez connecter votre cluster à des sous-réseaux qui utilisent l'espace d'adressage non-RFC 1918. Ces plages d'adresses IP sont appelées plages d'adresses IP publiques utilisées en mode privé (PUPI).

Aucune configuration supplémentaire n'est requise pour vous connecter aux sous-réseaux PUPI. Les sous-réseaux PUPI doivent utiliser une plage IPv4 valide qui n'est pas une plage de sous-réseaux IPv4 interdite.

Connecter des clients et des clusters de manière privée dans différents projets

Si vous souhaitez connecter des clients Kafka dans différents Google Cloud projets à votre cluster de manière privée, vous pouvez utiliser l'une des méthodes suivantes :

Les sections suivantes décrivent ces options.

Connecter un cluster dans différents projets

Vous pouvez connecter des sous-réseaux d'autres projets à votre cluster. Pour activer l'accès entre projets, vous devez accorder des autorisations au compte de service géré par Google associé au cluster. Pour chaque projet dans lequel vous souhaitez que les clients Kafka accèdent au cluster, le compte de service doit disposer du rôle IAM "Agent de service Kafka géré" sur ce projet. Ce rôle permet au cluster d'accéder aux Google Cloud ressources afin qu'il puisse créer des ressources réseau et des entrées DNS.

Par exemple, si project-1 contient le cluster et que vous souhaitez que les clients de project-2 y accèdent, accordez au compte de service Kafka géré pour project-1 le rôle "Agent de service Kafka géré" sur project-2. Connectez ensuite un sous-réseau de project-2 au cluster, comme décrit dans la section Connecter des sous-réseaux au cluster.

Pour attribuer les rôles nécessaires, procédez comme suit :

Console

  1. Déterminez les Google Cloud projets dans lesquels vous souhaitez que vos clients Kafka accèdent au cluster Managed Service pour Apache Kafka.

  2. Pour chaque projet, dans la Google Cloud console, accédez à la page IAM de ce projet :

    Accéder à IAM

  3. Cliquez sur Accorder l'accès.

  4. Dans le champ Nouveaux comptes principaux, saisissez les éléments suivants :

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

    Remplacez CLUSTER_PROJECT_NUMBER par le numéro de projet du projet contenant le cluster Managed Service pour Apache Kafka.

  5. Cliquez sur Ajouter des rôles.

  6. Dans le champ Rechercher des rôles, saisissez Managed Kafka Service Agent. Le nom de l'agent de service s'affiche dans les résultats de recherche.

  7. Dans les résultats de recherche, sélectionnez Agent de service Kafka géré.

  8. Cliquez sur Appliquer.

  9. Cliquez sur Enregistrer.

gcloud

  1. Déterminez les Google Cloud projets dans lesquels vous souhaitez que vos clients Kafka accèdent au cluster Managed Service pour Apache Kafka.

  2. Pour chaque projet, exécutez la gcloud projects add-iam-policy-binding commande :

    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

    Remplacez les éléments suivants :

    • CLIENT_PROJECT_ID : nom du projet contenant le réseau VPC à connecter.
    • CLUSTER_PROJECT_NUMBER : numéro de projet du projet contenant le cluster Managed Service pour Apache Kafka.

Utiliser un VPC partagé pour connecter des projets

Un VPC partagé permet à une organisation de connecter des ressources provenant de différents projets à un réseau VPC commun. Pour utiliser un VPC partagé avec Managed Service pour Apache Kafka, procédez comme suit :

  1. Créez un cluster Managed Service pour Apache Kafka.

  2. Provisionnez un VPC partagé.

  3. Accordez au compte de service Kafka géré les rôles requis dans le projet hôte du VPC partagé, comme décrit dans la section précédente.

  4. Connectez le cluster Managed Service pour Apache Kafka à un sous-réseau du réseau VPC partagé.

Les clients du projet hôte du VPC partagé ou des projets de service peuvent se connecter au cluster.

Pour savoir quand utiliser un VPC partagé dans vos architectures réseau, consultez la section Bonnes pratiques et architectures de référence pour la conception de VPC.

Connecter des clients à un cluster public

Si vous avez des applications clientes en dehors de votre réseau VPC, vous pouvez activer l'accès public à votre cluster. Un cluster public nécessite toujours un sous-réseau connecté. Toutefois, vous n'avez pas besoin d'y envoyer du trafic.

Lorsque vous activez la fonctionnalité de cluster public, le service provisionne des adresses IPv4 externes pour les points de terminaison d'agent et d'amorçage du cluster. Le service rend également les entrées DNS du cluster publiquement résolvables en ces adresses IP publiques. Cela signifie que les clients externes peuvent utiliser la même adresse d'amorçage pour localiser les agents et établir une connexion. Cette implémentation utilise un DNS fractionné. Les clients des réseaux VPC contenant un sous-réseau connecté continuent de résoudre les points de terminaison privés, tandis que les clients d'autres réseaux résolvent les points de terminaison publics. L'activation de la fonctionnalité de cluster public ne crée pas de ressources supplémentaires dans votre projet consommateur.

Lorsque vous activez la fonctionnalité de cluster public, vous devez fournir une ou plusieurs plages d'adresses IP sources autorisées. Pour en savoir plus sur les tailles et les limites des plages autorisées, consultez la section Clusters publics ou Limites.

Vous pouvez ajouter ou supprimer des plages d'adresses IP sources autorisées en mettant à jour votre cluster. Managed Service pour Apache Kafka utilise Cloud Next Generation Firewall pour limiter l'accès aux clusters publics. La suppression des plages d'adresses IP sources autorisées ne s'applique qu'aux nouvelles connexions (voir les effets sur le trafic existant).

Le service prend plusieurs précautions pour garantir la sécurité de vos clusters publics. Toutes les connexions sont chiffrées en transit à l'aide du protocole TLS et toutes les connexions nécessitent une authentification. Vous devez vous authentifier à l'aide d'une identité IAM avec SASL ou d'un certificat client avec mTLS. L'accès anonyme n'est pas autorisé. Pour en savoir plus, consultez la section Types d'authentification pour les agents Kafka.

Les administrateurs de la sécurité peuvent interdire les clusters publics dans votre projet à l'aide d'une contrainte de règle d'administration personnalisée. Pour en savoir plus sur les règles d'administration, consultez la section Créer des contraintes personnalisées.

Configurer les pare-feu de sortie à partir de réseaux externes

Dans certains cas, vous devrez peut-être déterminer les adresses IPv4 externes de vos points de terminaison d'agent et d'amorçage. Pour savoir comment récupérer ces valeurs, consultez la section Détails du cluster public.

Le service met ces informations à disposition de différentes manières :

  1. Les adresses IPv4 externes associées à votre cluster sont disponibles dans l'API Managed Service pour Apache Kafka, gcloud et Terraform.

  2. Le service gère un ou plusieurs enregistrements DNS de découverte. Il s'agit d'enregistrements DNS A qui contiennent toutes les adresses IPv4 externes associées à votre cluster. Vous pouvez utiliser ces enregistrements dans des pare-feu basés sur un nom de domaine complet, tels que Cloud NGFW, qui mettent automatiquement à jour les règles lorsque la liste des points de terminaison change. La liste des points de terminaison de découverte est disponible dans l'API, gcloud et Terraform.

Tenez compte des points suivants lorsque vous utilisez les adresses IP publiques associées à votre cluster :

  1. La liste des adresses IPv4 publiques associées à votre cluster peut changer ou s'allonger. Pour cette raison, automatisez la façon dont vous utilisez ces informations ou définissez un processus pour tenir compte des nouveaux enregistrements DNS de découverte lorsque vous faites évoluer votre cluster. Des modifications peuvent se produire dans les cas suivants :

    • Vous faites évoluer votre cluster. L'augmentation de la taille peut ajouter une ou plusieurs adresses IPv4 externes à mesure que de nouveaux agents sont ajoutés. Pour comprendre comment le nombre de processeurs virtuels influe sur le nombre d'agents, consultez la section Dimensionnement du sous-réseau.

    • Vous désactivez, puis réactivez la fonctionnalité de cluster public. Cette action attribue un nouvel ensemble d'adresses IPv4 externes au cluster.

  2. Chaque enregistrement DNS de découverte contient un maximum de 30 adresses IP. Cela reste dans les limites courantes appliquées par les pare-feu FQDN. Les clusters comportant 29 agents ou moins disposent d'un enregistrement DNS de découverte contenant 30 adresses IPv4 externes (y compris l'enregistrement d'amorçage). Le service ajoute un enregistrement DNS de découverte pour 30 agents supplémentaires. Pour comprendre comment le nombre de processeurs virtuels influe sur le nombre d'agents, consultez la section Dimensionnement du sous-réseau.

  3. Ne configurez pas vos clients Kafka pour qu'ils se connectent aux enregistrements DNS de découverte. Configurez-les plutôt pour qu'ils se connectent à l'adresse d'amorçage. Pour en savoir plus, consultez la section Limites.

  4. Si vous utilisez ces informations pour configurer des pare-feu de sortie, autorisez la connectivité aux ports TCP 9092 (SASL) et 9192 (mTLS).

Architecture réseau d'un cluster

Cette section décrit les détails de l'architecture réseau utilisée dans Managed Service pour Apache Kafka.

  • Un cluster Kafka s'étend sur un réseau locataire et un ou plusieurs réseaux consommateurs.

  • Dans le réseau locataire, le cluster dispose d'une seule adresse IP et URL d'amorçage. Cette adresse d'amorçage correspond à un équilibreur de charge connecté à tous les agents du cluster. Chaque agent peut également agir individuellement en tant que serveur d'amorçage, mais nous vous recommandons d'utiliser l'adresse d'amorçage pour plus de fiabilité.

  • Dans chaque réseau consommateur, le service crée un point de terminaison Private Service Connect pour l'adresse d'amorçage et un point de terminaison pour chaque agent.

  • L'URL de l'adresse d'amorçage est la même dans tous les réseaux VPC auxquels un cluster est connecté. L'adresse IP est locale au réseau consommateur.

  • Les clients se connectent aux agents Kafka à l'aide de noms DNS. Ces noms sont enregistrés automatiquement dans chaque réseau VPC auquel un cluster Kafka est connecté. L'adresse d'amorçage et son numéro de port sont disponibles en tant que propriété du cluster.

  • Les clients utilisent l'adresse d'amorçage pour récupérer les URL des agents. Ces URL sont résolues en adresses IP locales pour chaque réseau VPC. Vous trouverez les adresses IP et les URL réelles des agents dans Cloud DNS.

Le diagramme suivant présente un exemple d'architecture d'un réseau de cluster Managed Service pour Apache Kafka.

Réseau Managed Service pour Apache Kafka * Dans cet exemple, le cluster comporte trois agents et se trouve dans le VPC locataire.

  • Les agents communiquent avec les clients via le port Kafka par défaut (9092) et disposent d'adresses IP uniques. Dans cet exemple, les trois agents ont respectivement les adresses IP 10.128.10.2, 10.128.10.3 et 10.128.10.4.

  • Les trois agents se connectent à l'équilibreur de charge d'amorçage. Cela garantit une haute disponibilité et une tolérance aux pannes régionales, car l'adresse d'amorçage n'est pas limitée à un seul agent ou à une seule zone.

Limites

Les limites suivantes s'appliquent aux connexions VPC et aux clusters publics :

  • Région du sous-réseau. Les sous-réseaux connectés doivent se trouver dans la même région que votre cluster.

  • Nombre de sous-réseaux. Vous pouvez connecter un minimum d'un et un maximum de dix sous-réseaux à un cluster.

  • Sous-réseaux par réseau. Vous ne pouvez connecter qu'un seul sous-réseau par réseau VPC à un cluster.

  • Taille du sous-réseau. Chaque sous-réseau connecté nécessite au moins une adresse IP pour chaque agent, plus une adresse IP pour l'adresse d'amorçage. Un minimum de quatre adresses IP utilisables est requis. Pour en savoir plus, consultez la section Dimensionnement du sous-réseau.

  • Sous-réseaux connectés pour les clusters publics. Pour activer l'accès public, votre cluster doit toujours comporter au moins un sous-réseau connecté, même si vous n'avez pas besoin d'y envoyer du trafic.

  • Plages d'adresses IP sources autorisées. Chaque plage d'adresses IP sources autorisée pour un cluster public doit être spécifiée au format CIDR IPv4. La taille de chaque sous-réseau CIDR doit être comprise entre /16 et /32. Les plages CIDR ne doivent pas se chevaucher. Les adresses IPv6 ne sont pas compatibles. Vous pouvez spécifier un maximum de 500 plages d'adresses IP sources autorisées.

  • Résolution DNS des enregistrements de découverte. Les enregistrements DNS de découverte sont conçus uniquement pour configurer des pare-feu de sortie basés sur un nom de domaine complet. Ne configurez pas vos clients Kafka pour qu'ils se connectent à ces enregistrements de découverte. Configurez-les plutôt pour qu'ils se connectent à l'adresse d'amorçage.

Résoudre les problèmes

Pour en savoir plus sur la résolution des problèmes de mise en réseau, consultez la section Erreurs de mise en réseau.

Étape suivante