マルチクラスタ設定でのユーザー クラスタの作成

ベアメタル上の Anthos クラスタでは、ユーザー クラスタがワークロードを実行します。マルチクラスタ アーキテクチャでは、ユーザー クラスタの作成と管理は管理クラスタによって行われます。

管理クラスタを作成したら、bmctl create config コマンドを呼び出し、ユーザー クラスタを定義する yaml ファイルを作成します。構成を適用してユーザー クラスタを作成するには、ベアメタル 1.7.0 以降のバージョンの Anthos クラスタで bmctl create cluster コマンドを使用します。プリフライト チェックは、bmctl create cluster コマンドを使用して作成されたユーザー クラスタに適用されます。

ワークロードを管理クラスタ以外に配置すると、管理クラスタに保存されている SSH 認証鍵などの重要な管理情報は、その情報を必要としないユーザーから保護されます。さらに、ユーザー クラスタを互いに分離しておくことで、ワークロードの全般的なセキュリティを維持できます。

前提条件

  • 最新の bmctl が Cloud Storage からダウンロードされている（gs://anthos-baremetal-release/bmctl/1.7.7/linux-amd64/bmctl）。
  • クラスタ API サーバー（controlPlaneVIP）にアクセスできる作業用の管理クラスタがある。
  • 管理クラスタノードが、ターゲット ユーザー クラスタのすべてのノードに接続できる。
  • bmctl を実行するワークステーションが、ターゲット ユーザー クラスタのすべてのノードに接続できる。
  • ユーザー クラスタ内のすべてのノードで root または SUDO ユーザーが使用できるユーザー クラスタの作成に使用できる SSH 認証鍵が用意されている。
  • 1.7.0 以降のバージョンでは、Connect で使用できるように、Connect-register サービス アカウントが管理クラスタで構成されている。

ユーザー クラスタ構成ファイルを作成する

ユーザー クラスタを作成するための構成ファイルは、管理クラスタの作成に使用される構成ファイルとほぼ同じです。唯一の違いは、ローカルの認証情報構成セクションから削除し、構成ファイルを Kubernetes リソースの有効なコレクションにすることです。構成セクションは、ファイルの先頭にある bmctl configuration variables セクションの下にあります。

デフォルトでは、ユーザー クラスタはその管理クラスタから認証情報を継承します。これらの認証情報の一部またはすべてを無効にできます。詳しくは、ユーザー クラスタ構成ファイルの例をご覧ください。

  1. 次の bmctl create config コマンドを使用して、ユーザー クラスタ構成ファイルを作成します。

    bmctl create config -c USER_CLUSTER_NAME

    たとえば、user1 というユーザー クラスタ構成ファイルを作成するには、次のコマンドを実行します。

    bmctl create config -c user1

    ファイルは bmctl-workspace/user1/user1.yaml に書き込まれます。ファイルへの一般的なパスは bmctl-workspace/CLUSTER NAME/CLUSTER_NAME.yaml です。

  2. 構成ファイルに次の変更を行います。

    • ローカルの認証情報ファイル パスを構成から削除します。

      ....
  gcrKeyPath: (path to GCR service account key)
  sshPrivateKeyPath: (path to SSH private key, used for node access)
  gkeConnectAgentServiceAccountKeyPath: (path to Connect agent service account key)
  gkeConnectRegisterServiceAccountKeyPath: (path to Hub registration service account key)
  cloudOperationsServiceAccountKeyPath: (path to Cloud Operations service account key)
....

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

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

    • ロードバランサの VIP とアドレスプールに対する管理者クラスタとユーザー クラスタの指定が補完され、既存のクラスタと重複しないことを確認します。以下に、負荷分散とアドレスプールを指定する管理者クラスタとユーザー クラスタの構成のサンプルを示します。

      ....
# Sample admin cluster config for load balancer and address pools
  loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.49
      ingressVIP: 10.200.0.50
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.50-10.200.0.70
....
....
# Sample user cluster config for load balancer and address pools
loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
....

      ユーザー クラスタ構成ファイルの残りの部分は管理クラスタ構成ファイルと同じです。

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

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

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

ユーザー クラスタを作成する

bmctl コマンドを実行して、ユーザー クラスタ構成ファイルを適用し、クラスタを作成します。

bmctl create cluster -c USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

次のように置き換えます。

  • USER_CLUSTER_NAME: 前のセクションで作成したクラスタ名。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

たとえば、ユーザー クラスタの名前が user1 で、管理クラスタの kubeconfig ファイルのパスが kubeconfig bmctl-workspace/admin/admin-kubeconfig の場合、コマンドは次のようになります。

bmctl create cluster -c user1 --kubeconfig bmctl-workspace/admin/admin-kubeconfig

完全なユーザー クラスタ構成ファイルのサンプル

次に、bmctl コマンドによって作成されたユーザー クラスタ構成ファイルの例を示します。このサンプル構成では、プレースホルダのクラスタ名、VIP、アドレスが使用されていることに注意してください。ネットワークによっては動作しない可能性があります。デフォルトでは、認証情報は管理クラスタから継承されます。認証情報をオーバーライドする場合は、configuration variables セクションの対応するキーパスを指定する必要があります。

# Sample user cluster config:

# ---
# To override default credentials
# 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-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
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: user
  # Anthos cluster version.
  anthosBareMetalVersion: 1.7.7
  # 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
  # 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 virtual IPs 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/20
  # 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 load balancer 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 virtual IP (VIP) addresses: 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.
    # These IP addresses do not correspond to physical network interfaces.
    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.200.0.72
    # 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.200.0.72-10.200.0.90
    # A load balancer node pool 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
    # 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
  # 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
  # KubeVirt configuration, uncomment this section if you want to install kubevirt to the cluster
  # kubevirt:
  #   # if useEmulation is enabled, hardware accelerator (i.e relies on cpu feature like vmx or svm)
  #   # will not be attempted. QEMU will be used for software emulation.
  #   # useEmulation must be specified for KubeVirt installation
  #   useEmulation: false
  # 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: &lt;Redirect URL for the gcloud CLI; optional, default is "http://kubectl.redirect.invalid"&gt;
  #     # 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>
  #     # proxy specifies the proxy server to use for the cluster to connect to your OIDC provider, if applicable.
  #     # Example: https://user:password@10.10.10.10:8888. If left blank, this defaults to no proxy.
  #     proxy: <Proxy server to use for the cluster to connect to your OIDC provider; optional, default is no proxy>
  #     # deployCloudConsoleProxy specifies whether to deploy a reverse proxy in the cluster to allow Google Cloud
  #     # Console access to the on-premises OIDC provider for authenticating users. If your identity provider is not
  #     # reachable over the public internet, and you wish to authenticate using Google Cloud console, then this field
  #     # must be set to true. If left blank, this field defaults to false.
  #     deployCloudConsoleProxy: <Whether to deploy a reverse proxy for Google Cloud console authentication; 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.
  #     # However, if deployCloudConsoleProxy is true, then this value must be provided, even for 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>
---
# Node pools for worker nodes
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-user1
spec:
  clusterName: user1
  nodes:
  - address: 10.200.0.5