嗨，Spring 的爱好者们！今天是星期五，你们知道这意味着什么吗？某个倒霉蛋此刻正在徒劳地试图在晚餐前将某样东西部署到生产环境，或者至少能够稳定地回滚。而且，它不起作用。我经历过。部署很难。部署中有细微之处。我和其他运维人员一样热爱 Kubernetes，但让我们不要假装它是生产力的巅峰。恰恰相反。围绕着使用 Kubernetes 简化应用程序部署，已经形成了一个庞大的附属产业。例如，看看 KNative、Cloud Foundry on Kubernetes 或 Azure Spring Cloud。这些工具非常棒——它们为如何快速部署和管理典型的 12-Factor 风格在线 Web 应用程序提供了意见。它们有坚定的意见，但又很灵活。它们是特定工作负载的“轨道”——通往生产环境的轨道，如果 你的工作负载能适应特定的、对 PaaS 友好的形状。这对我们运行的许多工作负载来说都很棒，但并非全部。我们的应用程序不可避免地需要与更重要的东西对话，比如 Apache Kafka，而这些东西的部署从未如此简单。

Kubernetes 为此提供了一个答案：Operator。很难说一个典型的分布式数据库是什么样的，更不用说一个标准的报文队列、一个常规的邮件服务器，或者其他什么了。它们都相当独特，并且有各自的使用模式。因此，Kubernetes 提供了原语，例如 Kubernetes StatefulSet CRD，这些原语——组合在一起——可以用来成功地部署一个具有复制、备份、仲裁等功能的.*.* 但弄清楚何时以及如何部署这些东西并没有什么乐趣。没有人愿意做这些，或者在出现问题时尝试调试它们。

Operators

各种服务的供应商已经花费了巨大的精力将他们的产品打包成 Kubernetes operator。Operator 基本上就是驻留在你的 Kubernetes 集群中的程序，它们与 Kubernetes API 交互，以编程方式部署——并且在出现问题时——重新部署服务的各种活动部件。

大多数供应商为我们这些想要到达地球上最幸福的地方——生产环境——的迷途应用程序开发者提供了三种选择。

• 自己部署 OSS 组件。我称之为 YOLO 选项。
• 部署供应商（通常是 OSS）的 Kubernetes Operator
• 使用供应商托管的、云端的 SaaS 服务。我倾向于随时选择这个选项。当然，这需要花一些钱，但省去的烦恼呢？无价。

如果你不想冒险选择第三个选项，那么如果你知道该往哪里看，第二个选项就是你的最佳选择。所以，让我们来看看一些我在日常工作中构建 Spring 应用程序时喜欢使用的 Operator。

这些的安装通常是以下步骤的组合，大致顺序如下：

• 为你的 Kubernetes 安装设置适当的、必需的集群权限
• 通过 kubectl apply 一些定义，或者使用 Helm chart 来安装各种 Operator 资源定义
• 配置/部署由 Operator 管理的 CRD 的实例

一段时间后，你将希望升级到该基础设施的新版本，因此你通常会使用 Helm 或应用更新的定义。此外，许多（但不是全部！）都内置了对故障转移和复制的支持。

RabbitMQ

许多消息中间件都在这个列表中，因为它们的部署更令人兴奋且可能更脆弱。RabbitMQ 也不例外。RabbitMQ 是符合 AMQP 规范、以队列为中心的消息中间件，主要由 VMware 的一部分 Tanzu（我隶属于 Spring 团队）开发。在 VMware 拥有它之前我就爱上了 RabbitMQ，并且我经常使用它。我甚至通过 Cloud AMQP 的服务付费使用托管 RabbitMQ。但现在我不需要了。RabbitMQ 团队自己推出了一个 Operator。

Apache Kafka

