FAQ

Questions fréquentes sur le connector ClickHouse

​

FAQ

​

Qui peut modifier mes services, et quand ?

En mode managé, ClickHouse Cloud ne modifie que les services dont vous avez demandé la gestion. Toute personne ayant accès à l’hôte ou au pod de l’executor peut également les piloter avec les commandes locales clicklink clctl instances ; voir cycle de vie du service. ClickHouse Cloud envoie les commandes de cycle de vie via le canal sortant de l’executor :

• création, à partir de la définition que vous avez soumise
• mise à l’échelle, vers un nombre fixe de répliques défini par ClickHouse Cloud (plafonné par un paramètre ClickHouse Cloud, 20 dans la configuration par défaut)
• arrêt, démarrage et redémarrage
• sauvegarde et suppression de sauvegarde
• suppression

Les mises à niveau de version et les changements de configuration empruntent le même chemin, sous forme de définition de service réappliquée ; ils ne font l’objet d’aucune étape d’approbation du client. Aucune session d’assistance n’intervient : le canal de l’executor est distinct de celui de l’outil de diagnostic et ne dépend pas du session state.

Deux opérations requièrent votre intervention. La création d’un service passe par vos commandes clicklink clctl executor prepare et clicklink clctl instances create, car vous seul pouvez créer les buckets et l’IAM role. Les mises à jour des composants de la plateforme dans votre cluster attendent également votre intervention. L’executor met en attente chaque bundle proposé ; votre commande clicklink clctl platform approve l’approuve et génère un jeton valable 2 heures. Voir mises à jour de la plateforme.

Tout ce que fait l’executor passe par la Kubernetes API. Une policy d’admission limite ses écritures aux namespaces portant le préfixe de service (ns- par défaut). Elle admet également trois écritures dans le propre namespace de l’executor : le renouvellement du jeton, la ConfigMap du registry de services et, sur Kubernetes, le certificat client renouvelé dans le Secret clicklink-mtls. Ses lectures sur ces mêmes familles de ressources sont cluster-wide. Les mises à jour de plateforme approuvées s’exécutent sous une identity distincte, pcm-platform, limitée aux namespaces de la plateforme. Les clusters que vous exploitez vous-même ne sont jamais modifiés : le scraper et l’outil de diagnostic sont en lecture seule. Les portées exactes figurent sur la page modèle de privilèges.

​

Quelles données quittent mon environnement ?

Trois surfaces envoient des données vers l’extérieur, toutes via des connexions sortantes que le connector ouvre lui-même : le chemin de scrape, l’executor et les sessions de support que vous activez.

Le scraper envoie les résultats d’un ensemble fixe de system tables : metric_log, asynchronous_metric_log, tables, warnings et server_settings par défaut. Il envoie également des signaux de santé et de statut (heartbeats), l’état des services et des sauvegardes, ainsi que les métriques propres au connector. L’ensemble de scrape par défaut exclut system.query_log. Le texte SQL brut, ainsi que les literals ou données personnelles qu’il contient, ne quittent jamais votre environnement par le chemin de scrape, sauf si vous ajoutez cette table. Pendant une session, la liste d’autorisation de tables par défaut inclut system.processes, qui expose le texte des requêtes en cours d’exécution ; retirez-la de la liste d’autorisation si cela doit rester masqué.

L’executor envoie le résultat de chaque commande qu’il exécute ainsi que l’état et le nombre de répliques de chaque service managé. Son heartbeat indique si son canal de commandes est connecté. Il transporte également les versions des composants de la plateforme, l’empreinte du dernier bundle appliqué et le résultat de la dernière mise à jour de la plateforme. Sur une installation VM, le heartbeat indique aussi si son bundle d’accès Kubernetes est ok, expiring, expired ou absent. Lorsque vous créez un service, clicklink clctl instances create envoie l’identifiant de votre environnement, le cloud et la région, le nom du service, ainsi que les noms de ses buckets et l’ARN de son IAM role. Il envoie deux hachages du mot de passe de l’utilisateur default ; le mot de passe lui-même ne quitte jamais votre environnement.

