> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Actualizaciones de la plataforma
> Apruebe los paquetes de plataforma que ClickHouse Cloud propone para un cluster gestionado: qué es un paquete, cómo funciona la aprobación y qué permisos concede
export const Image = ({img, alt, size = "lg", background}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined;
return ;
};
export const PrivatePreviewBadge = () => {
return ;
};
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.
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.
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.
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.
```bash theme={null}
clicklink clctl commands list --status failed --action sync_platform
```
El campo `result` termina con `run: clctl platform approve (pending bundle sha )`. En Kubernetes, la indicación es `run: clctl platform approve --secret-namespace (pending bundle sha )`. 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:
```bash theme={null}
sudo cat /etc/clicklink/access/executor/platform-pending.json
```
El pod de Kubernetes del executor prepara el paquete en su volumen de estado y lo expone a través de su API local. Abra un reenvío de puertos y léalo:
```bash theme={null}
CONNECTOR_NAMESPACE='clicklink' # el espacio de nombres del connector que eligió en la inicialización
kubectl -n "${CONNECTOR_NAMESPACE}" port-forward deployment/clicklink-connector-executor 9999:9999 &
curl -s http://127.0.0.1:9999/v1/platform/pending
```
La API responde `404` con `no platform bundle is staged` hasta que llega la primera propuesta. Deje el reenvío de puertos abierto para el siguiente paso.
`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 ` si tu kubeconfig contiene varios) y las [credenciales del registry](#registry-credentials) 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:
```bash theme={null}
sudo clicklink clctl platform approve --config /etc/clicklink/config.yaml
```
`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.
En una implementación con registry replicado y la aprobación de plataforma de Kubernetes habilitada, `approve` lee el paquete preparado a través del reenvío de puertos del paso anterior. Entrega el paquete de tokens como un Secret en el espacio de nombres del conector, que el chart monta en el pod de Kubernetes. Ejecútalo desde una estación de trabajo cuyo kubeconfig llegue al cluster, con una copia de la configuración del conector y [acceso al registry](#registry-credentials). El chart renderiza la configuración en el ConfigMap del executor; `approve` la necesita únicamente para el prefijo del espacio de nombres y no lee ninguna credencial de ella.
```bash theme={null}
CONNECTOR_NAMESPACE='clicklink' # el espacio de nombres del conector que elegiste en init
kubectl -n "${CONNECTOR_NAMESPACE}" get configmap clicklink-connector-executor \
-o jsonpath='{.data.config\.yaml}' > clicklink-config.yaml
clicklink clctl platform approve --config clicklink-config.yaml \
--secret-namespace "${CONNECTOR_NAMESPACE}"
```
De forma predeterminada, `approve` lee el paquete preparado desde `http://127.0.0.1:9999`; usa `--endpoint` si tu reenvío de puertos emplea otro puerto local. Sin un reenvío de puertos se detiene e imprime el comando `kubectl port-forward` que debes ejecutar. El paquete queda en el Secret `clicklink-platform-bundle` (usa `--secret-name` para cambiarlo, en correspondencia con `executor.platformBundleSecret` del chart). El pod de Kubernetes del executor lo ve en cuanto el agente kubelet actualiza el montaje, en aproximadamente un minuto.
`approve` termina con:
```text theme={null}
Approved: permission object(s) applied, platform token valid until .
The executor may now apply the workload object(s) of this bundle inside .
```
En Kubernetes aparece una tercera línea: `Bundle written to Secret /; 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:
```bash theme={null}
clicklink clctl commands list --action sync_platform
```
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](/es/products/bring-your-own-cloud/connector/reference/privilege-model).
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 ` en Kubernetes. Las CustomResourceDefinitions, el RBAC y la StorageClass se mantienen. Ejecute `approve` de nuevo antes de la siguiente sincronización de la plataforma.
```bash theme={null}
sudo clicklink clctl platform reset --bundle --config /etc/clicklink/config.yaml --dry-run
```
`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.