Kubernetes备份的原因、时间和目的

在数据保护方面，Kubernetes 是最容易被误解的新技术之一。有几件事导致了这种混乱，包括：

——Kubernetes作为用于无状态应用程序的解决方案的传统。

——使用基础设施作为存储库中的代码自动部署应用程序甚至整个集群的趋势。

——云中的组织责任线模糊。

——Kubernetes 倾向于由没有传统 IT 运维背景的开发或 DevOps 团队管理。

相同也不同

在许多方面，备份 Kubernetes 的要求与其他关键 IT 基础设施的要求相同，但在一些方面却大不相同。

对于传统的服务器基础设施，通常假设运行生产应用程序的所有服务器或虚拟机以及对开发至关重要的所有系统都将得到备份。其他用于测试/QA 和登台的系统通常被排除在外，但也可能为了方便或尽量减少可能的开发计划中断而进行备份。这些备份可以在服务器或虚拟机级别、存储级别，或者更有可能在两者上完成。这个过程虽然不一定简单，但很好理解。

对于云基础设施，还必须备份基础设施本身的配置数据。如果使用 IaC 工具自动部署云基础设施，则应备份包含 IaC 文件的存储库。但通常这并没有完成，当完成时，必须希望实际配置没有偏离部署的配置。云中的存储卷可能包括不同类型的复制和快照功能，但这些需要进行管理，并且通常不能替代应用级备份。在云中运行并不会消除对备份的需求，它只会改变需求。

Kubernetes 增加了一层额外的复杂性。集群被强加在底层节点或虚拟机上，其配置可能会随着时间而改变。最重要的是，部署了容器化应用程序，这些应用程序可能需要各种类型的持久存储卷，并且可以创建自定义资源或以其他方式修改集群状态。

几种方法，相同的结果

有多种方法可以保护 Kubernetes 和在其上运行的应用程序，但不足为奇的是，最好的方法是使用真正了解 Kubernetes 的解决方案。你可以使用仅在存储级别保护基础持久卷 (PV) 的工具，或者可以备份基础节点，如果它们是虚拟机，这可能很容易。但是，当想要恢复时，情况如何？很有可能你只想恢复单个命名空间、单个 PV，甚至单个资源（例如秘密）。不了解 Kubernetes 的传统备份工具对此无济于事。

有状态的应用程序在 Kubernetes 下运行变得很常见，它使用持久卷，甚至经常在其上运行数据库。与在传统服务器基础设施上运行的数据库一样，获得一致的备份可能需要以“钩子”形式的应用程序感知，以便在创建卷快照之前使数据库或应用程序静默。在 Kubernetes 上，这些钩子还必须是集群感知的，以便它们被定向到正确的节点和容器。

备份或不备份

你可能认为Kubernetes 集群根本不需要备份，因为它只运行无状态应用程序，并且使用 CI/CD 管道和来自 git repo 中的文件的 IaC 工具自动部署所有内容。这可能是真的。但你确定可以按照五分钟前、两周前或九个月前的方式轻松重建该环境吗？确定自从集群由部署工具创建后没有任何配置偏差？你确定吗，即使你可能不使用 PV，重要的应用程序状态也不会被存储为 Kubernetes 自定义资源、CronJob 条目等？你的秘密和证书是否受到保护？最重要的是，你确定开发人员上个月告诉你的关于集群上缺少应用程序状态和可能的配置漂移的内容今天仍然适用吗？如果你选择放弃备份，请务必持续与所有利益相关者核实它是否仍然合适。然后忽略他们告诉的内容并定期从头开始测试完整的重建。安全总比后悔好。

高可用性与备份

Kubernetes 和云基础设施一起可以为你的应用程序提供出色的高可用性平台。跨多个可用区或区域的基础架构冗余和复制可以提供容错和应用程序级弹性。但高可用性不能替代备份。HA 解决方案可防止由于物理故障（例如磁盘、节点、电源、网络连接故障，以及通过适当设计，甚至是整个站点的故障）导致的数据丢失和不可用。但它们无助于防止逻辑故障。由于 RAID 和卷复制的使用在 1990 年代变得普遍，数据中心的物理故障很少成为恢复请求的原因。数据丢失和后续恢复的主要原因是逻辑错误：用户错误、软件错误、运维人员错误和安全漏洞。使用高度可用的云解决方案并不能免除你通过备份保护应用程序和数据的责任。

快乐的结果

在决定如何、何时以及是否保护 Kubernetes 集群时，请仔细考虑原因。一个好的和正确配置的备份解决方案可能会影响 Kubernetes 体验的好坏。

我们听说过许多保护 Kubernetes 的方法，以及为什么客户不这样做或不认为需要备份它的许多原因。其中一些原因是可以理解的，而另一些则不是。有时，这些决定会导致不愉快的结果，所以请认真对待。

原文链接：

https://thenewstack.io/the-whys-whens-and-wherefores-of-kubernetes-backup/