ユーザー クラスタの作成

Google Distributed Cloud では、ユーザー クラスタがワークロードを実行します。マルチクラスタ アーキテクチャでは、ユーザー クラスタの作成と管理は管理クラスタによって行われます。

管理クラスタを作成したら、bmctl create config コマンドを呼び出し、ユーザー クラスタを定義する YAML ファイルを作成します。構成を適用してユーザー クラスタを作成するには、bmctl create cluster コマンドを使用します。プリフライト チェックは、bmctl create cluster コマンドを使用して作成されたユーザー クラスタに適用されます。

ワークロードを管理クラスタ以外に配置すると、管理クラスタに保存されている SSH 認証鍵などの重要な管理情報は、その情報を必要としないユーザーから保護されます。さらに、ユーザー クラスタを互いに分離しておくことで、ワークロードの全般的なセキュリティを維持できます。

前提条件

  • 最新の bmctl が Cloud Storage からダウンロードされている（gs://anthos-baremetal-release/bmctl/1.30.300-gke.84/linux-amd64/bmctl）。
  • クラスタ API サーバー（controlPlaneVIP）にアクセスできる作業用の管理クラスタがある。
  • 管理クラスタノードが、ターゲット ユーザー クラスタのすべてのノードに接続できる。
  • bmctl を実行するワークステーションが、ターゲット ユーザー クラスタのすべてのノードに接続できる。
  • 管理ワークステーションから各ユーザー クラスタノードに SSH 接続を確立できる。
  • Connect-register サービス アカウントは、Connect で使用できるように管理クラスタで構成されています。

SELinux を有効にする

コンテナを保護するために SELinux を有効にする場合は、すべてのホストマシンで SELinux を Enforced モードで有効にする必要があります。リリース 1.9.0 以降の Google Distributed Cloud では、クラスタの作成やクラスタのアップグレードの前または後に SELinux を有効または無効にできます。Red Hat Enterprise Linux（RHEL）では、SELinux がデフォルトで有効になっています。ホストマシンで SELinux が無効になっている場合や、不明な場合は、SELinux を使用したコンテナの保護をご覧ください。

Google Distributed Cloud が SELinux をサポートするのは、RHEL システムの場合のみです。

ユーザー クラスタの構成ファイルを作成する

ユーザー クラスタを作成するための構成ファイルは、管理クラスタの作成に使用される構成ファイルとほぼ同じです。唯一の違いは、ローカルの認証情報構成セクションを削除し、構成ファイルを Kubernetes リソースの有効なコレクションにすることです。構成セクションは、ファイルの先頭にある bmctl configuration variables セクションの下にあります。ユーザー クラスタ構成の例については、クラスタ構成サンプルのユーザー クラスタをご覧ください。

デフォルトでは、ユーザー クラスタはその管理クラスタから認証情報を継承します。これらの認証情報の一部またはすべてを無効にできます。

  1. 次の bmctl create config コマンドを使用して、ユーザー クラスタ構成ファイルを作成します。

    bmctl create config -c USER_CLUSTER_NAME

    たとえば、user1 というユーザー クラスタの構成ファイルを作成するには、次のコマンドを実行します。

    bmctl create config -c user1

    ファイルは bmctl-workspace/user1/user1.yaml に書き込まれます。ファイルへの一般的なパスは bmctl-workspace/CLUSTER NAME/CLUSTER_NAME.yaml です。

  2. 構成ファイルに次の変更を行います。

    • ローカルの認証情報ファイルのパスを構成から削除します。

      ...
  gcrKeyPath: (path to GCR service account key)
  sshPrivateKeyPath: (path to SSH private key, used for node access)
  gkeConnectAgentServiceAccountKeyPath: (path to Connect agent service account key)
  gkeConnectRegisterServiceAccountKeyPath: (path to Hub registration service account key)
  cloudOperationsServiceAccountKeyPath: (path to Cloud Operations service account key)
