Skip to main content
En esta página se describen los cambios de configuración que probablemente realizará después de instalar el conector. Cada clave, con su valor predeterminado y su significado, se encuentra en la referencia de configuración; los indicadores de línea de comandos están en la referencia de la CLI. Crear, escalar y eliminar servicios se aborda en managed servicios.

​
Superficies de configuración

El conector tiene una superficie de configuración para cada destino de instalación.
clicklink clctl init prepara en el directorio de trabajo una superposición de valores denominada clicklink-values.yaml y despliega con ella el chart clicklink-connector. La superposición constituye el registro persistente de tu implementación: al volver a ejecutar init, se conserva salvo que especifiques --force, por lo que tus cambios se mantienen tras nuevas ejecuciones y durante la recuperación.
Los comandos de operaciones posteriores a la instalación de esta página y de operaciones usan la CLI de helm. Solo init incluye un client de Helm integrado.
Edita la superposición y aplícala:
El bloque vuelve a aplicar los valores editados con la versión del chart ya instalada, por lo que un cambio de configuración nunca implica una actualización no planificada. Actualizar a una versión nueva es un paso aparte; consulta operaciones. En una instalación reflejada que usa un repositorio de charts, sustituye --repo por tu réplica.Una instalación desde una referencia directa al chart (oci://, una URL o un archivo o directorio local; consulta réplicas privadas) no tiene ningún repositorio con el que resolver la referencia. Vuelve a ejecutar la actualización con la referencia desde la que realizaste la instalación:

​
Modo administrado

El modo administrado ejecuta el executor, que aplica a tu cluster el ciclo de vida del servicio que dirige ClickHouse Cloud. init lo activa durante la inscripción y completa la identity del cluster (consulta habilitar el modo administrado). Las claves que figuran a continuación son las que quizá quieras revisar más adelante. Para cambiar esta configuración, vuelve a ejecutar init con --force y --managed o --no-managed. Como en cualquier ejecución de init, se necesita un punto de entrada: --handoff si conservaste el paquete, o --enroll con un token nuevo (consulta nuevas ejecuciones y recuperación). En una VM, --no-managed deshabilita el executor en la configuración, pero no detiene ni deshabilita una systemd unit en ejecución. Detenla antes de cambiar la configuración:
En Kubernetes, establezca executor.enabled: false en los valores y aplíquelo con helm upgrade para eliminar la Implementación del executor. En ambos destinos, el grant del cluster se mantiene hasta que lo elimine; consulte detener el modo administrado.
init prepara el bloque executor en clicklink-values.yaml a partir del EKS cluster al que apunta tu contexto de kube:
  • cluster.namespacePrefix lo comparten todos los componentes y es el prefijo al que el grant del executor lo restringe. Cambiarlo después de la instalación implica volver a ejecutar el grant.
  • executor.cluster es exactamente un cluster: name, region, accountId e inCluster: true, lo que hace que el executor se autentique como la ServiceAccount del pod de Kubernetes. Las demás claves se transmiten al executor tal cual en snake_case, como s3_storage.
  • executor.serviceAccount se mantiene en create: false: init otorga acceso a nivel de todo el cluster a la ServiceAccount pcm-executor en el espacio de nombres del connector, y el chart se enlaza a ella en lugar de crear una nueva sin enlazar.
  • executor.persistence respalda /var/lib/clicklink, donde el executor guarda su base de datos de comandos y su registro de servicios; consulta almacenamiento.
  • executor.platformBundleSecret indica el nombre del Secret que contiene una actualización de plataforma aprobada. El montaje es opcional, por lo que el pod de Kubernetes se inicia antes de la primera aprobación; consulta aprobar una actualización de plataforma.
  • executor.ports.health expone /livez y /metrics; no hay un puerto de métricas independiente en ningún componente.
Aplica los cambios con el helm upgrade que se muestra en superficies de configuración.

​
Añadir o modificar instancias de ClickHouse

Los servicios que crea el executor se registran por sí mismos, de modo que en modo administrado nunca se añaden aquí. Esta sección se aplica a una implementación independiente del conector que se ejecuta sin el executor y que observa el ClickHouse que usted mismo ejecuta. Pase --ch-user-suffix en su init cuando ambas implementaciones compartan una instancia. Cada entrada de instances designa un endpoint del protocolo nativo de ClickHouse del que lee el conector: host, port, database, secure, cluster y, en Kubernetes, namespace. max_open_conns y max_idle_conns limitan el connection pool. Las credenciales nunca residen en la configuración; cada componente resuelve su usuario de ClickHouse de solo lectura a partir del paquete de acceso que genera el aprovisionamiento.
Añada la instancia al mapa instances de nivel superior en clicklink-values.yaml (los mismos campos que el registro de la VM). Incluya su espacio de nombres en networkPolicy.clickhouseNamespaces, que se compara con la etiqueta kubernetes.io/metadata.name del espacio de nombres. El chart representa el mapa en el ConfigMap clicklink-instance-registry que leen ambos daemons. Esto solo funciona mientras executor.enabled sea false; con el executor activado, la representación falla porque el executor es el propietario de ese ConfigMap.
Aprovisione acceso de solo lectura para cada componente desde su estación de trabajo. --apply-ch-grants aplica los grants de ClickHouse generados dentro del pod mediante kubectl exec; sin esta opción, el comando solo crea los recursos de Kubernetes y deja ch-grants.sql en disco para que lo aplique usted. Si el usuario admin tiene contraseña, añada --ch-admin-password-stdin y pásela mediante una tubería.
Para una instancia gestionada por un operador sin un usuario admin con capacidad para ejecutar SQL, sustituya --apply-ch-grants por --ch-user-via cr (se mantienen los indicadores de selección de pods); consulte la referencia de la CLI. A continuación, configure en el mapa accessBundles correspondiente el par Secret y ServiceAccount que crea cada comando y ejecute el helm upgrade mostrado anteriormente:
Los mismos comandos access provision con --force rotan las credenciales de ClickHouse de una instancia. Consulte operaciones.

​
Lista de permitidos de operadores

Una lista de direcciones de correo electrónico de operadores permitidos restringe las sesiones administradas mediante Gateway. Cada solicitud al gateway de sesiones debe incluir un token de ID de OIDC de corta duración cuya dirección de correo electrónico verificada figure en la lista. Una lista vacía cierra el gateway. En una VM, el usuario root del host también puede administrar sesiones directamente mediante el archivo de sesión local; la lista solo rige el acceso a través del gateway. Consulte sesiones de soporte para conocer el modelo de confianza completo.
La lista se encuentra en la superposición y el chart la procesa en un ConfigMap. Para cambiarla, edite la lista y ejecute helm upgrade:

​
Política de red y salida

En Kubernetes, el chart incluye una NetworkPolicy de denegación por defecto con una lista de permitidos de salida. Los objetos NetworkPolicy solo surten efecto si tu CNI los aplica. Con un CNI que los aplique, solo se puede alcanzar el DNS del cluster y los espacios de nombres del ClickHouse Service hasta que se completen ambas listas de CIDR. Hasta ese momento, el conector no tiene salida hacia tu endpoint del conector ni hacia el Kubernetes API server. init deja la política como enabled únicamente cuando conoce los CIDR que hay detrás de tu endpoint del conector.
Las dos listas de CIDR provienen de lugares distintos:
  • allowEgressCIDRs debe proporcionarla usted: los rangos que hay detrás de su endpoint del conector, indicados durante la instalación con --egress-cidrs o en el prompt. Todos los componentes los necesitan para alcanzar su endpoint del conector. En modo administrado, cuando los charts de la plataforma residen en Amazon ECR, añada los rangos de ECR y STS de su region (o el rango de su mirror). Sin ellos, las descargas de charts del executor fallan por efecto de la policy.
  • apiserverCIDRs la deriva init en modo administrado a partir de la VPC del EKS cluster (eks:DescribeCluster y ec2:DescribeVpcs). Todos los componentes emiten requests de token de Kubernetes y el executor gestiona servicios a través de la API, por lo que, con un CNI que aplique restricciones, todos quedan bloqueados hasta que se defina. Si el lookup falla, init emite una advertencia y deja la lista vacía para que usted la complete con los bloques CIDR de su VPC.
Los espacios de nombres de servicios se seleccionan de dos maneras. Los espacios de nombres que crea el executor llevan la etiqueta clicklink.clickhouse.com/managed-by: executor, y la policy los admite por esa etiqueta, de modo que una instalación administrada puede dejar clickhouseNamespaces vacío. Solo los espacios de nombres creados fuera del executor, para el ClickHouse que usted mismo opera, deben enumerarse por nombre. Habilitar la policy más adelante. Si omitió los CIDR del endpoint durante la instalación, init dejó preparado enabled: false con allowEgressCIDRs: [] e imprimió el paso necesario para completarlo. Cuando conozca los CIDR, establezca enabled: true y allowEgressCIDRs en clicklink-values.yaml, confirme que apiserverCIDRs contiene los rangos de su VPC y ejecute el helm upgrade que se muestra en superficies de configuración. Cuando el gateway de sesión está habilitado, entra en juego una regla de salida más: clctl.gateway.jwksEgressCIDRs. El solucionador de problemas obtiene el JWKS de su identity provider para validar los operador tokens, por lo que, con denegación predeterminada, una lista vacía bloquea toda comprobación de token:
El ejemplo es el rango private.googleapis.com, que abarca un identity provider de Google al que se accede mediante Private Google Access. Para cualquier otro identity provider, indique su rango o el CIDR del proxy de salida que lo precede. Quedan dos claves de ingreso: metricsScrapeSelector restringe el ingreso de scrape de metrics a un único espacio de nombres de Prometheus mediante una etiqueta, y kubeletProbeCIDRs admite explícitamente los health probes del agente kubelet bajo una política estricta de denegación predeterminada. Consulte la referencia de configuración para ver la lista completa de claves.

​
Patrones de redacción

El solucionador de problemas redacciona su salida antes de que salga de su perímetro. Los patrones integrados cubren ipv4, ipv6, bearer-token, aws-access-key, email, jwt, ssh-private-key y connection-string-credentials. Añada sus propios patrones en un archivo YAML. Estos se aplican primero, en el orden en que aparecen en el archivo, seguidos de los integrados; una entrada que reutilice el name de un patrón integrado lo sustituye. Cada patrón admite name (obligatorio, único), regex (obligatorio, sintaxis RE2 de Go), replace (valor predeterminado: [REDACTED], admite referencias a capturas como $1) y case_insensitive (valor predeterminado: false):
En una VM, el archivo se encuentra en /etc/clicklink/redaction-patterns.yaml. El instalador lo inicializa con un conjunto inicial de patrones activos (API keys de terceros, claves secretas de AWS, etc.). Recorte o amplíe el conjunto; el instalador conserva su versión durante las actualizaciones. En Kubernetes, incluya el YAML en un ConfigMap con la clave redaction-patterns.yaml y establezca troubleshooter.redaction.patternsConfigMap con su nombre; el chart lo monta en la misma ruta.
El solucionador de problemas no se inicia si existe un archivo de patrones no válido y registra la entrada que provoca el error. Un archivo configurado pero inexistente solo genera una advertencia en el log y se utilizan los patrones integrados. clicklink clctl preflight valida el archivo, por lo que debe ejecutarlo antes de reiniciar el daemon.

​
Réplicas privadas y endpoints dentro del perímetro

El chart publicado preconfigura image.repository con la imagen pública del conector, multiarquitectura y firmada con cosign, por lo que las instalaciones habituales no requieren valores de imagen. Para consultar los valores predeterminados publicados:
Para extraer desde tu propio registry, sobrescribe el repository en la superposición:
Para instalar el chart desde una réplica, init acepta --chart como el nombre de un chart que se resuelve en --chart-repo, o como una referencia directa oci://, una URL, un archivo local o un directorio. De forma predeterminada, --chart-version usa la propia versión de la CLI, por lo que el binary y el chart se actualizan juntos.
Cuando el endpoint de tu conector esté detrás de una CA privada dentro de tu perímetro, pasa --api-private-ca a init. Configura api.tls.caFile: /etc/clicklink/secrets/mtls/ca.crt, y el conector verifica el endpoint con las raíces del sistema más la cadena de CA de tu paquete de inscripción. En una VM, el equivalente es api.tls.ca_file en /etc/clicklink/config.yaml: init instala la cadena del paquete en /etc/clicklink/tls/ca.crt, y el conector la añade a las raíces del sistema de la misma forma. Para la inscripción y la firma de certificados en entornos completamente aislados, consulta onboarding.

​
Almacenamiento

Dos componentes mantienen estado en PersistentVolumeClaims. El del solucionador de problemas guarda el estado de sesión y el registro de auditoría:
El del executor guarda su base de datos de comandos y el registro de los servicios que administra:
init establece ambos valores de storageClass con la clase que hayas elegido. Un storageClass vacío utiliza la clase de almacenamiento predeterminada del cluster; si el cluster no tiene ninguna marcada como predeterminada, init solicitará una mediante el prompt o --storage-class. La claim del executor lleva la anotación helm.sh/resource-policy: keep, por lo que helm uninstall la deja intacta; consulta desinstalación.