引领ML发展的迁移学习，究竟在迁移什么？

或者我们干脆组一个全是唯一本地地址的网络，然后手动在每个节点上做路由。这实现起来非常容易，而且地址分配基本上就是 "随便选一个数字就可以了"。可能还需要设计一个子集，这样节点到节点的路由才会更有效率，但这都是不太复杂的东西。

有个麻烦是云服务商喜欢介入到网络的基础部分。所以IPAM模块要保持可插拔性(在上文所提到工作流模型之内)，这样我们就可以做一些事情，比如向AWS解释流量是如何转发的。不过，使用IPv6可能就无法在GCP上运行了。

不管怎么说，有许多备选的方案来做这部分的设计。就其根本而言，我只想在节点之间使用IPv6和配置一些基本的、简单的路由就可以了。这样就可以在接近零配置的情况下，解决Pod之间的连接问题，因为IPv6是有足够大的地址空间，我们选一些随机数字就能完事。

如果你有更复杂的连接需求，你就把这些作为额外的网络接口和我设计的简单、可预测的IPv6路由接上。需要保证节点间的通信安全?引入wireguard隧道，添加路由，通过wireguard隧道推送节点IP，完事。编排系统不需要知道这些细枝末节，除了可能会在节点生命周期管理中添加一个小小的控制循环，这样在隧道建立好之后，才让节点处于就绪状态。

好了，Pod之间的互联互通，Pod和外部网络的连接，这两个问题都解决了。考虑到现在只有IPv6，我们如何处理流入集群的IPv4流量呢?

首先，我们规定IPv4只适用于Pod和Internet连通的这种情况。在集群内必须强制使用IPv6。

我们可以用几种方法来应对这个限制。简单来说，我们可以让每个节点封装IPv4流量，为Pod预留一小块符合RFC 1918规范的地址空间(所有节点上预留的地址都从属于这个空间)。这样就可以让它们到达IPv4互联网，但这都是每个节点的静态配置，根本不需要集群可见。你甚至可以将IPv4的东西完全隐藏在控制平面中，这只是每台机器运行时的一个实现细节。

我们也可以用NAT64和CLAT来找点乐子：让整个网络只用IPv6，但用CLAT来欺骗Pods，让它们以为自己有IPv4连接。然后在Pod内进行 IPv4到IPv6的地址翻译，并将流量发送到NAT64网关。可以是每台机器的NAT64，也可以是集群内的部署的。如果你需要处理大量的NAT64流量，甚至可以用一个集群外部类似CGNAT这样的东西。在这一点上，CLAT和NAT64已经有很好的应用：你的手机可能正是通过这样的方式来让你获得IPv4地址接入互联网。

我可能会从简单的IPv4伪装开始(第一种方案)，因为所需的配置量极少，都可以由每台机器在本地处理，不会有任何交叉影响，让我们更容易着手实现。另外，后期改起来也很方便，因为在Pod看来都是一样的，而且我们也不希望通过一个网络插件来处理任何东西。

到这我们已经处理了出站方面的问题，我们有双栈上网。接下来怎么处理入站端呢?负载均衡器。不考虑把它构建在核心编排系统中。编排系统应该专注于一件事：如果一个数据包的目的IP是Pod IP，就把这个数据包交付给Pod。

正好，这应该主要适合公有云的场景。厂商们也倾向于这样的模型，这样就可以把他们的负载均衡器产品卖给你了。好吧，你赢了，姑且先采取这样的设计模型。不过我想要一个控制循环来控制负载均衡器，并将其与IPAM集成，这样VPC就能明白如何将数据包路由到Pod IP。

这忽略了由物理机搭建集群的场景。但这也不是一件坏事，因为没有一个放之四海而皆准的负载均衡器。如果我试图给你一个负载均衡器，但它没有完全按照你预想的工作。这说不定还会让你抓狂，一气之下装起了Istio，这时我所讨论到降低复杂性都是无用功了。

让负载均衡器集中精力把一件事做好：如果要把数据包转发给Pod，那就把数据包转发给Pod。在遵循这一原则的前提下，你可以基于LVS、Nginx、无状态、云厂商负载均衡服务、F5等来构建负载均衡器，你可以自由发挥。这里也许可以考虑提供几个“默认”实现。对于负载均衡器这部分，我确实有很多想法，也许我设计的方案就挺合适。这里的关键是编排系统对负载均衡器如何实现毫不关心，只要能把数据包转发到Pod上。

我没有触及IPv4 ingress的问题，主要是我认为这是负载均衡器该做的事情，让它们各自用最合适的方式来解决问题。像Nginx这样的代理型负载均衡器，只需要通过IPv6转发后端就可以了，没什么问题。无状态的负载均衡器可以很容易地将IPv4地址转换成IPv6，其间有个转换标准。源地址为::fffff:1.2.3.4数据包到达Pod时，Pod可以将其转回IPv4。或者干脆将其视为IPv6直接处理，这样的处理方式就假定网络中的地址都是IPv6。如果使用了无状态翻译方式，出站的时候需要有状态的跟踪机制，来映射回IPv4。但这也比原先在IPv4下采取的层层封装方式来得好。从节点的视角来看，这完全可以通过一条额外的::fffff:0000:0000/96的路由来处理。

（编辑：伊春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!