Google Distributed Cloud で、他のクラスタを安全に管理するための管理クラスタを設定します。管理クラスタでは、ユーザー クラスタの作成、更新、アップグレード、削除を行えます。ユーザー クラスタでは、管理とは別にワークロードが実行されるため、機密情報は保護されます。
マルチクラスタ ワークロードを管理する管理クラスタでは、高可用性（HA）の信頼性が得られます。HA クラスタでは、1 つのコントロール プレーンノードに障害が発生しても、他のノードは引き続き動作します。
マルチクラスタ環境の管理クラスタは、最高の基本的なセキュリティを提供します。管理データへのアクセスはワークロードから分離されるため、ユーザー ワークロードにアクセスするユーザーは、SSH 認証鍵やサービス アカウント データなどの機密性の高い管理データにはアクセスできません。その結果、セキュリティと必要なリソースの間でトレードオフが発生します。管理クラスタを分けるということは、つまり管理とワークロードに専用のリソースが必要になるということです。
管理クラスタは、bmctl コマンドを使用して作成します。ワークロードを実行するユーザー クラスタは、管理クラスタを作成した後に作成します。
前提条件:
- 最新の
bmctlが Cloud Storage からダウンロードされている（gs://anthos-baremetal-release/bmctl/1.30.300-gke.84/linux-amd64/bmctl）。 bmctlを実行するワークステーションが、ターゲット ユーザー クラスタのすべてのノードに接続できる。bmctlを実行するワークステーションが、クラスタ API サーバー（コントロール プレーン VIP）とネットワーク接続されている。- 管理クラスタの作成に使用される SSH 認証鍵は、ターゲット管理クラスタのすべてのノードで、
root、またはパスワードなしのsudo権限を持つ root 以外のユーザーが使用できます。 - Connect-register サービス アカウントは、Connect で使用できるように構成されています。
ハイブリッド クラスタを作成する詳細な設定ガイドについては、Google Distributed Cloud quickstartをご覧ください。管理クラスタの作成は、管理クラスタでワークロードを実行しないことを除けば、ハイブリッド クラスタの作成と類似しています。
SELinux を有効にする
コンテナを保護するために SELinux を有効にする場合は、すべてのホストマシンで SELinux を Enforced モードで有効にする必要があります。リリース 1.9.0 以降の Google Distributed Cloud では、クラスタの作成やクラスタのアップグレードの前または後に SELinux を有効または無効にできます。Red Hat Enterprise Linux（RHEL）では、SELinux がデフォルトで有効になっています。ホストマシンで SELinux が無効になっている場合や、不明な場合は、SELinux を使用したコンテナの保護をご覧ください。
Google Distributed Cloud が SELinux をサポートするのは、RHEL システムの場合のみです。
gcloud CLI にログインし、管理クラスタの構成ファイルを作成する
次のコマンドを使用して、Google Distributed Cloud でクラスタの作成に使用できるデフォルトの認証情報を設定します。
gcloud auth application-default loginこのページで自動 API 有効化とサービス アカウント作成機能を使用するには、そのプリンシパルにプロジェクト オーナー ロールを付与します。プリンシパルにプロジェクト オーナー ロールがない場合は、次の手順を行います。
プロジェクト オーナー ロールを付与せずにクラスタを作成できるようにするには、プリンシパルに次の IAM ロールを追加します。
- サービス アカウント管理者
- サービス アカウント キー管理者
- プロジェクト IAM 管理者
- Compute 閲覧者
- Service Usage 管理者
プリンシパルがこれらのロールを持つサービス アカウントの場合は、次のコマンドを実行できます。
export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILEJSON_KEY_FILEは、サービス アカウントの JSON キーファイルへのパスに置き換えます。Google Cloud プロジェクトの ID を取得し、それをクラスタの作成に使用する環境変数に保存します。
export CLOUD_PROJECT_ID=$(gcloud config get-value project)
bmctl を使用して管理クラスタ構成ファイルを作成する
gcloud CLI にログインしてプロジェクトを設定すると、bmctl コマンドを使用してクラスタ構成ファイルを作成できるようになります。
次の例では、すべてのサービス アカウントが bmctl create config コマンドで自動的に作成されます。
bmctl create config -c ADMIN_CLUSTER_NAME --enable-apis \
--create-service-accounts --project-id=CLOUD_PROJECT_ID
以下を置き換えます。
- ADMIN_CLUSTER_NAME: 新しいクラスタの名前。
- CLOUD_PROJECT_ID: Google Cloud プロジェクト ID または
$CLOUD_PROJECT_ID環境変数。
次の例では、プロジェクト ID my-gcp-project に関連付けられた admin1 という名前の管理クラスタの構成ファイルを作成します。
bmctl create config -c admin1 --create-service-accounts --enable-apis --project-id=my-gcp-project
ファイルは bmctl-workspace/admin1/admin1.yaml に書き込まれます。
API を自動的に有効にしてサービス アカウントを作成する代わりに、既存のサービス アカウントに対して適切な IAM 権限を付与することもできます。つまり、サービス アカウントを自動で作成した bmctl コマンドによる前の手順はスキップできます。
bmctl create config -c admin1 --project-id=my-gcp-project
クラスタ構成ファイルを編集する
クラスタ構成ファイルが完成したら、次のように修正します。
管理クラスタノードにアクセスするための SSH 秘密鍵を指定します。
# bmctl configuration variables. Because this section is valid YAML but not a valid Kubernetes # resource, this section can only be included when using bmctl to # create the initial admin/admin cluster. Afterwards, when creating user clusters by directly # applying the cluster and node pool resources to the existing cluster, you must remove this # section. gcrKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json sshPrivateKeyPath: /path/to/your/ssh_private_key gkeConnectAgentServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json gkeConnectRegisterServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.jsonフリートにクラスタを登録します。
bmctl create configコマンドで指定したプロジェクト ID が、クラスタ構成ファイルのgkeConnect.projectIDフィールドに自動的に追加されます。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。構成ファイルを作成し、自動 API 有効化とサービス アカウント作成機能を使用している場合は、この手順を省略できます。
API の自動有効化機能とサービス アカウント作成機能を使用せずに構成ファイルを作成した場合は、ダウンロードしたサービス アカウント JSON キーを、クラスタ構成ファイルの対応する
gkeConnectAgentServiceAccountKeyPathおよびgkeConnectRegisterServiceAccountKeyPathフィールドで参照します。必要に応じて、クラスタ仕様に
gkeConnect.locationを追加して、Fleet サービスと Connect サービスが実行される Google Cloud リージョンを指定できます。このリージョン メンバーシップにより、フリート サービス トラフィックがお客様のリージョンに制限されます。クラスタ仕様にgkeConnect.locationを含める場合、指定するリージョンはclusterOperations.locationで構成されたリージョンと同じでなければなりません。リージョンが同じでない場合、クラスタの作成は失敗します。
構成ファイルに
adminのクラスタタイプ（デフォルト値）が指定されていることを確認します。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: adminGoogle Cloud プロジェクトで GKE On-Prem API が有効になっている場合、プロジェクト内のすべてのクラスタが、
clusterOperations.locationで構成されたリージョンの GKE On-Prem API に登録（自動的に）されます。マルチノード、高可用性、コントロール プレーンを指定するように構成ファイルを変更します。HA 用に過半数のクォーラムが確保するように、ノード数を奇数で指定します。
# Control plane configuration controlPlane: nodePoolSpec: nodes: # Control plane node pools. Typically, this is either a single machine # or 3 machines if using a high availability deployment. - address: 10.200.0.4 - address: 10.200.0.5 - address: 10.200.0.6クラスタノードの 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: 250 ....管理クラスタの場合、
maxPodsPerNodeの値は、HA クラスタ用には32-250、HA 以外のクラスタ用には64-250です。指定しない場合、デフォルトの110が使用されます。クラスタの作成後、この値を更新することはできません。Pod 密度も、クラスタで使用可能な IP リソースによって制限されます。詳しくは、Pod ネットワークをご覧ください。
クラスタ構成ファイルで管理クラスタを作成する
bmctl コマンドを使用して、クラスタをデプロイします。
bmctl create cluster -c ADMIN_CLUSTER_NAME
ADMIN_CLUSTER_NAME は、前のセクションで作成したクラスタ名を指定します。
admin1 という名前のクラスタを作成するコマンドの例を次に示します。
bmctl create cluster -c admin1
管理クラスタの構成例
管理クラスタの構成例については、クラスタの構成例の管理クラスタをご覧ください。