實錄分享 | Mesos PMC 帶你回顧 Mesos 2016

數人云上海&深圳兩地「容器之 Mesos/K8S/Swarm 三國演義」的嘉賓精彩實錄第五彈！ Mesos Committer 登場，爲咱們帶來 Mesos 2016 年新功能的全面解讀及將來展望。 Mesos 愛好者不容錯過哦^_^

黃浩鬆， Apache Mesos PMC

目前就任於 Shopee （東南亞社交電商平臺），負責公司自動化運維平臺建設，業餘時間長期在 Apache Hadoop / Apache HBase / Tensorflow 打醬油。

今天想跟你們介紹一下 Mesos ，以及 Mesos 社區過去一年在容器化方面作的一些工做。我本人是一名在 Shopee 負責基礎設施工做的工程師， Shopee 主要作東南亞的電商市場。日常除了上班以外，下班和週末的空餘時間我常常會在社區打醬油，是 Apache Mesos Committer ，對 Mesos 比較熟悉。你們能夠經過下面的連接加入 Mesos 的 Slack ，遇到任何問題均可以在 Slack 上發問。更正式的方式是經過 Mesos 的郵件列表，上面的 user@mesos.apache.org 是專門給用戶的，下面的 dev@mesos.apache.org 是給開發者的，若是你肯定發現了 Mesos 的 BUG ，能夠直接把遇到的錯誤還有錯誤日誌貼到 Mesos JIRA 上。

What is Mesos?

今天照顧一下沒有了解到 Mesos 的同窗，講一下什麼是 Mesos ，以及當初爲何公司看各類容器編排框架的時候選擇了 Mesos ，後面最主要講今年社區作 Mesos 容器化方面作的兩個比較大的東西，一個是 Unified Containerizer ，另外一個是對 POD 的支持。

Mesos 的目標是想作一個數據中心的 Kernel ，相似於主流服務器操做系統的 Kernel 是 Linux 同樣。從一臺服務器的角度來講，一個 Linux kernel 資源抽象，單臺機器的 CPU ，單臺機器有多少內存，對 Mesos 來講由於是一個數據中心的操做系統，就上面的應用提供一個集羣這樣視角的資源，看到是這一批機器有多少空餘的 CPU ，有多少空餘的 memory 。若是你是針對單臺機器編程的話，在 Linux Kernel 裏面看到的是那種 POSIX 的 API ，好比進程、線程、包括系統標用調類的，若是用 Mesos 的話，它會提供對應的 API ，包括 Task ， Resource 等相關的抽象接口，把整個集羣的資源抽象起來。在資源隔離方面， Linux Kernel 用的是不一樣的用戶，還有不一樣的進程空間。可是 Mesos 主要是用容器，用 CGroup 、 Namespace 及其餘東西來隔離不一樣用戶之間的應用。

一個典型的 Mesos 集羣是這樣的，公司把 Spark 和 Kafka 跑在了同一個 Mesos 集羣裏面，通常一個 Mesos 集羣裏面有多臺 Master ， Master 是 Meoss 的控制節點，而後在每一臺機器上都裝一個 Mesos Agent ， Mesos Agent 具體去啓動用戶的任務， Master 之間的選舉包括 HA 經過 Zookeeper 來作。在 Mesos 上面跑着各類各樣的 Framework ，包括 Spark 、 Kafka 。 Kubernetes 或者 Marathon 均可以跑在 Mesos 上，也支持 Cassandra 這樣有狀態的分佈式的數據庫跑在 Mesos 上面。經過把不一樣種類型的 Framework 混布在一塊兒，給不一樣的 Framework 分配不一樣的角色和 Quota ，避免不一樣 Framework 互相的資源搶佔。過去一年社區還作了包括 Quota ， Weights ，如今還在作的多層資源調度，讓離線還有實時應用更好的充分利用整個計算集羣的資源。

Linux 編程的時候接觸到的都是進程、線程等概念， Mesos 則將進程抽象爲 Framework 、 Resource 、 Task 還有 Excutor 這幾個概念。舉個典型的例子，假設用戶要啓動一個 Docker 的鏡像，上層的 Framework ，即 Marathon 會發一個請求， Mesos 會按期的把 Resource Offer 發到 Framework ， Marathon 收到了用戶的任務請求以後就會找出匹配的 Offer ，將用戶的那些要啓動的鏡像等一系列的參數發給 Mesos Master ， Mesos Master 收到以後直接會到對應的 Mesos Agent 上去啓動任務，變成一個 Task 。

