Version 1.6. This version is fully supported, offering the latest patches and updates for security vulnerabilities, exposures, and issues impacting Anthos clusters on VMware. Refer to the release notes for more details. This is the most recent version.

Creating an admin cluster

This page shows how to create an admin cluster.

The instructions here are complete. For a shorter introduction to creating an admin cluster, see Create an admin cluster (quickstart).

Before you begin

Create an admin workstation.

Get an SSH connection to your admin workstation

Get an SSH connection to your admin workstation.

Recall that gkeadm activated your component access service account on the admin workstation.

Do all the remaining steps in this topic on your admin workstation in the home directory.

Credentials configuration file

When you used gkeadm to create your admin workstation, you filled in a credentials configuration file named credential.yaml. This file holds the username and password for your vCenter server.

Admin cluster configuration file

When gkeadm created your admin workstation, it generated a configuration file named admin-cluster.yaml. This configuration file is for creating your admin cluster.

Filling in your configuration file

bundlePath

This field is already filled in for you.

vCenter

Most of the fields in this are already filled in with values that you entered when you created your admin workstation. The exception is the dataDisk field, which you must fill in now.

network

Decide how you want your cluster nodes to get their IP addresses. The options are:

  • From a DHCP server. Set network.ipMode.type to "dhcp".

  • From a list of static IP addresses that you provide. Set network.ipMode.type to "static", and create a IP block file that provides the static IP addresses.

Provide values for the remaining fields in the network section.

loadBalancer

Set aside a VIP for the Kubernetes API server of your admin cluster. Set aside another VIP for the add-ons server. Provide your VIPs as values for loadBalancer.vips.controlPlaneVIP and loadBalancer.vips.addonsVIP.

Decide what type of load balancing you want to use. The options are:

  • Seesaw bundled load balancing. Set loadBalancer.kind to "Seesaw", and fill in the loadBalancer.seesaw section.

  • Integrated load balancing with F5 BIG-IP. Set loadBalancer.kind to "F5BigIP", and fill in the f5BigIP section.

  • Manual load balancing. Set loadBalancer.kind to "ManualLB", and fill in the manualLB section.

proxy

If the network that will have your admin cluster nodes is behind a proxy server, fill in the proxy section.

privateRegistry

Decide where you want to keep container images for the Anthos clusters on VMware components. The options are:

  • gcr.io. Do not fill in the privateRegistry section.

  • Your own private Docker registry. Fill in the privateRegistry section.

gcrKeyPath

Set gcrKeyPath to the path of the JSON key file for your component access service account.

stackdriver

Fill in the stackdriver section.

cloudAuditLogging

If you want Kubernetes audit logs to be integrated with Cloud Audit Logs, fill in the cloudAuditLogging section.

Validating your configuration file

After you've filled in your admin cluster configuration file, run gkectl check-config to verify that the file is valid:

gkectl check-config --config [CONFIG_PATH]

where [CONFIG_PATH] is the path of your admin cluster configuration file.

If the command returns any failure messages, fix the issues and validate the file again.

If you want to skip the more time-consuming validations, pass the --fast flag. To skip individual validations, use the --skip-validation-xxx flags. To learn more about the check-config command, see Running preflight checks.

Running gkectl prepare

Run gkectl prepare to initialize your vSphere environment:

gkectl prepare --config [CONFIG_PATH] --skip-validation-all

Creating the admin cluster

Create the admin cluster:

gkectl create admin --config [CONFIG_PATH] --skip-validation-all

where [CONFIG_PATH] is the path of your admin cluster configuration file.

The gkectl create admin command creates a kubeconfig file named kubeconfig in the current directory. You will need this kubeconfig file later to interact with your admin cluster.

Verifying that your admin cluster is running

Verify that your admin cluster is running:

kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

where [ADMIN_CLUSTER_KUBECONFIG] is the path of your kubeconfig file.

The output shows the admin cluster nodes.

Troubleshooting

Diagnosing cluster issues using gkectl

Use gkectl diagnosecommands to identify cluster issues and share cluster information with Google. See Diagnosing cluster issues.

Default logging behavior

For gkectl and gkeadm it is sufficient to use the default logging settings:

  • By default, log entries are saved as follows:

    • For gkectl, the default log file is /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log, and the file is symlinked with the logs/gkectl-$(date).log file in the local directory where you run gkectl.
    • For gkeadm, the default log file is logs/gkeadm-$(date).log in the local directory where you run gkeadm.
  • All log entries are saved in the log file, even if they are not printed in the terminal (when --alsologtostderr is false).
  • The -v5 verbosity level (default) covers all the log entries needed by the support team.
  • The log file also contains the command executed and the failure message.

We recommend that you send the log file to the support team when you need help.

Specifying a non-default location for the log file

To specify a non-default location for the gkectl log file, use the --log_file flag. The log file that you specify will not be symlinked with the local directory.

To specify a non-default location for the gkeadm log file, use the --log_file flag.

Locating Cluster API logs in the admin cluster

If a VM fails to start after the admin control plane has started, you can try debugging this by inspecting the Cluster API controllers' logs in the admin cluster:

  1. Find the name of the Cluster API controllers Pod in the kube-system namespace, where [ADMIN_CLUSTER_KUBECONFIG] is the path to the admin cluster's kubeconfig file:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Open the Pod's logs, where [POD_NAME] is the name of the Pod. Optionally, use grep or a similar tool to search for errors:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Debugging F5 BIG-IP issues using the admin cluster control plane node's kubeconfig

After an installation, Anthos clusters on VMware generates a kubeconfig file in the home directory of your admin workstation named internal-cluster-kubeconfig-debug. This kubeconfig file is identical to your admin cluster's kubeconfig, except that it points directly at the admin cluster's control plane node, where the admin control plane runs. You can use the internal-cluster-kubeconfig-debug file to debug F5 BIG-IP issues.

gkectl check-config validation fails: can't find F5 BIG-IP partitions

Symptoms

Validation fails because F5 BIG-IP partitions can't be found, even though they exist.

Potential causes

An issue with the F5 BIG-IP API can cause validation to fail.

Resolution

Try running gkectl check-config again.

gkectl prepare --validate-attestations fails: could not validate build attestation

Symptoms

Running gkectl prepare with the optional --validate-attestations flag returns the following error:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
Potential causes

An attestation might not exist for the affected image(s).

Resolution

Try downloading and deploying the admin workstation OVA again, as instructed in Creating an admin workstation. If the issue persists, reach out to Google for assistance.

Debugging using the bootstrap cluster's logs

During installation, Anthos clusters on VMware creates a temporary bootstrap cluster. After a successful installation, Anthos clusters on VMware deletes the bootstrap cluster, leaving you with your admin cluster and user cluster. Generally, you should have no reason to interact with this cluster.

If something goes wrong during an installation, and you did pass --cleanup-external-cluster=false to gkectl create cluster, you might find it useful to debug using the bootstrap cluster's logs. You can find the Pod, and then get its logs:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

For more information, refer to Troubleshooting.

What's next

Creating a user cluster