现在圈内几乎所有人，无论是传统IT驱动者还是互联网引领潮流者，甲方乙方，都知道云原生是个好东西。
所以，现在无论什么人上云，大家都要固定“云原生”而不是“生”。
不得不说，这洗脑真彻底~
那些销售和使用云的人，说起云最初的好处，都是赞不绝口。有什么不可比拟的灵活性、可扩展性、可移植性、自动化能力、快速迭代能力…
这个时候，理性的人就会站出来反思。从来没有“全是优点，没有缺点”这种东西。不要整天只吹云，还要说原生云。
《云原生》无限风光真的有劣势吗？
不仅是，还有，很多！
第一个“罪”，云原生应用比单个程序复杂。
云原生强调解耦，但解耦不代表简单。传统的单体程序，虽然看起来像个黑匣子，但是有各种弊端。但通常基于单一代码库实现，多个模块之间没有通信和管理开销，因此不需要额外的微服务治理。
所以“设计图”和“成品房”的体验不会相差太远，也不容易结局不好。
但是云原生应用只采用微服务架构。单个微服务模块很简单，但是太依赖API，无法组合多个模块。
不同模块的抽象和设计是一道坎，考验架构师的能力，而模块间的通信开销考验微服务治理能力...
总之，从“蓝图”到“成品”还有很长的路要走，说不定还会漏风漏雨。
第二个“罪”，更多的工具依赖和学习成本。
从开发阶段到运维阶段，云原生引入了更复杂的技术栈，很多都是全新的，不仅是编程语言，从K8S管理到各种CI/CD工具…，学习路径极其陡峭。
没有高手或者真正大规模的DevOps作战环境，依靠以前学习编程和语言的方式，很难搞定。
第三宗“罪”，厂商锁定风险。
云原生看起来“解耦”“开放”，API是他们积极倡导的。但毕竟说到PaaS，各大云厂的“粘性”还是极强的，尤其是Serverless这样的重云原生架构，还没有形成真正的标准化。
所以，要达到“一次编写，处处执行”的理想状态，还有很长的路要走。
因此，云原生架构可能会形成一波云厂商对客户的新锁定。
但是，你知道，这个困难对于IT人来说是困难的。大家一致认为云是原生的！
互联网行业不用多说，云原生就是基因，传统IT已经开始克服一切困难，一点一点把业务搬到云原生架构上。
然而，当大家历尽艰辛，爬上山头，云原生业务终于交付生产，才发现，
过了这座山，还有那道坎。
业务投产后，还有一个巨大的窟窿需要填补:这就是云原生业务的数据保护和容灾备份。
为什么「备份」会成为云端的巨大空洞？
首先，没有人敢忽视数据保护的重要性，备份基础设施对于任何稍有规模的企业级业务都是不可或缺的。
然而，有很多备份软件可以处理传统的IT和虚拟化环境，但你很难找到一个可靠的云原生数据保护平台。
云原生业务和传统IT架构的区别太大了。如果你想做好备份和恢复，你必须面对许多新的挑战。
第一，容器化和传统VM/裸机部署模式的区别。
传统IT架构下，无论裸机还是虚拟机，都只是计算能力粒度不同，但大多承载单一应用，以集中式架构为主。
备份目标明确，易于跟踪，易于控制。
云原生架构有着完全不同的承载应用的模式。将单个应用拆分成相对独立的微服务模块，然后由不同的容器承载不同的微服务。
容器不仅改变了计算单元的粒度，也改变了应用的构造方式和运行方式，成为真正的分布式架构。这样的一整套系统让传统的备份系统有点不知所措，看不懂资源关系，找不到备份目标。
第二，要适应DevOps的高速滚动。
云原生让DevOps火了，传统的瀑布式开发逐渐被滚动式敏捷开发取代。这符合大家对业务系统新功能小步快跑、快速上线、频繁迭代的诉求。
在这样的轮次、小步、频繁变更的过程中，开发团队需要一种方法来可靠地控制、迁移和测试真实的应用数据，尤其是对于那些“有状态”的容器。
传统的瀑布开发是一蹴而就的，不需要太多考虑。但是敏捷开发必须让有状态的CI/CD正常承载数据和流程，这要依靠同样敏捷的数据备份和恢复技术，一般人做不到。
第三，要注重应用，保证数据一致性。
在传统备份场景中，对于一些知名的大型应用，如Oracle、Exchange、SAP等。，还可以执行应用程序级备份，以确保数据一致性。
但一般依赖大型应用提供的备份接口，然后通过安装备份代理完成应用级备份，比如Oracle备份，就需要使用“O记”提供的RMAN工具和MML接口。
但是云的原始时代就大不一样了。应用程序“单薄而破碎”，甚至低至单个微服务级别。几乎不可能实现准确详细的应用级备份。
更有甚者，一些复杂的应用或服务要么没有专用的持久存储层，仅靠存储级备份无法做到，要么是有状态的，无法保证一致性，给以后的数据恢复带来层层阻碍。
第四，日益严峻的安全挑战。
虽然在云原生环境下保护数据很难，但是围绕K8S和容器的勒索病毒攻击永远无法停止。比如一个叫Siloscape的勒索软件，专门感染K8S集群。
一旦被攻击，又没有可靠的后援可以恢复，除了交赎金，只能“用脑袋抢地盘”
怎么样了？没想到，云原生业务的风光背后隐藏着这么多备份坑。
坑太多就不干了吗？不不不坑一定要填！
所以，今天我要介绍一位优秀的“填坑”专家，他就是卡斯滕↓
至于维姆，你不用白费口舌了。这就是长期以来在后备军人名单上占据主导地位的球员。总之，各种数据保护场景选择Veeam是对的！
Kasten是Veeam旗下面向云原生场景的独立品牌。不仅出身名门，而且很会玩。云原生领域很难有突破。
看看下面这个云原生数据保护的“专业比赛”。卡斯滕的位置是力量的象征。
Kasten的招牌产品名为Kasten K10，是一个“专为Kubernetes设计”的云原生数据保护和管理平台。
这么说吧，无论是自己搭建的小型K8S集群，还是超大型的K8S生产环境，还是基于各种K8S发行版的云原生环境，K10都可以帮你填补备份漏洞，让你无后顾之忧。
接下来，让我们来看看。卡斯滕K10是怎么填坑的？
在一个典型的云原生场景中，引入K10后，架构是这样的:K10就像一个集群中的并行Pod，与容器编排平台和基于API的底层持久存储进行通信。
在上层，Kasten专门推出了开源的数据管理框架Kanister，它根据应用蓝图执行有状态的应用感知数据备份。
仔细看我画了一天的这幅画。最底层是各种公共私有云平台，然后是虚拟或物理基础设施，然后是各种容器编排平台。最上面是各种各样的pod，承载着各种各样的云原生应用。
K10邮票在这里。它是如何工作的？有三个关键点。首先，应用程序发现。K10通过K8S API发现应用与应用部署之间的关系，并下达指令执行数据管理生命周期操作。无论是原生K8S，还是商业发行的各方诸侯，都能把准脉搏，迎头赶上。
其次，持久层是可见的。固定持久存储卷的应用易于处理。搞清楚关系后，就可以通过卷备份来做了。一些复杂的应用，没有专门的存储层，基于API进行跟踪。
说白了就是以应用为核心，剥开茧，找到对应的持久层备份源，再开始。
第三，应用感知。对于一些有状态的应用，比如使用数据库，备份时跟踪状态，从逻辑层备份保证一致性，是一个很大的问题。而K10用Kanister这个神器就能轻松搞定。
简单来说，就是通过“应用蓝图”了解备份应用所需的模板资源，用哪种原生方法获取数据集，然后按照业务逻辑，调用原生方法获取与应用一致的数据副本。
拿到这三个关键点，就算七七八八把云原生备份的大洞补上了:发现云原生应用和对应的资源关系；处理不同类型的持久存储层，以确保有状态应用程序的数据一致性。
总之，卡斯滕K10的核心本质是以应用为中心，应用捕获→应用恢复→应用迁移容灾，一站式服务。
做了这么多备份，为什么Kasten K10能成为云原生数据管理的肩膀？让我简单总结一下—
首先，K10本身就是云原生的，完全融入了云原生的海洋，从而实现了云原生生态的端到端适配。
其次，K10是以云原生应用为核心的数据管理平台，以应用为运营单元，支持基于应用感知的数据抓取，维护数据一致性，这在云原生架构下非常重要。
再次，K10是纯软件，不是备份一体机。简单易用，自动化和可视化优秀，运维无压力。它对RD学生也很友好。它保持开放的接口，RD可以扩展功能，支持更复杂的特殊应用。
同时，在大规模DevOps的场景下，有状态应用在CI/CD流程中快速流转是一个老问题。但是K10可以通过持续的“捕获和恢复”快速迭代有状态应用的数据一致性。
第四，Veeam的“备份家族”一直重视数据安全，如今这一光荣传统也传承到了Kasten。K10的应用自动抓取还原，本身就是一个防勒索的月光宝盒。
而且通过强大的验证机制，不会误备份被感染的数据，同时“不可变存储”提供了更深层次的保护，确保备份的数据不会被勒索软件覆盖。
至此，结论显而易见。veeam“Family”具备所有场景下的数据保护和管理能力。
无论是传统架构还是云原生架构，云下、云上、云上，无论是稳态业务还是敏感业务，物理、虚拟、应用层、有状态、无状态，无论是备份、恢复、容灾、迁移、数据管理、DevOps……...，找Veeam的金字标，没错！
