CDN邊緣節點容器調度實踐（上）

又拍雲容器雲是基於 Docker 的分佈式計算資源網，節點分散在全國各地及海外，提供電信、聯通、移動和多線網絡，融合微服務、DevOps 理念，知足精益開發、運維一體化，大幅下降分佈式計算資源構建複雜度，大幅下降使用成本。

上文是對容器雲的簡介，又拍雲容器雲是一個基於 Docker 的邊緣容器網絡。

過去，又拍雲數據中心用的是基於 Mesos 的容器調度平臺。它把數據中心的 CPU、內存、磁盤等抽象成一個資源池，Mesos 官方稱之爲分佈式系統內核。

 

Mesos架構

下圖是 Mesos 容器調度平臺的架構圖。

△ Mesos 架構

Mesos 調度平臺至關於數據中心的 Master，同時在每一個節點上都有一個 Agent。當每一個Agent 啓動後會向 Mesos 註冊，Agent 攜帶的資源信息，讓 Mesos 決定每一個框架的資源數量。當框架收到資源後，再根據需求調度資源。

Mesos Master 調度機制後面是 framework，經過 framework 能夠知足數據中心的容器調度。

 

邊緣容器調度方案概述

下面咱們簡要介紹下又拍雲的邊緣容器調度方案。又拍雲邊緣節點容器調度方案須要有一個部署在數據中心的 Master，負責集中調度統一管理。而 Agent 則部署在全國各個邊緣節點上，每一個節點的每臺機器上都會有一個 Agent，負責採集數據，管理 Docker。在邊緣運行長期服務，支持故障恢復。同一個節點的一批機器會組成一個集羣。另外，由於又拍雲有不一樣需求的客戶，因此邊緣節點須要部署多種功能，功能部署時要完成容器網絡的隔離，還會有一些負載均衡和定製化的需求。

版本 1 實現了調度策略最基本的功能

△ 版本1

上圖是最基礎的版本1 Master—Agent 架構。最上面是 Hancock （又拍雲內部項目名稱），它自己就是 Master，App 的擁有者能夠經過 API 接口接入，部署任務、建立 Docker 項目到邊緣節點。

這兩個虛線的框分別表示兩個不一樣的節點，每一個節點上數量不等的機器會組成一個小集羣，每一個機器上會部署一個 Agent， Agent 會負責建立各個 Docker 的 Task，容器服務的用戶(App user ) 直接會去邊緣節點訪問容器服務。

Agent 啓動後會上報消息到 Master， 而 Master 會根據用戶的請求和上報的消息下發指定給 Agent 。因爲邊緣節點和數據中心的網絡可能處於不穩定的狀態，在處理數據的時候會出現超時、延遲等問題，同步操做可能會致使用戶的請求一直得不到響應，最終致使信息丟失等問題，所以 Master 與 Agent 的數據交互、消息處理都是異步進行的。這種狀況下，用戶只要把請求提交到 Hancock Master 上，這個任務就會分發到全部的邊緣節點。

下面是 Master-Agent 消息介紹：

• 上報消息 Agent -> Master
• 下發指令 Master -> Agent

Resource 消息

當 Agent 啓動時會攜帶 Resource 消息 ，當攜帶資源信息發生變動時，會更新一次 Resource 消息 。如圖所示，Agent 經過節點名和主機名來惟一表示一臺邊緣設備，設備的資源信包括，網絡信息（包括運營商信息、寬帶信息），CPU， 內存， 磁盤，可用端口信息等，其中端口段的分配是由於有個攝像頭的用戶一個服務須要用到幾千個端口，這種狀況就再也不適合逐個端口進行隨機或者指定分配，這樣維護成本會變得很高。

Offer 消息

Agent 會定時上報 Offer 消息上報給 Master，會發送機器的 load 和當前網絡情況的使用狀況、CPU、Memory、Disk等使用狀況信息，以此維持 Master 與 Agent 之間的聯繫。

通常來講，Master 能夠計算出 CPU、Memory、Disk 的使用狀況。可是 load 和網絡情況，Master 是沒法知曉的，因此每隔一段時間就要上報，以供 Master 合理的調度 Docker 機器，好比不該該再安排服務部署到 load 較高的機器上。上述就是 offer 的做用。

Update 消息

負責提供實例的狀態變動，Docker 實例運行成功失敗等信息， 由 Agent 實時上報給 Master， 包含任務的狀態信息和相關描述。方便 Master 進行故障恢復等操做。

Containers 消息

負責提供機器容器列表， 防止有殭屍任務和任務遺漏， 由 Agent 定時上報給 Master， Master 負責檢查。

Master 到 Agent 的指令下發過程當中，主要包括兩個類下發指令：

1. 實例的建立，如增刪改查，把客戶增刪改查請求轉變爲對容器的操做
2. 鏡像操做，如鏡像拉取，鏡像查詢。好比 Docker 鏡像很大的時候，在邊緣節點拉取鏡像可能會超時。因此咱們設置了一個單獨的鏡像操做，保證在建立容器前，能夠預先異步提交拉取命令。

△ 處理流程

上圖是消息處理流程，當 Agent 啓動時上報 Resource、Offer、Container 等定時消息。其中 offer 消息頻率最高， 一旦一段時間沒有受到 Offer 消息， Master 會嘗試遷移這個 Agent 對應機器上的全部容器實例。

上述版本 1 的架構實現了調度策略最基本的功能。當 Master 收到各個集羣中 Agent 上報的資源時，經過自定義策略來完成任務調度。通常來講是尋找知足條件的（Node Cpu Mem Disk Port 等）機器。再選擇根據帶寬、load 等指標，進行權重估算，在估算出權重的前提下進行隨機調度。在權重相似的狀況下，每次調度儘量讓同一服務的各個實例分佈到節點的不一樣機器，保證在某臺機器崩潰的狀況下，其餘實例正常運行保證高可用。

 

版本 2 增長 calico，負責網絡控制和訪問限制

在版本 1 中，Master 和 Agent 已經完成了二者之間的消息交互。App 擁有者能夠建立服務，而且在邊緣機器上建立 Task。

但咱們不但願客戶的服務混雜在一塊兒，但願能夠隔離不一樣全部者的容器網絡， 能夠完成一些訪問控制的功能。又拍雲使用了 calico 的方案，它是基於 BGP 的路由協議的三層通訊模型，不須要額外報文封裝。

△ 容器網絡（圖片來自網絡）

如圖所示，其中 calico BGP client 負責每一個節點和集羣其餘節點創建 BGP Peer 鏈接，增加趨勢是 O(n^2)，它並不適合大規模的集羣網絡， 解決方法是 Route Reflector，選擇一部分節點做爲 Global BGP Peer，由它們互聯來交換路由信息。而又拍雲每一個邊緣集羣都是小規模集羣網絡，O(n^2) 的增加是能夠接受的，並不須要 Route Reflector 的機制。

其中 Felix 負責節點網絡相關配置。由它負責配置路由表、iptables 表項等。以便完成訪問控制和隔離的功能。

另外，集羣中還會有一個分佈式的 kv 數據庫—— etcd，負責保存網絡元數據。

 

calico 的優勢： 三層互聯，不須要報文封裝。訪問控制， 知足隔離網絡， 隔離容器。

calico 的缺點： 網絡規模限制， iptables 和路由表項限制。

△ 版本2

在咱們的場景下，它很好的知足了需求。加上 calico 方案，版本 2 的架構如上圖所示。

 

對內容感興趣的小夥伴，歡迎關注下咱們，《CDN邊緣節點容器調度實踐（下）》將於明天推送。