Google Distributed Cloud では、ユーザー クラスタがワークロードを実行します。マルチクラスタ アーキテクチャでは、ユーザー クラスタの作成と管理は管理クラスタによって行われます。
管理クラスタを作成したら、bmctl create config
コマンドを呼び出し、ユーザー クラスタを定義する YAML ファイルを作成します。構成を適用してユーザー クラスタを作成するには、bmctl create cluster
コマンドを使用します。プリフライト チェックは、bmctl create cluster
コマンドを使用して作成されたユーザー クラスタに適用されます。
ワークロードを管理クラスタ以外に配置すると、管理クラスタに保存されている SSH 認証鍵などの重要な管理情報は、その情報を必要としないユーザーから保護されます。さらに、ユーザー クラスタを互いに分離しておくことで、ワークロードの全般的なセキュリティを維持できます。
前提条件
- 最新の
bmctl
が Cloud Storage からダウンロードされている(gs://anthos-baremetal-release/bmctl/1.30.0-gke.1930/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 に登録(自動的に)されます。コントロール プレーン ノードの 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
ユーザー クラスタ構成の例
ユーザー クラスタ構成の例については、クラスタ構成サンプルのユーザー クラスタをご覧ください。