容器、容器雲和容器化PaaS平臺之間究竟是什麼關係？

一直都有很多人迷惑於容器應該屬於 IaaS 或是 PaaS 層，也搞不清楚容器雲到底是該歸到哪裡，該由哪個團隊來建設、哪個團隊來維護。K8s 是不是就等同於容器雲?所以我們看到概念和定義的混亂，在實施容器雲的時候也會有眾多的分歧，無所適從。目前又有眾多的公司推出容器化 PaaS 的概念，更搞不清楚誰是誰了。那麼容器、容器雲、容器化 PaaS 以及與 Docker 、 Kubernetes 之間是個什麼樣的關係?這是需要我們明確並理解的問題。

容器是一種作業系統級虛擬化技術， Docker 是一種容器引擎。使用 Docker 來執行操作容器。但從容器自身來說，其提供的是 IaaS 層能力。Kubernetes 提供了容器排程和管理的能力，加上雲端計算租戶功能，實現容器雲平臺功能。而基於容器技術所構建的應用開發、應用託管和應用運維平臺則可以稱為容器化 PaaS 平臺，它是一種輕量化 PaaS 實現。結合日誌、監控、認證、許可權等基礎能力則可以構建企業級的平臺和可複用服務，採用微服務架構實現企業技術服務中臺能力，支撐企業業務敏捷研發和模式轉型。

一、 容器

容器是一種輕量虛擬化技術，它不同於 VMware 虛擬化，所以其隔離性相對差、安全性差，但輕量也正是其特點。容器的概念其實也早就有之，只不過實踐的選擇有差別。早在 2006 年的時候，我當時所在的公司就提出了基於 java 的多 jvm Containers 概念並進行了產品實踐，一個 java 容器可以執行多個 jvm ，不過因為 java 自身特性導致的後來轉型並不成功，最後不得不放棄了。應用層容器和作業系統級容器的實現還是有很大差別。作業系統級的容器設計明顯更合理，更易於實現和推廣。透過標準化映象封裝，從而實現了環境一致性。

容器為了彈性伸縮能力傾向於無狀態應用，這樣簡化了容器設計實現的複雜性。所以基於容器自身的特點，容器適用的場景並不是無限的。當然 kubernetes 從 1.9 版本正式支援有狀態應用，增強了容器的場景適應能力，擴充套件了適用場景。

經常有人拿容器和虛擬機器比較，雖然都是虛擬化，但二者差別還是很大的。虛擬機器就好比是一個完整的人，而容器類似於媽媽肚子裡的胎兒。它需要依賴於母體來生存，所以我們可以看到容器在作業系統中以程式的方式執行。容器的虛擬化損耗約 1% ， 而虛擬機器的損耗約 20% 左右。但是容器帶來了管理和運維的複雜性。Docker 提供了 CLI 和 REST API 方式，都需要很高學習成本，在達到一定數量的容器後用 CLI 來管理和運維將會是噩夢，所以有 Docker Swarm 、 Mesos 、 Kubernetes 等容器排程管理框架的出現，提升管理和運維效率，降低運維難度和工作量。

既然容器也是作業系統級的虛擬化，其可以看作類似於虛擬機器的物件，容器本身提供的服務依然是基礎設施資源服務，所以容器應該是處於 IaaS 層。而基於容器技術和容器排程管理技術如 kubernetes 實現的容器雲平臺則封裝了容器操作，提供平臺能力，所以容器雲平臺應該屬於 PaaS 層。這也是很多人直接把容器雲平臺稱為 PaaS 平臺的原因吧。不過確切的說，容器雲平臺並非真的 PaaS 。目前很多容器雲平臺所提供的能力無法滿足應用開發、應用託管、應用運維的 PaaS 平臺能力要求，而通常僅僅實現租戶 + 雲端的容器排程管理能力，依然有大量的 CLI 運維工作。對使用容器雲的人員的學習成本和要求都比較高。

二、 容器雲

