揭秘云原生：那些鲜为人知的秘密

如今，几乎所有圈里人，无论传统IT老司机，还是互联网弄潮儿，甲方也好，乙方也好，都知道云原生是个好东西。

所以，现在但凡上云，大家都要整“云原生的”，“夹生的”不要

不得不说，这波洗脑，可真彻底呀~

卖云的、用云的，谈起云原生好处，全是溢美之词，什么无与伦比的弹性、扩展性、可移植性、自动化能力、快速迭代能力…

这时候，理性的人就会站出来反思一下，从来就不存在那种“全是优点、没有缺点”的东西，不要整天光吹云原生的好，也要讲讲云原生的孬↓

风光无限的「云原生」，真有缺点吗？

不光有，而且，还不少！

第一宗“罪”，云原生应用比单体程序更复杂。

云原生强调解耦，但解耦并不意味着简单。传统的单体程序，虽然看起来是个黑盒，有各种各样的不好。但它通常基于单一代码库实现，也没有多个模块之间的通信和管理开销，不需要什么额外的微服务治理。

所以，“设计图”和“成品房”之间的体验，差距不会太大，不容易烂尾。

而云原生应用则才采用微服务架构，单个微服务模块是简单了，但是要把多个模块糅合起来，对API过度依赖。

不同模块的抽象和设计就是一道坎，考验架构师能力，而模块间的通信开销又考验微服务治理能力……

总之吧，从“蓝图”到“成品”，任重道远，搞不好还漏风漏雨。

第二宗“罪”，更多的工具依赖和学习成本。

从开发阶段贯穿到运维阶段，云原生引入了更复杂的技术栈，很多还是全新的，不只是编程语言，还有从K8S管理到各种CI/CD工具…，学习路径极其陡峭。

没有老师傅带着，或者没有真正的大规模DevOps实战环境，靠以前学编程、学语言的方式，很难搞定。

第三宗“罪”，厂商锁定风险。

云原生看起来是“解耦”和“开放”，API化是他们积极倡导的，但是毕竟到了PaaS这一层，每个云大厂的“黏性”还是极强的，尤其是像Serverless这样的重度云原生架构，还没有形成真正的标准化。

so，想要达到“一次编写、到处执行”的理想状态，还有很长的路要走。

因此，云原生架构，可能形成云大厂对客户的一波新锁定。

但是你懂的，这点困难是难不倒IT人的，大家都一致看好云原生！

互联网行业自不必说，云原生就是基因，而传统IT也开始排除万难，把业务一点点往云原生架构搬。

可是，当大家历尽千辛万苦，踩坑爬坡，云原生业务终于交付生产了，却发现

过了这一山，还有那一坎

业务投产后，还有个巨大的坑没有填：这就是针对云原生业务的数据保护、容灾备份。

为什么「备份」会成为云原生的一个巨坑？

首先，没人敢忽视数据保护的重要性，稍微上点规模的企业级业务，都少不了备份基础设施。

可是，能搞定传统IT和虚拟化环境的备份软件一大把，而你却几乎找不到一个靠谱的云原生数据保护平台。

云原生业务和传统IT架构差别太大，想做好备份和恢复，要面临很多新挑战。

第一，容器化与传统VM/裸机的部署模式差异

在传统IT架构下，无论裸机还是虚机，它们只是算力的颗粒度不同，但承载的大都是单体应用，以集中式架构为主。

备份目标很明确，易追踪，好把控（磁盘、存储卷、虚机镜像、大型知名应用的备份接口等等）

云原生架构对应用的承载模式，就完全不一样了，一个单体应用，被拆分成相对独立的微服务模块，然后，不同的微服务分别由不同的一组容器（Pods）来承载。

容器不仅改变了算力单元的颗粒度，还改变了应用的构建模式和运行模式，成了真正的分布式架构，这么一整，就让传统备份系统有点懵逼，理不清资源关系，找不到备份目标。

第二，要适配DevOps的高速滚动

云原生让DevOps火了起来，传统瀑布式开发逐渐被滚动式的敏捷开发所代替。这很顺应当下大家对业务系统小步快跑、快速上线、频繁迭代新功能的诉求。

在这样一轮接一轮，小步快跑、频繁变动的过程中，开发团队需要有办法来可靠的控制、迁移、和测试真实的应用数据，尤其针对那些“有状态”容器（富含数据，比如数据库或者消息总线）

传统瀑布式开发，是一锤子买卖，不需要太多考虑，而敏捷开发必须要让有状态的CI/CD能够携带数据正常流转，这就要依赖同样敏捷的数据备份和恢复技术，一般人搞不定。

第三，需要以应用为中心，保证数据一致性。

传统备份场景，针对一些知名大型应用，比如Oracle、Exchange、SAP等等（其实VMware也算一种应用），也可以进行应用级备份，来保证数据的一致性。

但这一般都依赖于大型应用提供的备份接口，再借助于安装备份代理，来完成应用级备份，比如Oracle备份，就要用到“O记”提供的RMAN工具和MML接口。

可云原生时代就大不一样了，应用“又细又碎”，甚至要细到单个微服务级别，想要做到精准细致的应用级备份，几乎不可能。

更要命的是，有些复杂的应用或服务，要么没有专用持久存储层，仅靠存储级的备份搞不定，要么是有状态的，无法保证一致性（数据文件和控制文件相一致），给未来的数据恢复带来层层障碍。

第四，日益严峻的安全挑战。

虽然云原生环境做数据保护很难，但围绕K8S和容器的勒索攻击可一点不消停，比如一种叫做“Siloscape”的勒索病毒，就专门感染K8S集群。

一旦被攻击，又没有靠谱的备份来恢复，除了付赎金，就只能“以头抢地尔”了

怎么样？没想到吧，云原生业务风光的背后，竟然藏着这么多备份的坑儿

坑多就不干了吗？不不不，必须要把坑填上！

所以，我今天要介绍一位卓越的“填坑”小能手，这位小能手，就是当代备份大咖Veeam旗下的Kasten↓

关于Veeam，就不用多费口舌了吧，那可是备份兵器谱上长期霸榜头名的选手，总之吧，各种数据保护场景，选Veeam准没错！

而Kasten正是Veeam门下面向云原生场景的独立品牌，不光出身名门，自己也特别能打，硬是在云原生领域闯出了一片天。

看看下面这个云原生数据保护的“专业擂台赛”，Kasten的所处位置，就是实力的象征。（这是由专业分析机构GigaOm出品的K8S数据保护雷达图，越靠近中心代表越牛掰）

Kasten的招牌产品，叫做Kasten K10，是“专为Kubernetes设计的”云原生数据保护和管理平台。

这么说吧，不管是你自己搭的小规模K8S集群，还是超大规模的K8S生产环境，或者是基于各类K8S发行版的云原生环境，K10都能帮大家填平备份的大坑，让你没有后顾之忧。

接下来，我们就给大家捋一捋，Kasten K10具体怎么填坑的？

在典型的云原生场景里，引入K10以后，架构是这样的：K10就像集群里的一个平行Pod，与容器编排平台（K8S或其他商业版本）和底层持久存储都基于APIs来交流。

在上层，Kasten专门推出了一个开源数据管理框架Kanister，基于应用蓝图，进行有状态的应用感知数据备份。

细看这张我画了一天的图，最下面是各类公有私有云平台，然后是虚拟或物理的基础设施（集群的工作Node、PM/VM、容器持久化存储），再往上是各类容器编排平台（原生K8S或者各类商业发行版），最上面一层各种Pods，承载各类云原生应用（有状态的、无状态的、数据服务、移植应用）。

K10戳在这里，具体如何工作呢？这里面有三个关键点。

第一，应用发现。K10通过K8S API来发现应用与应用部署的关联关系，并发号施令，执行数据管理生命周期操作。不管是原生K8S还是商业发行版各方诸侯，都能号得了脉、搭得上话。

第二，持久层可视。有固定持久存储卷的应用，好办，探明关联关系后，用卷备份来搞定；有些复杂应用，并没有专用存储层，那就基于API来追踪。

说白了，以应用为核心，抽丝剥茧，找到对应的持久层备份源再下手。

第三，应用感知。对于一些有状态的应用，比如使用了数据库，备份时必须要跟踪状态，从逻辑层进行备份，确保一致性，这是个大难题。而K10用Kanister这个神器，就可以轻松搞定。

简单说呢，就是通过“应用蓝图”来获知备份该应用所需要的模板资源，用哪种原生方法来获取数据集（比如mysql用mysqldump），然后遵从业务逻辑，调用原生方法，来获得应用一致的数据副本。

搞定这三个关键点，云原生备份的大坑就算填得七七八八了：➊发现云原生应用以及对应的资源关系；➋搞定不同类型的持久化存储层➌保证有状态应用的数据一致性。

总之，Kasten K10的核心要义，就是以应用为中心，应用捕获→应用还原→应用迁移和容灾，一条龙服务

做备份的那么多，为啥Kasten K10能成为云原生数据管理的扛把子？我来简单总结下——

首先，K10本身就是云原生的，也把自己彻底融入到云原生的海洋里，实现了对Cloud Native生态的端到端适配（存储架构、容器编排、分发平台、数据服务）

第二，K10是以云原生应用为中心的数据管理平台，把应用作为操作单元，支持基于应用感知的数据捕获，保持数据一致性，这在云原生架构下，非常重要。

第三，K10是纯软件，不整啥备份一体机，简单易用，自动化、可视化优秀，运维操作起来毫无压力，而对研发同学们也很友好，保留开放接口，研发可以扩展功能，支持更加复杂的特殊应用。

同时，在大规模DevOps场景下，让有状态的应用在CI/CD流程中快速流转，是个老难题，而K10对有状态应用的数据一致性能力，通过持续的“捕获↔️恢复”，就能实现快速迭代。

第四，Veeam“备份世家”历来重视数据安全，如今这个光荣传统，也传承到了Kasten的身上，K10的自动化应用捕获与还原，本身就是防勒索的月光宝盒。

而且，还通过强大的验证机制，保证被感染的数据不会误备份，同时，“不可变存储”则提供了更深层次的防护，确保已备份的数据不会被勒索病毒改写。

事情讲到这儿，结论已经很明显了，Veeam“世家”具备全场景的数据保护和管理能力。

不管是传统架构还是云原生架构，云下的、云上的、多云的，不管稳态业务还是敏态业务，物理的、虚拟的、应用级的、有状态的、无状态的，不管是备份、恢复、容灾、迁移，还是数据管理、DevOps……，认准Veeam的金字招标，准没错！