1.3.6 is slightly different but the result should be the same -
The logic in the code seems contrary to the kubenet docs - 'Kubenet plugin:
implements basic cbr0 using the bridge and host-local CNI plugins
<http://kubernetes.io/docs/admin/network-plugins/>' i.e. 'cbr0 exists when
cni is being used' but perhaps I'm just misinterpreting something.
On Tuesday, September 20, 2016 at 3:06:33 AM UTC+9, Amey Deshpande wrote:
> From what I can tell, the use of kubenet and cbr0 is mutually exclusive:
> When cbr0 is being used, Docker daemon is restarted with "--bridge=cbr0"
> on commandline to use the correct bridge device. However, when cni is
> being used, I do not see any evidence of deleting docker0 in the code.
> I'll let K8s/GKE networking experts comment on it.
> On Mon, Sep 19, 2016 at 9:52 AM, Wil Reichert <wil.re...@gmail.com
>> I've got a GKE cluster that was create with a command something like
>> # gcloud container clusters create "cluster" --machine-type
>>> "n1-standard-1" --image-type=GCI --num-nodes "3" --network "default"
>> The resulting vm image os-release file is
>>> NAME="Google Container-VM Image"
>>> PRETTY_NAME="Google Container-VM Image"
>> GKE is configured with kubenet & a cbr0 bridge. Docker bridge networking
>> is setup to use the docker0 bridge. Since the docker0 bridge does not exist
>> any attempt by docker to use this network fails like:
>> # docker run --rm -i -t busybox sh
>> docker: Error response from daemon: failed to create endpoint
>>> pedantic_lalande on network bridge: adding interface vethdc5e518 to bridge
>>> docker0 failed: could not find bridge docker0: route ip+net: no such
>>> network interface.
>> Adding a --net=Host to the above run statement works fine. The primary
>> problem is docker does not accept the --net parameter for builds. The
>> relevant Docker issue <https://github.com/docker/docker/issues/10324>
>> has been open for a year & a half, a PR
>> <https://github.com/docker/docker/pull/20987> fix for 9 months.
>> My primary use case is running Docker builds on Jenkins slave pods which
>> is a complete no go with the above configuration.
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes user discussion and Q&A" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> To post to this group, send email to kubernet...@googlegroups.com
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.