Pendant une session d’assistance active, l’outil de diagnostic renvoie également la sortie des commandes. Cette sortie est limitée aux tables ClickHouse figurant sur la liste d’autorisation et aux vues Kubernetes en lecture seule, y compris les logs de pods. Elle passe par une redaction (patterns intégrés pour les adresses IP, credentials, jetons et clés, ainsi que les vôtres) avant d’être envoyée. Les données de vos tables, vos sauvegardes et votre query history (system.query_log, system.text_log) restent dans votre environnement. Trois éléments, en revanche, en sortent :

• les lignes des tables d’historique de métriques figurant sur la liste d’autorisation (system.metric_log, system.asynchronous_metric_log) sont transmises à chaque scrape
• le texte des requêtes en cours est visible dans une session via system.processes, sauf si vous la retirez de la liste d’autorisation
• les logs de pods lus pendant une session de support Kubernetes sortent après redaction

La liste complète des connexions sortantes figure sur la page modèle de privilèges.

​

Comment empêcher ClickHouse de modifier mes clusters ?

Exécutez sans le mode managé. À l’installation, passez --no-managed à clicklink clctl init, ou répondez non lorsque la question vous est posée. Seuls le scraper et l’outil de diagnostic sont déployés : ClickHouse ne peut donc ni créer, ni modifier, ni supprimer de services. Le connector continue de provisionner des ClickHouse users et des ServiceAccounts en lecture seule ; consultez le modèle de privilèges.

Sur une installation existante, arrêtez l’executor et retirez son grant d’administrateur du cluster. Pour l’arrêter, définissez executor.enabled: false dans vos Helm values puis exécutez helm upgrade, ou lancez systemctl disable --now clicklink-executor sur une VM. Retirez ensuite le grant. La dernière commande supprime le ServiceAccount lui-même ; son namespace est clicklink-system pour une installation sur VM et le namespace du connector pour une installation Kubernetes :

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n <executor-namespace>

Les services créés par ClickHouse continuent de fonctionner, mais ClickHouse Cloud ne peut plus les redimensionner, les mettre à niveau, les sauvegarder ni les supprimer, et les commandes en attente les concernant échouent. Les mises à jour de la plateforme s’arrêtent également : c’est l’executor qui en applique le volet charge de travail, et il n’est plus en cours d’exécution.

​

Que se passe-t-il si le connector est hors ligne ?

Vos services ClickHouse ne sont pas affectés : le connector ne se trouve sur aucun data path, et un service managé continue de fonctionner sans l’executor. L’impact se limite à une perte de visibilité et de contrôle. ClickHouse Cloud cesse de recevoir la telemetry, et les sessions d’assistance deviennent indisponibles jusqu’au retour du connector. En mode managé, ClickHouse Cloud affiche votre environnement comme hors ligne dès qu’aucun heartbeat n’est reçu pendant 5 minutes, puis de nouveau comme prêt dès le heartbeat suivant.

Les commandes de cycle de vie se comportent de deux manières tant qu’aucun executor n’est connecté. Une création, une suppression ou une synchronisation de plateforme déjà acceptée par ClickHouse Cloud est conservée et réessayée. Une création est réessayée pendant un maximum de 30 minutes à partir de son dernier rapport de progression, une suppression pendant 2 heures au maximum, et une synchronisation de plateforme sur un maximum de 10 tentatives. Passé ce délai, la commande est signalée comme échouée. Ces deux horizons correspondent aux clés de configuration executor.create_retry_horizon et executor.delete_retry_horizon. Toute autre commande (scale, stop, start, restart, sauvegarde, suppression de sauvegarde), ainsi que toute création ou suppression soumise alors qu’aucun executor n’est connecté, est refusée à la soumission et non mise en queue. Un résultat que l’executor n’a pas pu remonter est envoyé lors de sa prochaine connexion. Voir lorsque le connector est hors ligne.

