概要

參加了上一次CNUTCON 大會，有來自coreos的李響，分享了很多關於etcd的事情，以及關於k8s包括自己和coreos公司的一些觀點；還有來自mesos的tim chen, 他分享了很多mesos的思路以及一些接入容器過程中踩過的一些坑；swarm kit的負責人陳東洛也分享了swarm的思路，這方面由於剛出來沒多久以及分享的同學也只有他，所以東西並不多；總的來說，感觸很深。

關於容器和編排，想到開源和創業

從會議分享者來看。相比去年，容器技術有了更大的發展；docker很熱，每一個主題都在涉及docker。且基本上大家都認同docker的鏡像。對於容器，雖然也有其他的一些選擇，比如rkt,lxc等，但對於runtime以及介面，大家基本趨於一致，短期也不會期望有大的變化，大家開始從更高層次思考容器的應用，比如直接提供給用戶編排的工具，服務或系統，而不是一個容器。swarmkit的發布就有這個意思，大家開始把重心轉移到編排和調度。

從個人對容器的發展來看。大會上幾位問到一些隔離的問題，分享嘉賓都說這個比較複雜，要麼說這塊他們沒有解決，確實經常出問題，要麼說私下來討論；其實我們在接入和調度容器的時候，也發現了目前的容器技術在隔離上還欠缺很多，如果要能更好的提高物理機的資源利用率，降低成本，單機隔離和單機彈性將是一大關鍵技術和核心競爭力。

我們採用了跟mesos一樣的架構和思路，因此我重點聽了mesos相關的topic，希望是能夠吸取到好的經驗，能實際實施到我們的系統中，然後聽了更多的k8s的topic。整體個人感覺,在開源解決方案中，k8s目前要熱過mesos，k8s在web service這方面確實佔據了很大的市場，吸引了很多開發者，但在有狀態服務的應用特別是大數據上面目前並沒有很好的解決方案，社區也一直在討論和抽象當中。相反mesos在大數據服務場景下能夠很好的解決，並在集群規模上也有很好的優勢,但拿到mesos是不能直接解決用戶的需求，需要用戶寫一個scheduler。swarm的思路則是另外一種哲學，或是另一個極端，跟docker的思路是同承一脈的，把更多的東西集成進系統里，提供給用戶簡單統一的介面，裝好docker就可以編排調度了，這方面後續發展如何，很難說，暫且不論。總的來說，這一開源領域目前仍是K8s、Swarm、Mesos三足鼎立，近期也看不到誰會完全勝出。它們的功能比較如下圖所示。

無論mesos這種2次調度，擴展性強的哲學，還是swarm kit這種集裝箱式的哲學，其次是k8s先取其中，優先發展自己優勢的思路。國外這種開源以及項目創業的一些共性值得我們思考和學習，這裡舉一個例子， coreos公司他們把他們的目標和使命定義為"secure the internet", 在zookeeper的發展滿足不了他們需求的時候，他們能做出這麼大的決定重新build一個如此大的項目，並且成功了，成為容器界基本都依賴的一個項目，這個勇氣和思路值得學習。

我們的項目前身是hippo，跟google borg相似，採用自建的方式，借鑒了很多mesos的思路，但確沒有使用mesos開源版本進行改進，與社區缺乏交流，不能共享mesos社區新的feature，也不能對開源進行影響；另外我們系統暫時也不能對國內技術全產生很大的影響，吸收群體的智慧有限，這是一大遺憾。都說開源是有利益目的的，你認同嗎?

從mesos接入docker，想到hippo接入docker

為什麼想到這個，實際上我們在接入的過程當中踩到了相同的坑，有的mesos解決的好，有的還沒有解，可以作為後續改進的一個參考。

mesos和hippo容器化之路 (Containerizer)

容器接入的介面設計

我們團隊關注docker很早，在hippo啟動前就開始就關注docker。

14年我們直接用cgroup和namespace等標準的os feature完成了引擎進容器的demo，證明了隔離的可行性。

一直想完善我們的隔離，docker開始嶄露頭角，但docker在2.6.32內核上要跑到生產還不行，而t4在阿里在生產已經跑了一段時間，因此我們14年為了讓混布，提高資源利用率，節省成本，選擇了t4進行落地。

跟mesos一樣，在容器技術沒有完全統一的情況下，我們當時在設計的時候也考慮了支持不同的容器以及不同的隔離策略，以實現用戶的定製需求和可插入性，或者可配置性。

