來自滬江、滴滴、蘑菇街架構師的 Docker 實踐分享

架構師小組交流會是由國內知名公司架構師參與的技術交流會，每期選擇一個時下最熱門的技術話題進行實踐經驗分享。

Docker 做爲當前最具顛覆性的開源技術之一，其輕量虛擬化、可移植性是 CI/CD、DevOps、微服務的重要實現技術。但目前技術還不夠成熟，在生產實踐中還存在不少問題。對此，滬江黃凱、滴滴田智偉、蘑菇街張振華、蘑菇街向靖、扇貝丁彥以及七牛雲袁曉沛在本期交流會上分享了各自的經驗。本文是對這次交流的整理，歡迎探討。

---

自由交流

• 滬江黃凱

你們好，我是來自滬江的 Java 架構師，我叫黃凱。在加入滬江以前，曾在 HP 和 IBM 的雲計算部門擔任核心開發和架構職位。對 IaaS、PaaS、SaaS，尤爲是雲存儲有較深刻的瞭解。2015 年加入滬江，擔任架構師職位，主導的產品有：課件雲存儲，雲轉碼等等。在這些項目中，咱們使用 Mesos 和 Marathon 作 Docker 的編排工具，並開發了一個 Mesos Framework 作雲轉碼的核心框架。

那麼咱們爲何要使用 Docker，也是機緣巧合。因爲咱們的服務開始的時候不是特別多，採用的就是一種普通的架構，後來隨着服務的增多，發現部署和運維花的時間太長，咱們想使用一些新的方式。開始的時候研究過 Openstack，後來以爲 Openstack 慢慢沒落，因而咱們就選中如今使用的 Docker。咱們並不把 Docker 當成 VM 在用，而是使用它的原生的，在 Baremetal 上直接安裝 Docker，這樣運行效率比在 VM 運行 Docker 要來的快。課件雲是由不少微服務組成，不光是一些存儲，這種微服務是使用 Docker 部署，就至關於編排，把這些微服務部署上去。轉碼這一塊是使用了 Mesos 框架，和 Docker 沒有特別大的關係，可是轉碼的應用程序，好比說咱們如今應用 FFmpeg，這個程序是運行在 Docker 裏面的。

爲何要選擇 Marathon？第一，我以爲 Mesos＋Marathon 很是的容易理解。咱們也研究過 Kubernetes 和其餘的一些方法，發現從運維和研究的方面來講的話，Kubernetes 實在是過重並且太複雜，後來選擇了Marathon。咱們如今是內部服務使用，兩個部門在使用轉碼集羣，大概是 Baremetal 有 20 臺的物理機。除去咱們 API 的一些服務，還有一些第三方組件的服務的話，大概是有 400 多個 Docker 容器在跑。

• 滴滴田智偉

你們好，我是滴滴代駕事業部架構師，代駕事業部是公司最先嚐試 Docker 虛擬化的事業部。目前主要方向是業務系統及部分中間件的 Docker 化，咱們作的時間也不太長，半年多的時間。線上是由於咱們有老的一套發佈系統，集成涉及的部門比較多，因此咱們基於原來的發佈系統完成了預發佈環境 Docker 的部署。線下環境基於 Docker+K8s 開發內部的自動化持續交付系統及開發測試環境管理。咱們在作開發和測試環境的自動化，另外一方面也是作環境管理的，兩套環境。對於項目並行的時候發現原來不少不夠用，原來不少配置是基於端口綁死的狀況。如今基於開發 Kubernetes 的話，網絡隔離用了一部分，而後主要是用環境變量這一部分，主要考慮是解決一個配置能夠應用到在多個環境的狀況，基於這個需求才用它。開發 Kubernetes 基於 Namespace，同一個服務在不一樣的 Namespace 下，它其實環境變量名能夠是相同的，可是IP不一樣，而這一部分 IP 實際上是由開發 Kubernetes 本身去管理的。基於環境變量獲取一些配置的話，好比 IP 地址這種，就能夠作到拿一份配置能夠打出多套環境。

