管理クラスタを作成する

Google Distributed Cloud で、他のクラスタを安全に管理するための管理クラスタを設定します。管理クラスタでは、ユーザー クラスタの作成、更新、アップグレード、削除を行えます。ユーザー クラスタでは、管理とは別にワークロードが実行されるため、機密情報は保護されます。

マルチクラスタ ワークロードを管理する管理クラスタでは、高可用性(HA)の信頼性が得られます。HA クラスタでは、1 つのコントロール プレーンノードに障害が発生しても、他のノードは引き続き動作します。

マルチクラスタ環境の管理クラスタは、最高の基本的なセキュリティを提供します。管理データへのアクセスはワークロードから分離されるため、ユーザー ワークロードにアクセスするユーザーは、SSH 認証鍵やサービス アカウント データなどの機密性の高い管理データにはアクセスできません。その結果、セキュリティと必要なリソースの間でトレードオフが発生します。管理クラスタを分けるということは、つまり管理とワークロードに専用のリソースが必要になるということです。

管理クラスタは、bmctl コマンドを使用して作成します。ワークロードを実行するユーザー クラスタは、管理クラスタを作成した後に作成します。

前提条件:

  • 最新の bmctl が Cloud Storage からダウンロードされている(gs://anthos-baremetal-release/bmctl/1.30.100-gke.96/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 にログインし、管理クラスタの構成ファイルを作成する

  1. 次のコマンドを使用して、Google Distributed Cloud でクラスタの作成に使用できるデフォルトの認証情報を設定します。

    gcloud auth application-default login
    
  2. このページで自動 API 有効化とサービス アカウント作成機能を使用するには、そのプリンシパルにプロジェクト オーナー ロールを付与します。プリンシパルにプロジェクト オーナー ロールがない場合は、次の手順を行います。

  3. プロジェクト オーナー ロールを付与せずにクラスタを作成できるようにするには、プリンシパルに次の IAM ロールを追加します。

    • サービス アカウント管理者
    • サービス アカウント キー管理者
    • プロジェクト IAM 管理者
    • Compute 閲覧者
    • Service Usage 管理者

    プリンシパルがこれらのロールを持つサービス アカウントの場合は、次のコマンドを実行できます。

    export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
    

    JSON_KEY_FILE は、サービス アカウントの JSON キーファイルへのパスに置き換えます。

  4. 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

クラスタ構成ファイルを編集する

クラスタ構成ファイルが完成したら、次のように修正します。

  1. 管理クラスタノードにアクセスするための 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
    
  2. フリートにクラスタを登録します。bmctl create config コマンドで指定したプロジェクト ID が、クラスタ構成ファイルの gkeConnect.projectID フィールドに自動的に追加されます。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。

    • 構成ファイルを作成し、自動 API 有効化とサービス アカウント作成機能を使用している場合は、この手順を省略できます。

    • API の自動有効化機能とサービス アカウント作成機能を使用せずに構成ファイルを作成した場合は、ダウンロードしたサービス アカウント JSON キーを、クラスタ構成ファイルの対応する gkeConnectAgentServiceAccountKeyPath および gkeConnectRegisterServiceAccountKeyPath フィールドで参照します。

    • 必要に応じて、クラスタ仕様に gkeConnect.location を追加して、Fleet サービスと Connect サービスが実行される Google Cloud リージョンを指定できます。このリージョン メンバーシップにより、フリート サービス トラフィックがお客様のリージョンに制限されます。クラスタ仕様に gkeConnect.location を含める場合、指定するリージョンは clusterOperations.location で構成されたリージョンと同じでなければなりません。リージョンが同じでない場合、クラスタの作成は失敗します。

  3. 構成ファイルに 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: admin
    
  4. 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.enabledfalse に設定します。プロジェクトにクラスタを登録しない場合は、プロジェクトで gkeonprem.googleapis.com(GKE On-Prem API のサービス名)を無効にします。手順については、サービスの無効化をご覧ください。

  5. マルチノード、高可用性、コントロール プレーンを指定するように構成ファイルを変更します。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
    
  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

管理クラスタの構成例

管理クラスタの構成例については、クラスタの構成例の管理クラスタをご覧ください。