Sur une VM, le scraper met en tampon les données scrapées dans /var/lib/clicklink/buffer chaque fois que votre connector endpoint est injoignable (jusqu’à 168 heures ou 1024 Mo par défaut). Il livre ce tampon à la reconnexion, de sorte qu’une panne d’endpoint n’entraîne aucune perte de telemetry. Un démon qui a crashé est redémarré par systemd sur une VM et par le kubelet sur Kubernetes. L’executor conserve l’état de ses commandes sur disque, si bien qu’un redémarrage reprend les commandes en cours.

Pour diagnostiquer, vérifiez l’endpoint /livez de chaque composant (c’est le champ JSON status qui fait foi, et non le code HTTP) et exécutez clicklink clctl preflight (avec sudo sur l’hôte VM). Preflight vérifie en une seule passe la configuration, la connectivité, la joignabilité de ClickHouse, les accès et le disque. Voir opérations ; si le connector demeure en mauvaise santé, contactez ClickHouse Support.

​

Qu’est-ce qui est supprimé lorsqu’un service est supprimé ?

L’executor arrête le service, supprime ses resources Kubernetes et supprime son namespace. Il signale que le service est terminé dès que le namespace a disparu. Tout ce qui se trouve en dehors de Kubernetes est conservé : le bucket de données, le bucket de sauvegarde et l’IAM role du service. L’executor ne détient aucune credential pour vos buckets ni pour votre IAM : il ne peut donc pas y toucher.

Vous supprimez le reste avec clicklink clctl executor teardown, exécuté avec vos credentials. Par défaut, il supprime l’IAM role et conserve les données ainsi que les sauvegardes ; leur suppression requiert des flags explicites. Voir supprimer un service.

​

Où se trouve le mot de passe de mon utilisateur default ?

clicklink clctl executor prepare le génère de votre côté et ne l’affiche qu’une seule fois. Si vous effectuez la soumission avec les flags individuels plutôt qu’avec --from-prepare, clicklink clctl instances create le lit depuis --default-user-password-file, ou bien le génère et l’affiche. Seuls ses hashes sont transmis à ClickHouse Cloud : ni le connector ni ClickHouse ne peuvent donc vous le réafficher par la suite. Pensez à le conserver dès qu’il s’affiche.

​

Comment révoquer l’accès de ClickHouse ?

Par ordre croissant de radicalité :

1. Mettre fin à l’accès interactif. Désactivez la session : sudo clicklink clctl troubleshoot session disable sur l’hôte de la VM, ou exécutez la même commande avec --gateway-url via le port-forward sur Kubernetes (les commandes exactes figurent sur la page des sessions d’assistance). En l’absence de session active, l’outil de diagnostic refuse toutes les commandes, même lorsqu’il est connecté.
2. Arrêter le mode managé. Arrêtez l’executor et retirez son grant comme décrit dans Comment empêcher ClickHouse de modifier mes clusters ?. Les mises à jour de la plateforme nécessitent déjà votre approbation : la refuser les interrompt.
3. Empêcher toute session ultérieure. Videz la liste d’autorisation des opérateurs (une liste vide ferme la passerelle) ou désactivez la passerelle ; sur une VM, la gestion locale des sessions reste accessible à root sur l’hôte. Consultez le guide de configuration.
4. Couper la connectivité avec ClickHouse Cloud. Bloquez le trafic sortant vers le connector endpoint de votre connector au niveau réseau, ou videz networkPolicy.allowEgressCIDRs avec un CNI appliquant les règles. Le connector est uniquement sortant, donc ClickHouse Cloud ne dispose d’aucun chemin entrant pour le rétablir. Les lectures locales sur votre instance ClickHouse se poursuivent jusqu’à ce que vous arrêtiez ou désinstalliez les workloads, ce qui constitue l’arrêt complet.
5. Révoquer les credentials. Supprimez les users ClickHouse pcm_scraper et pcm_troubleshooter, puis supprimez les Secrets du connector (Kubernetes) ou les fichiers sous /etc/clicklink (VM).
6. Supprimer entièrement le connector. Consultez les opérations.