Mesos 自己有不一樣的抽象級別，最基礎的級別是 API 。 C++、 Java 、 Python 、 Golang 都有對應的 API 庫，若是你使用的語言找不到對應的庫的話，整個 Mesos API 都是基於 HTTP ，實現對應的庫也很是簡單。像使用 SDK ， API 開發新的 Framewor 都是須要一些時間的，大概耗費幾周或者 1 、 2 個月的時間。還有一種更簡單使用 Meos 的方式，直接用 JSON 等形式的 DSL 來定義好應用，這種只須要幾分鐘就能夠搞定。像 Marathon 用的就是 JSON 形式的 DSL ， Aurora 則是使用形似 Python 的 DSL 。

Why choose Mesos?

爲何當初 Shopee 在那麼多 Framework 中選擇了 Mesos ，有三個重要緣由： Mesos 通過這麼多年已經很是穩定，其次它的 Scalability 很是好，另外對於公司有各類奇奇怪怪的需求，能夠很是容易在它上面作擴展和可定製化。

Mesos 最開始是 2009 年 Ben 讀博士時候作的一個項目，在 2010 年 5 月，他們幾我的去 Twitter 介紹了一下它， Twitter 以爲這個很像谷歌的 Borg ，很是好，就直接把他們招進來繼續作， 9 月的時候發佈了 Mesos 的第一個版本，在 2010 年 12 月進入了 Apache 的孵化器，在第三年成爲了 Apache 的頂級項目，如今快 1.2 的版本了，這些年下來是至關穩定的。有一個完整的 Powered By Mesos 的列表，如今上面有 100 多家公司，還有更多的公司由於不知道有那個列表的存在，沒有加進去。

像 Apple 、 Twitter 、 Uber 都是在生成環境很是普遍地使用 Mesos ，在社區也有很是多的貢獻。還有像 Paypal ， 2 Sigma 這樣的金融公司，以及 Verizon 的這種電信運營商。 Mesos 在國內也有很是多的用戶，像小米、知乎、豆瓣和國內的三大運營商，特別是豆瓣在很早的時候就開始使用 Mesos ，他們在 Mesos 上面開發了不少框架，而且開源出來，還有微博、惟品會、攜程等。 Twitter 據我所知，內部有 3 萬多臺機器都已經跑在了 Mesos 裏， Apple 可能有更多，最開始他們把 Siri 即蘋果的語音助手放在 Mesos ，後來感受效果不錯，就把更多的服務遷移到了 Mesos 上面。

Verzion 使用 Mesos 也不少，他們演示了在 60 秒內啓動了 5 萬個 Container ，全部 Container 在 60 秒內都所有啓動完成了。爲何 Mesos 能夠擴展到這麼多臺機器，最關鍵的一點是 Master 是無狀態的，設計得很是簡單。不然像其餘的一些容器編排調度的框架把狀態存在 etcd 或者 consul 裏面，當機器愈來愈多時，存儲那些狀態的一些外部存儲，好比 etcd 會最早成爲瓶頸。 Mesos master 只用 Zookeeper 作 leader 選舉以及 HA ，並不會有其餘而外的狀態信息。自己 Mesos 只是想作一個數據中心的 Kernel ，就像 Linux 的 Kernel 同樣自己很是小。 Mesos 只專一於資源的分配和隔離，以及任務管理。

Mesos 每發一個版本以前都會作迴歸測試，有時候一個不經意的改動，看上去感受只是拷貝了某一個的 protobuf Message ，可是實際上擴展到幾萬臺機器時，這個改動均可能形成性能的降低。因此每次發佈以前，社區都會進行很是嚴格各方面的測試。 Shopee 目前機器是幾千臺，未來可能也會像 Twitter 或者是 Apple 那樣把 Mesos 用在幾萬臺機器上，因此，那時候就選擇了 Mesos 。並且 Mesos 參與的公司比較多，有 IBM 、 Microsoft 、 Uber 、 Apple 等公司，整個社區均可以一塊兒幫忙測試和改進 Mesos ，讓 Mesos 很是穩定。新版本發佈的時候，若是有任何兼容性的問題任何人均可以直接一票拒絕。

另外對於 Shopee 而言，有內部的服務器資產管理系統、本身內部的驗證、以及一些特殊的硬件設備，調研 Mesos 的時候就發現 Mesos 擴展性很好，能夠在上面繼續實現公司各類需求。每個公司都有公司內部的不一樣的狀況， Mesos 只專一作資源調度和隔離，而其餘部分則傾向於對接開放的標準，好比在網絡方面支持 CNI ，在存儲方面支持 Docker Volume ，而不是強制讓用戶使用某種網絡模型或者某種存儲。事實上也不存在一個容器編排框架，能夠知足全部不一樣公司不一樣用戶的需求，因此， Mesos 會盡可能傾向於把全部的東西都作成模塊，把核心的東西都作得比較簡單。

