轉載本文需註明出處：微信公衆號EAWorld，違者必究。
目錄：
一、爲何要上容器雲？
二、普元容器雲建設概述
三、關鍵設計
四、實踐之路
五、總結
一、爲何要上容器雲？
目前，DevOps，微服務與容器雲，可以說是炙手可熱的三大話題，甚至可以說它們是雲時代企業新一代IT架構的三大基石也不爲過。微服務主要解決的是開發期的設計問題，DevOps則是解決開發，測試與運維之間的銜接問題，容器雲則是重點在於簡化部署與解放運維。
相較於傳統運維，我們有太多痛點，下面爲大家分析一二。
痛點分析：
-
流程： 有過傳統項目實施經驗的同學都知道，原來要上一個項目，一般企業都有很嚴格的上線流程。首先開發要出一個很長的上線手冊。先是測試環境，再是預發環境，特別是到了生產環境，需要對着手冊反覆覈對，謹慎操作。一個項目上線下來，心力交瘁。
-
安全：傳統運維很多時候都需要通過命令行進行部署或運維。有時一不小心，很容易對系統造成衝擊，甚至銷燬寶貴的數據。一個運維毀了一個公司的事不是沒有發生過。操作安全，始終都是讓運維心驚的雷區。
-
環境：有時候一個應用，在開發，測試乃至預發環境都一直好好的，一上生產，各種問題，百思不得其解。運維人員也焦頭爛額，壓力山大。
-
自動：應用上線後難免有出現問題需要回滾的情況，此時需要刪除原有版本，再上新版本，各種配置的修改煩不勝煩。如果這一切都可以自動，那該多好。
-
智能：傳統運維中，應用橫向擴展困難。當流量高峯突然到來時，往往猝不及防，最終結果往是服務器崩潰，對外服務中斷。如何智能應對流量高峯？
-
追蹤：傳統運維中，應用出現問題也難以定位。問題可能出在哪呢，應用？服務器？網絡？存儲？可能因素太多。
那麼，如果上了容器雲，這些痛點能緩解甚至消失嗎？我們再來看看。
-
流程： 在容器雲中，應用都是打包部署，鏡像中已經包括了一切，所以上線流程必定大幅簡化。只需要界面中選擇，就可以在不同的環境中快速驗證。
-
安全： 在容器雲中，應用打包部署，無需執行shell命令。運維過程中，平臺上基本可以看到一切，無需直接登陸生產主機。針對操作安全提高了不止一個檔次。
-
環境： 容器鏡像中自帶標準環境，可最大程度減少運行環境差異。部署與運維對宿主機系統幾乎零侵入，不易出現環境差異問題，程序運行也會更穩定。
-
自動： 在容器雲中，因爲部署過程中平臺已經記錄了應用的所有編排信息，應用的升級與回退變得極其簡單。
-
智能： 配合對每個容器的性能監控，容器雲可以根據負載自動調節應用運行的實例數，智能應對流量或性能需求高峯。
-
追蹤： 在容器雲中，對應用運行產生影響的因素相對較少。配合監控與日誌體系，可快速發現並定位問題 。
當然，上面我們分析所列出的問題可能並不全。但是無可否認，容器雲的確可以爲部署與運維帶來不少的便利與提升。
二、普元容器雲建設概述
普元的容器雲這幾年一直在發展。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，可以提供從介質至應用鏡像的構建能力。
三、關鍵設計
下面介紹一些我們容器雲中的關鍵設計。
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之中。
四、實踐分享
下面是我們在某銀行中的一些實踐：
a. 首先介紹一下集羣管理模塊。添加集羣時，需要添加集羣的地址及https證書，同時也需要添加集羣監控heapster中時序數據庫influxdb的地址，這是目前我們監控信息的來源。
b. 系統管理模塊。創建系統的時候，需要選擇它所在的業務區與部署區。業務區只能選擇一個，但部署區可以選擇多個（參考前面的概念模型），系統中的應用與服務，可以部署在不同的集羣之中。系統有系統成員的概念，只有爲此係統成員的用戶，纔可以在自己的面板中看到這個系統，在此係統中創建應用與服務。
c. 服務管理模塊。服務詳情頁面中，可以實時看到各個實例的cpu與內存狀態，可以看到他們對外提供的訪問點。
創建服務時，需要先選擇服務所在的系統，然後選擇部署區（只能選擇一個）。然後填寫服務的參數。一般的參數我們都設有默認值，這裏只提供最常用的參數供用戶修改。可選是否進行服務擴展，部署dubbo服務提供者。如果需要部署dubbo服務提供者，需要選擇一個dubbo的註冊中心（支持多註冊中心，在系統配置中設置）。
d. 應用管理。應用詳情頁面中，可以看到應用的性能情況，以及對外地址。應用支持啓動，停止，重啓，升級，回退，以及刪除。
同樣，應用創建時需要選擇系統與部署區，還需要選擇應用鏡像，填寫應用的版本，參數等。應用支持添加命令行參數及環境變量。應用對外的端口，已在鏡像的配置中預置。
e. 最後介紹一下鏡像管理模塊。我們將鏡像分成了公共鏡像與應用鏡像。公共鏡像統一放置在harbor的一個專有project中，應用鏡像則放在每個系統在harbor上對應的project中。用戶可以通過使用公共鏡像中的基礎鏡像，加自己的介質，構建出自己的應用鏡像，然後用來應用部署。
五、總結
目前，容器雲很多公司都在發展，很多也是基於k8s的。就像docker一樣的，k8s基本上已成了容器編排的公認標準。但是，怎樣才能用好這個編排呢？怎樣才能讓他更貼近我們的業務，更好地與微服務框架進行整合呢？普元一直在思考這個問題，也一直在摸索，大家可持續關注我們EAWorld公衆號，我們會不斷分享。
本文爲帶來我們的部分經驗，願與諸君共勉，一起促進容器雲在企業中的落地。
關於作者：秦雙春，現任普元雲計算架構師。曾在PDM，雲計算，數據備份，移動互聯相關領域公司工作，10年IT工作經驗。曾任上海科企軟件桌面虛擬化產品的核心工程師，主導過愛數TxCloud雲櫃的設計與開發，主導過萬達信息的食安管理與追溯平臺的移動平臺開發。國內雲計算的早期實踐者，開源技術愛好者，容器技術專家。
關於EAWorld：微服務，DevOps，數據治理，移動架構原創 技術分享