簡介
你可能聽過Kubernetes中Operator的概念，Operator可以幫助我們擴充套件Kubernetes功能，包括管理任何有狀態應用程式。我們看到了它被用於有狀態基礎設施應用程式的許多可能性，包括版本升級、節點恢復、調整叢集大小等。
本文我們將揭開Operator的神祕面紗，為如何構建可應用於實際的自定義Operator打下堅實的基礎。
operator到底是什麼？
為了說明operator到底是什麼，讓我們回到Kubernetes的架構上來，Kubernetes本質上是理想的狀態管理器。你為你的應用程式提供了所需的狀態（例項數，磁碟空間，使用的映象等），並且如果任何事情失控，它都會嘗試保持該狀態。Kubernetes在Master節點上使用控制面，控制麵包含許多控制器，這些控制器的工作是按照下面的方式與期望的狀態進行協調（Reconcile）:
- 監視現有的K8S物件（pods,deployments等）去確定他們的狀態
- 比較該物件和它的K8s yaml配置
- 如果狀態和配置不同，控制器將嘗試進行修復（remedy）
進行協調的一個常見的場景是：
一個pod被定義了三個副本，當一個掛了，K8s控制器的監視（watching）下，它意識到應該執行三個pod,而不是兩個，然後，它將建立一個新的pod例項。
下圖簡單展示了控制器在K8s架構中的作用：
- kubectl CLI傳送一個物件配置(Pod,Deployment等)到Master Node的API Server以便在叢集執行
- Master Node將排程（schedule）物件去執行
- 一旦執行，一個控制器將持續件事這個物件並根據它的配置不斷協調（Reconcile）
通過這種方式，Kubernetes方便的代替了大量手動工作，以維護執行時的無狀態應用。然而，它僅限於K8S預定義的物件型別（Pod，Deployment,Namespace,Service,DaemonSet等），這些物件型別中的每一個都具有預定的行為和方式，如果它們和配置發生了偏離，他們就會與配置相協調（Reconcile），以達到所期望的配置。
現在，如果您的應用程式有更多複雜性，那麼你需要自定義Operator以將達到期望的執行狀態。
我們考慮一個有狀態的應用程式，有一個執行在多個節點上的資料庫應用程式。如果大多數節點出現故障，則需要按照特定步驟從指定快照重新載入資料庫。使用Kubernetes中現有的物件型別和控制器，這是不可能實現的。再考慮節點擴容，升級新版本，或為我們的有狀態應用程式進行災難恢復。這些型別的操作通常需要非常具體的步驟，並且通常需要手動干預。
Kubernetes Operators允許你定義一個自定義控制器來watch你的應用程式並根據其狀態執行自定義任務，從而擴充套件了Kubernetes（這是使我們上述的有狀態應用程式自動維護的完美選擇）。
你想要watch的應用程式在Kubernetes中被定義為一個新物件，一個CR（Custom Resource），它有自己的yaml spec和被API Server理解的物件型別（kind）。這樣，你可以在自定義spec中定義任何需要關注的特定標準，並在例項與期望不匹配時進行協調。雖然Operator Controller主要使用自定義元件，但是它的spec和本地Kubernetes的控制器非常相似。
Operator 執行自定義控制器以協調spec。雖然API server能感知到自定義控制器，但是Operator是獨立執行的，可以在叢集內部或外部執行。
由於Operator是有狀態應用程式的強大工具，因此我們看到CoreOS和其他貢獻Etcd,Prometheus等提供了許多Operator，而這些是一個偉大的起點，但是Operator的價值實際上取決於你對它的處理方式：針對故障的具體做法是什麼？以及Operator的功能如何與手動干預一起使用。
嘗試構建Operator：
- 定義我們要watch的應用程式的自定義資源CR spec以及該CR的API
- 編寫一個Custom Controller來監視我們的應用程式
- 新控制器中的自定義程式碼，讓我們知道如何使我們的CR與spec一致。
- 管理自定義控制器中的Operator
- 為了Operator和CR的一個Deployment
以上這些都可以通過手動編寫go程式碼和spec來實現，同時我們可以使用kubebuild、operator-sdk來生成骨架程式碼，讓我們更方便的去關注核心程式碼的編寫。
參考文章：
https://www.linux.com/topic/cloud/demystifying-kubernetes-operators-operator-sdk-part-1/