Closed AurelienGasser closed 4 years ago
@AurelienGasser is there a reason you provide -network-plugin=cni ? docker runtime does not need a cni and comes with cni by default
@AurelienGasser I also noticed:
I0610 15:51:39.356574 2332048 api_server.go:136] control plane version: v1.16.6-beta.0
W
you are using a k8s version with upstream problems
https://github.com/kubernetes/kubernetes/issues/87424
maybe try a newer k8s verison?
@medyagh I provide --network-plugin=cni
to be able to use Calico.
I get the same error if I use either
--network-plugin=cni
or
--extra-config=kubelet.network-plugin=cni
or both.
With kubernetes v1.16.10
: no more control plane version
issue, but the main error is still here:
networkPlugin cni failed to set up pod "coredns-5644d7b6d9-45s55_kube-system" network: failed to set bridge addr: could not add IP address to "cni0": permission denied
hm... I have not tested the docker driver with CNI, could u plz try with KVM driver and see if u have same issue?
@medyagh No issue with the KVM driver (using --network-plugin=cni
)
ok thanks for confirming this , this is a bug and we should fix it !
could u plz confirm something else ? can you try docker driver with containerd runtime and see if it works with that ?
start --container-runtime=containerd
@medmedchiheb No error with containerd
thanks for confriming this, @AurelienGasser we will have to fix the CNI on docker-runtime on docker driver.
@AurelienGasser I am curious does this error happen in v1.12.0 ?
Hi @medyagh, the error persists in v1.12.0.
The TL;DR here is that if you specify --network-plugin=cni
, you need to provide a CNI for CoreDNS to come up successfully.
Please note that this flag is deprecated - but for some reason, we hide the deprecation notice in the logs instead of showing it to the user. The new equivalent is --cni=/path/to/cni.yaml
, or one of the other options:
--cni='': CNI plug-in to use. Valid options: auto, bridge, calico, cilium, flannel, kindnet, or path to a CNI manifest (default: auto)
I can verify that minikube start --cni=bridge --driver=docker
for instance does not create this issue.
Renaming the issue to capture the primary remaining issue.
Fixing the title because I was a bit in err here: the deprecated flag is actually --enable-default-cni, which should show a warning. --network-plugin isn't deprecated. That said, this could be unexpected behavior, so we should show a warning.
Steps to reproduce the issue:
Full output of failed command:
coredns
pods stay in theContainerCreating
state forever.Describe
coredns
pod:Full output of
minikube start
command used, if not already included:Optional: Full output of
minikube logs
command: