-
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
Do not include the default CNI config by default #3441
Do not include the default CNI config by default #3441
Conversation
Can one of the admins verify this patch? |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: brb If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
b12f6ee
to
89f2607
Compare
@minikube-bot OK to test |
The CI failures seem to be unrelated to my changes. |
89f2607
to
1252ad9
Compare
Previously, minikube has been shipped with the default CNI config (/etc/cni/net.d/k8s.conf) in its rootfs. This complicated a lot when using a custom CNI plugin, as the default config was picked by kubelet before the custom CNI plugin has installed its own CNI config. So, the end result was that some Pods were attached to a network defined in the default config, and some got managed by the custom plugin. This commit introduces the flag "--enable-default-cni" to "minikube start" to trigger the provisioning of the default CNI config. Signed-off-by: Martynas Pumputis <m@lambda.lt>
As per kubernetes/kubernetes#32151, kubelet doesn't search for CNI configs in /usr/libexec/kubernetes/kubelet-plugins/net/exec/ by default anymore. Signed-off-by: Martynas Pumputis <m@lambda.lt>
Fixed the merge conflicts. |
Since minikube v0.33.0 the default CNI config is not being provisioned by default (kubernetes/minikube#3441). Therefore, we need to pass `--enable-default-cni` when starting minikube with an alternative container runtime. This commit
Since minikube v0.33.0 the default CNI config is not being provisioned by default (kubernetes/minikube#3441). Therefore, we need to pass `--enable-default-cni` when starting minikube.
Since minikube v0.33.0 the default CNI config is not being provisioned by default (kubernetes/minikube#3441). Therefore, we need to pass `--enable-default-cni` when starting minikube.
Since minikube v0.33.0 the default CNI config is not being provisioned by default (kubernetes/minikube#3441). Therefore, we need to pass `--enable-default-cni` when starting minikube.
Since minikube v0.33.0 the default CNI config is not being provisioned by default (kubernetes/minikube#3441). Therefore, we need to pass `--enable-default-cni` when starting minikube.
Previously, minikube has been shipped with the default CNI config (
/etc/cni/net.d/k8s.conf
) in its rootfs. This complicated a lot when using a custom CNI plugin, as the default config was picked by kubelet before the custom CNI plugin has installed its own CNI config. So, the end result was that some Pods were attached to a network defined in the default config, and some got managed by the custom plugin.This PR:
--enable-default-cni
tominikube start
to trigger the provisioning of the default CNI config./usr/libexec/kubernetes/kubelet-plugins/net/exec/k8s.conf
.If this PR gets merged, https://kubernetes.io/docs/setup/minikube/#alternative-container-runtimes needs to be updated as well.
Fixes #2907.