Kubernetes 並不等於容器雲， kubernets 只是一種容器排程管理框架，和 docker swarm 、 mesos 等一樣，用於排程、管理容器。比如排程容器到匹配的資源上，管理容器的彈性伸縮、灰度釋出、負載路由等。雲端計算很重要的一個概念是租戶。租戶租用共享的雲端計算資源，按需和用量計費，不用則不產生費用。而 kubernetes 中是沒有租戶的概念的。所以僅有 kubernetes 是不夠的， kubernetes 可以看作是容器雲平臺的核心，我們需要使用 kubernetes 來實現容器雲平臺，但還需要基於 kubernetes 進行封裝，支援租戶共享基礎設施資源等能力。

租戶可以是一個跨平臺的概念。在容器雲平臺建設中，有容器雲平臺的租戶設計是基於 kubernetes 的 namespaces 來劃分的，一個租戶使用一個 namespaces ，這會帶來很大的侷限性。雖然租戶的定義沒有明確標準，但從理論上說租戶是高於 kubernetes 的，所以在 kubernetes 內部沒有租戶的概念，而是用 namespaces 來實現資源隔離。在容器雲平臺實踐中，需要考慮租戶的設計，可能是跨越多個 kubernetes 叢集的，甚至跨越多個 IaaS 平臺用 kubernetes 實現容器排程，也就是可以把容器排程到不同的雲平臺上執行，比如同時可以把容器排程到騰訊雲、華為雲、 AWS 雲等雲平臺上(透過雲管來實現資源的統一管控，支撐容器雲平臺的資源排程)，從而實現高等級備份和容災等。這就需要考慮基於 Kubernetes 多叢集之上的容器雲平臺能力的抽象和設計。

容器適用於輕量、彈性、無狀態等業務場景，這也決定了在傳統行業其應用場景並不廣闊。傳統行業業務追求穩定性，並不需要頻繁的變更和重啟。重啟可能會帶來資料的丟失，也可能造成業務流量處理的波動。另外需要認識到，生產環境和測試環境的要求是不一樣的。測試環境可以敏捷的迭代測試、快速的環境準備、頻繁的部署刪除，但生產環境往往要求持續穩定的執行。所以容器更多的適合測試環境，以更快的構建測試環境，確保迴歸測試環境一致性，更快更頻繁的構建、釋出、部署、測試、反饋，從而提升效率，減少出錯頻率。這也是我們公司各個團隊都樂意轉到容器雲平臺的一個原因。生產環境則要求穩定，應用服務部署之後，不需要頻繁的啟停，也很少頻繁的彈性伸縮，往往需要提前規劃好系統容量需求，確保平穩和穩定。

一種技術解決不了所有問題。容器不是萬能，它有適合的場景。我們不能削足適履，而是要理解容器的特點，選擇合適的業務場景。企業內需要不同技術的組合來滿足企業業務需求，而容器適合支撐輕量、彈性、無狀態業務應用。所以測試環境我儘可以把 kafka 、 Mysql 、 ES 等快速部署起來用於測試，但這些元件在生產環境就需要物理化部署，而不是容器化部署。測試和生產在效能、穩定性、效率等方面的要求是不一樣的，所以不同的場景需要考慮不同的方式。

也有很多人鼓吹容器節省資源，這只是相對的。每個容器都是一個完整的業務應用及依賴包組合，依賴的檔案越多，部署容器越多，重複的資源佔用就越多。浪費就越多，反而比如一臺伺服器上直接起若干服務。而且大量的容器如果排程不合理往往會導致資源爭搶的出現，應用效能不時受到影響。什麼時候容器雲會節省資源?在達到一定量後，中大規模應用之後，可以實現資源的分時段使用，比如白天做業務處理，晚上做資料分析、計算、整合、統計等，相當於使資源分片，但這取決於業務的執行資源和時段要求以及容器量，只有達到一定量之後才能更好的規劃和分時利用資源，從而達到“節省資源”的目的。但這些對容器雲平臺的容器排程能力提出了非常高的要求。

