Kubernetes：Flomesh 服务网格与多集群通信

2022-12-16
北京
本文字数：1764 字
阅读完需：约 6 分钟

Kubernetes 成功普及了容器集群的概念。许多用户已经在多个集群中部署应用，组织需要运行多个 Kubernetes 集群可能来自以下原因（并非详尽列表）：

位置
延迟（尽可能在靠近客户的地方运行应用程序）
管辖权（例如，要求将用户数据保存在国内）
数据引力（例如，数据存在于一个供应商）。
隔离性
环境（例如，开发、测试、预发布、生产等）
性能隔离（团队之间希望互不影响）
安全隔离（敏感数据或不被信任的代码）
组织隔离（团队有不同的管理领域）。
成本隔离（团队希望得到不同的账单）
可靠性
爆炸半径（一个集群中的基础设施或应用问题不会使整个系统崩溃）
基础设施的多样性（底层区域、地区或供应商的故障不会导致整个系统瘫痪）。
规模（应用程序太大，无法在单个集群中安装）。
升级范围（为你的应用程序的某些部分升级基础设施，但不是全部；避免需要在原地进行集群升级）。

目前还没有标准的方法来连接甚至考虑超出单一集群边界的 Kubernetes Service，Kubernetes Multicluster SIG 已经提出了提案 KEP-1645，以便跨多个集群扩展 Kubernetes Service 概念。

Flomesh 一直在努力解决多集群通信的挑战，将南北向流量管理能力整合到兼容 SMI 的服务网格 osm-edge 中，并回馈社区。

上一篇 Kubernetes 跨集群流量调度实战，我们对 FSM 进行了简单的介绍并演示其使用方法。我们将探索 FSM 多集群支持的动机、目标、架构、组件，以及它如何与成熟的、轻量级的、兼容 SMI 并适用于云和边缘的服务网格 osm-edge 集成。

Flomesh 服务网格

FSM 是来自 Flomesh 的开源产品，用于 Kubernetes 南北向流量、网关 API 控制器和多集群管理。FSM 以可编程代理 Pipy 为核心，提供 Ingress 控制器、Gateway API 控制器、负载均衡器、跨集群服务注册发现等。

动机

在为社区、商业客户和企业提供咨询和支持期间，我们看到了大量需求和期望（有些在文章开头提到的），关于他们为什么要将部署拆分到多个集群中，同时保持在这些集群中运行的工作负载的相互依赖性。目前，集群是一个明显边界，服务对于远端 K8s 消费者来说是不透明的，否则他们可能会使用元数据（例如端点拓扑）来更好地引导流量。用户可能希望使用跨集群分布的服务来支持故障转移或在集群迁移期间提供临时的支持，然而，这都需要当今非常重的定制解决方案。

Flomesh 团队旨在通过为这些问题提供解决方案来帮助社区。

目标

定义一个最小的 API 来支持跨集群的服务发现和消费。
使用另一个集群中的服务。
将部署在多个集群中的服务作为单个服务使用。
当一个服务被另一个集群消费时，它的行为应该是可预测的，并且与它在集群中的消费方式一致。
允许在多集群环境中进行灰度发布。
提供一个独立的实现，可以在不与任何产品和/或解决方案耦合的情况下使用。
与 osm-edge 服务网格的透明集成，适用于希望通过服务网格功能获得多集群支持的用户。
完全开源，欢迎社区参与贡献。

架构

控制平面

osm-edge 集成 (纳管集群)

FSM 为集群连接器提供了一套 Kubernetes 自定义资源（CRD），并使用 KEP-1645 用于导出和导入服务的 ServiceExport 和 ServiceImport API。

FSM 多集群支持已经处于 alpha 阶段，欢迎从 FSM Github 下载尝试。

总结

Kubernetes 不再局限于单一边界，拥有多个 Kubernetes 集群的场景变得非常普遍，且没有一种典型或标准的方式来连接多集群并提供透明的方式来跨边界访问服务。Kubernetes Multicluster SIG 正在研究提案，以提供一组可以由供应商实现的通用 API，并为 k8s 用户提供一致的方式来访问内部或外集群的服务。

在后续的文章中，我们会进一步介绍 FSM 更多场景的使用，以及 FSM 能力的黑魔法。