We are several folks (organizations and companies) that are working on Mesos Networking (which is awesome btw!)
I revived our ticket on per-container IP and I think we have the critical mass to start a *community meeting* on this :) I suggest we fill in more thoughts and ideas in the suggested architecture doc [1] and join a hangout *Tuesday 10AM PST*. Thoughts or objections? If not, I will be following up with an invite. Cheers, Niklas [1] https://docs.google.com/document/d/17mXtAmdAXcNBwp_JfrxmZcQrs7EO6ancSbejrqjLQ0g/edit On 11 May 2015 at 12:15, James DeFelice <[email protected]> wrote: > Kubernetes services v2 leverages a "portal net", from which IPs are > allocated for service instances. It would be great if the kubernetes-mesos > framework could allocate this network (currently expressed as a CIDR range) > from an offer. > > On Wed, Apr 29, 2015 at 11:49 AM, Ian Downes <[email protected]> > wrote: > > > This is something we're interested in exploring as well. Can we ensure > the > > design thinking get circulated to the community early on? I agree there > > will be many different requirements and it would be helpful to understand > > those from the onset. > > > > Ian > > > > On Tue, Apr 28, 2015 at 5:48 PM, Christos Kozyrakis < > > [email protected]> > > wrote: > > > > > Hi Joe, > > > > > > 100% agreed, we need something like this. > > > > > > We are working on an open-source design for networking for Mesos with > > > Project Calico (using project calico and in collaboration with > > Metaswitch) > > > but you can imagine also using OVS or your favorite vSwitch or vRouter. > > > It's difficult to imagine that there will be a one size fits all here > but > > > we should be able to reuse most logic regardless of the network > > > virtualization scheme used. > > > > > > We can exchange design notes if you want. From the point of view of the > > > Mesos community, the most important part to get right is to identify > what > > > are the new requirements for the Mesos master or slave code to support > > such > > > efforts. From our point of view, the major missing piece is some way to > > > support express pools of IPs as globally managed resources and connect > > them > > > to offers given to frameworks. Niklas is looking into the design > details > > of > > > that. > > > > > > Cheers > > > Christos > > > > > > > > > > > > > > > On Tue, Apr 28, 2015 at 5:18 PM, Joe Stein <[email protected]> > wrote: > > > > > > > Hi Mesos community, there is a lot of work in progress around virtual > > > > routers and custom allocator(s) to enable for every task to have one > or > > > > more specific, or non-specific IP(v4/v6) addresses assigned to it > (long > > > > lived for the life of that task on that cluster). The goal is for > every > > > > mesos task to get a leased IP that it will _ALWAYS_ have. This means > we > > > can > > > > use standard ports :) since every task will be bound to its own IP. > > > > > > > > Essentially we are working on a control plane for the virtual router > > (on > > > > each slave) and a data plane for task to get the IP and a custom > > > allocator > > > > to manage it. This work is being done by a bunch of folks/companies > as > > > Open > > > > Source under Cisco Cloud. > > > > > > > > So, I wanted to send a quick note (before we circulate the design we > > have > > > > been working on and get coding) if folks would find this interesting? > > > Have > > > > already done it? Would like to contribute and help? Any thing else? > > > > > > > > One thing also (which came out of this collaboration but not just for > > > this > > > > feature) is that we are thinking of creating some callback mechanism > > for > > > > the allocator module so we can write in Python or Go the business > logic > > > for > > > > allocator modules. Not sure if folks have done this or are interested > > in > > > > such a thing or have thought about it at all. > > > > > > > > Thanks! > > > > > > > > ~ Joe Stein > > > > - - - - - - - - - - - - - - - - - > > > > > > > > http://www.stealth.ly > > > > - - - - - - - - - - - - - - - - - > > > > > > > > > > > > > -- > James DeFelice > 585.241.9488 (voice) > 650.649.6071 (fax) >
