嗨，Spring 爱好者们！今天是星期五，你知道这意味着什么吗？某个可怜的家伙正在徒劳地尝试在晚餐前将某些东西部署到生产环境，或者至少能一致地回滚。但就是行不通。我经历过。部署很难。部署中有很多细微差别。我像其他任何 Operator 一样热爱 Kubernetes，但我们别假装它是生产力的巅峰。恰恰相反，简化使用 Kubernetes 进行应用部署形成了一个完整的产业。例如，参见 KNative、 Kubernetes 上的 Cloud Foundry 或 Azure Spring Cloud。这些工具很棒——它们为如何快速部署和管理典型的 12 要素风格在线 Web 应用提供了指导。它们有强烈但灵活的意见。它们是特定工作负载的“轨道”，如果你的工作负载能适应特定的 PaaS 友好形状，这些轨道就能通往生产环境。这对于我们运行的许多工作负载来说都很好，但不是所有工作负载。我们的应用总是希望与更重要的东西交互，比如 Apache Kafka，而这些东西部署起来从来都不容易。

Kubernetes 对此提供了一个解决方案：Operator。很难说一个典型的分布式数据库是什么样子，更不用说标准的 messaging queue（消息队列），或者普通的邮件服务器，或者其他什么了。它们都相当独特，并且有各自的使用模式。所以 Kubernetes 提供了原语，比如 Kubernetes 的 StatefulSet CRD，这些原语结合起来可以使用复制、备份、仲裁等方式成功部署一个服务。但要弄清楚何时、何地部署这些东西并不有趣。没人愿意做这件事，也不想在出错时去调试它。

Operator

各种服务的供应商费尽心思将其产品打包为 Kubernetes Operator。Operator 本质上只是运行在你的 Kubernetes 集群中的程序，它与 Kubernetes API 交互，以编程方式部署，并在出现问题时重新部署服务的各个活动部件。

大多数供应商为我们这些希望抵达地球上最快乐的地方（生产环境）的迷途应用开发者提供了三种选择

• 自行部署开源（OSS）组件。我称之为 YOLO（你只活一次）选项。
• 部署供应商的 Kubernetes Operator（通常是开源的）
• 使用供应商托管的云端 SaaS 服务。我倾向于尽可能选择这个选项。当然，它要花一些钱，但安心？无价。

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

它们的安装通常是以下步骤的组合，大致按以下顺序进行

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

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

RabbitMQ

许多消息代理都在此列表中，因为它们的部署有些令人兴奋且可能很脆弱。RabbitMQ 也不例外。当然，RabbitMQ 是一个实现 AMQP 规范、以队列为中心的消息代理，主要由 Tanzu（我作为 Tanzu 的一部分在 Spring 团队工作，Tanzu 是 VMWare 的一部分）开发。在 VMWare 收购 RabbitMQ 之前我就很喜欢它，并且我经常使用它。说实话，我甚至会花钱使用 Cloud AMQP 提供的托管 RabbitMQ 服务。但现在我不需要了。RabbitMQ 团队自己提供了一个 Operator。

Apache Kafka

好的，我敢打赌你正在寻找这个。Apache Kafka 是一个以主题为中心的消息队列，它是 Linkedin 等公司在做...（此处原文似乎有缺失或不通顺，可能意指其起源）。Apache Kafka 是出了名的难以运维。天哪，它甚至包含像 Apache Zookeeper 这样的组件，而 Zookeeper 本身也是出了名的难以运维！在我写这篇文章的时候，Apache Zookeeper 正在被淘汰，所以当你有一天读到这篇文章时，可能就不需要处理它了，但现在它仍然存在。

这里有两个极好的选择。首先是 Confluent 为 Kubernetes 提供的 Operator，它不是开源的，但很容易测试和试用。它也由 Confluent 公司创建和支持，Confluent 是推动 Apache Kafka 及其生态系统发展的主要力量。它无疑是更复杂的项目，并且它能帮助那些致力于代码工作的人。所以，如果可以，你应该选择它。

此外，还有一个备受好评的 Apache Kafka 开源 Operator，名为 Strimzi。这个开源项目也为 IBM 等各种供应商的商业产品提供了支持。我也喜欢这个 Operator，原因有很多，包括它的代码本身是用 Java 编写的，而不是 Go，所以对于想学习如何编写 Operator 的人来说，这是一片沃土。（你确实想学习如何编写 Operator，不是吗？)

Artemis

还记得JBoss HornetQ吗？它曾是非常棒的，围绕 JMS API 提供了改变游戏规则的、当时世界一流的领先性能。HornetQ 项目最终被整合进 Apache ActiveMQ，后者也是当时非常流行的 JMS 消息代理。一个集各家所长的新项目发布了：Apache Artemis。看啊，还有一个开源 Operator！想要一个速度极快、性能卓越、世界一流的 JMS 代理，而且是开源价格？现在你有了。

Cassandra

