解決的問題，都會留在架構當中。
在介紹 Kubernetes 之前，我們必須瞭解容器技術的演變，儘管 Docker 現在的使用範圍已縮減到只剩開發環境，容器的運行環境被 containerd 以及 runc 取代，而容器鏡像的標準則是由 OCI，但 Docker 的歷史地位依然無法被取代。

介紹 Docker 不僅是出於對這一個傳奇專案的尊敬，更重要的是從作業系統的角度來解析容器技術的演進，幫助我們更好地理解容器的概念。因為理解容器技術的基礎，就是理解進程的運作，這也是掌握 Kubernetes Pod 運行原理的關鍵。

在現代計算環境中，管理應用程式的運行和資源分配是一個核心議題。隨著應用程式數量和複雜度的增加，傳統虛擬機技術在彈性和資源利用率方面顯得不足。為了解決這些問題，容器技術應運而生，它提供了一種更加輕量、靈活的隔離方式。

作業系統的進程管理是資源分配的基礎。進程虛擬化了 CPU，讓每個應用程式感覺自己獨佔一個 CPU，即使實際上是由作業系統的 Time Slicing 和 Scheduler 技術來分配資源。這種進程級別的虛擬化，讓系統可以更有效率的運行。

然而，進程之間雖然有記憶體隔離，但仍然會共享某些資源，例如檔案系統和網路連接，這就帶來了安全和管理上的挑戰。為了達到更高層次的隔離，虛擬機技術應運而生，模擬整個作業系統及其底層硬體。但這種方法也帶來了一些問題：

• 資源冗餘：虛擬機往往需要預留大量的 CPU 和記憶體資源，以應對高峰負載，但這導致了很多資源在大多數情況下處於閒置狀態，無法被有效利用。

• 虛擬化額外開銷：每個虛擬機都需要運行完整的作業系統，即使應用程式本身很小，這仍然會增加系統的開銷，降低資源利用率。

• 硬體相依的虛擬化技術：虛擬機的虛擬化技術大多相依於底層硬體的支持，尤其是對於硬體虛擬化功能的相依。然而，並不是所有的硬體都具備這些功能，這使得某些情況下虛擬化的效率無法達到預期，甚至會限制其應用範圍。

為了解決這些問題，我們發明了容器技術，容器技術是基於 Linux 核心中的 namespace 和 cgroup，namespace 負責隔離進程的視野，而 cgroup 控制進程的資源使用，chroot 改變根目錄。這些技術一起實現了進程的隔離與控制，讓容器可以在同一台主機上安全、有效地運行。容器技術利用這些，實現了虛擬化功能，但是本質上，容器就是受到嚴格控制的進程。[1]

[1] 現代的容器化技術，例如 runc，改變根目錄調用的是 pivot_root 而不是 chroot，因為 chroot 本身並不是設計用來處理安全問題，在其 man page 也有強調不要把 chroot 用於安全方案。
使用 chroot 最明顯的安全問題是：要離開 chroot 監獄的方法，就是再調用一次 chroot。https://github.com/opencontainers/runc/blob/961b8031f6614be300d3b10eec9d2f54323026d9/libcontainer/rootfs_linux.go#L208
https://tbhaxor.com/pivot-root-vs-chroot-for-containers/