Configuration personnalisée pour GCP

Déployer ClickHouse BYOC dans votre VPC GCP existant

​

VPC géré par le client (BYO-VPC) pour GCP

Si vous préférez utiliser un VPC existant pour déployer ClickHouse BYOC au lieu de laisser ClickHouse Cloud provisionner un nouveau VPC, suivez les étapes ci-dessous. Cette approche offre davantage de contrôle sur votre configuration réseau et vous permet d’intégrer ClickHouse BYOC à votre infrastructure réseau existante.

1. Configurez votre VPC existant

   1. Allouez au moins 1 sous-réseau privé dans une région prise en charge par ClickHouse BYOC pour le cluster Kubernetes (GKE) de ClickHouse. Assurez-vous que le sous-réseau dispose d’une plage CIDR minimale de /24 (par exemple, 10.0.0.0/24) afin de fournir suffisamment d’adresses IP aux nœuds du cluster GKE.
   2. Dans le sous-réseau privé, allouez au moins 1 plage IPv4 secondaire qui sera utilisée pour les pods du cluster GKE. Cette plage secondaire doit être d’au moins /21. Les plages plus petites ne fournissent pas suffisamment d’adresses IP de pods pour que le cluster GKE termine son provisionnement, et la configuration de l’infrastructure échouera.
   3. Activez Private Google Access sur le sous-réseau. Cela permet aux nœuds GKE d’accéder aux API et services Google sans nécessiter d’adresses IP externes.

   Pour exposer des services via Private Service Connect, vous avez également besoin, dans ce VPC, d’un sous-réseau dédié dont l’objectif est PRIVATE_SERVICE_CONNECT. Vous pouvez le créer dès maintenant ou plus tard, avant d’activer le private link.

2. Assurez la connectivité réseau

   Cloud NAT Gateway Assurez-vous qu’une passerelle Cloud NAT est déployée pour le VPC. Elle fournit la connectivité sortante aux instances sans adresses IP externes, et deux éléments en dépendent :

   • Tailscale. Les composants ClickHouse BYOC s’enregistrent auprès du plan de contrôle Tailscale, qui fournit un réseau sécurisé de type zero-trust pour les opérations de gestion privées, sans nécessiter d’accès public entrant.
   • Images de conteneurs. Certaines images exécutées par le déploiement ne sont pas répliquées dans le registre BYOC, notamment les images communautaires, et sont récupérées depuis leurs registres d’origine.

   Un VPC dépourvu de chemin sortant ne terminera pas son provisionnement ; la validation préalable vérifie qu’une passerelle Cloud NAT couvre le réseau. Il n’existe pas de liste publiée unique de points de terminaison ; si votre politique réseau exige un inventaire explicite, contactez le support pour examiner votre configuration.

   Résolution DNS Assurez-vous que votre VPC dispose d’une résolution DNS fonctionnelle et ne bloque pas, ne perturbe pas ou ne remplace pas les noms DNS standard. ClickHouse BYOC s’appuie sur le DNS pour résoudre les serveurs de contrôle Tailscale et les points de terminaison de service ClickHouse. Si le DNS n’est pas disponible ou est mal configuré, les services BYOC risquent de ne pas pouvoir se connecter ou fonctionner correctement.

3. Configurez l’infrastructure BYOC

   Lorsque vous cliquez sur Set up Infrastructure, ClickHouse Cloud exécute automatiquement la validation préalable avant le provisionnement. Elle vérifie que le compte de service de gestion dispose des autorisations requises et que les API Google Cloud requises sont activées, et elle valide le VPC que vous fournissez : que le réseau et le sous-réseau se résolvent, que la plage primaire du sous-réseau et la plage secondaire des pods sont suffisamment grandes, et qu’une passerelle Cloud NAT couvre le réseau. Si un élément est manquant, la configuration s’interrompt en indiquant les problèmes précis à corriger.

   Dans la console ClickHouse Cloud, configurez les éléments suivants lors de la mise en place d’une nouvelle infrastructure :

   1. Sous Configuration du VPC, sélectionnez Use existing VPC.
   2. Saisissez le nom de votre réseau VPC.
   3. Saisissez le nom du sous-réseau que vous avez alloué à ClickHouse.
   4. Vous pouvez éventuellement saisir des noms de plages secondaires pour déterminer lesquelles des plages secondaires du sous-réseau GKE utilise pour les pods. Laissez le champ vide pour toutes les utiliser ; chaque nom que vous indiquez doit déjà exister sur le sous-réseau.
   5. Si votre VPC se trouve dans un projet hôte de Shared VPC, saisissez l’ID du projet hôte du Shared VPC. Laissez le champ vide lorsque le VPC se trouve dans le même projet que l’infrastructure. Voir Shared VPC depuis un projet hôte ci-dessous.
   6. Cliquez sur Set up Infrastructure pour lancer le provisionnement.

