1. 程式人生 > >基於docker+kubernetes的一站式運維管理實踐

基於docker+kubernetes的一站式運維管理實踐

【編者的話】本文按照從整體架構到功能模組的順序為我們講述了搜狐自動化運維平臺DomeOS,實現使用者私有叢集的容器化管理和資源智慧分配

專案簡介

2015年下半年,搜狐北京研發中心基於docker和kubernetes開發了一套企業級的一站式運維管理系統——DomeOS。該系統是一個持續交付和自動運維平臺,解決使用者從程式碼自動編譯打包,到線上執行維護的全套需求,採用私有云模式,實現了使用者私有叢集的容器化管理和資源智慧分配。

整體架構:


DomeOS server是整個系統的控制模組,前端和所有邏輯控制均在這部分實現。

Mysql用來儲存專案、部署、使用者、監控等資料資訊

Server可以關聯到程式碼倉庫,目前支援gitlab和svn。

Registry是docker提供的開源私有倉庫,我們對它進行了改造,可以對接到搜狐雲臺的儲存系統,保證了映象的安全性和可靠性。

資源分配、任務排程部分交給kubernetes來完成。

監控部分融合了open-falcon和cadvisor,實現了主機和容器多個維度資訊的收集展示。

另外,為了方便研發及運維同學在部署過程中快速定位問題,加入了webssh模組,能夠通過網頁直接進入到容器內部檢視資訊。domeos支援ldap登入,方便企業使用者使用。

功能模組:

DomeOS提供了專案管理、持續整合、部署管理、映象管理、叢集管理、應用商店、使用者和組管理以及多層級監控服務。以下是功能模組圖:


其中專案管理、叢集管理和部署是比較重要的功能。

專案管理中包含了持續整合,設計方案如下:


使用者在程式碼倉庫的操作,通過webhook將操作資訊傳送給DomeOS server,server根據專案關聯配置資訊確認是否滿足構建任務的出發條件,如果滿足,Domeos server下發構建任務給kubernetes master,master挑選符合條件的slave啟動構建映象,該映象從程式碼倉庫中下載程式碼,根據對應的dockerfile執行構建,構建生成的映象被push到程式碼倉庫中,然後反饋構建日誌及結果給domeos server,server在倉庫中確認過映象資訊後,將構建結果寫入到資料庫中。

叢集管理部分,我們將一套kubernetes部署作為一套叢集,新增叢集是配置kubernetes master資訊的過程,使用者可以在DomeOS中新增多套叢集。


當master資訊配置完成後,我們提供了新增node的指令碼。對於一套叢集,網路部分採用flannel進行管理,每個node上啟動agent上報監控資訊並用於webssh登入。使用者可以通過為主機新增namespace和label進行資源和環境的隔離。

部署管理部分

部署啟動在一個叢集上,採用kubernetes pod的概念,每個部署都從一個或多個映象建立,可以對每個映象配置cpu和記憶體限制,可以在pod中配置一個或多個日誌收集模組,該部分用flume實現,日誌收集到kafka中。網路部分目前支援overlay和host兩種模式,overlay模式的負載均衡用kubernetes的service實現,host模式的負載均衡通過confd+nginx來實現。同一套叢集的部署之間可以通過內網域名互相訪問,這部分通過skyDNS和kube2sky來實現。


每套部署可以建立多個版本,升級回滾採用不同版本之間的切換完成。擴容縮容通過kubernetes的replication controller實現。

Q&A

Q1:“可以在pod中配置一個或多個日誌收集模組,該部分用flume實現” 這塊能具體說下嗎?

A:我們把flume做成了一個映象,利用kubernetes的empty dir來收集其他容器產生的日誌

Q2:你們webssh是自己開發的還是參考了開源專案?感覺debug的時候會很有用

A:我們參考了其他開源專案,自己做了調整

Q3:我想問下 容器內監控是怎麼實現的?每個容器安裝open-falcon的agent嗎

A:每個node上會啟動一個agent,通過agent收集主機和容器的資訊,agent集成了open-falcon的agent和cadvisor

Q4:自動化構建過程中,對應用的測試是怎麼實現的?

A:單元測試可以在編譯的時候完成,功能測試需要啟動部署

Q5:你好,請問你們的網路支援隔離嗎?

A:目前不支援隔離

Q6:你好,我想知道你們的裝置是哪個廠商的?謝謝

A:我們用的是戴爾的伺服器

Q7:感謝開源,試用過程中遇到的問題和反饋意見提交到哪?

A:可以直接在github上提issue,或者直接跟我聯絡

Q8:你們的部署環境是同時使用了overlay模式和host模式嗎,對於預防潛在的衝突你們有什麼好的建議?

A:我們主要對埠衝突做了嚴格限制,host模式下提供了自動尋找20000~21000段可用埠的外掛,overlay模式會根據資料庫中配置檢測衝突

Q9:使用kubernetes編排容器後,你們怎麼做服務發現的?如何解決容器間互相呼叫問題,及容器外調容器內服務問題?

A:我們用skyDNS做服務發現,容器間相互呼叫可以用內部域名,kubernetes叢集內的主機通過修改dns伺服器配置也可以通過內部域名訪問容器

Q10:專案有什麼瓶頸嗎?

A:kubernetes的部署比較複雜,我們做的是私有云下的管理,不同系統下部署會有各種各樣的問題

Q11:剛剛提到webssh在agent裡封裝了docker exec,當在master執行某容器的命令時,具體是如何控制node節點執行docker exec的,agent封裝是自己開發的嗎,還是借用一些第三方工具,kubernetes好像也有kubectl exec?

A:webssh有server端和agent端,agent在每個node節點上,server只要一個就夠了。kubectl也可以exec,不過採用的是kubernetes自定義的連線協議,效能也不如我們目前採用的方案