考慮業務的安全性和穩定性，線上基於純 Docker 的方式在作。咱們是基於裸的 Docker 來工做，主要是用資源隔離，沒有藉助調度框架，也沒有自動伸縮。咱們是兩步走，一步是驗證 Docker，其次是作開發 Kubernetes 線下使用和預研。爲何沒有考慮 Mesos？剛纔跟滬江的同窗，咱們的考慮是相反的。Mesos 側重點更專注一點，首先不會有模塊的劃分，好比 Kubernetes 有 Replication controller ，Namespace 這種概念，而 Mesos 下幾乎沒有這種概念。咱們拿 Kubernetes 主要是作一些編排的功能，而正好開發 Kubernetes 在整個發佈和編排上，體系更全面一點。Mesos 最先是作資源管理，基於 Docker 作一個 Framework 接進來的話，它不是專門爲編排而生。Kubernetes 首先解決咱們的問題是，咱們可能不須要加多份配置就能夠搭多套不一樣的環境，它就是基於 Namespace 作一個多租戶的概念，會對 Service 作一層隔離，對於動態配置，擴容這一部分暫時咱們沒用到，確實用到的一些場景比較少。主要是作不一樣環境的隔離，並無太多使用編排細節上的東西，動態伸縮之類的目前線下沒有太大必要，線上可能會用到。

• 蘑菇街向靖

你們好，我是向靖，來自蘑菇街的運維架構師。咱們接下來會作一個 PaaS 平臺，想作 Docker 和結合虛擬機以及咱們用到公有云產品，作成一個混合雲的架構平臺。咱們如今 Docker 也在用，更多的是當虛擬機用，後面咱們想基於 Docker 原生的方式去用，可能會涉及資源調度，服務發現的問題。除了 Docker，咱們還會用到公有云，公有云更可能是虛擬機的方式提供。出於混合雲，想在資源層作一個抽象，對於上層業務來說它沒有關係，它是跑在 Docker 上，仍是雲主機上，仍是 KVM 虛擬機上，那麼我想在這上面作一個抽象。另外還有，剛纔我也是提問滴滴架構師的問題，配置怎樣和代碼作隔離，這個也是我考慮的問題。由於我看 Docker 用了環境變量，經過環境變量作一些配置的參數的傳遞，可是在虛擬機上，特別是在物理機上，經過環境變量的方式，我還在考慮有沒有安全的風險，Docker 多是一個只讀的，不會被修改的，可是對於虛擬機以及物理機來講，可能會存在被修改的風險。

• 蘑菇街張振華

你們好，我叫張振華，花名郭嘉，我是 14 年從思科加入蘑菇街。咱們算是國內用 Docker 比較早的，咱們一開始用 Docker 是 1.3.2 的版本，當時咱們採用集羣管理工具仍是 Openstack，由於當時 Kubernetes 還不是很成熟。當時也走了一些彎路，好比咱們把 Docker 當成虛擬機來用，曾經在線上的規模也達到幾百臺虛擬機幾千個容器，可是咱們逐步發現不能把 Docker 當成虛擬機來使用，所以咱們作了一個轉型，從去年開始研究 Kubernetes，如今 Kubernetes 加 Docker 的版本開發完成了，準備逐步上線。

咱們爲何選用 Kubernetes？編排工具的選擇咱們也是作過一番調研的，它們沒有誰好誰很差這一說，只能說誰更貼切你的需求。對於咱們蘑菇街來講，咱們須要解決是資源利用率的問題，和運維的對接，咱們須要有預發和線上環境的持續集成持續部署的過程，還有咱們須要有對資源的隔離，對部署的快速迭代，包括集羣管理，這些方面，咱們以爲 Kubernetes 更加適合於咱們。

在網絡方面，咱們研究過如今在開源界比較經常使用的一些方案，可是咱們都以爲不太適合，比較 Fannel，Caico 等等，他們通常用的技術都是 VXLAN，或者是用 BGP。由於咱們以前對 Openstack 的網絡是比較有經驗的，而後咱們發現有一個項目，具體名字不記得，Neutron 和 Kubernetes 作一個對接，咱們在這個項目的基礎上作了 VLAN 的方案，咱們的網絡沒有用 VXLAN 來作，而是選擇 VLAN 來作，這樣的話一個 Docker 它能夠得到跟一個物理理同一個網絡平面的 IP，咱們的應用程序能夠直接對外訪問，由於咱們內部業務有這個需求選擇這個方案。雖然 Docker 內部網絡和外部網絡是通的，但 Docker 仍是獨立的一個網段，不須要一層 NAT 的轉換。咱們直接走二層的，是在交換機走 Chunk，原本物理機交換機的 Access 口，這樣的話，一臺物理機上面容許跑多個 VLAN 的容器，好比說 A 業務和 B 業務要走隔離的話，經過網絡的 VLAN 走隔離，它們的數據之間不會有干擾。

