在 Kubernetes 上管理云原生数据

第 1 章 云原生数据基础架构简介：持久性、流和批量分析

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

您是否在解决数据问题的过程中发现自己面临着现代化的需求？您的云原生应用是否仅限于使用微服务和服务网格？如果您在 Kubernetes（有时缩写为 "K8s"）上部署应用程序而不包括数据，那么您还没有完全接受云原生。您应用程序的每个元素都应体现云原生的扩展性、弹性、自愈性和可观察性原则，包括您如何处理数据。

从事数据工作的工程师主要关注有状态服务，这将是我们的重点：提高您在 Kubernetes 中管理数据的技能。通过阅读本书，我们的目标是丰富你的云原生数据之旅。如果你刚刚开始使用云原生应用程序，那么现在是将堆栈的各个方面都包含在内的最佳时机。这种融合是未来我们将如何消费云资源 。

那么，我们共同创造的未来是什么呢？

长期以来，数据一直生活在 Kubernetes 之外，造成了大量额外的工作和复杂性。我们将讨论其中的合理原因，但现在是将整个堆栈结合起来，以更快的速度和所需的规模构建应用程序的时候了。基于当前的技术，这是完全可能的。我们已经摆脱了过去部署单个服务器的时代，未来我们将能够部署整个虚拟数据中心。过去需要数月甚至数年的开发周期，现在只需数天或数周即可完成。开源组件现在可以组合成 Kubernetes 上的单个部署，从你的笔记本电脑到最大的云提供商都可以移植。

开源贡献也不小。除非另有说明，Kubernetes 和我们在本书中讨论的项目都采用 Apache License 2.0，这是有道理的。如果我们要构建可在任何地方运行的基础架构，就需要一种能让我们自由选择的许可模式。开源既像啤酒一样自由，也像自由一样自由，在 Kubernetes 上构建云原生应用时，这两者都很重要。开源一直是基础设施领域许多革命的推动力，这次也不例外。

这就是我们正在构建的：不久的将来完全实现 Kubernetes 应用的现实。最后一个组成部分是最重要的，那就是你。作为本书的读者，您是创造未来的人之一。创造是我们工程师的工作。我们不断重塑部署复杂基础设施的方式，以应对日益增长的需求。1960 年，当美国航空公司的第一个电子数据库系统上线时，一小队工程师确保了该系统的全天候在线运行。随着时代的进步，我们从大型机到微型计算机，再到微机，最终实现了今天的机队管理。现在，同样的进步正在延续到云原生和 Kubernetes。

本章将研究云原生应用程序的组成、运行有状态工作负载所面临的挑战以及本书所涉及的基本领域。首先，让我们来看看构成数据基础架构的构件。

基础设施类型

在过去的 20 年中，基础架构的方法慢慢分叉成两个领域，反映了我们部署分布式应用的方式（如图 1-1 所示）：

无状态服务

例如，向移动客户端发送格式化购物车信息的服务。一个典型的例子是执行购物车业务逻辑的应用服务器。然而，购物车内容的相关信息却位于这些服务的外部。从请求到响应，它们只需要在线一小段时间。用于提供服务的基础设施可以很容易地增长和收缩，而对整个应用的影响很小，在需要时可以按需扩展计算和网络资源。由于我们没有在单个服务中存储关键数据，因此数据可以快速创建和销毁，几乎不需要协调。无状态服务是分布式系统的重要架构元素。

有状态服务

这些服务需要从一个请求到下一个请求维护信息。磁盘和内存可存储数据，供多个请求使用。数据库或文件系统就是一个例子。有状态服务的扩展更为复杂，因为信息通常需要复制以实现高可用性。这就需要一致性和机制来保持副本之间的数据同步。这些服务通常有不同的扩展方法，包括纵向和横向扩展。因此，它们需要与无状态服务不同的操作任务集。 ...