スタンドアロン クラスタを作成する

Version 1.12 

• 最新
• バージョン 1.16
• 以前のバージョン（サポート対象外）

このページでは、スタンドアロン クラスタを作成する方法について説明します。これは、ワークロードを実行する自己管理型のクラスタです。スタンドアロン クラスタは、リソースが制限されたシナリオで別の管理クラスタを実行する必要性を排除するため、他のクラスタは管理しません。さらに、スタンドアロン クラスタには、次の 2 つのインストール プロファイルがあります。

• デフォルト: デフォルト プロファイルには、リソース要件に関する制限があります。
• Edge: Edge プロファイルはシステム リソースの要件を大幅に削減します。リソースの制約が大きい Edge デバイスにおすすめです。

スタンドアロン クラスタを作成する前には、リソースの削減と全体的なセキュリティとのトレードオフを検討します。スタンドアロン クラスタは自身を管理するため、同じクラスタでワークロードを実行すると、SSH 認証鍵などの機密性の高い管理データが公開されるリスクが高くなります。

前提条件

スタンドアロン クラスタを作成する前に、次のことを確認してください。

• 最新の bmctl が Cloud Storage からダウンロードされている（gs://anthos-baremetal-release/bmctl/1.12.9/linux-amd64/bmctl）。
• bmctl を実行するワークステーションが、ターゲットのスタンドアロン クラスタ内のすべてのノードとネットワークで接続されている。
• bmctl を実行するワークステーションは、ターゲット スタンドアロン クラスタのコントロール プレーンの VIP とネットワークで接続されている。
• スタンドアロン クラスタの作成に使用される SSH 認証鍵が root で使用可能、またはターゲット スタンドアロン クラスタ内のすべてのノードに対して SUDO のユーザー アクセス権がある。
• 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 のみをサポートしています。

スタンドアロン クラスタを作成する

コントロール ノード プレーンが 1 つあるスタンドアロン クラスタは、bmctl コマンドを使用して作成できます。このタイプの構成では、リソースの使用量が少なくなりますが、高可用性（HA）は実現されません。また、結果として得られるクラスタには、単一の障害点があります。

HA スタンドアロン クラスタを作成することもできます。HA モードでは、ノードに障害が発生すると、他のノードが障害の発生したノードの代わりをします。HA スタンドアロン クラスタを作成するには、コントロール プレーンに少なくとも 3 つのノードを指定する必要があります。

通常 bmctl コマンドは、別のワークステーションか、いずれかのスタンドアロン クラスタノードで実行できます。ただし、エッジ プロファイルを有効にしたスタンドアロン クラスタを作成し、必要最小限のリソースが構成されている場合は、bmctl を別のワークステーションで実行することをおすすめします。

gcloud にログインする

1. ユーザーとして gcloud にログインします。

   gcloud auth application-default login
   

   以下で説明する自動 API 有効化とサービス アカウント作成機能を使用するには、プロジェクト オーナーまたは編集者のロールが必要です。

   次の IAM ロールをユーザーに追加することもできます。

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

   あるいは、これらのロールを持つサービス アカウントがすでにある場合は、次のコマンドを実行します。

   export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
   

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

2. クラスタ作成に使用する Google CCloud プロジェクト ID を取得します。

   export CLOUD_PROJECT_ID=$(gcloud config get-value project)
   

スタンドアロン クラスタ構成ファイルを作成する

gcloud にログインしてプロジェクトを設定すると、bmctl コマンドを使用してクラスタ構成ファイルを作成できます。この例では、すべてのサービス アカウントが bmctl create config コマンドで自動的に作成されます。

bmctl create config -c STANDALONE_CLUSTER_NAME --enable-apis \
    --create-service-accounts --project-id=$CLOUD_PROJECT_ID

以下を置き換えます。

• STANDALONE_CLUSTER_NAME は、作成するスタンドアロン クラスタの名前に置き換えます。

例

次のコマンドを実行すると、プロジェクト ID my-gcp-project に関連付けられた standalone1 という名前のスタンドアロン クラスタ構成ファイルが作成されます。

bmctl create config -c standalone1 --create-service-accounts --project-id=my-gcp-project

ファイルは、bmctl-workspace/standalone1/standalone1.yaml に書き込まれます。

適切な IAM 権限がある場合は、API を自動的に有効にし、サービス アカウントを作成する代わりに、既存のサービス アカウントを指定することもできます。つまり、サービス アカウントを自動で作成した前の手順の次の bmctl コマンドはスキップできます。

bmctl create config -c standalone1

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

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

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/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
   

2. フリートにクラスタを登録します。bmctl create config コマンドで指定したプロジェクト ID は、クラスタ構成ファイルの gkeConnect.projectID フィールドに自動的に追加されます。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。

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

3. 構成を変更して、クラスタタイプを admin ではなく standalone を指定します。Edge プロファイルを有効にしてリソースの使用量を最小限に抑える場合は、profile: edge を指定します。

   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: standalone
     # Edge profile minimizes the resource consumption of Anthos clusters on bare metal. It is only available for standalone clusters.
     profile: edge
   

4. （省略可）マルチノード、高可用性、コントロール プレーンを指定するように構成を変更します。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 を維持します。

5. クラスタノードの 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
     # containerRuntime specifies which container runtime to use for scheduling containers on nodes.
     # containerd and docker are supported.
     containerRuntime: containerd
   ....
   

   スタンドアロン クラスタの場合、maxPodsPerNode の値は、HA クラスタ用には 32-250、HA 以外のクラスタ用には 64-250 です。指定しない場合、デフォルトの 110 が使用されます。クラスタの作成後、この値を更新することはできません。

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

   デフォルトのコンテナ ランタイムは containerd です。Docker を使用することもできます。ランタイムの変更について詳しくは、コンテナ ランタイムの変更ガイドをご覧ください。 最小リソース要件を構成して Edge プロファイルを有効にする場合は、containerd を使用することをおすすめします。

クラスタ構成ファイルでスタンドアロン クラスタを作成する

bmctl コマンドを使用して、スタンドアロン クラスタをデプロイします。

bmctl create cluster -c CLUSTER_NAME

CLUSTER_NAME は、前のセクションで作成したクラスタの名前に置き換えます。

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

bmctl create cluster -c standalone1

スタンドアロン クラスタの構成例

スタンドアロン クラスタの構成例については、クラスタ構成サンプルのスタンドアロン クラスタをご覧ください。