Kubernetes多云架构：构建无锁定的可移植数据库
大多数组织如今都在多个云平台上运行，以追求灵活性、更优定价或区域可用性。然而，虽然无状态应用可以自由迁移，但数据库往往被锁定在原地。每个云提供商都提供自己独特的托管数据库服务（如 RDS、Cloud SQL、Azure Database），拥有不同的 API、自动化工具和监控层。一旦你选择了其中一种，迁移就会变得复杂且昂贵。这就是为什么许多所谓的“多云”架构实际上并非真正的多云。应用程序可能是可移植的，但数据肯定不是。特定于供应商的服务创建了看不见的壁垒，使得真正的可移植性几乎不可能。
Kubernetes 通过在不同环境间提供一致的基础设施改变了这一局面。它提供了一个在任意云平台或本地硬件上运行数据库的统一平台，使用完全相同的配置和自动化工作流。再加上 Kubernetes Operator，这一模式就变得切实可行。数据库可以在任何地方以与托管服务相同的可靠性进行部署、扩展和恢复。这才是真正的可移植性：一种可以在你需要的地方运行的架构，而无需每次都从头开始。
真正的数据库可移植性意味着什么
数据库可移植性意味着无论在何处运行，都能保持行为、性能和管理的一致性。当一个数据库可以在不同环境中被部署、扩展、备份和恢复，而无需重新配置或依赖特定于提供商的功能时，它才是真正可移植的。你的数据库应该在每个地方都表现一致。
这意味着在云中或甚至本地的集群中使用相同的配置文件、监控堆栈和自动化工作流。这意味着无论工作负载位于何处，备份和恢复都遵循相同的流程，故障转移的工作方式也相同。
专有的数据库即服务（DBaaS）平台在设计中就阻止了这一点，每个平台都有自己的 API、监控工具和维护例程。即使是基本操作也可能依赖于供应商特定的实现，而这些依赖正是锁定你的根源。
Kubernetes 用一个一致的操作模型取代了这些差异。使用声明式配置，你只需描述一次数据库的期望状态，然后将其应用到任何地方。随后，Operator 和自动化确保每个环境都符合该定义。当一切都以这种方式配置时，可移植性就会作为系统的一部分自然而然地实现。
构建Kubernetes多云架构
跨多个云平台运行数据库始于一个原则：一致性。无论架构的任何部分在哪里运行，其行为方式都必须相同。没有这种一致性，可移植性就会变成手动的努力和故障排除，而不是自动化和控制。
首先是存储抽象。Kubernetes 使用持久卷（PersistentVolumes）和存储类（StorageClasses）将数据库连接到任何云中的块或文件存储。通过定义如何通过 Kubernetes 而非云 API 来配置和附加数据，你可以保持该层的可移植性。StatefulSet 在重启和故障转移期间维护数据库的身份标识，因此即使在扩展或恢复期间，集群的行为也是可预测的。
接下来是网络可靠性。数据库依赖低延迟和稳定连接，因此集群之间的网络至关重要。VPN、服务网格和私有对等互连有助于维持跨云的安全一致通信。这对于复制和高可用性尤其重要，因为中断可能导致数据延迟或故障转移偏差。
自动化和编排为系统带来了可重复性。声明式配置确保数据库部署被定义一次并一致地应用。使用 CI/CD 或 GitOps 工作流，可以在安全地推出更改的同时保持环境同步，无论你是更新配置还是修补软件。
可观测性提供了统一的视图。通过 Percona 监控和管理（PMM）等工具进行的统一监控，可以确保不同环境的指标保持一致。共享的仪表板和告警使团队能够快速检测性能或复制问题，而无需在多个监控系统之间切换。
安全性和合规性必须是一个一致的层。使用传输中和静态数据加密，并通过 HashiCorp Vault 或云原生 KMS 等服务集中管理密钥。在每个集群中应用相同的访问控制和策略执行，以确保合规性不被破坏。
即使有了这些构建模块，可移植性还需要另一层：能够理解数据库本身的自动化。这正是 Kubernetes Operator 至关重要的地方。
Kubernetes Operator：自动化复杂部分
Operator 通过将数据库专业知识转化为自动化，使数据库可移植性变得切实可行。它们弥合了 Kubernetes 擅长管理的部分（Pod、卷、服务）和有状态数据库所需的部分（精确的、过程性的操作）之间的差距。
一个好的 Operator 可以处理消耗 DBA 时间的重复性数据库管理任务。它理解安全的小版本升级所需的精确逻辑，如何将新副本引导到集群中，或者在故障转移期间如何提升新的主节点并隔离旧的主节点。它使这些工作流在跨集群和云时保持一致，因此在 AWS 上运行 PostgreSQL 与在本地或在 Azure 上运行 PostgreSQL 看起来和行为完全相同。
没有 Operator，多云数据库操作通常会变得脆弱。团队最终需要为每个环境维护脚本和自定义控制器，反而增加了复杂性。即使是简单的任务，如版本升级或副本管理，也可能变成一次性的过程，从而损害可移植性。
Operator 解决了这种脆弱性。它们将 Kubernetes 从一个通用的编排平台转变为一个完整的、可在任何地方自信运行的数据操作框架。
然而，Operator 生态系统本身也带来了新的选择，通常可分为两大类：
- 专有 Operator 简化了部署，但通常附带限制条件。它们与商业许可证或仅限企业使用的功能绑定，将灵活性限制在单个供应商生态系统中。
- 社区 Operator 则采取相反的方法，提供完全的自由，但质量参差不齐。许多能很好地处理初始部署，但在第 2 天操作（如自动化备份、升级和监控集成）方面存在不足。这些差距导致手动工作和不可靠性。
Percona Operator 提供了一种不同的方法，结合了两种模式的最佳优点：企业级的可靠性与开源灵活性。
Percona的开源方法：无妥协的可移植性
Percona Operator 提供了一个单一的、开源的框架，用于在你部署 Kubernetes 的任何地方运行 PostgreSQL、MySQL 和 MongoDB。这种一致性很重要，因为许多团队为每个数据库使用不同的 Operator，每个都有独特的 CRD、备份逻辑和高可用性模型。这只是用一种形式的供应商锁定换来了操作上的碎片化。
使用 Percona Operator，你的团队只需学习一种架构模式。用于 3 节点高可用 PostgreSQL 集群的清单文件，其外观和功能与用于 3 节点 MongoDB 副本集的清单文件完全相同。备份、监控和扩展的哲学理念是相同的，为你的数据、团队技能和操作流程提供了可移植性。
每个 Percona Operator 都包含可靠的企业级数据库管理所需的一切。
- 你可以获得自动升级和滚动重启、支持时间点恢复的定时备份，以及使用 ProxySQL 或 HAProxy 的内置高可用性。
- 传输中和静态数据加密可保护跨所有云的数据。
- 与 Percona 监控和管理（PMM）的原生集成，通过单一的可观测层提供对性能、查询和资源利用率的全面可见性。
每个 Percona Operator 也通过了 Red Hat OpenShift 认证，确保在受监管和高可用环境中的生产就绪性。
专有 Operator 将这些功能中的一部分锁在了许可证层级之后。Percona 的开源 Operator 免费提供了生产自动化所需的一切。社区 Operator 通常能很好地处理部署，但缺乏企业级的加固。Percona Operator 经过测试、得到支持，并为需要可预测行为和正常运行时间的生产工作负载而构建。
最终，你获得的是一个统一的自动化模型，它跨云提供一致性、自由选择基础设施的权利，以及对操作模型的完全所有权，而无需依赖供应商或产生隐藏成本。
构建你的可移植数据策略
一个真正的多云战略需要一个可移植的数据层，但依赖特定于云的 DBaaS 会创建操作孤岛和深入、昂贵的供应商锁定。通过采用一套统一的开源 Operator，你可以构建一个灵活、高效的数据平台，服务于你的业务，而不是将你锁定在单个供应商的生态系统中。