3 ms·

I suggest you also look at GCE for network performance. It is something that the Google networking team has been working hard on and, because of the unique net

by jbeda 11y ago

I suggest you also look at GCE for network performance. It is something that the Google networking team has been working hard on and, because of the unique network fabric at Google, should scale to lots of VMs. Also, you can get equivalent "IP per container" using advanced routing with GCE. Flannel has a GCE specific back end where it inserts routes for each subnet assigned to each range. That will eliminate the extra level of encap. (Disclaimer: I started GCE but am no longer at Google.)

jsolson 11y ago
Hi Joe :) Conveniently, Amin Vahdat recently shared some content publicly about why it should scale to lots of VMs: https://www.youtube.com/watch?v=FaAZAII2x0w https://www.youtube.com/watch?v=FaAZAII2x0w (And, to others, disclaimer: I work on some bits of GCE networking at Google)
__monadic 11y ago
+1 to @jbeda, but let me offer some comments for the avoidance of possible confusion among potential Weave users. Weave aims to deliver a completely portable network. In other words if you create an application using Docker container and a Weave network, that should be able to run anywhere. And all this should be 'magically simple'. Once you have decided where to run your app, you may wish to trade portability for performance gains. For example by using GCE networking (or Azure, or ...). To date Weave achieved portability by sending some packets (inter host) through user space. This has big benefits in terms of ease of use eg. dealing with wide area networks, multicast and firewalls. But under load it performs worse than kernel-only models. We now have Weave "fast data path" - http://blog.weave.works/2015/06/12/weave-fast-datapath/ http://blog.weave.works/2015/06/12/weave-fast-datapath/ ... This aims to deliver close to line performance with portability and extreme ease of use. There may of course be yet more optimisations that end users wish to investigate. If you are willing to sacrifice some portability you could certainly make use of fast networks provided by a specific public cloud. We haven't yet seen a strong need to support this, but it is certainly a reasonable thing. (Disclaimer: I work at Weaveworks)

by jbeda 11y ago

jsolson 11y ago

Hi Joe :) Conveniently, Amin Vahdat recently shared some content publicly about why it should scale to lots of VMs: https://www.youtube.com/watch?v=FaAZAII2x0w https://www.youtube.com/watch?v=FaAZAII2x0w (And, to others, disclaimer: I work on some bits of GCE networking at Google)

__monadic 11y ago

+1 to @jbeda, but let me offer some comments for the avoidance of possible confusion among potential Weave users. Weave aims to deliver a completely portable network. In other words if you create an application using Docker container and a Weave network, that should be able to run anywhere. And all this should be 'magically simple'. Once you have decided where to run your app, you may wish to trade portability for performance gains. For example by using GCE networking (or Azure, or ...). To date Weave achieved portability by sending some packets (inter host) through user space. This has big benefits in terms of ease of use eg. dealing with wide area networks, multicast and firewalls. But under load it performs worse than kernel-only models. We now have Weave "fast data path" - http://blog.weave.works/2015/06/12/weave-fast-datapath/ http://blog.weave.works/2015/06/12/weave-fast-datapath/ ... This aims to deliver close to line performance with portability and extreme ease of use. There may of course be yet more optimisations that end users wish to investigate. If you are willing to sacrifice some portability you could certainly make use of fast networks provided by a specific public cloud. We haven't yet seen a strong need to support this, but it is certainly a reasonable thing. (Disclaimer: I work at Weaveworks)