Operaciones

Esta página abarca las operaciones del día 2 de ClickHouse Connector en ambos destinos de instalación. Para la instalación y la inscripción, consulta configuración inicial.

Actualiza la versión desde el repositorio público de charts reutilizando la superposición de values que preparó init:

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm upgrade --install clicklink-connector clicklink-connector \
  --repo https://releases.clicklink.clickhouse.com/charts \
  --version <version> \
  -n "${CONNECTOR_NAMESPACE}" \
  -f clicklink-values.yaml

Las versiones del chart son las etiquetas de versión sin la v inicial (el chart 0.9.0 corresponde a la etiqueta v0.9.0). El chart publicado ya apunta a la imagen de contenedor pública, por lo que las instalaciones y actualizaciones normales no requieren valores de imagen. Para inspeccionar los valores predeterminados del chart, ejecute helm show values clicklink-connector --repo https://releases.clicklink.clickhouse.com/charts.

Una instalación desde una referencia directa al chart (oci://, una URL o un archivo o directorio local) no tiene ningún repositorio frente al que resolverla: en su lugar, vuelva a ejecutar helm upgrade clicklink-connector <same-chart-reference> con la nueva versión. Volver a ejecutar init con una CLI más reciente también permite alcanzar el estado deseado, pero init siempre requiere uno de sus puntos de entrada: --handoff si conservó el paquete, o un token de inscripción nuevo con --force tras la limpieza documentada; el helm upgrade anterior es el procedimiento habitual (consulte repeticiones y recuperación).

Vuelva a ejecutar el instalador en el host; descargará y verificará la nueva versión del mismo modo que durante la configuración inicial, hará una copia de seguridad del binario anterior y conservará los patrones activos de redacción y el archivo de entorno. A continuación, reinicie los demonios:

curl -fsSL https://releases.clicklink.clickhouse.com/install.sh | sudo bash -s -- --host
sudo systemctl restart clicklink-scraper clicklink-troubleshooter

Para cambiar a una versión específica en lugar de la más reciente, añada --version vX.Y.Z al comando de instalación.

Cada demonio expone un endpoint /livez en su puerto de estado de salud. El campo JSON status del cuerpo de la respuesta indica el estado de salud, no el código de estado HTTP; por tanto, compruebe el cuerpo en lugar de basarse en un 200. Las métricas de Prometheus se exponen en el puerto de métricas de cada componente. Puertos predeterminados en ambos destinos:

Cuando las sesiones de soporte están habilitadas, el gateway también escucha en el puerto 8443: TLS autofirmado en una VM, HTTP local al pod mediante kubectl port-forward o un Ingreso de Kubernetes con terminación TLS.

En una VM, puede ejecutar el conjunto completo de comprobaciones en cualquier momento:

sudo clicklink clctl preflight

Comprueba la configuración, los archivos, los conflictos de puertos, la accesibilidad de la red (el endpoint de la API y cada instancia de ClickHouse), la conectividad con ClickHouse, el estado de la unidad de systemd, el acceso por componente, el disco y los patrones de redacción, y sale con 2 si falla alguna comprobación.

El conector renueva su propio certificado de Client: cada demonio comprueba el certificado de hoja cada 12 horas y lo renueva cuando le quedan 10 días de validez; recibe un certificado de hoja con una validez de 30 días a través del canal existente autenticado mediante mTLS y HMAC. No se requiere ninguna intervención del operador. En Kubernetes, el certificado de hoja renovado se vuelve a escribir en el secreto clicklink-mtls; en una VM, se escribe en /etc/clicklink/tls/.

Para consultar la fecha de caducidad actual:

# Linux VM
sudo openssl x509 -in /etc/clicklink/tls/client.crt -noout -enddate

# Kubernetes
CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
kubectl get secret clicklink-mtls -n "${CONNECTOR_NAMESPACE}" -o jsonpath='{.data.tls\.crt}' \
  | base64 -d | openssl x509 -noout -enddate

Solicite un token de inscripción nuevo a su equipo de cuentas de ClickHouse y vuelva a ejecutar el comando init original con --enroll y --force. Conserve todos los indicadores específicos del destino de la primera instalación (--target-namespace, --values y cualquier indicador de mirror como --chart, --chart-repo o --chart-version), ya que --force vuelve a preparar la configuración conservada. En una instalación predeterminada:

# Kubernetes, from your workstation
clicklink clctl init --enroll https://<subdomain>.<connector-domain> --target helm --force

# Linux VM, on the host
sudo clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force

Vuelva a aprovisionar los usuarios de solo lectura del connector en cada instancia. En Kubernetes, ejecute lo siguiente desde su estación de trabajo: --apply-ch-grants vuelve a aplicar los grants regenerados dentro del pod para que las nuevas credenciales lleguen a ClickHouse (si el usuario admin tiene una password, añada --ch-admin-password-stdin y canalícela):

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
clicklink clctl scraper access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force
clicklink clctl troubleshoot access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force

En una VM, en el host:

sudo clicklink clctl scraper access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --force
sudo clicklink clctl troubleshoot access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --force

Para las instancias administradas por un operador, añada --ch-user-via cr y los indicadores de selección de pods a cualquiera de las dos formas; consulte la referencia de la CLI.

La renovación es automática (consulta certificados). Para sustituir inmediatamente un certificado que aún no ha caducado, vuelve a ejecutar init con --force.

Las reejecuciones de init son convergentes, por lo que volver a ejecutar el mismo comando siempre es el primer paso. Sin --force, se conserva el archivo /etc/clicklink/config.yaml (VM) o la superposición clicklink-values.yaml (Kubernetes) existentes, y se reutiliza una clave de Client existente; las credenciales y la cadena de la CA se sobrescriben de forma atómica. Los comandos de recuperación que imprime la CLI tras un error parcial se pueden repetir sin problemas.

--force sobrescribe la configuración o superposición conservada, regenera la clave de Client y reemplaza un certificado de Client no expirado. Nunca genera un UUID de cluster nuevo: la identidad del connector se conserva incluso con --force.

Si la firma del certificado falló después de la preparación, o el endpoint de firma devolvió 409 porque ya existe un certificado no expirado, no necesita un token nuevo ni una segunda emisión. Complete la instalación con los materiales firmados que ya están en disco:

sudo clicklink clctl init --signed-cert client.crt --chain ca-chain.crt

Esa es la variante para VM (root reescribe /etc/clicklink y administra los servicios). En Kubernetes, la CLI imprime el formulario completo, incluidos --target helm, --target-namespace y --values; use el comando impreso tal cual.

uninstall.sh se incluye en el archivo tar de la versión. Si no queda ningún archivo tar extraído en el host, descargue y extraiga uno como se muestra en la descarga y verificación manuales y ejecútelo desde el directorio extraído:

sudo ./uninstall.sh

Esto detiene y deshabilita los servicios, y elimina las unidades de systemd y el binario, pero conserva /etc/clicklink, /var/lib/clicklink, /var/log/clicklink y el usuario clicklink, de modo que una reinstalación posterior recupera la configuración existente. Para eliminar también estos elementos:

sudo ./uninstall.sh --purge

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm uninstall clicklink-connector -n "${CONNECTOR_NAMESPACE}"

Los secretos creados por init no pertenecen al chart y se conservan tras la desinstalación. Elimínelos explícitamente, incluidos los secretos de acceso específicos de cada instancia que haya configurado:

kubectl delete secret clicklink-hmac clicklink-mtls -n "${CONNECTOR_NAMESPACE}"
kubectl delete secret -n "${CONNECTOR_NAMESPACE}" \
  clicklink-connector-scraper-access-<instance> \
  clicklink-connector-troubleshooter-access-<instance>
kubectl delete serviceaccount -n "${CONNECTOR_NAMESPACE}" \
  pcm-scraper-<instance> pcm-troubleshooter-<instance>
# Repeat for every ClickHouse namespace that holds a provisioned instance.
for ns in <clickhouse-namespace-1> <clickhouse-namespace-2>; do
  kubectl delete serviceaccount,role,rolebinding -n "${ns}" \
    pcm-scraper pcm-troubleshooter
done

Al desinstalar cualquiera de los destinos, los usuarios de solo lectura aprovisionados permanecen. Elimínelos como administrador en cada instancia (agregue su --ch-user-suffix a los nombres si configuró uno):

DROP USER IF EXISTS pcm_scraper, pcm_troubleshooter;