本文介紹了容器的現(xiàn)狀和發(fā)展趨勢，容器集群編排引擎選型，跨主機(jī)網(wǎng)絡(luò)通信，定制化方案，公有云，私有云及混合云的場景及實(shí)現(xiàn)等內(nèi)容，說明如何打造簡單而強(qiáng)大的容器云平臺。

1. 容器技術(shù)現(xiàn)狀及發(fā)展趨勢

　　什么是容器？
　　我們可以將容器理解為一種沙盒，每個容器具有獨(dú)立的操作系統(tǒng)資源，不同的容器之間相互隔離，也可以建立通信，應(yīng)用跑在各自的容器中，避免了環(huán)境中有沖突的資源使用，做到一次封裝，到處運(yùn)行。

　　那容器與虛擬機(jī)的區(qū)別在哪？
　　容器可以看做輕量的虛擬機(jī)，虛機(jī)啟動可能需要數(shù)分鐘或者更長，而容器只需幾十毫秒。傳統(tǒng)虛擬技術(shù)是在硬件層面實(shí)現(xiàn)虛擬化，有性能損耗，而容器技術(shù)是以共享內(nèi)核的方式實(shí)現(xiàn)，幾乎無損耗。虛擬機(jī)更擅長于徹底隔離整個運(yùn)行環(huán)境。例如，云服務(wù)提供商通常采用虛擬機(jī)技術(shù)隔離不同的用戶。而Docker通常用于隔離不同的應(yīng)用，例如前端，后端以及數(shù)據(jù)庫。
　　以Docker為代表的容器技術(shù)的出現(xiàn)，給云計算提供了全新的視角，使創(chuàng)建和部署應(yīng)用如堆積木一樣簡單，我們在創(chuàng)建應(yīng)用或服務(wù)時，不用考慮資源和維護(hù)成本，使得應(yīng)用的部署極為簡單快捷，失敗的成本大大降低，讓我們的注意力更多的聚焦在應(yīng)用和服務(wù)本身，而不是繁瑣的系統(tǒng)和環(huán)境配置中。
　　幾年來，容器技術(shù)的發(fā)展也十分迅猛，從管理單一容器應(yīng)用到管理多容器，多主機(jī)的分布式應(yīng)用。企業(yè)也紛紛面臨著由傳統(tǒng)應(yīng)用向云端分布式應(yīng)用的轉(zhuǎn)變，使用容器技術(shù)將應(yīng)用轉(zhuǎn)型為微服務(wù)。
　　隨著容器采用率越來越快，容器的生態(tài)環(huán)境也需要快速迭代。需要有一個平臺可以對容器集群進(jìn)行高效靈活的管理，方便的搞定容器編排和容器部署，容器云平臺應(yīng)運(yùn)而生。容器云平臺應(yīng)具備哪些能力，如何打造一個安全，穩(wěn)定，高效的容器云平臺，我們從下面幾方面來談一談。

2. 容器集群編排引擎選型

