logo

我们定期在项目中处理备份管理,无论是物理环境,虚拟环境还是云环境。最近,一位客户问我:“我是否也需要保存我的Kubernetes环境?如果是,应该做什么,如何做,用什么解决办法?”

这些问题,以及我们能够给他的答案,激发了我写一篇文章的灵感。这不仅是一个有趣的话题,而且我认为我们的客户并不是唯一一个提出这个问题的人。通过这篇文章,我解释了一切!

为什么要备份?

在更具体地讨论Kubernetes环境的备份之前,有必要提醒一下备份的目的。

备份用于时光倒流,主要有两个目的:

  • 克服各种原因(硬件故障,软件错误,人为错误,病毒攻击……)造成的数据损坏或丢失。
  • 满足数据保留的法律约束。

备份还可以用于其他可用性方面,例如PSI(计算机备份计划),前提是恢复点目标(RPO)和恢复时间目标(RTO)符合业务期望。

显然,无需强调的是,在当前病毒攻击越来越多的情况下,备份数据的适当安全变得越来越重要。这包括良好的网络隔离,管理特权帐户,减少攻击面或使用对象锁类型的功能(创建不可变副本)。

重要的是要记住,这一切的基础是备份策略的定义!保存是好的,但能够恢复是更好的!

 

Kubernetes环境:需要保护什么?

回到我们感兴趣的话题:保护Kubernetes环境

尽管有上述所有优点;自动化,可伸缩性,可用性……Kubernetes本身并不能保证与公司要求相对应的数据保护水平。那么我们如何正确地备份我们的应用程序呢?

尽管大多数集装箱化应用程序最初都是“无状态”的,特别是为了简化它们的移动性和可伸缩性(向上和向下),但自那时以来,情况发生了变化。事实上,今天,在Kubernetes上运行“有状态”应用程序不再是神话,因为存储管理解决方案现在已经成熟。

因此,重要的是要了解部署在Kubernetes上的应用程序的描述将包括不同的元素:应用程序配置,使用的Kubernetes资源以及数据。

 

因此,为了有一个一致的备份,您将需要备份所有这些元素。

应用程序配置

关于应用程序配置,它可以来自几个来源:

  • 直接包含在使用的容器图像中:因此,请记住保存您的图像和相关的描述文件!知道我想象你的图像存储在一个注册表上(Harbor,Dragonfly,Azure Registry,Amazon ECR……),你的文件存储在一个代码管理器上(Github,Gitlab,Azure DevOps……)。最后,我希望整件事都安全了!
  • 或者在ConfigMap或Secret类型的Kubernetes资源中,例如K8S Resources。

 

K8S重购

  • 除了这些对应用程序配置有用的资源之外,还可以在应用程序体系结构中使用其他资源。下面是应用程序体系结构的示例:

K8S ressources

在不重复Kubernetes培训的情况下,这些不同资源的状态,以及更广泛地说集群的总体状态,都保存在Kubernetes数据库:etcd中!

因此,备份这个数据库“就足够了”。这可以通过使用etcdctl snapshot save db命令创建数据库快照来手动完成。

然而,我们将看到一些解决方案可以避免手动执行此操作。

 

数据

作为提醒,为了保持它们的状态,使用持久卷,或者预先提供,或者自动提供。

显然,有几种方法可以提供持久卷,但也有几种可能的存储类型和可以使用的协议,我们将不在本文中详细介绍。

然而,无论使用何种类型的存储,在保存时都存在一个众所周知的问题:一致性!

实际上,理想的情况是,备份解决方案能够理解使用此PersistentVolume的应用程序,然后与它进行讨论,以避免服务中断,以确保备份是一致的。

简单地说,有几个元素需要保存在Kubernetes环境中:

  • 图像和相关文件
  • Kubernetes的集成基础等
  • PersistentVolumes中的数据

如果您需要重建您的K8S集群,重要的是要记住,保留与部署相关的配置及其生态系统(LB,ingress,IAM……)是必不可少的。

 

好吧,我们必须保护一个Kubernetes环境,但是用什么解决方案呢?

基于容器和Kubernetes的环境与“遗留”环境非常不同,例如基于管理程序和虚拟机的环境。这就是为什么,就像每一次进化一样,我们发现备份的“传统”参与者试图调整他们的解决方案,而新的参与者则构建“从划痕”的解决方案。

因此,在这个市场上,我们可以区分三类解决方案:

  1. 传统的,支持Kubernetes环境
  2. 云原生存储,提供数据保护功能
  3. e云原生,提供数据保护功能
  4. 云本机备份,专为这些环境设计

我们将不讨论通过直接在承载PersistentVolumes的存储阵列上制作的快照来保护数据的可能性。

你为什么要这么做?主要是由于备份和还原粒度的原因,通常是一个完整的LUN/卷的粒度,这对用户的需求没有多大帮助。

为了介绍被称为“Kubernetes数据保护”的市场参与者,我建议参考Enrico Signoretti在2020年底进行的一项比较研究“Gigaom radar kubernetes数据保护”。虽然这项研究需要更新一些新功能,但它使人们更好地了解主要解决方案的可能性。

最接近中心的解决方案被认为是价值最高的解决方案(成熟度,创新性,功能性,兼容性)。

关于最核心的解决方案,需要注意的几个要点:

没有“传统”解决方案,即使Commvault解决方案接近它。早在2017年,出版商就开始对Kubernetes产生兴趣,与其他“传统”解决方案相比,它确实取得了成功。

  • PureStorage收购的Portworx解决方案最初是一个云本地存储解决方案,提供数据保护功能。请注意,开源版本仍然有限。
  • Robin解决方案也是一种云本机存储解决方案,然而,如今,数据保护功能并没有完全集成到存储解决方案中。
  • Kasten解决方案(由Veeam收购)和Trilio是为Kubernetes环境设计的备份解决方案。
  • Velero解决方案(以前的Heption ARK)是一个开源解决方案,但主要由VMware团队维护,是VMware Kubernetes发行版(vSphere7 with K8S,TKG,TKI)的一部分。

显然,提供数据保护功能的所有解决方案都没有得到研究。事实上,CNCF景观“云原生存储”类别中的许多解决方案都具有这种功能。

我们还可以注意到一些参与者的缺席,如Cohesity或Rubrik,这两个在备份世界中很有名的解决方案,它们提供了与Kubernetes环境的兼容性。

嗯,quelle解决方案?

同样,就像原生云世界中的几个领域一样,市场仍然是分散的,这使得选择变得复杂。

成熟的解决方案?创新解决方案?“数据管理”类型的功能?

就像所有的选择一样,你必须回答的问题是:“我的需求是什么?“。

云本机备份解决方案,如Kasten,仍然是最先进的解决方案,提供最先进的功能,部分原因是它们更好地理解上下文。

无论如何,可以肯定的是:

您的Kubernetes环境必须得到保护!

在这种情况下,对于介绍中提到的客户,选择使用Kasten解决方案来保护所有这些环境。你为什么要这么做?

主要是因为前面提到的原因,但也因为他已经在使用Veeam B&R来备份这些其他环境(物理,虚拟和云),并且对此感到满意。由于Kasten被Veeam收购,客户还押注将所有游戏机集中在一个单一的#SPOG接口中。

Adrien Huerre,运营总监