普元容器雲平臺實踐分享

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

目錄：

1、爲什麼要上容器雲？

2、普元容器雲建設概述

3、關鍵設計

4、實踐之路

5、總結

 

1、爲什麼要上容器雲？

 

目前，DevOps，微服務與容器雲，能夠說是煊赫一時的三大話題，甚至能夠說它們是雲時代企業新一代IT架構的三大基石也不爲過。微服務主要解決的是開發期的設計問題，DevOps則是解決開發，測試與運維之間的銜接問題，容器雲則是重點在於簡化部署與解放運維。

相較於傳統運維，咱們有太多痛點，下面爲你們分析一二。

痛點分析：

 

• 流程： 有過傳統項目實施經驗的同窗都知道，原來要上一個項目，通常企業都有很嚴格的上線流程。首先開發要出一個很長的上線手冊。先是測試環境，再是預發環境，特別是到了生產環境，須要對着手冊反覆覈對，謹慎操做。一個項目上線下來，心力交瘁。

• 安全：傳統運維不少時候都須要經過命令行進行部署或運維。有時一不當心，很容易對系統形成衝擊，甚至銷燬寶貴的數據。一個運維毀了一個公司的事不是沒有發生過。操做安全，始終都是讓運維心驚的雷區。

• 環境：有時候一個應用，在開發，測試乃至預發環境都一直好好的，一上生產，各類問題，百思不得其解。運維人員也焦頭爛額，壓力山大。

• 自動：應用上線後不免有出現問題須要回滾的狀況，此時須要刪除原有版本，再上新版本，各類配置的修改煩不勝煩。若是這一切均可以自動，那該多好。

• 智能：傳統運維中，應用橫向擴展困難。當流量高峯忽然到來時，每每猝不及防，最終結果往是服務器崩潰，對外服務中斷。如何智能應對流量高峯？

• 追蹤：傳統運維中，應用出現問題也難以定位。問題可能出在哪呢，應用？服務器？網絡？存儲？可能因素太多。

那麼，若是上了容器雲，這些痛點能緩解甚至消失嗎？咱們再來看看。

 

• 流程： 在容器雲中，應用都是打包部署，鏡像中已經包括了一切，因此上線流程一定大幅簡化。只須要界面中選擇，就能夠在不一樣的環境中快速驗證。

• 安全： 在容器雲中，應用打包部署，無需執行shell命令。運維過程當中，平臺上基本能夠看到一切，無需直接登錄生產主機。針對操做安全提升了不止一個檔次。

• 環境： 容器鏡像中自帶標準環境，可最大程度減小運行環境差別。部署與運維對宿主機系統幾乎零侵入，不易出現環境差別問題，程序運行也會更穩定。

• 自動： 在容器雲中，由於部署過程當中平臺已經記錄了應用的全部編排信息，應用的升級與回退變得極其簡單。

• 智能： 配合對每一個容器的性能監控，容器雲能夠根據負載自動調節應用運行的實例數，智能應對流量或性能需求高峯。

• 追蹤： 在容器雲中，對應用運行產生影響的因素相對較少。配合監控與日誌體系，可快速發現並定位問題 。

 

固然，上面咱們分析所列出的問題可能並不全。可是無能否認，容器雲的確能夠爲部署與運維帶來很多的便利與提高。

 

2、普元容器雲建設概述

 

普元的容器雲這幾年一直在發展。2015年的時候，公司啓動了新一代企業雲平臺（內部簡稱新一代）的預研與探索。咱們將應用從需求調研到開發到部署到運維等等，拆分紅了22個領域系統。其中包括PM(項目管理)，IAM（身份識別與訪問管理），SCM（軟件配置管理），SPM(軟件產品管理）等，容器雲是作爲SEM(軟件環境管理）最初在公司出現的。

 

當時的SEM只是一個小模塊，沒有管理門戶，也無需用戶，配置等模板，只有最簡單的容器部署能力。到了2016年，公司加大了對DevOps產品的投入力度。容器雲鬚要作爲DevOps的其中一個部署環境，爲此咱們開啓了第二版（內部名爲kunkka)的研發。此次在原有基礎上加了模板相關的管理等，也有本身的用戶，設置等，但仍然沒有門戶。

 

時至2017年年中，結合外部項目，容器雲發展到了第三代（內部代號arturo)。這一次咱們終於有了門戶，也有租戶，區域，報表，日誌等模塊。一步步走來，模塊愈來愈多，功能愈來愈強愈來愈穩定，咱們對前方的路也更清晰。

如下是咱們當前版本的容器雲的功能架構。底層基於kubernetes，上層則是容器雲提供的能力。上層咱們分了兩大塊，左邊是平臺的功能特性，如租戶，用戶，權限等等管理。而右側呢，則是平臺可以提供出來的基礎服務，包括一系列的中間件。落在咱們的平臺中，就是一堆的模板拆解，參數封裝，部署編排。

