TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Rudder: An etcd backed overlay network for containers

84 点作者 pquerna超过 10 年前

8 条评论

wmf超过 10 年前
I'm glad to see this since an easy overlay for Docker is badly needed. But ugh, userspace encapsulation. This would be a lot better if it used OVS + VXLAN.
评论 #8239255 未加载
derefr超过 10 年前
Would this allow you to mesh together containers in separate datacenters? Or mesh together, say, the containers on your home PC with containers in the cloud? I&#x27;m guessing not.<p>What I&#x27;m really excited for are the possibilities of docker containers with public-routable IPv6 addresses. It would move the world away from &quot;one host: many services on different arbitrary ports&quot;, and back to the &quot;one host: one service, possibly speaking a few protocols with ports being used for OSI-layer-5&#x2F;6 protocol discovery&quot; model of the 1970s (and eliminate the madness of SRV records, besides.)<p>Imagine if, say, bitcoind (which normally speaks &quot;JSON-RPC&quot; to clients -- a specific layer-6 encoding over HTTP) sat on &quot;bitcoind.host:80&quot; instead of &quot;host:8332&quot;. Suddenly, it&#x27;d be immediately clear to protocol clients (e.g. web browsers) which hosts they could or couldn&#x27;t speak to, based on the port alone! The whole redundancy between schema and port in URLs could go away: they&#x27;d be synonymous. And so on.
评论 #8240393 未加载
评论 #8240547 未加载
Oculus超过 10 年前
Only recently did I realize what a power house the team at CoreOS is. They&#x27;re building some really cool shit. I can spend hours on their blog just right-clicking and searching on Google. Definitely a good way to learn tons about distributed computing and that whole subject area.
MartinMond超过 10 年前
This is interesting, it&#x27;s pretty similar to <a href="http://tinc-vpn.org" rel="nofollow">http:&#x2F;&#x2F;tinc-vpn.org</a> which is a mesh VPN.
评论 #8240598 未加载
contingencies超过 10 年前
Sorry, what problem does this solve?<p><i>Things are not as easy on other cloud providers where a host cannot get an entire subnet to itself. Rudder aims to solve this problem by creating an overlay mesh network that provisions a subnet to each server.</i> ... is unclear.<p>What host for virtualized infrastructure needs an entire, fake, non-internet-routable subnet that it cannot provision itself?<p>I believe there&#x27;s a broken one size fits all network architectural assumption or provisioning methodology at the root of all this.<p>(Edit as reply to child as rate-limited: Sounds like I was right, and it&#x27;s docker&#x27;s fault. How is this not better solved with the standard approach of applying network namespaces and&#x2F;or unique interfaces to containers?)
评论 #8240333 未加载
vquemener超过 10 年前
FYI there&#x27;s already an open source software going by the name of Rudder : <a href="http://en.wikipedia.org/wiki/Rudder_(software)" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Rudder_(software)</a>
mrmondo超过 10 年前
&quot;... it has almost no affect on the bandwidth.&quot; - looking at those numbers it&#x27;s not the case at all, those numbers are really low to start with (as AWS isn&#x27;t exactly the fastest) but obviously this would be much more noticeable at the higher end of the scale when we&#x27;re talking about 100-200MB&#x2F;s transfer rates, not to mention nearly doubling the latency!
kapilvt超过 10 年前
also works great with lxc, i pushed a juju charm which automates the config for lxc <a href="http://bazaar.launchpad.net/~hazmat/charms/trusty/rudder/trunk/view/head:/readme.txt" rel="nofollow">http:&#x2F;&#x2F;bazaar.launchpad.net&#x2F;~hazmat&#x2F;charms&#x2F;trusty&#x2F;rudder&#x2F;tru...</a>