作者 | 匡大虎、闞俊寶

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

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

而隨著 Kubernetes 的蓬勃發(fā)展，在數(shù)據(jù)分析，機器學習等領域相繼出現(xiàn)了一些場景更為復雜的分布式應用系統(tǒng)，也給社區(qū)和相關應用的開發(fā)運維人員提出了新的挑戰(zhàn)：

• 不同場景下的分布式系統(tǒng)中通常維護了一套自身的模型定義規(guī)范，如何在 Kubernetes 平臺中表達或兼容出應用原先的模型定義？

• 當應用系統(tǒng)發(fā)生擴縮容或升級時，如何保證當前已有實例服務的可用性？如何保證它們之間的可連通性？

• 如何去重新配置或定義復雜的分布式應用？是否需要大量的專業(yè)模板定義和復雜的命令操作？是否可以向無狀態(tài)應用那樣用一條 kubectl 命令就完成應用的更新？

• 如何備份和管理系統(tǒng)狀態(tài)和應用數(shù)據(jù)？如何協(xié)調系統(tǒng)集群各成員間在不同生命周期的應用狀態(tài)？

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

初識?Operator

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

1. 什么是 Operator

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

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

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

與此同時，在云原生的大背景下，生態(tài)系統(tǒng)是衡量一個平臺成功與否的重要標準，而廣大的應用開發(fā)者作為 Kubernetes 的最直接用戶和服務推廣者，他們的業(yè)務需求更是 Kubernetes 的生命線。于是，谷歌率先提出了 Third Party Resource 的概念，允許開發(fā)者根據(jù)業(yè)務需求以插件化形式擴展出相應的 K8s API 對象模型，同時提出了自定義 controller 的概念用于編寫面向領域知識的業(yè)務控制邏輯，基于 Third Party Resource，Kubernetes 社區(qū)在 1.7 版本中提出了custom resources and controllers?的概念，這正是 Operator 的核心概念。

基于 custom resources 和相應的自定義資源控制器，我們可以自定義擴展 Kubernetes 原生的模型元素，這樣的自定義模型可以如同原生模型一樣被 Kubernetes API 管理，支持 kubectl 命令行；同時 Operator 開發(fā)者可以像使用原生 API 進行應用管理一樣，通過聲明式的方式定義一組業(yè)務應用的期望終態(tài)，并且根據(jù)業(yè)務應用的自身特點進行相應控制器邏輯編寫，以此完成對應用運行時刻生命周期的管理并持續(xù)維護與期望終態(tài)的一致性。這樣的設計范式使得應用部署者只需要專注于配置自身應用的期望運行狀態(tài)，而無需再投入大量的精力在手工部署或是業(yè)務在運行時刻的繁瑣運維操作中。

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

進一步講，Operator 的設計和實現(xiàn)并不是千篇一律的，開發(fā)者可以根據(jù)自身業(yè)務需求，不斷演進應用的自定義模型，同時面向具體的自動化場景在控制器中擴展相應的業(yè)務邏輯。很多 Operator 的出現(xiàn)都是起源于一些相對簡單的部署和配置需求，并在后續(xù)演進中不斷完善補充對復雜運維需求的自動化處理。

2. Operator 的發(fā)展

時至今日，Kubernetes 已經(jīng)確立了自己在云原生領域平臺層開源軟件中的絕對地位，我們可以說 Kubernetes 就是當今容器編排的事實標準；而在 Kubernetes 項目強大的影響力下，越來越多的企業(yè)級分布式應用選擇擁抱云原生并開始了自己的容器化道路，而 Operator 的出現(xiàn)無疑極大的加速了這些傳統(tǒng)的復雜分布式應用的上云過程。無論在生態(tài)還是生產(chǎn)領域，Operator 都是容器應用部署上云過程中廣受歡迎的實現(xiàn)規(guī)范，本小節(jié)就讓我們來一起回顧下 Operator 的誕生和發(fā)展歷史。

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

與此同時，谷歌于 2014 年基于其內(nèi)部的分布式底層框架 Borg 推出了 Kubernetes 并完成了第一次代碼提交。

2015 年，Kubernetes v1.0 版本正式發(fā)布，同時云原生計算基金會 Cloud Native Computing Foundation，簡稱 CNCF）正式成立，基于云原生這個大背景，CNCF 致力于維護和集成優(yōu)秀開源技術以支撐編排容器化微服務架構應用。