爲何咱們要把基礎服務單獨列出來呢？由於咱們認爲，容器雲平臺若是僅僅提供應用的部署，那就有點大材小用了，他有着隱藏的PAAS特性。如今通常的分佈式應用，或多或少都會用到一些中間件，若是容器雲能化身爲一個PAAS平臺，能夠方便地提供這些穩定的中間件服務，將會大大簡化應用的部署。

下面來看一下咱們平臺的總體概念。

其它的概念都比較好理解。咱們重點講一下咱們的系統，部署空間，應用與服務的這四個概念。

首先是部署空間，它其實對標kubernetes中的namespace，是集羣中用來作資源隔離用的，一個集羣能夠有多個namespace，因此也就有多個部署空間。

系統只是一個邏輯概念，咱們通常把它對標一個軟件系統，固然你也能夠把它對標一個項目組或人員小組這樣一個組織機構，比較靈活。它下面關聯着多個部署空間。系統下的應用與服務都將運行在這些部署空間之中。

你們稍微分析一下就能夠發現，系統經過關聯多個部署空間，實際上是間接關聯到了多個集羣。這說明，咱們系統，實際上是能夠跨集羣去進行部署的，它下面的應用與服務，能夠部署在不一樣的集羣中。

應用比較簡單，就是由一個鏡像跑起來的容器，固然不止容器，也包括k8s中的service，HPA之類的，就是一個應用。它的鏡像通常由用戶構建，運行着用戶的實際業務。

服務其實就是咱們上面的基礎服務，它由平臺提供模板，鏡像，參數，部署編排等，通常對應着第三方服務。相對應用，它就要複雜多了，可能有多組Service, Deployment，或者 StatefulSet之類的。

技術選型上，咱們基本上是圍繞着k8s來的，監控目前也就是用的k8s自帶的heapster。鏡像倉庫用的是harbor。

這是目前咱們容器雲的一個部署關係圖。平臺自己的管理中心arturo是先後端分離的。Harbor作爲鏡像倉庫，k8s作爲部署的載體，由Nas經過nfs協議爲pod提供持久存儲。咱們還集成有jenkins，能夠提供從介質至應用鏡像的構建能力。

 

3、關鍵設計

 

下面介紹一些咱們容器雲中的關鍵設計。

1. 首先，此次的版本，咱們摒棄了上一版本容器採用組裝化部署的方式。容器鏡像咱們走回了採用完整鏡像的標準打包方式。完整的鏡像，更容易維護，也利於同DevOps等平臺進行對接。

2. 從概念模型中，能夠看出咱們有租戶的概念。但租戶的並非在每一個表中置入一個租戶字段，它有獨立的對象。只須要將租戶與一些關鍵的對象關聯起來，就能夠起到隔離的目的。

3. 集羣之上，咱們有區域的概念。但這個區域，咱們將它們細分紅了兩類，業務區與部署區。每個集羣，必須同時設置業務區與部署區。不一樣重要等級的業務系統，咱們建議經過搭建不一樣的集羣進行物理隔離。不一樣的集羣可能經過採用不一樣級別的硬件配置及高可靠配置，來達到不一樣的保障級別。業務區與部署區的二維度設計，更利於企業對集羣進行總體規劃。

4. 應用與服務的部署，須要佔用切實的物理資源。不少企業對資源使用，都有比較完善的審批制度。爲了知足這一需求，容器雲集成了本身的BPS流程編排引擎，能夠針對不一樣的企業定製精準的審批流程。咱們目前默認的審批是很簡單的一字型。

5. 容器雲要上生產，高可用是必過的一道坎。普元容器雲目前部署主要是四塊：Arturo管理平臺，Harbor，Jenkins以及Kubernetes。

Arturo自己是先後端分離的，後端無狀態設計，數據庫則採用msqyl主備保證高可用。
 

Harbor咱們利用了它自己的鏡像同步功能來實現雙Harbor高可用。兩個harbor之間都配置了針對對方的複製規則。外部經過vip往harbor中推送或拉取鏡像，vip則由keepalive來保障始終分配在可用的harbor服務器上。

 

每個系統，咱們都會在harbor中爲它建立一個對應的project用來存儲系統的應用鏡像。系統建立時，咱們會在兩個harbor上都建立針對對方的複製規則。Harbor服務器故障恢復以後，只須要從新觸發一次高可用檢查，咱們就能夠在兩個harbor服務上對恢復過程當中缺失的同步規則補充完整，最終保障兩邊有着相同的鏡像。
 

Jenkins咱們採用的是多主的一個部署，而由客戶端來決定構建應當在哪一個服務器上去執行。目前採用的是輪詢的方式。構建任務中會記錄當前它在哪一個服務器上進行構建，若是由於服務器失效而失敗了，沒有關係，從新構建一次就行。
 