Load Balance 咱們尚未涉及到這一塊，Load Balance 咱們應該會在 nginx 上作一層。由於據我瞭解，如今 Kubernetes 這一塊 Proxy 還不是很成熟，這上面還存在一些問題，所以還不敢用 Kubernetes 現有提供的服務。服務發現和註冊這一塊咱們還在作開發，這塊會和配置管理中心打通。咱們內部也有其餘團隊在作這些功能，因此咱們會和內部的中間件團隊合做。

• 七牛雲袁曉沛

你們好，我是七牛雲數據處理技術總監袁曉沛。咱們的數據處理業務包括了圖片和視頻的實時在線及異步處理。數據處理的業務量比較大，日均請求量達到百億級。平臺採用容器技術的緣由是藉助容器技術快速部署，啓動的特性，數據處理程序能夠根據數據處理量快速地彈性伸縮。藉助容器技術內核級別的資源隔離和訪問控制，每一個數據處理程序能夠運行在一個私有的環境，不被其它程序所幹擾，保證其上運行數據是安全可靠的。並且容器技術是輕量的，它以最小的資源損耗提供資源隔離和訪問控制，而資源特別是計算資源在數據處理中是很是寶貴的。

咱們在資源調度上採用的是 Mesos，而二層的業務調度框架則是本身自研的。七牛自身擁有近千臺的物理機，容器是直接運行的物理機上，能夠減小虛擬層對資源的消耗，提升資源的利用率。

在網絡上，對於七牛的自定義數據處理服務直接使用的是 Host 模式，而對第三方數據處理服務則使用的是 Bridge 模式，由於這些程序是用戶本身部署運行的，並不知道用戶是否有開啓其餘的端口使用，因此使用的是 Bridge 模式，須要對外使用端口的都須要經過 NAT 進行暴露，這樣服務內部使用了什麼端口並不會對外界環境形成影響，對平臺環境作了很是好的安全隔離。咱們是使用 Consul 作註冊中心，支持跨數據中心的服務發現。咱們爲何自研的調度框架，而不用 Marathon。由於 Marathon 不支持跨數據中心的內部服務或外部服務的發現，而七牛有多個數據中心，影響總體的調度，其次若是選用 Marathon 的話，根據咱們業務的特色，仍是要再作一層對 Marathon 的包裝才能做爲 Dora 的調度服務，這樣模塊就會變多，部署運維會複雜。

• 扇貝丁彥

你們好，我是扇貝的技術總監丁彥，以前在暴走漫畫，前後在暴走漫畫和扇貝設計和主導了基於 Docker 的微服務架構系統，以及數據收集和分析系統。去年來到扇貝，這裏是 Python 的開發環境。後來發現業務增加快，水平擴展一些機器，出現問題須要換個機器等等，都須要很是熟悉業務的少數開發去作。另外公司對預算控制嚴格，機器基本都是滿負荷運做，平時也不可能多開空置的機器，已有的機器還要根據負載狀況調整服務分佈狀況，因此這種切換服務，增刪服務的操做仍是比較頻繁的。所以，咱們用了 2-3 個月的時間將全部的運行環境都切換到 Docker上，這大大提升了咱們的運維能力。

Docker 包裝有幾個好處。

第一個好處是，環境升級很是方便。由於只要pull 一下最新的鏡像，啓動一個 Container，環境就升級了。而若是直接基於公有云的鏡像升級的話就很難，由於一臺機器上跑哪些服務其實不必定是固定的，而且以前作的鏡像只要有一臺機器是還基於它的話，就刪除不掉的，鏡像數量又有上限。因此 Docker 很是好地解決了咱們的問題。

其次是環境的顆粒度會更小，一臺機器上配好幾個應用的話，每每配着配着，到最後你就不太能精確地記得上面裝的程序或者庫是給哪一個應用服務的，應用之間若是依賴有版本的衝突也很難調和。你想作些服務的遷移，把負載比較小的放一塊兒，把負載比較大的抽出來，這個時候就很是痛苦，但你若是用 Docker 包裝後就很是簡單，只要在不一樣的機器上起不一樣的 Container，就能夠實現這一點。

