Kubernetes应用程序的保护和移动性策略

　　随着Kubernetes（K8s）和容器成为开发、部署、运行和扩展云原生和下一代IT应用程序的事实选择，企业正在K8s集群上运行越来越多的业务关键型应用程序。业务关键型应用程序通常是有状态的。有状态应用程序具有关联的状态、数据和配置信息，并依赖以前的数据事务来执行其业务逻辑。
　　Kubernetes上提供服务的业务关键型应用程序通常与传统应用程序一样具有可用性和业务连续性要求，这意味着服务中断（违反SLA）会严重影响提供商的收入和声誉。企业通常意识到，他们需要使用数据管理工具使其Kubernetes部署能够在影响服务的灾难之后或面临到新集群或环境的硬应用程序迁移任务时对服务故障具有恢复能力。
　　企业认识到这一需求，但使用内部开发的定制工具，这些工具很难在企业和应用程序团队之间进行扩展、应用和规范化。换句话说，这种工具是特定于应用程序的，需要为每个应用程序定制开发。因此，企业需要为其Kubernetes资产制定一个连贯一致的持久性和数据管理战略。
　　K8s应用程序数据持久性和管理的现状
　　更大的Kubernetes社区和生态系统在定义容器存储接口（CSI）方面做得非常出色，它解决了用户在有状态Kubernetes应用程序的持久存储资源调配和消耗方面的一阶问题。CSI接口还定义了数据管理原语，如对持久卷（PV）快照和克隆的支持。这些接口为存储和数据管理供应商建立综合应用数据保护和移动性解决方案奠定了基础。
　　Kubernetes数据管理（应用程序感知是关键），并不总是关于集群中的内容
　　目前还没有关于Kubernetes应用程序组成的具体定义。但是，对于大多数Kubernetes从业者和用户来说，K8s应用程序是通过包含有关应用程序的数据和元数据形成的，这些数据和元数据结合了标准K8s对象和资源（如ConfigMap、Secrets、Deployment、ReplicaSet）、Persistent Volumes（PV）和跨命名空间（在某些情况下，跨集群）的自定义资源（CRD和CRs）。因此，任何与应用程序无关的Kubernetes数据管理工具都需要考虑构成应用程序的所有这些组件。
　　如果不这样做，也不复制和/或备份与K8s应用程序关联的持久卷，则在灾难发生后恢复应用程序时，可能会导致一些严重的故障。将应用程序视为保护和迁移的整体单元是实现Kubernetes应用程序数据管理的关键。
　　使这种情况更加复杂的是主要用于公共云的云原生K8s应用程序设计模式，在公共云中，应用程序团队利用了使用完全托管的云服务（如数据库、消息队列和对象存储）的便利性、稳定性和性能。在这种情况下，根据定义，K8s应用程序不再局限于集群，而是跨集群之外的完全托管的服务。在Kubernetes集群中运行的应用程序中使用外部完全托管或自我管理的数据库是非常常见的。
　　在这种云原生开发设计模式的基础上，AWS和Azure等公共云使得通过Kubernetes原生API使用Kubernetes集群的完全托管服务变得更加容易。AWS Controllers for Kubernetes（ACK）和Azure Service Operator（for Kubernetes）就是例子。
　　Kubernetes原生持久性的替代方案——常见设计模式及其原因
　　如上所述，构建基于Kubernetes的现代服务的应用程序团队除了使用不限于K8s集群中使用持久卷的原生云服务外，还经常使用多种持久性技术。出现这种模式的原因有很多，包括但不限于：
　　——坚信Kubernetes是只运行无状态应用程序的优秀平台。
　　——在K8s集群上运行数据库的早期经验，或了解尝试这样做的失败项目。
　　——采用云原生和微服务方法，使用原生公共云DBaaS（例如AWS RDS、Google cloud SQL、Azure Cosmos DB）、第三方供应商管理的数据存储（作为SaaS提供）或自我管理的外部数据库集群构建Kubernetes应用程序，感觉很正常。这种设计范式遵守云原生设计方法，它利用这些数据服务的可伸缩性、可恢复性、弹性和灵活性，在微服务之间使用基于API的契约。
　　——使用对象存储满足K8s持久性需要，因为它在公共云中无处不在，并且广泛用于持久化现代应用程序。
　　与其他选择一样，这些持久性选择也有缺点。使用完全托管的原生公共云数据库和NoSQL数据存储可能成本高昂，并导致对一个公共云的隐式锁定。但对于那些选择单一或主要云提供商满足其IT需求的企业来说，这可能是一个不错的设计选择。为了避免云提供商锁定，采用多云战略的企业通常使用第三方ISV提供的云不可知DBaaS产品。
　　在其他情况下，他们在云提供商的保留实例上运行外部数据库集群（利用折扣保留实例定价），以节省成本。这样做，他们最终会自我管理数据库集群，这可能会很乏味。
　　使用对象存储实现Kubernetes持久性非常流行。但是，使用对象存储也会使应用程序本身的可移植性降低，因为用于访问公共云中原生对象存储服务的API不兼容，因为不支持相同的API。K8s社区正在开发一个新的标准容器对象存储接口（COSI），为使用K8s应用程序的对象存储提供公共抽象层，这将让使用对象存储的K8s应用程序的可移植性更容易。此外，对象存储不适用于许多现有应用程序，即使它们正在重构。
　　这对企业意味着什么？
　　很明显，Kubernetes应用程序的组成及其持久性需求的定义并不总是精确地映射到集群内的Kubernetes资源和连接到集群内运行的pod的持久卷。K8s数据持久性的选择非常丰富，每种选择都有其优缺点。这意味着流行的K8s应用程序数据管理功能（如备份、恢复、迁移和合规性）必须包括K8s集群内部的内容，以及可能位于集群外部且是应用程序不可分割的一部分的对象和资源。
　　例如，对K8s应用程序进行一致备份还意味着触发对完全管理的公共云数据库的备份，该数据库除了K8s资源、元数据和Kubernetes集群中存在的对象之外，还向该应用程序提供数据服务。除集群内K8s资源外，后续恢复过程还必须恢复外部数据库。
　　因此，企业必须仔细审查其K8s应用程序保护、移动性和合规性战略，并为其K8s存储和数据管理解决方案使用选择标准，以保证其应用程序团队和开发人员采用的最常见的云原生持久性设计模式。
　　原文链接：
　　https://thenewstack.io/kubernetes-application-protection-and-mobility-strategies/