Kubernetes咱們的採用的是多master的模式。多master之間，採用的是同一套https的證書，對外只提供一個vip。Vip一樣經過keep avlive來切換。

 

6. 容器雲平臺提供的基礎服務，咱們提供集羣化的部署方案。以redis爲例，咱們採用的是一主二從三哨兵的部署模式。

它有兩個k8s中的service，一個是redis主服務的，一個是哨兵的。Redis主服務的主要用來redis master與slaver之間通訊，保障集羣的穩定。由於要對集羣外也提供服務，因此這裏redis主服務的容器，咱們採用的是hostnetwork，直接在所在節點上暴露端口。

 

Redis哨兵則採用的是nodePort的方式對外提供服務。客戶端首先鏈接哨兵，獲取redis master的地址。由於redis主服務用的是hostnetwork，因此取得的master地址就是 redis master所在節點的IP加上它所暴露的端口。

 

目前微服務是大勢所趨，通常的微服務框架都有服務註冊中心。若是能夠將基礎服務再封裝一下，直接將它的能力接口在註冊中心註冊，這樣其它的微應用使用起來會更加方便。目前咱們針對Dubbo框架，對redis等已經作了封裝，若是你用的是dubbo，能夠很方便地集成它們。

 

7. 容器雲，日誌也是必不可少的一塊。當前咱們採用的是ELKB的方案。採用filebeat採集日誌，kafka緩衝，logstash進行日誌分析，入ES，最後由kibana進行展示。採集方面，咱們採用了兩套filebeat，分別對容器的標準輸出與非標準輸出進行採集。

 

標準輸出採用deamonset中的filebeat進行採集，進入kafka中以Topic-主機名-deamon的topic中。非標準輸出，則須要先將容器內部的日誌掛載至主機某一目錄之中，而後由運行在宿主機上的filebeat進行採集，進入kafka中以 topic-主機名-mount爲名的topic之中。

 

4、實踐分享

 

下面是咱們在某銀行中的一些實踐：

a. 首先介紹一下集羣管理模塊。添加集羣時，須要添加集羣的地址及https證書，同時也須要添加集羣監控heapster中時序數據庫influxdb的地址，這是目前咱們監控信息的來源。

b. 系統管理模塊。建立系統的時候，須要選擇它所在的業務區與部署區。業務區只能選擇一個，但部署區能夠選擇多個（參考前面的概念模型），系統中的應用與服務，能夠部署在不一樣的集羣之中。系統有系統成員的概念，只有爲此係統成員的用戶，才能夠在本身的面板中看到這個系統，在此係統中建立應用與服務。

c. 服務管理模塊。服務詳情頁面中，能夠實時看到各個實例的cpu與內存狀態，能夠看到他們對外提供的訪問點。

建立服務時，須要先選擇服務所在的系統，而後選擇部署區（只能選擇一個）。而後填寫服務的參數。通常的參數咱們都設有默認值，這裏只提供最經常使用的參數供用戶修改。可選是否進行服務擴展，部署dubbo服務提供者。若是須要部署dubbo服務提供者，須要選擇一個dubbo的註冊中心（支持多註冊中心，在系統配置中設置）。

d. 應用管理。應用詳情頁面中，能夠看到應用的性能狀況，以及對外地址。應用支持啓動，中止，重啓，升級，回退，以及刪除。

一樣，應用建立時須要選擇系統與部署區，還須要選擇應用鏡像，填寫應用的版本，參數等。應用支持添加命令行參數及環境變量。應用對外的端口，已在鏡像的配置中預置。

e. 最後介紹一下鏡像管理模塊。咱們將鏡像分紅了公共鏡像與應用鏡像。公共鏡像統一放置在harbor的一個專有project中，應用鏡像則放在每一個系統在harbor上對應的project中。用戶能夠經過使用公共鏡像中的基礎鏡像，加本身的介質，構建出本身的應用鏡像，而後用來應用部署。

5、總結

目前，容器雲不少公司都在發展，不少也是基於k8s的。就像docker同樣的，k8s基本上已成了容器編排的公認標準。可是，怎樣才能用好這個編排呢？怎樣才能讓他更貼近咱們的業務，更好地與微服務框架進行整合呢？普元一直在思考這個問題，也一直在摸索，你們可持續關注咱們EAWorld公衆號，咱們會不斷分享。

本文爲帶來咱們的部分經驗，願與諸君共勉，一塊兒促進容器雲在企業中的落地。

 

 

關於做者：秦雙春，現任普元雲計算架構師。曾在PDM，雲計算，數據備份，移動互聯相關領域公司工做，10年IT工做經驗。曾任上海科企軟件桌面虛擬化產品的核心工程師，主導過愛數TxCloud雲櫃的設計與開發，主導過萬達信息的食安管理與追溯平臺的移動平臺開發。國內雲計算的早期實踐者，開源技術愛好者，容器技術專家。

關於EAWorld：微服務，DevOps，數據治理，移動架構原創  技術分享