Introduction

If you try to stop tutorial containers manually after running a Minikube or Kubernetes exercise, they often come right back. That is expected behavior. Kubernetes controllers are designed to keep the declared number of Pods running, so stopping individual containers is usually the wrong level of control.

Why the Containers Restart

Kubernetes does not manage containers one by one the way plain Docker workflows do. It manages higher-level resources such as:

• Deployments
• ReplicaSets
• StatefulSets
• DaemonSets
• Pods

If a Deployment says "run 10 replicas," Kubernetes notices when one container stops and immediately creates a replacement to restore the desired state.

That is why docker stop or a runtime-level stop inside a Kubernetes-managed environment often looks ineffective.

First Inspect What Is Running

Start by checking which resources are controlling the Pods.

1kubectl get pods -A
2kubectl get deployments -A
3kubectl get replicasets -A
4kubectl get daemonsets -A

If the tutorial created a Deployment with 10 replicas, that is the object you need to change, not the container process directly.

Stop the Workload by Scaling It Down

If the Pods come from a Deployment, scale it to zero.

kubectl scale deployment my-app --replicas=0

This tells Kubernetes that the desired state is now zero Pods, so the controller stops recreating them.

You can confirm the result with:

kubectl get pods

This is the normal Kubernetes way to "stop" a scalable stateless workload temporarily.

Delete the Controller If You Are Done with the Tutorial

If you do not need the workload anymore, delete the Deployment instead of fighting the containers.

kubectl delete deployment my-app

If the Pods came from another controller type, delete that controller instead.

Examples:

kubectl delete daemonset my-daemon
kubectl delete statefulset my-db

Deleting the controller removes the source of reconciliation.

If You Only Delete Pods, They May Return

This is a common surprise:

kubectl delete pod my-app-abc123

The Pod disappears, then a new one appears. That is normal if a Deployment or ReplicaSet still owns the workload.

Deleting a Pod removes one instance. It does not change the desired state stored in the controller.

Minikube Stop Is Different

If your goal is to stop the entire local Kubernetes cluster, stop Minikube itself.

minikube stop

This shuts down the local cluster VM or runtime environment. When Minikube starts again, workloads may still exist because the cluster state was only paused, not deleted.

If you want a full cleanup:

minikube delete

That removes the cluster entirely.

Docker Commands Can Be Misleading Here

Inside Minikube, containers may be managed by containerd or Docker depending on configuration, but Kubernetes is still the orchestrator. So even if you find the runtime container and stop it manually, Kubernetes may recreate it.

The right mental model is:

• Docker or containerd runs containers
• Kubernetes decides which containers should exist

When the orchestrator and the runtime disagree, the orchestrator wins.

Check the Namespace Too

Tutorial resources are not always in the default namespace. If you do not see the objects you expect, inspect all namespaces.

kubectl get all -A

Then scale or delete the correct resource in the correct namespace:

kubectl scale deployment my-app -n tutorial --replicas=0

Common Pitfalls

• Trying to stop individual containers instead of the Kubernetes resource that owns them.
• Deleting Pods and being surprised when the controller recreates them.
• Forgetting to check which Deployment, ReplicaSet, or DaemonSet created the workload.
• Using minikube stop when the real goal is to remove tutorial resources permanently.
• Looking only in the default namespace when the tutorial created objects elsewhere.

Summary

• Kubernetes keeps the desired number of Pods running, so manually stopping a container usually does not solve the problem.
• Find the owning controller with kubectl get commands.
• Scale the workload to zero or delete the controller if you want the Pods gone.
• Use minikube stop to pause the whole cluster and minikube delete to remove it entirely.
• Manage Kubernetes workloads at the controller level, not at the container level.