CRI-O 1.0 簡介

去年，Kubernetes 項目推出了容器運行時介面Container Runtime Interface（CRI）：這是一個插件介面，它讓 kubelet（用於創建 pod 和啟動容器的集群節點代理）有使用不同的兼容 OCI 的容器運行時的能力，而不需要重新編譯 Kubernetes。在這項工作的基礎上，CRI-O 項目（原名 OCID）準備為 Kubernetes 提供輕量級的運行時。

那麼這個真正的是什麼意思？

CRI-O 允許你直接從 Kubernetes 運行容器，而不需要任何不必要的代碼或工具。只要容器符合 OCI 標準，CRI-O 就可以運行它，去除外來的工具，並讓容器做其擅長的事情：加速你的新一代原生雲程序。

在引入 CRI 之前，Kubernetes 通過「一個內部的易失性介面」與特定的容器運行時相關聯。這導致了上游 Kubernetes 社區以及在編排平台之上構建解決方案的供應商的大量維護開銷。

使用 CRI，Kubernetes 可以與容器運行時無關。容器運行時的提供者不需要實現 Kubernetes 已經提供的功能。這是社區的勝利，因為它讓項目獨立進行，同時仍然可以共同工作。

在大多數情況下，我們不認為 Kubernetes 的用戶（或 Kubernetes 的發行版，如 OpenShift）真的關心容器運行時。他們希望它工作，但他們不希望考慮太多。就像你（通常）不關心機器上是否有 GNU Bash、Korn、Zsh 或其它符合 POSIX 標準 shell。你只是要一個標準的方式來運行你的腳本或程序而已。

CRI-O：Kubernetes 的輕量級容器運行時

這就是 CRI-O 提供的。該名稱來自 CRI 和開放容器計劃（OCI），因為 CRI-O 嚴格關注兼容 OCI 的運行時和容器鏡像。

現在，CRI-O 支持 runc 和 Clear Container 運行時，儘管它應該支持任何遵循 OCI 的運行時。它可以從任何容器倉庫中拉取鏡像，並使用容器網路介面Container Network Interface（CNI）處理網路，以便任何兼容 CNI 的網路插件可與該項目一起使用。

當 Kubernetes 需要運行容器時，它會與 CRI-O 進行通信，CRI-O 守護程序與 runc（或另一個符合 OCI 標準的運行時）一起啟動容器。當 Kubernetes 需要停止容器時，CRI-O 會來處理。這沒什麼令人興奮的，它只是在幕後管理 Linux 容器，以便用戶不需要擔心這個關鍵的容器編排。

CRI-O Overview

CRI-O 不是什麼

值得花一點時間了解下 CRI-O 不是什麼。CRI-O 的範圍是與 Kubernetes 一起工作來管理和運行 OCI 容器。這不是一個面向開發人員的工具，儘管該項目確實有一些面向用戶的工具進行故障排除。

例如，構建鏡像超出了 CRI-O 的範圍，這些留給像 Docker 的構建命令、 Buildah 或 OpenShift 的 Source-to-Image（S2I）這樣的工具。一旦構建完鏡像，CRI-O 將樂意運行它，但構建鏡像留給其他工具。

雖然 CRI-O 包含命令行界面 （CLI），但它主要用於測試 CRI-O，而不是真正用於在生產環境中管理容器的方法。

下一步

現在 CRI-O 1.0 發布了，我們希望看到它作為一個穩定功能在下一個 Kubernetes 版本中發布。1.0 版本將與 Kubernetes 1.7.x 系列一起使用，即將發布的 CRI-O 1.8-rc1 適合 Kubernetes 1.8.x。

我們邀請您加入我們，以促進開源 CRI-O 項目的開發，並感謝我們目前的貢獻者為達成這一里程碑而提供的幫助。如果你想貢獻或者關注開發，就去 CRI-O 項目的 GitHub 倉庫，然後關注 CRI-O 博客。

via: https://www.redhat.com/en/blog/introducing-cri-o-10

作者：Joe Brockmeier 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出