本文介紹了容器的現狀和發展趨勢，容器叢集編排引擎選型，跨主機網路通訊，定製化方案，公有云，私有云及混合雲的場景及實現等內容，說明如何打造簡單而強大的容器雲平臺。

1. 容器技術現狀及發展趨勢

　　什麼是容器？

　　我們可以將容器理解為一種沙盒，每個容器具有獨立的作業系統資源，不同的容器之間相互隔離，也可以建立通訊，應用跑在各自的容器中，避免了環境中有衝突的資源使用，做到一次封裝，到處執行。

　　那容器與虛擬機器的區別在哪？

　　容器可以看做輕量的虛擬機器，虛機啟動可能需要數分鐘或者更長，而容器只需幾十毫秒。傳統虛擬技術是在硬體層面實現虛擬化，有效能損耗，而容器技術是以共享核心的方式實現，幾乎無損耗。虛擬機器更擅長於徹底隔離整個執行環境。例如，雲服務提供商通常採用虛擬機器技術隔離不同的使用者。而Docker通常用於隔離不同的應用，例如前端，後端以及資料庫。

　　以Docker為代表的容器技術的出現，給雲端計算提供了全新的視角，使建立和部署應用如堆積木一樣簡單，我們在建立應用或服務時，不用考慮資源和維護成本，使得應用的部署極為簡單快捷，失敗的成本大大降低，讓我們的注意力更多的聚焦在應用和服務本身，而不是繁瑣的系統和環境配置中。

　　幾年來，容器技術的發展也十分迅猛，從管理單一容器應用到管理多容器，多主機的分散式應用。企業也紛紛面臨著由傳統應用向雲端分散式應用的轉變，使用容器技術將應用轉型為微服務。

　　隨著容器採用率越來越快，容器的生態環境也需要快速迭代。需要有一個平臺可以對容器叢集進行高效靈活的管理，方便的搞定容器編排和容器部署，容器雲平臺應運而生。容器雲平臺應具備哪些能力，如何打造一個安全，穩定，高效的容器雲平臺，我們從下面幾方面來談一談。

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

　　容器編排是容器雲平臺的核心部分和基礎能力，為實現大規模的容器化部署提供一個抽象層的處理。典型的容器編排引擎需要實現以下幾個功能：叢集（跨主機提供計算能力），排程（決定容器部署在哪個節點），可伸縮（支援應用例項的自動或手動擴容縮容），容錯（應用或主機故障的情況下自動重啟容器），隔離（保障容器安全）。

　　Docker Native（swarm）

　　Docker自帶原生編排工具，新增已經在多節點執行的Docker到Swarm中，Swarm的設定是很簡單的：你只需在其中一個節點上呼叫docker swarm init，然後在任何其他你想新增的節點上呼叫docker swarm join即可。使用與Docker Engine和Docker Compose相同的語法提供編排支援。

　　swarm會自動地做一些如負載均衡，保持容器副本數量等工作，所以swarm對外提供的和k8s類似也是屬於一個“服務”的概念。

　　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也可以使用約束和標籤來做一些非常基本的容器排程。使用約束可以向服務新增關聯，並且它將嘗試僅啟動具有特殊標籤的容器。

　　Kubenetes

　　kubelet將控制給定節點上的容器或pod與主控制節點的連線。kubeproxy用於為Kubernetes中定義的服務提供負載平衡和高可用性。

　　Kubernetes使用Pods的概念作為基本單位，而不是單個容器。每個pod是一組容器（集合大小可以是一個）。

　　kubernetes把叢集帶到了一個全新的高度，代價是學習曲線比較陡。它用一個不同的命令列介面，不同的程式設計介面及不同的YAML檔案定義等。換言之，你不能使用docker命令列介面也不能用docker compose來定義容器。好在kubernetes提供了各種api供開發者呼叫，也使得容器雲平臺和kubernetes的結合成為可能。是否能發揮出kubernetes的強大功能也是容器雲平臺是否好用的判斷標準之一。

