知識星球（點選上方公眾號，可快速關註）
來源：koala bear ，
wsfdl.com/kubernetes/2018/09/28/migrate_to_k8s_costs.html
本文介紹業務方容器化的成本，同時談談如何降低這些成本，從而讓容器化過程更為順暢。業務方的接入成本主要有如下四種：
-
業務遷移和改造的成本
-
映象的製作和管理成本
-
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 或者業務初始化指令碼中。
小結
總而言之，除了遷移和改造成本沒有特別好的辦法外，其它成本都可以透過技術或者流程使業務的成本降到最低。從另外一個角度來說，這些成本並不能給容器化帶來質的阻礙。
此外，對於非標準化且佔用資源少的業務，建議其先做標準化，再做容器化。
【關於投稿】
如果大家有原創好文投稿，請直接給公號傳送留言。
① 留言格式：
【投稿】+《 文章標題》+ 文章連結
② 示例：
【投稿】《不要自稱是程式員，我十多年的 IT 職場總結》：http://blog.jobbole.com/94148/
③ 最後請附上您的個人簡介哈~
看完本文有收穫？請轉發分享給更多人
關註「ImportNew」，提升Java技能
