![1.png](https://ucc.alicdn.com/pic/developer-ecology/afceb47b32854b5c8bb6aaa1a544b00d.png)

作者 | 匡大虎、闞俊寶

基於 Kubernetes 平臺，我們可以輕鬆的搭建一些簡單的無狀態應用，比如對於一些常見的 web apps 或是移動端後臺程式，開發者甚至不用十分了解 Kubernetes 就可以利用 Deployment，Service 這些基本單元模型構建出自己的應用拓撲並暴露相應的服務。由於無狀態應用的特性支援其在任意時刻進行部署、遷移、升級等操作，Kubernetes 現有的 ReplicaSets，ReplicationControllers，Services 等元素已經足夠支撐起無狀態應用對於自動擴縮容、例項間負載均衡等基本需求。

在管理簡單的有狀態應用時，我們可以利用社群原生的 StatefulSet 和 PV 模型來構建基礎的應用拓撲，幫助實現相應的持久化儲存，按順序部署、順序擴容、順序滾動更新等特性。

而隨著 Kubernetes 的蓬勃發展，在資料分析，機器學習等領域相繼出現了一些場景更為複雜的分散式應用系統，也給社群和相關應用的開發運維人員提出了新的挑戰：

- 不同場景下的分散式系統中通常維護了一套自身的模型定義規範，如何在 Kubernetes 平臺中表達或相容出應用原先的模型定義？

- 當應用系統發生擴縮容或升級時，如何保證當前已有例項服務的可用性？如何保證它們之間的可連通性？

- 如何去重新配置或定義複雜的分散式應用？是否需要大量的專業模板定義和複雜的命令操作？是否可以向無狀態應用那樣用一條 kubectl 命令就完成應用的更新？

- 如何備份和管理系統狀態和應用資料？如何協調系統叢集各成員間在不同生命週期的應用狀態？

而所有的這些正是 Operator 希望解決的問題，本文我們將首先了解到 Operator 是什麼，之後逐步瞭解到 Operator 的生態建設，Operator 的關鍵元件及其基本的工作原理，下面讓我們來一探究竟吧。

# 初識 Operator

首先讓我們一起來看下什麼是 Operator 以及它的誕生和發展歷程。

## 1. 什麼是 Operator

CoreOS 在 2016 年底提出了 Operator 的概念，當時的一段官方定義如下：

“An Operator represents human operational knowledge in software, to reliably manage an application.”

對於普通的應用開發者或是大多數的應用 SRE 人員，在他們的日常開發運維工作中，都需要基於自身的應用背景和領域知識構建出相應的自動化任務滿足業務應用的管理、監控、運維等需求。在這個過程中，Kubernetes 自身的基礎模型元素已經無法支撐不同業務領域下複雜的自動化場景。

與此同時，在雲原生的大背景下，生態系統是衡量一個平臺成功與否的重要標準，而廣大的應用開發者作為 Kubernetes 的最直接使用者和服務推廣者，他們的業務需求更是 Kubernetes 的生命線。於是，谷歌率先提出了 Third Party Resource 的概念，允許開發者根據業務需求以外掛化形式擴充套件出相應的 K8s API 物件模型，同時提出了自定義 controller 的概念用於編寫面向領域知識的業務控制邏輯，基於 Third Party Resource，Kubernetes 社群在 1.7 版本中提出了[custom resources and controllers](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247493984&idx=1&sn=59238e3a71d14702191e5c518b749836&chksm=fae6e2afcd916bb92a15170911643357ac56fa72ae9bf844b500fbd5e5253fd741f5af0d797c&token=10947129&lang=zh_CN) 的概念，這正是 Operator 的核心概念。

基於 custom resources 和相應的自定義資源控制器，我們可以自定義擴充套件 Kubernetes 原生的模型元素，這樣的自定義模型可以如同原生模型一樣被 Kubernetes API 管理，支援 kubectl 命令列；同時 Operator 開發者可以像使用原生 API 進行應用管理一樣，透過宣告式的方式定義一組業務應用的期望終態，並且根據業務應用的自身特點進行相應控制器邏輯編寫，以此完成對應用執行時刻生命週期的管理並持續維護與期望終態的一致性。這樣的設計正規化使得應用部署者只需要專注於配置自身應用的期望執行狀態，而無需再投入大量的精力在手工部署或是業務在執行時刻的繁瑣運維操作中。

簡單來看，Operator 定義了一組在 Kubernetes 叢集中打包和部署複雜業務應用的方法，它可以方便地在不同叢集中部署並在不同的客戶間傳播共享；同時 Operator 還提供了一套應用在執行時刻的監控管理方法，應用領域專家透過將業務關聯的運維邏輯編寫融入到 operator 自身控制器中，而一個執行中的 Operator 就像一個 7*24 不間斷工作的優秀運維團隊，它可以時刻監控應用自身狀態和該應用在 Kubernetes 叢集中的關注事件，並在毫秒級別基於期望終態做出對監聽事件的處理，比如對應用的自動化容災響應或是滾動升級等高階運維操作。

進一步講，Operator 的設計和實現並不是千篇一律的，開發者可以根據自身業務需求，不斷演進應用的自定義模型，同時面向具體的自動化場景在控制器中擴充套件相應的業務邏輯。很多 Operator 的出現都是起源於一些相對簡單的部署和配置需求，並在後續演進中不斷完善補充對複雜運維需求的自動化處理。

## 2. Operator 的發展

時至今日，Kubernetes 已經確立了自己在雲原生領域平臺層開源軟體中的絕對地位，我們可以說 Kubernetes 就是當今容器編排的事實標準；而在 Kubernetes 專案強大的影響力下，越來越多的企業級分散式應用選擇擁抱雲原生並開始了自己的容器化道路，而 Operator 的出現無疑極大的加速了這些傳統的複雜分散式應用的上雲過程。無論在生態還是生產領域，Operator 都是容器應用部署上雲過程中廣受歡迎的實現規範，本小節就讓我們來一起回顧下 Operator 的誕生和發展歷史。

2014 到 2015 年，Docker 無疑是容器領域的絕對霸主，容器技術自身敏捷、彈性和可移植性等優勢使其迅速成為了當時炙手可熱的焦點。在這個過程中，雖然市場上湧現了大量應用映象和技術分享，我們卻很難在企業生產級別的分散式系統中尋找到容器應用的成功案例。容器技術的本質是提供了主機虛擬層之上的隔離，這樣的隔離雖然帶來了敏捷和彈性的優勢，但同時也給容器和外部世界的互動帶來了多一層的障礙；尤其是面向複雜分散式系統中，在處理自身以及不同容器間狀態的依賴和維護問題上，往往需要大量的額外工作和依賴元件。這也成為了容器技術在雲原生應用生產化道路上的一個瓶頸。

與此同時，谷歌於 2014 年基於其內部的分散式底層框架 Borg 推出了 Kubernetes 並完成了[第一次程式碼提交](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247493984&idx=1&sn=59238e3a71d14702191e5c518b749836&chksm=fae6e2afcd916bb92a15170911643357ac56fa72ae9bf844b500fbd5e5253fd741f5af0d797c&token=10947129&lang=zh_CN)。

2015 年，Kubernetes v1.0 版本正式釋出，同時雲原生計算基金會 Cloud Native Computing Foundation，簡稱 CNCF）正式成立，基於雲原生這個大背景，CNCF 致力於維護和整合優秀開源技術以支撐編排容器化微服務架構應用。

2016 年是 Kubernetes 進入主幹道，開始蓬勃發展的一年。這一年的社群，開發者們從最初的種種疑慮轉為對 Kubernetes 的大力追捧，無論從 commit 數量到個人貢獻者數量都有了顯著增長；同時越來越多的企業選擇 Kubernetes 作為生產系統容器叢集的編排引擎，而以 Kubernetes 為核心構建企業內部的容器生態已經開始逐漸成為雲原生大背景下業界的共識。也正是在這一年，CoreOS 正式推出了 Operator，旨在透過擴充套件 Kubernetes 原生 API 的方式為 Kubernetes 應用提供建立、配置以及執行時刻生命週期管理能力，與此同時使用者可以利用 Operator 方便的對應用模型進行更新、備份、擴縮容及監控等多種複雜運維操作。

在 Kubernetes 實現容器編排的核心思想中，會使用控制器（Controller）模式對 etcd 裡的 API 模型物件變化保持不斷的監聽（Watch），並在控制器中對指定事件進行響應處理，針對不同的 API 模型可以在對應的控制器中新增相應的業務邏輯，透過這種方式完成應用編排中各階段的事件處理。而 Operator 正是基於控制器模式，允許應用開發者透過擴充套件 Kubernetes API 物件的方式，將複雜的分散式應用叢集抽象為一個自定義的 API 物件，透過對自定義 API 模型的請求可以實現基本的運維操作，而在 Controller 中開發者可以專注實現應用在執行時刻管理中遇到的相關複雜邏輯。

在當時，率先提出這種擴充套件原生 API 物件進行應用叢集定義框架的並不是 CoreOS，而是當時還在谷歌的 Kubernetes 創始人 Brendan Burns；正是 Brendan 早在 1.0 版本釋出前就意識到了 Kubernetes API 可擴充套件性對 Kubernetes 生態系統及其平臺自身的重要性，並構建了相應的 API 擴充套件框架，谷歌將其命名為 Third Party Resource，簡稱“TPR”。

CoreOS 是最早的一批基於 Kubernetes 平臺提供企業級容器服務解決方案的廠商之一，他們很敏銳地捕捉到了 TPR 和控制器模式對企業級應用開發者的重要價值；並很快由鄧洪超等人基於 TPR 實現了歷史上第一個 Operator：etcd-operator。它可以讓使用者透過短短的幾條命令就快速的部署一個 etcd 叢集，並且基於 kubectl 命令列一個普通的開發者就可以實現 etcd 叢集滾動更新、災備、備份恢復等複雜的運維操作，極大的降低了 etcd 叢集的使用門檻，在很短的時間就成為當時 K8s 社群關注的焦點專案。

與此同時，Operator 以其外掛化、自由化的模式特性，迅速吸引了大批的應用開發者，一時間很多市場上主流的分散式應用均出現了對應的 Operator 開源專案；而很多雲廠商也迅速跟進，紛紛提出基於 Operator 進行應用上雲的解決方案。Operator 在 Kubernetes 應用開發者中的熱度大有星火燎原之勢。

雖然 Operator 的出現受到了大量應用開發者的熱捧，但是它的發展之路並不是一帆風順的。對於谷歌團隊而言，Controller 和控制器模式一直以來是作為其 API 體系內部實現的核心，從未暴露給終端應用開發者，Kubernetes 社群關注的焦點也更多的是集中在 PaaS 平臺層面的核心能力。而 Operator 的出現打破了社群傳統意義上的格局，對於谷歌團隊而言，Controller 作為 Kubernetes 原生 API 的核心機制，應該交由系統內部的 Controller Manager 元件進行管理，並且遵從統一的設計開發模式，而不是像 Operator 那樣交由應用開發者自由地進行 Controller 程式碼的編寫。

另外 Operator 作為 Kubernetes 生態系統中與終端使用者建立連線的橋樑，作為 Kubernetes 專案的設計和捐贈者，谷歌當然也不希望錯失其中的主導權。同時 Brendan Burns 突然宣佈加盟微軟的訊息，也進一步加劇了谷歌團隊與 Operator 專案之間的矛盾。

於是，2017 年開始谷歌和 RedHat 開始在社群推廣 Aggregated apiserver，應用開發者需要按照標準的社群規範編寫一個自定義的 apiserver，同時定義自身應用的 API 模型；透過原生 apiserver 的配置修改，擴充套件 apiserver 會隨著原生元件一同部署，並且限制自定義 API 在系統管理元件下進行統一管理。之後，谷歌和 RedHat 開始在社群大力推廣使用聚合層擴充套件 Kubernetes API，同時建議廢棄 TPR 相關功能。

然而，巨大的壓力並沒有讓 Operator 曇花一現，就此消失。相反，社群大量的 Operator 開發和使用者仍舊擁護著 Operator 清晰自由的設計理念，繼續維護演進著自己的應用專案；同時很多雲服務提供商也並沒有放棄 Operator，Operator 簡潔的部署方式和易複製，自由開放的程式碼實現方式使其維護住了大量忠實粉絲。在使用者的選擇面前，強如谷歌，紅帽這樣的巨頭也不得不做出退讓。最終，TPR 並沒有被徹底廢棄，而是由 Custom Resource Definition（簡稱 CRD）這個如今已經廣為人知的資源模型正規化代替。

CoreOS 官方部落格也第一時間發出了回應文章指導使用者儘快從 TPR 遷移到 CRD：[https://coreos.com/blog/custom-resource-kubernetes-v17](https://coreos.com/blog/custom-resource-kubernetes-v17)

2018 年初，RedHat 完成了對 CoreOS 的收購，並在幾個月後釋出了 Operator Framework，透過提供 SDK 等管理工具的方式進一步降低了應用開發與 Kubernetes 底層 API 知識體系之間的依賴。至此，Operator 進一步鞏固了其在 Kubernetes 應用開發領域的重要地位。

## 3. Operator 的社群與生態

Operator 開放式的設計模式使開發者可以根據自身業務自由的定義服務模型和相應的控制邏輯，可以說一經推出就在社群引起了巨大的反響。

一時間，基於不同種類的業務應用湧現了一大批優秀的開源 Operator 專案，我們可以在[這裡](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247493984&idx=1&sn=59238e3a71d14702191e5c518b749836&chksm=fae6e2afcd916bb92a15170911643357ac56fa72ae9bf844b500fbd5e5253fd741f5af0d797c&token=10947129&lang=zh_CN)找到其中很多的典型案例，例如對於運維要求較高的資料庫叢集，我們可以找到像 etcd、Mysql、PostgreSQL、Redis、Cassandra 等很多主流資料庫應用對應的 Operator 專案，這些 Operator 的推出有效的簡化了資料庫應用在 Kubernetes 叢集上的部署和運維工作；在監控方向，CoreOS 開發的 prometheus-operator 早日成為社群裡的明星專案，Jaeger、FluentD、Grafana 等主流監控應用也或由官方或由開發者迅速推出相應的 Operator 並持續演進；在安全領域，Aqua、Twistlock、Sisdig 等各大容器安全廠商也不甘落後，透過 Operator 的形式簡化了相對門檻較高的容器安全應用配置，另外社群中像 cert-manager、vault-operator 這些熱門專案也在很多生產環境上得到了廣泛應用。

可以說 operator 在很短的時間就成為了分散式應用在 Kubernetes 叢集中部署的事實標準，同時 Operator 應用如此廣泛的覆蓋面也使它超過了分散式應用這個原始的範疇，成為了整個 Kubernetes 雲原生應用下一個重要存在。

隨著 Operator 的持續發展，已有的社群共享模式已經漸漸不能滿足廣大開發者和 K8s 叢集管理員的需求，如何快速尋找到業務需要的可用 Operator？如何給生態中大量的 Operator 定義一個統一的質量標準？這些都成為了剛剛完成收購的 RedHat 大佬們眼中亟需解決的問題。

於是我們看到 RedHat 在年初聯合 AWS、谷歌、微軟等大廠推出了 [OperatorHub.io](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247493984&idx=1&sn=59238e3a71d14702191e5c518b749836&chksm=fae6e2afcd916bb92a15170911643357ac56fa72ae9bf844b500fbd5e5253fd741f5af0d797c&token=10947129&lang=zh_CN)，希望其作為 Kubernetes 社群的延伸，向廣大 operator 使用者提供一個集中式的公共倉庫，使用者可以在倉庫網站上輕鬆的搜尋到自己業務應用對應的 Operator 並在嚮導頁的指導下完成例項安裝；同時，開發者還可以基於 Operator Framework 開發自己的 Operator 並上傳分享至倉庫中。

下圖為一個 Operator 專案從開發到開源到被使用的全生命週期流程：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/7216c4e1bd89415784069fda754f8625.png)
（Operator 開源生命週期流程圖）

主要流程包括：

- 開發者首先使用 Operator SDK 建立一個 Operator 專案；

- 利用 SDK 我們可以生成 Operator 對應的腳手架程式碼，然後擴充套件相應業務模型和 API，最後實現業務邏輯完成一個 Operator 的程式碼編寫；

- 參考社群[測試指南](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247493984&idx=1&sn=59238e3a71d14702191e5c518b749836&chksm=fae6e2afcd916bb92a15170911643357ac56fa72ae9bf844b500fbd5e5253fd741f5af0d797c&token=10947129&lang=zh_CN)進行業務邏輯的本地測試以及打包和釋出格式的本地校驗；

- 在完成測試後可以根據[規定格式](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247493984&idx=1&sn=59238e3a71d14702191e5c518b749836&chksm=fae6e2afcd916bb92a15170911643357ac56fa72ae9bf844b500fbd5e5253fd741f5af0d797c&token=10947129&lang=zh_CN)向社群提交[PR](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247493984&idx=1&sn=59238e3a71d14702191e5c518b749836&chksm=fae6e2afcd916bb92a15170911643357ac56fa72ae9bf844b500fbd5e5253fd741f5af0d797c&token=10947129&lang=zh_CN)，會有專人進行 review；

- 待社群稽核透過完成 merge 後，終端使用者就可以在 OperatorHub.io 頁面上找到業務對應的 Operator；

- 使用者可以在 OperatorHub.io 上找到業務 Operator 對應的說明文件和安裝指南，透過簡單的命令列操作即可在目標叢集上完成 Operator 例項的安裝；

- Operator 例項會根據配置建立所需的業務應用，OLM 和 Operator Metering 等元件可以幫助使用者完成業務應用對應的運維和監控採集等管理操作。

# 小結

本文主要介紹了 Operator 的基本概念，讓您瞭解 Operator 的應用場景和發展歷程。

Operator 已經成為 Kubernetes 生態的一個重要設計模式，Kubernetes 從 PaaS 層面提供整套叢集、應用編排的框架，而使用者透過 Operator 的方式擴充套件自己的應用，並實現與 Kubernetes 的融合。文章同時也介紹了使用 Operator 的生命週期流程，您可以結合自己的業務場景實現自己的 Operator 元件。

### 作者簡介

**匡大虎** 阿里雲高階技術專家，從事 Kubernetes 和容器相關產品的開發。尤其關注雲原生安全，是阿里雲容器服務雲原生安全核心成員。

**闞俊寶** 阿里雲容器服務技術專家，專注 Kubernetes、Docker、雲端儲存領域，是阿里雲 CSI 專案的核心維護者。

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/aXdbBJlUAQp6YPvZU3isSQ)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

雲原生應用實現規範 - 初識 Operator

相關文章