政採雲基於 sealer 的私有化業務交付實踐

作者:政採雲|汪勳

近年來, 互聯網極速發展,爲了跟進業務快速增長的發展步伐,新的技術如雨後春筍般不斷的湧現,一眼望去,漫天星光,羣星爭豔。以容器爲核心的雲原生技術成長迅速,其中 Kubernetes 作爲新的基礎設施,容器編排事實上的標準, 無疑是最耀眼的那顆星。

然而,Kubernetes 雖然很好的解決了大規模應用部署,資源管理及調度的問題,但是其對業務交付並不友好,Kubernetes 自身的部署也比較複雜,在不斷湧現的圍繞 Kubernetes 生態的應用中, 始終缺少了可以將業務、中間件、集羣整合起來一體化交付的應用。

在當下,由阿里雲智能雲原生應用平臺團隊發起, 政採雲、諧雲科技合作共建的 sealer 開源項目補充了 Kubernetes 在一體化交付領域的短板,sealer 以非常優雅的設計方案考慮了集羣 + 分佈式應用的整體交付。而政採雲作爲政府採購行業的代表,已成功的利用 sealer 完成了大型分佈式應用的整體私有化交付,交付的實踐充分證明了:sealer 具備靈活,強大的一體化交付能力。

背景

政採雲的私有化交付客戶爲政企場景,需交付業務規模較大:300+ 業務組件, 20+ 中間件,交付目標的基礎設施不同構且不可控,網絡限制嚴格,一些敏感的場景甚至是完全隔離的網絡,在這種背景下,業務交付的最大痛點就是部署依賴的處理以及交付一致性的問題。雖然業務統一基於 Kubernetes 進行交付實現了運行環境的一致,但是如何解決部署過程中所依賴的所有鏡像、 各種包的統一處理以及交付系統自身的一致性等一系列問題,亟需解決。

file 如上圖所示政採雲本地化交付的流程中, 主要分爲:用戶需求確認-> 提出資源需求給用戶 -> 獲得用戶所提供的資源清單 -> 根據資源清單生成準備配置 -> 準備部署腳本及依賴 -> 實際交付六個步驟。前置準備和實際交付時, 需要消耗大量的人力和時間來準備和進行部署。

私有化交付的痛

雲原生時代,docker 的出現解決了單個應用的環境一致性和打包問題,業務的交付不再像傳統的交付那樣花費大量的時間在部署環境依賴上。而後 Kubernetes 等容器編排系統的出現解決了對底層資源進行統一的調度,對應用運行時進行統一的編排的問題,然而一個複雜的業務, 其交付的本身就是一個工程浩大的問題,以政採雲的場景爲例:各種 helm chart、RBAC, istio gateway,cni,中間件等各種資源對象的部署和配置,再加上 300 餘業務組件的交付,每一次私有化交付帶來的都是大量人力和時間成本的消耗。

政採雲正處於業務高速發展的時期, 私有化部署項目的需求不斷新增,高成本的交付方式越來越難以支撐實際的需要,如何降低交付成本,並保障交付的一致性是運維團隊最迫切的需要解決的問題。

發現 sealer

在早期, 政採雲使用 ansible 來進行業務的交付,ansible 方案實現了一定程度的自動化並降低了交付成本但是存在如下幾個問題:

1、ansible 只解決部署過程問題,需要單獨準備部署所需的依賴,依賴的準備和可用性驗證產生了額外的成本,且政採雲的本地化場景基本都會嚴格限制外部網絡。直接從外網獲取依賴的方式也不可行。

2、使用 ansible 應對差異化的需求會非常累, 政採雲的私有化交付場景中,各個用戶的需求不一, 業務的依賴不一,每一次的交付重新編輯 ansible playbook 都要花費不少的時間進行調試。

3、涉及到複雜的控制邏輯時,ansible 的聲明語言比較乏力。

4、部署交付之前需要先準備 ansible 的運行環境。無法做到交付的0依賴。

ansible 更多的是在做一些粘合的事情,更適合邏輯比較簡單的運維工作。隨着本地化項目不斷新增, ansible 交付的弊端開始顯現,每個本地化項目都需要大量的時間投入,政採雲運維團隊開始探索和思考交付體系的優化方向。我們調研了很多的技術方案,但是已有的 Kubernetes 的交付工具都專注於集羣本身的交付而不考慮業務層交付。雖然可以基於集羣部署工具進行封裝,但是這種方案和使用 ansible 進行集羣部署後再去部署上層業務並沒有本質的區別。

比較幸運的是,我們發現了 sealer 項目, sealer 是一套分佈式應用打包交付的解決方案,通過把分佈式應用及其依賴一起打包以解決複雜應用的交付問題。其設計理念非常優雅,可以以容器鏡像的生態來管理整個集羣的打包交付。

