ユーザークラスタの作成

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

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

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

前提条件

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

SELinux を有効にする

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

GKE on Bare Metal は、RHEL システムと CentOS システムの SELinux のみをサポートしています。

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

ユーザークラスタを作成するための構成ファイルは、管理クラスタの作成に使用される構成ファイルとほぼ同じです。唯一の違いは、ローカルの認証情報構成セクションから削除し、構成ファイルを 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
...
```
- 1.16 以降では、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

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

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

ユーザー クラスタの作成

前提条件

SELinux を有効にする

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

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

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

ユーザークラスタの作成

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

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

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