K8S上的分佈式系統應用編排

前言

隨着容器技術的發展，容器的優點：易打包、可複製、隔離性、低開銷，使得不斷的有應用開始從傳統的物理機、虛擬機，逐漸的搬遷到容器上。而 Kubernetes 的誕生和發展壯大，又下降了應用的標準化部署管理的難度，大大加速了應用搬遷到容器的進程。將一個存在前臺、後臺、數據庫的分佈式系統一鍵式部署到 K8S 上時，能夠有哪些方法和途徑呢？

K8S上的應用模型

Kubernetes 對容器應用的編排，是將應用的運行時、配置、服務提供、存儲、鏡像等都定義成了多種資源對象，每種資源對象均可以按照必定的格式進行描述定義。好比環境變量能夠定義到 configmap 對象，也能夠定義在容器的配置中；而應用的運行時，則是多種工做負載：Deployment、StatefulSet、DaemonSet 等。

資源類型	功能
Deployment	定義應用的容器鏡像、資源要求、運行時環境等工做負載相關，無狀態記錄，可任意擴縮容
StatefulSet	定義應用的容器鏡像、資源要求、運行時環境等工做負載相關，存在狀態信息記錄，按序啓動與伸縮
DaemonSet	定義應用的容器鏡像、資源要求、運行時環境等工做負載相關，通常是代理類應用，會在每一個節點上運行實例
Job	定義應用的容器鏡像、資源要求、運行時環境等工做負載相關，短時任務類，執行完成即退出
ConfigMap	定義配置，可用於掛載到容器的環境變量或者文件中
Secret	定義敏感配置信息，可用於掛載到容器的環境變量或者文件中
Service	定義應用的訪問入口
Ingress	定義應用的http訪問入口
... ...

一個應用就會至少有一個工做負載，以及一些配置，訪問入口等資源對象。經過控制這些資源對象，就能夠完成一個應用，或者多個應用的統籌管理，這就是k8s上的應用編排。最原始的方式固然是直接操控每個的資源對象，可是，多個分散的文件，又沒有變量替換功能，就意味着這些文件只能在一套環境上執行，一旦環境有變化，還須要手動修改文件的內容；這些對象之間還必須以必定的前後順序執行，不然會失敗。當應用更多時，執行的流程就會更加的複雜。

分佈式系統的編排要求

下面是一個典型的分佈式系統，包括前端程序、後臺程序、後臺數據庫，負載均衡器等。在應用系統發展到必定程度，天然而然的就會對系統的各部件角色進行拆分，對於每種角色，均可以進行必定的水平或者垂直的擴展，保證應用的擴展性，解除系統的單點問題。

這樣的一個系統，對應用編排有這些要求：

1. 系統中能夠定義多種應用

2. 每一個應用的多個資源對象之間，能夠定義控制依賴關係

3. 不一樣應用之間存在配置上的傳遞

4. 不一樣應用之間存在啓動順序上的前後依賴關係

Helm：社區原生的包管理工具

因爲 K8S 的資源對象都具有着必定的格式化規範，社區提供了 Helm 用於處理 k8s 應用的打包，這個包叫作一個 chart。Chart 的包格式以下：一個Chart.yaml文件，用戶定義包的名稱、版本等信息，一個templates目錄，裏面定義了這個應用全部相關的資源描述的 go-template 語法的模板，而模板使用到的變量，則在values.yaml文件中進行聲明定義。

Helm 的實現原理很簡單，在客戶端實現變量的渲染替換，再將完整的內容傳遞到服務端（tiller），由 tiller 將生成的 k8s 對象按照必定的順序調用 k8s 接口，完成應用的編排建立。

helm 還支持了 dependency 的依賴關係，用於 chart 包之間的引用。而應用之間的參數傳遞，也能夠經過共享相同的變量輸入來完成。這樣，分佈式系統要求的1,2,3,4看起來也都知足了。

可是，在helm的實際應用中，存在着下面的幾個問題。

• 應用中的任務下發，只控制了請求的發送順序，並不能保證建立完成的前後順序。這就致使了有時候 secret 之類的對象還沒有處理完成，deployment 就去引用而失敗的狀況。

• 對於 Deployment 之類的工做負載，helm 沒有去真正的判斷實例是否啓動就緒完成了，即便應用實例由於某些緣由失敗了，helm也感知不到。

• Helm 的 dependency 依賴，只控制了 chart 包的引用，實際上的多個應用一塊兒建立時，仍是所有展開按照類型順序統一執行的。

• Chart 包的模板編寫，一方面須要用戶對k8s的資源對象結構有必定的理解基礎，另外一方面go-template的引入使得模板變成了非格式化的結構，沒法正常的進行校驗處理，致使容易出錯。

對於 Helm 在處理分佈式系統中遇到的問題，並不是難解。核心在於一套完善的DAG框架，可以精確控制全部的步驟流程，以及每一個步驟的結果管理和傳遞。 而這套框架最好是格式化的簡單的結構，不須要那麼複雜，要精通 K8S、go-templat e等等，最好有圖形化的界面，能夠輔助編寫。

應用編排服務：解決依賴和配置傳遞

華爲雲上的應用編排服務（如下簡稱 AOS），就是這樣一個可以知足複雜分佈式應用在 K8S 上的各類要求的系統。AOS 服務對接了華爲雲的雲容器引擎（CCE服務），提供了一套規範化的模型結構，可定義 K8S 上的各類資源對象。經過模型設計的模板，能夠實現複雜分佈式系統的一鍵式編排建立在 K8S 集羣上。

• 優秀的圖形化設計器，經過圖形化拖拽便可設計應用結構，將應用所需的各類資源，精確控制全部對象的執行順序關係，實現最大化的並行。

• 經過編排語法能夠將應用之間的共享參數、應用的輸出訪問地址等信息進行傳遞輸出。

• 良好的變量輸入輸出機制，將應用在不一樣環境中的部署所需配置提煉，實現一套模板，多處複用。

前面的分佈式系統，在 AOS 編排設計後，就能夠成爲下面的這個圖。這樣的一個分佈式系統，將依次建立 DB 數據庫，執行建立數據庫表結構的job，而數據庫的訪問信息將記錄到secret中，由兩個後端程序app1-back2，app-backend1 掛載使用。兩個後端程序還同時引用了共同的配置 appconfig。前臺應用經過 ingress 和 service 去訪問後端程序，並提供了 ingress 用於外部訪問。這個圖中沒有體現負載均衡器，由於這裏的 ingress 配置了鏈接華爲雲的 ELB 服務。

應用編排系統還支持編排管理雲上的各類服務，好比 RDS 數據庫，ELB 負載均衡器等，利用這些服務，將簡化分佈式系統的雲上架構，幫助用戶聚焦在自身的業務，再也不須要花大力氣在業務的交付和部署運維上。