　　容器編排是容器云平臺的核心部分和基礎(chǔ)能力，為實(shí)現(xiàn)大規(guī)模的容器化部署提供一個抽象層的處理。典型的容器編排引擎需要實(shí)現(xiàn)以下幾個功能：集群（跨主機(jī)提供計算能力），調(diào)度（決定容器部署在哪個節(jié)點(diǎn)），可伸縮（支持應(yīng)用實(shí)例的自動或手動擴(kuò)容縮容），容錯（應(yīng)用或主機(jī)故障的情況下自動重啟容器），隔離（保障容器安全）。
　　Docker Native（swarm）
　　Docker自帶原生編排工具，添加已經(jīng)在多節(jié)點(diǎn)運(yùn)行的Docker到Swarm中，Swarm的設(shè)置是很簡單的：你只需在其中一個節(jié)點(diǎn)上調(diào)用docker swarm init，然后在任何其他你想添加的節(jié)點(diǎn)上調(diào)用docker swarm join即可。使用與Docker Engine和Docker Compose相同的語法提供編排支持。
　　swarm會自動地做一些如負(fù)載均衡，保持容器副本數(shù)量等工作，所以swarm對外提供的和k8s類似也是屬于一個“服務(wù)”的概念。
　　docker service create \
　　-name helloworld \
　　-replicas 5 \
　　-network my-network \
　　--constraint engine.labels.cloud==aliyun \
　　--constraint node.role==manager \
　　-p 80：80/tcp nginx：latest.
　　Swarm也可以使用約束和標(biāo)簽來做一些非?；镜娜萜髡{(diào)度。使用約束可以向服務(wù)添加關(guān)聯(lián)，并且它將嘗試僅啟動具有特殊標(biāo)簽的容器。
　　Kubenetes

　　kubelet將控制給定節(jié)點(diǎn)上的容器或pod與主控制節(jié)點(diǎn)的連接。kubeproxy用于為Kubernetes中定義的服務(wù)提供負(fù)載平衡和高可用性。
　　Kubernetes使用Pods的概念作為基本單位，而不是單個容器。每個pod是一組容器（集合大小可以是一個）。
　　kubernetes把集群帶到了一個全新的高度，代價是學(xué)習(xí)曲線比較陡。它用一個不同的命令行接口，不同的編程接口及不同的YAML文件定義等。換言之，你不能使用docker命令行接口也不能用docker compose來定義容器。好在kubernetes提供了各種api供開發(fā)者調(diào)用，也使得容器云平臺和kubernetes的結(jié)合成為可能。是否能發(fā)揮出kubernetes的強(qiáng)大功能也是容器云平臺是否好用的判斷標(biāo)準(zhǔn)之一。
　　Mesos Marathon

　　Mesos是一個開源集群管理系統(tǒng)，支持各種工作負(fù)載。
　　marathon為運(yùn)行在mesos之上的框架（Framework），為運(yùn)行Docker容器（以及本地Mesos容器）提供支持。它的雙層調(diào)度機(jī)制可以使得集群規(guī)模大很多。其它框架的調(diào)度器是直接面對整個集群，Mesos的優(yōu)勢在于，第一層調(diào)度先將整個Node分配給一個Framework，然后Framework的調(diào)度器面對的集群規(guī)模小很多，然后在里面進(jìn)行二次調(diào)度，而且如果有多個Framework，例如有多個Marathon，則可以并行調(diào)度不沖突。
　　學(xué)習(xí)成本較高，復(fù)雜性較高，多層管理工具，很多marathon的高級功能作為Marathon之上運(yùn)行的附加框架提供（如marathon-lb）。
　　總結(jié)：
　　Docker Native更新迭代快，封裝較少，所以較為靈活，對于簡單的web/stateless應(yīng)用來說是個不錯的選擇。然而如果需要部署復(fù)雜的，大規(guī)模的生產(chǎn)環(huán)境應(yīng)用，則可能不是那么適用。kubenetes相較于mesos，提供更加豐富和成熟的功能體驗(yàn)。label的定義使用使得k8s更加靈活
　　如果你是一名開發(fā)人員，正需要一種科學(xué)的辦法來加速你的應(yīng)用程序開發(fā)過程或者微服務(wù)的構(gòu)建，那么我們建議你選擇Docker。
　　如果你是一個dev/devops團(tuán)隊(duì)，想要搭建一個系統(tǒng)致力于Docker容器編排，并愿意親力親為底層基礎(chǔ)設(shè)施的集成解決方案（或依賴于公共云基礎(chǔ)設(shè)施，如谷歌引擎或Azure容器服務(wù)），Kubernetes是你值得考慮的好技術(shù)。
　　如果您想構(gòu)建一個可靠的平臺，可以運(yùn)行多個關(guān)鍵任務(wù)，包括Docker容器、遺留程序（例如：Java）和分布式數(shù)據(jù)服務(wù)（例如：Spark，Kafka，Cassandra，Elastic），并想要可移植的云服務(wù)或數(shù)據(jù)中心，那么Mesos（或者我們自己的Mesos分布， Mesosphere DC/OS）是適合你的。

3. SDN（跨主機(jī)網(wǎng)絡(luò)通信）

　　在這里主要討論的是多主機(jī)容器網(wǎng)絡(luò)解決方案（SDN網(wǎng)絡(luò)）。
　　多主機(jī)聯(lián)網(wǎng)意味著將不同主機(jī)上的容器連接到同一個虛擬網(wǎng)絡(luò)，下面介紹三種方式實(shí)現(xiàn)：
　　docker的overlay網(wǎng)絡(luò) 使用docker network create -d overlay my-overlay 創(chuàng)建命名為 my-overlay的網(wǎng)絡(luò)。Overlay網(wǎng)絡(luò)是docker原生實(shí)現(xiàn)跨主機(jī)通信的網(wǎng)絡(luò)驅(qū)動類型，同時還需要一個鍵值型的服務(wù)發(fā)現(xiàn)和配置共享軟件。Overlay實(shí)現(xiàn)跨主機(jī)容器互聯(lián)的通信過程是這樣的：
　　1．宿主機(jī)A上的容器1通過容器的eth0發(fā)送出去，并通過路由表發(fā)往br0，br0相當(dāng)于交換機(jī)，如果目標(biāo)容器在同一宿主機(jī)，則直接通過br0通信，如果不在則通過vxlan；
　　2．br0收到請求會交給vxlan1，并通過宿主機(jī)的eth1發(fā)送出去；
　　3．請求到達(dá)宿主機(jī)B，發(fā)現(xiàn)是vxlan報文則交給宿主機(jī)B上的vxlan設(shè)備；
　　4．Vxlan設(shè)備處理后交給br0，br0根據(jù)MAC表完成請求投遞。
　　overlay雖然可以方便的實(shí)現(xiàn)跨主機(jī)訪問需求，但在傳遞過程中性能損耗較大，不太適合在生產(chǎn)過程中使用，經(jīng)常用于開發(fā)測試或者小并發(fā)量的容器集群。
　　flannel網(wǎng)絡(luò)
　　flanel需要先于docker啟動，docker啟動前需要配置flannel的信息，在docker啟動時啟用flannel網(wǎng)絡(luò)。flannel支持flannel和Etcd之間的TLS加密通道，以及Flannel對等體之間數(shù)據(jù)路徑的加密，在數(shù)據(jù)性上更加安全。但flannel在進(jìn)行路由轉(zhuǎn)發(fā)的基礎(chǔ)上進(jìn)行了封包解包的操作，這樣浪費(fèi)了CPU的計算資源。flanne沒有提供網(wǎng)絡(luò)隔離方案，需要使用者定制化解決隔離問題。
　　calico網(wǎng)絡(luò)
　　Calico 整個過程中始終都是根據(jù)iptables規(guī)則進(jìn)行路由轉(zhuǎn)發(fā)，并沒有進(jìn)行封包，解包的過程，這和flannel比起來效率就會快多了。請求從源容器經(jīng)過源宿主機(jī)，經(jīng)過數(shù)據(jù)中心的路由，然后到達(dá)目的宿主機(jī)最后分配到目的容器。Calico支持網(wǎng)絡(luò)隔離，可以方便的隔離租戶數(shù)據(jù)，隔離方案有NetworkPolicy，微分段等。
　　由于Calico是純?nèi)龑咏鉀Q方案，并不支持所有的第3層或第4層協(xié)議。只有TCP，UDP，ICMP和ICMPv6得到Calico的支持，flannel等其他解決方案由于是udp封裝或者是vxlan方式，可以支持通過L3封裝L2數(shù)據(jù)包，所以支持所有協(xié)議。
　　小結(jié)：
　　Calico不支持任何種類的加密方法，以及支持部分協(xié)議的通信，但是Calico在這三個解決方案中達(dá)到了最佳的性能，而且支持隔離策略，因此更適合內(nèi)部環(huán)境和多租戶環(huán)境。適合打造企業(yè)私有云或者混合云。

