没有一个开源项目撑得住公有云的数据规模

其实就是 gossip 吧？感觉很多问题想得有点粗糙了。就拿楼主提到的心跳机制来说，这个就决定了这个系统没法 scale up 。一个节点要给所有节点定时发心跳，节点数量为 n，网络中一段时间内的消息数量是 O(n^2)的，规模一大网络压力就上来了，很可怕。其他的，诸如一致性问题就不说了。

@labulaka521 gh 同名有邮箱。或者来个电报群吧。

@labulaka521 可以来交流呀。

@jeffreystoke 我不是专业的。楼主的建议也对我有启发，并没有冒犯的说法：）。

@jeffreystoke 仔细看了下楼主的想法。我们最终想实现的可能有点不一样？

@jeffreystoke 嗯。楼主看起来对 k8s 比较了解。对于容器多网络的确比较想基于 multus 。但对于 underlay，项目本身也考虑整合非专线下的互联，其实就是控制面利用 gossip 协议传播 peer 间的网络信息，数据面利用内核支持的一些网络特性（ ipsec，wireguard，gre 等等）来实现，这样使用会比较方便，这是目前我在做的。这样一说其实目前有一种实现了一个 功能不太多的 p2p vpn 的感觉。我感觉这个跟楼主的想法有点类似，就来回复啦：）。

@jeffreystoke 想做的是一个 overlay network tool 。在公有云、私有云互联的基础上，能方便创建和管理多个虚拟的二层网络（类似 flannel 已经砍掉的的 multiple network ？），并且能够将容器、虚拟机加入到某个虚拟的网络上。所以互联只是第一步？看了一下 tailscale，目前项目的样子确实比较像 tailscale （可能是因为还是 poc，在 early development 的阶段吧）。想得很多，但我觉得无论是 concept，还是最终设计，都还有不少工作要做。

有类似的想法。正在尝试做类似的开源项目。 不过目前在 Just for fun 的阶段：）

mark 。也在看这本，学 TLA+。

个人感觉解法是，将状态放到专门的地方（ redis 等等），或自己设计一个增量同步的协议，自己保证最终一致性，后者感觉会比较多坑。memberlist 基于那篇 SWIM 的论文，其 boardcast 是用于少量事件的同步的，最初应该就不是设计用来广播大量数据的。

这样仔细一想，CRD 定义 model，apiserver 提供 restful 的存储接口，确实和数据库很相似。Operator 和 Controller 某种意义上就是在上面构建的应用。确实很有意思。

要求几年经验呀。

华为业务方向来说是比 People 好的。People 要看做哪块了。如果 People 只是普通的后端业务开发，那么技术成长是很差的，基础技术组则稍好一些。Cloud BU 可能稍好，但还是要看做的事情。听楼上的说华为 Cloud BU 风气差。
其实说白了，两个选择其实可能都不太好，挺难选的。

这应该是常识来着。为什么还要提醒呢。

再来支持。帮顶。

看了下楼主需求，应该都跑不了。学生机也只适合拿来跑跑个人博客。

支持。只可惜经验达不到要求。

自己用 ansible 写了做了一套部署工具