淺談如何打造一個安全穩定高效的容器雲平台


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

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專線的方式提供混合雲的打通。相信總有一款適合你。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM