本文介紹業(yè)務(wù)方容器化的成本，同時(shí)談?wù)勅绾谓档瓦@些成本，從而讓容器化過程更為順暢。業(yè)務(wù)方的接入成本主要有如下四種：

• 業(yè)務(wù)遷移和改造的成本
• 鏡像的制作和管理成本
• K8S 的學(xué)習(xí)使用成本
• 容器環(huán)境下一些習(xí)慣轉(zhuǎn)變成本

業(yè)務(wù)遷移和改造成本

業(yè)務(wù)的遷移成本主要體現(xiàn)在把業(yè)務(wù)從物理機(jī)或虛擬機(jī)遷移到容器的過程中，用戶需要完成容器上線，測試業(yè)務(wù)功能，知會(huì)相關(guān)上下游，割接流量，最終下線業(yè)務(wù)并回收舊機(jī)器。鑒于遷移過程中的步驟多，流程長，同時(shí)為了避免對業(yè)務(wù)造成影響，故整個(gè)過程做到自動(dòng)化是非常困難的。對此，似乎沒有特別好的流程或者技術(shù)能夠降低遷移成本。

此外，部分用戶還需對業(yè)務(wù)進(jìn)行一定的改造和解耦。這些改造主要體現(xiàn)在無狀態(tài)化，以容器要求優(yōu)化項(xiàng)目的組織，如配置文件，啟動(dòng)腳本等等，往往需要 PaaS 團(tuán)隊(duì)支撐用戶進(jìn)行改造。然后改造的人力和時(shí)間成本往往比較大，對于這類業(yè)務(wù)，可降低其容器化的優(yōu)先級。

鏡像的制作和管理成本

鏡像制作是容器化必要步驟，Dockerfile 的編寫和維護(hù)，鏡像的制作又是鏡像模塊重要部分�？陀^而言，Dockerfile 學(xué)習(xí)成本比較高，制作一個(gè)優(yōu)雅的鏡像往往需要豐富的經(jīng)驗(yàn)；此外，鏡像制作環(huán)境的維護(hù)也是一個(gè)問題，如果每個(gè)用戶均有一個(gè)制作環(huán)境，勢必會(huì)造成大量資源的浪費(fèi)，如果大家共享一個(gè)環(huán)境，則有可能造成環(huán)境混亂。

對于資源大戶，建議由 PaaS 團(tuán)隊(duì)支撐和教育業(yè)務(wù)方編寫 Dockerfile，并約定一定的規(guī)則。這些 Dockerfile 最好以 git 的方式維護(hù)起來，便于管理維護(hù)。

對于標(biāo)準(zhǔn)化業(yè)務(wù)，它們的目錄組織比如啟動(dòng)方式，部署腳本，配置文件，依賴包等等都遵循某種規(guī)則，那么這類業(yè)務(wù)的鏡像制作相對容易做到自動(dòng)化。根據(jù)這些規(guī)則可以實(shí)現(xiàn)自動(dòng)生成 Dockerfile 并完成鏡像制作，最終讓用戶對鏡像的制作流程無感知。

對于非標(biāo)準(zhǔn)化且資源需求小的業(yè)務(wù)，因其應(yīng)用的環(huán)境和組織較為混亂，Dockfile 的編寫和鏡像制作的成本將非常高，大批量的接入容易會(huì)造成很多不良后果。對于這類用戶，可將其容器化的優(yōu)先級安排底一些，同時(shí)建議先做標(biāo)準(zhǔn)化，再做容器化。

從 PaaS 角度而言，需要維護(hù)到語言層次的基礎(chǔ)鏡像；其次做好引導(dǎo)措施，避免用戶寫出龐雜的鏡像；對于標(biāo)準(zhǔn)化業(yè)務(wù)，實(shí)現(xiàn)自動(dòng)生成 Dockerfile 的模塊。

K8S 的學(xué)習(xí)使用成本

業(yè)務(wù)容器化后，用戶可以通過 K8S 的 API 或者 Portal 來完成生命周期的管理。K8S 具有十幾個(gè) API，這些 API 的請求參數(shù)非常之多，用法較為復(fù)雜，用戶往往需要較長的一段時(shí)間實(shí)踐才能掌握這些參數(shù)的含義。

對于資源大客戶，他們往往在 K8S 基礎(chǔ)上構(gòu)建自身的平臺(tái)，所以通常直接使用 K8S 的 API 來實(shí)現(xiàn)生命周期管理。對于這類用戶，建議由 PaaS 團(tuán)隊(duì)進(jìn)行一定的介紹，讓業(yè)務(wù)方掌握正確的姿勢，避免潛在的風(fēng)險(xiǎn)。