4. 定制化方案

　　根據(jù)客戶需求提供定制化方案，比如：
　　1）K8S重構(gòu)
　　API Server減負(fù)：分析API請求，大量使用緩存技術(shù)
　　etcd：監(jiān)控，演戲故障恢復(fù)；configmap
　　Controller重構(gòu)：Node Controller，Service Controller
　　2）容器reuse策略
　　容器優(yōu)先自動拉起先前退出的容器，而不是總是啟動新的容器。
　　3）IP保留池
　　設(shè)計IP保留池，已應(yīng)用為單位進(jìn)行IP保留，容器刪除則IP回池，該應(yīng)用的容器創(chuàng)建使用池中的IP。
　　4）容器rebuild等
　　容器修改鏡像，配置文件，環(huán)境變量等，則在當(dāng)前容器所在節(jié)點(diǎn)新啟動一個容器而不用重新調(diào)度，并使用原來的數(shù)據(jù)卷。
　　容器云平臺不是簡單的堆砌開源解決方案，而是有在理解的基礎(chǔ)上進(jìn)行對客戶需求進(jìn)行深入定制的能力。

5. 公有云，私有云及混合云的場景及實(shí)現(xiàn)

　　公有云：
　　公有云實(shí)現(xiàn)規(guī)模化才能生存
　　公司對全盤云化沒做好準(zhǔn)備時，更愿意把公有云視為需求量不可預(yù)測的工作負(fù)載或者全新應(yīng)用開發(fā)的試驗(yàn)地。公有云市場面臨瓶頸。
　　私有云：
　　真正的私有云是做減法
　　私有云并不是把公有云的所有功能都照搬進(jìn)來，80％的企業(yè)私有云需要的是一個基本的云功能。降低企業(yè)私有云使用門檻，加快云計算進(jìn)入數(shù)據(jù)中心
　　混合云：
　　企業(yè)的應(yīng)用部署在安全性，可控性，定制化等方面有各種顧慮，有的想把關(guān)鍵數(shù)據(jù)留在內(nèi)部網(wǎng)絡(luò)，接入系統(tǒng)部署在公有云，或者直接在內(nèi)部網(wǎng)絡(luò)部署應(yīng)用，通過公有云進(jìn)行管理，所以就有混合云的需求存在，作為服務(wù)商我們開發(fā)者中心應(yīng)該提供相應(yīng)的方案實(shí)現(xiàn)混合云的架構(gòu)需求。大部分的“混合云”產(chǎn)品只有打通了控制層面，更多是把焦點(diǎn)放在管控面，除了管控面的統(tǒng)一調(diào)度，實(shí)現(xiàn)數(shù)據(jù)層面的統(tǒng)一以及自由流動，構(gòu)建無縫的用戶體驗(yàn)，才是混合云的本質(zhì)。實(shí)現(xiàn)控制面和數(shù)據(jù)面徹底打通才是真正的混合云。

