Kubernetes如何征服有状态的云原生应用程序

最新推荐文章于 2024-08-06 07:15:00 发布

cxu0262

最新推荐文章于 2024-08-06 07:15:00 发布

阅读量182

点赞数

文章标签：数据库运维操作系统

Niraj Tolia是Kasten的联合创始人兼首席执行官。

人们普遍认为Kubernetes尚未为MySQL和MongoDB等有状态应用做好准备，其半衰期非常长。这种误解是由最初对社区内无状态应用程序的关注与相对较晚地向平台添加持久存储支持的结合所驱动的。

此外，即使在最初支持持久性存储之后，有状态工作负载仍缺少为无状态应用程序带来易用性和灵活性的高级平台原语。但是，不仅解决了这个缺点，而且KubernetesSwift成为有状态云原生应用程序的首选平台。

[比较容器操作系统： Alpine Linux ， CoreOS容器Linux ， RancherOS ， Red Hat Project Atomic和VMware Photon OS 。 | 了解如何使用Kubernetes入门。 | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

如今，人们可以为所有主要的公共云提供商以及用于本地或混合环境的领先存储产品找到一流的Kubernetes存储支持。尽管Kubernetes兼容存储的可用性已成为一个重要的推动因素，但Kubernetes对容器存储接口（CSI）规范的支持甚至更为重要。

CSI计划不仅为跨容器协调器的存储供应商引入了统一的接口，而且还使为新存储系统提供支持，鼓励创新以及最重要的是为开发人员和运营商提供更多选择变得更加容易。

尽管增加对Kubernetes的存储支持是一个受欢迎的趋势，但这不是有状态的云原生应用程序成功的充分理由也不是主要理由。退一步，Kubernetes这样的平台成功的背后动力是，它专注于开发人员和应用程序，而不是供应商或基础架构。作为响应，Kubernetes开发社区做出了巨大贡献，创建了适当的抽象，以弥合磁盘和卷等原始基础架构与使用该基础架构的应用程序之间的鸿沟。

Kubernetes状态集，运算符和Helm图表

首先，为了使构建有状态的应用程序更加简单，以构建块（例如StatefulSets）的形式添加了对编排的支持。 StatefulSets自动处理从容地扩展和升级有状态应用程序以及在容器重新启动时保留网络身份的难题。 StatefulSet为构建，自动化和操作高可用性应用程序（例如数据库）提供了良好的基础。

其次，为简化大规模且无需人工干预的有状态应用程序的管理，引入了“运算符”概念。 Kubernetes Operator用软件对用于操作复杂应用程序的手册进行编码。在针对MySQL ， Couchbase和多数据库环境发布的运算符中，可以清楚地看到这些运算符的好处。

结合这些编排方面的进展， Helm的兴旺发展（等同于Kubernetes的软件包管理器）使不仅可以轻松部署不同的数据库，而且还可以部署依赖多个数据存储的高级应用程序（如GitLab）。 Helm使用一种称为“图表”的打包格式来描述应用程序及其Kubernetes资源。单行命令可以帮助您入门，而且Helm图表可以轻松地嵌入到较大的应用程序中，以提供任何堆栈的持久性。此外，以开放源代码图表的形式提供了多个参考示例，可以根据自定义应用程序的需求轻松对其进行自定义。

Kanister和K10平台

在Kasten，我们一直在进行Kanister和K10这两个项目，这使得开发人员和操作人员都可以轻松地使用上述所有功能。在大量客户投入的推动下，这些项目不仅消除了Kubernetes固有的一些技术复杂性，而且还提供了跨应用程序和云的大规模统一操作体验。

开源项目Kanister受到对通用和可感知应用程序的数据管理平面的日益增长的推动，该平面可支持多种数据服务并在应用程序级别执行数据管理任务。如今，开发人员经常为单个应用程序使用多个数据源（多语言持久性），使用最终一致的数据服务（例如Cassandra），并具有复杂的要求，包括一致的数据捕获，自定义数据屏蔽以及以应用程序为中心的备份和恢复。。

Kanister通过为数据相关操作（例如备份，还原，屏蔽等）提供统一的控制平面API来解决这些挑战。同时，Kanister允许域专家以蓝图或配方的形式捕获特定于应用程序的数据管理操作。轻松共享和扩展。尽管Kanister基于Kubernetes Operator模式和Kubernetes CustomResourceDefinitions ，但是这些细节对开发人员是隐藏的，从而使他们可以专注于应用程序对这些数据API的要求。他们无需学习如何编写Kubernetes Controller，而只是使用自己喜欢的任何语言（从Bash脚本到Go）编写其数据服务的操作。今天，公开的示例涵盖了从MongoDB备份到与PostgreSQL的时间点恢复功能的深度集成的所有内容。

尽管Kanister在应用程序级别处理数据，但是在分布于集群，云和开发环境中的多个应用程序和微服务中管理数据时，运营商也面临着严峻的挑战。我们在Kasten推出了K10平台，使企业可以轻松地大规模构建，部署和管理有状态的容器化应用程序。通过以应用程序为中心的独特视图，K10使用策略驱动的自动化为云原生应用程序提供诸如合规性，数据移动性，数据处理，审计和全局可见性等功能。对于有状态应用程序，K10消除了许多用例的复杂性，包括备份和恢复，跨集群和多云应用程序迁移以及灾难恢复。

有状态Kubernetes的状态

对有状态的基于容器的应用程序使用的不断增长推动了对诸如Kanister和K10平台之类的产品的需求。 Kubernetes应用程序特别兴趣小组最近进行的一项调查显示，超过50％的用户在其Kubernetes集群中运行某种关系数据库或NoSQL系统。这个数字只会增加。

此外，我们不仅看到传统的数据库系统在云原生环境中的使用，而且还看到了以真正的云原生方式专为弹性，可管理性和可观察性而构建的数据库系统的增长。随着诸如Vitess ， YugaByte和CockroachDB之类的下一代系统的成熟，期望在这一领域看到更多的创新。

当我们翻开有状态云原生应用程序演变的第一章时，未来既有机遇，也有挑战。鉴于Kubernetes等云原生平台提供了真正的云可移植性，因此在多集群，多云甚至星球级环境中移动应用程序数据将需要开发一种新型的分布式系统。

数据引力是需要克服的主要挑战。需要新的高效分配和传输算法来解决光速问题。要使企业平台运营商能够以这些新型云原生平台实现的空前规模工作，就需要对这些环境中的数据的管理方式进行以应用程序为中心的重新思考。我们在Kasten上使用K10企业平台和Kanister所做的事情不仅解决了这些问题，而且为真正的云原生数据管理奠定了基础。

Niraj Tolia是 Kasten的 联合创始人兼首席执行官， Kasten 是一家致力于云原生存储基础架构的早期创业公司。 在此之前，他曾是EMC / Maginatics的软件工程高级总监，负责CloudBoost系列产品，这些产品专注于云数据保护。 在EMC收购Maginatics之前，他是Maginatics团队的创始成员，并在公司内部担任过多个角色，包括工程副总裁，首席架构师和人事工程师。 Niraj在卡内基梅隆大学获得了计算机工程博士学位，硕士学位和理学学士学位。

新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们对InfoWorld读者认为最重要和最感兴趣的技术的选择。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到 newtechforum@infoworld.com 。