本Topic是红帽的两位软件工程师。笔者按照自己的理解和这两位同事的探讨，对演讲内容进行解读(注解仅供参考,OCP是红帽OpenShift Container Platform的简称)。

OCP3中，每个pod只能有一个IP地址，OCP4可以配置多个(有了CNI)。不同service之间的pod内部通讯，通过service访问。如果pod要访问外部网络，需要通过NAT的方式，用node的ip出去。如果OCP内部的service要访问外部应用，可以配置service endpoint(为外部的应用在OCP集群配置service)。

但是跨K8S集群的Pod是无法直接通讯的。如果K8S部署在异构云上，更是如此。

但随着红有云的发展，将K8S部署到异构环境中的需求越来越多。这时候不同pod之间如何通讯呢？

这种场景的应用包括但不限于下图：

我们需要考虑以上几个问题。

两个K8S集群pod之间要通讯，需要考虑两个集群的统一调度、连通，除此之外，还要考虑跨集群的服务注册发现和network policy等。

解决这个问题需要推动开源项目来完成。上面的几个开源项目，红帽都参与了。Submariner是解决这个问题的关键。

Submariner有两个组件：Engine(运行在网关节点)和Route Agent(运行通过daemonset的方式运行在所有的K8S节点上)。

Submariner是一个开源项目，如上图所示，是为了解决跨K8S集群的pod互通的。上面的两个集群：东群和西群。没有Submariner的情况下，pod跨K8S无法互通。有了Submariner之后，在东群和西群中各推举一个网关节点。这个两个网关节点负责与broker cluster通讯，最终实现跨集群的pod通讯。如果网关节点除了问题，K8S集群可以再推举出一个。

网关节点的选举方式见上图。

网关节点的高可用见上图。

目前工作方式和前提条件。

通讯方式见上图：PodA在东群，podB在西群。网络包精通网关节点传到路由器和公有云，然后传到西群的网关节点最终到达podB。需要注意上图的虚线颜色，集群内部不加密，跨集群加密。

Submariner目前尚处于Pre-Alpha阶段。后面还会增加新的功能。

那么，Submariner和联邦集群是否冲突呢？

答案是不冲突。Submariner解决的是pod跨K8S集群之间的通讯，而联邦集群解决的是跨集群的管理和调度，并不能解决pod在K8S 集群之间的通讯。因此，后续Submariner和联邦集群V2会一起工作，相互补充。