使用容器运行应用程序并通过 Kubernetes 编排其生命周期，已经改变了团队管理大规模部署的方式。 容器通常用于执行短生命周期的任务，例如发送消息，或运行不需要存储信息的应用程序，例如 Web 服务器。 可以创建一个新的容器，它不知道之前发生的任何工作——换句话说，是“无状态的”——这对大多数应用程序来说完全没问题。
数据库系统的重要部分是它维护状态：一个进程在运行时可以修改磁盘上的数据状态，并且即使在进程终止后，该状态也会被维护。 换句话说，当您使用数据库系统时，无论您的系统是否正在运行，您的数据都必须始终存储在磁盘上。
表面上看，这与“无服务器”世界相矛盾：对于数据库来说，即使在进程终止后，保持状态也很重要。 但是，如果应用程序能够为 Kubernetes 提供关于如何在 Pod 生命周期之外维护状态的额外知识，那么数据库不仅可以利用 Kubernetes 的编排功能，而且团队突然有能力运行自己的数据库即服务平台。
Kubernetes Operators & PostgreSQL
Kubernetes Operator 是一种应用程序，允许开发人员向 Kubernetes 提供关于如何管理有状态应用程序的额外上下文。 Operator 允许开发人员提供更多特定于应用程序的知识，以正确维护有状态应用程序的完整生命周期，并确保关键资产（例如数据）保持安全和可访问。
对于数据库，例如流行的开源 PostgreSQL 数据库，Operator 可以帮助执行以下操作：
- 配置：分配将永久存储数据的磁盘空间
- 扩展：安全地创建数据库的副本（或拷贝），并始终保持最新状态
- 高可用性：确保即使节点变得不可用，应用程序始终可以读取和写入数据库
- 用户管理：启用用户访问并记住环境中特定数据库的权限
其他操作要求包括使用特定版本的数据库软件，使用特定的存储系统或硬件配置，或者将数据库部署到集群中的特定服务器节点。
Crunchy Data 的开源 Crunchy PostgreSQL Operator 是一个用于 PostgreSQL 的 Operator，已在许多生产环境中使用。 它提供了一个简单而强大的 命令行界面，使用户能够在任何支持 Kubernetes 的平台上部署自己的 数据库即服务系统。
例如，使用 pgo create 命令（用于配置数据库），您可以设置一个分布式、高可用性的 PostgreSQL 集群，它具有完整的灾难恢复支持以及由 pgMonitor 提供支持的数据库监控 sidecar。 换句话说，无需复杂的多步骤流程或编写自己的脚本，您可以从单个命令创建生产所需的 PostgreSQL 系统类型。
如果您只管理几个数据库集群，这似乎有点过分，但如果您需要支持数百或数千个不同的集群，Operator 的价值会显着提高。 拥有一套标准化的命令，能够灵活地为不同的工作负载部署集群，既减轻了管理负担，又为团队如何开发和部署工作负载到生产环境提供了更多选择。
开源即服务
虽然许多大型云提供商提供各种“即服务”的开源平台，但这会使人们锁定到特定的云基础设施中。 使用 Kubernetes 和像 Crunchy PostgreSQL Operator 这样的开源 Operator 允许用户选择他们想要运行其有状态服务的云环境（有 Kubelet，就可以迁移！），同时从标准化接口管理它们。
Jonathan Katz 将在 3 月 7 日至 10 日在加利福尼亚州帕萨迪纳举行的第 17 届年度南加州 Linux 博览会 (SCaLE 17x) 上展示 使用 Kubernetes 扩展 PostgreSQL。
评论已关闭。