Docker 於 2013 推出了兩大核心技術：Docker Image 和 Docker Engine，這為容器技術帶來變革。

Docker Image 是容器技術的創新概念，讓容器技術不只是隔離。上篇文章提到，容器技術的環境不一致而導致部屬問題。Docker Image 解決了這一問題，它將包含了程式運行所需的所有相依，打包成自包含的可移植檔案，開發者可以將其運行到任何支持 Docker 的環境中，而不需要擔心環境差異，這大大簡化了容器從開發到部屬的過程，提供「一次打包，到處運行」的能力，開發者不再需要為環境差異擔心，這使得應用的交付流水線變得更加高效和穩定。

Docker Image 還有關於 Union File System 的創新應用。 這是一種分層、輕量級且高效能的檔案系統。它允許對檔案系統的變更以疊加的方式逐層保存，每一個 Docker Image 的變更都對應一個額外的層。**這樣的檔案系統架構提供了清楚追蹤變動的能力，透過程式碼定義應用運行環境的概念。**在這之前管理運行環境的常見挑戰是，一個檔案改了，但是沒有人知道它為什麼改、是誰改的、什麼時候改的，以及有什麼相依跟者一起改，而 Docker Image 的變更對應一個額外的層，讓每一次的變動都是可以追蹤的。

其次，Docker Engine 是 Docker 的運行時核心，它包含 Docker Client、Docker API 以及Docker Daemon 實現容器的管理和操作。Docker Engine 是容器技術的執行引擎，通過與 Linux Kernel 的容器技術進行交互，負責創建、管理和監控容器。Docker Daemon 則是運行在背景的服務，它通過 HTTP API 接受來自 Docker Client 的指令，從而觸發容器的操作。這使得容器的管理可以通過簡單的指令來實現，而不需要直接與複雜的內核技術打交道。Docker Daemon 進一步簡化了容器的操作流程，讓開發者可以方便地使用熟悉的 HTTP 協定來調用底層容器技術，達到了高效封裝與易用性的雙重目標。

然而，隨著業界大規模採用容器技術，Docker 的網路和儲存問題逐漸浮現。

在網路層面，Docker Engine 依賴於 Bridge 網路，為每個 Docker 容器分配 IP 地址，這些 IP 地址只在宿主機內有效。 當需要讓宿主機之外的流量導入容器時，通常需要通過暴露宿主機的端口，並通過宿主機來管理容器的對外流量。這種方式雖然有效，但會增加容器網路管理的複雜度，尤其是在涉及到多宿主機多容器之間的相互通信時。宿主機內的 Docker 容器之間的溝通也面臨挑戰，因為每個容器的 IP 地址是動態分配的，這使得容器之間的固定通信變得困難。這些網路問題在需要大規模部署容器的情況下，顯得非常棘手。

在儲存層面，容器的資料持久化也面臨挑戰。 由於容器的設計是基於進程，當容器被刪除或重新啟動時，其內部資料通常會丟失。為了解決這個問題，開發者需要將宿主機的硬碟掛載到容器中，以確保資料的持久性。然而，這個過程需要先將硬碟掛載到宿主機的目錄，然後再將該目錄掛載到容器中，這增加了配置的複雜性，尤其是在多容器共享資料或需要靈活調度儲存資源的情況下。

隨著越來越多的企業開始大規模地採用容器技術，單靠 Docker 的解決方案已經無法滿足所有需求。容器的數量增多後，如何有效地管理和排程這些容器成為新的挑戰。為了解決這些問題，Google 開發並開源了 Kubernetes，一個強大的容器管理與排程系統，專為大規模管理容器而設計。