好了，我打赌你一直在找这个。Apache Kafka 是一个以主题为中心的消息队列，它源于 LinkedIn 等公司在 Apache Kafka 上所做的工作。Apache Kafka 以其难以运维而闻名。甚至它的某些组件，比如 Apache Zookeeper，本身也以难以运维而闻名！在我写这篇文章的时候，Apache Zookeeper 已经退出了，所以你将来读到这篇文章时可能不必再处理它了，但现在它仍然存在。

这里有两个极好的选择。首先是 Confluent Operator for Kubernetes，它不是开源的，但很容易测试和试用。它也是由 Confluent 公司制作和支持的，该公司推动了 Apache Kafka 及其生态系统的发展。它无疑是更成熟的项目并且它有助于那些开发代码的人。所以，如果可以的话，你应该选择它。

否则，还有一个评分很高的 Apache Kafka 的 OSS Operator，叫做 Strimzi。这个开源项目也为 IBM 等各种供应商提供了商业产品。我也喜欢这个，原因有几个，包括它的代码本身是用 Java 编写的，而不是 Go，因此对于想学习如何编写 Operator 的人来说，这是一个肥沃的土壤。（你确实想学习如何编写 Operator，对吧？）

Artemis

还记得 JBoss HornetQ 吗？它非常棒，而且在当时以 JMS API 为中心，提供了改变游戏规则的、世界一流的性能。HornetQ 项目最终被整合到 Apache ActiveMQ 中，这是当时另一个非常流行的 JMS 消息中间件。一个比各部分之和更重要的项目发布了：Apache Artemis。而且，看吧，有一个 OSS Operator！想要一个非常快速、出色、世界一流的 JMS 中间件，而且价格是 OSS 级别的？现在你有了一个。

Cassandra

Apache Cassandra 是 Facebook 的工程师创造的一个非常流行的列式数据库。它在 CAP 定理中优先考虑可用性和分区容忍性，而不是一致性。它也支持地球上一些最大的网站。你也可以使用它。DataStax 公司（Apache Cassandra 及其新兴生态系统的幕后推手）的优秀团队开发了一个名为 K8ssandra 的绝佳 Operator。该网站称，它建立在“坚如磐石的 Apache Cassandra® NoSQL 数据库”之上，并且“将一套完整的 Kubernetes 运维数据平台结合在一起，包括 API、监控和备份”。听起来不错！

YugabyteDB

嘿，还记得我们在前面一节中谈到的 Apache Cassandra 吗？我说它在 CAP 定理中优先考虑 AP 而非 C？如果有一个分布式数据库，它感觉就像一个单节点 PostgreSQL 实例，并且与 PostgreSQL 兼容，同时又大大降低了你在 C 上的妥协程度，使其几乎不再是妥协呢？这就是 YugabyteDB，它是由最初设计 Apache Cassandra 的一些人创建的。我喜欢它。而且我很高兴有一个 Operator。

ElasticSearch

Elastic 是 ElasticSearch 的公司，ElasticSearch 是一个流行的搜索引擎。它非常强大，可以即时为应用程序添加自然语言搜索功能。正如你所能想象的，它也由许多活动部件组成，是 Operator 的完美候选者。如果你愿意，Elastic 会向你出售 Elastic Cloud 访问权限。这是最简单的选择。或者，你可以使用 Elastic Cloud on Kubernetes (ECK)，这是他们为你的特定 Kubernetes 安装提供的 Operator。它安装 ElasticSearch 和 Kibana、APM Server、Enterprise Search、Beats、Elastic Agent 和 Elastic Maps Server。无论哪种方式，都能让你重新找到组织中的那根“针”！

Prometheus

Prometheus 是一个流行的时序数据库，它可以与你的 Kubernetes 工作负载一起扩展。它是在 Kubernetes 生态系统的摇篮中开发的，并且与 Kubernetes 部署的服务配合良好。不出所料：还有一个优秀的 Prometheus Operator。

MySQL

