Docs: stop vs pause

[guettli]

What Happened?

I see that minikube containers in minikube consume ressources, so that my laptop fan makes noise.

At the moment I don't need minikube.

I look at

• https://minikube.sigs.k8s.io/docs/commands/stop/
• https://minikube.sigs.k8s.io/docs/commands/pause/

I have no clue what the difference between both commands.

It would be great, if the docs would explain the difference between both commands.

Attach the log file

.

Operating System

Ubuntu

Driver

Docker

[afbjorklund]

Stop kills the process, so that it has to be started up again.

Pause freezes the process, so that it can be resumed later.

[Aryan-Deshpande]

hey, I would like to work on this issue :)

[Aryan-Deshpande]

/assign

[Aryan-Deshpande]

Please let me know if any feedback, would love to learn or implement such suggestions.

[afbjorklund]

Note that if/when doing the "stop" command, it might also halt a virtual machine (if used)

The comments above applied to the "docker" driver, and doesn't affect the VM (if any)

e.g. the Docker Desktop VM is started and stopped, independent from minikube

Currently there is no way to suspend and resume VM, but that feature* might arrive later.

---

* here is the feature implemented for lima, which also uses a qemu driver:

• Implement suspend and resume of VM lima-vm/lima#598

The main issue is that the network connections get broken, when suspended.

It is the same feature as when hitting the "Pause" button in the VirtualBox GUI.

[Aryan-Deshpande]

So essentially when you mention "minikube stop", the underlying docker container that minikube runs on is halted.

[Aryan-Deshpande]

I have also noticed that when you use "minikube pause", its container on docker appears to be running. This means that only the cluster processes are halted/paused and not minikube itself.

[afbjorklund]

So essentially when you mention "minikube stop", the underlying docker container that minikube runs on is halted.

That is correct, or stopped (as in docker stop). This means that the actual process (systemd) inside, is killed.

I have also noticed that when you use "minikube pause", its container on docker appears to be running.

Right, in this scenario the kubernetes cluster containers' processes are all frozen. But the main process runs.

---

Things are a little different, when running a virtual machine instead of a container. Then it is halted with "stop", for real.

When the machine is started up again later, the whole VM needs to be booted again. And then processes are started.

For the platforms running Docker Desktop, that VM is handled with separate controls - minikube does not start/stop it.

This is similar to starting the machine with --no-kubernetes, when only the Linux system processes runs - no control plane

[afbjorklund]

For the platforms running Docker Desktop, that VM is handled with separate controls - minikube does not start/stop it.

Same comment applies to Podman Desktop, there the VM is controlled using the electron GUI or podman machine CLI.

[guettli]

@Aryan-Deshpande you said you want to work on the issue. I think it would be great if you could extend a docs a bit, so that the difference is easier to understand.

[Aryan-Deshpande]

@guettli sure that sounds good. Let me come back with more resources.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.