このドキュメントでは、Google Distributed Cloud（GDC）のエアギャップ ゾーンに共有 Kubernetes クラスタを作成する方法について説明します。共有クラスタは複数のプロジェクトにまたがり、標準クラスタよりも構成の自由度が低い、独自の Kubernetes クラスタ構成を提供する包括的な GDC 管理サービスが含まれています。標準クラスタの詳細については、Kubernetes クラスタ構成をご覧ください。
共有クラスタはゾーンリソースであり、複数のゾーンにまたがることはできません。マルチゾーン ユニバースでクラスタを運用するには、各ゾーンにクラスタを手動で作成する必要があります。
このドキュメントは、組織内のコンテナ ワークロードの管理を担当するアプリケーション オペレーター グループのアプリケーション デベロッパーなどのユーザーを対象としています。詳細については、GDC エアギャップの対象読者に関するドキュメントをご覧ください。
始める前に
共有クラスタの作成に必要な権限を取得するには、組織の IAM 管理者にユーザー クラスタ管理者ロール（
user-cluster-admin）を付与するよう依頼してください。このロールは名前空間にバインドされていません。API または Terraform を使用して共有クラスタを作成するには、クラスタをホストするゾーン API サーバーの kubeconfig ファイルを生成します。詳しくは、ログインするをご覧ください。環境変数
MANAGEMENT_API_SERVERを kubeconfig パスに設定します。Kubernetes クラスタの次の Google Distributed Cloud（GDC）エアギャップの上限を計画します。
- 組織あたり 16 個のクラスタ
- クラスタあたり 42 個のワーカーノード、最小 3 個のワーカーノード
- クラスタあたり 4,620 個の Pod
- ノードあたり 110 Pod
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）のみです。
専用のロードバランサ ノードを作成する場合は、作成するノードの数を入力します。デフォルトでは、ノードはゼロになり、ロードバランサ トラフィックはコントロール ノードを通過します。
使用するサービス CIDR（クラスレス ドメイン間ルーティング）を選択します。ロードバランサなどのデプロイされたサービスには、この範囲から IP アドレスが割り当てられます。
使用する Pod CIDR を選択します。クラスタは、この範囲から Pod と VM に IP アドレスを割り当てます。
[次へ] をクリックします。
クラスタの自動生成されたデフォルト ノードプールの詳細を確認します。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: サービス仮想 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: サービス仮想 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 分かかることがあります。