- 本文的內容僅限於技術探討，不能作爲指導生產環境的素材；
- 鼓勵讀者購買紅帽培訓獲得更多系統性的培訓。
一、如何在K8S集羣上部署應用？
首先，需要說明的是：Openshift是K8S集羣，但K8S集羣不是Openshift集羣。K8S集羣是Openshift集羣的真子集。
在K8S集羣上部署應用，有幾種方式：
1.通過docker image方式部署
2.通過模板方式部署
3.在Openshift上，我們還可以基於S2I方式部署應用。
在K8S上除了需要部署應用，很多時候還要部署應用集羣，對集羣進行擴縮容等。這時候，我們大多是調整應用dc。嗯，聽起來有一定技術含量。
那麼，有沒有一種方式，可以專門與K8S API集羣對接，實現K8S原生應用的管理？
二、Operator
有，Operator就是。
Operator是一種打包、部署和管理Kubernetes原生應用程序的方法。 Kubernetes應用程序是一個部署在Kubernetes上並使用Kubernetes API和kubectl工具進行管理的應用程序。
Operator是爲了解決一個問題而存在的一個思路。什麼問題？就是我們在管理應用時，會遇到無狀態和有狀態的應用。管理無狀態的應用是相對來說比較簡單的，但是有狀態的應用則比較複雜。
Operator的理念是希望注入領域知識，用軟件管理複雜的應用。例如對於有狀態應用來說，每一個東西都不一樣，都可能需要你有專業的知識去處理。對於不同的數據庫服務，擴容縮容以及備份等方式各有區別。能不能利用K8S便捷的特性去把這些複雜的東西簡單化呢？這就是Operator想做的事情。
Operator本質上是針對特定的場景去做有狀態服務，或者說針對擁有複雜應用的應用場景去簡化其運維管理的工具。
聽起來不錯，但問題的關鍵點在於：
1.Operator的生態如何，到底能管多少個應用。2. Operator是開源，還是閉源廠商按照License或者支持的軟件數量去收費？
Operator Framework是一個開源項目，由CoreOS發起的。2018年初CoreOS被紅帽收購。Operator目前在Openshift上是TP的狀態。相信很快就會正式GA。
Operator Framework提供開發人員和運行時Kubernetes工具，其框架包括三大架構：
它使開發人員能夠基於他們的專業知識構建操作員，而無需瞭解Kubernetes API的複雜性。
管理在Kubernetes集羣中運行的所有Operator（及其相關服務）的生命週期的安裝，更新和管理。
Operator Metering：爲提供專業服務的Operator啓用使用情況報告。
三、Operator的生態
我們看一下目前Operator社區支持的應用，目前有45個，並且數量在持續增加中：
https://commons.openshift.org/sig/operators.html?from=timeline&isappinstalled=0
除了紅帽列出的官方認證的應用種類，其實社區很多應用都在和operator對接，甚至如weblogic。這些都可以部署到Openshift上：
https://github.com/oracle/weblogic-kubernetes-operator
四、實驗展現：couchbase
我自己的Openshift3.11實驗環境中，部署了Operator組件：
我們先註冊Opertor的訂閱（實際上就是部署對應應用的Operator）
我們訂閱Couchbase：
看到了吧，源在coreos:
創建Couchbase的訂閱：
接下來，創建Couchbase Operator：
接下來，通過Operator部署couchbase集羣：
查看運行狀態：查看資源使用情況：
五、總結
一個軟件，不開放就沒有生態，沒有生態就沒有前途。
Operator能否“火”起來，主要取決於其在開源社區的普及程度。Ansible目前這麼普及，在於其在開源社區的受重視程度和影響力。
從目前來看，紅帽正在積極推動這個社區的發展。而很多軟件提供商/開源軟件項目也致力於與Operator對接。如Weblogic、Tensorflow等。
從目前看，我個人看到Operator這個開源項目。