如何实现跨数百个 K8s 集群的管理

2022 年 8 月 23 日
北京
本文字数：2203 字
阅读完需：约 7 分钟

随着云原生进程的加快，传统大型业务应用系统也走上了微服务化之路。服务功能分解是应用微服务化的巨大挑战，对于大型应用系统来说更是如此。不仅如此，虽然 K8s 已经实现了很多功能的自动化，也支撑了越来越多的服务，但当我们深入研究这些服务之间的连接时，发现微服务还有很长的路要走。而以 Istio 等为代表的高级服务网格平台，无疑已经成为微服务目前面临诸多问题的最佳解决手段。

Intuit 实现数百个 K8s 集群的管理

Intuit 公司成立于 1983 年。它以个人财经软件为主要产品。2019 年 10 月入选《财富》杂志“2019 未来 50 强榜单”，排第 21 位。截至当年，Intuit 公司 4 大 BU、30 个业务部门运行了大约 160 个 K8s 集群，大约 5400 个名称空间，每天要进行 1300 次的部署。那么他是如何做到，今天我们做一个简单的讲解。

首先就是为什么 Intuit 公司要划分如此多的集群？他们希望在不同的业务部门之间实现隔离，并且各业务部门能够拥有自主权；其次，为了满足合规，将审计限定在一定的范围内；此外，还有一些传统老旧应用以及跨多个区域的托管服务，都需要独立的集群去托管。

举一个简单的例子，在上图中的三个集群中，API 网关恰好是一个多租户系统，它支持多个 BU，所以 Intuit 不希望该服务和任何其他服务部署在一起，所以这个 API 网关隔离在一个集群中。相反，产品信息服务和图书订购服务实际上由同一个 BU 维护，因此，二者形成了一个独立的集群。而支付服务是审计的一部分，Intuit 把它拆分出来放到一个单独的集群里。

从单控制平面到多控制平面

当然，实际生产中的 Intuit 服务集群要比这个示例复杂的多，也庞大的多。支撑 Intuit 不断探索的动力主要有六个需求，分别是“服务的唯一全局标识”、“点对点身份验证”、“端到端加密”、“没有单点故障”、“服务发现和管理的解耦”以及“Istio 和 K8s 配置的协同”。

我们还是通过示例中的三个集群来讲解 Intuit 走向 Admiral 管理集群的路程。

起先，为了实现多集群的统一管理，最容易想到的就是多集群使用一个共享的控制平面。所有 Envoy 代理都直接连接到这个共享控制平面。同时，通过共享一个根 CA 进行身份验证和加密，实现跨集群的服务认证。但这种方案不能识别部署在不同名称空间中的工作负载，也没有将命名方案与名称空间解耦。此外，Istio 配置点在一个与服务分离的控制平面中，这让开发人员很尴尬。最后，这种方案的最大致命问题就是不能避免单点失败。

于是，有了改进方案，多集群控制平面。每个集群都有独立的控制平面，各集群运行的所有代理都可以从其集群内部控制平面获取其配置。但这也会遇到一个问题，那就是如何同步管理所有这些不同集群之间的配置？比如，图书订购服务如何知道支付服务实际部署在另一个集群中？它如何通过路由到达该集群？虽然 Istio 中有这样的配置功能，也可以实现这一点，但必须通过人工编辑，无法实现自动化。

而且，这种方案并没有真正地将名称空间与服务发现解耦。好在这个方案通过多空平面确实消除了单点故障。综合评估这个方案，其优势是单个集群工作得更稳定，但是在需要多集群之间联动时，有些功能可能就需要更加复杂的配置署。

Admiral 如何实现多集群管理

那么，如何解决这第二种方案的联动不足，Intuit 的答案是 Admiral 。Admiral 为多集群 Istio 服务网格提供自动配置和服务发现功能，目前它在 Github 平台上 Istio-ecosystem 中，位列第一。虽然，Istio 拥有一套非常强大的多集群功能，但跨多个集群大规模管理配置对其来说仍然具有挑战性。

Admiral 对此配置拥有独特优势，并提供跨集群的自动配置和同步。Admiral 定义了两个自定义资源，即依赖关系和全局流量策略，它们用于在每个集群上为每个跨集群服务配置 ServiceEntries、VirtualServices 和 DestinationRules。这消除了开发人员和网格运营人员的工作复杂性。

最终，Intuit 基于 Admiral 结合多集群控制平面方案部署实现了更高级别、自动化的配置管理。在这个方案中，使用 Admiral 作为多个集群控制平面的“中介”，或者更确切的说作为各个集群控制平面的统一“控制器”，自动化将配置同步到所有集群中，使集群之间的服务能够相互通信。

Admiral 创建服务可以使用的全局唯一名称，设置到这些服务的路由，从而将名称空间与服务配置分离。它还支持对同一个服务命名多个名称，将某些端到端场景固定在指定的区域路由中。这使得跨集群迁移部署变得轻松。它所做的就是随时侦测这些集群，然后跟随着集群的发展而变化。

Admiral 本身并没有任何运行时状态。基本上，在这种方案中 Istio 管理的这些集群的所有状态实际上都下沉到每个集群本身。这意味着，如果 Admiral“消失”了，集群中所有网格的当前运行状态不会有任何变化。因此，它不会影响任何运行时部署。

Istio 服务网格在国内某银行的应用

尽管 Istio 技术能够解决如此复杂的业务问题，但是在国内落地的场景并不多，某城商行算是金融领域的先行者。为了落实“强后台，大中台，敏前台”技术战略，构建云原生技术体系，深入推进全行架构云化转型，持续进行应用服务化解耦，支撑产品快速迭代与低成本创新，某银行在灵雀云的支持下建立了完善的 Service Mesh 平台，将服务治理、应用监控、链路追踪等平台功能下沉到数据平面，解耦平台与业务功能。