容器化上云之可行性評估

容器平臺本質上是一個分布式集群管理平臺，首先要從應用負載的性質上分析容器化的合理性。

總的來說，分布式應用負載包括三類：

l?? 計算密集型

典型的計算密集型負載是傳統HPC（高性能計算）應用。

l?? 存儲密集型

典型的存儲密集型負載是大數據應用。

l?? 長任務

典型的長任務負載是web類應用。

計算密集型和存儲密集型的工作負載通常運行于專門的分布式集群管理系統之上，下面主要對長任務類型的負載的容器化進行分析。

首先考慮單個應用或應用組件的容器化，即一個最小部署單元的容器化。

容器基于linux內核技術實現，由于容器實現原理中固有的技術限制，對應用有如下要求：

l?? 能夠基于linux運行；

l?? 應用不能修改系統內核模塊和內核參數；

l?? 應用不依賴于特定的內核版本；

l?? 容器鏡像大小最大不超過3GB；

l?? 應用對網絡帶寬的要求不大于1GE；

l?? 應用對內存的要求不大于32GB；

l?? 應用對CPU的要求不大于32vcpu；

同時，為了更好的運行容器化應用，充分發揮容器平臺的優勢，應用通常需要遵從以下最佳實踐：

l?? 進程無狀態化，對業務請求處理的正確性不依賴于本地文件或內存數據；

l?? 軟件與配置分離，即容器作為不可變的軟件發布包，將環境相關的配置外置到容器鏡像以外，以實現多環境部署；

l?? 快速啟動和優雅退出；

l?? 提供健康檢查的接口，包括存活檢查和業務就緒檢查；

l?? 將日志對接到統一運維平臺集中處理；

l?? 版本前向兼容性，在滾動升級中支持新老版本并存；

為了滿足和遵從上述技術要求和最佳實踐，通常應用需要經過如下改造和適配：

l?? 應用運行時改造，目標是適應容器化的運行時環境和減小運行時基礎軟件包的大小，例如從傳統重量級應用中間件切換到輕量級應用中間件；

l?? 應用無狀態化改造，主要涉及會話狀態，內存中間計算結果狀態，本地文件寫操作等，改為采用分布式緩存，數據庫，分布式文件系統等外置存儲方案；

l?? 應用配置改造，將環境相關的配置信息改為采用環境變量、文件注入、外部配置服務等方式加載，并考慮可動態生效配置的熱加載方案；

l?? 基礎鏡像體系建立，合理的基礎鏡像體系能夠增加安全性，加快鏡像構建和鏡像分發的速度；

l?? 增加健康檢查接口，包括應用存活檢查和業務就緒檢查，通常采用Restful API接口；

解決了單個組件容器化的問題以后，下一步要考慮多個容器之間相互訪問的問題。

不同應用組件之間相互集成時存在兩類場景：

l?? 本地通信，例如采用localhost方式訪問，通常為采用多進程模型的應用。

l?? 遠程通信，采用TCP或UDP協議通過網絡相互訪問。

本地通信的場景中，首先考慮采用Kubernetes的Pod模型進行封裝，同一個Pod內的不同容器共享一套本地網絡和本地存儲環境，能夠達在單機上運行多個進程相同的效果。

遠程通信的場景中，雖然容器之間網絡互通，但由于容器具有動態性，可能隨時增加或減少實例，因此無法通過容器實例的IP地址相互訪問，需要采用Kubernetes的Service模型進行封裝，將可變的容器實例地址轉換為不可變的Service地址，Service地址的形式包括域名和ClusterIP兩種。

容器

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。