有關(guān)容器的六大誤區和八大正確場(chǎng)景

做容器的研究和容器化幾年了，從最初對于容器的初步認識，到積攢了大量的容器遷移經(jīng)驗，并和客戶(hù)解釋了容器技術(shù)之后，發(fā)現原來(lái)對于容器的理解有大量的誤解，而且容器并非虛擬機的替代，而是有十分具體的應用場(chǎng)景的。

第一部分：容器的理解誤區

誤區一：容器啟動(dòng)速度快，秒級啟動(dòng)

這是很多人布道容器的時(shí)候經(jīng)常說(shuō)的一句話(huà)，往往人們會(huì )啟動(dòng)一個(gè)nginx之類(lèi)的應用，的確很快就能夠啟動(dòng)起來(lái)了。

容器為啥啟動(dòng)快，一是沒(méi)有內核，二是鏡像比較小。

然而容器是有主進(jìn)程的，也即Entrypoint，只有主進(jìn)程完全啟動(dòng)起來(lái)了，容器才算真正的啟動(dòng)起來(lái)，一個(gè)比喻是容器更像人的衣服，人站起來(lái)了，衣服才站起來(lái)，人躺下了，衣服也躺下了。衣服有一定的隔離性，但是隔離性沒(méi)那么好。衣服沒(méi)有根(內核)，但是衣服可以隨著(zhù)人到處走。

所以按照一個(gè)nginx來(lái)評判一個(gè)容器的啟動(dòng)速度有意義么？對于Java應用，里面安裝的是tomcat，而tomcat的啟動(dòng)，加載war，并且真正的應用啟動(dòng)起來(lái)，如果你盯著(zhù)tomcat的日志看的話(huà)，還是需要一些時(shí)間的，根本不是秒級。如果應用啟動(dòng)起來(lái)要一兩分鐘，僅僅談容器的秒級啟動(dòng)是沒(méi)有意義的。

現在OpenStack中的VM的啟動(dòng)速度也優(yōu)化的越來(lái)越快了，啟動(dòng)一個(gè)VM的時(shí)候，原來(lái)需要從Glance下載虛擬機鏡像，后來(lái)有了一個(gè)技術(shù)，是的Glance和系統盤(pán)共享Ceph存儲的情況下，虛擬機鏡像無(wú)需下載，啟動(dòng)速度就快很多。

而且容器之所以啟動(dòng)速度快，往往建議使用一個(gè)非常小的鏡像，例如alpine，里面很多東西都裁剪掉了，啟動(dòng)的速度就更快了。

OpenStack的虛擬機鏡像也可以經(jīng)過(guò)大量的裁剪，實(shí)現快速的啟動(dòng) 

我們可以精細的衡量虛擬機啟動(dòng)的每一個(gè)步驟，裁剪掉相應的模塊和啟動(dòng)的過(guò)程，大大降低虛擬機的啟動(dòng)時(shí)間。

例如在UnitedStack的一篇博客里面https://www.ustack.com/blog/build-block-storage-service，我們可以看到這樣的實(shí)現和描述

“使用原生的OpenStack創(chuàng )建虛擬機需要1~3分鐘，而使用改造后的OpenStack僅需要不到10秒鐘時(shí)間。這是因為nova-compute不再需要通過(guò)HTTP下載整個(gè)鏡像，虛擬機可以通過(guò)直接讀取Ceph中的鏡像數據進(jìn)行啟動(dòng)?！?/p>

所以對于虛擬機的整體啟動(dòng)時(shí)間，現在優(yōu)化的不錯的情況下，一般能夠做到十幾秒到半分鐘以?xún)?。這個(gè)時(shí)間和Tomcat的啟動(dòng)時(shí)間相比較，其實(shí)不算是負擔，和容器的啟動(dòng)速度相比，沒(méi)有質(zhì)的差別，可能有人會(huì )說(shuō)啟動(dòng)速度快一點(diǎn)也是快，尤其是對于在線(xiàn)環(huán)境的掛掉自修復來(lái)講，不是分秒必爭么？關(guān)于自修復的問(wèn)題，我們下面另外說(shuō)。

然而虛擬機有一個(gè)好處，就是隔離性好，如果容器是衣服，虛擬機就是房子，房子立在那里，里面的人無(wú)論站著(zhù)還是躺著(zhù)，房子總是站著(zhù)的，房子也不會(huì )跟著(zhù)人走。使用虛擬機就像人們住在公寓里面一樣，每人一間，互補干擾，使用容器像大家穿著(zhù)衣服擠在公交車(chē)里面，看似隔離，誰(shuí)把公交弄壞了，誰(shuí)都走不了。

