Индивидуальная настройка GCP

Развертывание ClickHouse BYOC в вашей существующей VPC в GCP

​

VPC под управлением клиента (BYO-VPC) для GCP

Если вы предпочитаете использовать существующую VPC для развертывания ClickHouse BYOC вместо того, чтобы ClickHouse Cloud создавал новую VPC, выполните приведенные ниже шаги. Такой подход дает больше контроля над конфигурацией сети и позволяет интегрировать ClickHouse BYOC в существующую сетевую инфраструктуру.

1. Настройте существующую VPC

   1. Выделите как минимум 1 приватную подсеть в регионе, поддерживаемом ClickHouse BYOC для кластера ClickHouse Kubernetes (GKE). Убедитесь, что подсеть имеет диапазон CIDR не менее /24 (например, 10.0.0.0/24), чтобы обеспечить достаточное количество IP-адресов для узлов кластера GKE.
   2. В пределах приватной подсети выделите как минимум 1 вторичный диапазон IPv4, который будет использоваться для подов кластера GKE. Вторичный диапазон должен быть не менее /21. Диапазоны меньшего размера не предоставляют достаточно IP-адресов для подов, чтобы кластер GKE мог завершить подготовку, и настройка инфраструктуры завершится ошибкой.
   3. Включите Private Google Access для подсети. Это позволит узлам GKE обращаться к API и сервисам Google без внешних IP-адресов.

   Чтобы предоставлять сервисы через Private Service Connect, в этой VPC также требуется отдельная подсеть с назначением PRIVATE_SERVICE_CONNECT. Вы можете создать ее сейчас или позже, до включения private link.

2. Обеспечьте сетевую связность

   Cloud NAT Gateway Убедитесь, что для VPC развернут Cloud NAT gateway. Он обеспечивает исходящую связность для инстансов без внешних IP-адресов, и от него зависят две вещи:

   • Tailscale. Компоненты ClickHouse BYOC регистрируются в control plane Tailscale, который обеспечивает безопасную сеть с нулевым доверием для закрытых операций управления без необходимости входящего публичного доступа.
   • Образы контейнеров. Некоторые образы, используемые в развертывании, не зеркалируются в реестр BYOC, включая community-образы, и загружаются из исходных реестров.

   VPC без исходящего маршрута не сможет завершить подготовку; предварительная проверка контролирует, что сеть покрыта Cloud NAT gateway. Единого опубликованного списка конечных точек не существует; если ваша сетевая политика требует явного перечня, обратитесь в поддержку для анализа вашей конфигурации.

   DNS Resolution Убедитесь, что в вашей VPC корректно работает DNS-разрешение и что стандартные DNS-имена не блокируются, не изменяются и не подменяются. ClickHouse BYOC использует DNS для разрешения серверов control plane Tailscale и конечных точек сервиса ClickHouse. Если DNS недоступен или настроен неправильно, сервисы BYOC могут не подключаться или работать некорректно.

3. Настройте BYOC infrastructure

   При нажатии Set up Infrastructure ClickHouse Cloud автоматически выполняет предварительную проверку перед подготовкой инфраструктуры. Проверяется, что управляющий service account имеет необходимые разрешения и что включены требуемые API Google Cloud, а также проверяется предоставленная вами VPC: что сеть и подсеть разрешаются, что основной диапазон подсети и вторичный диапазон для подов достаточно велики и что сеть покрыта Cloud NAT gateway. Если чего-то не хватает, настройка прерывается с указанием конкретных проблем, которые нужно устранить.

   В консоли ClickHouse Cloud при настройке новой инфраструктуры укажите следующее:

   1. В разделе VPC configuration выберите Use existing VPC.
   2. Введите VPC network name.
   3. Введите Subnet name подсети, которую вы выделили для ClickHouse.
   4. При необходимости укажите Secondary range names, чтобы задать, какие из вторичных диапазонов подсети GKE будет использовать для подов. Оставьте поле пустым, чтобы использовать все диапазоны; каждое указанное имя уже должно существовать в подсети.
   5. Если ваша VPC находится в host-проекте Shared VPC, укажите Shared VPC host project ID. Оставьте поле пустым, если VPC находится в том же проекте, что и инфраструктура. См. раздел Shared VPC из host-проекта ниже.
   6. Нажмите Set up Infrastructure, чтобы начать подготовку.

