Présentation du connecteur

Pour demander l’accès à la private preview, contactez l’équipe en charge de votre compte ClickHouse.

​

Ce que fait le connector

Le ClickHouse Connector est un composant que vous déployez dans votre propre environnement. Il permet à ClickHouse Cloud de gérer, superviser et prendre en charge des services ClickHouse dans un cluster Kubernetes que vous exploitez. Le connector n’établit que des connexions sortantes et agit sous des identités dont la portée est limitée à ces services. Il est livré sous la forme d’un binaire unique, clicklink, qui contient les démons ainsi que l’outillage clicklink clctl permettant de les installer et de les exploiter. Le connector comporte trois composants :

• L’executor pilote le cycle de vie des services dont vous confiez la gestion à ClickHouse. Il crée chaque service à partir d’une définition que vous soumettez, puis applique les commandes de scale, d’arrêt, de démarrage, de redémarrage, de sauvegarde et de suppression émises par ClickHouse Cloud. On parle de mode managé lorsque l’executor est en fonctionnement.
• Le scraper collecte des metrics issues d’une allowlist de system tables ClickHouse, ainsi que des métadonnées d’infrastructure et l’état de santé, puis les transmet à ClickHouse Cloud.
• Le troubleshooter permet aux ingénieurs du support ClickHouse d’exécuter des diagnostics en lecture seule durant une session d’assistance que vous activez et pouvez interrompre à tout moment.

Dans un terminal, init demande s’il faut activer le mode managé et propose oui par défaut ; les scripts doivent passer --managed. Sans le mode managé, le connector observe et prend tout de même en charge les clusters que vous exploitez vous-même ; voir exécuter sans le mode managé. Toutes les connexions établies par le connector sont sortantes ; ClickHouse Cloud n’en initie jamais vers votre environnement. La page architecture répertorie chaque connexion, son protocole et son mode d’authentification.

​

Quand l’utiliser

Déployez le connector lorsque vous souhaitez que ClickHouse Cloud exploite des services ClickHouse au sein de votre propre compte cloud, dans le respect des contraintes suivantes :

• Tous les chemins d’accès partent de l’intérieur de votre boundary ; aucune connectivité entrante n’est requise.
• Les writes vers votre cluster se limitent aux namespaces des services gérés par ClickHouse, auxquels s’ajoutent le jeton propre à l’executor, le registry et le certificat renouvelé dans son namespace d’origine. Les composants de plateforme dont dépendent ces services n’évoluent qu’après que vous ayez approuvé chaque update.
• Vos données restent dans des buckets et derrière des IAM roles que vous créez et supprimez vous-même. L’executor ne détient aucun identifiant pour vos buckets ni pour vos IAM roles.
• L’accès du Support est limité dans le temps, activé par vous et révocable à tout moment. Chaque commande passée lors d’une session de support est consignée dans un audit log qui vous appartient.

​

Fonctionnement

Lors de l’onboarding, ClickHouse enregistre votre environnement et fournit votre connector endpoint ainsi qu’un jeton d’inscription à usage unique. Vous exécutez clicklink clctl init --enroll une seule fois : depuis un poste de travail disposant d’un accès kubeconfig pour une installation Kubernetes, ou sur l’hôte pour une installation sur VM Linux. Cette commande consomme le jeton, obtient un certificat client mTLS, déploie et démarre les démons, puis vérifie leur health. L’activation du mode managé déploie l’executor et applique son octroi d’accès Kubernetes. Ce grant est un ServiceAccount pcm-executor. Une politique d’admission limite ses écritures aux namespaces de service (préfixe ns- par défaut). Les exceptions sont le renewal de son propre jeton, un ConfigMap de registry et, sur Kubernetes, le certificat client renouvelé dans son namespace d’origine. La création d’un service tient en deux commandes. clicklink clctl executor prepare crée les buckets et l’IAM role du service avec vos identifiants AWS et affiche une seule fois le password du default user. clicklink clctl instances create soumet la définition du service à ClickHouse Cloud via votre connector endpoint. Ensuite, ClickHouse Cloud pilote le service par le canal de commandes sortant de l’executor : scaling, arrêt et démarrage, redémarrages, sauvegardes, mises à niveau de version et changements de configuration. Consultez services managés pour la procédure détaillée. Deux actions restent à votre charge. Les updates des composants de plateforme de votre cluster attendent votre approbation ; voir mises à jour de la plateforme. La suppression d’un service ne retire que ses resources Kubernetes ; ses buckets et son IAM role subsistent jusqu’à ce que vous exécutiez clicklink clctl executor teardown. Le scraper lit les system tables autorisées par l’allowlist à intervalle fixe et transmet les metrics, les métadonnées et l’état de santé à votre connector endpoint via mTLS. Le troubleshooter maintient ouvert un canal de commandes sortant qui ne transporte rien tant que vous n’avez pas activé de session d’assistance. Le certificat mTLS se renouvelle de lui-même.