跑在 Mesos 上的 Framework 有不少種類型，有一些是跑 web 服務的，這種通常須要一直跑，自己沒有狀態，會很容易的水平擴展；有一些是定時跑的，並且定時的服務之間有相互的依賴，比方必定要 A 完成以後才能作 B ；另一些數據庫的，本地每個 Container 之間不能隨便啓動，之間有相互的依賴。就長時間跑的 servies 來講， Mesos 上有不少不一樣種類的 Framework ，都是不一樣公司實現的，像 Mesosphere 的 Marathon ，還有數人云也實現了一個 Swan 。你能夠在 Mesos 上面跑 Spark 、 Flink 、 Storm 這種計算的任務， Alluxio 、 Ceph 、 HyperTable 這種數據庫及文件系統。固然還有其餘各類類型，好比 Tensorflow on Mesos 的機器學習 Framework ，還有 Vamp 的一個 DevOps 框架，能夠作自動的擴容和縮容，根據總體的服務的狀況，把 container 的 instance scale in 和 scale out 。更多的框架，能夠在 Mesos 的官網的文檔裏找到。

在 Service Discovery 方面， Mesos 提供了不少的選項，包括基於 DNS 的，咱們公司作的基於 Zookeeper 的，其餘公司也會有各類不一樣方案。 traefik 比較有意思，一個域名過來，域名下面不一樣的路徑，它會對應地把這個路徑轉發到不一樣的後端 Container ，能夠看到 /api 這個路徑就轉到這一個 instance ， /web 的話就轉到另外一個 instance 。它能夠監聽 Mesos 或者 Marathon 裏面新起容器的變化，自動動態更新。爲何須要動態更新呢，假設一種場景，這臺機器掛掉了， Marathon 會在其餘機器上新起 Container ，而這個 Container 由於被調度到不一樣機器，機器的 IP 或者端口已經變化了，若是直接使用 Nnginx 或者 Apache 的話，沒辦法感知到這種的變化，像用這個 traefik 就能夠感覺到其餘的變化，從新生成一個配置文件並加載。

七層必定要有 HTTP 或者 HTTPS 協議，像 linkerd 也是相似的，但四層的可使用 TCP 或者 UDP 。它監聽 Mesos 或者 Marathon 的變化，把服務的 IP 自動更新到配置。也有使用 Mesos-DNS 的，可是用 DNS 的時候有一個問題，就是 DNS 自己有一個 TTL ，當服務掛或者是遷移的時候有必定的 downtime ，因此 Shopee 大部分東西仍是基於 Zookeeper 作服務發現，並無用 DNS 的方式。

Marathon 也有本身的 LoadBalancer ，基於 HAProxy ，一樣是是監聽本身 API 裏面容器狀態的變化。除了 Service Discovery 以外， Mesos 大部分已經模塊化，能夠按照它的接口實現包括驗證、採集、拉取資源，以及增長一些 Hook ，好比在 Docker 啓動前作什麼、銷燬後作什麼，包括 Master Contender ，若是公司內部不喜歡用 Zookeeper 的話，能夠用 etcd 作 Mesos 的 HA 和 Leader 選舉。以上主要爲你們介紹了 Mesos ，以及爲何 Shopee 那時選用了 Mesos 。

Mesos containerization in last year

接下來說一下社區在過去一年容器化方面作的工做，第一部分主要是加入了不一樣鏡像的支持，包括 Docker ， appc 和 oci 。以前若是要在 Mesos 裏面跑 Docker ，必定要裝一個 Docker Daemon ，全部啓動 Docker 的任務都是把它 delegate 到 Docker Daemon ，若是沒有 Docker Daemon ，機器就跑不了 Docker 的任務。如今 Mesos 能夠直接去 Docker registry 把鏡像一層一層拉下來直接解壓並啓動任務，因此，就算機器上沒有裝 Docker Daemon 也沒有問題。

在網絡方面 Mesos 去年支持了 cni ， cni 是其餘容器的編排平臺都支持的網絡協議的通用接口。經過 Mesos 支持 cni ，就能夠把 Mesos 和像 Maclan 及其餘一些 Vlan 的方式結合起來使用。

而後也支持了 Docker volume ，一些公司想在 Mesos 裏面用企業存儲，好比 EMC 的 ScaleIO ， Mesos 經過支持 Docker volume 的這種方式來對接了這些不一樣種類的分佈式文件系統。

