aka Container manager，用來啟動、停止或刪除 container。
目前常見的 container runtime 有 containerd、cri-o，而他們都可以能夠拉下並執行任何遵守 Open Container Initiatives (OCI) 規範的 image。
Why are Container Runtimes so Confusing?
當我們啟用一個 Docker container 時，會歷經以下步驟：
- 下載 image
- 解壓縮 image 變成 bundle，在這個過程中，會將 image 一層層的結構打平，變成單一個 filesystem
- 由 bundle 啟動 container
而 Docker 僅將如何標準化的啟動 (run) 一個 container 貢獻給 Open Container Initiatives (OCI)，並沒有釋出 image、或是 Registry push / pull 的格式。也就是説 Docker 僅提供啟動 container 的第三個步驟並標準化，而在這件事被釐清之前，所有人都認為 Container runtimes 幫我們完成了上面三個步驟，就像 Docker 過去所做的一樣。也造成 "Container runtimes" 這個字容易令人混淆的原因。
Low-level and High-level Container Runtimes
當提到 container runtimes 時，幾個名字可能會出現在腦中，像是 runC、LXC、lmctfy、Docker (containerd), rkt, cri-o 等等，但其實這些工具都各自為了不同的情境而生、也實作了不同的功能。像是 containerd 及 cri-o 使用 runC 來運行一個 container，但另外還實作了 higher level 的功能，像是 image 管理及 APIs。對比於 runC 的 low-level implementation，這些 high-level 的功能包含
- image transport
- image management
- image unpacking
- APIs
在實務方面，只專注於如何運行好一個 container 的 container runtime 稱為 low-level container runtimes；而支援較 high-level 功能的 container runtime，像是 image management 或是 gRPC/Web APIs，通常會稱為 high-level container runtimes 或是 high-level container tools