​

Exécution sans le mode managé

Passez --no-managed à clicklink clctl init, ou répondez non à la question posée, pour n’installer que le scraper et le troubleshooter. Le connector se contente alors d’observer et de prendre en charge les clusters ClickHouse que vous exploitez vous-même ; ClickHouse ne peut ni créer, ni modifier, ni supprimer de services. Le connector se déploie néanmoins lui-même et provisionne des utilisateurs ClickHouse en lecture seule ainsi que des ServiceAccounts ; consultez le modèle de privilèges. C’est également la configuration à retenir pour les cibles que le mode managé ne couvre pas. Le mode managé fonctionne sur Amazon EKS avec un stockage S3 ; l’observability et le support fonctionnent sur n’importe quel cluster Kubernetes conforme ou hôte Linux.

​

Aperçu des prérequis

• Une cible de déploiement. Le mode managé nécessite un cluster Amazon EKS avec du stockage S3. L’observability et le support seuls fonctionnent sur n’importe quel cluster Kubernetes conforme (installé avec le Helm chart) ou sur n’importe quel hôte Linux systemd, amd64 ou arm64.
• Enregistrement par ClickHouse. ClickHouse enregistre votre environnement pour le mode managé et, pendant l’onboarding, vous fournit votre connector endpoint ainsi qu’un jeton d’inscription à usage unique.
• Un accès réseau sortant sur le port 443 vers votre connector endpoint et son endpoint d’inscription, ainsi que vers releases.clicklink.clickhouse.com et ECR Public au moment de l’installation. Des alternatives en environnement isolé du réseau et en miroir existent pour chaque étape ; consultez onboarding. En mode managé, les nœuds de votre cluster récupèrent également les images ClickHouse depuis le registry auprès duquel votre environnement est enregistré. L’executor contacte Amazon ECR et STS lorsqu’il récupère un chart de plateforme depuis ECR.
• Un accès cluster admin pendant la configuration. L’activation du mode managé applique une seule fois l’octroi d’accès de l’executor : un ServiceAccount, le ClusterRole qui lui est associé et la politique d’admission qui confine ses écritures aux namespaces de service. L’approbation d’une mise à jour de plateforme requiert elle aussi les droits cluster admin. Sur les deux cibles d’installation, les ensembles d’accès du troubleshooter sont rattachés à des ServiceAccounts Kubernetes. Consultez onboarding.
• Des identifiants AWS pour prepare et teardown, et un accès au registry pour platform approve. La création des buckets et de l’IAM role d’un service s’exécute avec vos identifiants, de même que leur suppression une fois le service supprimé. Les deux opérations s’exécutent depuis votre poste de travail ou l’hôte du connector. Pour un accès direct au registry de ClickHouse, l’approbation et la synchronisation de plateforme endossent le rôle de pull en lecture seule via le profil d’instance de la VM EC2 du connector. Les profils AWS de votre poste de travail ou les identifiants SSO ne remplacent pas cette identité. Les autres registries de charts ECR utilisent les identifiants AWS ambiants. Consultez identifiants du registry. L’executor ne détient jamais d’identifiants sur vos buckets ni sur votre IAM. Ses seuls appels cloud vont vers Amazon ECR et STS pour la récupération des charts et la vérification des images de plateforme.
• Un listener natif ClickHouse joignable pour les clusters que vous exploitez vous-même, observés par un déploiement de connector distinct fonctionnant sans l’executor. Le scraper et le troubleshooter communiquent avec chaque cluster via le native protocol ; sur Kubernetes, ils détectent automatiquement le mode sécurisé (9440) ou plaintext (9000).
• Un accès admin ClickHouse pendant la configuration pour les clusters que vous exploitez vous-même. Le provisioning initial crée les utilisateurs en lecture seule du connector. Le mot de passe admin, lorsqu’il en existe un, est demandé une seule fois et n’est jamais stocké.

​

Étapes suivantes

• Onboarding : installez et enregistrez le connector sur Kubernetes ou une VM Linux.
• Services managés : activez le mode managé, créez un service et suivez son cycle de vie, son statut et sa suppression.
• Mises à jour de la plateforme : approuvez les modifications apportées aux composants de la plateforme dans votre cluster.
• Architecture : composants, connexions, cycle de vie des certificats et données qui quittent votre environnement.
• Sessions d’assistance : activation, définition du périmètre, audit et révocation de l’accès au support.
• Configuration et opérations : réglages, mises à niveau et tâches d’exploitation courante.
• FAQ : questions fréquentes, notamment qui peut modifier vos services, la sortie de données et la révocation.

Le connector s’exécute dans un cluster que vous fournissez et contrôlez ; ClickHouse Cloud y gère les services via l’executor. Si vous préférez que ClickHouse provisionne et exploite lui-même le cluster dans votre compte cloud, optez pour le modèle de déploiement BYOC. La page architecture BYOC explique les différences entre les deux.