OCI 是什麼？一篇搞懂 Open Container Initiative

在追蹤科技產業趨勢時，我們經常聽到 Docker、Kubernetes (K8s) 這些炙手可熱的名詞，它們共同構築了所謂的「雲原生 (Cloud Native)」時代。但就像觀察一家上市公司不能只看營收，要深入探究其核心技術護城河一樣，在這些明星技術的背後，有一個默默無聞卻至關重要的組織——OCI。你可能會問，OCI 是什麼？它既不是某家公司的產品，也不是一個可以下載安裝的軟體，但如果沒有它，現代雲端運算的世界可能會是另一番混亂的景象。今天，米拉將帶你從產業趨勢與技術標準化的角度，徹底解析 OCI (Open Container Initiative)，讓你明白它為何是支撐起整個容器生態系的隱形地基，以及理解它對於判斷未來技術走向的重要性。🧭

OCI，全名為 Open Container Initiative（開放容器倡議），是一個在 Linux 基金會 支持下的開放標準專案。它的核心使命非常單純卻極具影響力：為容器的映像檔格式 (Image Format) 和執行環境 (Runtime) 制定一套開放、穩定且具互通性的工業標準。你可以把它想像成是貨運界的「標準貨櫃」。在標準貨櫃出現之前，貨物奇形怪狀，每艘船、每個港口的裝卸方式都不同，效率極低。而標準貨櫃的誕生，讓全世界的港口、貨車、輪船都能用同樣的方式處理貨物，從而引發了全球物流革命。OCI 在軟體世界裡，扮演的就是這個「標準貨櫃」的制定者角色。

💡 OCI 的歷史與目標：為何我們需要開放容器標準？

要理解 OCI 的價值，我們必須將時光倒流至 2014-2015 年，那是一個容器技術野蠻生長的「戰國時代」。當時，Docker 以其輕量、快速、易用的特性席捲了整個開發者社群，幾乎成為容器技術的代名詞。然而，隨著 Docker 的巨大成功，整個行業也開始浮現一絲憂慮：如果容器的未來完全由一家公司（Docker Inc.）所定義，會不會形成新的技術壁壘與廠商鎖定 (Vendor Lock-in)？這意味著，所有圍繞容器開發的工具、平台和服務，都必須依賴 Docker 的技術路線，這對於追求開放與自由的軟體生態系來說，無疑是一大風險。

就在此時，市場上出現了挑戰者。由 CoreOS 公司（後來被 Red Hat 收購）推出的 `rkt`（發音為 Rocket）就是一個代表性的例子。`rkt` 同樣是一個容器引擎，但它在設計理念上更強調安全性與組合性，並提出了自己的容器格式標準——App Container (appc)。於是，一場潛在的「容器格式戰爭」似乎一觸即發。如果開發者打包一個應用，需要同時製作 Docker 格式和 `rkt` 格式的映像檔，那麼容器技術所承諾的「一次建置，到處運行」的優勢將大打折扣，整個生態系也會因此而碎片化。

面對這種分裂的風險，業界的領袖們迅速採取了行動。在 2015 年 6 月，由 Docker、CoreOS、Google、Red Hat、Microsoft 等二十多家科技巨頭共同發起，在 Linux 基金會的框架下，OCI (Open Container Initiative) 正式成立。這是一個歷史性的時刻，競爭對手們選擇坐下來，共同為了一個更宏大的目標而努力：

• 建立開放標準： 確保容器的核心技術（映像檔如何打包、容器如何運行）不被任何單一公司所控制，而是由社群共同維護和發展。
• 促進互通性： 讓使用 A 工具打包的容器映像檔，可以無縫地在 B 工具上運行，只要大家都遵循 OCI 標準。
• 鼓勵創新： 在一個穩定的基礎標準之上，不同的廠商可以專注於更高層次的功能創新，例如容器編排、安全性、監控等，而不是在底層格式上重複造輪子。

作為成立 OCI 的誠意之舉，Docker 公司將其容器執行時的核心程式碼 `libcontainer` 捐贈出來，並將其打包成一個名為 `runc` 的獨立工具，作為 OCI 執行時標準的參考實現。這意味著 Docker 主動放棄了對容器運行方式的絕對控制權，將其標準化，供整個行業使用。這一舉動成功化解了潛在的容器戰爭，為日後 Kubernetes 的蓬勃發展以及整個雲原生生態的繁榮奠定了堅實的基礎。

📊 OCI 的兩大核心規格：Runtime Spec 與 Image Spec

OCI 的工作成果主要體現在兩個核心的技術規格文件上。這兩個規格就像是容器世界的「憲法」，定義了所有參與者都必須遵守的基本原則。雖然內容非常技術性，但我們可以透過一些比喻來理解它們的核心思想。

1. 映像檔規格 (Image Specification / Image Spec)

   這份規格定義了「什麼是一個標準的容器映像檔」。你可以把容器映像檔想像成一個「應用程式的冷凍包裹」，裡面包含了應用程式執行所需的一切：程式碼、函式庫、環境變數、設定檔等等。Image Spec 就像是規定了這個冷凍包裹的標準打包方式：

   • 映像檔清單 (Image Manifest): 像包裹上的「內容清單」，用一個 JSON 檔案描述了這個映像檔包含了哪些東西，比如設定檔在哪、檔案系統有幾層 (Layers)、每一層的特徵碼 (Digest) 是什麼。
   • 檔案系統分層 (Filesystem Layers): 這是容器映像檔的核心概念。它不是一個巨大的單一檔案，而是像千層蛋糕一樣，由多個唯讀的層疊加而成。每一層都是對上一層的修改（新增、刪除或修改檔案）。這種設計的好處是極大地提高了儲存和傳輸效率。例如，如果你有 10 個都基於 Ubuntu 作業系統的映像檔，那麼它們可以共享同一個 Ubuntu 基礎層，而不需要重複儲存 10 次。
   • 映像檔設定 (Image Configuration): 一個 JSON 檔案，定義了容器啟動時的預設參數，比如預設要執行的命令、環境變數、工作目錄、網路端口等。

   有了 OCI Image Spec，無論你是用 Docker build、Buildah 還是其他工具來建置映像檔，只要產出的結果符合這個標準，那麼這個映像檔就可以被任何支援 OCI 標準的容器引擎所識別和運行。它確保了容器映像檔的可移植性。

2. 執行時規格 (Runtime Specification / Runtime Spec)

   如果說 Image Spec 定義了「靜態」的包裹長什麼樣，那麼 Runtime Spec 就定義了這個包裹該如何被「拆開並運行起來」。它規定了一個 OCI 相容的執行時 (Runtime) 應該如何接收指令，並將一個容器映像檔變成一個正在運行的程序（也就是容器）。

   • 設定檔 (config.json): 這是 Runtime Spec 的核心。當你要啟動一個容器時，上層工具（如 containerd）會產生一個 `config.json` 檔案，詳細描述了這個容器要如何運行。內容包括：要使用的根檔案系統在哪裡（通常是從映像檔解壓縮而來）、要執行的程序和參數、環境變數、掛載點、以及最重要的——Linux 命名空間 (Namespaces) 和控制組 (cgroups) 的設定。正是這些設定實現了容器的隔離性。
   • 容器生命週期 (Lifecycle): 規格定義了一套標準的容器操作命令，例如 `create` (建立容器)、`start` (啟動容器)、`kill` (發送信號給容器)、`delete` (刪除容器) 等。所有 OCI Runtime 都必須實現這些標準介面。

   最著名的 OCI Runtime Spec 實現就是 `runc`。`runc` 是一個非常底層的命令列工具，它只做一件事：根據 `config.json` 的內容，標準地把容器運行起來。它不關心映像檔如何下載、網路如何設定，只專注於最核心的「運行」這一步。這使得更高層級的工具可以專注於自己的業務邏輯，把最後的執行工作交給標準化的 `runc`。

📈 OCI、Docker 與 Kubernetes 之間的關係

理解了 OCI 的兩大規格後，我們就能更清晰地看懂 OCI、Docker 和 Kubernetes 這三者之間的分工與協作關係。它們不是競爭對手，而是一個分層明確、互相依賴的生態系統。

Docker 的演變：從單體到擁抱 OCI

早期的 Docker 是一個巨大的單體應用 (Monolith)，從映像檔建置、管理、推送到容器運行，所有功能都集中在一個 Docker Daemon 中。但在 OCI 成立後，Docker 進行了深刻的架構重構，將自己拆分成多個遵循開放標準的模組化元件：

1. Docker Engine: 這是我們最熟悉的上層介面，接收用戶的 `docker run`, `docker build` 等命令。
2. containerd: Docker 將容器運行和映像檔管理的核心邏輯抽離出來，變成一個獨立的常駐程式 containerd。containerd 負責管理容器的整個生命週期，包括從倉庫拉取 OCI 映像檔、管理映像檔儲存、以及呼叫底層 Runtime 來運行容器。containerd 後來也被捐贈給了 CNCF (雲原生運算基金會)，成為一個中立的開源專案。
3. runc: containerd 在需要真正啟動一個容器時，會呼叫 OCI Runtime Spec 的標準實現 `runc`。`runc` 負責與 Linux 核心直接互動，設定 cgroups 和 namespaces，並啟動容器內的程序。

所以，現在當你執行 `docker run` 命令時，背後的調用鏈是：
Docker CLI → Docker Engine → containerd → runc → 運行的容器
這條鏈路中的 `containerd` 和 `runc` 都是遵循 OCI 標準的。這意味著 Docker 已經從一個封閉的系統，轉變為一個基於開放標準建構的工具。

Kubernetes 的角色：高層的指揮家

Kubernetes 則處於更高的層次。它是一個「容器編排 (Orchestration)」平台，關心的是如何管理成千上萬個容器的集群。Kubernetes 負責調度（決定容器在哪台機器上運行）、服務發現、負載平衡、自動擴縮容、故障轉移等複雜的集群管理任務。但是，Kubernetes 自己並不直接運行容器。

為了能夠與不同的容器執行時協作，Kubernetes 定義了一個名為 CRI (Container Runtime Interface) 的標準化 API 介面。任何容器執行時，只要實現了 CRI 介面，就可以接入 Kubernetes 集群，成為 K8s 的「執行引擎」。

這就形成了另一個清晰的調用鏈：

1. Kubernetes 的 `kubelet` 元件（運行在每個節點上）決定要在本機啟動一個容器。
2. `kubelet` 透過 CRI 介面，向實現了 CRI 的容器執行時（如 containerd 或 CRI-O）發出指令：「請幫我運行這個 OCI 映像檔」。
3. `containerd` 或 `CRI-O` 接收到指令後，開始準備工作，然後呼叫底層的 OCI Runtime（如 `runc`）來創建並啟動容器。

整個雲原生技術棧的關係圖如下：
Kubernetes (Orchestration) → CRI (Interface) → containerd/CRI-O (High-level Runtime) → OCI (Standard) → runc (Low-level Runtime) → Linux Kernel

從這個關係圖中，你可以清楚地看到 OCI 的位置——它是整個技術棧的最底層標準。正是因為有了 OCI，Kubernetes 才能放心地將運行容器的髒活累活交給任何符合 CRI/OCI 標準的執行時，而不用關心它們的內部實現細節。這也解釋了為什麼 Kubernetes 在後期版本中棄用了與 Docker Engine 直接整合的 Dockershim，轉而推薦使用更輕量、更標準的 containerd 或 CRI-O。這不是要「拋棄 Docker」，而是要擁抱一個更標準、更解耦的架構，而這個架構的基石，正是 OCI。

💰 總結：OCI 對雲原生生態的重要性

回到我們最初的問題：OCI 是什麼？現在我們可以給出一個更深刻的答案。OCI 不僅僅是一套技術規格，它更是雲原生生態得以繁榮的制度保障和哲學基石。它的重要性體現在以下幾個方面：

• 防止廠商鎖定： OCI 確保了沒有任何一家公司可以壟斷容器的定義權，保障了用戶的選擇自由和市場的公平競爭。
• 保障穩定性： 作為一個由 Linux 基金會託管的專案，OCI 規格的變更是謹慎且向後相容的。這為上層工具提供了一個穩定可靠的開發基礎。
• 催化創新： OCI 將底層標準化的工作完成後，讓社群和企業可以將精力集中在更高價值的領域，如 Serverless、Service Mesh、AI/ML 平台等，這些創新都建立在 OCI 提供的穩固地基之上。
• 面向未來： OCI 的工作並未停止。隨著新技術的出現，例如基於 WebAssembly (WASM) 的輕量級容器，OCI 社群也在積極探索如何將這些新興技術納入標準框架，確保生態的持續演進。

對於開發者、維運工程師，乃至於關注科技趨勢的投資者而言，理解 OCI 的意義非凡。它讓我們明白，一個偉大技術的成功，不僅僅在於其自身的優越性，更在於它能否催生一個開放、協作、共贏的生態系統。OCI 正是這個生態系統的守護者。

下次當你看到一家公司宣稱其產品「支援容器」時，你的腦海中應該浮現出 OCI 的身影。你會去思考：它的產品是否遵循 OCI 標準？它在 OCI 所構建的生態中扮演什麼角色？這種基於第一性原理的思考，將幫助你在紛繁複雜的技術世界中，撥開迷霧，看清本質，做出更明智的判斷。