綜上所述，容器的啟動(dòng)速度不足以構成對OpenStack虛擬機的明顯優(yōu)勢，然而虛擬機的隔離性，則秒殺容器。

誤區二：容器輕量級，每個(gè)主機會(huì )運行成百上千個(gè)容器

很多人會(huì )做實(shí)驗，甚至會(huì )跟客戶(hù)說(shuō)，容器平臺多么多么牛，你看我們一臺機器上可以運行成百上千個(gè)容器，虛擬機根本做不到這一點(diǎn)。

但是一個(gè)機器運行成百上千個(gè)容器，有這種真實(shí)的應用場(chǎng)景么？對于容器來(lái)講，重要的是里面的應用，應用的核心在于穩定性和高并發(fā)支撐，而不在于密度。

我在很多演講的會(huì )議上遇到了很多知名的處理雙十一和618的講師，普遍反饋當前的Java應用基本上4核8G是標配，如果遇見(jiàn)容量不足的情況，少部分通過(guò)縱向擴容的方式進(jìn)行，大部分采用橫向擴容的方式進(jìn)行。

如果4核8G是標配，不到20個(gè)服務(wù)就可以占滿(mǎn)一臺物理服務(wù)器，一臺機器跑成百上千個(gè)nginx有意思么？ 這不是一個(gè)嚴肅的使用場(chǎng)景。

當然現在有一個(gè)很火的Serverless無(wú)服務(wù)架構，在無(wú)服務(wù)器架構中，所有自定義代碼作為孤立的、獨立的、常常細粒度的函數來(lái)編寫(xiě)和執行，這些函數在例如AWS Lambda之類(lèi)的無(wú)狀態(tài)計算服務(wù)中運行。這些計算服務(wù)可以是虛擬機，也可以是容器。對于無(wú)狀態(tài)的函數來(lái)講，需要快速的創(chuàng )建可刪除，而且很可能執行一個(gè)函數的時(shí)間本身就非常短，在這種情況下容器相比于虛擬機還是有一定優(yōu)勢的。

目前無(wú)服務(wù)架構比較適用于運行一些任務(wù)型批量操作，利用進(jìn)程級別的橫向彈性能力來(lái)抵消進(jìn)程創(chuàng )建和銷(xiāo)毀帶來(lái)的較大的代價(jià)。

在spark和mesos的集成中，有一個(gè)Fine-Grained模式，同通常大數據的執行的時(shí)候，任務(wù)的執行進(jìn)程早就申請好了資源，等在那里分配資源不同，這種模式是當任務(wù)分配到的時(shí)候才分配資源，好處就是對于資源的彈性申請和釋放的能力，壞處是進(jìn)程的創(chuàng )建和銷(xiāo)毀還是粒度太大，所以這種模式下spark運行的性能會(huì )差一些。

spark的這種做法思想類(lèi)似無(wú)服務(wù)架構，你會(huì )發(fā)現我們原來(lái)學(xué)操作系統的時(shí)候，說(shuō)進(jìn)程粒度太大，每次都創(chuàng )建和銷(xiāo)毀進(jìn)程會(huì )速度太慢，為了高并發(fā)，后來(lái)有了線(xiàn)程，線(xiàn)程的創(chuàng )建和銷(xiāo)毀輕量級的多，當然還是覺(jué)得慢，于是有了線(xiàn)程池，事先創(chuàng )建在了那里，用的時(shí)候不用現創(chuàng )建，不用的時(shí)候交回去就行，后來(lái)還是覺(jué)得慢，因為線(xiàn)程的創(chuàng )建也需要在內核中完成，所以后來(lái)有了協(xié)程，全部在用戶(hù)態(tài)進(jìn)行線(xiàn)程切換，例如AKKA，Go都使用了協(xié)程，你會(huì )發(fā)現趨勢是為了高并發(fā)，粒度是越來(lái)越細的，現在很多情況又需要進(jìn)程級別的，有種風(fēng)水輪流轉的感覺(jué)。

誤區三：容器有鏡像，可以保持版本號，可以升級和回滾

