Understanding preflight checks

In Google Distributed Cloud you can run preflight checks for different situations:

  • Google Distributed Cloud runs preflight checks when you create or update admin, hybrid, standalone, or user clusters and nodepool resources with bmctl. If the checks fail, no changes are made. You can also bypass these checks.
  • Google Distributed Cloud also runs internal preflight checks when you apply Kubernetes resources to user clusters from an admin or hybrid cluster. The checks are run before changes are actually applied to affected user clusters. If the checks fail, no changes are made. You can also bypass these checks, or run them explicitly.

Preflight checks when creating clusters using bmctl

When you create admin, hybrid, standalone, or user clusters with the bmctl command, Google Distributed Cloud automatically runs preflight checks before any changes are made.

When the checks pass, Google Distributed Cloud will create the clusters.

Ignoring the results of automated preflight checks

If you want to bypass these automated preflight checks, you can use the optional --force flag in the command.

Running preflight checks independently

You can also run preflight checks by themselves, before you create a cluster. This can help save time by ensuring your machine and node resources pass checks.

  • The following command validates the specified cluster config file, but doesn't try to create the cluster itself:

    bmctl check config --cluster CLUSTER_NAME

    Replace CLUSTER_NAME with the name of the cluster whose config file you're checking.

  • This command checks whether the machines and network are ready for cluster creation:

    bmctl check preflight --cluster CLUSTER_NAME

    Replace CLUSTER_NAME with the name of the cluster you're checking.

Preflight checks for user cluster creation

User clusters are created from an existing admin or hybrid cluster. Google Distributed Cloud automatically runs preflight checks before making any changes. You can also run preflight checks with bmctl before you create a cluster.

  • The following command validates the specified cluster config file, but doesn't try to create the cluster itself:

    bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

    Replace CLUSTER_NAME with the name of the user cluster you're checking and replace ADMIN_KUBECONFIG_PATH with the path to the associated admin cluster's kubeconfig file.

  • This command checks whether the machines and network are ready for cluster creation:

    bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

bmctl supports the use of --kubeconfig as an alias for the--admin-kubeconfig flag.

Internal preflight checks on existing clusters

Google Distributed Cloud also performs internal preflight checks when you apply Kubernetes resources to an existing cluster. If any checks fail, Google Distributed Cloud will not make any changes to the related nodes unless you've specifically bypassed the checks.

Bypassing preflight checks when applying Kubernetes resources

To ignore the internal preflight checks when applying resources to existing clusters, you need to set the BypassPreflightCheck field to true in the cluster YAML file.

Here is a fragment of a cluster config YAML file, showing the bypassPreflightCheck field set to true.

# Sample cluster config to bypass preflight check errors:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.8.9
....

Installation preflight check details

Google Distributed Cloud checks a variety of operating system, software, and machine prerequisite conditions when running preflight checks.

For more detailed information, see Installation prerequisites overview.