file 在使用 Docker 的時候,我們通過 Dockerfile 來定義單個應用的運行環境和打包,相應的,sealer 的技術原理可以通過類比 Docker 來進行解釋, 把整個集羣當做一臺機器, 把 Kubernetes 定義爲操作系統,通過 Kubefile 來定義這個"操作系統"裏面的應用並最終打包成鏡像,然後像 Docker run 交付單個應用一樣,sealer run 就可以將整個集羣及應用交付出去。

file 發現 sealer 的驚喜之餘,我們邀請了社區的夥伴來公司進行了交流,sealer 還是一個新項目, 年輕到只誕生了幾個月的時間,在實際的體驗中我們遇到了不少問題,也踩了不少的坑,落地嘗試時,也發現了挺多不滿足需求的地方,但是我們並沒有放棄,因爲我們對 sealer 的設計模式抱有很大的期望和信心, 我們選擇了與社區一起協作共建,共同成長。而最終成功的落地實踐也證明了,我們的選擇非常正確!

社區協作

在決定與社區合作之初,我們對 sealer 進行了全面的測試評估, 結合我們的需求場景, 主要存在如下幾個問題:

1、鏡像緩存成本太高, 最初 sealer 只提供 cloud build 的方式,即打包 sealer 集羣鏡像的前提是需要先基於雲資源拉起一個集羣,我們認爲這種方式成本太高,基於這個需求我們提案並且貢獻了 lite build 的構建方式,支持通過解析 helm、資源定義 yaml、鏡像清單的方式解析鏡像並直接緩存。lite build 是成本最低的 build 方式,無需拉起集羣, 只需一臺要能夠運行 sealer 的主機即可完成 build。

2、業務交付完之後,缺少 check 機制,需要手工去檢查 Kubernetes 集羣的各個組件狀態,然後,我們貢獻了集羣及組件狀態的 check 功能。

3、早期 sealer 的一些配置是固化在 rootfs 中的,例如 registry 的部署主機是固定在第一個 master 節點上的,在實際的場景中我們有自定義的需求,於是我們貢獻了自定義 registry 配置的功能。

4、基於 sealer 部署完集羣后, 還會有向集羣中添加節點的需求,因此我們貢獻了 sealer join 的功能。

此外,還有必要說一下我們落地時幾個很實用,很強大的 sealer 特性:

1、必須提到的一點是 sealer 構建產出的集羣鏡像完全可以直接 push 到私有的 docker 鏡像倉庫例如 harbor 中。然後像 docker 鏡像一樣, 可以基於已有鏡像的基礎上擴充功能並再次 build。

2、sealer 社區優化了 registry 和 docker, 使其支持多源,多域名的代理緩存,這是一個非常實用的功能,在處理鏡像依賴的時候,我們緩存一個鏡像需要變動鏡像的地址,例如需要把一個公共鏡像緩存到私有鏡像中,對應的資源對象引用的鏡像地址也需要同步變更爲私有鏡像倉庫的地址,但 sealer 內置的 registry 經過優化實現了不需要修改鏡像地址也能匹配緩存的功能。此外, sealer 中內置的 registry 作爲 proxy 時,可以代理多個私有化的鏡像倉庫,在具有多個私有倉庫的場景中,是很實用的功能。

落地實踐

使用 sealer 我們重新定義了交付流程,通過 Kubefile 將業務組件、容器化中間件的交付、鏡像緩存等組件的交付直接使用 sealer 來完成。利用 sealer lite build 模式, 自動化的完成依賴鏡像的解析及緩存內置。

利用 sealer 屏蔽了大量應用交付的複雜過程邏輯,和依賴處理邏輯,使實施難度極大的簡化。實施邏輯的持續簡化,使得規模化交付成爲可能。在我們的實踐場景中,使用新的交付系統,交付週期從 15天/人縮短至 2天/人,實現了包含 20G 業務鏡像緩存, 2000G+內存 800+核心 CPU 規模集羣的成功交付。下一步我們計劃通過持續的簡化交付過程,使一個新手只需要簡單的培訓即可完成整個項目的交付。

file

未來展望

落地的成功,收穫的不僅僅是交付系統的成果, 更體現了開源的力量,探索出了與社區合作共建的新模式。在未來,政採雲將繼續支持並參與 sealer 社區的建設,結合實際的業務場景,爲社區提供更多的貢獻。

作爲一個新的開源項目,sealer 的現在並不完美,還存在一些待解決和優化的問題,還有更多的需求和業務場景等待我們去實現,希望通過持續的貢獻,讓 sealer 可以服務於更多的用戶場景, 同時也希望有更多的合作伙伴能夠參與社區建設,讓 sealer 這顆星,更加的璀璨奪目! kubernetes一鍵安裝

sealer集羣整體打包!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章