在安全方面 Mesos 也作了不少，包括 Linux capabilities 、 User namespace ， seccomp 。當任務在容器裏面跑的時候，在容器裏面不能夠重啓服務器，不能夠修改網絡配置和宿主機上的一些文件。經過 Linux capabilities 還有 user namespace ，作到在容器裏面雖然是 root ，可是宿主機的角度看來是一個普通的用戶，這樣在容器裏面跑得任務就會比較安全，沒有辦法作一些宿主機 root 用戶能作的事，好比重啓機器這種危險的事。

還有一個是 POD ，就是把一組的任務跑在不一樣 container 裏面，這幾個 container 有相同的 namespace 。最主要的是能夠實現 DEBUG 、 Log 採集這樣的功能。 Log 採集要求必定能夠訪問到相同的文件系統。 Mesos 最近還在作了一個 CLI ，能夠從本地要遠程鏈接整個集羣的某一個 Container ，或者直接登陸進去進去裏面調試或者是執行一些命令。以上這些改動，方便你們更好的使用 Mesos 。

What is Unified Containerizer ？

關於 Unified Containerizer ，以前講到支持 Docker 、 Appc 、 OCI 三種不一樣的鏡像格式、支持三種不一樣鏡像格式的 Containerizer 就叫 Unified Containerizer 。 Mesos 裏面 Unified Containerizer 是處於 Mesos Agent 和 Task 之間中間的一個組件。它會接收 agent 的命令，把任務啓動起來，而且把任務放到 Container 裏面，而不是說直接在宿主機的環境跑，它會作包括建立，銷燬，檢測等 Contaienr 的管理工做，好比 Container 掛掉了，或者把健康檢查之類的一些狀態把它彙報給 agent 。

Unified Containerizer 裏面只分三個東西， Launcher 、 Isolators 和 Provisioner 。 Launcher 主要是啓動容器和殺死容器，如今 Mesos 支持 Mac ， Linux ， Windows ，不一樣的操做系統就是用不一樣的 Launcher 。機器上跑的大部分的容器隔離的功能都是在 Isolator 完成的，包括 Cgroup 不一樣的 subsystem ， CPU 、 memory 都是對應的一個一個的 Isolator 。磁盤控制容器只能用多少的磁盤空間，是經過 Disk 下面的幾個 Isolators 來管，包括一些 GPU 的 Isolators ，這些都是模塊化的，若是不想使用的話，參數的時候不傳進去，就不會加載進來。 Provisioner 是作鏡像管理，鏡像格式都是在 Provisioner 這裏把鏡像拉取下來解壓，一層層地解壓到機器上。

過去一年 Mesos 另一個比較大的特性是支持 POD ，若是有 POD 的使用要求能夠把 Mesos 升級到 1.1 。 Mesos 的 POD 還有其餘一些方面的特色，能夠支持任意層數的嵌套，最大能夠嵌到 32 層的 Container ，也能夠動態的建立和銷燬這些嵌套的 Container 。你們能夠看到原有的 Container 又啓動新的嵌套 container ，經過這種方式，這幾個嵌套 container 擁有一樣的網絡 namespace ，最主要的做用好比 debug ， Nginx 出問題了，能夠經過 Nested Container 直接遠程到 container 裏面 debug 。一些公司想把他們的 log 收集工具集成進來，能夠在這裏面起一個額外的 container 來採集 log 。

（此處是演示）啓動 Mesos 的集羣，能夠看到 POD 很簡單，就是一個生產者和消費者，消費者不停的往裏面寫數據，一直把它打出來，定義 path 外面有一個宿主，啓動這個 POD ，等 tasks 狀態變成 running ，能夠看到它在輸出，這個是 consumer 的 log ，生產者的信息也會在把那個打出來，兩個由於 share 相同的 namespace 以後纔可能這樣互相通訊。

What's the next ？

接下來 Mesos 要作的事情：

• 把 Mesos CLI 的工具改善，以前 Mesos Container 沒法遠程連上進行調試，你們在下個月 1.2 發佈後就能夠看到。

• 多層次的資源調度，這是 Mesos 以前說過的改進，避免實時還有離線的任務之間相互的資源搶佔，讓不一樣種類型的任務能夠混布在一塊兒。

• 支持更多類型的 Cgroups subsystem ，把以前漏掉的可是不那麼迫切的幾個 Cgroup subsystem 補齊，包括 blkio 和 cpuset 等等。

今天就到這裏，謝謝你們。