Actualizaciones
Kubernetes
Las operaciones de Kubernetes posteriores a la implementación usan la CLI de
helm en tu estación de trabajo. Solo init incluye un cliente de Helm integrado, así que instala helm antes de realizar tu primera actualización.init:
v inicial (el chart X.Y.Z corresponde a la etiqueta vX.Y.Z). 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. El executor se ejecuta como una única réplica con la estrategia Recreate, por lo que una actualización lo desconecta brevemente. Consulte cuando el connector está sin conexión para saber qué ocurre con los comandos durante esa ventana.
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 requiere un punto 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).
Máquina virtual Linux
Vuelva a ejecutar el instalador en el host. Descargará y verificará la nueva versión igual que durante la configuración inicial. Hará una copia de seguridad del binario anterior, instalará las unidades de systemd actuales y conservará los patrones activos de redacción y el archivo de entorno. A continuación, reinicie los demonios:--version vX.Y.Z al comando de instalación.
Estado de salud
Cada demonio expone un endpoint/livez en su puerto de estado de salud. El indicador de estado de salud es el campo JSON status del cuerpo de la respuesta, no el código de estado HTTP. Las métricas de Prometheus se exponen en /metrics en el mismo puerto; no hay un puerto de métricas separado. Puertos predeterminados en ambos destinos:
El executor también expone su API de comandos local en
127.0.0.1:9999. No cuenta con autenticación propia y nunca se expone fuera del host o del pod de Kubernetes; los comandos de servicio de clicklink clctl acceden a ella localmente.
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, ejecute el conjunto completo de comprobaciones en cualquier momento:
2 si falla alguna comprobación.
Certificados
El conector renueva su propio certificado de Client. El scraper, el solucionador de problemas y el executor comprueban cada uno el certificado de hoja cada 12 horas y lo renuevan cuando le quedan 10 días de validez. La renovación devuelve un certificado de hoja con una validez de 30 días a través del canal existente autenticado mediante mTLS y HMAC, por lo que no se requiere ninguna intervención del operador. En Kubernetes, el demonio vuelve a escribir el certificado de hoja renovado en el secretoclicklink-mtls; en una VM, lo escribe en /etc/clicklink/tls/.
Para consultar la fecha de caducidad actual:
Rotación de credenciales
Credenciales de API (HMAC)
Solicite un token de inscripción nuevo a su account team y vuelva a ejecutar el comandoinit 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. El modo Managed se hereda de la configuración que se está reemplazando, por lo que --managed es opcional aquí. En una instalación predeterminada:
init solo habilita e inicia las unidades que aún no están en ejecución, por lo que debe reiniciar los demonios después de la rotación:
init crea de antemano los secretos clicklink-hmac y clicklink-mtls rotados; el chart no los genera. Su anotación de suma de comprobación no los incluye, por lo que los pods en ejecución conservan las credenciales con las que se iniciaron. Reinicie todos los componentes después de la rotación:
Para la rotación desatendida en la que el aprovisionamiento mediante SQL requiere una contraseña, stdin recibe ambos secretos en este orden: el token en la primera línea y la contraseña en la segunda. La lectura del token consume exactamente una línea.
Usuarios de ClickHouse
Vuelva a aprovisionar los usuarios de solo lectura del connector en cada instancia que haya registrado usted mismo. En Kubernetes, ejecute los comandos 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 contraseña, añada --ch-admin-password-stdin y canalícela:
--ch-user-via cr:
--ch-user-via cr y los indicadores de selección de pods a cualquiera de las dos formas; consulte la referencia de la CLI.
Certificado de Client
La renovación es automática (consulta certificados). Para sustituir inmediatamente un certificado que aún no ha caducado, vuelve a ejecutarinit con --force. Después, reinicia cada component para que los demonios presenten el nuevo certificado de hoja: en Kubernetes, como se describe en credenciales de API; en una VM, las tres unidades.
Reejecuciones y recuperación
Las reejecuciones deinit 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; init sobrescribe las credenciales y la cadena de la CA 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, por lo que la identidad del connector se conserva. La postura de modo Managed de la configuración reemplazada se mantiene en las reejecuciones desatendidas y se ofrece como valor predeterminado en un terminal, salvo que pase --managed o --no-managed.
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:
/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.
Connector sin conexión. Mientras el connector está caído o inaccesible, los servicios que administra siguen funcionando. El ClickHouse Operator de su cluster los mantiene activos, y el executor no está en el data path. Los cambios de ciclo de vida requieren que el executor esté conectado, por lo que ninguno se aplica hasta que se reconecte. Al reiniciarse, el executor recupera de su base de datos de comandos aquellos que estaban en curso. Un comando que ClickHouse Cloud vuelve a entregar se responde con el resultado registrado; solo se vuelve a ejecutar un comando fallido. Para los comandos de ciclo de vida cuando no hay ningún executor conectado, consulte cuando el connector está sin conexión.
Desinstalar
Linux VM
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 (consulte la descarga y verificación manuales). Ejecute uninstall.sh desde el directorio extraído:
clicklink-scraper, clicklink-troubleshooter y clicklink-executor, y elimina las unidades de systemd y el binario. Conserva lo siguiente, de modo que una reinstalación posterior recupera la configuración existente:
/etc/clicklink, incluidos los access bundles del executor en/etc/clicklink/access/executor/var/lib/clicklink, incluidas la base de datos de comandos del executorexecutor.dby el registry de servicios/var/log/clicklink- el usuario
clicklink
clicklink-system; elimínelo cuando ya no lo utilice nada más.
Kubernetes
helm.sh/resource-policy: keep, por lo que la desinstalación lo deja intacto junto con la base de datos de comandos y el registry de servicios que contiene. Los secretos que creó init, el secreto del paquete de plataforma que escribió platform approve y el ConfigMap del registry de servicios que mantiene el executor tampoco pertenecen al chart y sobreviven a la desinstalación. Elimínalos de forma explícita. Incluye el par de secreto de acceso y ServiceAccount de cada instancia que hayas registrado tú mismo y de cada managed service para el que hayas aprovisionado el solucionador de problemas (con el nombre del service). --ignore-not-found contempla los objetos que nunca llegaron a crearse, como el secreto del paquete de plataforma antes de una primera aprobación:
init aplicó el grant del executor a nivel de todo el cluster, no el del chart. Elimínalo como administrador del cluster una vez que no queden managed services:
La capa de plataforma
Desinstalar el connector no elimina la capa de plataforma. Los espacios de nombres y los workloads de la plataforma, el RBACpcm-platform y los objetos de admission que instalaron tus aprobaciones permanecen en el cluster, al igual que todos los managed services. Elimina primero los services; consulta eliminar un service. En un cluster de pruebas sin services, clicklink clctl platform reset desinstala los releases de la plataforma. Las CustomResourceDefinitions, el RBAC y la clase de almacenamiento que quedan deben eliminarse manualmente; consulta restablecer un cluster de pruebas. Fuera de un cluster de pruebas, acuerda un plan de eliminación con tu account team antes de modificar la capa de plataforma.
Usuarios de ClickHouse
Al desinstalar cualquiera de los destinos, los usuarios de solo lectura aprovisionados permanecen en las instancias que registró usted mismo. Elimínelos como administrador en cada instancia (agregue su--ch-user-suffix a los nombres si configuró uno):