摘要容器技術的無狀態特性與臨時存儲模型導致容器實例銷毀時內部數據隨之丟失且宿主機與容器之間缺乏高效的文件交互機制。Docker 數據卷Data Volume機制通過將宿主機文件系統目錄掛載至容器內部命名空間實現了容器數據的持久化存儲、宿主機與容器間的雙向數據同步以及多容器間的共享訪問。本文系統闡述了 Docker 數據卷的形式化定義與分類體系深入剖析了綁定掛載Bind Mount、命名卷Named Volume及匿名卷Anonymous Volume三種掛載模式的語義差異與適用場景在此基礎上論述了數據卷容器Volume Container的繼承機制與生命周期解耦原理并探討了該機制在現代容器編排體系中的演進方向。研究表明合理選擇數據卷類型與掛載策略是構建有狀態容器應用與實現跨容器數據協同的關鍵。關鍵詞Docker數據卷容器持久化綁定掛載命名空間聯合文件系統多容器共享1. 引言在 Docker 容器技術的默認存儲模型中容器內部文件系統的讀寫操作發生于聯合文件系統Union File System的可寫層Writable Layer之上。該層與容器生命周期強耦合——當容器被刪除時可寫層隨之被垃圾回收內部生成的數據將全部丟失 [1]。這一特性對于無狀態應用Stateless Application而言尚可接受但對于數據庫、文件服務器等有狀態服務Stateful Service則構成了嚴重的數據持久化風險。與此同時容器與宿主機之間、容器與容器之間默認處于獨立的命名空間Namespace隔離環境中直接文件傳輸與數據互通存在顯著障礙。以 MySQL 容器為例若在容器內部寫入業務數據數據以文件形式存儲于容器的可寫層中一旦容器因故障被刪除并重建此前寫入的數據將無法恢復進而導致業務連續性中斷。為解決上述存儲持久化與跨實體數據交互問題Docker 引入了數據卷Data Volume機制。數據卷本質上是宿主機文件系統中的目錄或文件通過內核的綁定掛載Bind Mount技術映射至容器內部的指定掛載點Mount Point從而繞過聯合文件系統的可寫層直接在宿主機持久化存儲上執行 I/O 操作 [2]。本文旨在系統梳理 Docker 數據卷的概念定義、配置語義、多容器共享機制及其在現代容器編排環境中的演進。2. Docker 存儲機制與數據卷概念2.1 容器文件系統的臨時性Docker 鏡像由多個只讀層Read-Only Layers疊加而成容器運行時在其之上添加一個可寫層。該可寫層與容器生命周期綁定容器刪除時可寫層隨之銷毀內部生成的數據無法保留。這一特性決定了容器天然適合運行無狀態應用但對于數據庫、文件服務等有狀態場景必須引入外部持久化存儲。2.2 核心概念定義1數據卷Docker 數據卷是獨立于容器聯合文件系統Union File System的持久化存儲區域其本質是在宿主機上開辟的專用存儲空間通過與容器內目錄建立掛載綁定關系實現數據的持久化存儲與跨邊界訪問。掛載完成后宿主機目錄與容器內目錄構成雙向實時同步通道任意一端的文件變更均會即時映射至另一端。數據卷機制解決了容器技術的三大核心痛點數據持久化容器實例銷毀時聯合文件系統的可寫層被回收但宿主機上的數據卷目錄不受影響數據可長久留存宿主機與容器的數據交互外部文件可通過宿主機數據卷目錄中轉自動映射至容器內部實現二者的雙向數據互通多容器數據共享同一個宿主機數據卷可同時掛載至多個容器實例實現跨容器的數據共享與協同處理。2.3 類型辨析依據掛載源Source的性質與聲明方式Docker 數據卷可劃分為以下三類類型聲明方式掛載源位置生命周期管理適用場景綁定掛載Bind Mount-v /host/path:/container/path宿主機任意絕對路徑由宿主機文件系統管理Docker 不直接控制開發環境代碼熱更新、配置文件注入命名卷Named Volume-v volume-name:/container/pathDocker 管理的專用存儲目錄通常為/var/lib/docker/volumes/由 Docker Daemon 集中管理可顯式刪除生產環境數據持久化、數據庫文件存儲匿名卷Anonymous Volume-v /container/pathDocker 自動生成的存儲目錄隨容器創建而生成容器刪除后變為懸空卷Dangling臨時緩存、無需長期保留的中間數據綁定掛載直接映射宿主機已有目錄靈活性最高但路徑依賴宿主機文件系統結構可移植性較差。命名卷由 Docker 統一分配與管理具備顯式命名、備份遷移及跨容器復用的優勢是生產環境中的首選方案。匿名卷在僅指定容器內路徑時由引擎自動創建適用于無需人工干預生命周期的臨時存儲場景。3. 數據卷的配置與實驗3.1 基礎語法在創建并啟動容器時通過docker run命令的-v或--volume參數完成數據卷掛載其通用語法結構為dockerrun-v掛載源:容器內目標路徑[:選項]其他參數 鏡像名其中掛載源可以是宿主機絕對路徑綁定掛載、卷名稱命名卷或省略匿名卷選項包括ro只讀等訪問控制標志。操作規范路徑必須使用絕對路徑宿主機與容器側的目錄或文件均需填寫絕對路徑不能使用./或../等相對路徑目錄自動創建若指定的宿主機目錄已存在則直接掛載若容器內的目標目錄不存在Docker 會在容器文件系統中自動創建該目錄無需手動預先新建支持多數據卷掛載單個容器可同時掛載多個數據卷每組-v參數對應一個獨立的掛載點通過重復添加-v配置實現多路徑映射。3.2 綁定掛載實驗宿主機-容器數據同步實驗目的驗證宿主機目錄與容器內目錄的雙向實時同步特性。實驗環境macOS Docker Desktop。實驗步驟創建容器 c1將宿主機目錄掛載至容器內 /root/docker_data_containerdockerrun-d-v/host/data:/app/data mysql:8.0注意事項在 macOS 的 Docker Desktop 環境中綁定掛載受安全策略限制并非宿主機上任意目錄均可直接掛載。若目標目錄未加入 Docker 的文件共享白名單Settings → Resources → File Sharing將觸發 Mounts denied 錯誤。此限制僅針對綁定掛載命名卷不受此約束。在宿主機掛載目錄中創建文件 huey_docker.txt觀察容器內 /root/docker_data_container 目錄文件已同步出現。在容器內該目錄下創建文件 huey_docker_container.txt觀察宿主機對應目錄文件亦同步出現。3.3 數據持久化實驗實驗目的驗證容器刪除后掛載數據是否得以保留。實驗步驟刪除容器 c1docker rm c1。檢查宿主機掛載目錄 /Users/anphia/Documents/my-projects/docker-study/docker_data此前創建的文件仍然存在未被刪除。創建新容器 c2掛載同一宿主機目錄檢查容器 c2 內掛載點歷史數據完整恢復。實驗結論綁定掛載將數據存儲于宿主機文件系統中容器銷毀不影響宿主機數據實現了數據持久化。3.4 多目錄掛載實驗實驗目的驗證單個容器同時掛載多個獨立存儲實體的可行性。實驗步驟創建容器 c3同時掛載兩個獨立的宿主機目錄dockerrun-it--namec3\-v/Users/anphia/Documents/my-projects/docker-study/c3_host_data1:/root/c3_container_data1\-v/Users/anphia/Documents/my-projects/docker-study/c3_host_data2:/root/c3_container_data2\centos:7實驗結論單個容器支持將內部多個目錄分別掛載至不同的宿主機目錄實現細粒度的存儲隔離與管理。4.5 跨容器共享實驗實驗目的驗證多個容器掛載同一宿主機目錄時的數據共享特性。實驗步驟分別創建容器 c4 和 c5并且這兩個容器共享同一個宿主機的數據卷目錄。在其中一個容器寫入數據觀察到另一個容器可以讀取到達到數據共享的目的。分別創建容器 c4 和 c5二者掛載同一宿主機目錄dockerrun-it--namec4-v/Users/anphia/.../shared:/root/shared centos:7dockerrun-it--namec5-v/Users/anphia/.../shared:/root/shared centos:7在容器 c4 的共享目錄中寫入數據。在容器 c5 中讀取該數據。實驗結論多個容器通過綁定掛載共享同一宿主機目錄時任一容器的寫操作對其他容器立即可見實現了跨容器數據共享。5. 數據卷容器機制5.1 設計動機當容器數量較多時直接掛載方案要求每個容器均通過 -v 參數重復指定相同的宿主機目錄配置冗余度高維護成本顯著增加。為簡化大規模容器集群的數據共享部署Docker 引入了數據卷容器Data Volume Container機制。5.2 概念與工作原理數據卷容器本質上是一個普通容器實例其核心作用并非運行業務邏輯而是作為掛載配置的模板與代理。其他業務容器通過 --volumes-from 參數繼承該容器的所有掛載配置從而自動共享同一套存儲實體。如圖 1 所示創建數據卷容器 c3 并掛載數據卷業務容器 c1 和 c2 通過 --volumes-from c3 繼承掛載關系。此時 c1、c2、c3 均掛載至同一底層存儲實體。數據卷容器的核心特性在于掛載配置繼承與生命周期解耦配置繼承--volumes-from繼承的是掛載配置Mount Configuration而非文件數據的物理復制。繼承容器與數據卷容器共享同一宿主機目錄的讀寫視圖生命周期解耦數據實際存儲于宿主機數據卷中與數據卷容器本身解耦。即使數據卷容器被停止或刪除只要數據卷在宿主機上仍然存在其他繼承該配置的容器依然可以正常讀寫共享數據。數據卷容器既可使用匿名卷亦可使用命名卷或綁定掛載–volumes-from 對上述類型均有效。數據卷容器方案屬于 Docker 早期設計模式。在現代生產環境中Docker Compose 或 Kubernetes 等編排工具已提供更優雅的聲明式數據共享方案。5.3 操作流程與驗證創建數據卷容器 c6使用匿名卷dockerrun-it--namec6-v/volume centos:7 /bin/bash創建業務容器 c7 和 c8繼承 c6 的掛載配置dockerrun-it--namec7 --volumes-from c6 centos:7 /bin/bashdockerrun-it--namec8 --volumes-from c6 centos:7 /bin/bash在容器 c7 的 /volume 目錄下創建文件觀察 c6 和 c8文件均同步可見。通過 docker inspect c6 查看 Mounts 字段可獲取匿名卷在宿主機上的真實路徑Source及容器內掛載點Destination。實驗結論數據卷容器通過配置繼承機制實現了多容器對同一存儲實體的高效共享且數據卷容器的生命周期不影響業務容器的數據訪問。6 現代演進從數據卷容器到編排工具數據卷容器機制在早期 Docker 版本中廣泛應用于多容器數據共享場景。然而隨著容器編排技術的發展現代生產環境更傾向于使用Docker Compose或Kubernetes等工具統一管理數據卷聲明與掛載關系。例如Docker Compose 通過頂層volumes字段聲明命名卷并在各服務的volumes配置中直接引用實現了更清晰的配置集中化與版本可控性。盡管如此數據卷容器作為理解 Docker 掛載繼承原理的基礎機制在容器存儲語義的教學與面試考察中仍具重要價值。7. 結論本文系統分析了 Docker 容器默認存儲模型的局限性闡述了數據卷機制的形式化定義與分類體系深入探討了綁定掛載、命名卷及匿名卷的配置語義與適用邊界。在此基礎上本文詳細論述了數據卷容器的掛載繼承機制與生命周期解耦原理并結合底層內核實現說明了數據卷如何繞過聯合文件系統以實現持久化 I/O。研究表明數據卷是構建有狀態容器應用的核心基礎設施而命名卷與現代化編排工具的結合已成為生產環境中管理容器持久化存儲的主流實踐。未來研究可進一步關注容器存儲接口Container Storage Interface, CSI在 Kubernetes 生態中的標準化演進以及分布式存儲后端如 Ceph、NFS與容器卷驅動的深度集成方案。參考文獻[1] MERKEL D. Docker: Lightweight Linux Containers for Consistent Development and Deployment[J]. Linux Journal, 2014, 2014(239): 2.[2] NICKOLoff J. Docker in Action[M]. Shelter Island: Manning Publications, 2016: 105-128.[3] FELTER W, FERREIRA A, RAJAMONY R, et al. An Updated Performance Comparison of Virtual Machines and Linux Containers[C]//2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, 2015: 171-172.[4] TURNBULL J. The Docker Book: Containerization is the New Virtualization[M]. James Turnbull, 2014.[5] MATHIEU R, BURNS B, BEDA J, et al. Kubernetes: Up and Running[M]. Sebastopol: O’Reilly Media, 2017. Docker 容器數據卷機制：持久化存儲、掛載語義與多容器共享策略
摘要容器技術的無狀態特性與臨時存儲模型導致容器實例銷毀時內部數據隨之丟失且宿主機與容器之間缺乏高效的文件交互機制。Docker 數據卷Data Volume機制通過將宿主機文件系統目錄掛載至容器內部命名空間實現了容器數據的持久化存儲、宿主機與容器間的雙向數據同步以及多容器間的共享訪問。本文系統闡述了 Docker 數據卷的形式化定義與分類體系深入剖析了綁定掛載Bind Mount、命名卷Named Volume及匿名卷Anonymous Volume三種掛載模式的語義差異與適用場景在此基礎上論述了數據卷容器Volume Container的繼承機制與生命周期解耦原理并探討了該機制在現代容器編排體系中的演進方向。研究表明合理選擇數據卷類型與掛載策略是構建有狀態容器應用與實現跨容器數據協同的關鍵。關鍵詞Docker數據卷容器持久化綁定掛載命名空間聯合文件系統多容器共享1. 引言在 Docker 容器技術的默認存儲模型中容器內部文件系統的讀寫操作發生于聯合文件系統Union File System的可寫層Writable Layer之上。該層與容器生命周期強耦合——當容器被刪除時可寫層隨之被垃圾回收內部生成的數據將全部丟失 [1]。這一特性對于無狀態應用Stateless Application而言尚可接受但對于數據庫、文件服務器等有狀態服務Stateful Service則構成了嚴重的數據持久化風險。與此同時容器與宿主機之間、容器與容器之間默認處于獨立的命名空間Namespace隔離環境中直接文件傳輸與數據互通存在顯著障礙。以 MySQL 容器為例若在容器內部寫入業務數據數據以文件形式存儲于容器的可寫層中一旦容器因故障被刪除并重建此前寫入的數據將無法恢復進而導致業務連續性中斷。為解決上述存儲持久化與跨實體數據交互問題Docker 引入了數據卷Data Volume機制。數據卷本質上是宿主機文件系統中的目錄或文件通過內核的綁定掛載Bind Mount技術映射至容器內部的指定掛載點Mount Point從而繞過聯合文件系統的可寫層直接在宿主機持久化存儲上執行 I/O 操作 [2]。本文旨在系統梳理 Docker 數據卷的概念定義、配置語義、多容器共享機制及其在現代容器編排環境中的演進。2. Docker 存儲機制與數據卷概念2.1 容器文件系統的臨時性Docker 鏡像由多個只讀層Read-Only Layers疊加而成容器運行時在其之上添加一個可寫層。該可寫層與容器生命周期綁定容器刪除時可寫層隨之銷毀內部生成的數據無法保留。這一特性決定了容器天然適合運行無狀態應用但對于數據庫、文件服務等有狀態場景必須引入外部持久化存儲。2.2 核心概念定義1數據卷Docker 數據卷是獨立于容器聯合文件系統Union File System的持久化存儲區域其本質是在宿主機上開辟的專用存儲空間通過與容器內目錄建立掛載綁定關系實現數據的持久化存儲與跨邊界訪問。掛載完成后宿主機目錄與容器內目錄構成雙向實時同步通道任意一端的文件變更均會即時映射至另一端。數據卷機制解決了容器技術的三大核心痛點數據持久化容器實例銷毀時聯合文件系統的可寫層被回收但宿主機上的數據卷目錄不受影響數據可長久留存宿主機與容器的數據交互外部文件可通過宿主機數據卷目錄中轉自動映射至容器內部實現二者的雙向數據互通多容器數據共享同一個宿主機數據卷可同時掛載至多個容器實例實現跨容器的數據共享與協同處理。2.3 類型辨析依據掛載源Source的性質與聲明方式Docker 數據卷可劃分為以下三類類型聲明方式掛載源位置生命周期管理適用場景綁定掛載Bind Mount-v /host/path:/container/path宿主機任意絕對路徑由宿主機文件系統管理Docker 不直接控制開發環境代碼熱更新、配置文件注入命名卷Named Volume-v volume-name:/container/pathDocker 管理的專用存儲目錄通常為/var/lib/docker/volumes/由 Docker Daemon 集中管理可顯式刪除生產環境數據持久化、數據庫文件存儲匿名卷Anonymous Volume-v /container/pathDocker 自動生成的存儲目錄隨容器創建而生成容器刪除后變為懸空卷Dangling臨時緩存、無需長期保留的中間數據綁定掛載直接映射宿主機已有目錄靈活性最高但路徑依賴宿主機文件系統結構可移植性較差。命名卷由 Docker 統一分配與管理具備顯式命名、備份遷移及跨容器復用的優勢是生產環境中的首選方案。匿名卷在僅指定容器內路徑時由引擎自動創建適用于無需人工干預生命周期的臨時存儲場景。3. 數據卷的配置與實驗3.1 基礎語法在創建并啟動容器時通過docker run命令的-v或--volume參數完成數據卷掛載其通用語法結構為dockerrun-v掛載源:容器內目標路徑[:選項]其他參數 鏡像名其中掛載源可以是宿主機絕對路徑綁定掛載、卷名稱命名卷或省略匿名卷選項包括ro只讀等訪問控制標志。操作規范路徑必須使用絕對路徑宿主機與容器側的目錄或文件均需填寫絕對路徑不能使用./或../等相對路徑目錄自動創建若指定的宿主機目錄已存在則直接掛載若容器內的目標目錄不存在Docker 會在容器文件系統中自動創建該目錄無需手動預先新建支持多數據卷掛載單個容器可同時掛載多個數據卷每組-v參數對應一個獨立的掛載點通過重復添加-v配置實現多路徑映射。3.2 綁定掛載實驗宿主機-容器數據同步實驗目的驗證宿主機目錄與容器內目錄的雙向實時同步特性。實驗環境macOS Docker Desktop。實驗步驟創建容器 c1將宿主機目錄掛載至容器內 /root/docker_data_containerdockerrun-d-v/host/data:/app/data mysql:8.0注意事項在 macOS 的 Docker Desktop 環境中綁定掛載受安全策略限制并非宿主機上任意目錄均可直接掛載。若目標目錄未加入 Docker 的文件共享白名單Settings → Resources → File Sharing將觸發 Mounts denied 錯誤。此限制僅針對綁定掛載命名卷不受此約束。在宿主機掛載目錄中創建文件 huey_docker.txt觀察容器內 /root/docker_data_container 目錄文件已同步出現。在容器內該目錄下創建文件 huey_docker_container.txt觀察宿主機對應目錄文件亦同步出現。3.3 數據持久化實驗實驗目的驗證容器刪除后掛載數據是否得以保留。實驗步驟刪除容器 c1docker rm c1。檢查宿主機掛載目錄 /Users/anphia/Documents/my-projects/docker-study/docker_data此前創建的文件仍然存在未被刪除。創建新容器 c2掛載同一宿主機目錄檢查容器 c2 內掛載點歷史數據完整恢復。實驗結論綁定掛載將數據存儲于宿主機文件系統中容器銷毀不影響宿主機數據實現了數據持久化。3.4 多目錄掛載實驗實驗目的驗證單個容器同時掛載多個獨立存儲實體的可行性。實驗步驟創建容器 c3同時掛載兩個獨立的宿主機目錄dockerrun-it--namec3\-v/Users/anphia/Documents/my-projects/docker-study/c3_host_data1:/root/c3_container_data1\-v/Users/anphia/Documents/my-projects/docker-study/c3_host_data2:/root/c3_container_data2\centos:7實驗結論單個容器支持將內部多個目錄分別掛載至不同的宿主機目錄實現細粒度的存儲隔離與管理。4.5 跨容器共享實驗實驗目的驗證多個容器掛載同一宿主機目錄時的數據共享特性。實驗步驟分別創建容器 c4 和 c5并且這兩個容器共享同一個宿主機的數據卷目錄。在其中一個容器寫入數據觀察到另一個容器可以讀取到達到數據共享的目的。分別創建容器 c4 和 c5二者掛載同一宿主機目錄dockerrun-it--namec4-v/Users/anphia/.../shared:/root/shared centos:7dockerrun-it--namec5-v/Users/anphia/.../shared:/root/shared centos:7在容器 c4 的共享目錄中寫入數據。在容器 c5 中讀取該數據。實驗結論多個容器通過綁定掛載共享同一宿主機目錄時任一容器的寫操作對其他容器立即可見實現了跨容器數據共享。5. 數據卷容器機制5.1 設計動機當容器數量較多時直接掛載方案要求每個容器均通過 -v 參數重復指定相同的宿主機目錄配置冗余度高維護成本顯著增加。為簡化大規模容器集群的數據共享部署Docker 引入了數據卷容器Data Volume Container機制。5.2 概念與工作原理數據卷容器本質上是一個普通容器實例其核心作用并非運行業務邏輯而是作為掛載配置的模板與代理。其他業務容器通過 --volumes-from 參數繼承該容器的所有掛載配置從而自動共享同一套存儲實體。如圖 1 所示創建數據卷容器 c3 并掛載數據卷業務容器 c1 和 c2 通過 --volumes-from c3 繼承掛載關系。此時 c1、c2、c3 均掛載至同一底層存儲實體。數據卷容器的核心特性在于掛載配置繼承與生命周期解耦配置繼承--volumes-from繼承的是掛載配置Mount Configuration而非文件數據的物理復制。繼承容器與數據卷容器共享同一宿主機目錄的讀寫視圖生命周期解耦數據實際存儲于宿主機數據卷中與數據卷容器本身解耦。即使數據卷容器被停止或刪除只要數據卷在宿主機上仍然存在其他繼承該配置的容器依然可以正常讀寫共享數據。數據卷容器既可使用匿名卷亦可使用命名卷或綁定掛載–volumes-from 對上述類型均有效。數據卷容器方案屬于 Docker 早期設計模式。在現代生產環境中Docker Compose 或 Kubernetes 等編排工具已提供更優雅的聲明式數據共享方案。5.3 操作流程與驗證創建數據卷容器 c6使用匿名卷dockerrun-it--namec6-v/volume centos:7 /bin/bash創建業務容器 c7 和 c8繼承 c6 的掛載配置dockerrun-it--namec7 --volumes-from c6 centos:7 /bin/bashdockerrun-it--namec8 --volumes-from c6 centos:7 /bin/bash在容器 c7 的 /volume 目錄下創建文件觀察 c6 和 c8文件均同步可見。通過 docker inspect c6 查看 Mounts 字段可獲取匿名卷在宿主機上的真實路徑Source及容器內掛載點Destination。實驗結論數據卷容器通過配置繼承機制實現了多容器對同一存儲實體的高效共享且數據卷容器的生命周期不影響業務容器的數據訪問。6 現代演進從數據卷容器到編排工具數據卷容器機制在早期 Docker 版本中廣泛應用于多容器數據共享場景。然而隨著容器編排技術的發展現代生產環境更傾向于使用Docker Compose或Kubernetes等工具統一管理數據卷聲明與掛載關系。例如Docker Compose 通過頂層volumes字段聲明命名卷并在各服務的volumes配置中直接引用實現了更清晰的配置集中化與版本可控性。盡管如此數據卷容器作為理解 Docker 掛載繼承原理的基礎機制在容器存儲語義的教學與面試考察中仍具重要價值。7. 結論本文系統分析了 Docker 容器默認存儲模型的局限性闡述了數據卷機制的形式化定義與分類體系深入探討了綁定掛載、命名卷及匿名卷的配置語義與適用邊界。在此基礎上本文詳細論述了數據卷容器的掛載繼承機制與生命周期解耦原理并結合底層內核實現說明了數據卷如何繞過聯合文件系統以實現持久化 I/O。研究表明數據卷是構建有狀態容器應用的核心基礎設施而命名卷與現代化編排工具的結合已成為生產環境中管理容器持久化存儲的主流實踐。未來研究可進一步關注容器存儲接口Container Storage Interface, CSI在 Kubernetes 生態中的標準化演進以及分布式存儲后端如 Ceph、NFS與容器卷驅動的深度集成方案。參考文獻[1] MERKEL D. Docker: Lightweight Linux Containers for Consistent Development and Deployment[J]. Linux Journal, 2014, 2014(239): 2.[2] NICKOLoff J. Docker in Action[M]. Shelter Island: Manning Publications, 2016: 105-128.[3] FELTER W, FERREIRA A, RAJAMONY R, et al. An Updated Performance Comparison of Virtual Machines and Linux Containers[C]//2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, 2015: 171-172.[4] TURNBULL J. The Docker Book: Containerization is the New Virtualization[M]. James Turnbull, 2014.[5] MATHIEU R, BURNS B, BEDA J, et al. Kubernetes: Up and Running[M]. Sebastopol: O’Reilly Media, 2017.