本文介紹業務方容器化的成本，同時談談如何降低這些成本，從而讓容器化過程更爲順暢。業務方的接入成本主要有如下四種：
- 業務遷移和改造的成本
- 鏡像的製作和管理成本
- K8S 的學習使用成本
- 容器環境下一些習慣轉變成本
業務遷移和改造成本
業務的遷移成本主要體現在把業務從物理機或虛擬機遷移到容器的過程中，用戶需要完成容器上線，測試業務功能，知會相關上下游，割接流量，最終下線業務並回收舊機器。鑑於遷移過程中的步驟多，流程長，同時爲了避免對業務造成影響，故整個過程做到自動化是非常困難的。對此，似乎沒有特別好的流程或者技術能夠降低遷移成本。
此外，部分用戶還需對業務進行一定的改造和解耦。這些改造主要體現在無狀態化，以容器要求優化項目的組織，如配置文件，啓動腳本等等，往往需要 PaaS 團隊支撐用戶進行改造。然後改造的人力和時間成本往往比較大，對於這類業務，可降低其容器化的優先級。
鏡像的製作和管理成本
鏡像製作是容器化必要步驟，Dockerfile 的編寫和維護，鏡像的製作又是鏡像模塊重要部分。客觀而言，Dockerfile 學習成本比較高，製作一個優雅的鏡像往往需要豐富的經驗；此外，鏡像製作環境的維護也是一個問題，如果每個用戶均有一個製作環境，勢必會造成大量資源的浪費，如果大家共享一個環境，則有可能造成環境混亂。
對於資源大戶，建議由 PaaS 團隊支撐和教育業務方編寫 Dockerfile，並約定一定的規則。這些 Dockerfile 最好以 git 的方式維護起來，便於管理維護。
對於標準化業務，它們的目錄組織比如啓動方式，部署腳本，配置文件，依賴包等等都遵循某種規則，那麼這類業務的鏡像製作相對容易做到自動化。根據這些規則可以實現自動生成 Dockerfile 並完成鏡像製作，最終讓用戶對鏡像的製作流程無感知。
對於非標準化且資源需求小的業務，因其應用的環境和組織較爲混亂，Dockfile 的編寫和鏡像製作的成本將非常高，大批量的接入容易會造成很多不良後果。對於這類用戶，可將其容器化的優先級安排底一些，同時建議先做標準化，再做容器化。
從 PaaS 角度而言，需要維護到語言層次的基礎鏡像；其次做好引導措施，避免用戶寫出龐雜的鏡像；對於標準化業務，實現自動生成 Dockerfile 的模塊。
K8S 的學習使用成本
業務容器化後，用戶可以通過 K8S 的 API 或者 Portal 來完成生命週期的管理。K8S 具有十幾個 API，這些 API 的請求參數非常之多，用法較爲複雜，用戶往往需要較長的一段時間實踐才能掌握這些參數的含義。
對於資源大客戶，他們往往在 K8S 基礎上構建自身的平臺，所以通常直接使用 K8S 的 API 來實現生命週期管理。對於這類用戶，建議由 PaaS 團隊進行一定的介紹，讓業務方掌握正確的姿勢，避免潛在的風險。
對於採用發佈系統進行發佈的用戶，可以打通發佈系統和 K8S。每當用戶發佈時，應該先製作鏡像，然後根據該鏡像更新原有容器實例。如此，用戶對 K8S 幾乎不感知，大大的降低了學習成本。
對於其它一些機器資源比較少的用戶，建議使用 Portal 完成生命週期的管理。
從 PaaS 角度而言，首先要做好 API 的認證和授權工作，避免安全隱患，同時做好限流措施。其次，採用一個完全扁平互通的網絡非常有利於業務接入，完全扁平是指容器和虛擬機和物理機均可互通，如此可以避免引入 service 等模塊。
容器環境下的一些習慣轉變成本
很多用戶反饋了一些體驗上的問題，比如缺乏一些常用工具，free 看到的是宿主機內存，容器重啓後文件丟失等等。這些問題可以總結爲三類：
- 富容器 vs 瘦容器
- docker 的隔離性不徹底
- 如何保存有狀態數據或者工具
原則上來說，瘦容器更符合 K8S 和 Docker 的設計理念，也符合 Unix 的哲學：do one thing and do it well；其次，瘦容器的業務進程即容器內部的 pid 1 進程，容器的狀態基本上反應了業務進程的真實狀態，爲 K8S 提供更爲詳盡的信息和故障決策依據；最後瘦容器節省存儲空間。從實踐角度出發，瘦容器給業務接入帶來了很大的困難。首先是如何與公司現有的運維體系做好適配，如果容器沒有注入運維相關的 agent，那麼可能需要重新實現大量運維相關模塊，開發和推廣的工作量之大，可想而知；其次，如果沒有 SSH 等功能，非常影響用戶定位問題。所以，從落地的角度而言，採用富容器更利於業務方的接入，實時上，業內如阿里等，也採用了富容器的做法。
雖然 namespace, cgroup 等爲容器奠定了隔離的基礎，但是 /proc 下的某些文件，包括 sysconf 等系統調用，並沒有隔離。用戶使用一些如 free, df 等命令，看到的往往是宿主機的內容，非常容易造成誤解。對於 java 9 以下應用，由於採用 sysconf 獲取可用資源，非常容易造成 OOM。針對這些問題，要具體問題具體分析，比如改造 free, df 等命令，jvm 啓動時設置 Xms, Xmx 等參數。
此外，業務方有時候在容器中存放一些配置文件，工具等等，當容器重啓後，這些數據往往會丟失，容易給業務方造成困惑，關於這點，需要告知業務方數據需要存入持久化存儲中，對於常用工具，可以寫在鏡像的 Dockerfile 或者業務初始化腳本中。
小結
總而言之，除了遷移和改造成本沒有特別好的辦法外，其它成本都可以通過技術或者流程使業務的成本降到最低。從另外一個角度來說，這些成本並不能給容器化帶來質的阻礙。
此外，對於非標準化且佔用資源少的業務，建議其先做標準化，再做容器化。