如何实现跨数百个K8s集群的管理
随着云原生进程的加快，传统大型业务应用系统也走上了微服务化之路。服务功能分解是应用微服务化的巨大挑战，对于大型应用系统来说更是如此。不仅如此，虽然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平台，将服务治理、应用监控、链路追踪等平台功能下沉到数据平面，解耦平台与业务功能。
平台的建立使得该行在应用无感知情况下提供灵活的服务治理和可观测能力，使业务开发人员更关注于业务开发，提升业务迭代速率，赋予开发人员更多创造性。
扫码加我微信，进群和大佬们零距离