做容器雲的最佳用戶

原創 2018-01-08 曹亞孟 雲算計

——給用戶看的容器雲的科普和展望

前言

我一直瞧不上容器廠商的企宣話述，連帶著看輕了容器技術；但容器技術是有價值的，容器編排技術更是一片大好的發展方向。

我很討厭這些電線杆小廣告的宣傳方式：可以實現彈性伸縮、自動化運維、持續交付、微服務、秒級部署、高強度容災、多版本控制等功能，從而改善和解決複雜的IT應用場景。事實上是使用者自己設計維護可以彈性伸縮、自動運維、容災冗餘的程序，無論是用物理機、虛擬機還是容器（進程），本來能彈性的服務還是能彈性，沒容災的服務還是在賭命。

合格的架構和運維都瞧不上這些廢話，因為十年前我們用裸機就能實現這些功能了。但世上沒有那麼多合格的架構師，雲計算要解決的就是缺人的問題。最早的雲主機也是類似誇張無賴的宣傳，我第一眼看雲主機也覺得是個噱頭，這些遺毒至今還在誤導客戶。本文是為說清容器的能力特性，我們該如何用好容器編排系統。

容器的基礎特性

容器和虛擬機都屬於IaaS雲的範疇，按申請資源量付費，不關注客戶業務邏輯和訪問頻率。容器只是隔離出一個進程，而虛擬機是模擬了一整套操作系統，這是雙方的本質區別。

進程的創建就是申請內存、埠等系統資源，但應用的初始化仍然需要時間，所以容器啟動到服務可用仍然需要幾秒甚至更久。容器的快速部署優勢在於CI/CD環境里，快速部署不只是說程序啟動的快慢，而是決策的快、操作的簡單。

容器是一個進程，本地文件系統是容器最大短板。文件和設備的所與者都是「用戶/OS/虛擬機ID」這類長效標識，不可能是「進程ID/容器ID」這類臨時狀態。假設我在一個虛擬機上開了多個容器分別讀寫多個文件夾，現在我重新啟動這些容器，新啟動的容器根本不知道自己「上輩子是哪個容器」，該接管哪個文件夾。K8S 的 StatefulSet 已經在嘗試將磁碟等資源綁定到一個Pod內，但這個功能還不夠成熟，且需要外部存儲系統的支持，所以容器使用本地文件存儲仍然是一種冒險行為。

我們該引導客戶放棄本地文件存儲的習慣，本地只讀寫重啟就失效的緩存和socket文件，讓容器用戶將持久化文件都放到對象存儲和資料庫。這是個必然的技術趨勢，即使不用容器用物理機，本地文件都是無法被統一讀取的，集中存儲在OSS和RDS的數據，才能稱之為數據資產。

少談做容器能省資源

容器因為虛擬化程度低，肯定比虛擬機要節省資源，但面對這種詭辯我會三聯問：

• 「您的職場生涯中關注過消耗伺服器資源嗎？」
• 「拿省下的錢給你們團隊發工資好不好？」
• 「為了資源效率，我們直接用裸機行嗎？」。

容器公司見到客戶就談價格談省錢，又說不清楚省了多少錢，實際上砍了IT項目才是最省錢的，能解決問題客戶可以多花錢。

在雲平台運營過程中，容器技術確實能節省成本，但這是靠容器資源的更小調度粒度決定的。假設一台物理機有180G內存可用，客戶買了5台32G內存的虛擬機用了160G，剩餘20G內存就是賣不出去了。但如果拿這20G內存給一堆只用500M到2G的容器進程用，還是整機都跑小容器不跑大虛機，資源利用率一下就高很多了。那閑置的20G內存成本早晚也要把攤到客戶身上，但這和客戶直接可視的資源售價沒關係。

這個理由最蠢的地方就是，它把容器雲的客戶限定成了對成本敏感的運維人員，而使用和更新容器、使用容器編排系統，都是要研發人員一起努力才能發掘出來。