Apache Cassandra 是 Facebook 工程师创建的一种非常流行的列式数据库。在 CAP 定理中，它优先考虑可用性（Availability）和分区容错性（Partitionability），而非一致性。它也为全球一些最大的网站提供支持。你也可以使用它。DataStax 的好伙伴们提供了一个很棒的 Operator，名为 K8ssandra，DataStax 是 Apache Cassandra 及其新兴生态系统背后的公司。从网站上看，它建立在“坚如磐石的 Apache Cassandra® NoSQL 数据库”之上，并“汇集了一个完整的 Kubernetes 运营数据平台，包括 API、监控和备份”。听起来很不错！

YugabyteDB

嘿，还记得我们在上一段提到 Apache Cassandra 时，我说它在 CAP 定理中优先考虑 AP 而非 C 吗？如果有一个分布式数据库，它感觉就像一个单节点的 PostgreSQL 实例，并且与 PostgreSQL 兼容，同时又大大减少了你在 C（一致性）上需要妥协的程度，以至于几乎不再是妥协，那会怎样？这就是 YugabyteDB，由最初设计 Apache Cassandra 的同一批人创建，它旨在实现这一目标。我喜欢它。我也喜欢它提供了 Operator。

ElasticSearch

Elastic 是流行搜索引擎 ElasticSearch 背后的公司。它令人难以置信，可以立即为应用添加自然语言搜索功能。你也可以想象，它包含许多活动部件，是 Operator 的完美候选者。如果你愿意，Elastic 会向你出售 Elastic Cloud 访问权。这是最简单的方式。或者，你可以使用 Kubernetes 上的 Elastic Cloud (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 甚至构建了一个 开源 Kubernetes Operator，用于在你的集群中运行 MySQL。这个 Operator 管理整个生命周期，包括备份和恢复。

MongoDB

MongoDB 是一个流行的 NoSQL 数据存储，咳咳，它是“web 规模”的。

这里有两个选项。MongoDB 企业版 Kubernetes Operator 是企业产品，可在 Enterprise Advanced 许可下使用。该 Operator 能够轻松地将以下应用程序部署到 Kubernetes 集群中

• MongoDB - 副本集（Replica Sets）、分片集群（Sharded Clusters）和独立实例（Standalones）- 支持认证、TLS 和更多选项。
• Ops Manager - MongoDB 的企业管理、监控和备份平台。Operator 可以为你安装并在 Kubernetes 中管理 Ops Manager。此外，Ops Manager 可以管理 Kubernetes 内部和外部的 MongoDB 实例。

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

PostgreSQL

想大规模运行 PostgreSQL 吗？我也想！显然，很多人也想！不幸的是，我没有找到一个单一的、广为人知且受认可的 PostgreSQL Operator——我找到了很多，但没有一个看起来是“官方的”，无论那意味着什么。我以前使用过来自德国在线时尚平台 Zalando 的这个 Operator，它运行良好。

Couchbase

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

FluxCD

好吧，我承认。然而，这个有点像附赠品。它是 FluxCD。它管理 Kubernetes 集群中的持续交付。也就是说，不在 Kubernetes 中运行它就没有自然的方法。尽管如此，它在技术上确实有一个 Operator！

NATS

NATS 是一种消息传递技术（又一个！），由 Derek Collison 在十多年前开发，用于支持 Cloud Foundry 的消息总线需求。它是一种非常轻量级、超快速的消息代理，非常适合扩展系统。此外，还有一个 Spring Cloud Stream binder、一个 Java 客户端，并且——很明显——它有一个 Kubernetes Operator。

ArangoDB

ArangoDB 是一种多模型分布式数据库。我使用它不多。我用过的那一次，它在我的本地机器上运行得相当容易，而且——重要的是——多亏了这个 Operator，它在 Kubernetes 上也运行得很好

下一步

根据我的经验，当我接触 Kubernetes 时，我首先尝试做的是使用 Spring Boot 部署无状态微服务。我知道这类无状态微服务是 Kubernetes 的顺畅之道，我不想逆流而上。这次经历令人满意，让我着迷。我惊呼：“这东西有潜力！”然后我花时间尝试优化无状态微服务。我学习了 Istio、KNative 等等。在我学过的所有东西中，Tanzu Application Platform 似乎是部署应用的最好选择。（我真希望它当时就像现在这样存在！那样我无疑会节省大量时间！)

然后，我开始想如何将我的数据放到这个平台上。乐观的情绪也就在此时消退了。我在 Kubernetes 上的 90% 的历程都在研究如何让基础设施在这个平台上可靠地工作。比如消息队列、数据库等等。在我开始理解问题领域之前，我花了很多时间学习如何使用 Helm chart、Operator 和 StatefulSet。如果让我重新来过，我会少花些时间在微服务上原地踏步，而是几乎立刻投入到如何让我最喜欢的数据库可靠地运行起来。从小处着手。然后学习 Helm。然后发现 Operator 模式。一旦你拥有了这些技能，一切皆有可能。然后，组合和重用的力量倍增效应才会在平台层面显现出来。

在这篇文章中，我们介绍了一些我认为使用起来足够令人愉悦且强大到值得使用的 Operator。我很想知道你在自己的经验中发现哪些其他的 Operator 有用。