コンテナ ワークロードを実行する共有クラスタを作成する

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ ゾーンに共有 Kubernetes クラスタを作成する方法について説明します。共有クラスタは複数のプロジェクトにまたがり、包括的な GDC マネージド サービスが含まれています。このサービスは、標準クラスタよりも構成が少ない、高度に意見の強い Kubernetes クラスタ構成を提供します。標準 クラスタの詳細については、 Kubernetes クラスタ構成をご覧ください。

共有クラスタは ゾーンリソース であり、複数のゾーンにまたがることはできません。マルチゾーン ユニバースでクラスタを運用するには、各ゾーンにクラスタを手動で作成する必要があります。

このドキュメントは、組織内のコンテナ ワークロードの管理を担当するアプリケーション オペレーター グループ内のアプリケーション デベロッパーなどのユーザーを対象としています。詳細については、 GDC エアギャップ ドキュメントの対象読者をご覧ください。

始める前に

  • 共有クラスタの作成に必要な権限を取得するには、組織の IAM 管理者にユーザー クラスタ管理者ロール（user-cluster-admin）を付与するよう依頼してください。このロールは名前空間にバインドされていません。

  • API または Terraform を使用して共有クラスタを作成するには、クラスタをホストするゾーン API サーバーの kubeconfig ファイルを生成します。環境変数 MANAGEMENT_API_SERVER を kubeconfig パスに設定します。詳細については、 ゾーン管理 API サーバーのリソースをご覧ください。

  • リソースに関する考慮事項については、クラスタの上限 を確認してください。

Pod CIDR ブロックを計画する

ワークロードに適切なサイズの Pod CIDR ブロックを割り当てるには、Kubernetes クラスタを作成する前に、必要な IP アドレスの量を計算する必要があります。クラスタの作成後に、ほとんどのネットワーク パラメータを変更することはできません。

Kubernetes クラスタは、IP アドレスを割り当てる際に次のロジックに従います。

  • Kubernetes は、各ノードに 256 個のアドレスで構成される /24 CIDR ブロックを割り当てます。この量は、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 クラスタを作成する手順は次のとおりです。

コンソール

  1. ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。

  2. [クラスタを作成] をクリックします。

  3. [名前] フィールドに、クラスタの名前を指定します。

  4. クラスタの Kubernetes バージョンを選択します。

  5. クラスタを作成するゾーンを選択します。

  6. [プロジェクトを接続] をクリックし、クラスタに接続する既存のプロジェクトを選択します。オンにして [保存] をクリックします。クラスタの作成後に、プロジェクトの詳細ページからプロジェクトをアタッチまたは切断できます。コンテナ ワークロードをデプロイする前に、プロジェクトをクラスタに接続する必要があります。

    コンソールを使用してクラスタを作成します。

  7. [次へ] をクリックします。

  8. クラスタのネットワーク設定を構成します。クラスタの作成後にこれらの掲載ネットワークの設定を変更することはできません。Kubernetes クラスタのデフォルトのインターネット プロトコルとサポートされているインターネット プロトコルは、インターネット プロトコル バージョン 4（IPv4）のみです。

    1. 専用のロードバランサ ノードを作成する場合は、作成するノードの数 を入力します。デフォルトでは、ノードは 0 個になり、ロードバランサのトラフィックはコントロール ノードを通過します。

    2. 使用するサービス CIDR （クラスレス ドメイン間ルーティング）を選択します。デプロイされたサービス（ロードバランサなど）には、この範囲の IP アドレスが割り当てられます。

    3. 使用するPod CIDR を選択します。クラスタは、この範囲の IP アドレスを Pod と VM に割り当てます。

    4. [次へ] をクリックします。

  9. クラスタの自動生成されたデフォルトのノードプールの詳細を確認します。 [Edit] をクリックして、 デフォルトのノードプールを変更します。

  10. ノードプールを追加するには、[ノードプールを追加] を選択します。デフォルトのノードプールを編集する場合や、新しいノードプールを追加する場合は、次のオプションを使用してカスタマイズします。

    1. ノードプールの名前を割り当てます。ノードプールの作成後に名前を変更することはできません。
    2. ノードプールに作成するワーカーノードの数を指定します。

    3. ワークロードの要件に最も適したマシンクラスを選択します。 次の設定のリストを表示します。

      • マシンタイプ
      • CPU
      • メモリ

    4. [保存] をクリックします。

  11. [作成] をクリックしてクラスタを作成します。

共有クラスタの作成が完了するまでに最大 90 分かかることがあります。

API

  1. 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 分かかることがあります。

  2. 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

  1. 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 プロファイルをご覧ください。

  2. 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 を作成する必要があります。

    デベロッパーがコンテナ ワークロードをクラスタにデプロイするには、事前にプロジェクトをクラスタに接続する必要があります。

  3. Terraform を使用して新しいカスタム リソースを適用します。

    terraform apply

共有クラスタの作成が完了するまでに最大 90 分かかることがあります。

次のステップ