背景
當前有爲數不少的legacy應用,無法或很難進行改造(微服務化,容器化等),需要安裝各種agent。
傳統應用往往部署在虛擬機上,而虛擬機啓動較慢,不能滿足業務靈活性,彈性的需求。
虛擬化技術堆棧較重,資源損耗大,客戶希望能夠充分發揮強大服務器硬件的能力。
傳統應用的運維人員更傾向於將應用系統視爲pet而不是cattle,發現問題後更希望能手動去做調整。
應用對性能敏感,容器環境下的高密度部署引起的CPU上下文切換等性能造成很大影響。
博雲胖容器技術BeyondVM
BeyondVM是一種container-based實現的胖容器技術,兼容OCI標準,可以靈活的與Kubernetes集羣進行集成。
01
1號進程
容器技術推崇單進程模型,而胖容器技術與容器技術一個明顯的差異點就是在胖容器內部運行一個init進程,而傳統的容器(如 docker 容器等)將容器鏡像中指定的 CMD作爲容器內 pid=1 的進程。BeyondVM技術支持使用systemd和sbin/init作爲init進程。init程序的引入,使得胖容器內的運維工作成爲可能,也爲傳統應用上雲提供了很大的便利。02
容器的CMD
容器的CMD代表了容器內部運行的業務系統。beyondVM技術會自動將其託管在Init進程下,運維人員可以方便的對業務系統進行運維工作。03
系統組件或特定agent
傳統應用和應用的運維人員依賴衆多系統組件,比如ssh/rsyslog/crond等。這部分傳統應用上雲時可以直接安裝相應組件並做成鏡像,這樣既獲取了容器交付可移植性強的優勢,又保留了傳統的使用習慣。04
資源視圖隔離
傳統的應用系統經過多年的維護,往往具有多種的優化措施,例如業務上線後,自動根據環境資源大小調整運行時參數。但傳統容器環境下,即使爲容器設置了cpu/mem配額,容器內部的業務系統仍然會看到主機的計算資源。這對傳統的應用如典型的java應用造成了很多問題。BeyondVM技術利用lxcfs技術對容器的資源進行了視圖隔離,從而讓內部運行的業務系統能自動感知容器自身的計算資源。05
業務啓動前和停止後的鉤子處理
因爲BeyondVM技術與Kubernetes進行了集成,因此可以天然利用kubernetes爲pod提供的鉤子函數實現業務系統啓動前和停止後需要的處理工作。與容器、虛擬機的技術對比
虛擬機 | 容器 | BeyondVM | |
模型 | 基於kvm+qemu,內核隔離 | 基於cgroup+namespace,共享內核
| 基於cgroup+namespace,共享內核
|
資源消耗 | 重 | 輕 | 輕 |
鏡像體積 | 大 | 小 | 小 |
進程模型 | 虛擬機內可以運行多個進程 | 容器內單進程 | BeyondVM內部可以運行多個進程 |
狀態保持 |
|
|
|
彈性伸縮 | 狀態重,彈性伸縮慢 | 手動、自動快速彈性伸縮 | 手動、自動快速彈性伸縮 |
移植性 | 差 | 強 | 中 |
微服務、DevOps支持 | 差 | 強 | 強 |
Kubernetes支持 | 差 | 支持 | 支持 |
主要場景 |
|
|
|
BeyondVM核心優勢
BeyondVM 提供相對完備的進程樹和系統服務的容器環境,使得業務獲得虛擬機的運行體驗,無需改變代碼即可實現向容器平臺的遷移。利用BeyondVM技術,可以實現:- 比虛擬機輕量的資源分配能力,以方便資源快速申請、彈性。
- 類似虛擬機的使用體驗,可登陸,可任意安裝組件。
- 有固定IP地址,胖容器從創建到刪除,IP地址保持不變。
- 可以通過ssh遠程登錄系統。
- 登錄登錄後,可以通過傳統的yum命令安裝標準的軟件包, 比如mysq,apache。
- 可以安裝運維類的agent,不影響應用的正常部署流程。
- 資源隔離,如CPU、內存等。
- JVM,監控類工具看到的資源不是整個物理機的資源,而是真實分配給胖容器使用的資源。
展望
當前容器雲平臺建設的過程中,上線的往往是新的業務系統;企業中大量的存量業務仍然運行在物理機或虛擬機環境中。雖然目前已經有部分企業碰到了傳統應用上雲困難的問題,但整體上這部分需求還不強烈。我們有理由相信,隨着容器技術在企業生態中的佔比逐漸增加,傳統應用上雲的需求會逐步釋放出來,胖容器技術將在其中發揮重要作用。