容器有兩個(gè)特性，一個(gè)是封裝，一個(gè)是標準。有了容器鏡像，就可以將應用的各種配置，文件路徑，權限封裝起來(lái)，然后像孫悟空說(shuō)“定”,就定在了封裝好的那一刻。鏡像是標準的，無(wú)論在哪個(gè)容器運行環(huán)境，將同樣的鏡像運行起來(lái)，都能還原當時(shí)的那一刻。

容器的鏡像還有版本號，我們可以根據容器的版本號進(jìn)行升級，一旦升級有錯，可以根據版本號進(jìn)行回滾，回滾完畢則能夠保證容器內部還是原來(lái)的狀態(tài)。

 

但是OpenStack虛擬機也是有鏡像的，虛擬機鏡像也是可以打snapshot的，打snapshot的時(shí)候，也會(huì )保存當時(shí)的那一刻所有的狀態(tài)，而且snapshot也可以有版本號，也可以升級和回滾。

似乎容器有的這些特性OpenStack虛擬機都有，二者有什么不同呢？

虛擬機鏡像大，而容器鏡像小。虛擬機鏡像動(dòng)不動(dòng)就幾十個(gè)G甚至上百G，而容器鏡像多幾百M。

虛擬機鏡像不適合跨環(huán)境遷移。例如開(kāi)發(fā)環(huán)境在本地，測試環(huán)境在一個(gè)OpenStack上，開(kāi)發(fā)環(huán)境在另一個(gè)OpenStack上，虛擬機的鏡像的遷移非常困難，需要拷貝非常大的文件。而容器就好的多，因為鏡像小，可以很快的從不同的環(huán)境之間遷移。

虛擬機鏡像不適合跨云遷移。當前沒(méi)有一個(gè)公有云平臺支持虛擬機鏡像的下載和上傳(安全的原因，盜版的原因)，因而一個(gè)鏡像在不同的云之間，或者同一個(gè)云不同的region直接，無(wú)法進(jìn)行遷移，只能重新做一個(gè)鏡像，這樣環(huán)境的一致性就得不到保障。而容器的鏡像中心是獨立于云之外的，只要能夠連上鏡像中心，到哪個(gè)云上都可以下載，并且因為鏡像小，下載速度快，并且鏡像是分層的，每次只需要下載差異的部分。

OpenStack對于鏡像方面的優(yōu)化，基本上還是在一個(gè)云里面起作用，一旦跨多個(gè)環(huán)境，鏡像方便的多。

誤區四：容器可以使用容器平臺管理自動(dòng)重啟實(shí)現自修復

容器的自修復功能是經(jīng)常被吹噓的。因為容器是衣服，人躺下了，衣服也躺下了，容器平臺能夠馬上發(fā)現人躺下了，于是可以迅速將人重新喚醒工作。而虛擬機是房子，人躺下了，房子還站著(zhù)，因而虛擬機管理平臺不知道里面的人能不能工作，所以容器掛了會(huì )被自動(dòng)重啟，而虛擬機里面的應用掛了，只要虛擬機不掛，很可能沒(méi)人知道。

這些說(shuō)法都沒(méi)錯，但是人們慢慢發(fā)現了另外的場(chǎng)景，就是容器里面的應用沒(méi)有掛，所以容器看起來(lái)還啟動(dòng)著(zhù)，但是應用以及不工作沒(méi)有反應了。當啟動(dòng)容器的時(shí)候，雖然容器的狀態(tài)起來(lái)了，但是里面的應用還需要一段時(shí)間才能提供服務(wù)。所以針對這種場(chǎng)景，容器平臺會(huì )提供對于容器里面應用的health check，不光看容器在不在，還要看里面的應用能不能用，如果不能，可自動(dòng)重啟。

一旦引入了health check，和虛擬機的差別也不大了，因為有了health check，虛擬機也能看里面的應用是否工作了，不工作也可以重啟應用。

還要就是容器的啟動(dòng)速度快，秒級啟動(dòng)，如果能夠自動(dòng)重啟修復，那就是秒級修復，所以應用更加高可用。

