Kubernetes 1.3.5 breaks cni config with docker
hanikesn opened this issue · 11 comments
Kubernetes version:
1.3.5
Environment:
- Cloud provider or hardware configuration: AWS
- OS : Debian 8
- Kernel : 3.16.0-4-amd64
- Install tools: custom puppet module
- Calico networking
What happened:
After upgrading the kublet to 1.3.5 the cni plugin tries to setup the lo network using cni, but can't find a corresponding plugin.
I0816 14:09:57.662326 18493 cni.go:226] Got netns path /proc/19285/ns/net
I0816 14:09:57.662344 18493 cni.go:227] Using netns path default
I0816 14:09:57.662358 18493 cni.go:198] About to run with conf.Network.Type=loopback
E0816 14:09:57.662387 18493 cni.go:201] Error adding network: could not find "." plugin
E0816 14:09:57.662399 18493 cni.go:152] Error while adding to cni lo network: could not find "." plugin
What you expected to happen:
The lo network is already configured using docker, so there's nothing to do.
cc @euank
Installing the default cni plugins from https://github.com/containernetworking/cni/releases into /opt/cni/bin/ fixed the issue. I still consider this to be a BC breaking bug.
Yeah, we need another update of CNI plugin binaries and corresponding update to Salt in cluster/saltbase/salt/cni/init.sls.
Or, if provisioning yourself, we should document the minimum required CNI plugin version somewhere.
Yeah, if this isn't documented somewhere already in the k8s docs then it should be.
I think we should be able to document and rely on a minimum cni version and set of plugins just to have a sane support matrix, but if we need to work around this (e.g. if our minimum supported version doesn't include lo) it's easy to make this work with a short patch. https://github.com/kubernetes/kubernetes/compare/master...euank:cni-lo-nondocker?expand=1
I'd definitely prefer just being able to count on a sane cni version though.
Can this be closed since 1.4.0 updated the base CNI version?
@bboreham The lack of documentation still seems to be the main issue. And people having their own provisioning will hit this bug, so I vote for leaving it open till the documentation is fixed or we have a separate issue for that.
I think the minimum CNI version required is 0.2.0, since that's when the lo plugin was added.
Have included this with kubernetes/website#1516
I also want to reference #25062 which I think is the first place this requirement came from.
I think @hanikesn solution is the only possible solution to make cni work with Kubernetes v1.3.6
seems like this issue can be closed, right?
/assign /close