Anthos clusters on bare metal は、ベアメタル向け Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

このページは Cloud Translation API によって翻訳されました。

ハイブリッドクラスタを作成する

Google Distributed Cloud では、ハイブリッドクラスタは管理クラスタとユーザークラスタの 2 つの役割を担いますす。ハイブリッドクラスタはワークロードの実行と同時に、他のクラスタとクラスタ自身の管理を行います。

ハイブリッドクラスタでは、リソース制限のあるシナリオで個別の管理クラスタを実行する必要がなくなり、高可用性（HA）の信頼性が得られます。HA ハイブリッドクラスタでは、1 つのノードに障害が発生した場合、他のノードが障害の発生したノードの代わりをします。

ハイブリッドクラスタは、他のクラスタも管理できる点で、スタンドアロンクラスタとは異なります。スタンドアロンクラスタでは、他のクラスタを作成または管理できません。

ただし、ハイブリッドクラスタを作成する場合、柔軟性とセキュリティとの間にはトレードオフの関係があります。ハイブリッドクラスタはクラスタ自身を管理するため、同じクラスタ上でのワークロードの実行は、SSH 認証鍵などの機密性の高い管理データが公開されるセキュリティリスクが高まります。

bmctl コマンドを使用して、高可用性（HA）コントロールプレーンを含むハイブリッドクラスタを作成します。bmctl コマンドは、別のワークステーションまたはハイブリッドクラスタノードのいずれかでの実行が可能です。

前提条件

最新の bmctl が Cloud Storage からダウンロードされている（gs://anthos-baremetal-release/bmctl/1.30.300-gke.84/linux-amd64/bmctl）。
bmctl を実行するワークステーションが、ターゲットのハイブリッドクラスタ内のすべてのノードとネットワークで接続されている。
bmctl を実行するワークステーションが、ターゲットハイブリッドクラスタのコントロールプレーンの VIP とネットワークで接続されている。
ハイブリッドクラスタの作成に使用される SSH 認証鍵が root で使用できる。または、ターゲットハイブリッドクラスタ内のすべてのノードに対して SUDO のユーザーアクセス権がある。
Connect-register サービスアカウントは、Connect で使用できるように構成されています。

ハイブリッドクラスタを作成する手順ガイドについては、Google Distributed Cloud のクイックスタートをご覧ください。

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 にログインしてクラスタ構成ファイルを作成する

gcloud auth application-default login を使用して、ユーザーとして gcloud CLI にログインします。
```
gcloud auth application-default login
```
次のセクションで説明する API の自動有効化機能とサービスアカウント作成機能を使用するには、プロジェクトオーナーまたは編集者のロールが必要です。

次の IAM ロールをユーザーに追加することもできます。
- サービスアカウント管理者
- サービスアカウントキー管理者
- プロジェクト IAM 管理者
- Compute 閲覧者
- Service Usage 管理者
あるいは、これらのロールを持つサービスアカウントがすでにある場合は、次のコマンドを実行します。
```
export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
```
JSON_KEY_FILE は、サービスアカウント JSON キーファイルのパスで置き換えます。
クラスタ作成に使用する Google Cloud プロジェクト ID を取得します。
```
export CLOUD_PROJECT_ID=$(gcloud config get-value project)
```

`bmctl` を使用してクラスタ構成ファイルを作成する

gcloud CLI にログインしてプロジェクトを設定すると、bmctl コマンドを使用してクラスタ構成ファイルを作成できるようになります。

クラスタ構成ファイルを作成するには:

次のコマンドを実行すると、クラスタ構成ファイルが作成され、必要なすべてのサービスアカウントが作成されて、必要なすべての API が有効になります。
```
bmctl create config -c CLUSTER_NAME</var> --enable-apis \
    --create-service-accounts --project-id=CLOUD_PROJECT_ID
```
次のように置き換えます。
- CLUSTER_NAME: 作成するクラスタの名前。
- CLOUD_PROJECT_ID: Google Cloud プロジェクトの ID。
デフォルトでは、構成ファイルは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml に書き込まれます。

API を有効にしてサービスアカウントを作成している場合は、API を有効にしてサービスアカウントを作成する必要なしに構成ファイルを作成できます。--project-id フラグを使用する必要もありません。ただし、構成ファイルで認証情報を手動で指定する必要があります。

コマンドオプションの詳細については、構成を作成するをご覧ください。

クラスタ構成ファイルの編集

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

ハイブリッドクラスタノードにアクセスするための 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/hybrid 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 フィールドで参照します。

構成を変更して、クラスタタイプを admin ではなく hybrid を指定します。

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: hybrid

マルチノード、高可用性、コントロールプレーンを指定するように構成を変更します。 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
```
注: ノードのメンテナンスや交換によるノードの追加や削除で、ノード数が一時的に偶数になる場合でも、クォーラムが十分に確保されている限りデプロイは HA を維持します。
クラスタノードの 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 です。指定しない場合、maxPodsPerNode のデフォルト値は 110 です。クラスタの作成後、この値を更新することはできません。

Pod 密度も、クラスタで使用可能な IP リソースによって制限されます。詳しくは、Pod ネットワークをご覧ください。

クラスタ構成ファイルでハイブリッドクラスタを作成する

bmctl コマンドを使用して、クラスタを作成します。

bmctl create cluster -c CLUSTER_NAME

CLUSTER_NAME は、前のセクションでクラスタ構成ファイルを作成したときに使用した名前に置き換えます。

hybrid1 という名前のクラスタを作成するコマンドの例を次に示します。

bmctl create cluster -c hybrid1

ハイブリッドクラスタ構成の例

ハイブリッドクラスタの構成例については、クラスタ構成サンプルのハイブリッドクラスタをご覧ください。

ハイブリッド クラスタを作成する