隨著京東雲業務規模、管理機器規模的擴大,各類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上線分級發布。
DevOps學習一 基礎概念
從事軟體開發不少年頭,從15年開始逐漸轉管理,很少實際程式設計,也極少動手寫心得體會了。最近的閱讀有所感慨,光讀不寫實際上並不知道自己是否理解,是否有所提高,計畫慢慢講最近的學習和心得通過文章做個記錄。1 藍綠部署 正常的程式更新上線,需要暫停原有伺服器端服務,上傳部署包再重新啟動服務,這期間服務都...
DevOps基礎之持續改善
在devops中,我們喜歡日語單詞。主要是因為精益在日本得到了如此強烈的採用,我們從他們那裡得到了大量的借鑑。像andencord和kaizen。kaizen是乙個受歡迎的開發者文化實踐。kaizen字面意思是變得更好。我們可能會將其粗略地翻譯為持續改進。kaizen是豐田汽車生產系統著名的精益模型...
DevOps專題 大型企業級監控系統設計
10月30日,全球權威資料調研機構idc正式發布 idcmarketscape 中國devops雲市場2019,廠商評估 報告。京東雲憑藉豐富的場景和實踐能力,以及高質量的服務交付和平台穩定性,取得優異出成績,躋身 major players 核心廠商 位置。京東雲devops能力起源於自身的業務實...