-
Notifications
You must be signed in to change notification settings - Fork 735
Auto detect CRI #1117
Copy link
Copy link
Closed
Labels
area/UXarea/ecosystemkind/featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.lifecycle/activeIndicates that an issue or PR is actively being worked on by a contributor.Indicates that an issue or PR is actively being worked on by a contributor.priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Milestone
Metadata
Metadata
Assignees
Labels
area/UXarea/ecosystemkind/featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.lifecycle/activeIndicates that an issue or PR is actively being worked on by a contributor.Indicates that an issue or PR is actively being worked on by a contributor.priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.Important over the long term, but may not be staffed and/or may need multiple releases to complete.
With CRIs different than Docker gaining more and more popularity, we need to improve the user experience of kubeadm by not having to supply
--cri-socketon every command if something different than Docker is used.Most of the other CRIs have well known default paths for Unix domain sockets, thus detecting the default installations of CRIs on the local machine should not be too difficult.
Currently kubeadm will fail if
--cri-socketis not specified and Docker is not installed on the system. But the bigger problem here is that, if--cri-socketis forgotten and Docker is installed, the wrong CRI could be used and the operation to succeed (like with kubeadm init)./area UX
/area ecosystem
/kind feature