mesos在最開始的時候，為了支持External Containerizer，定義了一套回調的腳本介面，用戶可以在腳本里完成各個階段的工作。但docker非常火，連k8s也在學習docker的介面設計理念，而且External Containerizer變得很難用，最終這種方式被廢棄掉。

hippo是自建方案，有一個好處我們不需要考慮太多其他人的兼容性，這樣我們在設計實現的時候，相對的在介面設計方面做得直接些，沒有過度設計，從t4到docker基本上，對主體結構代碼沒有太多的侵入性。createInstance，destoryInstance，checkInstance幾個簡單的介面不論是什麼容器，都適用。

現在的mesos，對docker是native integration。沒有額外的setup。只需要docker daemon和docker client。可以說在這方面和hippo是殊途同歸了。

容器接入踩了很多坑，還有很多未解決的

真的就是3個介面那麼簡單嗎？mesos在接入docker的時候，在處理日誌，recovery, tag containers, cgroup資源更新等等踩了很多坑。以docker update為例，docker在1.2以前是一直不支持的，且後續版本也支持的不夠。

更能說明這個問題的是如果mesos自己跑在容器里，如何去更新其他容器的資源，因為這個時候已經chroot。mesos採用了一個跑在宿主機的docker exectute的代理（如圖2）。這個方案我覺得比我們做的好，我們的pouch(阿里自研容器產品)把很多的邏輯直接做在了docker daemon，這樣侵入性太高，跟蹤最新的docker版本成本很高，無法及時享受修復的bug以及新的feature。

還講到一些cgroup的坑，我們最近在升級7u的過程也踩到過。主要是systemd+docker+mesos。這三者都會涉及cgroup節點。在7u中，systemd管控了整個系統的資源。https://issues.apache.org/jira/browse/MESOS-3009 ，他們踩到一些坑復現後發現是docker創建的容器，systemd有在干預它的cgroup。hippo也踩到了這樣的坑，對應的內存,cpu限制不住，我們的實際做法是通過採用cgroup driver為systemd，並在pouch裡面通過systemd api來控制cgroup來避開這些衝突。

還有很多解決了的坑，暫且不論，還有很多我們未解決的坑，這些可能每一個都需要開一個topic去討論，這裡有興趣的可以私下討論。

docker會妨礙我們的容器發展嗎？

mesos的經驗，docker相對比較重，在一台機器上跑很多的docker容器是會帶來額外很多問題。

hippo希望做的更強大，希望能支持更多的離線和在線job，來提供資源利用率，最終降低成本。但有的場景需要很輕量級的容器，有的需要更強的隔離。比如，隨著圖像處理需求的增強，AR/VR的發展，對GPU的隔離需求會越來越強烈，如果我們一直等docker來提供這些feature來解決這些問題，肯定是不行的，這是一個很大的問題。因此，和mesos一樣，hippo也需要考慮解決這個問題，因此可能如何支持不同級別的隔離是未來需要思考的。

容器裡面跑容器

這個在集群調度中心群也集中討論過這個問題，當時是為了解決case的資源問題，據部分同學說docker不支持這個。但mesos表態要支持這個，他們舉了幾個需求，這裡講一個。

一個是在跑CI（Jenkins）時，希望jenkins申請一個大的資源，然後jenkins分給跑在上面的case，tim說這樣做是為了設計簡單，感覺沒有說到點子上，但估計他對這塊不是很熟，但我們的場景有一點很明確，就是各二層測試的時候，需要部署hippo一層來創建出各類的異常case。這個時候就需要二層起的hippo跑在容器的容器里。

還有一個很重要的需求其實來源於pod。需要容器里跑容器，來進行更細粒度的資源控制，以及更靈活的調度。

How to solve utilization, fairness and performance when

running all of these services at scale?

這才是最根本的問題，tee選擇離開mesos，選擇創業，需求也來源於此。

這個我們還在探索當中，大師從谷歌帶回來的消息是，他們的cpu利用率超乎你的想像，我們還在探索當中，這裡暫且不論。

其他

一口氣寫了這麼多，零零碎碎，僅僅作為容器大會的一次觀後作業。 整個2天下來，東西很多，對國內的這麼大的分享也是第一次參加，會前並不太會選topic，所以會場裡面的topic，有收穫的，也有純粹看熱鬧了，總體感覺國外請過來的嘉賓乾貨多，國內的廣告多；國內張磊workshop專場講k8s技術點以及發展還不錯，ppt都在上面，大家可以下載下來看看，http://ppt.geekbang.org/cnutcon。

另外阿里新一代基礎設施調度系統sigma正在如火如荼的統一所有資源池，後面我們也會在這方面分享對應的技術和思考。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！