-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove docker assumptions from minikube installation #11059
Comments
The dockershim will be removed in Kubernetes 1.23: https://kubernetes.io/blog/2020/12/02/dockershim-faq/
Added as #12099 |
how about intergration test in GH Action without any Docker at all to ensure minikube can run without any docker at all... |
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:
You can:
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
Now that Docker is deprecated in Kubernetes (after 1.20), it should be the same in minikube.
Unfortunately this issue is not addressed upstream, and makes misleading statements:
https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
In minikube, these so called "two environments" are one and the same.
We should aim for using CRI for the runtime operations, and to use CNI for the networking
We should stop using
docker-env
etc, and instead use theminikube image
abstractions.docker image load
=>minikube image load
docker image build
=>minikube image build
The minikube user does not need to have a local Docker client installation, when using a VM.
Images should be called "container images", and be fully qualified (including "docker.io" where needed) (#11126)
The code base should not assume that there is a local Docker daemon running, to be queried (#8577)
Stop using libmachine legacy, and allow for choosing a different runtime when provisioning the machine. (#10883)
It is still perfectly legit to default to the "docker" driver, and to the "docker" container runtime (with cri-dockerd)
Other drivers such as "podman", need to first prove that they are a viable alternative before default is changed.
Same goes for the "containerd" container runtime, it could need some better integration (especially buildkitd)
The text was updated successfully, but these errors were encountered: