2016美國QCon觀察：容器與排程這麼熱，未來會是怎樣的一個趨勢？

編者按：今年qcon容器/docker和微服務幾乎占據了會場的半壁江山，大家也都趨之若鹜場場爆滿,而且作為一名雲計算工程師，對容器/docker也是格外關注,容器/docker已經不僅僅是個技術，而是作為一個生态在深刻影響着每一個細分行業，對于每個行業既是機會也是挑戰，稍有不慎可能就會被時代抛棄。作為與會者現場聆聽大家對容器/docker的思考和應用，并逐漸廓清現狀和未來，與大家共同學習。

    容器（container）是近些年迅速火熱的一門技術和話題，容器技術本身和在容器之上衍生的資源編排和排程技術也在飛速發展和演進之中，容器的代表有cgroup,docker,vm等，編排排程的代表有google開源的kubernetes以及apache社群的mesos，有了容器這個基礎之後微服務（microservice）也從一個萌芽和概念逐漸變成一個現實，并在生産環境中不斷得到應用和驗證。

    本次2016 san

francisco大會上container容器、scheduler排程器、resources orchestration資源編排、microservice微服務等系列技術成為了整個會場最熱門的話題，來分享的既有amazon、apple等大公司，也有mesosphere、netflix和其它一些行業翹楚。

    提到容器就不得不說docker，docker目前幾乎成為了容器的代名詞，有關docker的文章汗牛充棟，不再贅述。kubernetes也是docker生态中的一員，kubernetes為應用提供資源排程、部署運作、負載均衡、服務發現、彈性擴縮容等功能，kubernetes是docker出現之後google基于borg的理念開發的産品，可以了解為kubernetes = borg + docker（實際還是有些差别的），當然borg是無法開源的，borg如果開源估計半個google的技術棧都要開源了，後續講到的mesos也是與borg對标的一個技術産品。

    來自apprenda公司的mattew

miller分享了利用kubernetes實作業務微服務化的實踐經驗，主講人分享了kubernetes的架構和目前在開源社群的活躍程度，當然是極火了，kubernetes中有controller、pod、services幾種概念，pod是一組提供相同服務的容器的統稱，services是以邏輯或者ip位址對外提供服務的内部服務供應者，controller是pod的複制抽象，用于pod的擴縮容，對于搭建平台的使用者來說kubernetes不但提供可靠的cluster&workload管理、還有豐富的經過實戰檢驗的幾種pattern抽象，如：

rolling deployents：滾動部署新版本并不中斷服務，在新版本部署完成後老版本退出

sidecars：比如收集已有服務的日志

ambassador：比如提供通路sharding資料的統一入口

adatapter：比如将服務日志格式轉換成日志系統可以識别的格式

leader elector：保證提供單例服務通路

work queue：将service從1:1的關系擴充到1：n，為被通路的service前置一層代理agent，用來轉發請求

autoscale：根據收集的業務metric來決定是否需要自動擴縮容

    接下來來自mesosphere（mesos的發起者）公司的zhe yu分享了mesos的發展曆程和最近的一些改進， mesos提供資源管理和排程架構抽象的功能，第三方應用需要實作mesos架構提供的api才能接入mesos所管理的資源，具體的原理和架構可以自己去google。mesos近些年發展比較穩健，已經在若幹大公司的production環境使用，目前mesos最大的部署規模是30000個節點超過25w個容器，apple的siri就是基于mesos來實作，amazon内部據說也用到了mesos，主講人也提到了mesos的一個優勢就是提供flexible的可插拔的scheduler，當然mesos本來就是為此而抽象的，還有flexible的服務發現機制，包括但不限于dns/zk/chubby等，在此還吐槽了一下基于dns服務發現的機制，雖然沒說具體原因，但是應該和dns的生效時間不可控有關，而且dns還會受到本地local綁定、jvm虛拟機緩存dns解析結果等細節問題的幹擾，是以不是一個好的選擇。由于docker實在太火，mesos也加入到了支援docker的陣營中，從mesos 028版本開始支援，mesos支援的container種類繁多，甚至tar包也可以被當做一種container，而且也支援nested container，還提供了類似于docker cnm的cni（container network interface）方案來更清晰剝離container和網絡。

    聽完mesos的分享感覺mesos還是感受到了來自kubernetes的壓力，也有人現場提問mesos和kubernetes的差別，雖然mesos和kubernetes根本不屬于一個層面的東西，但是kubernetes更易用更貼近使用者業務，mesos屬于我們所謂的一層排程，主要解決資源管理排程問題并提供抽象的架構api，目前熟知的主要應用領域也是spark,marathan,cassandra等大資料相關的應用，每個應用接入時都要完整實作mesos的api，也就是我們所謂的二層排程，是以還是有不少開發工作在的，門檻較高；kubernetes主要用來容器排程和服務發現，沒有什麼額外的開發工作，而且對于一個需要快速bootstrap的創業公司來講，明顯kubernetes是一個更接地氣的存在。其實kubernetes和mesos是可以共存的，mesos甚至可以作為kubernetes的資源提供者，兩者解決的本來就不是同一層面的問題，應該說kubernetes解決了mesos無法解決的問題，而這些問題是更為普适的痛點。稍後來自apple的人分享了mesos的最佳實踐，尤其是對stateful和stateless的服務的差別管理可圈可點。

    amazon的人也分享了ecs（ec2

container service）的一些基本原理和實作機制，能夠讓使用者友善地管理大規模的容器叢集，并通過api的方式來自己程式設計随心所欲管理docker和其它各種資源如elb，當然其它雲廠商也有對應的服務，如阿裡雲的容器服務（container service），azure的acs等。

    今天還聽了一些其他場次，會在其它文章中分析彙總，本文主要聚焦容器和排程問題。