Containers Are Still Not a Thing — At Least, Not to the Linux Kernel
For anyone running container platforms in production, the practical question behind a recurring effort on the Linux kernel mailing lists is a blunt one: when something goes wrong inside a container, what exactly are you debugging? The kernel's answer, for the better part of two decades, has been that no such thing exists.
According to LWN.net, the design of containers in the kernel is founded on the absence of a container abstraction. The kernel does not recognise a container object. Instead it ships a collection of parts — namespaces, control groups, sandboxing mechanisms, and more — with an implicit instruction that the user assemble them into something coherent. Any fresh effort to change that would ask the kernel to recognise containers as a first-class object; LWN's coverage frames the discussion, carried on the lore.kernel.org and LKML archives, as the latest attempt in a very long line of them.
The proposal is not new. LWN has covered earlier efforts it has linked to in the same piece, each reaching the same wall. What keeps the debate alive is a genuine tension rather than stubbornness. Formalising a container object would hand observability, policy and security tooling an authoritative contract to program against — today, each tool must re-derive what a "container" is from the same low-level primitives. But doing so risks freezing one userspace convention into kernel ABI. Docker and runc, LXC, systemd-nspawn, Kubernetes and Firejail each assemble the primitives differently, and there are dozens of such conventions in active use. Committing the kernel to one of them, or to a lowest-common-denominator abstraction, would constrain userspace design for years.
The stakes for practitioners are concrete. Tooling that audits, traces or throttles workloads today relies on heuristics and hand-maintained mappings between cgroup paths, namespace identities and runtime labels. An authoritative kernel object would simplify that considerably; its absence means every platform team maintains its own version of the same glue.
What is known, and what is not
LWN's full coverage sits behind a subscription paywall, so the specifics of the series — who proposed it, how the patch is shaped, and how the list responded — could not be independently verified from the public excerpt alone. The premise, the history of failed attempts, and both sides of the argument are all supported by the accessible portion of the article and the linked public threads.
The payoff of that split is the takeaway for Hong Kong DevOps teams evaluating tracing and security tooling: the container remains a userspace convention, not a kernel promise. Maintainers have declined the ABI trade in the current iteration of the argument, so tooling built on inference rather than interface should be treated as version-coupled and runtime-coupled — and kept flexible.
容器仍然不存在 — 至少在 Linux kernel 眼中如此
對於任何在生產環境運行 container 平台的人來說，Linux kernel 郵件列表上一再出現的討論背後，其實是一個非常實際的問題：當容器內部出錯時，你究竟在 debug 什麼？近二十年來，kernel 的答案始終是：這種東西並不存在。
據 LWN.net 報道，kernel 中容器的設計，正是建立在「容器抽象缺席」這一基礎之上。kernel 並不承認 container 物件，而是提供一系列組件 —— namespace、control group、sandboxing 機制等等 —— 並附帶一項隱含指示，要求用戶自行將它們組裝成一個連貫的整體。任何試圖改變現狀的新嘗試，都意味著要求 kernel 承認容器是一等物件（first-class object）；LWN 的報道將這場在公開的 lore.kernel.org 和 LKML 存檔中進行的討論，框定為漫長歷史中最新一次嘗試。
這項提案並不新。LWN 在同一篇文章中連結了早前的多次努力，每一次都撞上同一堵牆。令這場辯論持續存在的，是真正的張力而非固執。將 container 物件正式化，將令可觀測性（observability）、policy 及安全工具獲得一份可供編程的權威合約 —— 而今天，每一個工具都必須從相同的低階 primitives 重新推導「容器」是什麼。但這樣做有風險：可能把某一種 userspace 習慣固化為 kernel ABI。Docker 和 runc、LXC、systemd-nspawn、Kubernetes 和 Firejail 各自組裝 primitives 的方式都不一樣，目前活躍使用的此類慣例更有數十種。若令 kernel 承諾採用其中一種，或採用一個最小公分母式的抽象，將會在未來多年限制 userspace 的設計空間。
對從業者而言，利害關係十分具體。今天審計、追蹤或節流（throttle）工作負載的工具，依賴的是 heuristic 方法，以及在 cgroup path、namespace 身份與 runtime 標籤之間人工維護的映射關係。一個權威的 kernel 物件將大幅簡化這一切；而它的缺席，意味著每一個 platform 團隊都要自行維護同一套黏合層的私有版本。
已知與未知
LWN 的完整報道設有訂閱付費牆，因此該系列的具體內容 —— 由誰提出、patch 的具體形態，以及郵件列表的反應 —— 無法僅憑公開節錄獨立核實。文章的論點前提、歷次失敗嘗試的歷史，以及辯論雙方的立場，均可從文章可閱讀部分及所連結的公開討論串得到支持。
這種區分所帶來的啟示，正是香港 DevOps 團隊在評估 tracing 及安全工具時需要注意的一點：容器仍然是 userspace 的慣例，而非 kernel 的承諾。在本輪爭論中，maintainers 已拒絕以 ABI 作為交換條件，因此建立在推斷（inference）而非 interface 之上的工具，應被視為與特定版本及 runtime 緊密耦合 —— 必須保留靈活性。