Karmada | VIPKID在线教育平台从天到秒的跨云迁移实践
作者：互联网
在线教育的业务高速发展的技术困境
VIPKID的定位是在线教育行业里在线青少儿英语，拥有80万以上付费学员和7万多的优质北美外教，在快速发展大体量的情况下，我们遇到了如下这些问题：
1）业务体量的快速增长：在整个在线教育行业的迅速发展下，如何即满足业务体量的快速增长，又能灵控制成本？
2）业务的快速发展：产品迭代加速，创新项目增加。如何能提供高效快速的项目发布支持，助力产品快速成长？
3）产品模式的多样化：除传统web服务外，如何满足AI计算，多语言栈，音视频编解码等不同的产品模式的新的资源需求？
为何选择云原生作为解决思路
在上文提到的几个场景下，比如无状态应用、音视频，计算和弹性伸缩，其实我们在19年就已进入了容器化过程。但刚开始，我们只是从VM迁移到容器，在迁移后，我们发现并未得到预期的收益。然后从2020年初开始，我们遵循云原生的容器化之路，对原有的容器化方案进行进一步的改造。我们获得了如下收益：
1）无状态应用容器化
效率收益：过去在VM上，一个应用从创建到上线2-3天的流程，现在借助容器平台上仅需3-5分钟，并且80%以上需求场景完全自助，无需运维人员介入。
2）弹性伸缩能力
成本收益：与容器化改造前相比，AI离线计算成本下降了 43% 弹性实现完全自动化，无需人工干预，降低了人工成本；在线服务成本下降10%-70%
3）音视频服务容器化
效率收益：部署效率大大提升，从0开始部署并上线整套系统由原来的3-5天缩短到3-5小时。
成本收益：on the way
什么是云原生
左图是我以标签的形式列举的云原生概念里的一些关键词。右图从下面看，为整个云基础设施的种类，包括公有云、私有云和混合云，刨除基础设施往上看，其实有一点很重要不可变基础架构，也叫不可变基础设施。声明式API构成了整个云原生最核心的宗旨，再往上是容器和整个k8s平台。
在整个容器体系内，我们拥有以微服务式的方式拆分或开发的应用，若需要更进一步进入云原生，可以进行Service Mesh整体封装和对外提供这种灵活的流量服务。两侧贯穿的这两个概念也是很重要的，首先是可观测性，可观测性就是大家熟知的监控日志和trace，左侧我画了CI/CD,相当于要让整个云原生的这套机制在整个流水线下自动运行起来，这对于效率的提升和整个产品的迭代有很大的作用。
接下来，我举几个例子：
所以说在整个云原生改造过程中，还是需要注意方法方式的，使我们的改造尽可能的偏向于云原生，改造成云原生模式，你可以从容器中获得更多的收益，不论是成本方面还是效率方面。我个人写了一个评判云原生改造是否成功的标准，不论是改造pod还是整个平台，在R&D使用期间，它在整个软件生命周期的过程中，它的自动化程度是相当高的。
多场景云原生落地剖析
无状态应用的落地实践
前提条件：研发的准备—微服务化、存储分离、状态外置
1）产品迭代迅速，多种技术栈快速支持
上图是我们稳定版本构建系统的架构。开发者向GitLab提交代码去做代码的维护，引入了Jenkins的pipeline功能，它在每次构建的时候会将代码克隆下来，进行构然后做相应的测试。这里其实有一个我们独有的步骤，我们会将它打包传到制品库，这个地方其实是为了兼容我们自己的 vm的发布做的，所以纯容器的可以把这个忽略，然后之后再做镜像的构建和push。
整个架构里最明显的三个角色是GitLab（一个VC系统）、Workflow或Pipeline引擎，基于这个引擎，可以低成本的创造一条Workflow或Pipeline，实现某个技术栈的构建。另外是我们熟知的 docker的镜像仓库。
2）多种发布方式：蓝绿发布&灰度发布
- 共同点：使用一个Service和多个Deployment来承载一个应用
- 差异：Service通过selector将流量打到其中一个或多个Deployment的实例上
- 缺点：灰度的流量配比只能通过实例数来实现
- 更好的选择：Serivce Mesh (Istio)
3）多集群管理
- 开源/自建平台胜于kubectl: 尤其是多集群之间切换时容易混乱，比对集群之间资源差异的时候简直就是噩梦
集群资源由平台统一管理：包括同一应用不同集群之间的关联，不同集群内的状态感知等。难点：同一应用实际上在不同的集群之间是独立无关的，但是他们又有一些相同的属性。部署过程需要关心这些差异，比如镜像仓库地址。日常运行期间又要关心他们在不同云之间的实例数量，集群故障时还需要进行手工迁移。
4）巡检工具：降低研发同学的使用门槛，降低运维同学的重复工作
- 弱化专业术语/知识，增强交互体验
- 工具平台化，方便新增诊断case
弹性伸缩能力的实践
1）AI离线计算任务，利用云原生带来技术领先型
AI业务线某项目升级，在推敲了基于容器的任务调度能力后，欣然达成合作。目前该项目的所有计算任务均基于K8s的Job来承载，而我们又针对任务的整体容量增加了K8s node的动态扩缩容能力，这个可以把我们的计算任务跑到任意一个云上面。
图：计算任务数量与计算节点数量走势图（周期1w）
2）在线服务通过HPA进行弹性伸缩，有效降低成本
原生HPA和CronHPA结合的方式来，为了方便管理，最终选择了社区开源方案 keda.sh (CNCF sandbox)
音视频服务的落地过程
1）有状态应用改造实践 - 摈弃VM上的不良使用习惯
有状态应用改造中，一些VM时代的使用习惯虽然依然work，但是他们不符合云原生的思想，会带来更多的维护成本。
上图为我们的改造，改造方式其实就是换了一个workload类型,另外将我们的 pod和数据用PV&PVC的方式进行一对一挂载。这样就解决了两个问题，第一，我们不需要再维护数据和pod所在node的关系了。第二个问题我们不论是弹性还是出现这种pod漂移，其实都不需要顾虑找不到它的数据。其实有的时候我们将 k8s的这种能力多了解下，就能找到我们适合的场景去改造。
2）有趣的Case - 长连接ELB负载不均的问题
场景：K8s原生service，业务某个服务被调用，但实例上收到的请求量负载不均衡。
原因：传统ELB对接k8s原生nodeport service，长连接会出现负载不均衡。
解决方案：使用华为云云原生2.0网络，使外部流量直通容器，不再经过k8s原生nodeport service转发。
社区参考连接：https://learnk8s.io/kubernetes-long-lived-connections
深度分析：多集群管理
演进和思考
所以在这个背景下，我们去各种寻找解决之道，最终找到了一个特别适合我们的解决方案。Karmada同时满足了上文提到的我们现在业务对多集群管理的三个要求：
集中管理，但要原生
应用在不同集群的差异化管理
集群故障自动转移
Karmada架构图
Karmada其实它整个的设计结构就是按原生k8s开发标准开发的,唯一差别之处是需要管理多个集群不同的 workload信息，所以改写了调度器和控制器，在它们下面对接了多个集群管理起来。这样最大的好处其实在于我们其实是在控制一个集群，但最终的效果是在控制多个集群。
接下来分享我们在 Karmada下面做的demo：
该演示其实想说明我们对多集群管理完全可以通过一个重要化的原生k8s原生的方式去做管理。
云原生改造过程中的心得
1）拥抱云原生，拥抱社区开源产品：这其实是一个相对必要的或者前提的一个要求。当我们拥抱云原生，了解整个容器生态，了解它所有的能力情况下，你才能用更正确的方式，或者是用总综合成本最低的方式做这种容器的实践或者迁移。另外在迁移过程中，大家肯定会遇到各式各样的问题，当遇到问题时，首先应该想到的是开源社区，因为很多人会遇到和你相同的问题，去寻找社区产品其实是一个低成本的解决方式，有效的减少了我们的开发成本和和投入的周期。
2）效率至上：平台面向R&D，面向全生命周期
3）平台系统松耦合&分层设计，剥离自身业务，少给自己造“轮子”，更多的参与到社区的“轮子”中。
很高兴有机会能够加入到Karmada项目，希望有更多的开发者能够加入Karmada，与我们共建社区，共建这样一个多云管理的新项目。
标签：原生,VIPKID,从天,容器,改造,跨云,集群,Karmada,我们 来源： https://blog.51cto.com/u_15127680/2813123