写点什么

微服务与 Kubernetes 容器云的边界

  • 2022 年 7 月 12 日
  • 本文字数:1184 字

    阅读完需:约 4 分钟

微服务与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 名称:使用应用级注册中心。

发布于: 刚刚阅读数: 4
用户头像

InfoQ签约作者 2018.11.30 加入

热爱生活,收藏美好,专注技术,持续成长

评论

发布
暂无评论
微服务与Kubernetes容器云的边界_微服务_穿过生命散发芬芳_InfoQ写作社区