Skip to content
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

Closed
afbjorklund opened this issue Apr 10, 2021 · 4 comments
Closed

Remove docker assumptions from minikube installation #11059

afbjorklund opened this issue Apr 10, 2021 · 4 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@afbjorklund
Copy link
Collaborator

afbjorklund commented Apr 10, 2021

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/

[...] We’re talking about two different environments here, and that’s creating confusion. [...]

[...] the Docker installation you’re using in development is unrelated to the Docker runtime inside your Kubernetes cluster. [...]

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 the minikube 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.

--driver=docker
--driver=podman

Same goes for the "containerd" container runtime, it could need some better integration (especially buildkitd)

--container-runtime=docker
--container-runtime=containerd
@afbjorklund afbjorklund added the triage/discuss Items for discussion label Apr 10, 2021
@afbjorklund
Copy link
Collaborator Author

afbjorklund commented Apr 10, 2021

The dockershim will be removed in Kubernetes 1.23: https://kubernetes.io/blog/2020/12/02/dockershim-faq/

This means that for the newer versions, we need to install and start cri-dockerd to provide the CRI socket.

* https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/

* https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/

Added as #12099

@spowelljr spowelljr added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 21, 2021
@medyagh
Copy link
Member

medyagh commented May 5, 2021

how about intergration test in GH Action without any Docker at all to ensure minikube can run without any docker at all...

@sharifelgamal sharifelgamal added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed triage/discuss Items for discussion labels May 5, 2021
@sharifelgamal sharifelgamal added priority/backlog Higher priority than priority/awaiting-more-evidence. and removed priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels Jun 14, 2021
@k8s-triage-robot
Copy link

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-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 31, 2021
@k8s-triage-robot
Copy link

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:

  • 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 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 rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Nov 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

No branches or pull requests

6 participants