Operations

На этой странице рассматривается эксплуатация коннектора после развертывания для обоих вариантов установки. Инструкции по установке и онбордингу см. в разделе онбординг. Эксплуатация самих сервисов (создание, масштабирование, удаление и обновления платформы) описана в разделах managed services и platform updates.

Обновление

Kubernetes

Для операций Kubernetes после первоначального развертывания используется CLI helm, установленный на рабочей станции. Только init содержит встроенный клиент Helm, поэтому перед первым обновлением установите helm.

Обновите релиз из публичного репозитория chart с оверлеем values, подготовленным 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

Версии chart — это теги релизов без начального v (chart X.Y.Z соответствует тегу vX.Y.Z). Опубликованный chart уже указывает на публичный образ контейнера, поэтому при обычной установке и обновлении не нужно задавать значения image. Чтобы просмотреть значения chart по умолчанию, выполните helm show values clicklink-connector --repo https://releases.clicklink.clickhouse.com/charts. Исполнитель работает в одной реплике со стратегией Recreate, поэтому при обновлении он ненадолго отключается. О том, что происходит с командами в этот период, см. когда connector offline. При установке по прямой ссылке на chart (oci://, URL или локальный архив либо каталог) отсутствует repository, по которому можно определить обновление. Вместо этого выполните helm upgrade clicklink-connector <same-chart-reference> повторно, указав новую версию. Повторный запуск init с более новой версией CLI также приведёт систему к нужному состоянию, но требует точки входа: --handoff, если вы сохранили bundle, или новый токен регистрации с --force после описанной в документации очистки. Приведённая выше команда helm upgrade — стандартный способ (см. повторные запуски и восстановление).

Linux VM

Повторно запустите установщик на хосте. Он скачает и проверит новый релиз так же, как во время онбординга. Он создаст резервную копию предыдущего бинарного файла, установит текущие юниты systemd и сохранит действующие шаблоны маскирования и файл окружения. Затем перезапустите демоны:

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

Чтобы перейти на конкретный релиз вместо последнего, добавьте --version vX.Y.Z к команде установки.

Проверка работоспособности

Каждый демон предоставляет конечную точку /livez на порту проверки работоспособности. Индикатором работоспособности служит поле JSON status в теле ответа, а не код состояния HTTP. Метрики Prometheus доступны по пути /metrics на том же порту; отдельного порта метрик нет. Порты по умолчанию для обеих целей:

Компонент	Порт проверки работоспособности
Скрапер	8082
Средство диагностики	8084
Исполнитель	8086

Исполнитель также предоставляет свой локальный API команд по адресу 127.0.0.1:9999. Собственной аутентификации у него нет, и он никогда не доступен за пределами хоста или пода; сервисные команды clicklink clctl обращаются к нему локально. Когда включены сеансы поддержки, шлюз также прослушивает порт 8443: с самоподписанным TLS на виртуальной машине, по pod-local HTTP через kubectl port-forward или через входной шлюз с терминацией TLS в Kubernetes. На виртуальной машине полный набор проверок можно запустить в любое время:

sudo clicklink clctl preflight

Проверяет конфигурацию, файлы, конфликты портов, доступность сети, подключение к ClickHouse, состояние юнита systemd, доступ к каждому компоненту, диск и шаблоны маскирования. При сбое любой проверки завершает работу с кодом 2.

Сертификаты

Коннектор самостоятельно продлевает свой клиентский сертификат. Scraper, средство диагностики и исполнитель каждые 12 часов проверяют срок действия конечного сертификата и продлевают его, когда до истечения остаётся 10 дней. При продлении по существующему каналу с mTLS и HMAC-аутентификацией возвращается новый конечный сертификат сроком на 30 дней, поэтому действия оператора не требуются. В Kubernetes демон записывает обновлённый конечный сертификат обратно в Secret clicklink-mtls; на виртуальной машине — в /etc/clicklink/tls/. Чтобы проверить текущий срок действия:

# 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

Ротация учётных данных

Учетные данные API (HMAC)

Запросите новый токен регистрации у команды сопровождения аккаунта ClickHouse, затем повторно выполните исходную команду init с параметрами --enroll и --force. Сохраните все флаги, относящиеся к целевому развертыванию, из первой установки (--target-namespace, --values, а также все флаги mirror: --chart, --chart-repo и --chart-version), поскольку --force повторно развертывает сохраненную конфигурацию. Режим Managed переносится из заменяемой конфигурации, поэтому флаг --managed здесь необязателен. Для установки по умолчанию:

# 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

На ВМ команда init включает и запускает только те юниты, которые еще не запущены, поэтому после ротации перезапустите демоны:

sudo systemctl restart clicklink-scraper clicklink-troubleshooter clicklink-executor