​

Общий VPC из host-проекта

Вы можете запускать BYOC в service-проекте в сети, которая расположена в отдельном host-проекте Shared VPC — это позволяет централизованно управлять сетевой частью. VPC и его подсети принадлежат host-проекту, а BYOC infrastructure работает в присоединённом service-проекте. Требования, указанные выше, не меняются — они просто применяются к подсети в host-проекте.

Для такой конфигурации есть два специфичных prerequisite:

• До начала работы включите host-проект как хост Shared VPC и присоедините к нему service-проект. Оба шага обязательны и выполняются отдельно: проект, который ещё не является хостом Shared VPC, сначала нужно включить в этом качестве, и только затем можно присоединить service-проект. Кластер GKE в Shared VPC требует наличия такого присоединения. Предварительная проверка читает вашу сеть и подсеть через привилегии в host-проекте независимо от того, выполнено ли присоединение, поэтому она проходит успешно в любом случае, а подготовка затем падает уже на этапе создания кластера GKE. Обе операции выполняются на уровне organization тем, кто администрирует Shared VPC в вашей organization; Terraform для онбординга не сможет сделать это за вас.
• Запустите Terraform для онбординга с указанным host-проектом. Передайте shared_vpc_host_project_id, shared_vpc_host_subnet_region и shared_vpc_host_private_subnet_id в onboarding module. shared_vpc_host_private_subnet_id — это подсеть host-проекта, в которой работают ваши node GKE (та, которую вы настроили выше), а не подсеть Private Service Connect, описанная ниже. Если указать здесь подсеть PSC, grant roles/compute.networkUser будет назначен не на ту подсеть, и подготовка затем упадёт при создании кластера GKE. Один запуск вносит изменения сразу в оба проекта, поэтому credentials, под которыми он выполняется, должны иметь права IAM admin и в service-проекте, и в host-проекте.

Привилегии, которые module добавляет в ваш host-проект, узкие, но не все из них только для чтения:

Grant в host-проекте	Кому выдан	Зачем
compute.networks.get, compute.subnetworks.get, compute.subnetworks.use	Управляющий service account ClickHouse	Чтение вашей сети и подсети, а также возможность для присоединения Private Service Connect использовать вашу подсеть PSC
roles/compute.networkUser на подсети node	Управляющий service account ClickHouse, GKE service agent вашего service-проекта и service account Google APIs вашего service-проекта	Три identity, которые используют подсеть
roles/container.hostServiceAgentUser	GKE service agent вашего service-проекта	Требуется для любого кластера GKE в Shared VPC
compute.firewalls.create, compute.firewalls.delete, compute.firewalls.get, compute.firewalls.list, compute.firewalls.update и compute.networks.updatePolicy	GKE service agent вашего service-проекта	В режиме Shared VPC GKE создаёт правила firewall для своего cluster и load balancer в host-проекте, а не в service-проекте. Без этого правило проверки health для внутреннего load balancer не будет создано, backend-соединения входного шлюза останутся нездоровыми, а private link не заработает. Это задокументированная Google гранулярная альтернатива выдаче roles/compute.securityAdmin.

Последняя строка — единственный доступ на запись, и он выдаётся GKE service agent вашего собственного проекта, а не ClickHouse. Управляющий service account ClickHouse никогда не пишет в host-проект. Module также включает API container.googleapis.com в host-проекте, благодаря чему создаётся собственный GKE service agent этого проекта.

Затем укажите host-проект в поле Shared VPC host project ID, описанном выше. Если вам нужен private link, создайте в host-проекте отдельную подсеть PRIVATE_SERVICE_CONNECT — в той же сети и region, что и подсеть node. Она существует наряду с подсетью node, а не заменяет её, и это не та подсеть, которую вы передаёте в shared_vpc_host_private_subnet_id.