你想运行 MySQL 吗？你不是一个人！Oracle 甚至还构建了一个 OSS Kubernetes Operator 来在你的集群中运行 MySQL。这个 Operator 管理整个生命周期，包括备份和恢复。

MongoDB

MongoDB 是一个流行的 NoSQL 数据存储，它，嗯，“网络规模”。

有两个选项。MongoDB Enterprise Kubernetes Operator 是一个企业产品，可在 Enterprise Advanced 许可证下使用。该 Operator 支持轻松地将以下应用程序部署到 Kubernetes 集群中：

• MongoDB - 副本集、分片集群和独立实例 - 支持身份验证、TLS 以及更多选项。
• Ops Manager - MongoDB 的企业级管理、监控和备份平台。Operator 可以为你安装和管理 Kubernetes 中的 Ops Manager。此外，Ops Manager 可以管理 Kubernetes 内外的 MongoDB 实例。

你还可以尝试 MongoDB Community Operator，它将 MongoDB 社区版部署到 Kubernetes 集群中。MongoDB Community Operator。

PostgreSQL

想规模化运行 PostgreSQL 吗？我也是！而且，显然，还有很多人也是！不幸的是，我找不到一个单一的、广为人知且得到认可的 PostgreSQL Operator——我找到了很多，但没有一个似乎是“官方”的，无论那是什么意思。我之前使用过德国在线时尚平台 Zalando 的这个 Operator，它运行良好。

Couchbase

很久以前，在遥远的星系，CouchDB 和 Membase 合并了，结果就是 Couchbase。Couchbase 是一个键值存储，可以存储许多不同类型的数据。有一个企业级（付费）Kubernetes Operator。企业（读取：付费）Kubernetes Operator。

FluxCD

好吧，我承认。不过，这个有点免费。它是 FluxCD。它在你的 Kubernetes 集群中为你的 Kubernetes 集群管理持续交付。也就是说，没有自然的运行方式不在 Kubernetes 中运行它。尽管如此，它确实有技术上的 Operator！

NATS

NATS 是一种消息（又是另一个！）技术，由 Derek Collison 在十多年前开发，以支持 Cloud Foundry 的消息总线需求。它是一个非常轻量级、超快的消息中间件，非常适合扩展系统。此外，它还有一个 Spring Cloud Stream 绑定器、一个 Java 客户端，当然——还有一个 Kubernetes Operator。

ArangoDB

ArangoDB 是一个多模型分布式数据库。我用得不多。我用它的那一次，在本地机器上很容易上手，而且——重要的是——在 Kubernetes 上，得益于这个 Operator

下一步

根据我的经验，当我刚接触 Kubernetes 时，我尝试做的第一件事就是使用 Spring Boot 部署一个无状态微服务。我知道这类无状态微服务是 Kubernetes 的理想选择，我不想走弯路。这种体验令人满意，并让我着迷。“这个东西有潜力！”我惊呼道。然后我花时间优化无状态微服务。我学习了 Istio、KNative 等。Tanzu Application Platform 似乎最适合部署我学到的所有东西的应用程序。（我只希望它当时就有，而不是现在！我无疑会节省大量时间！）

然后，我开始想如何在平台上存储我的数据。这时乐观情绪就开始消退了。我在 Kubernetes 上的 90% 的旅程都在努力让基础设施在平台上可靠运行。像消息队列、数据库等等。在开始理解问题空间之前，我花了很长时间学习如何使用 Helm chart、Operator 和 StatefulSet。如果让我重新开始，我会花更少的时间在微服务上徘徊，而是几乎立即深入研究如何让我的首选数据库可靠运行。从小处着手。然后学习 Helm。然后发现 Operator 模式。一旦你拥有了这些工具，在平台层面，组合和重用的效果就会开始显现。

在这篇文章中，我们探讨了几个我发现足够好用、足够强大、值得使用的 Operator。我很想知道你们在经验中还发现了哪些有用的 Operator。