このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ ゾーンに共有 Kubernetes クラスタを作成する方法について説明します。共有クラスタは複数のプロジェクトにまたがり、包括的な GDC マネージド サービスが含まれています。このサービスは、標準クラスタよりも構成可能性が低い、高度にオピニオン化された Kubernetes クラスタ構成を提供します。標準クラスタの詳細については、Kubernetes クラスタの構成をご覧ください。
共有クラスタはゾーンリソースであり、複数のゾーンにまたがることはできません。マルチゾーン ユニバースでクラスタを運用するには、各ゾーンにクラスタを手動で作成する必要があります。
このドキュメントは、組織内のコンテナ ワークロードの管理を担当するアプリケーション オペレーター グループ内のアプリケーション デベロッパーなどを対象としています。詳細については、GDC エアギャップ ドキュメントの対象読者をご覧ください。
始める前に
共有クラスタの作成に必要な権限を取得するには、IAM 組織管理者にユーザー クラスタ管理者ロール（
user-cluster-admin）を付与するよう依頼します。このロールは Namespace にバインドされていません。API または Terraform を使用して共有クラスタを作成するには、クラスタをホストするゾーン API サーバーの kubeconfig ファイルを生成します。環境変数
MANAGEMENT_API_SERVERを kubeconfig パスに設定します。詳細については、ゾーン管理 API サーバー リソースをご覧ください。リソースに関する考慮事項については、クラスタの上限を確認してください。
Pod CIDR ブロックを計画する
ワークロードに適切なサイズの Pod CIDR ブロックを割り当てるには、Kubernetes クラスタを作成する前に、クラスタに必要な IP アドレスの数を計算する必要があります。クラスタの作成後に、ほとんどのネットワーキング パラメータを変更することはできません。
Kubernetes クラスタは、IP アドレスを割り振る際に次のロジックに従います。
- Kubernetes は、256 個のアドレスで構成される
/24CIDR ブロックを各ノードに割り当てます。この数は、Kubernetes クラスタのノードあたりのデフォルトの最大 Pod 数である 110 に準拠しています。 - ノードに割り当てられる CIDR ブロックのサイズは、ノードあたりの最大 Pod 数によって異なります。
- ブロックには、ノードあたりの最大 Pod 数の少なくとも 2 倍のアドレス範囲があります。
次の例は、110 個の Pod に対応するために、デフォルト値のノードあたりのマスクサイズ= /24 がどのように計算されたかを示しています。
Maximum pods per node = 110
Total number of IP addresses required = 2 * 110 = 220
Per node mask size = /24
Number of IP addresses in a /24 = 2(32 - 24) = 256
必要なノード数に基づいて、Kubernetes クラスタに構成する Pod CIDR マスクを決定します。CIDR の範囲を構成する際は、将来クラスタにノードを追加することを計画します。
Total number of nodes supported = 2(Per node mask size - pod CIDR mask)
デフォルトのノードあたりのマスクサイズ= /24 がある場合は、次の表を参照して、Pod CIDR マスクをサポートされているノード数にマッピングします。
| Pod CIDR マスク | 計算: 2（ノードあたりのマスクサイズ - CIDR マスク） | サポートされるノードの最大数（コントロール プレーン ノードを含む） |
|---|---|---|
| /21 | 2（24 - 21） | 8 |
| /20 | 2(24-20) | 16 |
| /19 | 2(24 - 19) | 32 |
| /18 | 2（24 - 18） | 64 |
Kubernetes クラスタの Pod CIDR ブロックを計算したら、次のセクションのクラスタ作成ワークフローの一部として構成します。
共有クラスタを作成する
共有 Kubernetes クラスタを作成する手順は次のとおりです。
コンソール
プロジェクト選択ツールで、組織を選択します。
共有クラスタは組織を対象にしたリソースです。代わりにプロジェクトを選択すると、プロジェクト スコープの標準クラスタが作成されます。詳細については、リソース階層をご覧ください。
ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。
[クラスタを作成] をクリックします。
[名前] フィールドに、クラスタの名前を指定します。
クラスタの Kubernetes バージョンを選択します。
クラスタを作成するゾーンを選択します。
[プロジェクトを接続] をクリックし、クラスタに接続する既存のプロジェクトを選択します。オンにして [保存] をクリックします。クラスタの作成後に、プロジェクトの詳細ページからプロジェクトを接続または切断できます。コンテナ ワークロードをデプロイする前に、クラスタにプロジェクトを接続する必要があります。
[次へ] をクリックします。
クラスタのネットワーク設定を構成します。クラスタの作成後にこれらのネットワーク設定を変更することはできません。Kubernetes クラスタでサポートされているデフォルトのインターネット プロトコルは、インターネット プロトコル バージョン 4（IPv4）のみです。
専用のロードバランサ ノードを作成する場合は、作成するノードの数を入力します。デフォルトでは、ノードは 0 個になり、ロードバランサのトラフィックはコントロール ノードを通過します。
使用する Service CIDR（クラスレス ドメイン間ルーティング）を選択します。ロードバランサなどのデプロイされたサービスには、この範囲の IP アドレスが割り当てられます。
使用する Pod CIDR を選択します。クラスタは、この範囲の IP アドレスを Pod と VM に割り振ります。
[次へ] をクリックします。
クラスタ用に自動生成されたデフォルトのノードプールの詳細を確認します。edit [編集] をクリックして、デフォルトのノードプールを変更します。
追加のノードプールを作成するには、[ノードプールを追加] を選択します。デフォルトのノードプールを編集する場合、または新しいノードプールを追加する場合は、次のオプションを使用してカスタマイズします。
- ノードプールの名前を割り当てます。ノードプールの作成後に名前を変更することはできません。
- ノードプールに作成するワーカーノードの数を指定します。
ワークロードの要件に最も適したマシンクラスを選択します。次の設定のリストを表示します。
- マシンタイプ
- CPU
- メモリ
[保存] をクリックします。
[作成] をクリックしてクラスタを作成します。
共有クラスタの作成が完了するまでに最大 90 分ほどかかる場合があります。
API
Clusterカスタム リソースを作成します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: cluster.gdc.goog/v1 kind: Cluster metadata: name: CLUSTER_NAME namespace: platform spec: clusterNetwork: podCIDRSize: POD_CIDR serviceCIDRSize: SERVICE_CIDR initialVersion: kubernetesVersion: KUBERNETES_VERSION nodePools: - machineTypeName: MACHINE_TYPE name: NODE_POOL_NAME nodeCount: NUMBER_OF_WORKER_NODES taints: TAINTS labels: LABELS acceleratorOptions: gpuPartitionScheme: GPU_PARTITION_SCHEME releaseChannel: channel: UNSPECIFIED EOF次のように置き換えます。
MANAGEMENT_API_SERVER: ゾーン API サーバーの kubeconfig パス。CLUSTER_NAME: クラスタの名前。クラスタ名の末尾を-systemにすることはできません。-system接尾辞は、GDC によって作成されたクラスタ用に予約されています。POD_CIDR: Pod 仮想 IP アドレスが割り振られるネットワーク範囲のサイズ。設定しない場合、デフォルト値の21が使用されます。SERVICE_CIDR: Service の仮想 IP アドレスが割り振られるネットワーク範囲のサイズ。設定しない場合、デフォルト値の23が使用されます。KUBERNETES_VERSION: クラスタの Kubernetes バージョン（1.26.5-gke.2100など）。構成可能な Kubernetes バージョンを一覧表示するには、クラスタで使用可能な Kubernetes バージョンを一覧表示するをご覧ください。MACHINE_TYPE: ノードプールのワーカーノードのマシンタイプ。構成可能なマシンタイプについては、使用可能なマシンタイプをご覧ください。NODE_POOL_NAME: ノードプールの名前。NUMBER_OF_WORKER_NODES: ノードプールにプロビジョニングするワーカーノードの数。TAINTS: このノードプールのノードに適用する taint。このフィールドは省略できます。LABELS: このノードプールのノードに適用するラベル。Key-Value ペアのリストが含まれます。このフィールドは省略できます。GPU_PARTITION_SCHEME: GPU ワークロードを実行している場合の GPU パーティショニング スキーム。このフィールドは省略できます。例:mixed-2このフィールドが設定されていない場合、GPU はパーティショニングされません。使用可能なマルチインスタンス GPU（MIG）プロファイルの詳細については、サポートされている MIG プロファイルをご覧ください。
共有クラスタの作成が完了するまでに最大 90 分ほどかかる場合があります。
ProjectBindingカスタム リソースを作成します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: resourcemanager.gdc.goog/v1 kind: ProjectBinding metadata: name: CLUSTER_NAME-PROJECT_NAME namespace: platform labels: resourcemanager.gdc.goog/projectbinding-for-user-project: "true" spec: clusterRef: name: CLUSTER_NAME selector: nameSelector: matchNames: - PROJECT_NAME EOF次のように置き換えます。
MANAGEMENT_API_SERVER: ゾーン API サーバーの kubeconfig パス。CLUSTER_NAME: クラスタの名前。PROJECT_NAME: バインドするプロジェクトの名前。各ProjectBindingリソースは 1 つのクラスタにのみマッピングできます。プロジェクトで複数のクラスタへのアクセスが必要な場合は、クラスタごとに一意のProjectBindingを作成する必要があります。
デベロッパーがコンテナ ワークロードをクラスタにデプロイする前に、プロジェクトをクラスタに接続する必要があります。
Terraform
Terraform 構成ファイルに次のコード スニペットを挿入して、
Clusterカスタム リソースを作成します。provider "kubernetes" { config_path = "MANAGEMENT_API_SERVER" } resource "kubernetes_manifest" "CLUSTER_RESOURCE_NAME" { manifest = { "apiVersion" = "cluster.gdc.goog/v1" "kind" = "Cluster" "metadata" = { "name" = "CLUSTER_NAME" "namespace" = "platform" } "spec" = { "clusterNetwork" = { "podCIDRSize" = "POD_CIDR" "serviceCIDRSize" = "SERVICE_CIDR" } "initialVersion" = { "kubernetesVersion" = "KUBERNETES_VERSION" } "nodePools" = [{ "machineTypeName" = "MACHINE_TYPE" "name" = "NODE_POOL_NAME" "nodeCount" = "NUMBER_OF_WORKER_NODES" "taints" = "TAINTS" "labels" = "LABELS" "acceleratorOptions" = { "gpuPartitionScheme" = "GPU_PARTITION_SCHEME" } }] "releaseChannel" = { "channel" = "UNSPECIFIED" } } } }次のように置き換えます。
MANAGEMENT_API_SERVER: ゾーン API サーバーの kubeconfig パス。CLUSTER_RESOURCE_NAME: クラスタの一意の Terraform リソース名（cluster-1など）。この名前は Terraform がクラスタを識別するために使用するもので、GDC では使用されません。CLUSTER_NAME: クラスタの名前。クラスタ名の末尾を-systemにすることはできません。-system接尾辞は、GDC によって作成されたクラスタ用に予約されています。POD_CIDR: Pod 仮想 IP アドレスが割り振られるネットワーク範囲のサイズ。設定しない場合、デフォルト値の21が使用されます。SERVICE_CIDR: Service の仮想 IP アドレスが割り振られるネットワーク範囲のサイズ。設定しない場合、デフォルト値の23が使用されます。KUBERNETES_VERSION: クラスタの Kubernetes バージョン（1.26.5-gke.2100など）。構成可能な Kubernetes バージョンを一覧表示するには、クラスタで使用可能な Kubernetes バージョンを一覧表示するをご覧ください。MACHINE_TYPE: ノードプールのワーカーノードのマシンタイプ。構成可能なマシンタイプについては、使用可能なマシンタイプをご覧ください。NODE_POOL_NAME: ノードプールの名前。NUMBER_OF_WORKER_NODES: ノードプールにプロビジョニングするワーカーノードの数。TAINTS: このノードプールのノードに適用する taint。このフィールドは省略できます。LABELS: このノードプールのノードに適用するラベル。Key-Value ペアのリストが含まれます。このフィールドは省略できます。GPU_PARTITION_SCHEME: GPU ワークロードを実行している場合の GPU パーティショニング スキーム。このフィールドは省略できます。例:mixed-2このフィールドが設定されていない場合、GPU はパーティショニングされません。使用可能なマルチインスタンス GPU（MIG）プロファイルの詳細については、サポートされている MIG プロファイルをご覧ください。
Terraform 構成ファイルに次のコード スニペットを挿入して、
ProjectBindingカスタム リソースを作成します。provider "kubernetes" { config_path = "MANAGEMENT_API_SERVER" } resource "kubernetes_manifest" "PROJECT_BINDING_RESOURCE_NAME" { manifest = { "apiVersion" = "resourcemanager.gdc.goog/v1" "kind" = "ProjectBinding" "metadata" = { "name" = "CLUSTER_NAME-PROJECT_NAME" "namespace" = "platform" "labels" = { "resourcemanager.gdc.goog/projectbinding-for-user-project" = "true" } } "spec" = { "clusterRef" = { "name" = "CLUSTER_NAME" } "selector" = { "nameSelector" = { "matchNames" = [ "PROJECT_NAME", ] } } } } }次のように置き換えます。
MANAGEMENT_API_SERVER: ゾーン API サーバーの kubeconfig パス。PROJECT_BINDING_RESOURCE_NAME: プロジェクト バインディングの Terraform リソース名（project-binding-1など）。この名前は、Terraform がプロジェクト バインディングを識別するために使用するもので、GDC では使用されません。CLUSTER_NAME: クラスタの名前。PROJECT_NAME: バインドするプロジェクトの名前。各ProjectBindingリソースは 1 つのクラスタにのみマッピングできます。プロジェクトで複数のクラスタへのアクセスが必要な場合は、クラスタごとに一意のProjectBindingを作成する必要があります。
デベロッパーがコンテナ ワークロードをクラスタにデプロイする前に、プロジェクトをクラスタに接続する必要があります。
Terraform を使用して新しいカスタム リソースを適用します。
terraform apply
共有クラスタの作成が完了するまでに最大 90 分ほどかかる場合があります。