上一篇【第65篇】kubelet深度解析——節(jié)點上的“全能管家“起容器、查健康、報狀態(tài)一把抓下一篇【第67篇】CNI深度解析——容器網(wǎng)絡(luò)接口標(biāo)準(zhǔn)摘要上篇我們說kubelet通過CRI調(diào)containerd起容器。你可能會問為什么K8s能隨便換容器引擎早年只用Docker后來把Docker干掉換成containerd/CRI-Okubelet的代碼卻沒重寫答案就是CRIContainer Runtime Interface——K8s在kubelet和容器運行時之間插了一層標(biāo)準(zhǔn)接口。就像USB接口讓電腦能插任何牌子的鼠標(biāo)CRI讓K8s能用任何符合標(biāo)準(zhǔn)的運行時。這篇文章講清CRI的設(shè)計兩組gRPC API、Pod SandboxPod沙箱這個獨特概念、containerd的CRI插件架構(gòu)以及為什么CRI是K8s換引擎不換車的關(guān)鍵。一、CRI是什么1.1 解耦kubelet和運行時【沒有CRI (早期)kubelet 和 Docker 死綁】 kubelet ──直接調(diào)用──? Docker API (代碼里寫死Docker的調(diào)用) 問題 ? 想換運行時改kubelet源碼 ? Docker太重(K8s只用它一小部分能力) ? 升級Docker牽一發(fā)動全身【有CRI (現(xiàn)在)中間一層標(biāo)準(zhǔn)接口】 kubelet ──CRI(gRPC)──? 任意運行時 ├── containerd ├── CRI-O └── (未來的新運行時) kubelet只依賴CRI接口不關(guān)心后面是誰 → 換運行時 換CRI實現(xiàn)kubelet零改動要點CRI的本質(zhì)是**“依賴抽象不依賴實現(xiàn)”**——經(jīng)典的依賴倒置原則。kubelet依賴CRI這個抽象接口任何運行時只要實現(xiàn)CRI接口就能被K8s用。這就是為什么第005篇說的K8s干掉Docker其實不疼——kubelet調(diào)的是CRIDocker只是通過dockershim間接實現(xiàn)了CRIdockershim移除后kubelet直接調(diào)containerd的CRI插件更純凈。二、CRI的兩組API2.1 RuntimeService ImageService【CRI 的兩大服務(wù)】 ┌─────────────────────────────────────────────┐ │ RuntimeService (運行時服務(wù)) │ │ 管容器的生老病死 │ │ │ │ ? RunPodSandbox / StopPodSandbox │ │ ? CreateContainer / StartContainer │ │ ? StopContainer / RemoveContainer │ │ ? ListContainers / ContainerStatus │ │ ? Exec / Attach / PortForward │ └─────────────────────────────────────────────┘ ┌─────────────────────────────────────────────┐ │ ImageService (鏡像服務(wù)) │ │ 管鏡像 │ │ │ │ ? PullImage / PushImage │ │ ? ListImages / ImageStatus │ │ ? RemoveImage / ImageFsInfo │ └─────────────────────────────────────────────┘ 兩者通過 gRPC 調(diào)用(默認(rèn) unix socket: /run/containerd/containerd.sock)2.2 Pod Sandbox——CRI的獨特概念【Pod Sandbox (Pod沙箱) —— 先蓋好房子再入住】 關(guān)鍵洞察K8s的世界里最小調(diào)度單元是Pod(不是容器) 但Docker的世界里只有容器沒有Pod! CRI的解決方案Pod Sandbox 1. kubelet先讓運行時創(chuàng)建一個沙箱(Pause容器) → Pause容器創(chuàng)建Pod的網(wǎng)絡(luò)命名空間(netns) → 分配Pod IP 2. 再把Pod里的業(yè)務(wù)容器塞進(jìn)這個沙箱 → 業(yè)務(wù)容器共享Pause的網(wǎng)絡(luò)命名空間 → 這就是Pod內(nèi)共享網(wǎng)絡(luò)的實現(xiàn)(見第008篇) Pause容器(第008篇講過) ? 幾乎啥也不干就占著netns不退出 ? 所有業(yè)務(wù)容器join它的netns → Pod網(wǎng)絡(luò)統(tǒng)一# 看節(jié)點上的Pause容器(每個Pod一個)dockerps|greppause# 或 ctr (containerd命令行)ctr-nk8s.io containers list|greppause三、containerd的CRI插件架構(gòu)3.1 調(diào)用鏈【containerd 內(nèi)部結(jié)構(gòu)(簡化)】 kubelet │ CRI gRPC ▼ ┌─────────────────────────────────┐ │ containerd │ │ ┌───────────────────────────┐ │ │ │ CRI Plugin (內(nèi)置) │ │ ← 實現(xiàn)CRI接口 │ │ ? 處理RunPodSandbox等 │ │ │ │ ? 轉(zhuǎn)成containerd的調(diào)用 │ │ │ └───────────────────────────┘ │ │ ┌───────────────────────────┐ │ │ │ core (容器/鏡像/快照管理) │ │ │ └───────────────────────────┘ │ │ ┌───────────────────────────┐ │ │ │ OCI runtime shim │ │ │ │ (調(diào) runc 創(chuàng)建容器) │ │ │ └───────────────────────────┘ │ └──────────────────┬──────────────┘ │ OCI runtime spec ▼ ┌─────────────────────────────────┐ │ runc (真正創(chuàng)建Linux容器) │ └─────────────────────────────────┘3.2 containerd vs CRI-O運行時背景特點containerdDocker捐給CNCF生態(tài)最大Docker兼容好CRI-O紅帽主導(dǎo)輕量專為K8s設(shè)計無Docker包袱# 看當(dāng)前節(jié)點用哪個CRI運行時kubectl get nodes-owide# CONTAINER-RUNTIME: containerd://1.7.11# 直接用ctr操作containerdctr-nk8s.io images list# 看K8s命名空間下的鏡像要點containerd本來是Docker的核心組件后來獨立成CNCF項目并實現(xiàn)CRI插件成了K8s主流運行時。它在kubelet(CRI)和runc(OCI)之間做轉(zhuǎn)換。CRI-O是紅帽專為K8s打造的更輕量替代。兩者都通過OCI標(biāo)準(zhǔn)調(diào)runc——所以CRI是K8s和運行時之間的標(biāo)準(zhǔn)OCI是運行時和容器之間的標(biāo)準(zhǔn)兩層標(biāo)準(zhǔn)各管一段。四、為什么CRI這么重要4.1 它讓K8s面向未來【CRI 開啟的可能性】 1. 換運行時零成本 → containerd / CRI-O / 未來的WASM運行時 2. 安全運行時崛起 → Kata Containers (VM級隔離) 實現(xiàn)CRI → gVisor (用戶態(tài)內(nèi)核) 實現(xiàn)CRI → 直接用于K8s不用改kubelet 3. Windows容器 → Windows上的容器運行時也實現(xiàn)CRI 4. WASM/wasmedge → WebAssembly運行時也開始實現(xiàn)CRI → 輕量級替代容器(見第090篇)本篇小結(jié)CRI是kubelet和容器運行時之間的標(biāo)準(zhǔn)gRPC接口分RuntimeService容器生命周期和ImageService鏡像兩組。它讓K8s換引擎不換車——kubelet只依賴CRI抽象具體運行時containerd/CRI-O/Kata/gVisor誰實現(xiàn)誰上崗。Pod Sandbox是CRI的獨特設(shè)計kubelet先讓運行時創(chuàng)建一個Pause沙箱容器建立Pod網(wǎng)絡(luò)命名空間、分配IP再把業(yè)務(wù)容器塞進(jìn)去共享網(wǎng)絡(luò)——這就是Pod內(nèi)共享網(wǎng)絡(luò)的落地方式。containerd通過內(nèi)置CRI插件在CRI(gRPC)和runc(OCI)之間做轉(zhuǎn)換。CRI是K8s面向未來的關(guān)鍵——安全容器、WASM運行時都能即插即用。下篇講CNI——網(wǎng)絡(luò)接口標(biāo)準(zhǔn)。上一篇【第65篇】kubelet深度解析——節(jié)點上的“全能管家“起容器、查健康、報狀態(tài)一把抓下一篇【第67篇】CNI深度解析——容器網(wǎng)絡(luò)接口標(biāo)準(zhǔn) 【Kubernetes從入門到精通】第66篇：CRI深度解析——容器運行時接口，K8s能“換引擎“全靠它
上一篇【第65篇】kubelet深度解析——節(jié)點上的“全能管家“起容器、查健康、報狀態(tài)一把抓下一篇【第67篇】CNI深度解析——容器網(wǎng)絡(luò)接口標(biāo)準(zhǔn)摘要上篇我們說kubelet通過CRI調(diào)containerd起容器。你可能會問為什么K8s能隨便換容器引擎早年只用Docker后來把Docker干掉換成containerd/CRI-Okubelet的代碼卻沒重寫答案就是CRIContainer Runtime Interface——K8s在kubelet和容器運行時之間插了一層標(biāo)準(zhǔn)接口。就像USB接口讓電腦能插任何牌子的鼠標(biāo)CRI讓K8s能用任何符合標(biāo)準(zhǔn)的運行時。這篇文章講清CRI的設(shè)計兩組gRPC API、Pod SandboxPod沙箱這個獨特概念、containerd的CRI插件架構(gòu)以及為什么CRI是K8s換引擎不換車的關(guān)鍵。一、CRI是什么1.1 解耦kubelet和運行時【沒有CRI (早期)kubelet 和 Docker 死綁】 kubelet ──直接調(diào)用──? Docker API (代碼里寫死Docker的調(diào)用) 問題 ? 想換運行時改kubelet源碼 ? Docker太重(K8s只用它一小部分能力) ? 升級Docker牽一發(fā)動全身【有CRI (現(xiàn)在)中間一層標(biāo)準(zhǔn)接口】 kubelet ──CRI(gRPC)──? 任意運行時 ├── containerd ├── CRI-O └── (未來的新運行時) kubelet只依賴CRI接口不關(guān)心后面是誰 → 換運行時 換CRI實現(xiàn)kubelet零改動要點CRI的本質(zhì)是**“依賴抽象不依賴實現(xiàn)”**——經(jīng)典的依賴倒置原則。kubelet依賴CRI這個抽象接口任何運行時只要實現(xiàn)CRI接口就能被K8s用。這就是為什么第005篇說的K8s干掉Docker其實不疼——kubelet調(diào)的是CRIDocker只是通過dockershim間接實現(xiàn)了CRIdockershim移除后kubelet直接調(diào)containerd的CRI插件更純凈。二、CRI的兩組API2.1 RuntimeService ImageService【CRI 的兩大服務(wù)】 ┌─────────────────────────────────────────────┐ │ RuntimeService (運行時服務(wù)) │ │ 管容器的生老病死 │ │ │ │ ? RunPodSandbox / StopPodSandbox │ │ ? CreateContainer / StartContainer │ │ ? StopContainer / RemoveContainer │ │ ? ListContainers / ContainerStatus │ │ ? Exec / Attach / PortForward │ └─────────────────────────────────────────────┘ ┌─────────────────────────────────────────────┐ │ ImageService (鏡像服務(wù)) │ │ 管鏡像 │ │ │ │ ? PullImage / PushImage │ │ ? ListImages / ImageStatus │ │ ? RemoveImage / ImageFsInfo │ └─────────────────────────────────────────────┘ 兩者通過 gRPC 調(diào)用(默認(rèn) unix socket: /run/containerd/containerd.sock)2.2 Pod Sandbox——CRI的獨特概念【Pod Sandbox (Pod沙箱) —— 先蓋好房子再入住】 關(guān)鍵洞察K8s的世界里最小調(diào)度單元是Pod(不是容器) 但Docker的世界里只有容器沒有Pod! CRI的解決方案Pod Sandbox 1. kubelet先讓運行時創(chuàng)建一個沙箱(Pause容器) → Pause容器創(chuàng)建Pod的網(wǎng)絡(luò)命名空間(netns) → 分配Pod IP 2. 再把Pod里的業(yè)務(wù)容器塞進(jìn)這個沙箱 → 業(yè)務(wù)容器共享Pause的網(wǎng)絡(luò)命名空間 → 這就是Pod內(nèi)共享網(wǎng)絡(luò)的實現(xiàn)(見第008篇) Pause容器(第008篇講過) ? 幾乎啥也不干就占著netns不退出 ? 所有業(yè)務(wù)容器join它的netns → Pod網(wǎng)絡(luò)統(tǒng)一# 看節(jié)點上的Pause容器(每個Pod一個)dockerps|greppause# 或 ctr (containerd命令行)ctr-nk8s.io containers list|greppause三、containerd的CRI插件架構(gòu)3.1 調(diào)用鏈【containerd 內(nèi)部結(jié)構(gòu)(簡化)】 kubelet │ CRI gRPC ▼ ┌─────────────────────────────────┐ │ containerd │ │ ┌───────────────────────────┐ │ │ │ CRI Plugin (內(nèi)置) │ │ ← 實現(xiàn)CRI接口 │ │ ? 處理RunPodSandbox等 │ │ │ │ ? 轉(zhuǎn)成containerd的調(diào)用 │ │ │ └───────────────────────────┘ │ │ ┌───────────────────────────┐ │ │ │ core (容器/鏡像/快照管理) │ │ │ └───────────────────────────┘ │ │ ┌───────────────────────────┐ │ │ │ OCI runtime shim │ │ │ │ (調(diào) runc 創(chuàng)建容器) │ │ │ └───────────────────────────┘ │ └──────────────────┬──────────────┘ │ OCI runtime spec ▼ ┌─────────────────────────────────┐ │ runc (真正創(chuàng)建Linux容器) │ └─────────────────────────────────┘3.2 containerd vs CRI-O運行時背景特點containerdDocker捐給CNCF生態(tài)最大Docker兼容好CRI-O紅帽主導(dǎo)輕量專為K8s設(shè)計無Docker包袱# 看當(dāng)前節(jié)點用哪個CRI運行時kubectl get nodes-owide# CONTAINER-RUNTIME: containerd://1.7.11# 直接用ctr操作containerdctr-nk8s.io images list# 看K8s命名空間下的鏡像要點containerd本來是Docker的核心組件后來獨立成CNCF項目并實現(xiàn)CRI插件成了K8s主流運行時。它在kubelet(CRI)和runc(OCI)之間做轉(zhuǎn)換。CRI-O是紅帽專為K8s打造的更輕量替代。兩者都通過OCI標(biāo)準(zhǔn)調(diào)runc——所以CRI是K8s和運行時之間的標(biāo)準(zhǔn)OCI是運行時和容器之間的標(biāo)準(zhǔn)兩層標(biāo)準(zhǔn)各管一段。四、為什么CRI這么重要4.1 它讓K8s面向未來【CRI 開啟的可能性】 1. 換運行時零成本 → containerd / CRI-O / 未來的WASM運行時 2. 安全運行時崛起 → Kata Containers (VM級隔離) 實現(xiàn)CRI → gVisor (用戶態(tài)內(nèi)核) 實現(xiàn)CRI → 直接用于K8s不用改kubelet 3. Windows容器 → Windows上的容器運行時也實現(xiàn)CRI 4. WASM/wasmedge → WebAssembly運行時也開始實現(xiàn)CRI → 輕量級替代容器(見第090篇)本篇小結(jié)CRI是kubelet和容器運行時之間的標(biāo)準(zhǔn)gRPC接口分RuntimeService容器生命周期和ImageService鏡像兩組。它讓K8s換引擎不換車——kubelet只依賴CRI抽象具體運行時containerd/CRI-O/Kata/gVisor誰實現(xiàn)誰上崗。Pod Sandbox是CRI的獨特設(shè)計kubelet先讓運行時創(chuàng)建一個Pause沙箱容器建立Pod網(wǎng)絡(luò)命名空間、分配IP再把業(yè)務(wù)容器塞進(jìn)去共享網(wǎng)絡(luò)——這就是Pod內(nèi)共享網(wǎng)絡(luò)的落地方式。containerd通過內(nèi)置CRI插件在CRI(gRPC)和runc(OCI)之間做轉(zhuǎn)換。CRI是K8s面向未來的關(guān)鍵——安全容器、WASM運行時都能即插即用。下篇講CNI——網(wǎng)絡(luò)接口標(biāo)準(zhǔn)。上一篇【第65篇】kubelet深度解析——節(jié)點上的“全能管家“起容器、查健康、報狀態(tài)一把抓下一篇【第67篇】CNI深度解析——容器網(wǎng)絡(luò)接口標(biāo)準(zhǔn)