Skip to main content

​
FAQ

​
Кто и когда может изменять мои сервисы?

В управляемом режиме ClickHouse Cloud изменяет только те сервисы, управление которыми вы ему поручили. Любой, у кого есть доступ к хосту или поду исполнителя, также может управлять ими локальными командами clicklink clctl instances; см. жизненный цикл сервиса. ClickHouse Cloud отправляет команды жизненного цикла через исходящий канал исполнителя:
  • создание — на основе отправленного вами определения
  • масштабирование — до фиксированного количества реплик, задаваемого ClickHouse Cloud (ограничено настройкой ClickHouse Cloud, в конфигурации по умолчанию — 20)
  • остановка, запуск и перезапуск
  • резервное копирование и удаление резервных копий
  • удаление
Обновления версий и изменения конфигурации поступают тем же путём — как повторно применённое определение сервиса; отдельного шага подтверждения со стороны клиента для них нет. Сеанс поддержки при этом не задействуется: канал исполнителя отделён от канала средства диагностики и не зависит от состояния сеанса. Двух действий система ждёт от вас. Для создания сервиса нужно выполнить clicklink clctl executor prepare и clicklink clctl instances create, поскольку только вы можете создать бакеты и роль IAM. Обновления компонентов платформы в вашем кластере также ждут вашего участия. Исполнитель подготавливает каждый предлагаемый пакет; ваша команда clicklink clctl platform approve утверждает его и выпускает токен со сроком действия 2 часа. См. обновления платформы. Всё, что делает исполнитель, происходит через Kubernetes API. Политика допуска ограничивает его операции записи пространствами имён с префиксом сервисов (по умолчанию ns-). Она также допускает три операции записи в собственном пространстве имён исполнителя: обновление токена, ConfigMap реестра сервисов и — в Kubernetes — обновлённый клиентский сертификат в Secret clicklink-mtls. Чтение тех же семейств ресурсов доступно в пределах всего кластера. Утверждённые обновления платформы выполняются от отдельной identity pcm-platform, ограниченной пространствами имён платформы. Кластеры, которыми вы управляете самостоятельно, никогда не изменяются: сборщик и средство диагностики работают только для чтения. Точные области действия приведены на странице модель привилегий.

​
Какие данные покидают мою среду?

Данные уходят наружу по трём каналам, и все они используют исходящие подключения, которые коннектор открывает сам: путь сбора метрик (scrape), исполнитель и включённые вами сеансы поддержки. Сборщик отправляет результаты из фиксированного набора системных таблиц: по умолчанию это metric_log, asynchronous_metric_log, tables, warnings и server_settings. Также он отправляет сигналы работоспособности и статуса, состояние сервисов и резервных копий и собственные метрики коннектора. Набор по умолчанию не включает system.query_log. Исходный текст SQL, а также любые литералы и персональные данные внутри него никогда не покидают среду по этому пути, если вы сами не добавите эту таблицу. Во время сеанса список разрешённых таблиц по умолчанию включает system.processes, где виден текст выполняющихся запросов; удалите её из списка, если эти данные должны оставаться скрытыми. Исполнитель отправляет результат каждой выполненной команды, а также состояние и количество реплик каждого управляемого сервиса. Его сигнал работоспособности сообщает, подключён ли командный канал. Он также передаёт версии компонентов платформы, дайджест последнего применённого пакета и результат последнего обновления платформы. При установке на ВМ сигнал также сообщает, в каком состоянии находится пакет доступа к Kubernetes: ok, expiring, expired — или что он отсутствует. При создании сервиса команда clicklink clctl instances create отправляет идентификатор вашей среды, облако и регион, имя сервиса, имена бакетов и ARN роли IAM. Она отправляет два хеша пароля пользователя default; сам пароль среду не покидает. Во время активного сеанса поддержки средство диагностики также возвращает вывод команд. Этот вывод ограничен разрешёнными таблицами ClickHouse и представлениями Kubernetes только для чтения, включая журналы подов. Перед отправкой он проходит маскирование (встроенные шаблоны для IP-адресов, учётных данных, токенов и ключей, а также ваши собственные). Данные ваших таблиц, резервные копии и история запросов (system.query_log, system.text_log) остаются в вашей среде. Наружу уходят только три вещи:
  • строки из разрешённых таблиц истории метрик (system.metric_log, system.asynchronous_metric_log) передаются при каждом сборе
  • текст выполняющихся запросов виден в сеансе через system.processes, если вы не удалите эту таблицу из списка разрешённых
  • журналы подов, прочитанные во время сеанса поддержки Kubernetes, уходят после маскирования
Полный список исходящих подключений приведён на странице модель привилегий.

​
Как запретить ClickHouse изменять мои кластеры?

