Skip to main content
En esta página se describen los cambios de configuración que probablemente realizará después de instalar ClickHouse Connector. Para consultar cada clave, su valor predeterminado y su significado, vea la referencia de configuración; para los indicadores de línea de comandos, consulte la referencia de la CLI.

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 deliberado que se explica en 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:

Añadir o modificar instancias de ClickHouse

Cada entrada en instances define un endpoint del protocolo nativo de ClickHouse desde el que el conector lee: host, port, database, secure y, en Kubernetes, namespace y cluster. Las credenciales nunca se incluyen en la configuración; cada componente obtiene su usuario de ClickHouse de solo lectura del paquete de acceso que crea el aprovisionamiento.
Añada la instancia a ambos mapas de componentes de clicklink-values.yaml e incluya su espacio de nombres en networkPolicy.clickhouseNamespaces (que se compara con la etiqueta kubernetes.io/metadata.name del espacio de nombres):
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 operadores permitidos

Las sesiones administradas mediante Gateway están restringidas por una lista de direcciones de correo electrónico de operadores permitidos: 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, por lo que nadie puede abrir una sesión a través de él. 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 se 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 predeterminada con una lista de permitidos para la salida (networkPolicy.enabled: true). Los objetos NetworkPolicy solo surten efecto cuando su CNI los aplica; con un CNI que los aplica, el conector no tiene salida alguna hasta que allowEgressCIDRs especifique los CIDR asociados al API endpoint de su conector.
Dos reglas requieren especial atención:
  • apiserverCIDRs: si está vacío, el chart no genera ninguna regla de salida para el servidor de API. Los daemons fallarán en su primera solicitud de token de Kubernetes con un error de red, lo que indica que debe configurarlo. En Kubernetes gestionado, use los CIDR de los endpoints del servidor de API del cluster.
  • clctl.gateway.jwksEgressCIDRs: cuando el gateway de sesión está habilitado, el solucionador de problemas obtiene los JWKS de su proveedor de identidad para validar los tokens de operador. Con una política de denegación predeterminada, dejarlo vacío bloquea todas las comprobaciones de tokens:
El ejemplo es el rango private.googleapis.com, que cubre un proveedor de identidad de Google accesible mediante Private Google Access; para cualquier otro proveedor de identidad, proporcione el rango de ese proveedor (o el CIDR del proxy de salida situado delante de él). Otros dos parámetros de Ingreso: metricsScrapeSelector restringe el Ingreso para la recopilación de métricas a un espacio de nombres específico de Prometheus mediante una etiqueta, y kubeletProbeCIDRs permite explícitamente las sondas de estado del agente kubelet en entornos con una política predeterminada estricta de denegación. Consulte la referencia de configuración para ver la lista completa de claves.

Patrones de redacción

La salida del solucionador de problemas se redacciona antes de salir de su perímetro. Los patrones integrados cubren ipv4, ipv6, bearer-token, aws-access-key, email, jwt, ssh-private-key y connection-string-credentials. Puede añadir sus propios patrones en un archivo YAML; 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 sustituye dicho patrón. 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 incluye una configuración predeterminada comentada y 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. 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 binario y el chart se actualizan juntos:
Cuando el endpoint de la API 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 para que el endpoint se verifique con la cadena de CA de tu paquete de inscripción, en lugar de con las raíces del sistema. 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 la añade a las raíces del sistema para la verificación. Para la inscripción y la firma de certificados en entornos completamente aislados, consulta onboarding.

Almacenamiento

El solucionador de problemas conserva su estado en un PersistentVolumeClaim, de modo que el estado de la sesión y el registro de auditoría se mantienen tras reprogramar el pod de Kubernetes:
Una storageClass vacía utiliza la clase de almacenamiento predeterminada del clúster. Si el clúster no tiene ninguna marcada como predeterminada, init requiere una, mediante el prompt o --storage-class.
Última modificación el 26 de agosto de 2026