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

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

容器和微服务没有所谓边界问题，两种技术思想和解决业务场景各有侧重。
微服务作为一种当下流行的技术架构，主要解决原有架构中服务比较重、依赖性比较强，所需要承载服务的资源要求比较高，无法快速响应业务变化等问题。
容器解决底层物理资源、虚拟资源利用率不足、容灾备份跨集群保障等方面问题。
当微服务架构越来越成熟后，容器作为微服务载体能够提升微服务架构的稳定、高可用、数据安全以及快速响应变化等诉求。所以微服务和容器即可相辅相成又可独立使用。

两个层面的事情，容器云是资源层、网络层、存储层，当然主要还是资源层的事情。微服务是应用层面的解决方案，应用服务、业务能力，提供一种架构。
最近经常把微服务与容器合并到一起说，主要是微服务提供应用服务层面的解耦，容器云提供资源层面的解耦，两个珠联璧合。但是独立使用的，依然不存在缺陷和问题，微服务可以部署在物理机、虚拟机上也可以运行的很好，容器中也可以运行单体应用。所以二者没有依赖。
那二者的集合呢，其实也不会有问题，使用容器云，不管是多k8s集群，还是单k8s集群，都是提供一个资源、网络、存储的底层平台，微服务是运行其上的，自然需要考虑网络模式、存储方式，但这种考虑不是微服务与容器云的边界，因为微服务部署在哪儿都需要考虑网络、资源和存储的。
所以微服务与容器云不同层面的东西，理论上是不会有边界一说的。

微服务是重构业务的方法吧，而容器云是承载微服务的一种更好的方法。同样都是为了更好的为业务服务的手段。