В Kubernetes init заранее создает обновленные Secret-ы clicklink-hmac и clicklink-mtls; чарт их не формирует. Его annotation с checksum их не охватывает, поэтому запущенные поды продолжают использовать те учетные данные, с которыми были запущены. После ротации перезапустите каждый компонент:

kubectl rollout restart deployment,statefulset -n "${CONNECTOR_NAMESPACE}" \
  -l app.kubernetes.io/part-of=clicklink-connector

Для автоматической ротации, когда для настройки SQL требуется пароль, через stdin последовательно передаются оба секрета: токен в первой строке, пароль — во второй. При чтении токена считывается ровно одна строка.

printf '%s\n' "$ENROLLMENT_TOKEN" "$CH_ADMIN_PASSWORD" | \
  clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force --ch-admin-password-stdin

Пользователи ClickHouse

Повторно создайте пользователей коннектора с доступом только для чтения для каждого инстанса, который вы зарегистрировали самостоятельно. В Kubernetes выполните команды на рабочей станции. --apply-ch-grants повторно применяет обновлённые привилегии внутри пода, чтобы новые учётные данные попали в ClickHouse; если у пользователя admin задан пароль, добавьте --ch-admin-password-stdin и передайте пароль через канал:

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

На виртуальной машине выполните их на хосте, передав пароль пользователя admin через канал; там пароль обязателен, если только вы не указали --ch-user-via cr:

printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl scraper access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --ch-admin-password-stdin --force
printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl troubleshoot access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --ch-admin-password-stdin --force

Для инстансов под управлением оператора добавьте --ch-user-via cr и флаги выбора пода в любой из вариантов; см. справочник CLI.

Клиентский сертификат

Продление выполняется автоматически (см. сертификаты). Чтобы немедленно заменить ещё действующий сертификат, повторно выполните init с параметром --force. Затем перезапустите все компоненты, чтобы демоны начали предъявлять новый конечный сертификат: в Kubernetes — так, как описано в разделе API credentials, а на ВМ — все три юнита.

Повторные запуски и восстановление

Повторный запуск init приводит систему к согласованному состоянию, поэтому первым делом всегда следует повторно выполнить ту же команду. Без --force сохраняются существующие /etc/clicklink/config.yaml (VM) или оверлей clicklink-values.yaml (Kubernetes), а существующий клиентский ключ используется повторно; init перезаписывает учетные данные и цепочку CA атомарно. Команды восстановления, которые CLI выводит после частичного сбоя, можно безопасно выполнять повторно. --force перезаписывает сохраненную конфигурацию или оверлей, генерирует новый клиентский ключ и заменяет действующий клиентский сертификат. Он никогда не создает новый UUID кластера, поэтому идентичность коннектора сохраняется. Управляемый режим заменяемой конфигурации сохраняется при автоматических повторных запусках и предлагается по умолчанию в терминале, если вы не передали --managed или --no-managed. Если подписание сертификата завершилось ошибкой после промежуточного хранения или конечная точка подписания вернула 409, так как действующий сертификат уже существует, новый токен или повторный выпуск не требуются. Завершите установку, используя уже подписанные материалы на диске:

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

Это вариант для виртуальной машины (root перезаписывает /etc/clicklink и управляет сервисами). В Kubernetes CLI выводит полный вариант, включая --target helm, --target-namespace и --values; используйте выведенную команду без изменений. Коннектор офлайн. Пока коннектор не работает или недоступен, управляемые им сервисы продолжают работать. ClickHouse Operator в вашем кластере поддерживает их в рабочем состоянии, а исполнитель не находится в пути данных. Для изменений жизненного цикла требуется подключенный исполнитель, поэтому ни одно из них не применяется до повторного подключения. При перезапуске исполнитель восстанавливает из своей базы данных команд команды, выполнение которых не было завершено. Команда, повторно доставленная ClickHouse Cloud, обрабатывается на основе записанного результата; повторно выполняется только команда, завершившаяся ошибкой. О командах жизненного цикла, когда ни один исполнитель не подключен, см. когда коннектор офлайн.

Удаление

Перед удалением удалите все управляемые сервисы, как описано в разделе удалить сервис, и дождитесь завершения каждой операции. Если сначала удалить connector, у сервисов не останется компонента, способного управлять их жизненным циклом.

Linux VM

Скрипт uninstall.sh входит в архив релиза. Если на хосте не сохранился распакованный архив, скачайте и распакуйте его (см. ручная загрузка и проверка). Запустите uninstall.sh из распакованного каталога:

sudo ./uninstall.sh

Это останавливает и отключает юниты clicklink-scraper, clicklink-troubleshooter и clicklink-executor, а также удаляет юниты systemd и бинарный файл. При этом сохраняется следующее, поэтому при последующей установке будет использована существующая конфигурация:

