GCP 向けカスタマー管理 VPC (BYO-VPC)
ClickHouse Cloud に新しい VPC をプロビジョニングさせる代わりに、既存の VPC を使用して ClickHouse BYOC をデプロイする場合は、以下の手順に従ってください。この方法では、ネットワーク構成をより細かく制御できるほか、ClickHouse BYOC を既存のネットワークインフラストラクチャに統合できます。1
既存の VPC を設定する
- ClickHouse Kubernetes (GKE) クラスター用に、ClickHouse BYOC がサポートするリージョン内にプライベートサブネットを少なくとも 1 つ割り当てます。GKE クラスターのノードに十分な IP アドレスを確保するため、サブネットの CIDR 範囲は最低でも
/24(例: 10.0.0.0/24) であることを確認してください。 - そのプライベートサブネット内で、GKE クラスターのポッドに使用するセカンダリ IPv4 範囲を少なくとも 1 つ割り当てます。セカンダリ範囲は少なくとも
/21である必要があります。これより小さい範囲では、GKE クラスターがプロビジョニングを完了するのに十分なポッド IP アドレスを確保できず、インフラストラクチャのセットアップに失敗します。 - サブネットで Private Google Access を有効にします。これにより、GKE ノードは外部 IP アドレスなしで Google API や各種サービスにアクセスできます。
Private Service Connect 経由でサービスを公開するには、この VPC 内に用途が
PRIVATE_SERVICE_CONNECT の専用サブネットも必要です。これは今すぐ作成することも、プライベートリンクを有効にする前に後から作成することもできます。2
ネットワーク接続を確保する
Cloud NAT ゲートウェイ
VPC に Cloud NAT ゲートウェイがデプロイされていることを確認してください。これは外部 IP アドレスを持たないインスタンスにアウトバウンド接続を提供するもので、次の 2 つがこれに依存しています。
- Tailscale。 ClickHouse BYOC の各コンポーネントは Tailscale コントロールプレーンに登録されます。Tailscale は、インバウンドのパブリックアクセスを必要とせずに、プライベートな管理操作のための安全なゼロトラストネットワークを提供します。
- コンテナイメージ。 デプロイで実行されるイメージの一部は、コミュニティイメージを含め、BYOC レジストリにミラーリングされておらず、上流のレジストリから取得されます。
3
BYOC インフラストラクチャを設定する
Set up Infrastructure をクリックすると、ClickHouse Cloud はプロビジョニング前に自動的にプリフライト検証を実行します。管理 service account に必要な権限があること、および必要な Google Cloud API が有効になっていることを確認するとともに、持ち込んだ VPC についても、ネットワークとサブネットが解決できること、サブネットのプライマリ範囲とポッド用セカンダリ範囲が十分な大きさであること、Cloud NAT ゲートウェイがそのネットワークをカバーしていることを検証します。不足があった場合、セットアップは中断され、修正すべき具体的な問題が示されます。
- VPC configuration で、Use existing VPC を選択します。
- VPC network name を入力します。
- ClickHouse 用に割り当てた Subnet name を入力します。
- 必要に応じて Secondary range names を入力し、GKE がポッド用に使用するサブネットのセカンダリ範囲を指定します。空のままにするとすべてのセカンダリ範囲が使用されます。指定する名前はいずれも、あらかじめそのサブネット上に存在している必要があります。
- VPC が共有 VPC のホストプロジェクトにある場合は、Shared VPC host project ID を入力します。VPC がインフラストラクチャと同じプロジェクトにある場合は空のままにします。以下のホストプロジェクトからの共有 VPC を参照してください。
- Set up Infrastructure をクリックして、プロビジョニングを開始します。
ホストプロジェクトの共有 VPC
BYOC は、別の 共有 VPC ホストプロジェクトに存在するネットワーク上で、サービスプロジェクト内で実行できます。これによりネットワーク構成を一元管理できます。VPC とそのサブネットは ホスト プロジェクトが所有し、BYOC インフラストラクチャは接続された サービス プロジェクトで稼働します。上記の要件に変更はなく、ホストプロジェクト内のサブネットにそのまま適用されます。 この構成に固有の前提条件が 2 つあります。- 開始前に、ホストプロジェクトを共有 VPC ホストとして有効化し、サービスプロジェクトをそこに接続してください。 この 2 つの手順はいずれも必須で、かつ別個のものです。まだ共有 VPC ホストになっていないプロジェクトは、まずホストとして有効化する必要があり、その後にはじめてサービスプロジェクトを接続できます。共有 VPC の GKE クラスターには、この接続が存在していることが必要です。プリフライト検証は接続の有無にかかわらずホストプロジェクトの grants を通じてネットワークとサブネットを読み取るため、どちらの場合も検証は通過してしまい、後続のクラスター作成時にプロビジョニングが失敗します。いずれの操作も組織レベルのものであり、組織内で共有 VPC を管理している担当者が実施します。オンボーディング用 Terraform が代行することはできません。
- ホストプロジェクトを設定したうえでオンボーディング用 Terraform を実行してください。 onboarding module に
shared_vpc_host_project_id、shared_vpc_host_subnet_region、shared_vpc_host_private_subnet_idを渡します。shared_vpc_host_private_subnet_idは GKE ノードが稼働するホストサブネット、つまり上記で設定したサブネットであり、後述の Private Service Connect サブネットではありません。これを PSC サブネットに向けるとroles/compute.networkUserの grant が誤ったサブネットに付与され、クラスター作成時にプロビジョニングが失敗します。1 回の実行で両方のプロジェクトに書き込みが行われるため、実行に使う認証情報にはサービスプロジェクトとホストプロジェクトの両方に対する IAM 管理権限が必要です。
書き込み権限は最後の行のみで、しかも ClickHouse ではなく自プロジェクトの GKE サービスエージェントに付与されます。ClickHouse 管理用 service account がホストプロジェクトに書き込むことはありません。またモジュールは、ホストプロジェクトで
container.googleapis.com API を有効化し、これによりそのプロジェクト自身の GKE サービスエージェントがプロビジョニングされます。
その後、上記で説明した Shared VPC host project ID フィールドにホストプロジェクトを入力します。プライベートリンクが必要な場合は、ノードサブネットと同じネットワークおよびリージョン内に、ホストプロジェクトで別途 PRIVATE_SERVICE_CONNECT サブネットを作成してください。これはノードサブネットを置き換えるものではなく併存するものであり、shared_vpc_host_private_subnet_id として渡すサブネットでもありません。