前言

經歷了三篇來到第四篇，我們現在認知 OpenShift 是基於 Kubernetes 在搭配一些 OpenShift 的加強套件之後，還有一部分需要進行對比，那就是 Container Runtime。

專有名詞

Runtime

• 中文字如果寫 執行時 / 執行時期 / 執行階段 / 运行时，指的都是同一件事情。
• 第一次看到「Runtime」這個組合字的時候，是 Java Runtime Environment。 非常地糾結，明明知道他指的是「提供 Java 程式運作的沙盒環境」，他是執行環境欸！環境！ 好歹也要叫做 Runspace 才對啊。
• 後來調查才知道，那是一個基於「程式」視角，程式的一生，會從設計時期、編譯時期、鏈結時期、載入時期，再到執行時期。 所以 Runtime 才會泛指提供給程式執行的環境。 以下是 Runtime 會有的幾個功能：

• 幾種常見的 Runtime
  • Java Runtime
  • JavaScript Runtime
  • Python Runtime
  • Container Runtime

Container Runtime

• Container Runtime 是負責啟動與管理容器程序的後端程式，讓容器能在作業系統上運行。 本身不負責直接執行容器。
• 以下比較 K8s 和 OCP 的 Container Runtime：
  • Containerd： 當使用者透過指令運行容器，它會呼叫 containerd-shim (意思是：墊片)，由這個墊片程式去執行 runc 喚醒容器後，runc 則結束。shim 仍然作為 container 的父程序，用來監管該叫出來的容器。 墊片這種設計可以確保容器發生意外中斷時，還有程序可以記錄下容器中斷的訊息 stdout / stderr。

  一個容器就會對應到一個 shim。

  • CRI-O：大致上跟 Containerd 做一樣的事情，但是不用透過 containerd-shim。

OCI

• Open Container Initiative 的縮寫，是一個開放社群組織，制定容器格式與執行環境的標準，目的是讓容器技術互通、可攜、避免綁死特定平台。
• 連結：https://opencontainers.org/

CRI

• Container Runtime Interface 的縮寫，CRI 是 Kubernetes 設計的一個介面（gRPC API），用來讓 kubelet 可以與不同的 container runtime 溝通。
• 早期 Kubernetes 是硬編碼支援 Docker 的，造成只能用 Docker，無法使用其他 Runtime（如 rkt、containerd、CRI-O）。
• 後來 Kubernetes 團隊推出 CRI，目的是切割 Docker，kubelet 不再直接控制容器，而是透過 CRI 跟任何符合規範的 container runtime 通訊。
  

結論

• CRI-O 是專門為 Kubernetes 而設計的，目標就是「只做一件事：跑 Pod」
• Containerd 還需要透過 CRI plugin 才能作為 K8s 的 CRI。

參考資料

1. YouTube: Docker Architecture | Docker components : daemon, containerd, containerd-shim, runc
   • 連結： https://www.youtube.com/watch?v=253o0hxwxm8
2. Cloudflight / kubernetes, docker, cri/-o, containerd, OCI, runC,
   container
   • 連結： https://cloudnativelinz.at/slides/2022-10/Kubernetes,%20docker,%20cri-o,%20containerd,%20OCI,%20runC,%20container%20-%20what%20they%20are%20and%20how%20they%20fit%20together.pdf
3. GitHub： CRI-O
   • 連結： https://github.com/cri-o/cri-o