bmctl is the single binary used to deploy and upgrade Anthos clusters on bare metal. It takes cluster settings from a configuration file. Before running it, verify the hardware, software, and Google Cloud project requirements. section 17.3 section 17.6
A first-cluster deployment follows this sequence:
- Download the appropriate bmctl binary, make it executable, and generate a template with `bmctl create config -c CLUSTER_NAME --project-id=CLOUD_PROJECT_ID`. section 17.4.1
- Edit the template for the chosen admin, hybrid, or standalone cluster: set nodes, networking, load balancing, and paths to the required keys. section 17.4.1
- Run `bmctl create cluster -c CLUSTER_NAME`. Configuration validation and preflight checks precede node provisioning and add-on installation. section 17.4.1
The Google Cloud project needs required APIs and service accounts. bmctl can enable APIs and create service accounts during installation, but distinct service accounts are recommended instead of one account holding every role. A missing API stops deployment at preflight. Other checks cover machine configuration, available filesystem space, and access to Google Cloud API endpoints. section 17.3.5 section 17.4.1
Add a user cluster
After creating an admin or hybrid cluster, generate a user-cluster template with `bmctl create config -c CLUSTER_NAME`. Keep its Cluster and NodePool manifests, set the cluster type to `user`, and avoid reusing control-plane, load-balancer, or node-pool IP addresses. The user cluster inherits the earlier Google Cloud credentials, so remove their key paths. Then run `bmctl create cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG`. section 17.4.2
To upgrade an admin, standalone, or hybrid cluster, change its configured Anthos version, download bmctl for that target version, and run `bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG`. Plan storage separately: the default local-host option is suitable only for development clusters. section 17.5.1 section 17.6
