微服务与容器云的边界划分是什么？

SpringCloud与K8S的考量，其实就是SpringCloud要不要跨多个K8S集群的事情。
比较理想的情况是：SpringCloud和K8S完全对齐,也就是一套Spring Cloud运行在一套K8S集群。在这种情况下，微服务、配置中心、注册中心都在相同的K8S集群中。这样，微服务在指向配置中心的时候，写配置中心的SVC就可以，这样做的好处是网络I/O路径短。

但是，如果SpringCloud跨多个K8S，会有什么问题呢？

我们先看两种实现方式：

1.配置+注册中心在一个K8S集群上：如果K8S集群的SDN用的是underlay网络，那么其他K8S集群注册的时候，由于其pod ip和宿主机ip在同一个网络平面，注册中心能够准确识别pod的ip，问题也不大。但这时候，就需要手工配置跨K8S集群的dns了。例如pod hostname到pod id的解析。这种方式的弊端是：

（1）微服务去注册中心注册时，网路I/O路径长。需要先经过注册中心所在K8S的ingress，才能到pod（数据中心一般不让用nodeport）。

（2）数据中心网络需要打开BGP（因为用到了类似caloci的underlay sdn方案）

（3）underlay网络方案比较耗费数据中心的IP。

2.配置+注册中心在一个K8S集群上：如果K8S集群的SDN用的是overlay网络，那么其他K8S集群注册的时候，由于pod ip和宿主机ip不在同一个网络平面，注册中心不能够准确识别pod的ip，只能识别到pod所在K8S宿主机的IP（pod以SNAT的方式访问集群外部），这就有问题了。想要解决这个问题，可以考虑使用pod的多网络平面，也就是给pod增加第二个虚拟网卡，挂载数据中心同一个网络平面的IP。具体技术类似macvlan、ipvlan。这种方式不用再单独配置DNS。

这种方式的弊端是：

当宿主机的上启动的macvlan数量较多时，网卡性能会下降。

以上两种实现方式，各有优劣势。

https://mp.weixin.qq.com/s?__biz=MzAwMDc2NjQ4Nw==&;mid=2663502397&idx=1&sn=4bb5ef56a5651a147acdeb23664df2ec&chksm=81d69545b6a11c53c4b827e8c6d747c8b333ce2b660d7794de61a0a068e64ea1837d04fd248e&token=295652040&lang=zh_CN#rd