這個(gè)觀(guān)點(diǎn)當然不正確，應用的高可用性和重啟的速度沒(méi)有直接關(guān)系。高可用性一定要通過(guò)多個(gè)副本來(lái)實(shí)現，在任何一個(gè)掛掉之后，不能通過(guò)這一個(gè)應用快速重啟來(lái)解決，而是應該靠掛掉的期間，其他的副本馬上把任務(wù)接過(guò)來(lái)進(jìn)行解決。虛擬機和容器都可以有多副本，在有多個(gè)副本的情況下，重啟是一秒還是20秒，就沒(méi)那么重要了，重要的是掛掉的這段時(shí)間內，程序做了什么，如果程序做的是無(wú)關(guān)緊要的操作，那么掛了20秒，也沒(méi)啥關(guān)系，如果程序正在進(jìn)行一個(gè)交易和支付，那掛掉一秒也不行，也必須能夠修復回來(lái)。所以應用的高可用性要靠應用層的重試，冪等去解決，而不應該靠基礎設施層重啟的快不快來(lái)解決。

對于無(wú)狀態(tài)服務(wù)，在做好重試的機制的情況下，通過(guò)自動(dòng)重啟修復是沒(méi)有問(wèn)題的，因為無(wú)狀態(tài)的服務(wù)不會(huì )保存非常重要的操作。

對于有狀態(tài)服務(wù)，容器的重啟不但不是推薦的，而且可能是災難的開(kāi)始。一個(gè)服務(wù)有狀態(tài)，例如數據庫，在高并發(fā)場(chǎng)景下，一旦掛了，哪怕只有一秒，我們必須要弄清楚這一秒都發(fā)生了什么，哪些數據保存了，哪些數據丟了，而不能盲目的重啟，否則會(huì )很可能造成數據的不一致性，后期修都沒(méi)法修。例如高頻交易下的數據庫掛了，按說(shuō)DBA應該嚴格審核丟了哪些數據，而不是在DBA不知情的情況下，盲目的重啟了，DBA還覺(jué)得沒(méi)什么事情發(fā)生，最終很久才能發(fā)現問(wèn)題。

所以容器比較適合部署無(wú)狀態(tài)服務(wù)的，隨便重啟都可以。

而容器部署有狀態(tài)容器不是不能，而是要非常小心，甚至都是不推薦的。雖然很多的容器平臺都支持有狀態(tài)容器，然而平臺往往解決不了數據問(wèn)題，除非你對容器里面的應用非常非常非常熟悉，當容器掛了，你能夠準確的知道丟了哪些，哪些要緊，哪些不要緊，而且要寫(xiě)代碼處理這些情況，然后才能支持重啟。網(wǎng)易這面的數據庫主備同步的情況下，是通過(guò)修改mysql源代碼，保證主備之間數據完全同步，才敢在主掛了的情況下，備自動(dòng)切換主。

而宣傳有狀態(tài)容器的自動(dòng)重啟，對于服務(wù)客戶(hù)來(lái)講是很不經(jīng)濟的行為，因為客戶(hù)往往沒(méi)有那么清楚應用的邏輯，甚至應用都是買(mǎi)的，如果使用有狀態(tài)容器，任憑自動(dòng)重啟，最終客戶(hù)發(fā)現數據丟失的時(shí)候，還是會(huì )怪到你的頭上。

所以有狀態(tài)的服務(wù)自動(dòng)重啟不是不可用，需要足夠專(zhuān)業(yè)才行。

誤區五：容器可以使用容器平臺進(jìn)行服務(wù)發(fā)現

容器平臺swarm, kubernetes，mesos都是支持服務(wù)發(fā)現的，當一個(gè)服務(wù)訪(fǎng)問(wèn)另一個(gè)服務(wù)，都會(huì )有服務(wù)名轉化為VIP，然后訪(fǎng)問(wèn)具體的容器。

然而人們會(huì )發(fā)現，基于Java寫(xiě)的應用，服務(wù)之間的調用多不會(huì )用容器平臺的服務(wù)發(fā)現，而是用Dubbo或者spring cloud的服務(wù)發(fā)現。因為容器平臺層的服務(wù)發(fā)現，還是做的比較基礎，基本是一個(gè)域名映射的過(guò)程，對于熔斷，限流，降級都沒(méi)有很好的支持，然而既然使用服務(wù)發(fā)現，還是希望服務(wù)發(fā)現中間件能夠做到這一點(diǎn)，因而服務(wù)之間的服務(wù)發(fā)現之間使用容器平臺的少，越是需要高并發(fā)的應用，越是如此。

