Что делает коннектор
Коннектор ClickHouse — это компонент, который вы разворачиваете в собственной среде. Он позволяет ClickHouse Cloud управлять сервисами ClickHouse в вашем Kubernetes-кластере, отслеживать их состояние и оказывать поддержку. Коннектор устанавливает только исходящие подключения и действует от имени учётных сущностей, ограниченных областью этих сервисов. Он поставляется в виде одного бинарного файлаclicklink, который содержит демоны и инструментарий clicklink clctl для их установки и эксплуатации.
Коннектор состоит из трёх компонентов:
- Исполнитель управляет жизненным циклом сервисов, которые вы передаёте под управление ClickHouse. Он создаёт каждый сервис по отправленному вами определению, а затем применяет команды scale, stop, start, restart, backup и delete, поступающие из ClickHouse Cloud. Работа с запущенным исполнителем называется управляемым режимом.
- Scraper собирает метрики из разрешённого списка (allowlist) системных таблиц ClickHouse, а также метаданные инфраструктуры и данные о состоянии, и отправляет их в ClickHouse Cloud.
- Средство диагностики позволяет инженерам поддержки ClickHouse выполнять диагностику в режиме только для чтения в ходе сеанса поддержки, который вы включаете и можете завершить в любой момент.
init спрашивает, включить ли управляемый режим, и по умолчанию предлагает «да»; в скриптах необходимо передавать --managed. Без управляемого режима коннектор по-прежнему обеспечивает наблюдение и поддержку для кластеров, которыми вы управляете самостоятельно; см. запуск без управляемого режима.
Все соединения, которые устанавливает коннектор, — исходящие; ClickHouse Cloud никогда не инициирует подключение к вашей среде. На странице архитектуры перечислены все соединения, используемые ими протоколы и способы аутентификации.
Когда его использовать
Разверните коннектор, если вы хотите, чтобы ClickHouse Cloud управлял сервисами ClickHouse внутри вашего собственного облачного аккаунта при следующих ограничениях:- Все пути доступа начинаются внутри вашего периметра; входящие подключения отсутствуют.
- Запись в ваш кластер ограничена пространствами имен тех сервисов, которыми управляет ClickHouse, а также собственным токеном, реестром и обновленным сертификатом исполнителя в его домашнем пространстве имен. Компоненты платформы, от которых зависят эти сервисы, изменяются только после того, как вы одобрите каждое обновление.
- Ваши данные остаются в бакетах и под защитой ролей IAM, которые вы создаете и удаляете самостоятельно. У исполнителя нет учетных данных для доступа к вашим бакетам или ролям IAM.
- Доступ для службы поддержки ограничен по времени, предоставляется вами и может быть отозван в любой момент. Каждая команда, выполненная в рамках сеанса поддержки, попадает в журнал аудита, который принадлежит вам.
Как это работает
Во время онбординга ClickHouse регистрирует вашу среду и предоставляет конечную точку коннектора и одноразовый токен регистрации. Командаclicklink clctl init --enroll выполняется один раз: с рабочей станции с доступом через kubeconfig — при установке в Kubernetes, либо непосредственно на хосте — при установке на Linux VM. Эта команда активирует token, получает клиентский сертификат mTLS, разворачивает и запускает демоны, а также проверяет их работоспособность.
При включении управляемого режима разворачивается исполнитель и применяется его grant доступа к Kubernetes. Этот grant представляет собой ServiceAccount pcm-executor. Политика допуска ограничивает его операции записи пространствами имен сервисов (по умолчанию с префиксом ns-). Исключения — обновление его собственного токена, одна ConfigMap реестра и, в случае Kubernetes, обновленный клиентский сертификат в его домашнем пространстве имен.
Создание сервиса выполняется двумя командами. clicklink clctl executor prepare создает бакеты сервиса и роль IAM с использованием ваших учётных данных AWS и однократно показывает пароль пользователя default. clicklink clctl instances create отправляет определение сервиса в ClickHouse Cloud через вашу конечную точку коннектора. После этого ClickHouse Cloud управляет сервисом через исходящий командный канал исполнителя: scaling, остановка и запуск, перезапуски, резервные копии, обновления версий и изменения конфигурации. Пошаговое описание см. в разделе управляемые сервисы.
Два действия остаются за вами. Обновления компонентов платформы в вашем кластере ожидают вашего одобрения; см. обновления платформы. При удалении сервиса удаляются только его ресурсы Kubernetes; бакеты и роль IAM сохраняются, пока вы не выполните clicklink clctl executor teardown.
Scraper с фиксированным интервалом считывает разрешенные системные таблицы и отправляет метрики, метаданные и health status на вашу конечную точку коннектора по mTLS. Средство диагностики держит открытым исходящий командный канал, по которому ничего не передается, пока вы не включите сеанс поддержки. Сертификат mTLS обновляется самостоятельно.
Запуск без управляемого режима
Передайте--no-managed в clicklink clctl init либо ответьте «нет» на соответствующий вопрос, чтобы установить только scraper и средство диагностики. В этом случае коннектор наблюдает за кластерами ClickHouse, которыми вы управляете самостоятельно, и обеспечивает их поддержку; ClickHouse не может создавать, изменять или удалять сервисы. Коннектор по-прежнему разворачивает сам себя и создаёт пользователей ClickHouse только для чтения и ServiceAccounts; см. модель привилегий. Такая же схема применяется к целевым системам, которые управляемый режим не охватывает. Управляемый режим работает на Amazon EKS с хранилищем S3; обсервабилити и поддержка доступны на любом совместимом Kubernetes-кластере или Linux-хосте.
Требования вкратце
- Целевая среда развертывания. Для управляемого режима требуется кластер Amazon EKS с хранилищем S3. Обсервабилити и поддержка сами по себе работают на любом совместимом кластере Kubernetes (устанавливаются с помощью Helm-чарта) или на любом Linux-хосте с systemd, amd64 или arm64.
- Регистрация со стороны ClickHouse. ClickHouse регистрирует вашу среду для управляемого режима и в ходе онбординга предоставляет конечную точку коннектора и одноразовый токен регистрации.
- Исходящий сетевой доступ по порту 443 к вашей конечной точке коннектора и её конечной точке регистрации, а также к
releases.clicklink.clickhouse.comи ECR Public во время установки. Для каждого шага предусмотрены варианты для изолированных от интернета и зеркалированных окружений; см. онбординг. В управляемом режиме узлы вашего кластера также загружают образы ClickHouse из реестра, с которым зарегистрирована ваша среда. Исполнитель обращается к Amazon ECR и STS, когда загружает чарт платформы из ECR. - Права администратора кластера во время настройки. При включении управляемого режима права доступа исполнителю выдаются однократно: ServiceAccount, привязанная к нему РольКластера и политика допуска, ограничивающая его запись пространствами имен сервисов. Одобрение обновления платформы также выполняется с правами администратора кластера. На обеих целевых средах установки пакеты доступа средства диагностики привязаны к Kubernetes ServiceAccount. См. онбординг.
- Учетные данные AWS для
prepareиteardown, а также доступ к реестру дляplatform approve. Создание бакетов и роли IAM для сервиса выполняется под вашими учетными данными, как и их удаление после удаления сервиса. Обе операции выполняются на вашей рабочей станции или на хосте коннектора. Для прямого доступа к реестру ClickHouse утверждение и синхронизация платформы принимают роль загрузки только для чтения через instance profile виртуальной машины EC2 коннектора. Профили AWS на рабочей станции или учетные данные SSO эту идентичность не заменяют. Другие реестры чартов в ECR используют окружающие учетные данные AWS. См. учетные данные реестра. Исполнитель никогда не располагает учетными данными к вашим бакетам или IAM. Его единственные облачные вызовы направлены в Amazon ECR и STS для загрузки чартов и проверки образов платформы. - Доступный слушатель собственного протокола ClickHouse для кластеров, которыми вы управляете самостоятельно и которые наблюдаются отдельным развертыванием коннектора, работающим без исполнителя. Scraper и средство диагностики взаимодействуют с каждым кластером по собственному протоколу; в Kubernetes они автоматически определяют защищенное (9440) или незашифрованное (9000) подключение.
- Административный доступ к ClickHouse во время настройки для кластеров, которыми вы управляете самостоятельно. При первичной подготовке создаются пользователи коннектора с правами только для чтения. Пароль администратора, если он задан, запрашивается однократно и нигде не сохраняется.
Следующие шаги
- Онбординг: установка и регистрация коннектора в Kubernetes или на Linux VM.
- Управляемые сервисы: включение управляемого режима, создание сервиса, а также его жизненный цикл, статус и удаление.
- Обновления платформы: утверждение изменений компонентов платформы в вашем кластере.
- Архитектура: компоненты, все подключения, жизненный цикл сертификатов и данные, покидающие вашу среду.
- Сеансы поддержки: как включать, ограничивать, проверять и отзывать доступ службы поддержки.
- Конфигурация и операции: настройка, обновления и задачи по сопровождению.
- FAQ: часто задаваемые вопросы, в том числе о том, кто может изменять ваши сервисы, об исходящем трафике данных и отзыве доступа.