Skip to main content
Cette page présente les modifications de configuration les plus courantes après l’installation du connector. Chaque clé, avec sa valeur par défaut et sa signification, figure dans la référence de configuration ; les options de ligne de commande figurent dans la référence CLI. La création, le scaling et la suppression de services sont traités dans services managés.

​
Points de configuration

Le connecteur dispose d’un point de configuration pour chaque cible d’installation.
clicklink clctl init crée, dans le répertoire de travail, un fichier de valeurs de surcharge nommé clicklink-values.yaml, puis déploie le chart clicklink-connector avec celui-ci. Ce fichier de surcharge constitue la trace persistante de votre déploiement : relancer init le conserve, sauf si vous passez --force, afin que vos modifications soient préservées lors des nouvelles exécutions et de la récupération.
Les commandes d’exploitation de cette page et de la page opérations utilisent la CLI helm. Seule init intègre un client Helm.
Modifiez le fichier de surcharge, puis appliquez-le :
Ce bloc réapplique vos valeurs modifiées à la version du chart déjà installée, afin qu’une modification de configuration ne déclenche jamais une mise à niveau imprévue. Le passage à une nouvelle version est une étape distincte ; voir les opérations. Pour une installation en miroir utilisant un dépôt de charts, remplacez --repo par votre miroir.Une installation à partir d’une référence directe de chart (oci://, une URL, une archive locale ou un répertoire local ; voir miroirs privés) ne dispose d’aucun dépôt permettant de résoudre cette référence. Relancez la mise à niveau avec la référence utilisée lors de l’installation :

​
Mode managé

Le mode managé exécute l’executor, qui applique à votre cluster le cycle de vie de service piloté par ClickHouse Cloud. init l’active lors de l’inscription et renseigne l’identity du cluster (voir activer le mode managé). Les clés ci-dessous sont celles que vous pourriez avoir à ajuster par la suite. Pour modifier la posture, relancez init avec --force et --managed ou --no-managed. Comme toute exécution d’init, cela nécessite un entry point : --handoff si vous avez conservé le bundle, ou --enroll avec un nouveau jeton (voir relances et recovery). Sur une VM, --no-managed désactive l’executor dans la configuration, mais n’arrête ni ne désactive une systemd unit en cours d’exécution. Arrêtez-la avant de modifier la configuration :
Sur Kubernetes, définissez executor.enabled: false dans les values et appliquez le changement avec helm upgrade pour supprimer le Déploiement de l’executor. Sur les deux cibles, le grant au niveau du cluster reste en place tant que vous ne l’avez pas supprimé ; voir arrêter le mode managé.
init prépare le bloc executor dans clicklink-values.yaml à partir du cluster EKS vers lequel pointe votre contexte kube :
  • cluster.namespacePrefix est partagé par tous les composants et constitue le préfixe auquel le grant de l’executor le restreint. Le modifier après l’installation impose de relancer le grant.
  • executor.cluster désigne un seul cluster : name, region, accountId et inCluster: true, ce qui amène l’executor à s’authentifier en tant que ServiceAccount du pod. Les autres clés sont transmises telles quelles à l’executor en snake_case, comme s3_storage.
  • executor.serviceAccount reste à create: false : init accorde un accès cluster-wide au ServiceAccount pcm-executor dans le namespace du connector, et le chart s’y lie au lieu d’en créer un non lié.
  • executor.persistence sous-tend /var/lib/clicklink, où l’executor conserve sa base de données de commandes et son registry de services ; voir storage.
  • executor.platformBundleSecret désigne le Secret qui contient une mise à jour de plateforme approuvée. Le mount est optionnel, si bien que le pod démarre avant la première approbation ; voir approuver une mise à jour de plateforme.
  • executor.ports.health expose /livez et /metrics ; aucun composant ne possède de port de metrics distinct.
Appliquez les modifications avec la commande helm upgrade présentée dans surfaces de configuration.

​
Ajouter ou modifier des instances ClickHouse

Les services créés par l’executor s’enregistrent eux-mêmes : en mode managé, vous n’avez donc jamais à les ajouter ici. Cette section concerne un déploiement de connector distinct, exécuté sans l’executor, qui observe le ClickHouse que vous exploitez vous-même. Passez --ch-user-suffix lors de son init lorsque les deux déploiements partagent une instance. Chaque entrée sous instances désigne un endpoint ClickHouse en protocole natif depuis lequel le connector lit : host, port, database, secure, cluster, et sur Kubernetes namespace. max_open_conns et max_idle_conns limitent le connection pool. Les identifiants ne figurent jamais dans la configuration : chaque composant résout son ClickHouse user en lecture seule à partir du bundle d’accès créé lors du provisioning.
Ajoutez l’instance au mappage instances de premier niveau dans clicklink-values.yaml (les mêmes champs que le registre de la VM). Ajoutez son espace de noms à networkPolicy.clickhouseNamespaces, mis en correspondance via le label kubernetes.io/metadata.name de l’espace de noms. Le chart génère le mappage dans la ConfigMap clicklink-instance-registry que les deux démons lisent. Cela ne fonctionne que tant que executor.enabled vaut false ; lorsque l’executor est activé, la génération échoue car c’est l’executor qui détient cette ConfigMap.
Provisionnez un accès en lecture seule pour chaque composant depuis votre poste de travail. --apply-ch-grants applique les autorisations ClickHouse générées dans le pod via kubectl exec ; sans cette option, la commande crée uniquement les ressources Kubernetes et laisse ch-grants.sql sur le disque afin que vous l’appliquiez. Si l’utilisateur admin possède un mot de passe, ajoutez --ch-admin-password-stdin et transmettez-le par un pipe.
Pour une instance gérée par un opérateur ne disposant pas d’un administrateur capable d’exécuter du SQL, remplacez --apply-ch-grants par --ch-user-via cr (les options de sélection du pod restent les mêmes) ; consultez la référence CLI. Référencez ensuite la paire Secret et ServiceAccount créée par chaque commande dans le mappage accessBundles correspondant, puis exécutez la commande helm upgrade indiquée ci-dessus :
Les mêmes commandes access provision, avec --force, renouvellent les identifiants ClickHouse d’une instance. Consultez la page opérations.

​
Liste d’autorisation des opérateurs

Une liste d’autorisation d’adresses e-mail d’opérateurs conditionne les sessions gérées par la passerelle. Chaque requête envoyée à la passerelle de sessions doit inclure un jeton d’identité OIDC à courte durée de vie dont l’adresse e-mail attestée figure dans cette liste. Une liste d’autorisation vide ferme la passerelle. Sur une VM, root sur l’hôte peut également gérer les sessions directement via le fichier de sessions local ; la liste d’autorisation ne régit que le chemin passant par la passerelle. Consultez les sessions de support pour connaître le modèle de confiance complet.
La liste d’autorisation se trouve dans le fichier de surcharge, et le chart la génère dans une ConfigMap. Pour la modifier, éditez la liste et exécutez helm upgrade :

​
Politique réseau et egress

Sur Kubernetes, le chart fournit une NetworkPolicy en mode « refus par défaut » assortie d’une allowlist d’egress. Les objets NetworkPolicy ne prennent effet que si votre CNI les applique. Avec un CNI qui les applique, seuls le DNS du cluster et les namespaces du ClickHouse Service restent joignables tant que les deux listes de CIDR ne sont pas renseignées. D’ici là, le connector n’a aucun egress vers votre connector endpoint ni vers le Kubernetes API server. init n’active la politique que lorsqu’il connaît les CIDR situés derrière votre connector endpoint.
Les deux listes de CIDR proviennent d’endroits différents :
  • allowEgressCIDRs est à votre charge : il s’agit des plages situées derrière votre connector endpoint, fournies à l’installation avec --egress-cidrs ou lors de l’invite. Tous les composants en ont besoin pour atteindre votre connector endpoint. En mode managé, lorsque les charts de la plateforme résident dans Amazon ECR, ajoutez les plages ECR et STS de votre region (ou la plage de votre mirror). Sans elles, les récupérations de charts de l’executor échouent sous la policy.
  • apiserverCIDRs est déduite par init en mode managé à partir du VPC de l’EKS cluster (eks:DescribeCluster et ec2:DescribeVpcs). Chaque composant émet des requêtes de jeton Kubernetes et l’executor pilote les services via l’API : sous un CNI appliquant les règles, ils sont donc tous bloqués tant qu’elle n’est pas définie. Si le lookup échoue, init émet un avertissement et laisse la liste vide afin que vous la renseigniez avec les blocs CIDR de votre VPC.
Les namespaces de service sont sélectionnés de deux manières. Les namespaces créés par l’executor portent le label clicklink.clickhouse.com/managed-by: executor, et la policy les admet via ce label : une installation managée peut donc laisser clickhouseNamespaces vide. Seuls les namespaces créés en dehors de l’executor, pour un ClickHouse que vous exploitez vous-même, doivent être énumérés par nom. Activer la policy ultérieurement. Si vous avez ignoré les CIDR de l’endpoint à l’installation, init a préparé enabled: false avec allowEgressCIDRs: [] et affiché l’étape permettant de finaliser la configuration. Une fois les CIDR connus, définissez enabled: true et allowEgressCIDRs dans clicklink-values.yaml, vérifiez que apiserverCIDRs contient bien les plages de votre VPC, puis exécutez le helm upgrade indiqué dans surfaces de configuration. Lorsque la passerelle de sessions est activée, une règle d’egress supplémentaire entre en jeu : clctl.gateway.jwksEgressCIDRs. L’outil de diagnostic récupère le JWKS de votre identity provider pour valider les jetons d’opérateur ; sous un refus par défaut, une liste vide bloque donc toute vérification de jeton :
L’exemple porte sur la plage private.googleapis.com, qui couvre un fournisseur d’identité Google accessible via Private Google Access. Pour tout autre fournisseur d’identité, indiquez sa plage, ou le CIDR du proxy d’egress placé devant lui. Il reste deux clés d’ingress : metricsScrapeSelector limite l’ingress de scrape des metrics à un seul espace de noms Prometheus au moyen d’un label, et kubeletProbeCIDRs autorise explicitement les sondes de santé du kubelet dans le cadre d’un refus par défaut strict. Consultez la référence de configuration pour la liste complète des clés.

​
Motifs de masquage

L’outil de diagnostic masque sa sortie avant qu’elle ne quitte votre périmètre. Les motifs intégrés couvrent ipv4, ipv6, bearer-token, aws-access-key, email, jwt, ssh-private-key et connection-string-credentials. Ajoutez vos propres motifs dans un fichier YAML. Ils sont appliqués en premier, dans l’ordre du fichier, suivis des motifs intégrés ; une entrée qui réutilise le name d’un motif intégré remplace ce dernier. Chaque motif accepte name (obligatoire, unique), regex (obligatoire, syntaxe RE2 de Go), replace (par défaut [REDACTED], prend en charge les références de capture $1) et case_insensitive (par défaut false) :
Sur une VM, le fichier est /etc/clicklink/redaction-patterns.yaml. L’installateur l’initialise avec un ensemble de départ de motifs actifs (API keys tierces, clés secrètes AWS, etc.). Réduisez ou étendez cet ensemble ; l’installateur conserve votre version lors des mises à niveau. Dans Kubernetes, placez le YAML dans une ConfigMap sous la clé redaction-patterns.yaml et définissez troubleshooter.redaction.patternsConfigMap sur son nom ; le chart le monte au même chemin.
L’outil de diagnostic refuse de démarrer lorsqu’un fichier de patterns est présent mais non valide, et consigne l’entrée en cause. Un fichier configuré mais absent ne génère qu’un avertissement dans les log et les motifs intégrés sont utilisés. clicklink clctl preflight valide le fichier ; exécutez-le avant de redémarrer le démon.

​
Miroirs privés et endpoints internes au périmètre

Le chart publié définit par défaut image.repository sur l’image publique multi-architecture du connecteur, signée avec cosign ; les installations standard ne nécessitent donc aucune valeur d’image. Pour consulter les valeurs par défaut publiées :
Pour utiliser votre propre registre, remplacez le dépôt dans le fichier de surcharge :
Pour installer le chart depuis un miroir, init accepte --chart sous la forme d’un nom de chart résolu à partir de --chart-repo, ou d’une référence oci:// directe, d’une URL, d’une archive locale ou d’un répertoire local. Par défaut, --chart-version utilise la version de la CLI afin que le binaire et le chart évoluent de concert.
Lorsque l’endpoint de votre connector se trouve derrière une CA privée au sein de votre périmètre, transmettez --api-private-ca à init. Cette option configure api.tls.caFile: /etc/clicklink/secrets/mtls/ca.crt, et le connector vérifie l’endpoint par rapport aux racines système ainsi qu’à la chaîne de CA de votre bundle d’inscription. Sur une VM, l’équivalent est api.tls.ca_file dans /etc/clicklink/config.yaml : init installe la chaîne du bundle dans /etc/clicklink/tls/ca.crt, et le connector l’ajoute aux racines système de la même manière. Pour une inscription entièrement en environnement isolé du réseau et la signature de certificats, consultez l’onboarding.

​
Stockage

Deux composants conservent un état sur des PersistentVolumeClaims. Celui de l’outil de diagnostic contient l’état de session et la piste d’audit :
Celui de l’executor contient sa base de données de commandes et le registre des services qu’il gère :
init définit les deux valeurs storageClass sur la classe que vous avez choisie. Une storageClass vide utilise la StorageClass par défaut du cluster ; si le cluster n’en désigne aucune par défaut, init en exige une via le prompt ou --storage-class. La claim de l’executor porte l’annotation helm.sh/resource-policy: keep : helm uninstall la laisse donc en place ; voir uninstall.