DevOps專題|基礎Agent部署系統

京東科技開發者發表於2019-12-27

DevOps專題|基礎Agent部署系統

隨著京東雲業務規模、管理機器規模的擴大,各類agent也在逐漸增多,如日誌agent、監控agent、控制系統agent等。這對agent的部署、升級、狀態維護提出了很高的要求,一旦某個全域性agent進行了錯誤地部署、升級,可能會導致agent的資源使用率過高,進而會對全公司的業務產生影響。在此背景下需要有一個統一管理系統來對全網agent的部署、升級進行管控,可以靈活的指定不同的釋出策略進行灰度更新,如按照pin層面升級、按照叢集層面等等。 基於此,京東雲自研了ifrit系統用於全網agent的部署、升級和狀態維護。

總體架構

ifrit是阿拉伯神話中一種遇火而生,浴火重生的精靈,只有英雄才有駕馭它的能力。這裡的“火”可以指代全網每一個節點,“英雄”則可以指代管理員。此外,阿拉丁神話中的“燈神”就是一種ifrit,燈神可以幫阿拉丁實現願望,京東雲ifrit系統也可以幫助我們管理節點。
ifrit 架構自上而下分為 ifrit-manage ifrit-master ifrit-agent三大模組,如下圖所示:

DevOps專題|基礎Agent部署系統

ifrit-agent :負責本機所需業務agent以及ifrit-agent本身的部署、升級、狀態維護,定期從ifrit-master中拉取本機agent配置用以管理本機所有agent。配置完成後向ifrit-master彙報本機的agent狀態資訊。
ifrit-master :每個叢集內部署一套master,向上提供ifrit-manage釋出部署、更新指令和agent狀態查詢介面;向下為本叢集內所有ifrit-agent提供agent配置資訊查詢和agent狀態回傳介面。
ifrit-manage :向使用者提供web介面,在該頁面可以對指定agent進行灰度更新和全量更新、檢視操作記錄等。

ifrit-agent

ifrit-agent設計目標:
•    定期獲取agent配置資訊並向master彙報agent狀態資訊
•    程式包下載、校驗
•    安裝
•    解除安裝
•    升級
•    安裝包完整性檢測
•    例項存活檢測
•    自升級
•    自守護
由於幾乎所有部署、監控等相關功能都依賴於agent,ifrit-agent在機器中以服務形式存在並且開機自啟動。若ifrit-agent啟動時網路服務未啟動。則會導致機器在數分鐘內無法使用部署、監控、日誌服務等功能,同時也無法採集到docker容器類應用的初始化日誌,因此ifrit-agent啟動時配備重試機制,以確保網路服務已經啟動。
ifrit-agent在訪問master介面獲取期望agent狀態資訊時,需要帶上機器型別和機器uuid(例如內網中的ip、雲主機上的instance-id等)。其中機器型別(主要是作業系統、cpu架構)可透過初始化時執行命令獲取,或使用golang中的條件編譯將機器型別直接寫在程式中。

iFrit-master

ifrit-master負責agent管理工作,全網部署agent的增刪查改都是透過ifirt-manage呼叫ifrit-master介面完成的。當叢集規模增大時,直接讀取mysql獲取agent版本資訊會對資料庫造成很大壓力,為了避免這類問題,ifrit-master中採用redis快取,以固定時間間隔讀取mysql中agent版本資訊,併合成為ifrit-agent可直接讀取的資料快取到redis,如下圖所示:

DevOps專題|基礎Agent部署系統

為了減少因agent升級導致的全網業務故障,ifrit-master提供了灰度釋出機制,即指定一批機器更新agent到指定版本灰度執行。待灰度驗證透過後,在叢集內全量部署該agent。同時,ifrit系統可以根據不同機器型別部署不同的業務agent,目前京東雲內支援了容器、linux物理機、arm64架構機器和windows系統機器。

iFrit-manage

ifrit-manage統一管理多個叢集的master,主要功能如下:
• 使用者許可權管理
• 分級釋出(叢集粒度)
• agent狀態查詢
• 操作審計
ifrit-manage本身作為運營後臺的一部分,可讀許可權由運營後臺統一管理。ifrit寫操作是高危操作,預設只有超級管理員(一般為公司運維人員)有寫許可權,其他人員可以透過在配置檔案中新增寫許可權。
根據業務需要,可以將機器劃分到不同叢集中,當有agent需要變更時,運維人員在灰度驗證透過後,按照給定的叢集順序分叢集進行部署。運維完成一個叢集的agent部署後,15分鐘內(ifrit-agent主迴圈週期+ifrit-master redis快取週期)該叢集內所有指定型別機器應當變更生效,運維驗證部署生效後方可對下一個叢集進行部署。

單叢集分級釋出

以上的ifrit系統已經具備了叢集粒度的分級釋出功能,但是隨著叢集規模越來越大,叢集粒度的agent上線仍然有很大風險,因此需要一套更細粒度的分級釋出機制,以便於降低agent上線事故帶來的影響。
ifrit中根據叢集規模大小,使用一致性hash演算法將叢集中的機器均勻分成若干批,並分批上線。一致性hash演算法是hash演算法的改進,和普通hash演算法的關鍵區別是,對於節點和資料(ifrit中使用機器uuid)都做一次hash運算,並比較節點和資料的hash值,順時針方向取距離資料點的節點。若hash後的節點分佈不均勻,可透過引入虛擬節點增大節點數目,從而使得散落在hash環上的節點更加均勻,如下圖。

DevOps專題|基礎Agent部署系統

DevOps專題|基礎Agent部署系統

叢集分批完成後,叢集內進行agent全量上線時首先進行小流量驗證,驗證透過後按照一定時間間隔更新redis快取資訊, 新增鍵值expect_default_hash1_CONTAINER等。此時ifrit-agent獲取agent版本資訊的優先順序為:灰度資料>hash資料>全量資料(時間戳相同的情況)。還可以透過暫停更新/刪除redis中hash型別的資料,實現agent上線的暫停與回滾(操作mysql資料間接實現)。
自此,ifrit實現了單叢集內的agent上線分級釋出。
看完本文後,您是否有所收穫呢,如果您想了解更多關於京東雲翼的訊息,歡迎點選 閱讀 瞭解更多~
也歡迎點選“ 京東雲 ”瞭解更多精彩內容

DevOps專題|基礎Agent部署系統

DevOps專題|基礎Agent部署系統


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69912185/viewspace-2670878/,如需轉載,請註明出處,否則將追究法律責任。

相關文章