那容器平臺的服務(wù)發(fā)現沒(méi)有用了么？不是，慢慢你會(huì )發(fā)現，內部的服務(wù)發(fā)現是一方面，這些Dubbo和spring cloud能夠搞定，而外部的服務(wù)發(fā)現就不同了，比如訪(fǎng)問(wèn)數據庫，緩存等，到底是應該配置一個(gè)數據庫服務(wù)的名稱(chēng)，還是IP地址呢？如果使用IP地址，會(huì )造成配置十分復雜，因為很多應用配置之所以復雜，就是依賴(lài)了太多的外部應用，也是最難管理的一方面。如果有了外部的服務(wù)發(fā)現，配置就會(huì )簡(jiǎn)單很多，也只需要配置外部服務(wù)的名稱(chēng)就可以了，如果外部服務(wù)地址變了，可以很靈活的改變外部的服務(wù)發(fā)現。

誤區六：容器可以基于鏡像進(jìn)行彈性伸縮

在容器平臺上，容器有副本數的，只要將副本數從5改到10，容器就基于鏡像進(jìn)行了彈性伸縮。其實(shí)這一點(diǎn)虛擬機也能做到，AWS的Autoscaling就是基于虛擬機鏡像的，如果在同一個(gè)云里面，就沒(méi)有區別。

當然如果跨云無(wú)狀態(tài)容器的彈性伸縮，容器方便很多，可以實(shí)現混合云模式，當高并發(fā)場(chǎng)景下，將無(wú)狀態(tài)容器擴容到公有云，這一點(diǎn)虛擬機是做不到的。

容器理解誤區總結

如圖，左面是經(jīng)常掛在嘴邊的所謂容器的優(yōu)勢，但是虛擬機都能一一懟回去。

如果部署的是一個(gè)傳統的應用，這個(gè)應用啟動(dòng)速度慢，進(jìn)程數量少，基本不更新，那么虛擬機完全能夠滿(mǎn)足需求。

應用啟動(dòng)慢：應用啟動(dòng)15分鐘，容器本身秒級，虛擬機很多平臺能優(yōu)化到十幾秒，兩者幾乎看不出差別

內存占用大：動(dòng)不動(dòng)32G，64G內存，一臺機器跑不了幾個(gè)。

基本不更新：半年更新一次，虛擬機鏡像照樣能夠升級和回滾

應用有狀態(tài)：停機會(huì )丟數據，如果不知道丟了啥，就算秒級啟動(dòng)有啥用，照樣恢復不了，而且還有可能因為丟數據，在沒(méi)有修復的情況下，盲目重啟帶來(lái)數據混亂。

進(jìn)程數量少：兩三個(gè)進(jìn)程相互配置一下，不用服務(wù)發(fā)現，配置不麻煩

如果是一個(gè)傳統應用，根本沒(méi)有必要花費精去容器化，因為白花了力氣，享受不到好處。

第二部分：容器化，微服務(wù)，DevOps三位一體

什么情況下，才應該考慮做一些改變呢？

傳統業(yè)務(wù)突然被互聯(lián)網(wǎng)業(yè)務(wù)沖擊了，應用老是變，三天兩頭要更新，而且流量增大了，原來(lái)支付系統是取錢(qián)刷卡的，現在要互聯(lián)網(wǎng)支付了，流量擴大了N倍。

沒(méi)辦法，一個(gè)字：拆

拆開(kāi)了，每個(gè)子模塊獨自變化，少相互影響。

拆開(kāi)了，原來(lái)一個(gè)進(jìn)程扛流量，現在多個(gè)進(jìn)程一起扛。

所以稱(chēng)為微服務(wù)。

微服務(wù)場(chǎng)景下，進(jìn)程多，更新快，于是出現100個(gè)進(jìn)程，每天一個(gè)鏡像。

容器樂(lè )了，每個(gè)容器鏡像小，沒(méi)啥問(wèn)題，虛擬機哭了，因為虛擬機每個(gè)鏡像太大了。

所以微服務(wù)場(chǎng)景下，可以開(kāi)始考慮用容器了。

虛擬機怒了，老子不用容器了，微服務(wù)拆分之后，用Ansible自動(dòng)部署是一樣的。

這樣說(shuō)從技術(shù)角度來(lái)講沒(méi)有任何問(wèn)題。

然而問(wèn)題是從組織角度出現的。

一般的公司，開(kāi)發(fā)會(huì )比運維多的多，開(kāi)發(fā)寫(xiě)完代碼就不用管了，環(huán)境的部署完全是運維負責，運維為了自動(dòng)化，寫(xiě)Ansible腳本來(lái)解決問(wèn)題。

