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

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

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

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

前提条件

最新の bmctl が Cloud Storage からダウンロードされている（gs://anthos-baremetal-release/bmctl/1.30.100-gke.96/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 セクションの下にあります。ユーザークラスタ構成の例については、クラスタ構成サンプルのユーザークラスタをご覧ください。

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

次の 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 です。
構成ファイルに次の変更を行います。
- ローカルの認証情報ファイルのパスを構成から削除します。
```
...
  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 ネットワークをご覧ください。