/etc/clicklink, включая access bundles исполнителя в /etc/clicklink/access/executor
/var/lib/clicklink, включая базу данных команд исполнителя executor.db и registry сервисов
/var/log/clicklink
пользователь clicklink

Чтобы удалить и их:

sudo ./uninstall.sh --purge

Кластерный grant исполнителя хранится в вашем кластере, а не на хосте. Удалите его от имени администратора кластера, когда не останется управляемых сервисов:

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n clicklink-system

Grant также создал пространство имен clicklink-system; удалите его, когда оно больше ничем не используется.

Kubernetes

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

PersistentVolumeClaim исполнителя помечен аннотацией helm.sh/resource-policy: keep, поэтому при удалении он сохраняется вместе с базой данных команд и реестром сервисов на нём. Secret’ы, созданные командой init, Secret с platform bundle, записанный командой platform approve, и ConfigMap реестра сервисов, который ведёт исполнитель, также не принадлежат чарту и остаются после удаления. Удалите их явно. Включите пару из Secret с доступом и ServiceAccount для каждого инстанса, зарегистрированного вами вручную, и для каждого управляемого сервиса, для которого вы развернули средство диагностики (они названы по имени сервиса). Флаг --ignore-not-found учитывает объекты, которые так и не были созданы, — например, Secret с platform bundle до первого одобрения:

kubectl delete pvc -n "${CONNECTOR_NAMESPACE}" -l app.kubernetes.io/instance=clicklink-connector --ignore-not-found
kubectl delete secret clicklink-hmac clicklink-mtls clicklink-platform-bundle -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete configmap clicklink-instance-registry -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete secret -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  clicklink-connector-scraper-access-<instance> \
  clicklink-connector-troubleshooter-access-<instance>
kubectl delete serviceaccount -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  pcm-scraper-<instance> pcm-troubleshooter-<instance>
# Repeat for every ClickHouse namespace that holds an instance you registered yourself;
# a managed service's namespace went away with the service.
for ns in <clickhouse-namespace-1> <clickhouse-namespace-2>; do
  kubectl delete serviceaccount,role,rolebinding -n "${ns}" --ignore-not-found \
    pcm-scraper pcm-troubleshooter
done

init применил общекластерный grant исполнителя, а не chart. Удалите его от имени администратора кластера, когда не останется ни одного управляемого сервиса:

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n "${CONNECTOR_NAMESPACE}"

Платформенный слой

Удаление коннектора не удаляет платформенный слой. Пространства имен и рабочие нагрузки платформы, RBAC pcm-platform и объекты допуска, установленные при ваших одобрениях, остаются в кластере, как и все управляемые сервисы. Сначала удалите сервисы; см. удалить сервис. На тестовом кластере без сервисов команда clicklink clctl platform reset удаляет релизы платформы. Оставшиеся после нее CustomResourceDefinition, RBAC и класс хранилища приходится удалять вручную; см. сброс тестового кластера. За пределами тестового кластера согласуйте план удаления с командой сопровождения аккаунта ClickHouse, прежде чем вносить изменения в платформенный слой.

Пользователи ClickHouse

При удалении с любого из целевых экземпляров подготовленные пользователи с правом только на чтение остаются на инстансах, которые вы зарегистрировали самостоятельно. Удалите их от имени администратора на каждом экземпляре (если вы задали --ch-user-suffix, добавьте его к именам):

DROP USER IF EXISTS pcm_scraper, pcm_troubleshooter;

Начало работы

Сервисы и инфраструктура

Собственное облако

Данные и интеграции

Подключение и выполнение запросов

Управление доступом

Безопасность и соблюдение требований

Мониторинг и резервные копии

Инструменты и агенты ИИ

Cloud API

Оплата

Поддержка

ClickHouse Private

Обновление

Kubernetes

Linux VM

Проверка работоспособности

Сертификаты

Ротация учётных данных

Учетные данные API (HMAC)

Пользователи ClickHouse

Клиентский сертификат

Повторные запуски и восстановление

Удаление

Linux VM

Kubernetes

Платформенный слой

Пользователи ClickHouse

​Обновление

​Kubernetes

​Linux VM

​Проверка работоспособности

​Сертификаты

​Ротация учётных данных

​Учетные данные API (HMAC)

​Пользователи ClickHouse

​Клиентский сертификат

​Повторные запуски и восстановление

​Удаление

​Linux VM

​Kubernetes

​Платформенный слой

​Пользователи ClickHouse

Обновление

Kubernetes

Linux VM

Проверка работоспособности

Сертификаты

Ротация учётных данных

Учетные данные API (HMAC)

Пользователи ClickHouse

Клиентский сертификат

Повторные запуски и восстановление

Удаление

Linux VM

Kubernetes

Платформенный слой

Пользователи ClickHouse