【翻译】持续的一切：为什么你需要为Kubernetes提供更好的备份和DR？

Zerto的特邀文章

在之前的一篇博文中，我们谈到了容器状态，以及容器的只读、无状态特性如何迫使应用架构师重新思考哪些数据被存储在哪里，以防止数据丢失和配置问题。

同样，数据保护也需要从头开始建立，以支持这种截然不同的方法。

有什么不同？

保护应用程序的容器和持久性存储只是战斗的一半。

当然，你可以从集群和任何持久性存储卷中备份容器镜像、其运行状态和配置，但这只能保护当前状态，而不是未来状态。

随着新的容器不断从应用程序的新版本中构建，创建这些容器的管道是你的数据保护策略的关键部分。

这是因为对于云原生的内部应用程序，构建部分与运行部分同样重要。运行应用程序可以照顾到现在，但未来，尚未释放的潜力是在构建部分。有可能的是，与运行当前版本相比，构建下一版本的应用程序所涉及的人员和投资数量相等，甚至可能更多。

持续的一切

新的代码要经过自动化管道：由许多步骤组成的工作流程，自动测试代码、构建容器和部署到生产。

我们需要确保将数据保护整合到这些管道中，确保每个新版本都能以完全自我服务的方式，用正确的保护策略自动保护。这样一来，我们不仅要捕获最终结果--容器图像，还要保护构建该最终结果的完全记录的过程和工作流程：生产图像的软件工厂，包括所有必要的配置脚本（如Dockerfiles和Kubernetes YAML文件）和文档。

由于管道中有许多不同的系统，如代码库、构建服务器、测试工具等，跟踪特定应用程序的所有相关配置并非易事，特别是在测试、验收、暂存和生产等不同环境中；这还没有考虑多云的复杂性，或使用多个云可用区。

这就是为什么采用 "一切皆为代码 "很重要。配置是'作为代码'写的：描述云资源、应用部署、监控和数据保护的理想状态的语言。

通过将持续的数据保护整合到应用程序的开发和部署生命周期中，应用程序不仅在生产中得到保护，而且也是开发生命周期的一部分。自然，作为CI/CD管道的一部分，有必要保护创建容器的系统，这一点经常被遗忘。通过保护这些工作负载，生产容器镜像的 "工厂 "就能保持安全。

对于数据保护来说，这意味着不仅要备份容器镜像本身，还要备份其来自Kubernetes YAML的部署配置、相关秘密、持久化存储和构建管道，如代码库、构建和测试自动化。这些元素可能是在数据中心运行的虚拟机，需要由现有的数据保护解决方案进行保护。

这些策略改变了工程师与数据保护互动的方式。数据保护不再需要与一个单独的用户界面互动，而是成为应用部署管道中应用配置规范的一个自然、完全自助的部分。数据保护是通过将策略应用于容器构建工作流来配置的。

基于策略的操作的这些自助服务和按需操作方面是使用数据保护即代码方法的关键好处，消除了开发和运营团队之间的依赖性。

想了解更多吗？

这篇博文只触及到表面，所以请到CNCF的网络研讨会上了解更多。