Skip to main content
Un cluster gestionado ejecuta una pequeña capa de plataforma de la que dependen los servicios de ClickHouse. ClickHouse Cloud propone actualizaciones para esa capa; el executor no aplica ninguna hasta que usted apruebe cada una con las credenciales de su propio cluster.

​
Qué es una actualización de la plataforma

La capa de plataforma consta de tres componentes: el controlador de snapshots, el ClickHouse Operator y los collectors de monitorización. Se instalan en ese orden porque cada uno necesita las definiciones de custom resource del anterior. Los services utilizan una StorageClass llamada gp3-encrypted (volúmenes gp3 cifrados) que se incluye con ellos. Un paquete de plataforma es el manifiesto que ClickHouse Cloud renderiza para tu entorno. Fija las versiones de chart e image de esos componentes e indica el registry del que se descargan. Cada paquete se identifica por el sha256 de ese manifiesto. ClickHouse Cloud lo envía al executor a través del canal de comandos, y el executor lo deja preparado para que lo apruebes. Un paquete se aplica en dos mitades:
  • La mitad de permisos es todo aquello que concede o delimita el acceso: Espacios de nombres, CustomResourceDefinitions, ServiceAccounts, ClusterRoles y ClusterRoleBindings, Roles y RoleBindings, configuraciones de webhook y de admission, PriorityClasses y la StorageClass. Solo tú la aplicas, con tus credenciales, ejecutando clicklink clctl platform approve.
  • La mitad de workload es lo que se ejecuta: Deployments, Services, ConfigMaps, Secrets, Jobs y PodDisruptionBudgets. El executor la aplica con una identity dedicada, pcm-platform, que solo puede escribir esos tipos de recursos y únicamente mientras siga siendo válido el token de corta duración generado por tu aprobación.
El executor nunca aplica un paquete que no hayas aprobado. Rechaza cualquier sincronización de plataforma a la que le falte la mitad de permisos, cuyo sha256 difiera del aprobado o cuyo token haya expirado. El rechazo informa de que se requiere aprobación e indica el sha256 del paquete preparado. La creación de un service que necesite una definición de custom resource de la que carece tu plataforma actual falla del mismo modo, con el mismo comando a ejecutar.

​
Aprobar una actualización de la plataforma

​
Credenciales del registry

La authentication del registry depende del modo de distribución de imágenes registrado para su entorno:
  • Acceso directo al registry de ClickHouse. Ejecute la aprobación en la VM de EC2 del connector. Tanto approve como la sincronización de plataforma del executor asumen el rol de extracción de ECR de solo lectura de su entorno con credenciales del instance metadata service de EC2. Ese rol inicia sesión en el registry de charts, y el executor también lo usa para comprobar que existen las imágenes de la plataforma. Los perfiles de AWS, las credenciales de entorno o las credenciales de SSO en una workstation no sustituyen al perfil de instancia. Su kubeconfig sigue aportando las credenciales independientes de administración del cluster que aplican la mitad de permisos.
  • Charts en otro registry de ECR, incluido su propio mirror. El inicio de sesión en el chart utiliza las credenciales de AWS ambientales del proceso que ejecuta approve o el executor. Esas credenciales deben tener permiso de lectura sobre ese registry.
Utilice el procedimiento de workstation de Kubernetes que se describe a continuación únicamente para implementaciones con registry replicado y con la aprobación de plataforma de Kubernetes habilitada. En el caso del acceso directo, solicite primero a su account team que confirme un entorno de ejecución compatible con el perfil de instancia de EC2 requerido.
1

Busque el paquete en preparación

ClickHouse Cloud envía primero cada paquete propuesto al executor. El executor lo deja preparado como el paquete pending e informa su sha256 en el heartbeat. Existe un paquete preparado a la vez; una propuesta más reciente lo sustituye. Acto seguido, el executor rechaza la sincronización y registra un comando failed cuyo resultado termina con el comando que se debe ejecutar.
El campo result termina con run: clctl platform approve (pending bundle sha <sha256>). En Kubernetes, la indicación es run: clctl platform approve --secret-namespace <connector-namespace> (pending bundle sha <sha256>). Una creación que se encontró con una definición de recurso personalizado ausente incluye esa misma línea clctl platform approve. Aparece tanto en su propio comando fallido como en el error que imprime clicklink clctl instances create --wait. Su account team también le avisará cuando se proponga una actualización de plataforma.Lea el paquete preparado antes de aprobarlo. Contiene el manifiesto y su sha256.
El executor prepara el paquete como un archivo junto a sus access bundles en el host del connector:
2

Ejecute approve

