Hulu是美國領先的網際網路專業影片服務平臺，目前在美國擁有超過2000萬付費使用者。Hulu總部位於美國洛杉磯，北京辦公室是僅次於總部的第二大研發中心，也是從Hulu成立伊始就具有重要戰略地位的分支辦公室，獨立負責播放器開發，搜尋和推薦，廣告精準投放，大規模使用者資料處理，影片內容基因分析，人臉識別，影片編解碼等核心專案。
在影片領域我們有大量的影片轉碼任務；在廣告領域當我們需要驗證一個投放演演算法的效果時，我們需要為每種新的演演算法執行一個模擬的廣告系統來產出投放效果對比驗證；在AI領域我們需要對影片提取幀，利用一些訓練框架產出模型用於線上服務。這一切都需要執行在一個計算平臺上，Capos是Hulu內部的一個大規模分散式任務排程和執行平臺。
Capos是一個容器執行平臺，包含映象構建，任務提交管理，任務排程執行，日誌收集檢視，Metrics收集，監控報警，垃圾清理各個元件。整個平臺包含的各個模組，如下圖所示：
使用者可以在介面上建立映象描述符，系結GitHub的repo，生成映象。之後在介面上建立作業描述符，填上映象地址，啟動引數，資源需求，選擇資源池，就可以執行作業，看作業執行日誌等。這些所有操作也可以透過REST API來呼叫，對於一些高階的需求，Capos提供Golang和Python的SDK，可以讓使用者申請資源，然後啟動作業，廣告系統就是利用SDK，在Capos上面申請多個資源，靈活的控制這些資源的生命週期，一鍵啟動一個分散式的廣告系統來做模擬測試。
Capos大部分元件都是用Golang實現的，Capos的核心元件，任務排程執行CapScheduler是今天主要和大家分享和探討的模組。CapScheduler是一個基於Mesos的Scheduler，負責任務的接收，元資料的管理，任務排程。CapExecutor是Mesos的一個customized executor，實現Pod-like的邏輯，以及pure container resource的功能，在設計上允許Capos使用者利用Capos SDK復用計算資源做自定義排程。
上圖淺藍色部分是Mesos的元件，包括Mesos master，Mesos agent，Mesos zookeeper。Mesos作用是把所有單體的主機的資源管理起來，抽象成一個CPU、Memory、Port、GPU等的資源池，供之上的Capos scheduler使用。
其中Capos scheduler是一個active-standy的HA模型，在scheduler中我們實現了一個raft based的k-v用來儲存Metadata，active的scheduler註冊成為Mesos之上的一個framework，可以收到資源，根據排程策略來啟動作業。
Capbox是一個定製實現的Mesos的executor，作為Mesos agent的資源的佔位符，接收請求與Mesos agent上的Docker daemon通訊啟動容器。其中也實現了POD-like的功能，同時可以啟動多個容器共享network，磁碟等。
Capos scheduler提供兩類作業執行，一個是簡單作業直接在Capbox執行，另一個是複雜帶有程式設計語意的作業，我們稱之為AppMaster，其本身執行佔用一個CapBox，然後透過程式設計語意二次申請CapBox執行作業。
首先說明下簡單作業執行流程，這裡的簡單作業，提交的作業透過json描述，可以包含多個Container，然後scheduler收到請求之後，命中某個offer，向Mesos傳送offer啟動請求，在請求中同時夾帶著作業json資訊，把作業啟動起來，scheduler根據Mesos狀態同步資訊來控製作業的生命週期。
如果是AppMaster Programmatically二次排程的作業，首先需要把AppMaster啟動，這部分和簡單作業執行是一致的，然後AppMaster再申請一個到多個資源來啟動CapBox，執行作業。此時AppMaster申請的CapBox的生命週期完全由AppMaster決定，所以這裡AppMaster可以復用CapBox，或者批次申請CapBox完成自己特定的排程效果。多說一句，AppMaster可以支援client-mode和cluster-mode，client-mode是指AppMaster執行在叢集之外，這種情況適用於把AppMaster嵌入在使用者原先的程式之中，在某些場景更符合使用者的使用習慣。
說完Capos的使用方式後，我們可以聊下在Capos系統中一些設計的思考：
1、Scheduler的排程job和offer match策略，如下圖所示：
快取offer。當scheduler從Mesos中獲取offer時候，Capos scheduler會把offer放入到cache，offer在TTL後，offer會被launch或者歸還給Mesos，這樣可以和作業和offer的置放策略解耦。
外掛化的排程策略。Capos scheduler會提供一系列的可插拔的過濾函式和優先順序函式，這些優先順序函式對offer進行打分，作用於排程策略。使用者在提交作業的時候，可以組合過濾函式和優先順序函式，來滿足不同workload的排程需求。
延遲排程。當一個作業選定好一個offer後，這個offer不會馬上被launch，scheduler會延遲排程，以期在一個offer中match更多作業後，再launch offer。獲取更高的作業排程吞吐。
2、Metadata的raft-base key value store
多個scheduler之間需要有一個分散式的kv store，來儲存作業的Metadata以及同步作業的狀態機。在scheduler downtime切換的時候，新的scheduler可以接管，做一些recovery工作後，繼續工作。
基於Raft實現的分散式一致性儲存。Raft是目前業界最流行的分散式一致性演演算法之一，Raft依靠leader和WAL（write ahead log）保證資料一致性，利用Snapshot防止日誌無限的增長，目前Raft各種語言均有開源實現，很多新興的資料庫都採用Raft作為其底層一致性演演算法。Capos利用了etcd提供的raft lib， 實現了分散式的一致性資料儲存方案。etcd為了增強lib的通用性，僅實現了Raft的核心演演算法，網路及磁碟io需要由使用者自行實現。Capos中利用etcd提供的rafthttp包來完成網路io，資料持久化方面利用channel並行化leader的本地資料寫入以及follower log同步過程，提高了吞吐率。
Capos大部分的模組都是Golang開發，所以目前的實現是基於etcd的raft lib，底層的kv儲存可以用BoltDB，Badger和LevelDB。有些經驗可以分享下，在排程方面我們應該關註關鍵路徑上的消耗，我們起初有引入StormDB來自動的做一些key-value的index，來加速某些帶filter的查詢。後來benchmark之後發現，index特別在大規模meta儲存之後，效能下降明顯，所以目前用的純kv引擎。在追求高效能排程時候，寫會比讀更容器達到瓶頸，BoltDB這種b+ tree的實現是對讀友好的，所以排程系統中對於kv的選型應該著重考慮想LevelDB這種lsm tree的實現。如果更近一步，在lsm tree基礎上，考慮kv分離儲存，達到更高的效能，可以考慮用badger。不過最終選型，需要綜合考慮，所以我們底層儲存目前實現了BoltDB、Badger和LevelDB這三種引擎。
簡單的作業可以直接把json描述透過REST API提交執行，我們這邊討論的是，比較複雜場景的SaaS，可能使用者的workload是一種分散式小系統，需要多個Container資源的執行和配合。這樣需要Capos提供一種程式設計方式，申請資源，按照使用者需要先後在資源上執行子任務，最終完成複雜作業的執行。
-
Capbox.go capbox是Capos中資源的描述：
AppMaster可以用這些API申請資源，釋放資源，獲取資源的狀態更新，在此基礎上可以實現靈活的排程。
-
Task.go task也就是可以在Capbox上執行的task，如下圖所示：
在資源基礎上，appmaster可以用api啟動/停止作業，appmaster也可以復用資源不斷的啟動新的作業。基於以上的api，我們可以把廣告模擬系統，AI框架tensorflow，xgboost等分散式系統執行在Capos之上。
4、Capos對比下Netflix開源的Titus和Kubernetes
Netflix在今年開源了容器排程框架Titus，Titus是一個Mesos framework，titus-master是基於fenso lib的Java based scheduler，meta儲存在cassandra中。titus-executor是Golang的Mesos customized executor。因為是Netflix的系統，所以和AWS的一些設施是系結的，基本上在私有雲中不太適用。
Kubernetes是編排服務方面很出色，在擴充套件性方面有Operator，Multiple Scheduler，CRI等，把一切可以開放實現的都介面化，是眾人拾柴的好思路，但是在大規模排程短作業方面還是有提升空間。
Capos是基於Mesos之上的排程，主要focus在大規模叢集中達到作業的高吞吐排程執行。
在分散式排程編排領域，有諸多工業界和學術界的作品，比如開源產品Mesos，Kubernetes，YARN，排程演演算法Flow based的Quincy，Firmament。在long run service，short term workload以及function call需求方面有Service Mesh，微服務，CaaS，FaaS等解決思路，私有雲和公有雲的百家爭鳴的解決方案和角度，整個生態還是很有意思的。絕技源於江湖、將軍發於卒伍，希望這次分享可以給大家帶來一些啟發，最後感謝Capos的individual contributor（字母序）：chenyu.zheng、fei.liu、guiyong.wu、huahui.yang、shangyan.zhou、wei.shao。
Q：Capos如何處理健康檢查？之前瞭解到，Mesos內建的健康檢查不是特別完善。
A：目前Capos focus的作業大部分都是短作業型別，所以我們目前就是透過容器的退出碼來判斷success或者fail，如果你說的健康檢查是針對服務的，一般實現是支援多種健康檢查的方式，bash，http等，然後為了大規模容器執行情況下的可用性，建議這種健康檢查的發起client和服務instance是在一臺機器上，或者是一個Pod中，發現不健康透過某種機制上報，或者退出Container，但是需要控制Threshold以免整個服務downtime。這樣可以探測instance的健康，整個服務的健康，可以在透過外部的一些子系統去check。
Q：關於排程方面，分享中只提到了使用了一系列的可插拔的過濾函式和優先順序函式，我想問下能否具體描述下如何被排程的？和yarn裡使用的Fair Schedule或者DRF演演算法的異同有哪些？因為對於多種資源維度的排程是一個很複雜的問題，希望知道Hulu這方面有什麼心得和思考？
A：目前實現是，會針對一個請求，首先根據過濾函式比如一些constraints進行offer過濾，然後剩下的offer apply所有的優先順序打分函式，進行打分，打分的時候，會根據一個請求和offer的資源，算CPU和mem的比例，選取出dominate的resource進行主要評分，然後選取最優的offer進行bind，bind之後不會馬上排程，而是會delay scheduler，這樣一般在比較繁忙的情況下，一次offer launch可以啟動多個tasks，這是對於大規模吞吐的考慮。 以上這些實現還是queue-base的排程，借鑒了一些Fair Schedule和drf的思路，具體差別你瞭解了Capos scheduler策略後，應該就會有自己的想法了。多種資源維度，目前我們是根據dominate resource作為主要評分標準的，當然你也可以看下我最後分享提到的一些flow-base的scheduler演演算法，比如firmament。希望可以回答你的問題。
Q：Capos是否支援，資料中心之間的備份/切換。比如Zone – A的資料中心出現網路故障，把服務遷移到另一個指定的區域 Zone – B（仍然考慮恢復以後優先部署到 Zone – A）。之前考慮是類似一個Mask的機制，如果故障就加一定的Mask值（比如Opcacity）在某個叢集上，然後排程的時候去參考這個Mask值，不知道Hulu有沒有類似的需求或者考慮過這樣的機制？
A：Capos是on Mesos，Mesos是根據zk做選主，而且Capos scheduler中還有一個raft base key value store，所以這些條件，使得Capos是一個datacenter的解決方案。目前Hulu是有多個DataCenter的，所以看架構元件圖，你可以看到，我們有一個Capos portal，在這個元件下，是可以選擇不同DataCenter去run workload。所以我們目前對於資料中心的備份和切換，主要是依賴Capos portal這個元件，在Gateway的位置做的控制。
Q：想請問下Capos的鑒權是怎麼做的，有沒有使用者許可權認證系統？此外，針對每個使用者有沒有容器資源使用量的限制？
A：可以翻到之前share的架構元件圖，我們有一個Capos portal元件，這個元件是提供Restful API和Portal，我們在這邊整合Hulu SSO，然後關聯Hulu yellowpages（Hulu的服務許可權控制系統），做的使用者的認證，我們分成自己的Capos APP， team的APP，別的組無法操作不屬於自己的Capos APP。對於Quota的管理，我們做了Queue/Label機制，每個服務會建一個標識，然後在標識底下配置總的資源使用量，以及可以用的機器串列（萬用字元），用這樣的機制控制Capos的使用者資源使用。
本次培訓包括：Docker介紹、Docker映象、網路、儲存、容器安全；Kubernetes架構、設計理念、常用物件、網路、儲存、網路隔離、服務發現與負載均衡；Kubernetes核心元件、Pod、外掛、微服務、雲原生、Kubernetes Operator、叢集災備、Helm等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
文章已於修改
![]()
微信掃一掃
使用小程式
知識星球