第三，咱們不光用了 Docker，還加入了服務發現，剛剛討論配置管理這些，咱們一併作了。Docker 啓動時候，咱們本身寫了一些工具，能夠自定義 Docker 啓動參數，包括配置參數，好比說，一些程序要運行的參數，咱們主要用兩種方式，一種方式是經過環境變量灌進去，還有一種方式讓程序的啓動腳本支持參數，而後拼接不一樣的參數灌進去，最終都是落實到 Docker 的啓動命令上。服務發現是基於 Consul，Docker 的啓動命令是從 Consul 裏取的。首先 Consul有 HTTP 的 API，咱們是本身寫的 pip 包，只要 Include 一下這個包就能夠了，Docker 的服務啓動後會自動註冊到 Consul。好比要在負載後加一個服務，只須要找到一臺機器，啓動對應的 container，剩下的事情它本身會到 Consul，註冊它的參數地址一系列東西，自動把它加進去。因此這些都是自動化的，若是檢測那臺機器/服務掛了，Health Check 也會到 Consul 裏面更新。該增長機器就增長機器，該下線就下線。整體來講，咱們的生產環境所有跑在 Docker 上面的，而後區分有狀態和無狀態兩種，有狀態的定死在機器上，無狀態的靈活的自由切換。還有一點，若是是有狀態的容器要定死在機器上的時候，咱們通常來講都會採起冗餘的結構，至少保證有兩個在運行，一個掛了，保證總體的服務在運行。其次基於 Docker，咱們還作了一套數據蒐集以及分析的機制。數據蒐集是基於日誌來蒐集的，利用 Docker 的 Log driver，把日誌打到 Filter，把結果存在存儲服務上。同時監控也是基於日誌作的。第三部分非生產環境，好比開發環境跟測試環境都是 Docker 作的，由於咱們每個服務都作了 Image、鏡像，用容器方式跑的。經過參數來決定啓動方式的，咱們能夠在開發環境以及測試環境採用不一樣的參數來啓動容器。 經過 Consul 來隔離的，由於 Consul 的服務發現，開發、生產、測試環境在不一樣的自動發現框架裏不會相互影響到。目前機器在 120 臺左右，基於雲服務。有些基礎的東西不須要依賴於 Docker，好比說申請雲主機，申請的時候就能夠指定它的 CPU 和內存這些服務器資源的配置。因此這部分東西仍是屬於 Human schedule，不是徹底讓編排的系統本身決定該怎麼樣。

編排工具咱們如今在研究進一步，我剛來這工做的時候，全部的服務沒有一個跑在 Docker 上面的，我如今把它遷進來。如今數據增加，已經有一些編排的瓶頸，如今在作調研，可能基於 Swarm，作自動編排的設計。

---

指定話題交流

主持人：容器多的狀況下 Kubernetes 存在性能問題，各位在這方面有沒有好的經驗？

扇貝丁彥：咱們其實也遇到了這個問題，找不到辦法因此放棄了 Kubernetes。咱們也是用公有云，網絡直接依賴公有云的網絡，有多是由於公有云形成的，我沒有試過在祼機上試過。

滬江黃凱：Kuberneters 的 Fannel 有一種模式是 VXLAN，它的封裝摺包是作內核裏作的，效率會高一點。容器多就會效率會低是由於，在 Kubernetes 1.2 的時候，走這樣的一種模式，數據先到內核態中，而後把數據拉回到用戶態，用  Proxy 的方式分發給各個容器當中的。其實在 Kubernetes 1.3 之後，它直接在iptables裏設規則，至關於用戶數據不用跑到用戶態，在內核直接分發出去了，這種效率會很是高。因此能夠研究一下 Kubernetes 新版本。

扇貝丁彥：咱們碰到過網絡方面的問題。默認的 Docker engine 的啓動參數裏面有個 iptables，不知道你們有沒有定製化過，若是不定製化這個參數，它默認會幫你建 iptables 的轉發規則，並會開啓內核的網絡追蹤的模塊。一開始咱們沒有注意這件事情，當咱們的 Nginx 遷到 Docker 的時候，Nginx 服務瞬間會掛。後來查緣由，是由於這些參數會開啓網絡追蹤模塊。由於咱們的 Nginx 流量很是大，當時只有 3 臺 Linux 雲主機，分發 http 請求的，而後會致使 3 臺Linux宿主機，內存會被刷破，網絡會出現堵塞。因此咱們關掉了 iptables 參數，並採用 Host 的網絡模型。因此它的容器拿到的 IP 就是 Host 的 IP。咱們一開始也想上一些 Kubernetes 這些東西，而後發現簡單跑個模型根本跑不起來，因此一開始就放棄了這一套東西，直接搞了個裸的 Docker。

主持人：關於跨數據中心容器集羣的使用，你們有經驗麼？

滬江黃凱：咱們跨數據中心主要是IP分配上的問題，咱們如今也在嘗試使用 Calico，若是 Host 網絡是通的話，那麼它的內部網絡也就通了，能夠自由劃 VLAN，這樣你就能夠解決跨 Data center 的問題。還有一個問題就在跨 Data center 時，服務註冊與發現的問題。這個問題也困擾咱們好久了，咱們如今使用 Consul 作服務註冊與發現。雖然 Consul 它是官方支持跨 Data center，可是咱們在使用當中的話會發現註冊的 IP，在另一個註冊中心，它會發現的比較慢，甚至有時候出現 IP 衝突的時候。

咱們的作法是把 Host 的 IP 地址直接用 Environment 的形式注到 Docker 鏡像內部，接下 來 Docker 鏡像要註冊，它就會讀取 App 的 IP，而後發送給 Consul，只要保證 Host 的 IP 和 Docker內部容器的 IP 可以互通的就好了。若是不能通的話，好比說徹底和 Host IP 隔離，那麼起碼有幾臺機器要暴露出去，又好比說，Consul 它自己本身要暴露出去才能訪問到。Host 的 IP 是容器啓動以後注進去的，啓動命令中把 Host 的 IP 地址加在 -e 的後面，容器在啓動以後，它的環境就會有這麼一個 IP。咱們用 Mesos 就沒這個問題，可是用 Kubernetes 就有這個問題。Mesos 會自動幫你把這些東西注入容器中去。

滴滴田智偉：其實 Kubernetes 自己也是能夠解決這個問題，咱們如今在作線下持續交付的時候。定義完 Service 以後，容器會同一個 Namespace 默認加一個系統環境變量。

滬江黃凱：咱們試過，在 Pod 啓動以後，Pod 裏容器想訪問 host 的 IP 地址，是沒有辦法作到的。 

蘑菇街張振華：由於咱們以前也遇到這個問題，而後咱們業務方，他們可能有一些程序會獲取本機 IP 地址，若是是內部的 IP 地址，他們程序可能會出現問題，因而咱們當時沒有用 Docker 默認的網絡，而是採用 VLAN。

主持人：咱們提到好多 Mesos、Kubernetes、網絡，發現沒有提自動伸縮，有沒有項目涉及到容器的自動伸縮？

滬江黃凱：咱們滬江是基於 Mesos+Marathon 作了本身的一個服務，它這個服務是幹嗎的呢，就是監測，不停的監測每個 Docker 的 CPU 和內存的利用率，一旦超過百分之多少之後，就向 Marathon 發一個命令，說我要擴容，它還能夠支持時間點，好比 15 分鐘監測一次，若是在 15 分鐘發現它超過閾值了，就立刻擴容出來，可是縮的話，不是適用於頻繁監控，若是小於 20% 的話就會縮，一旦縮的話會影響線上用戶的請求。怎麼辦呢？咱們在縮的時候能夠規定它的時間點，好比半夜裏 2-3 點，訪問量少於多少點時候把它縮掉。咱們監測的是 Docker 內部的 CPU 的使用率。就是監測一個服務，它能夠監控全部同一服務的 Container，好比一個服務有 100 個容器，那麼這一百多個 CPU 利用率加起來除於一百，至關於平均的利用率。若是平均利用率超過 80%了，那說明這個集羣到了擴展程度了，它會以一種比例來擴展。針對單個容器，能夠設置內存的限制。咱們給每個容器呢，好比它只能用 4 個 CPU，只能用 8G 的內存，或者更小一點的內存，這些都設好，設好以後它自動擴展相同規格的容器。這麼作是由於 Cgroup 有個問題，當利用率到達了啓動的限制，Cgroup 會把這個容器 kill 掉。這個是不可理喻的問題，因此咱們想到用 Load scale 來擴容，不讓他直接死掉。