approve sin indicadores lee el paquete preparado y calcula su hash, de modo que apruebas exactamente lo que recibió el executor. Renderiza cada chart tal y como lo hará el executor y aplica la mitad correspondiente a permisos con el contexto de kube que elijas. Crea la identidad pcm-platform si hace falta y genera su token. No realiza ninguna solicitud a tu endpoint del conector.approve necesita un contexto de kube con derechos de cluster-admin sobre el cluster gestionado (--context <name> si tu kubeconfig contiene varios) y las credenciales del registry correspondientes al modo de distribución de imágenes de tu entorno. --dry-run renderiza y enumera la mitad correspondiente a permisos sin aplicar ni generar nada; aun así necesita acceso al registry para renderizar los charts.
Ejecútalo en el host del conector, como root, donde el executor preparó el paquete:
approve escribe el token en /etc/clicklink/access/executor/_platform, junto a las demás credenciales del executor. Construye el nuevo paquete al lado del vigente y solo lo intercambia una vez que su token existe, de modo que una aprobación fallida deja intacto un token aún válido.
3

Confirmar

approve termina con:
En Kubernetes aparece una tercera línea: Bundle written to Secret <namespace>/<name>; the executor pod sees it once the kubelet refreshes the mount, within about a minute.ClickHouse Cloud reenvía la sincronización en cuanto el siguiente heartbeat del executor refleja la aprobación. Espera hasta 20 minutos si ya hay una sincronización en curso y omite cualquier executor cuyo último heartbeat tenga más de 5 minutos de antigüedad. Tras 3 intentos con un mismo paquete se detiene, y su account team vuelve a activarla. El executor aplica la mitad correspondiente al workload e informa la plataforma como synced. Compruebe que la sincronización se complete con:
El comando sync_platform más reciente pasa a completed. El executor también informa el estado de la plataforma y la versión de los componentes a ClickHouse Cloud en cada heartbeat, de modo que su account team verá el mismo resultado.

​
La ventana de aprobación

Una aprobación emite un token para la identity pcm-platform, válido durante 2 horas de forma predeterminada (--ttl lo modifica). El executor nunca lo renueva. Una vez que expira, el executor deja de poder actuar sobre la capa de plataforma y rechaza la siguiente sincronización de plataforma mostrando de nuevo el mensaje de aprobación. Esto es intencionado e independiente de la conectividad: una aprobación otorgada mientras el connector está desconectado expira igualmente según su propio reloj. Vuelve a ejecutar approve siempre que:
  • el token expire antes de que finalice la sincronización;
  • ClickHouse Cloud proponga un paquete distinto. El sha256 que aprobaste queda registrado en el ServiceAccount pcm-platform, y el executor rechaza la sincronización de cualquier otro paquete hasta que apruebes ese;
  • la creación de un service informe de una definición de custom resource ausente.
Volver a aprobar el mismo paquete es seguro y reemplaza el token. El paquete preparado permanece en su sitio tras la sincronización, por lo que una aprobación repetida no requiere una nueva propuesta.

​
Qué otorga la aprobación

Usted aplica la mitad de permisos, de modo que esta lleva su autoridad; el executor no aplica nada de esa mitad. approve la sella con el sha256 del paquete y, antes de tocar nada, el executor verifica que todos los objetos de permiso del paquete que se le envió estén presentes y aprobados. El executor aplica la mitad de workload como pcm-platform. Esa identity puede crear y actualizar Secrets, ConfigMaps, Services, Deployments, Jobs y PodDisruptionBudgets únicamente dentro de los espacios de nombres de la plataforma, algo que impone una política de admission. Puede leer los objetos que necesita para su preflight (pods, events, espacios de nombres, ServiceAccounts y los kinds de permisos mencionados arriba). No puede:
  • escribir en ningún kind con alcance de cluster ni en ningún objeto RBAC;
  • ejecutar escalate, bind o impersonate;
  • emitir ni renovar su propio token.
La identity de ciclo de vida de services del executor, pcm-executor, es independiente y está confinada a los espacios de nombres de los services. No puede escribir en los espacios de nombres de la plataforma; sus reads no están limitados por la protección de prefix. Para ver la enumeración completa de ambas identities, consulte el modelo de privilegios.

​
Restablecer un cluster de prueba

clicklink clctl platform reset está pensado para clusters de prueba: desinstala los componentes de la plataforma para poder volver a probar su primera instalación. Antes de modificar nada, enumera los clusters de ClickHouse de los espacios de nombres que pertenecen a este connector y se niega a continuar si existe algún service. En un cluster vacío, desinstala las releases de la plataforma en orden inverso al de dependencias. A continuación, elimina el paquete de tokens de plataforma del executor: el directorio local en una VM, o el Secret indicado por --secret-namespace <connector-namespace> en Kubernetes. Las CustomResourceDefinitions, el RBAC y la StorageClass se mantienen. Ejecute approve de nuevo antes de la siguiente sincronización de la plataforma.
reset recibe el manifiesto de plataforma renderizado como archivo (--bundle); no lee el paquete preparado. --dry-run comprueba los servicios e imprime el plan sin modificar el cluster.
Última modificación el 26 de septiembre de 2026