然而這么多進(jìn)程，又拆又合并的，更新這么快，配置總是變，Ansible腳本也要常改，每天都上線(xiàn)，不得累死運維。

所以這如此大的工作量情況下，運維很容易出錯，哪怕通過(guò)自動(dòng)化腳本。

這個(gè)時(shí)候，容器就可以作為一個(gè)非常好的工具運用起來(lái)。

除了容器從技術(shù)角度，能夠使得大部分的內部配置可以放在鏡像里面之外，更重要的是從流程角度，將環(huán)境配置這件事情，往前推了，推到了開(kāi)發(fā)這里，要求開(kāi)發(fā)完畢之后，就需要考慮環(huán)境部署的問(wèn)題，而不能當甩手掌柜。

這樣做的好處就是，雖然進(jìn)程多，配置變化多，更新頻繁，但是對于某個(gè)模塊的開(kāi)發(fā)團隊來(lái)講，這個(gè)量是很小的，因為5-10個(gè)人專(zhuān)門(mén)維護這個(gè)模塊的配置和更新，不容易出錯。

如果這些工作量全交給少數的運維團隊，不但信息傳遞會(huì )使得環(huán)境配置不一致，部署量會(huì )大非常多。

容器是一個(gè)非常好的工具，就是讓每個(gè)開(kāi)發(fā)僅僅多做5%的工作，就能夠節約運維200%的工作，并且不容易出錯。

然而本來(lái)原來(lái)運維該做的事情開(kāi)發(fā)做了，開(kāi)發(fā)的老大愿意么？開(kāi)發(fā)的老大會(huì )投訴運維的老大么？

這就不是技術(shù)問(wèn)題了，其實(shí)這就是DevOps，DevOps不是不區分開(kāi)發(fā)和運維，而是公司從組織到流程，能夠打通，看如何合作，邊界如何劃分，對系統的穩定性更有好處。

所以微服務(wù)，DevOps，容器是相輔相成，不可分割的。

不是微服務(wù)，根本不需要容器，虛擬機就能搞定，不需要DevOps，一年部署一次，開(kāi)發(fā)和運維溝通再慢都能搞定。

所以，容器的本質(zhì)是基于鏡像的跨環(huán)境遷移。

鏡像是容器的根本性發(fā)明，是封裝和運行的標準，其他什么namespace，cgroup，早就有了。這是技術(shù)方面。

在流程方面，鏡像是DevOps的良好工具。

容器是為了跨環(huán)境遷移的，第一種遷移的場(chǎng)景是開(kāi)發(fā)，測試，生產(chǎn)環(huán)境之間的遷移。如果不需要遷移，或者遷移不頻繁，虛擬機鏡像也行，但是總是要遷移，帶著(zhù)幾百G的虛擬機鏡像，太大了。

第二種遷移的場(chǎng)景是跨云遷移，跨公有云，跨Region，跨兩個(gè)OpenStack的虛擬機遷移都是非常麻煩，甚至不可能的，因為公有云不提供虛擬機鏡像的下載和上傳功能，而且虛擬機鏡像太大了，一傳傳一天。

所以跨云場(chǎng)景下，混合云場(chǎng)景下，容器也是很好的使用場(chǎng)景。這也同時(shí)解決了僅僅私有云資源不足，扛不住流量的問(wèn)題。

第三部分：容器的正確使用場(chǎng)景

根據以上的分析，我們發(fā)現容器推薦使用在下面的場(chǎng)景下。

1. 部署無(wú)狀態(tài)服務(wù)，同虛擬機互補使用，實(shí)現隔離性

2. 如果要部署有狀態(tài)服務(wù)，需要對里面的應用十分的了解

3. 作為持續集成的重要工具，可以順利在開(kāi)發(fā)，測試，生產(chǎn)之間遷移

4. 適合部署跨云，跨Region，跨數據中心，混合云場(chǎng)景下的應用部署和彈性伸縮

5. 以容器作為應用的交付物，保持環(huán)境一致性，樹(shù)立不可變更基礎設施的理念

6. 運行進(jìn)程基本的任務(wù)類(lèi)型的程序

7. 用于管理變更，變更頻繁的應用使用容器鏡像和版本號，輕量級方便的多

8. 使用容器一定要管理好應用，進(jìn)行health check和容錯的設計