​

Puis-je exécuter cela en environnement air-gapped ou via mes propres mirrors ?

Oui. Chaque artifact nécessaire à l’installation peut provenir de l’intérieur de votre boundary :

• Créez un mirror de l’archive tarball du CLI et de l’image de conteneur depuis releases.clicklink.clickhouse.com et le registry public, puis faites pointer image.repository vers votre mirror.
• Passez --chart avec une référence oci://, une URL ou une archive locale. --chart-version prend par défaut la version du CLI lui-même.
• Si votre connector endpoint est exposé à l’intérieur de votre boundary derrière une private CA, --api-private-ca (Kubernetes) ou api.tls.ca_file (VM) ajoute la CA chain de l’enrollment bundle aux racines système.
• Pour un enrollment sans connectivité directe, init --handoff consomme un bundle obtenu hors bande, et --no-auto-sign combiné à init --signed-cert finalise la signature du certificat hors bande.
• En mode managé, les images ClickHouse destinées à vos services et aux composants de la plateforme peuvent provenir de votre propre registry une fois que vous les y avez importées ; ClickHouse enregistre ce registry pour votre environnement.
• Les bundles de plateforme peuvent être transmis hors bande, puis fournis sous forme de fichier à clicklink clctl platform approve --bundle.

Consultez private mirrors et la section air-gapped de l’onboarding. Le connector a toujours besoin d’une route vers votre connector endpoint au runtime ; faute de quoi ClickHouse Cloud ne reçoit aucune telemetry et aucune commande de cycle de vie n’atteint l’executor.

​

Comment les sessions d’assistance sont-elles auditées ?

Chaque commande exécutée durant une session, qu’elle soit acceptée ou bloquée, est ajoutée à /var/log/clicklink/troubleshoot-audit.log au format JSON délimité par des sauts de ligne. Chaque entrée enregistre submitted_by (l’Organization ID sur le canal de commande), le texte de la commande, l’instance cible, le résultat, ainsi que blocked_by pour les commandes rejetées. Les appels de passerelle, y compris ceux refusés, sont consignés sous forme de lignes structurées clctl.gateway dans le journal propre à l’outil de diagnostic. Ils sont attribués à l’adresse e-mail de l’opérateur attestée par le jeton, jamais à un nom déclaré par l’utilisateur. Les modifications des sessions locales sur une VM enregistrent l’utilisateur hôte à l’origine de l’appel dans le champ enabled_by de /var/lib/clicklink/session.json.

Les sessions sont limitées dans le temps (4 heures par défaut, 24 heures au maximum). Chaque activation enregistre la personne qui l’a activée, sa date d’expiration et un motif facultatif, informations affichées par clicklink clctl troubleshoot session status.

Lisez le journal d’audit avec clicklink clctl troubleshoot audit tail. Sur Kubernetes, cette commande est le lecteur pris en charge (l’image d’exécution ne contient pas de shell). Avec le paramètre par défaut persistence.enabled: true, le journal est stocké sur le volume persistant de l’outil de diagnostic, de sorte que la trace soit conservée après le réordonnancement des pods. La désactivation de la persistance limite le journal d’audit et l’état de session à la durée de vie du pod, ce que le chart indique comme étant adapté uniquement au développement local. Par défaut, la rotation conserve 5 fichiers de 128 Mo maximum pendant 168 heures ; consultez la référence de configuration pour l’ajuster, ainsi que les sessions d’assistance pour connaître le modèle de confiance complet.