Containerization
Low-Level 和 High-Level Container Runtime
當人們想到 Container Runtime，可能會想到一系列範例；runc、lxc、lmctfy、Docker（容器）、rkt、cri-o。這些中的每一個都是為不同的情況而建構的，並實現了不同的功能。如 containerd 和 cri-o，實際上使用 runc 來運行容器，在 High-Level 實作鏡像管理和 API。與 runc 的 Low-Level 實作相比，可以將這些功能（包括鏡像傳輸、鏡像管理、鏡像解包和 API）視為 High-Level 功能。每種 Runtime 都涵蓋了 Low-Level 到 High-Level 頻譜的不同部分。
只專注於正在運行的容器的 Runtime 通常稱為 “Low-Level Container Runtime”，支援更多高級功能（如鏡像管理和 gRPC / Web API）的 Runtime 通常稱為“ High-Level Container Runtime”。Low-Level Container Runtime 和 High-Level Container Runtime 是解決不同問題的、從根本上不同的事物。
Low-Level Container Runtime
容器是透過 Linux nanespace 和 Cgroups 實現的，Namespace 能讓你為每個容器提供虛擬化系統資源，像是檔案系統和網絡，Cgroups 提供了限制每個容器所能使用的資源的如記憶體和 CPU 使用量的方法。
在最低級別的 Runtime 中， Container Runtime 負責為容器建立 namespaces 和 cgroups,然後在其中運行命令，Low-Level Container Runtime 支援在容器中使用這些作業系統特性。由 Docker 實作的 runc 就是我們最熟悉也是被廣泛使用的 Container Runtime。runV 是一個基於虛擬機器管理程式（OCI）的執行階段。
它透過虛擬化 guest kernel，將容器和主機隔離開來，使得其邊界更加清晰，這種方式很容易就能幫助加強主機和容器的安全性。代表實作是 kata 和 Firecracker。runsc = runc + safety ，典型實作就是 Google 的 gvisor，透過攔截應用程式的所有系統調用，提供安全隔離的輕量級 Container Runtime 沙箱。Wasm 的沙箱機制帶來的隔離性和安全性，比 Docker 做的更好。但是 wasm 容器處於草案階段，距離生產環境仍有很長的一段路。
High-Level Container Runtime
開發人員想要運行一個容器不僅僅需要 Low-Level Container Runtime 提供的這些特性，同時也需要與鏡像格式、鏡像管理和共享鏡像相關的 API 介面和特性，而這些特性一般由 High-Level Container Runtime 提供。
就日常使用來說，Low-Level Container Runtime 提供的這些特性可能滿足不了日常所需，因為這個緣故，唯一會使用 Low-Level Container Runtime 的人是那些實現 High-Level Container Runtime 以及容器工具的開發人員。
那些實現 Low-Level Container Runtime 的開發者會說 High-Level Container Runtime 比如 containerd 和 cri-o 不像真正的 Container Runtime，因為從他們的角度來看，他們將容器運行的實現外包給了 runc。
但是從使用者的角度來看，它們只是提供容器功能的單一元件，可以被另一個的實作替換，因此從這個角度將其稱為 runtime 仍然是有意義的。即使 containerd 和 cri-o 都使用 runc ，但是它們是截然不同的項目，支援的特性也是非常不同的。 dockershim, containerd 和 cri-o 都是遵循 CRI 的 Container Runtime。