Kubernetes 是公有云中应用程序部署的事实标准。然而，随着企业将更多的工作负载迁移到 K8s，经常遇到应用程序稳定性的的问题。

在业务连续的场景中，在不同区域及云厂商的不同集群上恢复具有相同配置的应用程序可能相对容易，但应用程序需要数据才能运行，恢复一个应用程序的状态是非常复杂的。

试图为 K8s 的有状态应用程序构建高可用性环境以履行其服务水平协议(SLA)并维护应用程序和数据可用性的企业面临着以下挑战。

复杂性

使用 Kubernetes 的主要问题之一是难以为有状态应用程序设置存储，同时保持弹性和应用程序移动性。公有云中的标准解决方案还有待改进，任何超出标准解决方案的东西都需要大量的专业知识来设置和维护。因此，通往有状态、有弹性的运营之路还很漫长。它需要存储、网络和迁移方面的知识。许多团队缺乏做这件事的资金、人力或专业知识。

困难在于，构建存储基础设施所需的技能与大多数 DevOps 专业人员受过培训的技能有很大不同。大多数云原生团队缺乏存储专家的专业知识，他们接受过配置和维护专门的存储网络和设备的培训，以确保所有的存储都是可用的、有弹性的和有备份——前提是可以访问公有云中的高级存储解决方案的话。

供应商选择受限

由于存储和基础设施来自特定的供应商(EBS、Azure Disk 等)，供应商选择受限和数据重力问题是不可避免的。数据重力(即某个位置的数据量)越大，未来就越难转移到其他地方。应用程序不断被拉到数据所在的位置，而过去的数据存储选择决定了其未来的位置。

当数据转移到公有云时，服务提供商不可避免地会影响应用程序的性能。

弹性挑战

说到弹性，仅仅依靠单一的云提供商有很大的局限性。然而，由于为有状态的应用程序建立跨区域或多云基础设施过于复杂，大多数组织除了依赖单一的云提供商或区域之外，别无选择。

即使在不同的可用性区域之间迁移数据，仍然存在区域故障的风险。因此，为了给运行在云中的有状态应用程序提供业务连续性，需要能够立即在第二站点或区域进行恢复，才能不丢失任何数据。

风险

风险是不可避免的。但是，当你的稳定性计划只是在 AWS 或谷歌云(统计学上故障最少)上运行你的业务时，就有麻烦了。

臃肿的基础设施

此外，由于数据没有其应用就一文不值，为了让有状态的 K8s 应用在不同的基础设施和公有云厂商之间恢复，整个应用环境包括应用状态必须被复制，并且完全不受应用所运行的底层基础设施的影响。

随着时间的推移，这些基础设施变得越来越臃肿。对于一个拼命尝试维持稳定的团队来说，需要额外的变通方法的操作，就变得难以忍受了。

解决公有云弹性之谜

随着复杂性的增加，对更复杂的弹性、性能和操作技术的需求也在增加，这就需要有一种方法让复杂的事情变简单。

为了解决这些问题，出现了一个新的类别。Stateful application mobility platforms. 这些平台允许用户配置有状态的应用程序，而不用担心它们是如何配置或部署的，允许有状态的应用继续不间断地运行，并能够在另一个位置恢复，而不会出现数据丢失。用户可以放心，他们的集群可以在云厂商、区域和数据中心之间移动。

这将带来更大的灵活性、更高的性能和更好的弹性，最终，通过允许有状态的应用在不同地点之间自由移动来简化它们的运行位置，使企业能够利用“云”的能力，同时避免其局限性。

通过使用这些平台，无论应用程序部署在哪里，数据都是可用的。

这个多云一键部署的可伸缩的存储解决方案，实现了有状态的 Kubernetes 的稳定性。