眾所周知，Kubernetes 是一個容器編排平台，它有非常豐富的原始的 API 來支持容器編排，但是對於用戶來說更加關心的是一個應用的編排，包含多容器和服務的組合，管理它們之間的依賴關系，以及如何管理存儲。
在這個領域，Kubernetes 用 Helm 的來管理和打包應用，但是 Helm 並不是十全十美的，在使用過程中我們發現它並不能完全滿足我們的需求，所以在 Helm 的基礎上，我們自己研發了一套編排組件……
什么是編排？
不知道大家有沒仔細思考過編排到底是什么意思? 我查閱了 Wiki 百科，了解到我們常說的編排的英文單詞為 “Orchestration”，它常被解釋為:
- 本意:為管弦樂中的配器法，主要是研究各種管弦樂器的運用和配合方法，通過各種樂器的不同音色，以便充分表現樂曲的內容和風格。
- 計算機領域:引申為描述復雜計算機系統、中間件 (middleware) 和業務的自動化的安排、協調和管理。
有趣的是 “Orchestration” 的標准翻譯應該為“編配”，而“編排”則是另外一個單詞 “Choreography”，為了方便大家理解， 符合平時的習慣，我們還是使用編排 (Orchestration) 來描述下面的問題。至於“編配 (Orchestration)” 和 “編排(Choreography)” 之爭，這里有一篇文章，有興趣可以看一下 。
編配和編排的定義之爭www.infoq.com
Kubernetes 容器編排技術
當我們在說容器編排的時候，我們在說什么？
在傳統的單體式架構的應用中，我們開發、測試、交付、部署等都是針對單個組件，我們很少聽到編排這個概念。而在雲的時代，微服務和容器大行其道，除了為我們顯示出了它們在敏捷性，可移植性等方面的巨大優勢以外，也為我們的交付和運維帶來了新的挑戰：我們將單體式的架構拆分成越來越多細小的服務，運行在各自的容器中，那么該如何解決它們之間的依賴管理，服務發現，資源管理，高可用等問題呢？
在容器環境中，編排通常涉及到三個方面:
- 資源編排 - 負責資源的分配，如限制 namespace 的可用資源，scheduler 針對資源的不同調度策略；
- 工作負載編排 - 負責在資源之間共享工作負載，如 Kubernetes 通過不同的 controller 將 Pod 調度到合適的 node 上，並且負責管理它們的生命周期；
- 服務編排 - 負責服務發現和高可用等，如 Kubernetes 中可用通過 Service 來對內暴露服務，通過 Ingress 來對外暴露服務。
在 Kubernetes 中有 5 種我們經常會用到的控制器來幫助我們進行容器編排，它們分別是 Deployment, StatefulSet, DaemonSet, CronJob, Job。
在這 5 種常見資源中，Deployment 經常被作為無狀態實例控制器使用; StatefulSet 是一個有狀態實例控制器; DaemonSet 可以指定在選定的 Node 上跑，每個 Node 上會跑一個副本，它有一個特點是它的 Pod 的調度不經過調度器，在 Pod 創建的時候就直接綁定 NodeName；最后一個是定時任務，它是一個上級控制器，和 Deployment 有些類似，當一個定時任務觸發的時候，它會去創建一個 Job ，具體的任務實際上是由 Job 來負責執行的。他們之間的關系如下圖：
一個簡單的例子
我們來考慮這么一個簡單的例子，一個需要使用到數據庫的 API 服務在 Kubernetes 中應該如何表示:
客戶端程序通過 Ingress 來訪問到內部的 API Service, API Service 將流量導流到 API Server Deployment 管理的其中一個 Pod 中，這個 Server 還需要訪問數據庫服務，它通過 DB Service 來訪問 DataBase StatefulSet 的有狀態副本。由定時任務 CronJob 來定期備份數據庫，通過 DaemonSet 的 Logging 來采集日志，Monitoring 來負責收集監控指標。
容器編排的困境
Kubernetes 為我們帶來了什么？
通過上面的例子，我們發現 Kubernetes 已經為我們對大量常用的基礎資源進行了抽象和封裝，我們可以非常靈活地組合、使用這些資源來解決問題，同時它還提供了一系列自動化運維的機制:如 HPA, VPA, Rollback, Rolling Update 等幫助我們進行彈性伸縮和滾動更新，而且上述所有的功能都可以用 YAML 聲明式進行部署。
困境
但是這些抽象還是在容器層面的，對於一個大型的應用而言，需要組合大量的 Kubernetes 原生資源，需要非常多的 Services, Deployments, StatefulSets 等，這里面用起來就會比較繁瑣，而且其中服務之間的依賴關系需要用戶自己解決，缺乏統一的依賴管理機制。
應用編排
什么是應用？
一個對外提供服務的應用，首先它需要一個能夠與外部通訊的網絡，其次還需要能運行這個服務的載體 (Pods)，如果這個應用需要存儲數據，這還需要配套的存儲，所以我們可以認為:
應用單元 = 網絡 + 服務載體 +存儲
那么我們很容易地可以將 Kubernetes 的資源聯系起來，然后將他們划分為 4 種類型的應用：
- 無狀態應用 = Services + Volumes + Deployment
- 有狀態應用 = Services + Volumes + StatefulSet
- 守護型應用 = Services + Volumes + DaemonSet
- 批處理應用 = Services + Volumes + CronJob/Job
我們來重新審視一下之前的例子：
應用層面的四個問題
通過前面的探索，我們可以引出應用層面的四個問題：
- 應用包的定義
- 應用依賴管理
- 包存儲
- 運行時管理
在社區中，這四個方面的問題分別由三個組件或者項目來解決:
- Helm Charts: 定義了應用包的結構以及依賴關系；
- Helm Registry: 解決了包存儲；
- HelmTiller: 負責將包運行在 Kubernetes 集群中。
Helm Charts
Charts 在本質上是一個 tar 包，包含了一些 yaml 的 template 以及解析 template 需要的 values, 如下圖：templates 是 Golang 的 template 模板，values.yaml 里面包含了這個 Charts 需要的值。
Helm Registry
用來負責存儲和管理用戶的 Charts, 並提供簡單的版本管理，與容器領域的鏡像倉庫類似這個項目是開源的。（ https://github.com/caicloud/helm-registry）
Tiller
- 負責將 Chart 部署到指定的集群當中，並管理生成的 Release (應用)；
- 支持對 Release 的更新，刪除，回滾操作；
- 支持對 Release 的資源進行增量更新；
- Release 的狀態管理；
- Kubernetes下屬子項目(https://github.com/kubernetes/helm) 。
Tiller 的缺陷
- 沒有內建的認知授權機制，Tiller 跑在 kube-system 分區下，擁有整個集群的權限；
- Tiller 將 Release 安裝到 Kubernetes 集群中后並不會繼續追蹤他們的狀態；
- Helm+Tiller的架構並不符合 Kubernetes 的設計模式，這就導致它的拓展性比較差；
- Tiller 創建的 Release 是全局的並不是在某一個分區下，這就導致多用戶/租戶下，不能進行隔離；
- Tiller 的回滾機制是基於更新的，每次回滾會使版本號增加，這不符合用戶的直覺。
Release Controller
為了解決上述的問題，我們基於 Kubernetes 的 Custom Resource Definition 設計並實現了我們自己的運行時管理系統 – Release Controller， 為此我們設計了兩個新的 CRD – Release 和 Release History。
Release 創建
當 Release CRD 被創建出來，controller 為它創建一個新的 Release History, 然后將 Release 中的 Chart 和 Configuration 解析成 Kubernetes 的資源，然后將這些資源在集群中創建出來，同時會監聽這些資源的變化，將它們的狀態反映在 Release CRD 的 status 中。
Release 更新
當用戶更新 Release 的時候，controller 計算出更新后的資源與集群中現有資源的 diff， 然后刪除一部分，更新一部分，創建一部分，來使得集群中的資源與 Release 描述的一致，同時為舊的 Release 創建一份 Release History。
Release 回滾和刪除
用戶希望回滾到某一個版本的 Release, controller 從 Release History 中找到對應的版本，然后將 Release 的 Spec 覆蓋，同時去更新集群中對應的資源。當 Release 被刪除后，controller 將它關聯的 Release History 刪除，同時將集群中的其他資源一並刪除。
架構圖
這樣的設計有什么好處?
- 隔離性：資源使用 Namespace 隔離，適應多用戶/租戶；
- 可讀性：Release Controller 會追蹤每個 Release 的子資源的狀態；
- 版本控制：你可以很容易地會退到某一個版本；
- 拓展性：整個架構是遵循 Kubernetes 的 controller pattern，具有良好的可擴展性，可以在上面進行二次開發；
- 安全性：因為所有的操作都是基於 Kubernetes 的 Resource，可以充分利用 Kubernetes 內建的認證鑒權模塊，如 ABAC, RBAC 。
總而言之，編排不僅僅是一門技術也是一門藝術！謝謝！