...

    • 構成を変更して、クラスタタイプを admin ではなく user を指定します。

      ...
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create
  #   user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster
  #   components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user
  #   workloads, but does not manage other clusters.
  type: user
...

    • gkeConnect.projectID フィールドにプロジェクト ID を指定して、クラスタをフリートに登録します。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。

      ...
gkeConnect:
   projectID: my-project-123
...
      • 必要に応じて、クラスタ仕様に gkeConnect.location を追加して、Fleet サービスと Connect サービスが実行される Google Cloud リージョンを指定できます。このリージョン メンバーシップにより、フリート サービス トラフィックがお客様のリージョンに制限されます。クラスタ仕様に gkeConnect.location を含める場合、指定するリージョンは clusterOperations.location で構成されたリージョンと同じでなければなりません。リージョンが同じでない場合、クラスタの作成は失敗します。

    • Google Cloud プロジェクトで GKE On-Prem API が有効になっている場合、プロジェクト内のすべてのクラスタが、clusterOperations.location で構成されたリージョンの GKE On-Prem API に登録（自動的に）されます。

      • GKE On-Prem API のプロジェクトにすべてのクラスタを登録する場合は、始める前にの手順に沿って、プロジェクト内の GKE On-Prem API を有効にしてから使用します。

      • GKE On-Prem API にクラスタを登録しない場合は、このセクションを追加して、gkeOnPremAPI.enabled を false に設定します。プロジェクトにクラスタを登録しない場合は、プロジェクトで gkeonprem.googleapis.com（GKE On-Prem API のサービス名）を無効にします。手順については、サービスの無効化をご覧ください。

    • コントロール プレーン ノードの IP アドレスを指定します。

      ...
# Sample control plane config
controlPlane:
 nodePoolSpec:
   nodes:
   - address: 10.200.0.20
...

    • ロードバランサの VIP とアドレスプールに対する管理者クラスタとユーザー クラスタの指定が補完され、既存のクラスタと重複しないことを確認します。次の例は、ロード バランシングとアドレスプールを指定する管理クラスタとユーザー クラスタの構成のサンプルを示しています。

      ...
# Sample admin cluster config for load balancer and address pools
  loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.49
      ingressVIP: 10.200.0.50
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.50-10.200.0.70
...
...
# Sample user cluster config for load balancer and address pools
loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
...

      ユーザー クラスタの構成ファイルの残りの部分は管理クラスタの構成ファイルと同じです。

    • クラスタノードの Pod 密度を指定します。

      ...
# NodeConfig specifies the configuration that applies to all nodes in the cluster.
nodeConfig:
  # podDensity specifies the pod density configuration.
  podDensity:
    # maxPodsPerNode specifies at most how many pods can be run on a single node.
    maxPodsPerNode: 110
...

      ユーザー クラスタの場合、maxPodsPerNode に指定できる値は 32-250 です。指定しない場合、デフォルトの 110 が使用されます。クラスタの作成後、この値を更新することはできません。

      Pod 密度も、クラスタで使用可能な IP リソースによって制限されます。詳しくは、Pod ネットワークをご覧ください。

ユーザー クラスタを作成する

bmctl コマンドを実行して、ユーザー クラスタ構成ファイルを適用し、クラスタを作成します。

bmctl create cluster -c USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

次のように置き換えます。

  • USER_CLUSTER_NAME: 前のセクションで作成したクラスタ名。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

たとえば、ユーザー クラスタの名前が user1 で、管理クラスタの kubeconfig ファイルのパスが kubeconfig bmctl-workspace/admin/admin-kubeconfig の場合、コマンドは次のようになります。

bmctl create cluster -c user1 --kubeconfig bmctl-workspace/admin/admin-kubeconfig

ユーザー クラスタ構成の例

ユーザー クラスタ構成の例については、クラスタ構成サンプルのユーザー クラスタをご覧ください。