找到Kubernetes原生的数据保护方法

Posted 2022-07-24 k8s中文技术社区

数据保护通常不是开发人员最关心的问题。从历史上看，开发人员只从事功能性工作是有好处的，并且可以将基础设施管理中不太令人兴奋但绝对关键的方面留给生产团队。

但是随着DevOps原则改变了行业，开发人员不再可能将生产问题留给其他团队。以整体、端到端的方式思考软件开发还包括软件开发生命周期中传统上不那么引人注目的方面，例如测试、可用性、故障切换和数据保护。

让我们深入了解Kubernetes的数据保护，以确定DevOps专业人员在思考这个重要的软件开发问题时应该遵循的一些最佳做法。

针对传统环境的数据保护

当虚拟机（VM）在应用程序部署中风靡时，数据保护是一项相对简单的任务。为了备份虚拟机，基础架构经理转向了像IBM的Tivoli Storage Manager（TSM）这样的解决方案，从根本上获取虚拟机、其操作系统、安装在其中的应用程序以及应用程序状态的快照。当出现故障并且需要恢复备份时，将正确的数据返回到正确的位置相对简单，因为所有数据都生活在一个单体虚拟机中。

然后Kubernetes出现了。起初，没有任何重大变化。Kubernete和容器主要用于无状态工作负载。任何确实需要备份的数据都存在于传统的关系数据库中，在那里，它们仍然可以通过传统的存储管理器解决方案轻松备份。到目前为止，开发和运维之间的分歧仍然根深蒂固。开发人员不需要担心存储、备份或任何与基础设施相关的问题——这些都是生产线下游人员的问题。

然而，这种模式在现代企业中正在迅速过时。

什么让现代数据保护与众不同

今天，DevOps至少是许多组织的目标（如果不是标准的话）。

实际上，这意味着改变软件开发生命周期中遗留的传统基础设施相关问题，实施基于微服务的架构，并采用云原生方法交付应用程序。对于数据保护问题来说，最重要的是，现代DevOps通常意味着在Kubernetes中管理更多的基础设施和更有状态的工作负载。

尽可能多地在Kubernetes内工作，可以在许多方面大大简化DevOps专业人员的工作。最重要的是，他们可以使用Kubernetes作为抽象层，允许他们以几乎相同的方式工作，并使用几乎相同的技能集，而不管他们的云提供商、部署方法或底层基础设施如何。

但这也意味着传统的数据保护方法不再适用。

拍摄系统快照不再是一项简单的任务，因为系统是分布式的，并分解为数百个微服务。以前，你可以在关系数据库中捕捉某个时间点的状态，但现在有状态的工作负载正在这些不同的微服务之间分布，这使得以下工作具有挑战性：

——确定哪些数据需要备份，哪些数据不需要备份。

——确定关键数据所在的位置。

——将这些数据纳入数据保护解决方案。

——跨微服务架构一致、准确地恢复数据。

——在每个环境中都以相同的方式执行所有这些操作。

数据保护解决方案

已经有开源和商业解决方案，但它们仍然需要扩展以解决所有这些挑战。

Velero（以前是Heptio Ark）是一个著名的开源解决方案，由Kubernetes联合创始人Craig McLuckie和Joe Beda创建。在商业方面，有一些解决方案与Veeam类似，Veeam收购了Kubernetes备份解决方案Kasten。

通常，这些解决方案的功能是明确地不控制如何启动和停止应用程序或获取容器中发生的事情的一致快照。相反，它们允许你在某些事件上施加前后钩子。这可能看起来像是暂停了PostgreSQL数据库。然后，数据保护解决方案可以采取不同的备份操作：它可以调用Kubernetes容器存储接口（CSI），拍摄快照，写入与S3兼容的存储桶，或者采取各种不同的方法，这些方法或多或少适合你的应用程序。然后，你可以定义一个后钩子来执行操作。

获取一致快照有两种主要方法，第一种是逻辑备份。当你正在恢复到时间戳并使用应用程序级智能（插入事务日志）时，将使用逻辑备份，这将在本文中介绍。第二种方法是物理级备份，你可以使用CSI插件在存储块级别创建快照。然后可以像以前一样将其流式传输到与S3兼容的远程目标。

对数据保护左移感兴趣的DevOps专业人员可能会在他们的集群上启动其中一个解决方案，熟悉其操作，并发现它并不太理想。

是的，这些现代数据解决方案在分布式、基于微服务的架构中可以有效地备份和恢复数据。但它们并不是在每个环境中都以相同的方式发挥作用。因此，如果你依赖多个云提供商，拥有一个混合环境或打算在未来扩展到多个环境，那么用它们可能会很麻烦，需要团队在管理和配置上花费额外的时间，并降低自动化能力。

以Kubernetes原生方式考虑数据保护

尽管在Kubernetes中集中应用程序基础设施迫使我们找到新的方法来提供一流的数据保护，但许多DevOps专业人员仍然选择使用Kubernetes，因为它使业务应用程序的开发变得更加容易。它使处理多个环境变得非常简单。我们需要的是一种数据保护方法，该方法与Kubernetes类似并与Kubernetes一起工作，从而使其功能相同，而不管底层基础设施如何。

随着更多有状态的应用程序部署到Kubernetes中，对Kubernetes原生数据保护解决方案的需求增加。无论这些数据是消息队列、数据库还是AI/ML工作负载，都需要由集成到Kubernetes生态系统中的可靠、高性能和安全的存储层来支撑。

这就是Ondat的由来，它是一种通过容器存储接口交付的软件定义的存储解决方案，用于向工作负载交付块和文件持久卷。通过对CSI快照的支持，它可以用于为Kubernetes工作负载构建数据灾难恢复和业务连续性战略。

在这里（https://www.ondat.io/platform/how-it-works）了解更多关于Ondat和Kubernetes的持久存储的信息。或者，如果你想亲自尝试Ondat，请在此处（https://www.ondat.io/request-demo）请求demo。

原文链接：

​​https://thenewstack.io/identifying-a-kube-native-approach-to-data-protection/​​