2016 年是 Kubernetes 進入主干道，開始蓬勃發(fā)展的一年。這一年的社區(qū)，開發(fā)者們從最初的種種疑慮轉為對 Kubernetes 的大力追捧，無論從 commit 數(shù)量到個人貢獻者數(shù)量都有了顯著增長；同時越來越多的企業(yè)選擇 Kubernetes 作為生產(chǎn)系統(tǒng)容器集群的編排引擎，而以 Kubernetes 為核心構建企業(yè)內(nèi)部的容器生態(tài)已經(jīng)開始逐漸成為云原生大背景下業(yè)界的共識。也正是在這一年，CoreOS 正式推出了 Operator，旨在通過擴展 Kubernetes 原生 API 的方式為 Kubernetes 應用提供創(chuàng)建、配置以及運行時刻生命周期管理能力，與此同時用戶可以利用 Operator 方便的對應用模型進行更新、備份、擴縮容及監(jiān)控等多種復雜運維操作。

在 Kubernetes 實現(xiàn)容器編排的核心思想中，會使用控制器（Controller）模式對 etcd 里的 API 模型對象變化保持不斷的監(jiān)聽（Watch），并在控制器中對指定事件進行響應處理，針對不同的 API 模型可以在對應的控制器中添加相應的業(yè)務邏輯，通過這種方式完成應用編排中各階段的事件處理。而 Operator 正是基于控制器模式，允許應用開發(fā)者通過擴展 Kubernetes API 對象的方式，將復雜的分布式應用集群抽象為一個自定義的 API 對象，通過對自定義 API 模型的請求可以實現(xiàn)基本的運維操作，而在 Controller 中開發(fā)者可以專注實現(xiàn)應用在運行時刻管理中遇到的相關復雜邏輯。

在當時，率先提出這種擴展原生 API 對象進行應用集群定義框架的并不是 CoreOS，而是當時還在谷歌的 Kubernetes 創(chuàng)始人 Brendan Burns；正是 Brendan 早在 1.0 版本發(fā)布前就意識到了 Kubernetes API 可擴展性對 Kubernetes 生態(tài)系統(tǒng)及其平臺自身的重要性，并構建了相應的 API 擴展框架，谷歌將其命名為 Third Party Resource，簡稱“TPR”。

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

與此同時，Operator 以其插件化、自由化的模式特性，迅速吸引了大批的應用開發(fā)者，一時間很多市場上主流的分布式應用均出現(xiàn)了對應的 Operator 開源項目；而很多云廠商也迅速跟進，紛紛提出基于 Operator 進行應用上云的解決方案。Operator 在 Kubernetes 應用開發(fā)者中的熱度大有星火燎原之勢。

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

另外 Operator 作為 Kubernetes 生態(tài)系統(tǒng)中與終端用戶建立連接的橋梁，作為 Kubernetes 項目的設計和捐贈者，谷歌當然也不希望錯失其中的主導權。同時 Brendan Burns 突然宣布加盟微軟的消息，也進一步加劇了谷歌團隊與 Operator 項目之間的矛盾。

于是，2017 年開始谷歌和 RedHat 開始在社區(qū)推廣 Aggregated apiserver，應用開發(fā)者需要按照標準的社區(qū)規(guī)范編寫一個自定義的 apiserver，同時定義自身應用的 API 模型；通過原生 apiserver 的配置修改，擴展 apiserver 會隨著原生組件一同部署，并且限制自定義 API 在系統(tǒng)管理組件下進行統(tǒng)一管理。之后，谷歌和 RedHat 開始在社區(qū)大力推廣使用聚合層擴展 Kubernetes API，同時建議廢棄 TPR 相關功能。

然而，巨大的壓力并沒有讓 Operator 曇花一現(xiàn)，就此消失。相反，社區(qū)大量的 Operator 開發(fā)和使用者仍舊擁護著 Operator 清晰自由的設計理念，繼續(xù)維護演進著自己的應用項目；同時很多云服務提供商也并沒有放棄 Operator，Operator 簡潔的部署方式和易復制，自由開放的代碼實現(xiàn)方式使其維護住了大量忠實粉絲。在用戶的選擇面前，強如谷歌，紅帽這樣的巨頭也不得不做出退讓。最終，TPR 并沒有被徹底廢棄，而是由 Custom Resource Definition（簡稱 CRD）這個如今已經(jīng)廣為人知的資源模型范式代替。

