整個Web開發社群都在為Kubernetes（K8s）而沸騰。毫無疑問，去年的大會和開發人員集會上這都是最熱的話題。
它並非僅僅是管理容器的工具，實際上，Kubernetes允許使用者輕鬆地新增負載均衡，並且無需使用服務發現層（比如，不再需要eureka[1]）。Kubernetes還能夠自動化應用程式的部署和更新，更為重要的是，它讓使用者可以為自己的基礎架構新增/編寫自定義的控制器。
是不是很棒？但是管理無狀態的容器畢竟並不是那麼複雜，它們本質上是短暫的，你可以隨意殺死並且重新啟動實體，並不會帶來什麼副作用。
但是這隻是故事的一部分，應用程式不可能全部無狀態，在大多數情況下，我們簡單地將狀態推送到下層去處理。因此，在Kubernetes裡如何處理有狀態的應用程式呢？幸運的是，從1.5版本開始出現了StatefulSet。
Kubernetes StatefulSet提供了一系列資源來處理有狀態的容器，比如：volume，stable network id， 從0到N的順序索引等。volume是其中的核心特性之一，讓使用者可以在Kubernetes上執行有狀態的應用，讓我們看看目前支援的兩大主要型別：
短暫儲存的行為和我們在Docker裡使用的有所區別，在Kubernetes裡，短暫儲存在容器外存在，在Pod裡執行，資料可以跨容器的重啟保留。但是如果Pod被殺死，這個捲就會被自動移除。
在持久化儲存裡，正如名字所示，資料的生命週期獨立於Pod的生命週期。因此，即使當Pod不存在或者移動到另外的節點上後，資料仍然會存在，直到被使用者顯式刪除為止。在這種型別的捲裡，資料通常儲存在遠端。
我們希望Kubernetes能夠支援本地持久化儲存，因為這將最適合執行資料庫，但是同時，預設使用短暫的儲存捲。這裡，你可能會問為什麼使用短暫儲存而不是持久化儲存呢？不用太驚訝，有很多原因：
-
短暫儲存比持久化儲存更快更便宜。使用持久化儲存對基礎架構/網路要求更高，因為需要來回傳送資料。
-
Kubernetes 1.9開始支援Raw Block[2]，讓使用者可以應用裡訪問物理磁碟。
-
維護網路儲存系統並不是必需的。
-
永遠可以先首先嘗試重啟容器，而不是殺死整個Pod：kubectl exec POD_NAME -c CONTAINER_NAME reboot
-
可以配置Couchbase來自動化複製資料，因此即使N個Pod都不存在了，資料也不會丟失。
-
Kubernetes的部分工作是在不同的地方執行Pod從而避免大規模故障。
但是，有一些場景裡值得使用遠端持久化儲存，即使會帶來額外的延遲，比如大部分資料庫，當rebalancing行程需要幾分鐘來完成的時候。這也正是為什麼會支援遠端持久化儲存的原因。
Statefullset的一個缺點是受限的管理，這也是我們決定透過使用自定義資源定義（CRD）擴充套件Kubernetes API的原因，這讓我們可以在Kubernetes上建立自定義的原生資源，就像StatefulSet或者Deployment一樣，但是是為管理Counchbase實體而特別設計的。
太好了！使用StatefulSet/CRD我們處理好了所有硬體運維，這裡還漏了一個“小”事情，應用程式本身的狀態如何處理呢？比如，在資料庫裡，向集群裡新增一個新節點很可能不夠，你還需要觸發一些行程，比如rebalancing行程來將一些資料移動/複製到新增節點上，從而讓這個新節點真正起作用。這也正是Kubernetes Operator出場的原因。
Kubernetes 1.7增加了一個重要特性，稱為自定義控制器[3]。總的來說，它讓開發人員可以擴充套件以及增加新功能，替換已有的功能（比如替換kuber-proxy），並且能夠自動化管理任務，就像它們是原生的Kubernetes元件一樣。
Operator就是一系列應用程式特定的自定義控制器。那麼，為什麼說它是遊戲規則改變者呢？控制器能夠直接訪問Kubernetes API，這意味著它們可以監控叢集，改變Pod/服務，擴容/縮容，以及呼叫執行著的應用程式的endpoint，所有這些都根據編寫在這些控制器裡的自定義規則來實現。
為了更好的解釋它的行為，讓我們看看當一個Pod被殺死時，Couchbase的Operator是如何工作的：
正如上圖所示，Operator監控並且分析叢集，同時基於一系列引數，觸發一系列行為來達到所需狀態。這樣的調和行程在Kubernetes裡到處都是。但是並非所有行為都是平等的，在本文示例裡，有兩大主要類別：
這就是Operator的真正能力，它們允許使用者編寫的應用程式能夠完整管理其他應用程式，猜猜什麼型別的有狀態應用程式最難管理？對了，就是：資料庫。
開發人員永遠期望資料庫能開箱即用，但是實際情況通常和期望恰恰相反。我們甚至還有專門負責管理資料庫的特定職位，資料庫管理員。
Couchbase的Operator致力於改變這樣的場景，讓資料庫更易於管理，讓使用者無需鎖定在特定的雲供應商上。目前，它支援自動的叢集預配，彈性伸縮，自動恢復，日誌，並且提供Web控制檯的訪問，將來還會推出更多的特性。如果想瞭解更多，請看這篇文章[4]或者查閱Couchbase的正式檔案[5]。
我還需要說一下，這是針對資料庫的第一個正式的Operator，還有一些小社群專案正在嘗試為MySQL，Postrgres和其他資料庫構建Operator。
Operator的生態系統正在迅速成長，比如rook[6]，讓使用者可以部署非常類似於AWS S3的東西。Apache Kafka Operator即將推出，我們期待在接下來的幾個月裡出現更多的Operator，畢竟所有主流雲供應商都已經支援Kubernetes了。
最後，Kubernetes提供了和雲平臺無關的應用程式部署和管理方式。它非常強大，可能會讓雲供應商變成某種日用品，因為使用者將能夠在雲供應商之間隨意遷移。
未來，對雲供應商的選擇可能就是去選擇誰能夠提供最佳的效能/花費而已。這種根本的改變會帶來的市場影響目前還不是很明朗，但是作為開發人員來說，我們肯定是最大的贏家。
-
https://github.com/Netflix/eureka
-
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/raw-block-pv.md
-
https://kubernetes.io/docs/concepts/api-extension/custom-resources/
-
https://blog.couchbase.com/introducing-couchbase-operator/
-
http://docs.couchbase.com/prerelease/couchbase-operator/beta/overview.html
-
https://github.com/rook/rook
原文連結：https://blog.couchbase.com/kubernetes-operators-game-changer/
本次培訓內容包括：容器原理、Docker架構及工作原理、Docker網路與儲存方案、Harbor、Kubernetes架構、元件、核心機制、外掛、核心模組、Kubernetes網路與儲存、監控、日誌、二次開發以及實踐經驗等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球