マルチクラスタ設定での管理クラスタの作成

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

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

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

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

事前準備

  • gs://anthos-baremetal-release/bmctl/1.6.2/linux-amd64/bmctl から bmctl をダウンロードします。
  • bmctl を実行するワークステーションは、ターゲット ユーザー クラスタのすべてのノードにネットワーク接続を持っている必要があります。
  • bmctl を実行するワークステーションは、クラスタ API サーバー（コントロール プレーン VIP）とのネットワーク接続が必要です。
  • 管理クラスタの作成に使用される SSH キーは、ルートとして使用可能である必要があります。または、対象の管理クラスタのすべてのノードで SUDO ユーザー アクセス権を持っている必要があります。

ハイブリッド クラスタを作成する際の拡充された手順ガイドについては、ベアメタル版 Anthos クラスタのクイックスタートをご覧ください。管理クラスタの作成は、管理クラスタでワークロードを実行しないことを除けば、ハイブリッド クラスタの作成と類似しています。

gcloud にログインして管理クラスタ構成ファイルを作成する

  1. gcloud auth application-default ログインを使用して、ユーザーとして gcloud にログインします。
    2. gcloud auth application-default login
    以下で説明する自動 API 有効化とサービス アカウント作成機能を使用するには、プロジェクト オーナーまたは編集者のロールが必要です。次の IAM ロールをユーザーに追加することもできます。
    • サービス アカウント管理者
    • サービス アカウント キー管理者
    • プロジェクト IAM 管理者
    • Compute 閲覧者
    • Service Usage 管理者
    また、これらのロールを持つサービス アカウントがすでにある場合は、次のコマンドを実行します。
    export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
    JSON_KEY_FILE には、サービス アカウントの JSON キーファイルへのパスを指定します。
  2. クラスタの作成に使用する Cloud プロジェクト ID を取得します。
    3. export CLOUD_PROJECT_ID=$(gcloud config get-value project)

bmctl を使用して管理クラスタ構成を作成する

gcloud にログインしてプロジェクトを設定すると、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 はプロジェクト 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

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

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

  1. 管理クラスタノードにアクセスするための SSH 秘密鍵を指定します。
    2. 
# 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/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /path/to/your/ssh_private_key
gkeConnectAgentServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json
gkeConnectRegisterServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json
cloudOperationsServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json
  2. 構成ファイルに admin のクラスタタイプ（デフォルト値）が指定されていることを確認します。
    3. 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
  3. マルチノード、高可用性、コントロール プレーンを指定するように構成ファイルを変更します。HA 用に過半数のクォーラムが確保するように、ノード数を奇数で指定します。
    4.   # 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

クラスタ構成ファイルで管理クラスタを作成する

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

bmctl create cluster -c ADMIN_CLUSTER_NAME

ADMIN_CLUSTER_NAME は、前のセクションで作成したクラスタ名を指定します。

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

bmctl create cluster -c admin1

完全な管理クラスタ構成ファイルの例

bmctl コマンドによって作成された管理クラスタ構成ファイルの例を次に示します。このサンプル構成では、プレースホルダのクラスタ名、VIP、アドレスが使用されていることに注意してください。ネットワークによっては動作しない可能性があります。


gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /bmctl/bmctl-workspace/.ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json
gkeConnectRegisterServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json
cloudOperationsServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
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
  # Anthos cluster version.
  anthosBareMetalVersion: v1.6.2
  # GKE connect configuration
  gkeConnect:
    projectID: $GOOGLE_PROJECT_ID
  # 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
  # Cluster networking configuration
  clusterNetwork:
    # Pods specify the IP ranges from which Pod networks are allocated.
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    # Services specify the network ranges from which service VIPs are allocated.
    # This can be any RFC 1918 range that does not conflict with any other IP range
    # in the cluster and node pool resources.
    services:
      cidrBlocks:
      - 10.96.0.0/12
  # Load balancer configuration
  loadBalancer:
    # Load balancer mode can be either 'bundled' or 'manual'.
    # In 'bundled' mode a load balancer will be installed on load balancer nodes during cluster creation.
    # In 'manual' mode the cluster relies on a manually-configured external load balancer.
    mode: bundled
    # Load balancer port configuration
    ports:
      # Specifies the port the LB serves the kubernetes control plane on.
      # In 'manual' mode the external load balancer must be listening on this port.
      controlPlaneLBPort: 443
    # There are two load balancer VIPs: one for the control plane and one for the L7 Ingress
    # service. The VIPs must be in the same subnet as the load balancer nodes.
    vips:
      # ControlPlaneVIP specifies the VIP to connect to the Kubernetes API server.
      # This address must not be in the address pools below.
      controlPlaneVIP: 10.200.0.71
      # IngressVIP specifies the VIP shared by all services for ingress traffic.
      # Allowed only in non-admin clusters.
      # This address must be in the address pools below.
      # ingressVIP: 10.0.0.2
    # AddressPools is a list of non-overlapping IP ranges for the data plane load balancer.
    # All addresses must be in the same subnet as the load balancer nodes.
    # Address pool configuration is only valid for 'bundled' LB mode in non-admin clusters.
    # addressPools:
    # - name: pool1
    #   addresses:
    #   # Each address must be either in the CIDR form (1.2.3.0/24)
    #   # or range form (1.2.3.1-1.2.3.5).
    #   - 10.0.0.1-10.0.0.4
    # A load balancer nodepool can be configured to specify nodes used for load balancing.
    # These nodes are part of the kubernetes cluster and run regular workloads as well as load balancers.
    # If the node pool config is absent then the control plane nodes are used.
    # Node pool configuration is only valid for 'bundled' LB mode.
    # nodePoolSpec:
    #  nodes:
    #  - address: <Machine 1 IP>
  # Proxy configuration
  # proxy:
  #   url: http://[username:password@]domain
  #   # A list of IPs, hostnames or domains that should not be proxied.
  #   noProxy:
  #   - 127.0.0.1
  #   - localhost
  # Logging and Monitoring
  clusterOperations:
    # Cloud project for logs and metrics.
    projectID: <Google Project ID>$GOOGLE_PROJECT_ID
    # Cloud location for logs and metrics.
    location: us-central1
    # Whether collection of application logs/metrics should be enabled (in addition to
    # collection of system logs/metrics which correspond to system components such as
    # Kubernetes control plane or cluster management agents).
    # enableApplication: false
  # Storage configuration
  storage:
    # lvpNodeMounts specifies the config for local PersistentVolumes backed by mounted disks.
    # These disks need to be formatted and mounted by the user, which can be done before or after
    # cluster creation.
    lvpNodeMounts:
      # path specifies the host machine path where mounted disks will be discovered and a local PV
      # will be created for each mount.
      path: /mnt/localpv-disk
      # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
      # is created during cluster creation.
      storageClassName: local-disks
    # lvpShare specifies the config for local PersistentVolumes backed by subdirectories in a shared filesystem.
    # These subdirectories are automatically created during cluster creation.
    lvpShare:
      # path specifies the host machine path where subdirectories will be created on each host. A local PV
      # will be created for each subdirectory.
      path: /mnt/localpv-share
      # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
      # is created during cluster creation.
      storageClassName: local-shared
      # numPVUnderSharedPath specifies the number of subdirectories to create under path.
      numPVUnderSharedPath: 5
  # Authentication; uncomment this section if you wish to enable authentication to the cluster with OpenID Connect.
  # authentication:
  #   oidc:
  #     # issuerURL specifies the URL of your OpenID provider, such as "https://accounts.google.com". The Kubernetes API
  #     # server uses this URL to discover public keys for verifying tokens. Must use HTTPS.
  #     issuerURL: <URL for OIDC Provider; required>
  #     # clientID specifies the ID for the client application that makes authentication requests to the OpenID
  #     # provider.
  #     clientID: <ID for OIDC client application; required>
  #     # clientSecret specifies the secret for the client application.
  #     clientSecret: <Secret for OIDC client application; optional>
  #     # kubectlRedirectURL specifies the redirect URL (required) for the gcloud CLI, such as
  #     # "http://localhost:[PORT]/callback".
  #     kubectlRedirectURL: <Redirect URL for the gcloud CLI; optional default is             "http://kubectl.redirect.invalid"
  #     # username specifies the JWT claim to use as the username. The default is "sub", which is expected to be a
  #     # unique identifier of the end user.
  #     username: <JWT claim to use as the username; optional, default is "sub">
  #     # usernamePrefix specifies the prefix prepended to username claims to prevent clashes with existing names.
  #     usernamePrefix: <Prefix prepended to username claims; optional>
  #     # group specifies the JWT claim that the provider will use to return your security groups.
  #     group: <JWT claim to use as the group name; optional>
  #     # groupPrefix specifies the prefix prepended to group claims to prevent clashes with existing names.
  #     groupPrefix: <Prefix prepended to group claims; optional>
  #     # scopes specifies additional scopes to send to the OpenID provider as a comma-delimited list.
  #     scopes: Additional scopes to send to OIDC provider as a comma-separated list; optional>
  #     # extraParams specifies additional key-value parameters to send to the OpenID provider as a comma-delimited
  #     # list.
  #     extraParams: Additional key-value parameters to send to OIDC provider as a comma-separated list; optional>
  #     # certificateAuthorityData specifies a Base64 PEM-encoded certificate authority certificate of your identity
  #     # provider. It's not needed if your identity provider's certificate was issued by a well-known public CA.
  #     certificateAuthorityData: Base64 PEM-encoded certificate authority certificate of your OIDC provider; optional>
  # Node access configuration; uncomment this section if you wish to use a non-root user
  # with passwordless sudo capability for machine login.
  # nodeAccess:
  #   loginUser: login user name