容器編排系統的核心優勢

很多人都說容器雲是「私有雲誰用誰爽，公有雲誰用誰喪」，其實原因就是：容器雲需要開發人員配合才能用好，而容器編排系統比容器自身更重要。K8S與其說是Docker的競爭者，不如說是容器行業的庇護者。有了K8S這個容器編排系統，雖然Docker技術不那麼醒目了，但其可用性更高更接地氣了。

單純用Dokcer的容器，更像是個封裝的比較徹底，做足了資源隔離的JVM。研發人員只在程序出錯時才會關注Runtime，而運維人員沒感覺到這有什麼酷的，但確實容器雲已經有存在的價值了。比如說OpenStack、PaddlePaddle這類新興軟體和開發框架的部署環境沒那麼簡單，用Docker包一層就變的非常友好了。

對於持續集成和交付場景來說，以前我們是硬壓著研發和測試，務必保持版本一致、務必保證文件打好包，從不盲信回滾預案，必須後半夜上線，就這樣還天天出故障；現在自動上線的壓力確實小多了，大家都可以放心測試生產環境一致、保證文件不漏傳、可以和Git無縫集成，可以扔給研發和測試半自助上線了。這就是我前文所說的，容器快速部署的優勢在於決策的快、操作的簡單。

而K8S的興起它把容器從改良工具變成了革新武器。以前有過很多架構師做培訓和文檔，講解服務發現、註冊、編排、路由，資源監控和統計，研發就是說聽不懂。可是一套來自大廠的開源方案出來了，研發就主動去擁抱了。有了K8S以後，即使研發人員做不了架構和運維，只要肯適應K8S的設計邏輯，都可以取代這兩類人的工作。他們通過配合了K8S或類似組件的容器雲，老老實實改變研發流程，讓代碼和架構，讓架構和資源耦合到一起。

現在我們能說清楚過去為什麼沒有公有容器雲成功案例，因為客戶的執行層是腦臀分離的——運維推動研發把程序改造到可以上容器，以完成運維的業績，貓讓狗幫忙抓條魚給貓吃，這事能搞定才怪。而成功的私有雲案例，其原始推動力都是客戶的技術決策層和架構師，他們不依賴K8S也能搞定架構問題，這不是容器技術和容器廠商的成功，而是客戶技術團隊的成功案例。

現在是個有趣的節點了，K8S在逐漸被大家接受，研發擁抱K8S就可能設計出符合架構美學的服務。相信很快就會出現容器雲的真正成功案例——客戶技術足夠普通但上雲後架構足夠合理。

文末總結

以前我看到虛擬機套單容器的事情，因為不信任他們老套的宣傳話述，狠狠的嘲笑了這些容器雲從業者。

但我和一個值得信任的高手聊天時，他反問我，這種架構除了看起來不夠優雅，有沒有什麼邏輯上的致命問題？

如果有一些服務就是要業務進程包在容器里，但數據文件就是要落在硬碟上，這時候用容器加雲主機可以說是一種取長補短的嫁接，總好過拿pod本地存儲做冒險。

我也是因為這次會面而想寫本文，開始更正態度看容器的，有問題的人用過的工具一樣可以是好工具。

想想自己曾經也對雲計算不屑一顧，人生的循環真是有趣。

備註

1.本文中的運維指的是業務服務運維，不是資源支撐運維。

2.很多人會跟我說容器比虛擬機啟動的快，但容器應該跟虛擬機里的進程比重啟速度啊，虛擬機重啟進程也不用重啟系統啊。

3.我一般說docker純粹指的是它的容器部分，不包括swarm等部分。

4.在我看來容器對系統運行環境的封裝就是像個jvm，我知道容器封裝的更多更徹底，但這只是五十步和一百步的區別。

5.我知道文中沒把docker和k8s分太清楚，但這是給客戶看的，不是內部考核用的，請大家腦補時往好處想。