詳解如何構建容器服務平台?
文末有福利,閱讀需仔細。
編者的話:容器技術作為這兩年最令人矚目的技術,在各個行業無論是互聯網還是傳統行業都得到廣大的應用。作為致力於打造金融行業領先的平安雲,於今年引進容器技術,研發平安雲容器服務平台,吧容器技術應用到業務中,推動業務和技術快速發展。本次分享的核心內容即是從用戶 痛點及特徵分析想如何構建平安雲容器平台,內容分為4個部分:
容器平台定位
容器平台設計
容器平台架構
容器平台設計技術
一、定位
首先平安集團旗下的子公司包含了金融行業各個類別,每個子公司有自己的開發模式,對底層計算資源的需求也各有不同。
對做平台來說,所有需求都是合理的,因此平安云為用戶提供不同類型的計算資源。
在提供容器之前,雲平台已經存儲雲主機、雲存儲,現在雲平台將提供容器服務。
因此我們將容器定義為虛擬機式的容器服務。提供符合平安基礎架構,用戶自助服務的容器服務。
計算服務「三劍客」,滿足不同種類的計算需求:物理機+虛擬機+容器。
容器入伍作為一種輕量、便捷的計算方式,需要發展其長處。
二、平台的設計
平台建設
1、面向多租戶
「內部公有雲」,需要滿足多租戶安全隔離的需求,有足夠的許可權控制,支持多種計算方式互聯互通。
2、融合用戶體驗
符合雲服務的特徵,簡化交付流程
兼顧用戶使用習慣和既有的流程
汲取容器的優勢進行微創新
下面是對應的產品概覽圖。
平台設計概念模型
租戶:對應雲門戶的租戶概念,可以理解為一個部門,或者一個產品開發組。
環境:即容器運行的載體,環境中包含若干台主機,環境內的主機共同承擔容器的運行。
主機:只能屬於某個指定的環境,不能跨環境部署。
應用:與系統概念相似,對應容器的stack概念
編排:即Docker Compose
服務:即Docker Service
容器:即Docker Container
鏡像:即Docker Image
平台設計主要功能
1、 容器環境
租戶在一個數據中心擁有一套單獨容器服務。用戶可以根據需求創建多套容器環境,並將自己的計算節點添加到環境中,實現底層資源的彈性擴容。
環境之間資源、服務等完全隔離,僅在管理態存在關聯。
2、應用
支持Docker Compose V1編排方式創建。提供常見的編排方案,一鍵式部署應用,應用和編排相互轉,個人編排發布到應用商城。
3、服務
支持服務連接、埠映射、環境變數、目錄掛載等多種策略等配置。
詳細的服務管理:服務信息、服務事件、服務配置。支持Shell、文件上傳、鏡像製作等擴展功能。
4、鏡像管理
鏡像商城:提供多種官方鏡像,所有租戶均可使用。
公共倉庫:每個租戶擁有自己的公共倉庫,租戶內用戶共享租戶內鏡像.
個人鏡像:支持將容器提交成鏡像,下載官方和公開鏡像.
支持多區域分散式鏡像管理。上述是我們針對容器領域提供的四大功能。
三、容器部署架構
先整體看我們目前的平台系統架構。
其中上述的各個區是公司針對金融行業所架設的網路架構。具體考慮如下:
首先,門戶部署在雲管區中,保證所有租戶都能通過門戶使用容器服務。另外,我們的鏡像商城也部署在雲管區中。
在每個數據中心的都部署一套或者多套容器編排調度系統,針對不同區域和用戶需求。
如在開發區域,我們提供一套編排系統,所有租戶使用一套容器服務。
而在生產環境,我們會為每個租戶搭建一套編排系統,這樣租戶之間完全隔離。
另外容器平台會和監控平台以及配置管理中心對接。其中上述的各個區是平安雲正對金融行業所架設的網路架構。
介紹完部署組件,再詳細介紹每個組件的功能以及使用到的技術。
雲管區(對外)
CaaS Portal 是我們核心,也是用戶直接接觸的界面。具體介紹就是前一章的功能介紹的界面。
CaaS Portal 後台資料庫我們採用mysql集群,使用的Galera Cluster集群技術。
Pub Hub是我們為平安用戶搭建的鏡像商城,由於網路以及規範原因,我們採取自行搭建鏡像hub。將Docker hub最主要的鏡像下載到商城中。
公共服務區(雲平台資源區,對內)
Docker Server:我們在Remote Docker API的基礎上封裝了一套Java實現的Docker API,並將它作為Docker Server Agent部署。
用於執行Docker命令,比如提交鏡像為容器,獲取鏡像數據。
編排:我們採用開源容器編排平台Rancher,通過調用API方式管理容器。
Registry Mirror:為了不讓租戶VPC下的所有Docker Jost一起訪問Pub Hub,也減少網路之間的傳輸以及安全。
我們在每個數據中心搭建了一套Registry,與Pub Hub通信。當用戶需要創建容器後。
另外我們配置工具採用Ansible,該工具主要到docker host上執行相應命令。例如將VM變成Docker Host,並且添加到環境里。我們將Ansible包裝成Restful。
四、容器平台技術
整體的架構分享完畢,後面針對容器服務所涉及的技術以及我們的方案進行介紹。容器領域所涉及的技術包括:
容器網路
容器存儲
容器日誌
容器監控
鏡像管理
整個容器技術也就主要包括這5大塊。
容器網路
先介紹容器網路歷史,我將容器忘了的發展分為3個階段。
第1階段:
容器最早的網路模型,提供了4種方式。bridge橋接模式,即使用主機IP,而將容器埠映射到主機的埠中。缺點在於埠大量使用會導致衝突。
Host方式:使用host ip,缺點就是一個容器使用了某個埠後,其他容器再也不能使用該埠。
Container方式:即和主機上的其他容器共享網路。
None方式:不設置網路,需要手工配置、
第2階段:
為了解決上述問題,湧現了很多方案,比較有名的就下面三種,這三總都是為了解決跨主機通訊,最大程度彌補容器本身的網路模型缺點。
從技術層面講,這些容器技術可以歸為兩個技術流派:隧道模式和路由模式。其中,IPSec,Fannel屬於隧道模式,而Calico屬於路由模式。
第3階段:
後來Docker公司和Google公司分別為自己的容器網路模型指定標準。其中Docker公司推出的標準是CNI,可以通過Docker命令直接管理網路模型。
介紹完網路知識,我們看看CaaS選擇網路。
對外:Container Bridge,採用埠映射
對內:容器之間採用實現的IPsec隧道實現(直接使用編排框架Rancher自帶的)。
如果某個容器需要對外服務,則採用埠映射方式,連通所在VM,就可以暴露服務。如果容器不需要對外提供服務,只需要在同個應用內提供服務,那麼採用ipsec方式,這樣避免浪費過多埠。
容器與容器之間建立私有網路,只有容器與容器之間可以訪問。每個容器都擁有一個私有網路地址。
下面我是我們通過容器平台創建的一個Tomcat容器,同時我將該容器映射到主機上,以便可以從外面訪問。其中,對外的埠佔用問題,我們統一分配和回收。
可以看到該容器又主機IP 239,以及容器IP 10.42.243.155。這裡就綜合使用的埠映射和ipsec。
容器存儲
目標:極快的創建速度,極小的存儲資源消耗以及容器遷移的便捷性。
技術:分層和寫時複製CoW。
實現:AUFS,Device Mapper,ZFS,OverlayFS。
目前我們容器服務統一運行在CentOS,還沒使用其他操作系統。因此我們選擇DeviceMapper作為容器存儲驅動。
下面是Docker官方提供的所有存儲驅動的成熟度。可以看到目前比較成熟的是AUFS和DeviceMapper。目前只有這兩個是官方建議的Production-Ready,我們的容器平台選擇DeviceMapper。
Docker存儲系統選擇發展比較早比較成熟的Device Mapper,一方面是因為該技術已經納入Linxu內核,穩定成熟,另一方面我們選擇VM是CeotOS,其默認使用的是DeviceMapper。DeviceMapper底層直接使用雲磁碟作為Pool,採用LVM管理。
除了容器和鏡像存儲外,另外一塊大家所忽視的存儲是應用數據存儲,包括配置文件。我們的方案採用了Volume介面或者直接Volume映射。
這樣解決容器可以自動遷移。關於日誌,主要實現如下。
容器服務平台日誌:本地+雲平台ELK日誌服務。
容器自身運行日誌:本地雲磁碟+雲平台ELK日誌服務。
容器內應用(業務方)日誌:業務自行規劃,已經提供目錄掛載。
容器監控
這塊監控,我們依賴於雲平台原有 監控,另外補充了針對容器特有的監控。
1、主機監控
2、容器監控
自研髮腳本,提供容器本身的性能監控(CPU、Mem、Network、Storage),監控平台定時獲取,同時,能夠在Portal上查看。
3、特定的中間件監控
提供常見中間件的性能監控(WebLogic、Tomcat、Nginx等),為中間件鏡像製作腳本,中間件監控程序整合到Docker鏡像中,容器一啟動,就能即時上報性能數據到監控平台,無需任何外部干預。該監控能夠到監控平台查看。
監控平台是由本部門另外團隊研發。目前採用Zabbix、Open-Falcon。
鏡像管理
針對鏡像管理,我們從單節點->雙節點->跨區域分散式進行演進。
1、鏡像管理使用Distribution,前端設置LVS+ Keepalived作負載均衡和高可用,鏡像存儲採用DNAS。
2、Docker Server是我們自行開發的服務組件,每個區域都部署一套,對接本區域的Registry。
一方面:監聽當前區域的Registry事件,然後主動發起同步操作。
另一方面:執行Dockcer命令,管理該區域的所有運行容器的機器。
關於跨區域分散式鏡像管理,基本只有三種方式:
主動執行同步,比如調用docker remote api,執行docker push /docker pull。
事件監聽,採用registry的notification監聽。
底層存儲同步。
我們綜合三種方案,結合實際,採用的第1和第2中方案。
Q:跨區域的容器集群間是否能通信?
A:目前跨區域機器不能通訊。跨區域之間機器是租戶完全隔離。如果租戶需要通訊,需要針對具體機器進行開牆。
Q:請問使用DeviceMapper其中遇到了那些問題?
A:最常遇到的是device busy。會導致容器無法刪除。此時需要人工干預。
Q:鏡像管理如果只是基於distribution的話,許可權與多租戶管理是如何實現的?
A:許可權納入平台管理,由我們自行實現。租戶之間的鏡像不可共享。租戶內的可共享和私有。
租戶間的鏡像必須通過發布,由平台審核方能在各個區域和各個租戶間共享。
Q:監控是用什麼語言開發的,是自主開發還是用開源的?
A:監控,我這邊針對鏡像和容器這塊做了一些監控數據的收集,然後提供給監控平台。監控平台由部門另外一組開發。目前基於Zabbix進行開發。
Q:請問:1. DockerHUB只有一個實例嗎?如何保證高可用?2. Docker Server間同步的是什麼內容呢?
A:所有區域,包括pub和mirror,都是keepalive+lvs搭建。目前使用雙registry+共享nas。而這兩個Registry所在的vm是跨az。也就是一個Registry宕完全不影響另外一個提供。而nas是雙寫nas,我們這邊的存儲組提供的DNAS服務。備份策略也是可以根據自己定義。
Q:pub hub獲取docker hub 鏡像的方式,目前是自動維護嗎?
A:不是,從docker hub進入公司官方鏡像倉庫,都是人工維護同步。我們需要針對一些鏡像做特殊處理。
Q:IPsec的性能傳說不是很好,你們有遇到過網路的問題嗎?Rancher 的IPsec網路性能怎麼樣?容器有涉及到彈性伸縮嗎?容器間採用Rancher 實現網路通信,為什麼沒有選擇類似組件?
A:這3個問題統一回答。目前是使用IPsec。由於當前每個Rancher對接的容器數目不是特別大,還沒產生網路問題。另外對外網路走的是雲主機網路。
有考慮過其他組件,由於之前起步階段,所有直接採取rancher提供的。最近Rancher提供支持CNI的方案。目前正在研究對應的組件。
Q:我能想到的一個方案是自己的用戶體系加雲平台的租戶和雲平台的用戶體系,多對1的映射,當審核通過後,使用不同的雲平台用戶,這樣許可權就不一樣了。是這樣嗎?
A:目前容器服務只針對公司內部開放,直接兼容雲平台租戶。
Q:請問內核版本是?用4.9的計劃嗎?平安雲是OpenStack嗎?用Magnum嗎?
A:使用CentOS 7.2,內核版本是3.10.xxx,平安雲使用Cloud Foundry,平安雲使用了多種虛擬機,VMware和KVM是主要。
Q:容器是跑在物理機上還是虛擬機上,容器所在的操作系統歸租戶所有還是運營商所有?容器的分配規則由誰決定?一個宿主機跑多少個容器由誰決定?
A:目前資源限制還是交給Rancher來管理,我們對Rancher的規劃是:讓Rancher管理資源,分配容器。在頁面提供Docker目前支持的資源參數。
容器所在的操作系統歸租戶所有。租戶可以任意添加自己的雲主機到容器華環境中。
Q:目前這個系統是內部用的吧?安全性有沒有考慮?
A:安全:目前針對公司內部,使用公司AD認證登錄。而計算資源限制採用租戶隔離。鏡像這塊安全採用主機互信。
Q:很多業務日誌是不直接輸出到stdout 的,這些業務日誌如何搜集?容器日誌的採集採用什麼方式?容器規模大約有多大呢?當採集方出現採集中斷的時候會有報警提示嗎?打入到es後,做了哪些比較有效的報表數據呢?
A :日誌需要分為三種:
容器服務平台日誌:本地+雲平台ELK日誌服務
容器自身運行日誌:本地雲磁碟+雲平台ELK日誌服務
容器內應用日誌:業務自行規劃,已經提供目錄掛載
平台這邊目前集中負責前兩個日誌。日誌這塊也會根據重要程度選擇上報告警。
業務日誌:我們提供方案。
針對業務方的日誌管理:需要幫助業務方將系統容器化,其中一個重要的方面就是日誌管理。
目前採用方案:讓業務方將日誌容器化,這樣日誌不會打在容器本身的所在的機器上。
福利:從10.24(猿節)日起,加入本號知識星球的前五名同學,將獲得由極客時間提供的一門專欄課程(68-299元),課程內容包括(技術與商業案例解讀/AI技術內參、左耳聽風、趣談網路協議/數據結構與演算法之美等8個專欄、深入淺出K8s等)。請新成員留言聯繫獲取課程,課程和選擇有限,先到先得(10.31截止)。
數據存儲知識星球
致力於構建專業存儲技術平台,研討存儲技術(分散式,傳統存儲,高端存儲,雲存儲,快閃記憶體,軟體定義存儲),存儲生態,數據保護,介質,存儲特性(加密,重刪,防病毒等)。
溫馨提示:
求知若渴, 虛心若愚
※解析微服務架構組件,看這一篇文章就夠
※對大數據架構師說,離年薪100w還有多遠?
TAG:架構師技術聯盟 |