編排的藝術| K8S 中的容器編排和應用編排

衆所周知，Kubernetes 是一個容器編排平台，它有非常豐富的原始的 API 來支援容器編排，但是對于使用者來說更加關心的是一個應用的編排，包含多容器和服務的組合，管理它們之間的依賴關系，以及如何管理存儲。

在這個領域，Kubernetes 用 Helm 的來管理和打包應用，但是 Helm 并不是十全十美的，在使用過程中我們發現它并不能完全滿足我們的需求，是以在 Helm 的基礎上，我們自己研發了一套編排元件……

什麼是編排？

不知道大家有沒仔細思考過編排到底是什麼意思? 我查閱了 Wiki 百科，了解到我們常說的編排的英文單詞為 “Orchestration”，它常被解釋為:

• 本意:為管弦樂中的配器法，主要是研究各種管弦樂器的運用和配合方法， 通過各種樂器的不同音色，以便充分表現樂曲的内容和風格。
• 計算機領域:引申為描述複雜計算機系統、中間件 (middleware) 和業務的自動化的安排、協調和管理。

有趣的是 “Orchestration” 的标準翻譯應該為“編配”，而“編排”則是 另外一個單詞 “Choreography”，為了友善大家了解， 符合平時的習慣，我們還是使用編排 (Orchestration) 來描述下面的問題。至于“編配 (Orchestration)” 和 “編排(Choreography)” 之争，這裡有一篇文章，有興趣可以看一下 。

編配和編排的定義之争

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

我們來重新審視一下之前的例子：

應用層面的四個問題

通過前面的探索，我們可以引出應用層面的四個問題：

1. 應用包的定義
2. 應用依賴管理
3. 包存儲
4. 運作時管理

在社群中，這四個方面的問題分别由三個元件或者項目來解決:

• Helm Charts: 定義了應用包的結構以及依賴關系；
• Helm Registry: 解決了包存儲；
• HelmTiller: 負責将包運作在 Kubernetes 叢集中。

Helm Charts

Charts 在本質上是一個 tar 包，包含了一些 yaml 的 template 以及解析 template 需要的 values, 如下圖：templates 是 Golang 的 template 模闆，values.yaml 裡面包含了這個 Charts 需要的值。

Helm Registry

用來負責存儲和管理使用者的 Charts, 并提供簡單的版本管理，與容器領域的鏡像倉庫類似這個項目是開源的。（

github.com/caicloud/he…

）

Tiller

1. 負責将 Chart 部署到指定的叢集當中，并管理生成的 Release (應用)；
2. 支援對 Release 的更新，删除，復原操作；
3. 支援對 Release 的資源進行增量更新；
4. Release 的狀态管理；
5. Kubernetes下屬子項目( github.com/kubernetes/… ) 。

Tiller 的缺陷

1. 沒有内建的認知授權機制，Tiller 跑在 kube-system 分區下，擁有整個叢集的權限；
2. Tiller 将 Release 安裝到 Kubernetes 叢集中後并不會繼續追蹤他們的狀态；
3. Helm+Tiller的架構并不符合 Kubernetes 的設計模式，這就導緻它的拓展性比較差；
4. Tiller 建立的 Release 是全局的并不是在某一個分區下，這就導緻多使用者/租戶下，不能進行隔離；
5. 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 。

本文轉自掘金-

編排的藝術| K8S 中的容器編排和應用編排