微服务与 Kubernetes 容器云的边界

微服务与 Kubernetes 容器云的边界的考量，其实就是思考微服务要不要跨多个 Kubernetes 集群的问题。比较理想的情况是微服务和 Kubernetes 完全对齐，也就是一套微服务运行在一套 Kubernetes 集群上。在这种情况下，微服务、配置中心+注册中心都在相同的 Kubernetes 集群中。当微服务指向配置中心时，写配置中心的 ServiceName 即可，网络 I/O 路径较短。否则，需要通过 Kubernetes Ingress 访问注册中心（如果容器云的 SDN 采用 overlay 模式），网络延迟将会较大。这在微服务数量较多、变更较频繁的时候更为明显。

1）配置+注册中心在一个 Kubernetes 集群上：如果 Kubernetes 集群的 SDN 用的是 underlay 网络，那么其他 Kubernetes 集群注册的时候，由于其 Pod IP 和宿主机 IP 在同一个网络平面，使得注册中心能够准确识别到 Pod 的 IP。这种方式的弊端体现在如下三个方面。

• 微服务去注册中心注册时，由于跨 Kubernetes 集群，网络 I/O 路径长。

• 数据中心网络需要打开 BGP（用到了类似 Caico 的 underlay SDN 方案）。

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

2）配置+注册中心不在一个 Kubernetes 集群上：如果 Kubernetes 集群的 SDN 方案用的是 overlay 网络，那么其他 Kubernetes 集群注册的时候，由于 Pod IP 和宿主机 IP 不在同一个网络平面，导致注册中心不能准确识别 Pod 的 IP，只能识别到 Pod 所在 Kubernetes 宿主机的 IP（Pod 以 SNAT 的方式访问集群外部）。

想要解决这个问题，可以考虑使用 Pod 的多网络平面，也就是给 Pod 增加第二个虚拟网卡，挂载数据中心到同一个网络平面的 IP。这种方式类似 macvlan、ipvlan，不用再单独配置 DNS，但弊端是当宿主机上启动的 macvlan 数量较多时，网卡性能会下降。

如果 Spring Cloud 的边界远大于一个 Kubernetes 边界，想让一套 Spring Cloud 分布在很多个 Kubernetes 集群时，最好把微服务配置中心和注册中心从 Kubernetes 集群中独立出来，放在虚拟机或者物理机上。这样做的好处是让这个配置+注册中心离所有 Kubernetes 集群网络都比较近。而且，在虚拟机或者物理机上部署配置+注册中心，当需要注册微服务的时候，也不必再经过类似 Ingress 的环节，性能也会得到提升。此外，我们可以针对独立的配置+注册中心做高可用或者容灾方案。

注册中心的整体选择思路主要从三个维度考量：应用是否跨开发语言，微服务的边界是否大于 Kubernetes 集群，以及是否限定应用的 Service 名称。

1）应用跨语言，微服务边界不大于一个 Kubernetes 集群，不限定应用的 Service 名称：使用 Kubernetes 平台的 etcd。

2）应用跨语言，微服务边界大于一个 Kubernetes 集群，不限定应用的 Service 名称：使用应用级注册中心，而且每种语言都需要设置自己的注册中心。

3）应用不跨开发语言，微服务不大于一个 Kubernetes 边界，不限定应用的 Service 名称：使用 Kubernetes 平台的 etcd。

4）应用不跨开发语言，微服务大于一个 Kubernetes 边界，不限定应用的 Service 名称：使用一个应用级注册中心。

5）限定应用的 Service 名称：使用应用级注册中心。