三、 容器化PaaS

容器雲可以看作是容器化 PaaS 的一個雛形，但並不能真正稱為 PaaS 。PaaS 平臺類似於作業系統(雲作業系統)，提供應用開發、託管、運維等能力。特別對傳統行業人員來說，需要具備友好的 UI ，使使用者能夠不需要額外學習就可以方便的使用 PaaS 平臺來完成應用開發、託管和運維需求。

容器雲或容器化 PaaS 平臺屬於基礎平臺，理論上應該由運維團隊來搭建。但採用容器雲之後， PaaS 運維團隊是有別於傳統的運維團隊，而應該是一種開發型運維團隊，重點是運維平臺建設、運維工具開發以及穩態業務應用運維。而運維可以分 2-3 個層次：基礎設施資源運維、平臺和工具運維、業務應用運維。開發團隊則專注於業務應用的開發和迭代，業務團隊則專注於業務的運營和創新。PaaS 平臺則起到一個承上啟下的作用，向下使用基礎設施資源，向上則支撐業務應用的開發、運維和運營等。這有點類似於 Google SRE ，這也是企業數字化轉型 IT 組織轉型的重要方面。

容器化 PaaS 平臺可以更好的利用容器的特點支撐微服務化業務應用。所以我們在建設容器雲平臺時就提出了“以應用管理為核心”，支撐微服務化業務應用，這就需要在容器雲平臺具備服務治理能力。服務治理不是指 SpringCloud ，也不是 dubbo ，微服務開發框架和微服務治理是兩個概念。在容器雲平臺或容器化 PaaS 平臺，可以不用 SpringCloud ，不用 dubbo ，同樣可以開發微服務，反而會簡化微服務的管理和治理。比如說服務註冊，使用 SpringCloud 可以要使用 Eureka ，就需要額外的 Eureka 元件，而容器雲平臺自身是提供服務註冊發現機制的，所以沒必要非要選擇 SpringCloud 等工具。但是這就對容器雲平臺或容器化 PaaS 提出了比較高的要求，要能實現不同型別微服務的管理和治理。

理解了這一點，在設計實現容器化 PaaS 平臺的時候，就不會只考慮 SpringCloud 或 Dubbo ，就可以設計出更通用的 PaaS 平臺。

我們把容器化 PaaS 定義為輕量化 PaaS 。所謂輕量化 PaaS ，就是讓它來支撐微服務架構業務應用，而不去部署如生產資料庫、 Kafka 、 ES 等重型資料庫或中介軟體系統，因為它無論在穩定性、可靠性、效能等方面都不如非容器化部署，運維複雜度高。因此，使用容器雲或容器化 PaaS 來支撐微服務架構業務應用，實現敏捷的業務應用服務開發和迭代，快速構建一致性的開發、測試環境，支援彈性伸縮應對突發流量，擴充套件服務治理增強安全管控，提供統一的日誌、監控、審計等企業級能力中心等，從而就可以基於容器化 PaaS 構建企業的可複用中臺服務，從而滿足企業業務應用的敏捷變化需求和業務模式轉型，促進企業數字化轉型。

也不少人在提敏態和穩態雙態運維，我們覺得核心不是新的運維模式和傳統運維模式並行，而是不同的業務場景需求。任何時候都存在敏態和穩態的需求，如果把資料庫都容器化部署，這不是敏態，而是自找麻煩。我們前面提到， PoC 和測試環境可以這麼幹，但生產環境就是不一樣的場景需求。無論網際網路類業務或者傳統業務，生產環境的穩定性都是首要要求。

容器、容器雲、容器化 PaaS 對使用者有不同的要求。容器雲產品化需要向容器化 PaaS 平臺轉型，並需要考慮不同業務場景的需求，以更好的實現應用開發、託管和運維能力需求。這也是實現 PaaS 平臺的一個相對便捷的途徑。