​

VPC partagé provenant d’un projet hôte

Vous pouvez exécuter BYOC dans un projet de service sur un réseau hébergé dans un projet hôte Shared VPC distinct, ce qui vous permet de centraliser la gestion réseau. Le VPC et ses sous-réseaux appartiennent au projet hôte, tandis que la BYOC infrastructure s’exécute dans un projet de service rattaché. Les exigences ci-dessus restent inchangées : elles s’appliquent simplement au sous-réseau du projet hôte.

Deux prerequisites sont propres à cette configuration :

• Activez le projet hôte en tant qu’hôte Shared VPC et rattachez-y le projet de service avant de commencer. Ces deux étapes sont obligatoires et distinctes : un projet qui n’est pas déjà un hôte Shared VPC doit d’abord être activé comme tel, et ce n’est qu’ensuite que le projet de service peut y être rattaché. Un cluster GKE en Shared VPC exige que ce rattachement existe. La validation préalable lit votre réseau et votre sous-réseau via les grants du projet hôte, que le rattachement soit en place ou non : elle réussit donc dans les deux cas, et le provisionnement échoue plus tard, au moment de la création du cluster. Ces deux opérations relèvent du niveau organization et sont effectuées par la personne qui administre le Shared VPC dans votre organization ; le Terraform d’onboarding ne peut pas les réaliser à votre place.
• Exécutez le Terraform d’onboarding en renseignant le projet hôte. Transmettez shared_vpc_host_project_id, shared_vpc_host_subnet_region et shared_vpc_host_private_subnet_id au onboarding module. shared_vpc_host_private_subnet_id correspond au sous-réseau hôte dans lequel s’exécutent vos nœuds GKE — celui que vous avez configuré ci-dessus — et non au sous-réseau Private Service Connect décrit plus bas. Le faire pointer vers le sous-réseau PSC place le grant roles/compute.networkUser sur le mauvais sous-réseau, et le provisionnement échoue alors à la création du cluster. Une seule invocation écrit dans les deux projets : les credentials qui l’exécutent doivent donc disposer des droits d’administration IAM sur le projet de service comme sur le projet hôte.

Les grants que le module ajoute à votre projet hôte sont restreints, mais ils ne sont pas tous en read-only :

Grant sur le projet hôte	Accordé à	Raison
compute.networks.get, compute.subnetworks.get, compute.subnetworks.use	Le compte de service de gestion ClickHouse	Lire votre réseau et votre sous-réseau, et permettre au rattachement Private Service Connect d’utiliser votre sous-réseau PSC
roles/compute.networkUser sur le sous-réseau des nœuds	Le compte de service de gestion ClickHouse, l’agent de service GKE de votre projet de service et le compte de service Google APIs de votre projet de service	Les trois identities qui consomment le sous-réseau
roles/container.hostServiceAgentUser	L’agent de service GKE de votre projet de service	Obligatoire pour tout cluster GKE en Shared VPC
compute.firewalls.create, compute.firewalls.delete, compute.firewalls.get, compute.firewalls.list, compute.firewalls.update et compute.networks.updatePolicy	L’agent de service GKE de votre projet de service	En Shared VPC, GKE crée les règles de firewall de son cluster et de son load balancer dans le projet hôte plutôt que dans le projet de service. Sans cela, la règle de contrôle de health du load balancer interne n’est jamais créée, les backends d’Ingress restent en mauvaise santé et le private link ne fonctionne pas. Il s’agit de l’alternative granulaire documentée par Google à l’attribution de roles/compute.securityAdmin.

La dernière ligne constitue le seul accès en écriture, et il est accordé à l’agent de service GKE de votre propre projet, et non à ClickHouse. Le compte de service de gestion ClickHouse n’écrit jamais dans le projet hôte. Le module active également l’API container.googleapis.com sur le projet hôte, ce qui provisionne l’agent de service GKE propre à ce projet.

Saisissez ensuite le projet hôte dans le champ Shared VPC host project ID décrit ci-dessus. Si vous souhaitez utiliser le private link, créez un sous-réseau PRIVATE_SERVICE_CONNECT distinct dans le projet hôte, dans le même réseau et la même region que le sous-réseau des nœuds. Il coexiste avec le sous-réseau des nœuds au lieu de le remplacer, et ce n’est pas le sous-réseau que vous transmettez via shared_vpc_host_private_subnet_id.