Introduction

MicroK8s wraps a full Kubernetes stack into a snap package, so “kill MicroK8s” can mean different things depending on what you want. Sometimes you only want to stop the services temporarily, sometimes you want to wipe cluster state, and sometimes you want to remove MicroK8s entirely from the machine.

Choose the Right Level of Shutdown

Before running commands, decide which outcome you need:

• stop the cluster but keep it installed
• reset Kubernetes state and addons
• remove the snap package completely

Those actions are not equivalent. A stop is reversible. A reset is destructive to cluster resources. A full uninstall removes the MicroK8s installation itself.

Temporarily Stop MicroK8s

If the goal is simply to halt Kubernetes processes and free resources, use MicroK8s’ own stop command:

microk8s stop

This shuts down the services managed by MicroK8s but keeps the installation and cluster data on disk. You can later start it again with:

microk8s start

This is the safest option when you are troubleshooting or pausing a development environment.

You can verify the state afterward:

microk8s status

If MicroK8s is stopped, the status output will indicate that the services are not currently running.

Stop the Snap Service Directly

Because MicroK8s is delivered as a snap, you can also stop the snap service layer. This is useful when the wrapper command is unavailable or you want to manage the service from the system side.

sudo snap stop microk8s

To start it again:

sudo snap start microk8s

In day-to-day use, microk8s stop is usually clearer because it expresses the Kubernetes intent directly. The snap commands are still useful when the service management itself is the problem.

Reset the Cluster State

If by “kill” you mean “wipe the cluster and start fresh,” use reset instead of stop. This removes deployed workloads, resets addons, and clears the local Kubernetes state managed by MicroK8s.

microk8s reset

This is a destructive operation. It is appropriate for:

• broken local test clusters
• lab environments you want to rebuild quickly
• addon experiments that left the cluster messy

It is not appropriate if you want to preserve namespaces, deployments, or local registry content.

A common reset flow is:

microk8s kubectl get all --all-namespaces
microk8s reset
microk8s status --wait-ready

That lets you inspect what exists before wiping it, then confirm the clean cluster afterward.

Remove MicroK8s Completely

If you want the software gone, stopping or resetting is not enough. Remove the snap package:

sudo snap remove microk8s

That removes the installed MicroK8s package. On some systems you may also want to inspect leftover data directories if you are doing a thorough cleanup, especially after failed installs or experiments.

A practical cleanup flow is:

microk8s stop || true
sudo snap remove microk8s

Only remove directories manually if you know they are leftover artifacts and not part of something you still need.

When Processes Seem Stuck

Sometimes MicroK8s does not shut down cleanly because containerd, kubelite, or other underlying processes are hung. In that case, inspect what is still running before reaching for kill -9.

Useful checks:

ps aux | grep -i microk8s
ps aux | grep -E 'kubelite|containerd|kube-apiserver'
sudo journalctl -u snap.microk8s.daemon-kubelite -n 100

If you identify a truly stuck service, stopping the snap is usually a better first step than manually killing individual processes, because snap-managed services are expected to restart or stop as a unit.

Avoid Using Manual Kill as the First Option

You can manually terminate processes with tools such as pkill, but that should usually be the last resort. Killing Kubernetes processes directly can leave state inconsistent or make the real cause harder to diagnose.

If you must do it for a stuck local dev box, be explicit:

sudo pkill -f kubelite
sudo pkill -f containerd

After that, either restart cleanly or reset the cluster. Do not assume the cluster is healthy just because the processes disappeared.

Common Pitfalls

The most common mistake is using microk8s reset when the real goal was only to stop the cluster temporarily. Another is killing individual processes first and only later checking the snap-managed service state, which makes diagnosis harder. Teams also sometimes remove the snap and then wonder why workloads are gone, because uninstall is more destructive than stop. A final issue is forgetting that MicroK8s is a snap-managed package, so service behavior is tied to both Kubernetes commands and snap lifecycle commands.

Summary

• Use microk8s stop to halt the cluster temporarily.
• Use sudo snap stop microk8s when you need to control the snap service directly.
• Use microk8s reset to wipe cluster state and start fresh.
• Use sudo snap remove microk8s to uninstall MicroK8s completely.
• Manual process killing should be a last resort, not the default shutdown method.