Cluster Uninstallation Overview ​

This page is the single entry for openFuyao cluster uninstallation. It covers delete order, impact, where to run commands, and what each command removes. Detailed steps are in the linked guides below.

Danger:
Uninstall and delete are high-risk operations. Verify the target cluster, namespace, and resource names, and back up as needed. After a mistaken delete you may be unable to manage or uninstall other clusters from the management plane.

Recommended delete order ​

Uninstall in this order. Do not remove the bootstrap cluster while service/management clusters still depend on it:

Service cluster → Management cluster (if any) → Bootstrap cluster

Table 1 Recommended delete order

Caution:
Do not delete the bootstrap cluster before service/management clusters are uninstalled. After bootstrap uninstall:

• The openFuyao bootstrap management plane cannot be logged in;
• You can no longer uninstall service/management clusters via the UI or bc on the bootstrap node;
• Leftover nodes must be cleaned manually on each host.

Where to operate ​

Table 2 Where to operate and entry points

What gets deleted ​

1. Service / management cluster (via BKECluster) ​

Edit the target bc on the bootstrap or management cluster; configuration details are as follows:

Table 3 BKECluster uninstall configuration

For a full target uninstall, set ignore-target-cluster-delete to "false" and spec.reset: true. When only deleting API/bc objects without cleaning nodes, you can keep the default annotation as "true".

Note:
For a management cluster, the node agent bkeagent first listens on the bootstrap cluster and later switches to the management cluster itself. Uninstall must handle both sides (Web: delete on both UIs; CLI: delete bc on both clusters); see the dedicated guides.

During uninstall, the controller cleans addons, Kubernetes components, etcd, and related resources in reverse dependency order. If cleanup fails, the bc may enter a terminating-failed state; use kubectl describe bc to troubleshoot.

2. Bootstrap cluster (bke reset) ​

Table 4 bke reset command cleanup scope

Note:

• bke reset does not unbind leftover HA VIPs; if a VIP remains on a node, unbind it manually with ip addr del, see FAQ.
• rm -rf /bke and rm -f /usr/local/bin/bke are optional, not required for a successful reset. They remove the install media directory and the local bke binary. Reset can still be considered successful without them, but you may need to re-download tools and media before the next install.

See Command Reference and bkeadm Configuration.

Success criteria ​

Frontend (Web) ​

• Gone from the Cluster Lifecycle Management list.
• For a management cluster: the management-cluster UI (:31616) can no longer be signed in or opened; the bootstrap UI (:30010) list shows no matching entry.

Backend (CLI) ​

• Service cluster: kubectl get bc -A on the creating-side cluster no longer shows the BKECluster.
• Management cluster: former management-cluster API / management plane is unavailable; on the bootstrap node, kubectl get bc -A no longer lists that management cluster.
• Bootstrap: bke reset --all --mount finishes successfully; local k3s/Kubernetes processes and containers are gone; (after optional cleanup) /bke and the local bke binary are gone.

Navigation ​

Table 5 Cluster uninstallation documentation navigation