This page describes how to delete a GKE On-Prem user cluster.
Overview
GKE On-Prem supports deletion of healthy user clusters via gkectl
.
If the cluster is unhealthy (for example, if its control plane is unreachable or
the cluster failed to bootstrap), refer instead to
Manually deleting a user cluster.
Deleting a user cluster
Run the following command:
gkectl delete cluster \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --cluster [CLUSTER_NAME]
where [ADMIN_CLUSTER_KUBECONFIG] is the admin cluster's kubeconfig file, and [CLUSTER_NAME] is the name of the user cluster you want to delete.
After you have finished
After gkectl finishes deleting the user cluster, delete the user cluster kubeconfig.
Known Issues
An additional user control plane VM might be created in vSphere after the cluster is deleted. Verify that all user cluster VMs are deleted by performing the following steps:
- From the vSphere Web Client's left-hand Navigator menu, click the Hosts and Clusters menu.
- Find your Resource Pool.
- There should be no VMs that are prefixed with your user cluster's name.
If there are user cluster VMs remaining, perform the following steps from the vSphere Web Client:
- Right-click the user cluster VM and select Power > Power Off.
- Once the VM is powered off, right-click the VM and select Delete from Disk.
Troubleshooting
For more information, refer to Troubleshooting.
Diagnosing cluster issues using gkectl
Use gkectl diagnose
commands 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 thelogs/gkectl-$(date).log
file in the local directory where you rungkectl
. -
For
gkeadm
, the default log file islogs/gkeadm-$(date).log
in the local directory where you rungkeadm
.
-
For
- All log entries are saved in the log file, even if they are not printed in
the terminal (when
--alsologtostderr
isfalse
). - 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:
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
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