Uninstall c8s

Reverse a c8s install with c8s uninstall — what the Helm release removes, the host-side kata artifact sweep, running the sweep on its own, and the two destructive opt-ins that are off by default.

c8s uninstall reverses the install — same --namespace / --release defaults as c8s install:

c8s uninstall

It runs helm uninstall to remove the release (operator, CDS, attestation-api, ratls-mesh, tls-lb, webhook configuration, RuntimeClasses, enforcement policy), and for a --cvm-mode=pod install it then sweeps the host-side kata artifacts off every node — /opt/kata, the containerd runtime drop-in, the multi-GB kata-guest-base image, the RKE2 prep template, and the kata-runtime node labels — via a short-lived privileged DaemonSet. The sweep is read from the release's computed values before deletion, so install-time -f overrides are honored, and it's skipped automatically for a non-pod install. The sweep only recursively deletes guest-image directories strictly under /var/lib/c8s/; a kata.guestImage.hostPath you relocated elsewhere aborts the sweep with an error rather than being deleted by a privileged DaemonSet — remove that directory yourself.

To remove kata leftovers from a cluster whose release is already gone (e.g. a previous bare helm uninstall), run just the sweep:

c8s uninstall --host-sweep-only

Uninstall refuses to proceed while pods with a kata RuntimeClass are still running — pulling the runtime out from under a confidential workload kills it without cleanup. Delete those workloads first, or pass --force (the VMs keep running unmanaged but cannot restart).

Two opt-ins are destructive and off by default: --delete-crds removes the ConfidentialWorkload CRD and every ConfidentialWorkload object in the cluster with it, and --delete-namespace deletes the release namespace and everything left in it.

See the CLI Reference for every flag.