K8S数据保护工具比较：Cohesity、 Kasten、 OpenEBS、 Portworx、 Rancher Longhorn、 和Velero
数据保护对于客户越来越重要。从概念上来说，数据保护包括备份、高可用性、应用连续性、和容灾恢复。所有的企业都需要实施，测试和运维自己的数据保护策略，来避免在发生问题时对商业产生不利影响。随着数据在用户体验和商业流程中的作用越来越重要，对关键数据突然不能访问的问题的容忍度越来越低。根据Uptime Institute的报告(https://uptimeinstitute.com/data-center-outages-are-common-costly-and-preventable) 数据无法访问问题中41%的情况导致的损失均超过了百万美元。企业对高可用性的基础架构的依赖性逐渐增强。
因此，一个有效的数据保护策略可以使宕机时间极少，即便发生意外宕机，应用和数据也都可以快速的恢复。同时数据保护策略还需要确保数据的隐私性和合规性（比如GDPR和CCPA），现在越来越多的用户数据转移到了线上隐私合规愈发重要。
虽然数据保护是一个硬性需求，很多客户仍然做的不够好。传统的数据保护方式在单独主机环境里很出色，但在分布式或跨数据中心环境里就能力不足了。而Kubernetes环境是典型的分布式环境。传统的业务连续性和容灾恢复（BCDR）方案，无法支持现今运行在Kubernetes上的关键商业应用所要求的RPO（Recovery Point Objective）和RTO（Recovery Time Objective）。
由于每个应用和每个客户环境都各不相同，因此数据保护方式也多种多样。当我们考虑数据保护解决方案的时候，一些重要的问题我们首先需要思考：
- 我是不是只需要在一个单独的数据中心里保护我的数据？
- 我是否需要保护数中心内和数据中心外的数据，需要建立一个混合的数据保护方案？
- 是不是合规部门对一些备份和恢复数据的存储位置有要求？
- 应用对RPO和RTO的要求低还是高？
- 是否需要对Kubernetes集群里的每一个应用都采用同样水平的数据保护方式？
- 我们准备对数据保护方案花多少钱，可否对不同的应用采用不同的数据保护方式，以降低成本？
还有一些问题取决于你的目标，比如：
- 即使出现服务器宕机，或者磁盘宕机，也需要保证Kubernetes应用的高可用。
- 备份数据和应用的配置，这样我们可以在另一个环境里恢复它们。
- 一旦出现数据中心服务中断，应用可以即时在另一个环境重启且没有数据损失。
我们可以把数据保护场景分为：
- 本地高可用
- 备份和恢复
- 容灾恢复
这三种场景是所有企业级数据保护的基础，也是评估一个Kubernetes数据保护解决方案能力的重要要素。不同解决方案的客户要求可能各有不同，客户需要根据自身的需求来评估这些要素。通常来说，只有静态数据备份不足以完成有效的数据保护，本地高可用通常是必须的基础性需求。
本地高可用、备份和恢复、容灾恢复是评估一个Kubernetes数据保护解决方案能力的重要要素。
对于Kubernetes，数据保护是一个较新的领域，市场有一些解决方案提供。本文我们要分析Kubernetes应用数据保护领域的一些主要供应商（https://www.computerweekly.com/feature/Spread-of-Kubernetes-spurs-backup-and-disaster-recovery-products）。我们在博文中讨论的解决方案主要是为了保护Kubernetes中正在运行的应用、和应用中的持久性数据，而不是备份Kubernetes的节点服务或者etcd存储，明确这些有助于我们更好的理解数据保护工具和Kubernetes的数据保护。
本地高可用性
本地高可用性指的是保护发生在某单个数据中心的错误，或者是某单个可用性区域内的云平台的错误。当应用正在运行时，如果基础架构、应用或者节点发生错误，都被认为是本地的错误。当我们用Kubernetes数据保护工具来构建本地高可用时，应用的复本可以在用户无感觉的情况下快速恢复，达到对用户的高可用。一个在本地节点错误情况下，宕机的例子：https://thenewstack.io/overcome-stuck-ebs-volumes-running-stateful-containers-aws/。本地高可用性是数据保护的基础。为达到本地高可用性，一般通过建立本地数据复制集的方式。如果本地高可用性是通过从外部其它位置的备份数据恢复的方式进行，那就应该被归类为是备份恢复方案，因为恢复时间会比本地高可用性的方案长很多。
备份和恢复
备份和恢复方案，指的是把Kubernetes上的整个应用，从本地Kubernetes集群上，备份到非本地的另一位置的对象存储里（非本地指位于其他区域的公有云、私有云、或者是本地部署环境）。备份解决方案也可以有多个备份位置。备份通常是为了防止系统错误，或者为了应用的合规和监管要求。而Kubernetes备份，需要符合Kubernetes环境特点。包括：
- Kubernetes资源，比如Secrets、服务账户、CRDs等
- 应用配置和数据
这些对象对Kubernetes来说都需要被备份。传统的备份方案一般不会考虑这些Kubernetes的对象，而是通常只把应用所依赖的VM、服务器、磁盘作为备份目标。一个Kubernetes备份解决方案，不仅能备份单个应用，而且可以备份多个应用或者整个Kubernetes命名空间，同时也能够支持传统备份方式的内容，比如调度、Jobs、 retention、加密和分层。
一个Kubernetes备份必须包括Kubernetes的资源比如Secrets、服务账户、CRDs、应用配置和数据。
容灾恢复
与备份类似，容灾恢复也必须要包括Kubernetes的一系列对象，应用配置和数据。并且需要创建主站点之外的容灾站点，这样资源和持久状态能够在主站点出问题时快速恢复到容灾站点。容灾恢复系统也可以处理不同保护层级的RPO和RTO，取决于成本和商业需要的综合考虑。
例如，如果应用不能承担任何数据丢失，那就必须设定零RPO的目标。如果要求没那么高，也可以设定15分钟RPO的目标。再例如，一个应用的RTO要求<2分钟，而另一个应用可以允许1小时之内的宕机时间。
容灾恢复系统必须规划应用如何配置才能够在容灾节点上有效的启动运行。这需要处理应用的元数据，例如标签和复制集等，让它们能够自动启动起来。如果Kubernetes的API不能够被理解和启动，就会产生宕机事故或者数据损失。
Kubernetes数据保护解决方案的比较
我们已经理解了数据保护的多种类型，我们接下来比较一下市场上的解决方案：*比较基于各解决方案提供商的网站和文档。
快速索引
X – 没有这项功能，或者宣称有功能但没有找到任何支持性信息
❍ – 宣称有这项功能，但是功能较为薄弱
◑ – 宣称有这项功能，但是功能不完整
✅ – 宣称有这项功能，并且从网站上的文档来看功能完整
Cohesity
Cohesity在网站上介绍，“Cohesity保护Kubernetes命名空间的数据和应用状态。Web-Scale平台备份命名空间包括运行状态，而不仅仅是数据。”Cohesity是数据保护和存储领域的一个主要服务商，它近期也通过备份命名空间的数据和应用，开始支持Kubernetes。但是Cohesity仅仅针对整个命名空间，而不能保护命名空间内的每个独立应用。保护单独应用是很有必要的，因为不是所有命名空间内的应用都需要同一水平的保护级别。因此Cohesity保护的颗粒度还不够。另外Cohesity目前还没有Kubernetes主存储，也还没有基于Kubernetes的容灾恢复方案。由于Cohesity对于备份VM的传统解决方案积累很久，现在进入到对Kubernetes的支持，也是一个很好的解决方案。
Kasten
Kasten在网站上介绍，“K10数据管理平台，为Kubernetes而建，为企业运营团队提供易用、可扩展、安全的备份恢复、容灾恢复、和集群间应用迁移能力”。Kasten使用自身构建的存储系统 -EBS/RBD，不支持应用自身所在集群里的复制，因此它无法支持本地高可用。基于云端的块存储来构建Kubernetes卷，经常会由于Stuck Volumes导致应用的宕机。由于没有数据路径的组件，Kasten无法达到数据完全无损的零RPO，备份只能是异步的，因此恢复后的数据与最新的数据会有一定的不同。有时候企业在容灾恢复上的要求不高，但很多企业仍然在容灾恢复上需要零RPO。
OpenEBS
OpenEBS这样描述：“我们是应用和本地、网络或云存储之间的抽象层，通过OpenEBS可以减少维护工作量，降低存储成本并且简化管理。”OpenEBS主要集中在本地高可用，也可以和Velero集成来达到OpenEBS 数据管理即服务（DMaaS）。DMaaS能够把Kubernetes有状态应用以及持久数据进行迁移。本地部署、云部署等任意方式都可以互相迁移。相对于Cohesity只备份整个命名空间而非每个独立的Kubernetes应用，OpenEBS只备份独立的应用。应用层级的备份的确更加灵活，但很多客户仍然需要命名空间层级的备份。另外OpenEBS只能用来备份包含持久存储卷的有状态应用，而不能备份或迁移Kubernetes对象和应用配置。OpenEBS备份是基于Velero进行的，而Velero也有自身的局限性 – 不能提供完整的容灾恢复功能，而OpenEBS自身也没有容灾恢复功能的补充，虽然OpenEBS也可以提供类似Kasten那样的异步备份的容灾，但问题也是无法达到数据完全无损的零RPO。
Portworx
Portworx是一个端到端的Kubernetes存储和数据管理方案。包括基于容器的CaaS，DBaaS，SaaS，备份恢复，以及容灾恢复。Portworx被市场研究机构GigaOm评为全球第一的Kubernetes存储平台。GigaOm评价Portworx的功能完美适应大型客户与服务提供商的需求。Portworx解决方案支持复杂的Kubernetes基础架构，无论是本地部署还是公有云/混合云部署。在Portworx的支持下，所有的Kubernetes应用都可以获得容器原生存储能力，以及本地高可用、容灾恢复、备份、安全管理、多云间迁移的能力等。Portworx提供一个数据层能够伸展在低延迟的网络上，从而达到零RPO容灾恢复，本地应用的备份和命名空间的备份。Portworx一开始就支持本地高可用，以及后来推出的PX-DR和PX-Backup能够提供更加多样的数据保护能力。
Rancher Longhorn
根据Rancher的描述，Longhorn是“轻量的，可靠的，和强大的。你可以使用简单的Kubectl命令，或者使用Helm来把Longhorn安装到Kubernetes集群上。一旦安装完成，Kubernetes集群就具备了持久存储卷的支持。”虽然比起其他开源解决方案，Longhorn的社区较小，但它近期被接受加入了CNCF。Longhorn有DR Volume的功能，可以被设定成源卷和目标卷，这样卷可以在一个新集群上基于最新的备份被激活。这个很类似Kasten的DR解决方案，是基于备份的，因此无法达到零RPO的能力。同样由于也不含应用元数据，因此也无法达到Kubernetes应用层级的恢复。
Velero
Velero描述自己的解决方案：“一个开源工具，可实现安全的备份恢复、容灾和恢复，以及迁移Kubernetes集群资源和持久卷。”Velero自身只能支持无状态应用资源。但是用户可以选择增加插件来达到持久卷声明快照备份。另一个选择是Restic，它通过文件/拷贝方式来实现。Velero自身并没有解决Kubernetes应用的数据问题。但如果结合插件或者Restic一起使用，可以提供备份和恢复，以及基于异步备份的容灾恢复能力 – 类似OpenEBS和Kasten。但是一样也无法提供零RPO的容灾恢复能力。结语
希望这篇文章能够帮助您更多的了解Kubernetes备份和数据保护解决方案，以及它们与传统的容灾恢复方案或者备份恢复方案有什么不同。各种解决方案在目前云原生架构下的构建方式都各有不同，因此这需要用户根据自身的应用的实际情况与需要，为应用选择不同层级的数据保护机制，从而选择有效的数据保护解决方案。
参考文档：
[2] www.kasten.io/product/
[4] https://help.mayadata.io/hc/en-us/articles/360033401591-DMaaS