　　Mesos+Marathon

　　Mesos是一個開源叢集管理系統，支援各種工作負載。

　　marathon為執行在mesos之上的框架（Framework），為執行Docker容器（以及本地Mesos容器）提供支援。它的雙層排程機制可以使得叢集規模大很多。其它框架的排程器是直接面對整個叢集，Mesos的優勢在於，第一層排程先將整個Node分配給一個Framework，然後Framework的排程器面對的叢集規模小很多，然後在裡面進行二次排程，而且如果有多個Framework，例如有多個Marathon，則可以並行排程不衝突。

　　學習成本較高，複雜性較高，多層管理工具，很多marathon的高階功能作為Marathon之上執行的附加框架提供（如marathon-lb）。

　　總結：

　　Docker Native更新迭代快，封裝較少，所以較為靈活，對於簡單的web/stateless應用來說是個不錯的選擇。然而如果需要部署複雜的，大規模的生產環境應用，則可能不是那麼適用。kubenetes相較於mesos，提供更加豐富和成熟的功能體驗。label的定義使用使得k8s更加靈活

　　如果你是一名開發人員，正需要一種科學的辦法來加速你的應用程式開發過程或者微服務的構建，那麼我們建議你選擇Docker。

　　如果你是一個dev/devops團隊，想要搭建一個系統致力於Docker容器編排，並願意親力親為底層基礎設施的整合解決方案（或依賴於公共雲基礎設施，如谷歌引擎或Azure容器服務），Kubernetes是你值得考慮的好技術。

　　如果您想構建一個可靠的平臺，可以執行多個關鍵任務，包括Docker容器、遺留程式（例如：Java）和分散式資料服務（例如：Spark，Kafka，Cassandra，Elastic），並想要可移植的雲服務或資料中心，那麼Mesos（或者我們自己的Mesos分佈， Mesosphere DC/OS）是適合你的。

3. SDN（跨主機網路通訊）

　　在這裡主要討論的是多主機容器網路解決方案（SDN網路）。

　　多主機聯網意味著將不同主機上的容器連線到同一個虛擬網路，下面介紹三種方式實現：

　　docker的overlay網路 使用docker network create -d overlay my-overlay 建立命名為 my-overlay的網路。Overlay網路是docker原生實現跨主機通訊的網路驅動型別，同時還需要一個鍵值型的服務發現和配置共享軟體。Overlay實現跨主機容器互聯的通訊過程是這樣的：

　　1．宿主機A上的容器1通過容器的eth0傳送出去，並通過路由表發往br0，br0相當於交換機，如果目標容器在同一宿主機，則直接通過br0通訊，如果不在則通過vxlan；

　　2．br0收到請求會交給vxlan1，並通過宿主機的eth1傳送出去；

　　3．請求到達宿主機B，發現是vxlan報文則交給宿主機B上的vxlan裝置；

　　4．Vxlan裝置處理後交給br0，br0根據MAC表完成請求投遞。

　　overlay雖然可以方便的實現跨主機訪問需求，但在傳遞過程中效能損耗較大，不太適合在生產過程中使用，經常用於開發測試或者小併發量的容器叢集。

　　flannel網路

　　flanel需要先於docker啟動，docker啟動前需要配置flannel的資訊，在docker啟動時啟用flannel網路。flannel支援flannel和Etcd之間的TLS加密通道，以及Flannel對等體之間資料路徑的加密，在資料性上更加安全。但flannel在進行路由轉發的基礎上進行了封包解包的操作，這樣浪費了CPU的計算資源。flanne沒有提供網路隔離方案，需要使用者定製化解決隔離問題。

　　calico網路

　　Calico 整個過程中始終都是根據iptables規則進行路由轉發，並沒有進行封包，解包的過程，這和flannel比起來效率就會快多了。請求從源容器經過源宿主機，經過資料中心的路由，然後到達目的宿主機最後分配到目的容器。Calico支援網路隔離，可以方便的隔離租戶資料，隔離方案有NetworkPolicy，微分段等。

