本篇文章来自在线教育途径 VIPKID 在容器体系规划进程中的落地实践，从 VIPKID 的事务布景、事务挑战、选型进程、引进 Karmada 前后的比照以及收益等方面深入分析了 VIPKID 容器化改造进程。
本文作者：VIPKID 后端研发专家慈轶恒
01 事务布景
VIPKID 的事务覆盖数十个国家和地区，签约教师数量超越 8 万名，为全球 100 万学员供给教育服务，累计授课 1.5 亿节。为了更好的为教师和学员供给服务，相关运用会按地域就近布置，比方面向教师的服务会贴近教师地点的地域布置，面向学员的服务直接布置在学员侧。为此，VIPKID 从全球多个云供应商采购了数十个集群用于构建 VIPKID 内部根底设施。
无法躲开的多云，多 Region
VIPKID 的事务形状是将国内外的教育资源进行交换互补，包括曩昔的北美外教资源引进到国内和将现在国内的教育服务供给到海外。
为了追求优质的上课体会，除了组建了一个安稳低延迟的互通链路外，不同形状的计算服务都要就近布置，比方教师客户端的依靠服务，要优先布置在海外，而家长客户端的依靠服务则首选国内。
因而 VIPKID 运用了国内外多个公有云厂商的网络资源和计算资源。对多云的资源办理，很早就成为了 VIPKID 的 IaaS 办理体系的一部分。
K8s 多集群战略
在 VIPKID 容器体系规划之初，咱们首选的计划是单集群模式，该计划的优势是结构简略且办理本钱低。但归纳评价多云之间和多 Region 的网络质量与根底设施（网络和存储）计划，并归纳咱们的项目周期，只能放弃这个想法。主要原因有两点：
1）不同云之间的网络延迟和安稳性无法保证
2）各家云厂商的容器网络和存储计划均有差异
若要处理以上问题，需求消耗较高的本钱。最后，咱们依照云厂商和 Region 的维度去装备 K8s 集群，如此就拥有许多 K8s 集群。
集群的容灾
容灾关于容器而言，相比传统的 VM 资源已经友爱得多。K8s 处理了大部分 Pod 和 Node 等级的 Case，但单个集群的灾祸处理，还需求咱们自行处理，因为 VIPKID 早期已经完成了微服务化的改造，因而能够运用快速创立新集群或者扩容现有特定集群的方法来快速进行计算服务的转移。
02 事务挑战及痛点
怎样对待不同集群中的同一个运用？
在多云布置进程中，咱们遇到了一个很杂乱的问题：同一个运用在不同集群中的 workload 简直都是不同的，比方运用的镜像、发动参数（装备）乃至有时候连发布版别都不相同。前期咱们是依靠自己容器 PaaS 途径来办理这些差异，但随着差异需求增多，场景也越来越多，差异抽象越发困难。
咱们的初衷是让开发者能够直接在咱们的 PaaS 途径上办理其运用，但因为杂乱的差异越来越难以办理，终究只能依靠运维同学帮忙操作。别的，在某些杂乱场景下，运维同学也难以快速、准确的进行办理，如此偏离了 DevOps 理念，不只添加了办理本钱，而且降低了运用功率。
怎样快速完成毛病迁移？
关于毛病迁移，这儿我从运用和集群两个不同视角来描述，运用视角垂青要害运用的自愈才能以及能否在多集群状况下保证全体的负载才能。而集群维度则更垂青集群全体等级的灾祸或对新集群的交给需求，比方网络毛病，此刻应对战略会有不同。
运用视角：运用的动态迁移
- 从运用动身，保证要害运用的安稳性，能够灵活的调整运用在多集群中的布置状况。例如某要害运用在 A 集群的实例出现毛病且无法快速康复，那就需求根据事先拟定的战略，在同厂商或同 Region 下的集群中创立实例，而且这一切应该是主动的。
集群视角：新集群怎样快速 ready
- 新集群的创立在咱们的事务场景很常见。比方当某个 K8s 集群不行用时，咱们的期望是经过拉起新集群的方法进行快速修正，再如，事务对新的云厂商或者 Region 有需求时候，咱们也需求能够快速交给集群资源。咱们期望他能够像发动 Pod 相同迅速。
03 Why Karmada
不自己造轮子，着眼开源社区
上述列举的痛点，若只企图满意暂时的需求是远远不够的，体系在快速开展进程中必须要恰当的进行抽象宽和耦，而且随着体系组成模块的角色分工逐渐明晰，也需求恰当的重构。
关于咱们的容器 PaaS 途径而言，事务需求与集群资源耦合越发严重，咱们将解耦的切面画在了多集群的办理上，由咱们自研的途径办理运用的生命周期，别的一个体系办理集群资源的操作指令。
明晰需求后，咱们就开端在开源社区寻觅与调研这类产品，但找到的开源产品都是途径层的，也便是与咱们自研途径处理思路类似，而且大多是以集群视角来进行操作的，一切资源首先在集群的维度上就被分裂开了，并不符合咱们对运用视角的诉求。
以运用为视角，能够理解为将多个 K8s 集群作为一个大型集群来办理，这样一个 workload 就能够看做是一个运用（或一个运用的某个版别）而不是散落在多个集群中同一个运用的多个 workload。
别的一个原则是尽量低的接入本钱。咱们调研了开源社区的多种计划，归纳评价后，发现 Karmada 比较符合咱们的需求。
就它了， Karmada！
试用 Karmada 后，发现有以下几方面优势：
1）Karmada 真实意义的完成了以一个 K8s 集群视角来办理多集群的才能，让咱们能够以运用视角办理多集群中的资源。别的，Karmada 的 OverridePolicy 规划简直一切差异都能够单独声明出来，简略直观且便于办理，这与咱们内部对运用画像在不同集群之间的运用差异不谋而合。
2）Karmada 彻底运用了 K8s 原生 API，使得咱们能够像原来相同运用，一同也标明咱们在后续的接入本钱会很低。而且 Karmada 的 CRD 相对来讲也更简单理解，咱们途径的服务画像模块能够很简单的将分发和差异装备动态渲染成 Propagation 和 Override 战略，下发给 Karmada 操控面。
3）开源敞开的社区治理模式，也是咱们团队最垂青的一点。在试用 Karmada 进程中，不论是咱们自己还是社区方面对需求的理解和想象的处理计划，都能够在社区中敞开评论。一同，在参加代码奉献进程中，咱们团队全体技能才能也明显提高。
04 Karmada at VIPKID
咱们的容器途径，承载了整个公司一切的容器化布置诉求，包括有无状况、在离线事务和 AI 大数据等。而且要求 PaaS 途径的规划和实施不会对某一家公有云发生任何依靠，因而咱们无法运用云厂商封装过的一些产品。
咱们会依靠内部的 IaaS 途径去办理多家云厂商的各类根底设施，包括 K8s 集群的创立、扩容、VPC，子网以及安全组的装备。这个很重要，因为这让咱们能够标准化多个云厂商的 K8s 集群，让上层 PaaS 途径简直无需关怀厂商等级的差异。
别的，关于体系等级的运用和组件，咱们为开发者创立了别的一条办理途径，那便是运用 GitOps。这对高阶开发者来说要愈加友爱，对体系运用的组件装置布置更为高效。
根据 Karmada 的容器化改造计划
在途径落地之初，咱们单独剥离了一个组件（上图左边的“集群会聚 API”），专门和 K8s 集群进行交互，而且向上保留 K8s 原生 API，也会附加一些和集群相关信息。
但在落地进程中，“容器运用办理”体系需求进行许多操作适配多集群下的杂乱状况。比方虽然 PaaS 体系看起来是一个运用，但体系需求渲染不同的完整资源声明到不同的集群，使得咱们在真实维护多集群运用时仍然是不相关的、分裂的，因为咱们没办法在底层处理这个问题。诸如此类问题的处理还是占用了团队不少的资源，尤其是引进 CRD 资源后，还需求重复的处理这方面的问题。而且这个体系无法不去关怀每个集群里面的细节状况，如此背离了咱们规划“集群会聚 API”组件的初衷。
别的，因为 GitOps 也需求与集群强相关，在集群数量较大，而且经常随同集群上下线的状况下，此刻，若要正常工作就需求对 GitOps 的运用装备进行批量改变，随之添加的杂乱度，让全体效果并未到达预期。
下图是 VIPKID 引进 Karmada 之前和之后的架构比照：
\
引进 Karmada 后，多集群聚合层得以真实的统一，咱们能够在 Karmada 操控平面以运用维度去办理资源，大都状况下都不需求深入到受控集群中，只需求与 Karmada 交互即可。如此极大的简化了咱们的“容器运用办理”体系。现在，咱们的 PaaS 途径能够彻底倾泻于事务需求，Karmada 强大的才能已经满意了当时咱们的各类需求。
而 GitOps 体系运用 Karmada 后，体系级组件也能够简略的在各个集群中进行发布和升级，不只让咱们体会到了 GitOps 本身的便当，更是让咱们收成到了 GitOps*Karmada 的成倍级的功率提高。
05 收益
以运用为维度来办理 K8s 资源，降低了途径杂乱度，一同大幅提高运用功率。下面以咱们 PaaS 途径特性下手，来描述引进 Karmada 后的改变。
1）多集群运用的布置速度明显提高： 从前在布置时需求向每个集群发送布置指令，随之监测布置状况是否反常。如此就需求不断的查看多个集群中的资源状况，然后再根据反常状况做不同的处理，这个进程逻辑繁琐而且缓慢。引进 Karmada 后，Karmada 会主动收集和会聚运用在各个集群的状况，这样咱们能够经过 Karmada 来感知运用状况。
2）运用的差异操控可敞开给开发者： DevOps 文化最重要的一点便是开发者要能够彻底参加进来，能够快捷地对运用全生命周期进行办理。咱们充分运用了 Karmada 的 Override 战略，直接与运用画像对接，让开发者能够明晰的了解和操控运用在不同集群的差异，现已支持环境变量，发动参数，镜像仓库。
3）集群的快速拉起 &对 GitOps 适配： 咱们将根底服务（体系级和通用类型服务）在 Karmada 的 Propagation 设定为全量集群，在新集群创立好以后，直接加入到 Karmada 中进行纳管，这些根底服务能够随同集群交给一并交给，节省了咱们对集群做根底服务初始化的操作，大大缩短了交给环节和时刻。而且大部分根底服务都是由咱们的 GitOps 体系办理的，相比曩昔一个个集群的装备来讲，既便利又直观。
4）途径改造周期短，事务无感知： 得益于 Karmada 的原生 K8s API，咱们花了很少的时刻在接入 Karmada 上。Karmada 真实做到了原来怎样用 K8s 现在持续怎样用就能够了。唯一需求考虑的是 Propagation 战略的定制，能够依照资源姓名的维度，也能够依照资源类型或 LabelSelector 的维度来声明，极其便利。
参加开源项目的收成
从 2021 年的 2 月份接触到 Karmada 项目以来，咱们团队先后有 3 人成为了 Karmada 社区的 Contributor，从 0.5.0 到 1.0.0 版别，参加和见证了多个 feature 的发布。一同 Karmada 也见证了咱们团队的成长。
把自己的需求写成代码很简略，把自己的需求和其他人评论，对一切人的需求进行圈定和取舍，选择一个符合大家的处理计划，再转换成代码，难度则会升级。咱们团队在此期间收成了许多，也成长了许多，而且为能够参加 Karmada 项目建设而感到自豪，期望更多的开发者能加入 Karmada 社区，一同让社区生态愈加昌盛！
附：Karmada 社区技能交流地址
项目地址： github.com/karmada-io/…
Slack 地址： slack.cncf.io/