CoreOS 官方博客也第一時間發(fā)出了回應文章指導用戶盡快從 TPR 遷移到 CRD：https://coreos.com/blog/custom-resource-kubernetes-v17

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

3. Operator 的社區(qū)與生態(tài)

Operator 開放式的設計模式使開發(fā)者可以根據(jù)自身業(yè)務自由的定義服務模型和相應的控制邏輯，可以說一經(jīng)推出就在社區(qū)引起了巨大的反響。

一時間，基于不同種類的業(yè)務應用涌現(xiàn)了一大批優(yōu)秀的開源 Operator 項目，我們可以在這里找到其中很多的典型案例，例如對于運維要求較高的數(shù)據(jù)庫集群，我們可以找到像 etcd、Mysql、PostgreSQL、Redis、Cassandra 等很多主流數(shù)據(jù)庫應用對應的 Operator 項目，這些 Operator 的推出有效的簡化了數(shù)據(jù)庫應用在 Kubernetes 集群上的部署和運維工作；在監(jiān)控方向，CoreOS 開發(fā)的 prometheus-operator 早日成為社區(qū)里的明星項目，Jaeger、FluentD、Grafana 等主流監(jiān)控應用也或由官方或由開發(fā)者迅速推出相應的 Operator 并持續(xù)演進；在安全領域，Aqua、Twistlock、Sisdig 等各大容器安全廠商也不甘落后，通過 Operator 的形式簡化了相對門檻較高的容器安全應用配置，另外社區(qū)中像 cert-manager、vault-operator 這些熱門項目也在很多生產(chǎn)環(huán)境上得到了廣泛應用。

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

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

于是我們看到 RedHat 在年初聯(lián)合 AWS、谷歌、微軟等大廠推出了?OperatorHub.io，希望其作為 Kubernetes 社區(qū)的延伸，向廣大 operator 用戶提供一個集中式的公共倉庫，用戶可以在倉庫網(wǎng)站上輕松的搜索到自己業(yè)務應用對應的 Operator 并在向導頁的指導下完成實例安裝；同時，開發(fā)者還可以基于 Operator Framework 開發(fā)自己的 Operator 并上傳分享至倉庫中。

下圖為一個 Operator 項目從開發(fā)到開源到被使用的全生命周期流程：

（Operator 開源生命周期流程圖）

主要流程包括：

• 開發(fā)者首先使用 Operator SDK 創(chuàng)建一個 Operator 項目；

• 利用 SDK 我們可以生成 Operator 對應的腳手架代碼，然后擴展相應業(yè)務模型和 API，最后實現(xiàn)業(yè)務邏輯完成一個 Operator 的代碼編寫；

• 參考社區(qū)測試指南進行業(yè)務邏輯的本地測試以及打包和發(fā)布格式的本地校驗；

• 在完成測試后可以根據(jù)規(guī)定格式向社區(qū)提交PR，會有專人進行 review；

• 待社區(qū)審核通過完成 merge 后，終端用戶就可以在 OperatorHub.io 頁面上找到業(yè)務對應的 Operator；

• 用戶可以在 OperatorHub.io 上找到業(yè)務 Operator 對應的說明文檔和安裝指南，通過簡單的命令行操作即可在目標集群上完成 Operator 實例的安裝；

• Operator 實例會根據(jù)配置創(chuàng)建所需的業(yè)務應用，OLM 和 Operator Metering 等組件可以幫助用戶完成業(yè)務應用對應的運維和監(jiān)控采集等管理操作。

小結

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

Operator 已經(jīng)成為 Kubernetes 生態(tài)的一個重要設計模式，Kubernetes 從 PaaS 層面提供整套集群、應用編排的框架，而用戶通過 Operator 的方式擴展自己的應用，并實現(xiàn)與 Kubernetes 的融合。文章同時也介紹了使用 Operator 的生命周期流程，您可以結合自己的業(yè)務場景實現(xiàn)自己的 Operator 組件。

作者簡介

匡大虎 阿里云高級技術專家，從事 Kubernetes 和容器相關產(chǎn)品的開發(fā)。尤其關注云原生安全，是阿里云容器服務云原生安全核心成員。

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

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號。”

總結

以上是生活随笔為你收集整理的云原生应用实现规范 - 初识 Operator的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。