對于采用發(fā)布系統(tǒng)進(jìn)行發(fā)布的用戶，可以打通發(fā)布系統(tǒng)和 K8S。每當(dāng)用戶發(fā)布時(shí)，應(yīng)該先制作鏡像，然后根據(jù)該鏡像更新原有容器實(shí)例。如此，用戶對 K8S 幾乎不感知，大大的降低了學(xué)習(xí)成本。

對于其它一些機(jī)器資源比較少的用戶，建議使用 Portal 完成生命周期的管理。

從 PaaS 角度而言，首先要做好 API 的認(rèn)證和授權(quán)工作，避免安全隱患，同時(shí)做好限流措施。其次，采用一個(gè)完全扁平互通的網(wǎng)絡(luò)非常有利于業(yè)務(wù)接入，完全扁平是指容器和虛擬機(jī)和物理機(jī)均可互通，如此可以避免引入 service 等模塊。

容器環(huán)境下的一些習(xí)慣轉(zhuǎn)變成本

很多用戶反饋了一些體驗(yàn)上的問題，比如缺乏一些常用工具，free 看到的是宿主機(jī)內(nèi)存，容器重啟后文件丟失等等。這些問題可以總結(jié)為三類：

• 富容器 vs 瘦容器
• docker 的隔離性不徹底
• 如何保存有狀態(tài)數(shù)據(jù)或者工具

原則上來說，瘦容器更符合 K8S 和 Docker 的設(shè)計(jì)理念，也符合 Unix 的哲學(xué)：do one thing and do it well；其次，瘦容器的業(yè)務(wù)進(jìn)程即容器內(nèi)部的 pid 1 進(jìn)程，容器的狀態(tài)基本上反應(yīng)了業(yè)務(wù)進(jìn)程的真實(shí)狀態(tài)，為 K8S 提供更為詳盡的信息和故障決策依據(jù)；最后瘦容器節(jié)省存儲(chǔ)空間。從實(shí)踐角度出發(fā)，瘦容器給業(yè)務(wù)接入帶來了很大的困難。首先是如何與公司現(xiàn)有的運(yùn)維體系做好適配，如果容器沒有注入運(yùn)維相關(guān)的 agent，那么可能需要重新實(shí)現(xiàn)大量運(yùn)維相關(guān)模塊，開發(fā)和推廣的工作量之大，可想而知；其次，如果沒有 SSH 等功能，非常影響用戶定位問題。所以，從落地的角度而言，采用富容器更利于業(yè)務(wù)方的接入，實(shí)時(shí)上，業(yè)內(nèi)如阿里等，也采用了富容器的做法。

雖然 namespace, cgroup 等為容器奠定了隔離的基礎(chǔ)，但是 /proc 下的某些文件，包括 sysconf 等系統(tǒng)調(diào)用，并沒有隔離。用戶使用一些如 free, df 等命令，看到的往往是宿主機(jī)的內(nèi)容，非常容易造成誤解。對于 java 9 以下應(yīng)用，由于采用 sysconf 獲取可用資源，非常容易造成 OOM。針對這些問題，要具體問題具體分析，比如改造 free, df 等命令，jvm 啟動(dòng)時(shí)設(shè)置 Xms, Xmx 等參數(shù)。

此外，業(yè)務(wù)方有時(shí)候在容器中存放一些配置文件，工具等等，當(dāng)容器重啟后，這些數(shù)據(jù)往往會(huì)丟失，容易給業(yè)務(wù)方造成困惑，關(guān)于這點(diǎn)，需要告知業(yè)務(wù)方數(shù)據(jù)需要存入持久化存儲(chǔ)中，對于常用工具，可以寫在鏡像的 Dockerfile 或者業(yè)務(wù)初始化腳本中。

小結(jié)

總而言之，除了遷移和改造成本沒有特別好的辦法外，其它成本都可以通過技術(shù)或者流程使業(yè)務(wù)的成本降到最低。從另外一個(gè)角度來說，這些成本并不能給容器化帶來質(zhì)的阻礙。

此外，對于非標(biāo)準(zhǔn)化且占用資源少的業(yè)務(wù)，建議其先做標(biāo)準(zhǔn)化，再做容器化。

標(biāo)簽： 安全 腳本 推廣 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。