　　由於Calico是純三層解決方案，並不支援所有的第3層或第4層協議。只有TCP，UDP，ICMP和ICMPv6得到Calico的支援，flannel等其他解決方案由於是udp封裝或者是vxlan方式，可以支援通過L3封裝L2資料包，所以支援所有協議。

　　小結：

　　Calico不支援任何種類的加密方法，以及支援部分協議的通訊，但是Calico在這三個解決方案中達到了最佳的效能，而且支援隔離策略，因此更適合內部環境和多租戶環境。適合打造企業私有云或者混合雲。

4. 定製化方案

　　根據客戶需求提供定製化方案，比如：

　　1）K8S重構

　　API Server減負：分析API請求，大量使用快取技術

　　etcd：監控，演戲故障恢復；configmap

　　Controller重構：Node Controller，Service Controller

　　2）容器reuse策略

　　容器優先自動拉起先前退出的容器，而不是總是啟動新的容器。

　　3）IP保留池

　　設計IP保留池，已應用為單位進行IP保留，容器刪除則IP回池，該應用的容器建立使用池中的IP。

　　4）容器rebuild等

　　容器修改映象，配置檔案，環境變數等，則在當前容器所在節點新啟動一個容器而不用重新排程，並使用原來的資料卷。

　　容器雲平臺不是簡單的堆砌開源解決方案，而是有在理解的基礎上進行對客戶需求進行深入定製的能力。

5. 公有云，私有云及混合雲的場景及實現

　　公有云：

　　公有云實現規模化才能生存

　　公司對全盤雲化沒做好準備時，更願意把公有云視為需求量不可預測的工作負載或者全新應用開發的試驗地。公有云市場面臨瓶頸。

　　私有云：

　　真正的私有云是做減法

　　私有云並不是把公有云的所有功能都照搬進來，80％的企業私有云需要的是一個基本的雲功能。降低企業私有云使用門檻，加快雲端計算進入資料中心

　　混合雲：

　　企業的應用部署在安全性，可控性，定製化等方面有各種顧慮，有的想把關鍵資料留在內部網路，接入系統部署在公有云，或者直接在內部網路部署應用，通過公有云進行管理，所以就有混合雲的需求存在，作為服務商我們開發者中心應該提供相應的方案實現混合雲的架構需求。大部分的“混合雲”產品只有打通了控制層面，更多是把焦點放在管控面，除了管控面的統一排程，實現資料層面的統一以及自由流動，構建無縫的使用者體驗，才是混合雲的本質。實現控制面和資料面徹底打通才是真正的混合雲。

6. 打造簡單而強大的容器雲平臺

　　我們從編排選型，網路通訊，定製化能力和平臺接入方面闡述了容器雲平臺的關鍵指標和適用場景，打造一個安全，穩定，高效的容器雲平臺，需要我們在simplicity（使用簡單）和power（功能強大）之間找到一個平衡點。我們可以將功能模組化，在保證核心功能穩定高可用的基礎上，根據不同的使用場景和使用者人群，提供相應的技術選型和不同維度的服務，做到簡單而強大。

　　用友雲開發者中心採用Mesos+Kubenetes 雙編排架構，可以按照使用者需求提供不同的服務，容器間通訊（SDN網路）採用calico方案，並使用networkpolicy實現網路隔離策略，支援在控制檯主頁進行一鍵設定，更安全可靠。核心模組的儲存採用OSS及Fastdfs分散式儲存，確保了多叢集訪問，以及通過掛載卷的方式實現容器的檔案共享，並提供了容災策略，使使用者的資料更安全。

　　對marathon框架及k8s進行了深度優化，對升級和自動擴縮排行了優化，實現了真正的不間斷升級和熱更新。

　　開發者中心既有公有云的展現，又提供了定製化的專屬雲版本，並可通過接入vpn和建立vpc專線的方式提供混合雲的打通。相信總有一款適合你。