嗨，Spring 的粉絲們！今天是星期五，你知道這意味著什麼嗎？某個可憐的傢伙正在徒勞地嘗試將某些東西部署到生產環境，或者至少在晚餐前一致地回滾。但它不起作用。我經歷過。部署很困難。部署有細微差別。我和下一個人一樣熱愛 Kubernetes，但別假裝它是生產力的頂峰。恰恰相反。圍繞著簡化使用 Kubernetes 的應用程式部署，已經形成了一個完整的家庭手工業。例如，請參閱KNative、Kubernetes 上的 Cloud Foundry或Azure Spring Cloud。這些工具非常棒 - 它們提供了關於如何快速部署和管理典型的 12 因素風格線上網路應用程式的建議。它們具有強烈的意見，但並非一成不變。它們是特定工作負載的軌道 - 引導至生產環境的軌道，如果您可以將您的工作負載放入特定的、PaaS 友好的形狀中。這對於我們在外面運行的許多工作負載來說非常棒，但並非全部。我們的應用程式總是希望與更實質性的東西通信，例如 Apache Kafka，而這些東西從來都不容易部署。

Kubernetes 對此有一個答案：Operator。很難說典型的分散式資料庫是什麼樣子的，更不用說標準訊息佇列、常規郵件伺服器或其他什麼。它們都非常獨特，並且具有自己的使用模式。因此，Kubernetes 提供了諸如 Kubernetes StatefulSet CRD 之類的原語，這些原語可以一起使用，以成功部署具有複寫、備份和仲裁等的服務。但是，弄清楚何時以及以何種方式部署東西並不有趣。沒有人想這樣做，也沒有人想在出現問題時嘗試進行除錯。

Operator

各種服務的供應商都竭盡全力將其產品打包為 Kubernetes Operator。Operator 基本上只是駐留在您的 Kubernetes 叢集中並與 Kubernetes API 互動，以程式化方式部署服務的各種移動部件，並且 - 如果出現問題 - 重新部署它們。

大多數供應商向我們這些想要到達地球上最快樂的地方（生產環境）的任性應用程式開發人員提供三種選擇

• 自己部署 OSS 位元。我稱此為 YOLO 選項。
• 部署供應商的（通常是 OSS）Kubernetes Operator
• 使用供應商託管的雲端 SaaS 產品。我傾向於在可以的情況下選擇此選項。當然，這需要花費一些錢，但是安心呢？無價。

如果您不想冒險選擇第三個選項，那麼如果您知道在哪裡尋找，第二個選項是您的最佳選擇。因此，讓我們看看我喜歡並且在我日常構建 Spring 應用程式的工作中使用的一些 Operator。

這些的安裝通常是以下步驟的某種組合，大致按以下順序

• 為您的 Kubernetes 安裝設定適當且必需的叢集權限
• 透過 kubectl applying 某些定義或使用 Helm Chart 來安裝各種 Operator 資源定義
• 佈建/配置由 Operator 管理的 CRD 實例

一段時間後，您將想要升級到該基礎架構的較新版本，因此您通常會使用 Helm 或套用更新的定義。此外，許多（但不是全部！）都內建支援容錯移轉和複寫。

RabbitMQ

許多訊息代理程式都在此清單上，因為它們具有一些更令人興奮且可能更脆弱的部署。RabbitMQ 也不例外。RabbitMQ 當然是由 Tanzu（我作為 VMWare 的一部分，在 Spring 團隊工作）主要開發的、實作 AMQP 規格的、以佇列為中心的訊息代理程式。在 VMWare 擁有它之前，我就喜歡 RabbitMQ，並且我經常使用它。天哪，我甚至使用 Cloud AMQP 的服務為託管的 RabbitMQ 付費。但現在我不需要了。RabbitMQ 團隊本身有一個 Operator。

Apache Kafka

好吧，我敢打賭你正在尋找這個。Apache Kafka 是一種以主題為中心的訊息佇列，它源自 Linkedin 和其他人在做的工作。眾所周知，Apache Kafka 很難操作。天哪，它甚至還有諸如 Apache Zookeeper 之類的元件，這些元件本身也很難操作！在我撰寫本文時，Apache Zookeeper 已經退出，因此當您有一天閱讀本文時，您可能不必處理它，但現在它仍然是一件事。

您在這裡有兩個絕佳的選擇。首先，有 Kubernetes 的 Confluent Operator，它不是開放原始碼，但很容易測試和嘗試。它也是由 Confluent（推動 Apache Kafka 及其生態系統發展的人們）製作和支援的。無可爭議地，它是一個更複雜的專案並且它有助於從事程式碼工作的人們。因此，如果可以這樣做，就應該這樣做。

否則，有一個針對 Apache Kafka 的頂級 OSS Operator 稱為 Strimzi。這個開放原始碼專案也為 IBM 等各種供應商的商業產品提供動力。我也喜歡這個專案，原因有很多，包括程式碼本身是用 Java 而不是 Go 編寫的，因此對於想要學習如何編寫 Operator 的人來說，這是一片沃土。（您確實想學習如何編寫 Operator，不是嗎？）

Artemis

還記得 JBoss HornetQ 嗎？它非常棒，並提供了以 JMS API 為中心的、改變遊戲規則的、世界一流的領先效能（當時）。HornetQ 專案最終被合併到 Apache ActiveMQ 中，Apache ActiveMQ 是當時另一個超級流行的 JMS 訊息代理程式。發布了一個比各部分總和更多的新專案：Apache Artemis。而且，瞧，有一個 OSS Operator！想要以 OSS 價格獲得非常快速、出色的、世界一流的 JMS 代理程式嗎？現在您有一個了。

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 叢集中。

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 binder、一個 Java 客戶端，以及 - 顯然 - 一個 Kubernetes operator。

ArangoDB

ArangoDB 是一個多模型分散式資料庫。我沒有用過很多。我用過一次，它很容易在我的本機機器上啟動並運行 - 重要的是 - 在 Kubernetes 上，這要歸功於這個 Operator

下一步

以我的經驗，我剛開始接觸 Kubernetes 時做的第一件事就是使用 Spring Boot 部署一個無狀態微服務。我知道這些無狀態微服務是 Kubernetes 的最佳路徑，我不想逆流而上。這種經驗令人滿意並讓我著迷。「這東西有潛力！」我驚呼道。然後我花時間優化無狀態微服務。我學習了 Istio、KNative 等等。對我學到的所有東西來說，Tanzu 應用程式平台似乎最適合部署應用程式。(我只希望它當時就存在，就像現在一樣！我肯定可以節省大量的時間！)

然後，我想知道如何將我的資料放在平台上。這就是樂觀情緒減弱的地方。我在 Kubernetes 上的 90% 的時間都花在弄清楚如何在平台上可靠地運行基礎架構。像是訊息佇列、資料庫等等。我學會如何使用 Helm charts、operators 和 StatefulSets 之後，我才開始了解這個問題領域。如果我要重新來過，我會減少花費在微服務上的時間，幾乎立即投入到讓自己喜歡的資料庫可靠地運行起來。從小處著手。然後學習 Helm。然後發現 operator 模式。一旦你掌握了這些技巧，一切皆有可能。然後，組合和重用的力量倍增效應開始在平台層面發揮作用。

在這篇文章中，我們看了一些我發現使用起來相當愉快且功能強大到值得使用的 operators。我很想知道您在您的經驗中發現哪些其他 operators 有幫助。