嗨，Spring 粉丝们！今天是星期五，你们知道这意味着什么吗？某个地方某个倒霉蛋正在徒劳地尝试将某些东西部署到生产环境，或者至少在晚餐前一致地回滚。而且它没有成功。我经历过。部署很难。部署有其微妙之处。我和其他 Operator 一样热爱 Kubernetes，但我们不能假装它是生产力的顶峰。恰恰相反。围绕使用 Kubernetes 简化应用程序部署的整个行业正在兴起。例如，请参阅 KNative、Kubernetes 上的 Cloud Foundry 或 Azure Spring Cloud。这些工具很棒 - 它们对如何快速部署和管理典型的 12 要素风格的在线 Web 应用程序提供了见解。它们有强烈的观点，但这些观点并不拘泥。它们是针对特定工作负载的轨道 - 如果您可以将您的工作负载适应特定的、支持 PaaS 的形状，那么这些轨道将通往生产环境。这对我们运行的大量工作负载来说非常棒，但并非所有工作负载都如此。我们的应用程序总是希望与更强大的东西（如 Apache Kafka）进行通信，而这些东西的部署从来都不那么容易。

Kubernetes 为此提供了一个解决方案：Operator。很难说典型的分布式数据库是什么样子，更不用说标准的消息队列、常规邮件服务器或任何其他东西了。它们都非常独特，并且具有各自的使用模式。因此，Kubernetes 提供了诸如 Kubernetes StatefulSet CRD 之类的基本元素，这些元素可以组合在一起用于成功部署具有复制、备份、仲裁等功能的服务。但是，弄清楚何时以及在何处部署这些东西并不有趣。没有人想这样做，或者在出现问题时尝试调试它。

Operators

各种服务的供应商煞费苦心地将其产品打包为 Kubernetes Operators。从本质上讲，Operators 只是驻留在 Kubernetes 集群中的程序，它们与 Kubernetes API 交互以以编程方式部署和（如果出现问题）重新部署服务的各个移动部件。

大多数供应商为我们这些想要到达地球上最快乐的地方（生产环境）的迷途的应用程序开发人员提供了三种选择

• 自己部署开源组件。我称之为 YOLO 选项。
• 为 Kubernetes 部署供应商的（通常是开源的）Operator
• 使用供应商托管的、基于云的 SaaS 产品。只要有可能，我倾向于使用此选项。当然，它需要花费一些费用，但安心感呢？无价的。

如果您不想冒险选择第三种选项，那么如果您知道在哪里寻找，第二种选项是您的最佳选择。因此，让我们看看一些我日常构建 Spring 应用程序时喜欢并使用的 Operators。

这些 Operators 的安装通常是以下步骤的某种组合，大致按以下顺序进行

• 为您的 Kubernetes 安装设置适当且必要的集群权限
• 通过 kubectl apply 一些定义或使用 Helm Chart 安装各种 Operator 资源定义
• 配置/配置由 Operator 管理的 CRD 实例

一段时间后，您可能希望升级到该基础设施的新版本，因此您通常会使用 Helm 或应用更新的定义。此外，许多（但并非所有！）都内置了故障转移和复制支持。

RabbitMQ

许多消息代理都包含在此列表中，因为它们具有一些更令人兴奋且可能更脆弱的部署。RabbitMQ 也不例外。RabbitMQ 当然是由 Tanzu（我作为 Tanzu 的一部分在 Spring 团队工作）主要开发的、以 AMQP 规范为基础、以队列为中心的消息代理，Tanzu 是 VMware 的一部分。在 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 制造和支持的，Confluent 是推动 Apache Kafka 及其生态系统发展的人员。它毫无疑问是更复杂的项目，并且它可以帮助那些致力于该代码的人。因此，如果您能够做到这一点，您应该这样做。

否则，还有一个顶级开源的 Apache Kafka Operator，名为 Strimzi。这个开源项目也为 IBM 等各种供应商的商业产品提供支持。我也喜欢这个，原因有几个，包括代码本身是用 Java 编写的，而不是 Go，因此对于那些想要学习如何编写 Operator 的人来说，它是一个肥沃的土壤。（您确实想学习如何编写 Operator，不是吗？)

Artemis

还记得 JBoss HornetQ 吗？它很棒，并且提供了具有开创性意义的、世界一流的领先性能（当时），其核心是围绕 JMS API。HornetQ 项目最终被并入 Apache ActiveMQ，Apache ActiveMQ 是当时另一个非常流行的 JMS 消息代理。一个超越部分之和的新项目发布了：Apache Artemis。而且，瞧，有一个开源的 Operator！想要一个非常快、出色、世界一流的 JMS 代理，价格为开源价格？现在您拥有了一个。

Cassandra

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

YugabyteDB

嘿，还记得我们在上一段中谈论过 Apache Cassandra 吗？我说它在 CAP 定理中优先考虑 AP 而不是 C？如果您有一个分布式数据库，它感觉就像一个单节点 PostgreSQL 实例，并且与 PostgreSQL 兼容，同时减少了您需要为 C 做出的妥协程度，以至于它实际上不再是妥协？这就是 YugabyteDB（由最初设计 Apache Cassandra 的一些相同人员创建）力求做到的。我喜欢它。而且我喜欢它有一个 Operator。

ElasticSearch

Elastic 是 ElasticSearch 背后的公司，ElasticSearch 是一款流行的搜索引擎。它非常强大，可以立即为应用程序添加自然语言搜索功能。正如你所想象的，它包含了许多活动部件，是运维人员的理想选择。如果你愿意，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 甚至构建了一个开源的 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 社区 Operator，它将 MongoDB 社区版部署到 Kubernetes 集群中。

PostgreSQL

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

Couchbase

很久以前，在一个遥远的星系中，CouchDB 和 Membase 合并了，结果诞生了 Couchbase。Couchbase 是一种键值存储，可以存储许多不同类型的数据。有一个企业级（付费）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 对你有所帮助。