我一直瞧不上容器廠商的企宣話述，連帶著看輕了容器技術；但容器技術是有價值的，容器編排技術更是一片大好的發展方向。
我很討厭這些電線桿小廣告的宣傳方式：可以實現彈性伸縮、自動化運維、持續交付、微服務、秒級部署、高強度容災、多版本控制等功能，從而改善和解決複雜的IT應用場景。事實上是使用者自己設計維護可以彈性伸縮、自動運維、容災冗餘的程式，無論是用物理機、虛擬機器還是容器（行程），本來能彈性的服務還是能彈性，沒容災的服務還是在賭命。
合格的架構和運維都瞧不上這些廢話，因為十年前我們用裸機就能實現這些功能了。但世上沒有那麼多合格的架構師，雲端計算要解決的就是缺人的問題。最早的雲主機也是類似誇張無賴的宣傳，我第一眼看雲主機也覺得是個噱頭，這些遺毒至今還在誤導客戶。本文是為說清容器的能力特性，我們該如何用好容器編排系統。
容器和虛擬機器都屬於IaaS雲的範疇，按申請資源量付費，不關註客戶業務邏輯和訪問頻率。容器只是隔離出一個行程，而虛擬機器是模擬了一整套作業系統，這是雙方的本質區別。
行程的建立就是申請記憶體、埠等系統資源，但應用的初始化仍然需要時間，所以容器啟動到服務可用仍然需要幾秒甚至更久。容器的快速部署優勢在於CI/CD環境裡，快速部署不只是說程式啟動的快慢，而是決策的快、操作的簡單。
容器是一個行程，本地檔案系統是容器最大短板。檔案和裝置的所與者都是“使用者/OS/虛擬機器ID”這類長效標識，不可能是“行程ID/容器ID”這類臨時狀態。假設我在一個虛擬機器上開了多個容器分別讀寫多個檔案夾，現在我重新啟動這些容器，新啟動的容器根本不知道自己“上輩子是哪個容器”，該接管哪個檔案夾。Kubernetes的StatefulSet已經在嘗試將磁碟等資源系結到一個Pod內，但這個功能還不夠成熟，且需要外部儲存系統的支援，所以容器使用本地檔案儲存仍然是一種冒險行為。
我們該引導客戶放棄本地檔案儲存的習慣，本地只讀寫重啟就失效的快取和socket檔案，讓容器使用者將持久化檔案都放到物件儲存和資料庫。這是個必然的技術趨勢，即使不用容器用物理機，本地檔案都是無法被統一讀取的，集中儲存在OSS和RDS的資料，才能稱之為資料資產。
容器因為虛擬化程度低，肯定比虛擬機器要節省資源，但面對這種詭辯我會三聯問：
-
“您的職場生涯中關註過消耗伺服器資源嗎？”
-
“拿省下的錢給你們團隊發工資好不好？”
-
“為了資源效率，我們直接用裸機行嗎？”
容器公司見到客戶就談價格談省錢，又說不清楚省了多少錢，實際上砍了IT專案才是最省錢的，能解決問題客戶可以多花錢。
在雲平臺運營過程中，容器技術確實能節省成本，但這是靠容器資源的更小排程粒度決定的。假設一臺物理機有180G記憶體可用，客戶買了5臺32G記憶體的虛擬機器用了160G，剩餘20G記憶體就是賣不出去了。但如果拿這20G記憶體給一堆只用500M到2G的容器行程用，還是整機都跑小容器不跑大虛機，資源利用率一下就高很多了。那閑置的20G記憶體成本早晚也要把攤到客戶身上，但這和客戶直接可視的資源售價沒關係。
這個理由最蠢的地方就是，它把容器雲的客戶限定成了對成本敏感的運維人員，而使用和更新容器、使用容器編排系統，都是要研發人員一起努力才能發掘出來。
很多人都說容器雲是“私有雲誰用誰爽，公有雲誰用誰喪”，其實原因就是：容器雲需要開發人員配合才能用好，而容器編排系統比容器自身更重要。Kubernetes與其說是Docker的競爭者，不如說是容器行業的庇護者。有了Kubernetes這個容器編排系統，雖然Docker技術不那麼醒目了，但其可用性更高更接地氣了。
單純用Dokcer的容器，更像是個封裝的比較徹底，做足了資源隔離的JVM。研發人員只在程式出錯時才會關註Runtime，而運維人員沒感覺到這有什麼酷的，但確實容器雲已經有存在的價值了。比如說OpenStack、PaddlePaddle這類新興軟體和開發框架的部署環境沒那麼簡單，用Docker包一層就變的非常友好了。
對於持續整合和交付場景來說，以前我們是硬壓著研發和測試，務必保持版本一致、務必保證檔案打好包，從不盲信回滾預案，必須後半夜上線，就這樣還天天出故障；現在自動上線的壓力確實小多了，大家都可以放心測試生產環境一致、保證檔案不漏傳、可以和Git無縫整合，可以扔給研發和測試半自助上線了。這就是我前文所說的，容器快速部署的優勢在於決策的快、操作的簡單。
而Kubernetes的興起它把容器從改良工具變成了革新武器。以前有過很多架構師做培訓和檔案，講解服務發現、註冊、編排、路由，資源監控和統計，研發就是說聽不懂。可是一套來自大廠的開源方案出來了，研發就主動去擁抱了。有了Kubernetes以後，即使研發人員做不了架構和運維，只要肯適應Kubernetes的設計邏輯，都可以取代這兩類人的工作。他們透過配合了Kubernetes或類似元件的容器雲，老老實實改變研發流程，讓程式碼和架構，讓架構和資源耦合到一起。
現在我們能說清楚過去為什麼沒有公有容器雲成功案例，因為客戶的執行層是腦臀分離的——運維推動研發把程式改造到可以上容器，以完成運維的業績，貓讓狗幫忙抓條魚給貓吃，這事能搞定才怪。而成功的私有雲案例，其原始推動力都是客戶的技術決策層和架構師，他們不依賴Kubernetes也能搞定架構問題，這不是容器技術和容器廠商的成功，而是客戶技術團隊的成功案例。
現在是個有趣的節點了，Kubernetes在逐漸被大家接受，研發擁抱Kubernetes就可能設計出符合架構美學的服務。相信很快就會出現容器雲的真正成功案例——客戶技術足夠普通但上雲後架構足夠合理。
以前我看到虛擬機器套單容器的事情，因為不信任他們老套的宣傳話述，狠狠的嘲笑了這些容器雲從業者。
但我和一個值得信任的高手聊天時，他反問我，這種架構除了看起來不夠優雅，有沒有什麼邏輯上的致命問題？
如果有一些服務就是要業務行程包在容器裡，但資料檔案就是要落在硬碟上，這時候用容器加雲主機可以說是一種取長補短的嫁接，總好過拿Pod本地儲存做冒險。
我也是因為這次會面而想寫本文，開始更正態度看容器的，有問題的人用過的工具一樣可以是好工具。
想想自己曾經也對雲端計算不屑一顧，人生的迴圈真是有趣。
-
本文中的運維指的是業務服務運維，不是資源支撐運維。
-
很多人會跟我說容器比虛擬機器啟動的快，但容器應該跟虛擬機器裡的行程比重啟速度啊，虛擬機器重啟行程也不用重啟系統啊。
-
我一般說Docker純粹指的是它的容器部分，不包括Swarm等部分。
-
在我看來容器對系統執行環境的封裝就是像個JVM，我知道容器封裝的更多更徹底，但這隻是五十步和一百步的區別。
-
我知道文中沒把Docker和Kubernetes分太清楚，但這是給客戶看的，不是內部考核用的，請大家腦補時往好處想。
本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；微服務架構；微服務的容器化等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
