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

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

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

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

前提条件

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

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

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

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

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

通常 bmctl コマンドは、別のワークステーションか、いずれかのスタンドアロン クラスタノードで実行できます。ただし、Edge プロファイルを有効にしたスタンドアロン クラスタを作成し、必要最小限のリソースが構成されている場合は、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 Cloud プロジェクト ID を取得します。

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

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

gcloud CLI にログインしてプロジェクトを設定すると、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 Google Distributed Cloud. 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. クラスタ構成ファイルで、クラスタ ネットワークの詳細を入力するか、編集します。

    • clusterNetwork.pods.cidrBlocks: Pod が使用する IP アドレスの範囲（CIDR ブロック表記）。推奨の開始値は、生成されたクラスタ構成ファイルに事前入力されている 192.168.0.0/16 です。

    • clusterNetwork.services.cidrBlocks: Service が使用する IP アドレスの範囲（CIDR ブロック表記）。推奨の開始値は、生成されたクラスタ構成ファイルに事前入力されている 10.96.0.0/20 です。

    • loadBalancer.vips.controlPlaneVIP: クラスタの Kubernetes API サーバーの仮想 IP（VIP）アドレス。

    • loadBalancer.vips.ingressVIP: Ingress プロキシの外部アドレスとして使用する VIP アドレス。

    • loadBalancer.addressPools.addresses:: LoadBalancer タイプの Service の外部 IP アドレスとして使用する 10 個の IP アドレスの範囲。この範囲には、MetalLB に必要な Ingress VIP が含まれることに注意してください。他の IP アドレスは、この範囲と重複できません。

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

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

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

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

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

bmctl create cluster -c CLUSTER_NAME

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

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

bmctl create cluster -c standalone1

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

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