Open afbjorklund opened 3 years ago
@afbjorklund I'd like to work on this. /assign
@Aut0R3V : sure thing, please make a PR
Hey @Aut0R3V are you still working on this?
@afbjorklund is this still needed or we did that already ?
It's still the same blanket statement: https://minikube.sigs.k8s.io/docs/start/
All you need is Docker (or similarly compatible) container or a Virtual Machine environment, and Kubernetes is a single command away: minikube start
Container or virtual machine manager, such as: Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMWare
It doesn't say when you would use one over the other, and doesn't mention bare metal.
Will try to do a better grouping as part of the work for the Kubecon presentation.
And hopefully it can get a better graphic presentation later on, similar to #10353
Running Docker and Podman in a VM on Linux is a bit of an experiment now, but would be included same as "Docker Desktop".
That is, the overall setup is the same: 1) start a VM 2) Run engine on VM 3) Create node in engine on VM 4) Connect remote
It's not clear when you would prefer this "double isolation", over the regular setup of just running kubeadm on the actual VM ?
One reason would be to have the VM running in the background, to get a faster turnaround time by handling privileged containers.
But you could get a similar effect by having multiple VMs and doing suspend/resume on them, even if not handled by minikube yet.
And we still don't recommend running un-isolated on the laptop, the bare metal solution is supposed to have a dedicated node...
Traditional use cases:
1) Run the minikube OS in a VirtualBox VM (Virtualization)
This is the "traditional" approach, using the same virtualization "API" on all platforms and with a controlled distribution. For instance the setup that is being used in the Kubernetes course, https://www.edx.org/course/introduction-to-kubernetes
Cons: x86 only (need other hypervisor setup on ARM)
2) Run the ubuntu OS in a container on Docker (Containerization)
This is the "modern" approach, if you already have the Docker VM idling in the background but you don't want to manage it. Currently comes HighlyPreferred, and on Linux it would not even need a VM but run everything in a privileged container.
Cons: bad networking and limited control, for non-Linux
3) Run the none driver as root in a dedicated VM (Bare Metal)
This is a "lightweight" approach, that is being used for instance in a CI setup where you want to avoid nested virtualization. It also being used for the VM in the interactive Katacoda environment, https://kubernetes.io/docs/tutorials/hello-minikube/
Cons: terminal only (without extra setup, like tunneling)
I think it would also help if I finished the network diagrams: #4938
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
This is still probably something we want to do.
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
This is probably still something we want to do. Clearer documentation can only help.
Currently it is a bit unclear what you actually need:
This mixes containers and virtual machines etc.
We need to make some kind of distinction between local drivers Docker and Podman, and remote drivers Docker and Podman.
And try to explain how it is related to the hypervisors, Hyperkit, Hyper-V, KVM (Libvirt), Parallels, VMware and the
--vm=true
Beyond separating Docker Engine and Docker Desktop.