Kubernetes面临的数据保护挑战

Kubernetes作为容器编排的事实上的标准，将加速企业数据中心编排和现代化工作进程。如今，从SMB到大型企业，各个垂直领域和细分市场的公司都已采用容器，来进行开发云原生产品。

但是，随着Kubernetes的采用，DevOps工程师将容器作为新的虚拟机，并开始将有状态应用程序迁移到容器。随之而来的容器扩展和集群扩展，组织也面临越来越多的数据保护挑战。

企业容器化之旅

为什么DevOps工程师采用持久卷，管理有状态应用程序？简单：敏捷。

Kubernetes允许开发人员根据业务需求进行配置，测试，甚至扩展其应用程序。如果组织从传统的单体应用程序开始，第一步是要完成从虚拟机到容器的迁移。

企业需要重新学习，如何利用云原生技术的按需性质和弹性功能来响应客户需求。

从上图，我们看到从虚拟机应用于容器空间，经历了多个重构阶段，随后采用了灵活的软件定义存储，以简化大规模的存储管理。其中理想状态是微服务架构，许多企业也正在努力实现该架构。

当前的挑战

Kubernetes 所缺少的是，端到端数据管理的基础工具和自动化。

有一些项目试图尝试解决（以前是Heptio Ark和Velero，现在是VMware Tanzu）。还有Kubernetes Storage SIG和最近成立的数据保护工作组（WG）。

目前，仍然存在一些需要解决的基本挑战：

• Kubernetes中应用程序的定义是什么（请参阅v1beta1 Application CRD）？
• 开发人员如何记录应用程序中的依赖关系（例如，自定义资源或三方资源）？
• 如何在多租户Kubernetes集群中工作（请参阅分层命名空间(Hierarchical Namespace )概念）？

除此之外，如果我们查看正在积极迁移到Kubernetes应用程序的传统单体应用程序，我们会发现另一个挑战—应用程序一致性。

应用程序一致性是，协调应用程序状态和数据保护操作（备份，存储快照等）的行为。

Kubernetes 存储注意事项

必须使用快照机制实现存储一致性，这样就可以在不影响正在运行的应用程序的情况下提供在线或“实时”保护。

很多组织，是通过使用传统的企业存储阵列技术，来了解并采纳基于快照的数据保护。在允许将传统应用程序批量迁移到容器前，快照，克隆和备份是必须提前考虑的重点。

随着企业采用各种各样的存储解决方案，需要采用云原生方法进行存储管理（API驱动，开放接口，无缝可伸缩性）。Container Storage Interface (CSI) 就是一种云原生的做法，支持动态配置，安装/拆卸，并且mount 能力是稳定的，但是其中快照功能尚未全面可用。

应该注意的是，CSI虽然提供了一种基于时间点存储快照的方法，但是它并没有将该快照转移至其他存储介质。因为，快照被认为是“恢复点”，并且需要复制到云，磁盘或磁带介质上，才被视为真正的“备份副本”。

目前，数据保护工作组正在应对这一挑战。

应用弹性的实现方法

根据企业可用的开发资源，应用弹性可能采用以下两种灾难恢复方法之一：

• 以应用程序为中心的灾难恢复，它专注于捕获整个Kubernetes应用程序（清单，持久性数据，相关资源），并将它们重新安排在远程集群中。这种方法可以完全自动化，而无需依赖应用程序所有者。
• 以基础架构为中心的灾难恢复，它专注于利用下一代软件定义存储（SDS），可以通过自定义资源（CRD）将其紧密集成到Kubernetes中，以从Kubernetes命令（即kubectl）提供调度，复制，克隆和恢复。

这两种方法都是有效的，但是会带来不同级别的IT运营资源，应用程序开发资源以及相关的自动化。由于恢复事件通常是对意外事件的响应，因此需要智能自动化来驱动一致的恢复结果并满足业务恢复时间目标（RTO）。

超越Kubernetes集群

基于Kubernetes或基于容器的应用程序，他们是由分布在整个组织中的许多新数据类型组成。

在最近的KubeCon欧洲大会上，经验丰富的Kubernetes资深人士表示希望不要“绕过CI / CD，代码审查和正式发布过程“。

为了使容器化成为下一代应用程序环境的基础构建块，需要数据保护最佳实践。

例如：

• 你是否在保护开发人员工作站？
• 你是否在保护源代码控制系统和CI/CD系统？
• 如果你的CI/CD系统不可用，对客户会有什么影响？
• 你是否在保护本地集群的etcd数据？
• 你是否正在运行自己的私有镜像仓库，如果是，它们是否受到保护（goharbor.io）？
• 你将如何保护现代持久性存储（如云对象存储）？

考虑端到端挑战

当我们退后一步并回顾这些挑战时，我们必须反思为什么我们要执行数据保护和数据管理。

• 我们需要将失败的应用程序，恢复到生产环境中。
• 我们需要将失败的应用程序或容器，恢复到备用位置（灾难恢复）。
• 我们需要为迁移应用程序（即，部署新集群）。
• 我们需要通过整合基础架构，来优化我们的部署。
• 我们需要根据明确的SLA，保护应用程序。
• 我们需要交付功能，而与工作负载的位置（本地，云）无关。

这些挑战需要企业具备数据管理功能，包括：

• 在所有Kubernetes部署中基于策略的集中式保护。
• 提供整个集群的报告，仪表板，警报。
• 自助备份，恢复和授权访问管理。
• 集成到单点登录（SSO）系统中，以提供基于角色的细粒度访问控制。
• 基于策略的控制，用于访问和使用受保护的数据。
• 报告，审计，日志和持久性数据的监管能力，以满足法规要求。

如今，许多数据保护解决方案都依赖于捕获应用程序清单和持久性数据。保护的调度是逐个集群进行的，在多个集群中实施可见性很小。此外，安全的多租户集群的最佳实践以及与Open Policy Agilent（OPA）等技术的集成尚未成熟。

Kubernetes已经提供了应用程序移动性，现在可以将应用程序从一个集群编排到另一个集群。未来的挑战将需要策略控制，警报甚至Kubernetes manifest 转换，以支持不同集群版本和技术之间的迁移。

一个数据保护的标准–允许第三方数据保护供应商的接入，是迫切需要的。

译文链接：https://thenewstack.io/the-data-protection-challenges-of-kubernetes/