Запускайте без управляемого режима. При установке передайте --no-managed в clicklink clctl init либо ответьте «нет» на соответствующий вопрос. Тогда развертываются только сборщик и средство диагностики, поэтому ClickHouse не сможет создавать, изменять или удалять сервисы. Коннектор по-прежнему создает пользователей ClickHouse только для чтения и ServiceAccounts; см. модель привилегий. Если установка уже выполнена, остановите исполнитель и отзовите его grant в роли cluster admin. Чтобы остановить его, задайте executor.enabled: false в значениях Helm и выполните helm upgrade либо выполните systemctl disable --now clicklink-executor на ВМ. Затем отзовите grant. Последняя команда удаляет сам ServiceAccount; его пространство имен — clicklink-system для установки на ВМ и пространство имен коннектора для установки в Kubernetes:
Сервисы, созданные ClickHouse, продолжают работать, но ClickHouse Cloud больше не может масштабировать, обновлять, создавать резервные копии или удалять их, а команды, ожидающие выполнения, завершаются с ошибкой. Обновления платформы также прекращаются: их часть с рабочими нагрузками применяет исполнитель, а он больше не запущен.

​
Что произойдёт, если коннектор недоступен?

На ваши сервисы ClickHouse это не влияет: коннектор не находится на пути данных, а управляемый сервис продолжает работать без исполнителя. Последствия — потеря наблюдаемости и управления. ClickHouse Cloud перестаёт получать телеметрию, а сеансы поддержки становятся недоступны, пока коннектор не вернётся в строй. В управляемом режиме ClickHouse Cloud отображает вашу среду как offline, если heartbeat не приходил в течение 5 минут, и снова как готовую — при поступлении следующего. Пока исполнитель не подключён, команды жизненного цикла ведут себя по-разному в двух случаях. Команда create, delete или platform sync, которую ClickHouse Cloud уже принял, сохраняется и повторяется. Создание повторяется до 30 минут с момента последнего отчёта о прогрессе, удаление — до 2 часов, а platform sync — до 10 попыток. После этого команда считается проваленной. Эти два горизонта задаются ключами конфигурации executor.create_retry_horizon и executor.delete_retry_horizon. Любая другая команда (scale, stop, start, restart, создание резервной копии, удаление резервной копии), а также любое создание или удаление, отправленное при отсутствии подключённого исполнителя, отклоняется при отправке и не ставится в очередь. Результат, который исполнитель не смог передать, отправляется при следующем соединении. См. когда коннектор недоступен. На ВМ сборщик буферизует собранные данные в /var/lib/clicklink/buffer всякий раз, когда конечная точка вашего коннектора недостижима (по умолчанию до 168 часов или 1024 МБ). При восстановлении соединения накопленные данные доставляются, поэтому недоступность конечной точки не приводит к потере телеметрии. Аварийно завершившийся daemon перезапускается systemd на ВМ и кубелетом в Kubernetes. Исполнитель хранит состояние команд на диске, поэтому после перезапуска выполнение незавершённых команд возобновляется. Для диагностики проверьте конечную точку /livez каждого компонента (сигналом служит поле status в JSON, а не HTTP-код) и выполните clicklink clctl preflight (с sudo на хосте ВМ). Preflight за один проход проверяет конфигурацию, сетевую связность, доступность ClickHouse, права доступа и диск. См. операции; если коннектор остаётся неработоспособным, обратитесь в ClickHouse Support.

​
Что удаляется при удалении сервиса?

Исполнитель останавливает сервис, удаляет его ресурсы Kubernetes и его пространство имен. Он сообщает о завершении работы сервиса, как только пространство имен удалено. Всё, что находится за пределами Kubernetes, сохраняется: бакет с данными, бакет с резервными копиями и роль IAM сервиса. Исполнитель не хранит учетных данных для ваших бакетов или IAM, поэтому он не может их затронуть. Остальное вы удаляете командой clicklink clctl executor teardown, запустив её со своими учетными данными. По умолчанию она удаляет роль IAM, но сохраняет данные и резервные копии; чтобы удалить и их, нужно указать явные флаги. См. удалить сервис.

​
Где найти пароль пользователя default?

clicklink clctl executor prepare генерирует его на вашей стороне и выводит ровно один раз. Если вы отправляете запрос с отдельными флагами вместо --from-prepare, то clicklink clctl instances create считывает его из --default-user-password-file либо создаёт и выводит сам. В ClickHouse Cloud передаются только его хеши, поэтому ни connector, ни ClickHouse не смогут показать его вам повторно. Сохраните пароль сразу, как только он отобразится.

​
Как отозвать доступ ClickHouse?

