一直都有很多人迷惑于容器應該屬于IaaS或是PaaS層，也搞不清楚容器云到底是該歸到哪里，該由哪個團隊來建設、哪個團隊來維護。K8s是不是就等同于容器云？所以我們看到概念和定義的混亂，在實施容器云的時候也會有眾多的分歧，無所適從。目前又有眾多的公司推出容器化PaaS的概念，更搞不清楚誰是誰了。那么容器、容器云、容器化PaaS以及與Docker、Kubernetes之間是個什么樣的關系？這是需要我們明確并理解的問題。
容器是一種操作系統(tǒng)級虛擬化技術，Docker是一種容器引擎。使用Docker來運行操作容器。但從容器自身來說，其提供的是IaaS層能力。Kubernetes提供了容器調(diào)度和管理的能力，加上云計算租戶功能，實現(xiàn)容器云平臺功能。而基于容器技術所構建的應用開發(fā)、應用托管和應用運維平臺則可以稱為容器化PaaS平臺，它是一種輕量化PaaS實現(xiàn)。結合日志、監(jiān)控、認證、權限等基礎能力則可以構建企業(yè)級的平臺和可復用服務，采用微服務架構實現(xiàn)企業(yè)技術服務中臺能力，支撐企業(yè)業(yè)務敏捷研發(fā)和模式轉型。
一、容器
容器是一種輕量虛擬化技術，它不同于VMware虛擬化，所以其隔離性相對差、安全性差，但輕量也正是其特點。容器的概念其實也早就有之，只不過實踐的選擇有差別。早在2006年的時候，我當時所在的公司就提出了基于java的多jvm Containers概念并進行了產(chǎn)品實踐，一個java容器可以運行多個jvm，不過因為java自身特性導致的后來轉型并不成功，最后不得不放棄了。應用層容器和操作系統(tǒng)級容器的實現(xiàn)還是有很大差別。操作系統(tǒng)級的容器設計明顯更合理，更易于實現(xiàn)和推廣。通過標準化鏡像封裝，從而實現(xiàn)了環(huán)境一致性。
容器為了彈性伸縮能力傾向于無狀態(tài)應用，這樣簡化了容器設計實現(xiàn)的復雜性。所以基于容器自身的特點，容器適用的場景并不是無限的。當然kubernetes從1.9版本正式支持有狀態(tài)應用，增強了容器的場景適應能力，擴展了適用場景。
經(jīng)常有人拿容器和虛擬機比較，雖然都是虛擬化，但二者差別還是很大的。虛擬機就好比是一個完整的人，而容器類似于媽媽肚子里的胎兒。它需要依賴于母體來生存，所以我們可以看到容器在操作系統(tǒng)中以進程的方式運行。容器的虛擬化損耗約1%，而虛擬機的損耗約20%左右。但是容器帶來了管理和運維的復雜性。Docker提供了CLI和REST API方式，都需要很高學習成本，在達到一定數(shù)量的容器后用CLI來管理和運維將會是噩夢，所以有Docker Swarm、Mesos、Kubernetes等容器調(diào)度管理框架的出現(xiàn)，提升管理和運維效率，降低運維難度和工作量。
既然容器也是操作系統(tǒng)級的虛擬化，其可以看作類似于虛擬機的對象，容器本身提供的服務依然是基礎設施資源服務，所以容器應該是處于IaaS層。而基于容器技術和容器調(diào)度管理技術如kubernetes實現(xiàn)的容器云平臺則封裝了容器操作，提供平臺能力，所以容器云平臺應該屬于PaaS層。這也是很多人直接把容器云平臺稱為PaaS平臺的原因吧。不過確切的說，容器云平臺并非真的PaaS。目前很多容器云平臺所提供的能力無法滿足應用開發(fā)、應用托管、應用運維的PaaS平臺能力要求，而通常僅僅實現(xiàn)租戶+云端的容器調(diào)度管理能力，依然有大量的CLI運維工作。對使用容器云的人員的學習成本和要求都比較高。
二、容器云
Kubernetes并不等于容器云，kubernets只是一種容器調(diào)度管理框架，和docker swarm、mesos等一樣，用于調(diào)度、管理容器。比如調(diào)度容器到匹配的資源上，管理容器的彈性伸縮、灰度發(fā)布、負載路由等。云計算很重要的一個概念是租戶。租戶租用共享的云計算資源，按需和用量計費，不用則不產(chǎn)生費用。而kubernetes中是沒有租戶的概念的。所以僅有kubernetes是不夠的，kubernetes可以看作是容器云平臺的內(nèi)核，我們需要使用kubernetes來實現(xiàn)容器云平臺，但還需要基于kubernetes進行封裝，支持租戶共享基礎設施資源等能力。
租戶可以是一個跨平臺的概念。在容器云平臺建設中，有容器云平臺的租戶設計是基于kubernetes的namespaces來劃分的，一個租戶使用一個namespaces，這會帶來很大的局限性。雖然租戶的定義沒有明確標準，但從理論上說租戶是高于kubernetes的，所以在kubernetes內(nèi)部沒有租戶的概念，而是用namespaces來實現(xiàn)資源隔離。在容器云平臺實踐中，需要考慮租戶的設計，可能是跨越多個kubernetes集群的，甚至跨越多個IaaS平臺用kubernetes實現(xiàn)容器調(diào)度，也就是可以把容器調(diào)度到不同的云平臺上運行，比如同時可以把容器調(diào)度到騰訊云、華為云、AWS云等云平臺上（通過云管來實現(xiàn)資源的統(tǒng)一管控，支撐容器云平臺的資源調(diào)度），從而實現(xiàn)高等級備份和容災等。這就需要考慮基于Kubernetes多集群之上的容器云平臺能力的抽象和設計。
容器適用于輕量、彈性、無狀態(tài)等業(yè)務場景，這也決定了在傳統(tǒng)行業(yè)其應用場景并不廣闊。傳統(tǒng)行業(yè)業(yè)務追求穩(wěn)定性，并不需要頻繁的變更和重啟。重啟可能會帶來數(shù)據(jù)的丟失，也可能造成業(yè)務流量處理的波動。另外需要認識到，生產(chǎn)環(huán)境和測試環(huán)境的要求是不一樣的。測試環(huán)境可以敏捷的迭代測試、快速的環(huán)境準備、頻繁的部署刪除，但生產(chǎn)環(huán)境往往要求持續(xù)穩(wěn)定的運行。所以容器更多的適合測試環(huán)境，以更快的構建測試環(huán)境，確?；貧w測試環(huán)境一致性，更快更頻繁的構建、發(fā)布、部署、測試、反饋，從而提升效率，減少出錯頻率。這也是我們公司各個團隊都樂意轉到容器云平臺的一個原因。生產(chǎn)環(huán)境則要求穩(wěn)定，應用服務部署之后，不需要頻繁的啟停，也很少頻繁的彈性伸縮，往往需要提前規(guī)劃好系統(tǒng)容量需求，確保平穩(wěn)和穩(wěn)定。
一種技術解決不了所有問題。容器不是萬能，它有適合的場景。我們不能削足適履，而是要理解容器的特點，選擇合適的業(yè)務場景。企業(yè)內(nèi)需要不同技術的組合來滿足企業(yè)業(yè)務需求，而容器適合支撐輕量、彈性、無狀態(tài)業(yè)務應用。所以測試環(huán)境我盡可以把kafka、Mysql、ES等快速部署起來用于測試，但這些組件在生產(chǎn)環(huán)境就需要物理化部署，而不是容器化部署。測試和生產(chǎn)在性能、穩(wěn)定性、效率等方面的要求是不一樣的，所以不同的場景需要考慮不同的方式。
也有很多人鼓吹容器節(jié)省資源，這只是相對的。每個容器都是一個完整的業(yè)務應用及依賴包組合，依賴的文件越多，部署容器越多，重復的資源占用就越多。浪費就越多，反而比如一臺服務器上直接起若干服務。而且大量的容器如果調(diào)度不合理往往會導致資源爭搶的出現(xiàn)，應用性能不時受到影響。什么時候容器云會節(jié)省資源？在達到一定量后，中大規(guī)模應用之后，可以實現(xiàn)資源的分時段使用，比如白天做業(yè)務處理，晚上做數(shù)據(jù)分析、計算、整合、統(tǒng)計等，相當于使資源分片，但這取決于業(yè)務的運行資源和時段要求以及容器量，只有達到一定量之后才能更好的規(guī)劃和分時利用資源，從而達到“節(jié)省資源”的目的。但這些對容器云平臺的容器調(diào)度能力提出了非常高的要求。
三、容器化PaaS
容器云可以看作是容器化PaaS的一個雛形，但并不能真正稱為PaaS。PaaS平臺類似于操作系統(tǒng)（云操作系統(tǒng)），提供應用開發(fā)、托管、運維等能力。特別對傳統(tǒng)行業(yè)人員來說，需要具備友好的UI，使用戶能夠不需要額外學習就可以方便的使用PaaS平臺來完成應用開發(fā)、托管和運維需求。
容器云或容器化PaaS平臺屬于基礎平臺，理論上應該由運維團隊來搭建。但采用容器云之后，PaaS運維團隊是有別于傳統(tǒng)的運維團隊，而應該是一種開發(fā)型運維團隊，重點是運維平臺建設、運維工具開發(fā)以及穩(wěn)態(tài)業(yè)務應用運維。而運維可以分2-3個層次：基礎設施資源運維、平臺和工具運維、業(yè)務應用運維。開發(fā)團隊則專注于業(yè)務應用的開發(fā)和迭代，業(yè)務團隊則專注于業(yè)務的運營和創(chuàng)新。PaaS平臺則起到一個承上啟下的作用，向下使用基礎設施資源，向上則支撐業(yè)務應用的開發(fā)、運維和運營等。這有點類似于Google SRE，這也是企業(yè)數(shù)字化轉型IT組織轉型的重要方面。
容器化PaaS平臺可以更好的利用容器的特點支撐微服務化業(yè)務應用。所以我們在建設容器云平臺時就提出了“以應用管理為核心”，支撐微服務化業(yè)務應用，這就需要在容器云平臺具備服務治理能力。服務治理不是指SpringCloud，也不是dubbo，微服務開發(fā)框架和微服務治理是兩個概念。在容器云平臺或容器化PaaS平臺，可以不用SpringCloud，不用dubbo，同樣可以開發(fā)微服務，反而會簡化微服務的管理和治理。比如說服務注冊，使用SpringCloud可以要使用Eureka，就需要額外的Eureka組件，而容器云平臺自身是提供服務注冊發(fā)現(xiàn)機制的，所以沒必要非要選擇SpringCloud等工具。但是這就對容器云平臺或容器化PaaS提出了比較高的要求，要能實現(xiàn)不同類型微服務的管理和治理。
理解了這一點，在設計實現(xiàn)容器化PaaS平臺的時候，就不會只考慮SpringCloud或Dubbo，就可以設計出更通用的PaaS平臺。
我們把容器化PaaS定義為輕量化PaaS。所謂輕量化PaaS，就是讓它來支撐微服務架構業(yè)務應用，而不去部署如生產(chǎn)數(shù)據(jù)庫、Kafka、ES等重型數(shù)據(jù)庫或中間件系統(tǒng)，因為它無論在穩(wěn)定性、可靠性、性能等方面都不如非容器化部署，運維復雜度高。因此，使用容器云或容器化PaaS來支撐微服務架構業(yè)務應用，實現(xiàn)敏捷的業(yè)務應用服務開發(fā)和迭代，快速構建一致性的開發(fā)、測試環(huán)境，支持彈性伸縮應對突發(fā)流量，擴展服務治理增強安全管控，提供統(tǒng)一的日志、監(jiān)控、審計等企業(yè)級能力中心等，從而就可以基于容器化PaaS構建企業(yè)的可復用中臺服務，從而滿足企業(yè)業(yè)務應用的敏捷變化需求和業(yè)務模式轉型，促進企業(yè)數(shù)字化轉型。
也不少人在提敏態(tài)和穩(wěn)態(tài)雙態(tài)運維，我們覺得核心不是新的運維模式和傳統(tǒng)運維模式并行，而是不同的業(yè)務場景需求。任何時候都存在敏態(tài)和穩(wěn)態(tài)的需求，如果把數(shù)據(jù)庫都容器化部署，這不是敏態(tài)，而是自找麻煩。我們前面提到，PoC和測試環(huán)境可以這么干，但生產(chǎn)環(huán)境就是不一樣的場景需求。無論互聯(lián)網(wǎng)類業(yè)務或者傳統(tǒng)業(yè)務，生產(chǎn)環(huán)境的穩(wěn)定性都是首要要求。
容器、容器云、容器化PaaS對使用者有不同的要求。容器云產(chǎn)品化需要向容器化PaaS平臺轉型，并需要考慮不同業(yè)務場景的需求，以更好的實現(xiàn)應用開發(fā)、托管和運維能力需求。這也是實現(xiàn)PaaS平臺的一個相對便捷的途徑。
