マルチクラスタ設定でのユーザークラスタの作成

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

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

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

前提条件

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

SELinux を有効にする

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

ベアメタル版 Anthos クラスタは、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
....

ロードバランサの 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
  # containerRuntime specifies which container runtime to use for scheduling containers on nodes.
  # containerd and docker are supported.
  containerRuntime: containerd
....
```
ユーザークラスタの場合、maxPodsPerNode に指定できる値は 32-250 です。指定しない場合、デフォルトの 110 が使用されます。クラスタの作成後、この値を更新することはできません。

デフォルトのコンテナランタイムは containerd です。Docker を使用することもできます。ランタイムの変更について詳しくは、コンテナランタイムの変更ガイドをご覧ください。

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 を有効にする

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

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

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

マルチクラスタ設定でのユーザークラスタの作成

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

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

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