蘑菇街向靖：大家好，我是子騫，來自蘑菇街的運維架構(gòu)師。我們接下來會做一個 Paas 平臺，想做 Docker 和結(jié)合虛擬機以及我們用到公有云產(chǎn)品，做成一個混合云的架構(gòu)平臺。我們現(xiàn)在 Docker 也在用，更多的是當(dāng)虛擬機用，后面我們想基于 Docker 原生的方式去用，可能會涉及資源調(diào)度，服務(wù)發(fā)現(xiàn)的問題。除了 Docker，我們還會用到公有云，公有云更多是虛擬機的方式提供。出于混合云，想在資源層做一個抽象，對于上層業(yè)務(wù)來講它沒有關(guān)系，它是跑在 Docker 上，還是云主機上，還是 KVM 虛擬機上，那么我想在這上面做一個抽象。另外還有，剛才我也是提問滴滴架構(gòu)師的問題，配置怎樣和代碼做隔離，這個也是我考慮的問題。因為我看 Docker 用了環(huán)境變量，通過環(huán)境變量做一些配置的參數(shù)的傳遞，但是在虛擬機上，特別是在物理機上，通過環(huán)境變量的方式，我還在考慮有沒有安全的風(fēng)險，Docker 可能是一個只讀的，不會被修改的，但是對于虛擬機以及物理機來說，可能會存在被修改的風(fēng)險。
蘑菇街張振華：大家好，我叫張振華，花名郭嘉，我是 14 年從思科加入蘑菇街。我們算是國內(nèi)用 Docker 比較早的，我們一開始用 Docker 是 1.3.2 的版本，當(dāng)時我們采用集群管理工具還是Openstack，因為當(dāng)時 Kubernetes 還不是很成熟。當(dāng)時也走了一些彎路，比如我們把 Docker 當(dāng)成虛擬機來用，曾經(jīng)在線上的規(guī)模也達到幾百臺虛擬機幾千個容器，但是我們逐步發(fā)現(xiàn)不能把 Docker 當(dāng)成虛擬機來使用，因此我們做了一個轉(zhuǎn)型，從去年開始研究 Kubernetes，現(xiàn)在 Kubernetes 加 Docker 的版本開發(fā)完成了，準(zhǔn)備逐步上線。
我們?yōu)槭裁催x用 Kubernetes?編排工具的選擇我們也是做過一番調(diào)研的，它們沒有誰好誰不好這一說，只能說誰更貼切你的需求。對于我們蘑菇街來說，我們需要解決是資源利用率的問題，和運維的對接，我們需要有預(yù)發(fā)和線上環(huán)境的持續(xù)集成持續(xù)部署的過程，還有我們需要有對資源的隔離，對部署的快速迭代，包括集群管理，這些方面，我們覺得 Kubernetes 更加適合于我們。
在網(wǎng)絡(luò)方面，我們研究過現(xiàn)在在開源界比較常用的一些方案，但是我們都覺得不太適合，比較 Fannel，Caico 等等，他們一般用的技術(shù)都是 Vxlan，或者是用 BGP。因為我們之前對 Openstack 的網(wǎng)絡(luò)是比較有經(jīng)驗的，然后我們發(fā)現(xiàn)有一個項目，具體名字不記得，Neutron 和 Kubernetes 做一個對接，我們在這個項目的基礎(chǔ)上做了 Vlan 的方案，我們的網(wǎng)絡(luò)沒有用 Vxlan 來做，而是選擇 Vlan 來做，這樣的話一個 Docker 它可以獲得跟一個物理理同一個網(wǎng)絡(luò)平面的 IP，我們的應(yīng)用程序可以直接對外訪問，因為我們內(nèi)部業(yè)務(wù)有這個需求選擇這個方案。雖然 Docker 內(nèi)部網(wǎng)絡(luò)和外部網(wǎng)絡(luò)是通的，但 Docker 還是獨立的一個網(wǎng)段，不需要一層 NAT 的轉(zhuǎn)換。我們直接走二層的，是在交換機走 Chunk，本來物理機交換機的 Access 口，這樣的話，一臺物理機上面允許跑多個vlan的容器，比如說 A業(yè)務(wù)和 B業(yè)務(wù)要走隔離的話，通過網(wǎng)絡(luò)的 Vlan 走隔離，它們的數(shù)據(jù)之間不會有干擾。
Load Balance 我們還沒有涉及到這一塊，Load Balance 我們應(yīng)該會在 nginx 上做一層。因為據(jù)我了解，現(xiàn)在 Kubernetes 這一塊 Proxy 還不是很成熟，這上面還存在一些問題，因此還不敢用 Kubernetes 現(xiàn)有提供的服務(wù)。服務(wù)發(fā)現(xiàn)和注冊這一塊我們還在做開發(fā)，這塊會和配置管理中心打通。我們內(nèi)部也有其他團隊在做這些功能，所以我們會和內(nèi)部的中間件團隊合作。
七牛云袁曉沛：大家好，我是七牛云數(shù)據(jù)處理技術(shù)總監(jiān)袁曉沛。我們的數(shù)據(jù)處理業(yè)務(wù)包括了圖片和視頻的實時在線及異步處理。數(shù)據(jù)處理的業(yè)務(wù)量比較大，日均請求量達到百億級。平臺采用容器技術(shù)的原因是借助容器技術(shù)快速部署，啟動的特性，數(shù)據(jù)處理程序可以根據(jù)數(shù)據(jù)處理量快速地彈性伸縮。借助容器技術(shù)內(nèi)核級別的資源隔離和訪問控制，每個數(shù)據(jù)處理程序可以運行在一個私有的環(huán)境，不被其它程序所干擾，保證其上運行數(shù)據(jù)是安全可靠的。而且容器技術(shù)是輕量的，它以最小的資源損耗提供資源隔離和訪問控制，而資源特別是計算資源在數(shù)據(jù)處理中是非常寶貴的。
我們在資源調(diào)度上采用的是 Mesos，而二層的業(yè)務(wù)調(diào)度框架則是自己自研的。七牛自身擁有近千臺的物理機，容器是直接運行的物理機上，可以減少虛擬層對資源的消耗，提高資源的利用率。
在網(wǎng)絡(luò)上，對于七牛的自定義數(shù)據(jù)處理服務(wù)直接使用的是 Host 模式，而對第三方數(shù)據(jù)處理服務(wù)則使用的是 Bridge 模式，因為這些程序是用戶自己部署運行的，并不知道用戶是否有開啟其他的端口使用，所以使用的是 Bridge 模式，需要對外使用端口的都需要通過 NAT 進行暴露，這樣服務(wù)內(nèi)部使用了什么端口并不會對外界環(huán)境造成影響，對平臺環(huán)境做了非常好的安全隔離。我們是使用 Consul 做注冊中心，支持跨數(shù)據(jù)中心的服務(wù)發(fā)現(xiàn)。我們?yōu)槭裁醋匝械恼{(diào)度框架，而不用 Marathon。因為 Marathon 不支持跨數(shù)據(jù)中心的內(nèi)部服務(wù)或外部服務(wù)的發(fā)現(xiàn)，而七牛有多個數(shù)據(jù)中心，影響整體的調(diào)度，其次如果選用 Marathon 的話，根據(jù)我們業(yè)務(wù)的特點，還是要再做一層對 Marathon 的包裝才能作為 Dora 的調(diào)度服務(wù)，這樣模塊就會變多，部署運維會復(fù)雜。