滴滴田志偉：關於自動擴容，咱們線下的時候遇到一個問題，咱們最先的時候是用騰訊的公有云，它限制了 NET 的模塊，致使咱們最初用 Cgroup 的方案去作，綁定端口。內部使用全部應用，端口是要作分配的，要否則出現端口衝突。而後遇到問題是，在這種狀況下，若是要作動態擴容的話，它每次先建立一個，再殺掉一個，致使每次起來的時候就起不來了，由於端口的問題。服務啓動的時候端口是隨機，會出現衝突問題，由於用的是 Host 的模式。

主持人：關於自動伸縮爲何沒有考慮到請求數？由於若是內存佔用率若是超過必定預支，那麼請求數也可能超過必定預支了。把單個容器所處理的請求數給限定了，那麼它內存天然不會超，而後也不會被幹掉。

滬江黃凱：我我的認爲，第一，請求數很難測，你不知道請求數到多少時要擴容，還不如根據 CPU 到 80%，或者 90% 來的直觀。咱們的 API 也是根據 CPU 來算的。你真正是高併發的 API 的話，我也測過，最後咱們可以監測到的，其實仍是 CPU 和內存。

扇貝丁彥：咱們擴容是根據響應時間，跟請求數相似，請求數定指標不太好定，咱們是根據響應時間，好比平時的響應時間是 50 毫秒，當響應時間是 300 毫秒的時候就要擴容了。

主持人：關於自動伸縮爲何沒有考慮到請求數？由於若是內存佔用率若是超過必定預支，那麼請求數也可能超過必定預支了。把單個容器所處理的請求數給限定了，那麼它內存天然不會超，而後也不會被幹掉。

滬江黃凱：關於存儲，咱們是有一些研究的。如今容器存儲問題分爲兩種，Kubernetes 官方支持一種理念，任何一種存儲都是一個 Volume。Volume 先於 Docker 存在的，而不是 Docker 啓動以後再掛載 Volume。無論是網絡存儲仍是本地存儲，所有以卷的形式，掛載在 Pod 裏面或者是宿主機上,以 Driver mapper 來驅動這個 Volume，來讀到你所要的內容。

還有一種狀況，就是 Docker 公司主導的存儲模型，任何的存儲都是一種驅動。若是你想用 NFS 或者如 Ceph 這樣分佈式存儲的話，讓 Ceph 開發 Docker 的驅動，Docker run 的時候指定存儲的驅動，Docker storage driver 這種方式，外部的存儲在容器內部它展示形式能夠是目錄，也能夠是掛載卷、塊的形式。若是用塊掛載到容器中，這個容器本身格式化它，或直接讀取它都是能夠的。它只不過它是至關於用了一個 Driver 的形式，把你的容器和分佈式存儲創建一個鏈接而已。對於容器，若是本來綁定塊或 Volume，容器出現故障的話，直接把容器殺掉，再啓動掛在一樣一個 塊或Volume 就解決了。優勢是直接讀取，而不是經過再轉一層，效率比較高一點。全部存儲都是 Volume 的形式理解度比較高一點，因此咱們仍是贊同於用 Volume 的形式。

有狀態的容器。我知道 k8s 的新的計劃，若是你沒有用 Kubernetes 最新版本的話，通常來講咱們都是容器啓動在固定 Host 上，下次啓動仍是在這臺 Host 上，它的存儲它的內存，包括一些 log，所有是在這臺 Host 上。還有一種是用最新的版本，有個 PetSet 的新 kind，Kubernetes 它本身會記錄 Pod 在什麼 Host 上啓動過，不用本身去指定必定要在某一臺 Host 上啓動，這種方法比較智能化，可是不是特別穩定的一種方法，由於它是剛剛開發出來的新功能。

主持人：關於自動伸縮爲何沒有考慮到請求數？由於若是內存佔用率若是超過必定預支，那麼請求數也可能超過必定預支了。把單個容器所處理的請求數給限定了，那麼它內存天然不會超，而後也不會被幹掉。

滬江黃凱：我我的認爲仍是在同一臺機器上起一個新的實例，不要讓它作數據遷移，由於數據遷移會佔用不少資源。並且若是你的想法是說，全部的分佈式的存儲只是以 Volume 的形式掛載在宿主同上，這也就沒什麼問題了。由於存儲和 Docker 是徹底分開來的。若是隻有一個 Volume，存儲的可靠性會得不到保障，因此在 Kubernetes 新版本當中，它會創建一個 Volume 的 kind，也至關於創建 RC kind同樣，是一個 Pod，那這樣由 Kubernetes 來保障這個 Volume 的高可用。