В порядке усиления мер:
  1. Завершите интерактивный доступ. Отключите сеанс: на хосте ВМ выполните sudo clicklink clctl troubleshoot session disable, а в Kubernetes — ту же команду с --gateway-url через проброс порта (точные команды приведены на странице сеансов поддержки). При отсутствии активного сеанса средство диагностики не выполняет никакие команды, даже при наличии подключения.
  2. Остановите управляемый режим. Остановите исполнителя и отзовите его grant, как описано в разделе Как запретить ClickHouse изменять мои кластеры?. Обновления платформы и без того требуют вашего подтверждения, поэтому отказ в нём их останавливает.
  3. Предотвратите будущие сеансы. Очистите список разрешённых операторов (пустой список закрывает шлюз) или отключите шлюз; на ВМ локальное управление сеансами остаётся доступным пользователю root на хосте. См. руководство по настройке.
  4. Отключите ClickHouse Cloud от коннектора. Заблокируйте исходящий трафик к конечной точке коннектора на сетевом уровне или очистите networkPolicy.allowEgressCIDRs при использовании CNI с принудительным применением политик. Коннектор работает только с исходящими подключениями, поэтому у ClickHouse Cloud нет входящего пути для его восстановления. Локальное чтение из ClickHouse продолжится, пока вы не остановите или не удалите рабочие нагрузки — это окончательная мера.
  5. Отзовите учётные данные. Удалите пользователей ClickHouse pcm_scraper и pcm_troubleshooter, а также Secrets коннектора в Kubernetes или файлы в /etc/clicklink на ВМ.
  6. Полностью удалите коннектор. См. operations.

​
Можно ли запустить это в изолированной от интернета среде или через собственные зеркала?

Да. Любой артефакт, требуемый при установке, может находиться внутри вашего контура:
  • Сделайте зеркало tar-архива CLI и контейнерного образа из releases.clicklink.clickhouse.com и публичного registry, затем укажите в image.repository адрес вашего зеркала.
  • Передайте --chart со ссылкой oci://, URL или локальным архивом. По умолчанию --chart-version соответствует версии самого CLI.
  • Если ваша конечная точка коннектора обслуживается внутри вашего контура за частным CA, параметр --api-private-ca (Kubernetes) или api.tls.ca_file (ВМ) добавит цепочку CA из пакета регистрации к системным корневым сертификатам.
  • Для регистрации без прямого подключения команда init --handoff принимает пакет, полученный по внешнему каналу, а --no-auto-sign вместе с init --signed-cert позволяет завершить подписание сертификата по внешнему каналу.
  • В управляемом режиме образы ClickHouse для ваших сервисов и компонентов платформы могут поступать из вашего собственного registry после того, как вы импортируете их туда; ClickHouse регистрирует этот registry для вашего окружения.
  • Пакеты платформы можно передать по внешнему каналу и подать в clicklink clctl platform approve --bundle в виде файла.
См. частные зеркала и раздел об изолированных от интернета средах в онбординге. Коннектору всё равно нужен маршрут до вашей конечной точки коннектора во время работы; без него ClickHouse Cloud не получает телеметрию, а команды управления жизненным циклом не доходят до исполнителя.

​
Как аудитируются сеансы поддержки?

Каждая команда, выполненная во время сеанса, — независимо от того, принята она или заблокирована, — добавляется в /var/log/clicklink/troubleshoot-audit.log в формате JSON с разделением по строкам. Каждая запись фиксирует submitted_by (Organization ID в канале команд), текст команды, целевой instance, результат, а для отклонённых команд — blocked_by. Вызовы шлюза, включая отклонённые, записываются как структурированные строки clctl.gateway в собственный журнал средства диагностики. Они атрибутируются подтверждённому токеном адресу электронной почты оператора, но никогда — указанному им самим имени. Изменения локального сеанса на ВМ фиксируют инициировавшего их пользователя хоста в поле enabled_by в /var/lib/clicklink/session.json. Время сеансов ограничено (по умолчанию — 4 часа, максимум — 24 часа). При каждом включении записываются сведения о том, кто его включил, когда оно истекает и, при необходимости, причина. Эти сведения отображает clicklink clctl troubleshoot session status. Просматривайте журнал аудита с помощью clicklink clctl troubleshoot audit tail. В Kubernetes эта команда является поддерживаемым средством чтения журнала (в образе среды выполнения нет оболочки). При установленном по умолчанию значении persistence.enabled: true журнал хранится в постоянном томе средства диагностики, поэтому сохраняется при перепланировании пода. При отключении сохранения журнал аудита и состояние сеанса существуют только в течение жизни пода; chart отмечает этот вариант как подходящий только для локальной разработки. По умолчанию ротация хранит 5 файлов размером до 128 МБ в течение 168 часов; см. справочник по конфигурации, чтобы изменить эти параметры, и сеансы поддержки с полным описанием модели доверия.
Последнее изменение 7 октября 2026 г.