6. 打造簡單而強(qiáng)大的容器云平臺 

　　我們從編排選型，網(wǎng)絡(luò)通信，定制化能力和平臺接入方面闡述了容器云平臺的關(guān)鍵指標(biāo)和適用場景，打造一個安全，穩(wěn)定，高效的容器云平臺，需要我們在simplicity（使用簡單）和power（功能強(qiáng)大）之間找到一個平衡點(diǎn)。我們可以將功能模塊化，在保證核心功能穩(wěn)定高可用的基礎(chǔ)上，根據(jù)不同的使用場景和用戶人群，提供相應(yīng)的技術(shù)選型和不同維度的服務(wù)，做到簡單而強(qiáng)大。
　　用友云開發(fā)者中心采用Mesos Kubenetes 雙編排架構(gòu)，可以按照用戶需求提供不同的服務(wù)，容器間通信（SDN網(wǎng)絡(luò)）采用calico方案，并使用networkpolicy實(shí)現(xiàn)網(wǎng)絡(luò)隔離策略，支持在控制臺主頁進(jìn)行一鍵設(shè)置，更安全可靠。核心模塊的存儲采用OSS及Fastdfs分布式存儲，確保了多集群訪問，以及通過掛載卷的方式實(shí)現(xiàn)容器的文件共享，并提供了容災(zāi)策略，使用戶的數(shù)據(jù)更安全。
　　對marathon框架及k8s進(jìn)行了深度優(yōu)化，對升級和自動擴(kuò)縮進(jìn)行了優(yōu)化，實(shí)現(xiàn)了真正的不間斷升級和熱更新。
　　開發(fā)者中心既有公有云的展現(xiàn)，又提供了定制化的專屬云版本，并可通過接入***和建立vpc專線的方式提供混合云的打通。相信總有一款適合你。