DevOps專題|基礎Agent部署系統

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

整體架構

ifrit是阿拉伯神話中一種遇火而生，浴火重生的精靈，只有英雄才有駕馭它的能力。這裏的「火」能夠指代全網每個節點，「英雄」則能夠指代管理員。此外，阿拉丁神話中的「燈神」就是一種ifrit，燈神能夠幫阿拉丁實現願望，京東雲ifrit系統也能夠幫助咱們管理節點。

ifrit 架構自上而下分爲ifrit-manage、ifrit-master、ifrit-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，以下圖所示：

爲了減小因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環上的節點更加均勻，以下圖。

集羣分批完成後，集羣內進行agent全量上線時首先進行小流量驗證，驗證經過後按照必定時間間隔更新redis緩存信息，新增鍵值expect_default_hash1_CONTAINER等。此時ifrit-agent獲取agent版本信息的優先級爲：灰度數據>hash數據>全量數據（時間戳相同的狀況）。還能夠經過暫停更新/刪除redis中hash類型的數據，實現agent上線的暫停與回滾(操做mysql數據間接實現)。

自此，ifrit實現了單集羣內的agent上線分級發佈。

看完本文後，您是否有所收穫呢，若是您想了解更多關於京東雲翼的訊息，歡迎點擊「閱讀」瞭解更多~

也歡迎點擊「京東雲」瞭解更多精彩內容