歸根結底，Kubernetes Node(kubelet)的主要功能就是啟動和停止 容器的組件，我們稱之為容器運行時(Container Runtime)，其中最知 名的就是Docker了。為了更具擴展性，Kubernetes從1.5版本開始就加入 了容器運行時插件API，即Container Runtime Interface，簡稱CRI。
每個容器運行時都有特點，因此不少用戶希望Kubernetes能夠支持 更多的容器運行時。Kubernetes從1.5版本開始引入了CRI接口規范，通 過插件接口模式，Kubernetes無須重新編譯就可以使用更多的容器運行 時。CRI包含Protocol Buffers、gRPC API、運行庫支持及開發中的標准 規范和工具。Docker的CRI實現在Kubernetes 1.6中被更新為Beta版本， 並在kubelet啟動時默認啟動。
可替代的容器運行時支持是Kubernetes中的新概念。在Kubernetes 1.3發布時，rktnetes項目同時發布，讓rkt容器引擎成為除Docker外的又 一選擇。然而，不管是Docker還是rkt，都用到了kubelet的內部接口，同 kubelet源碼糾纏不清。這種程度的集成需要對kubelet的內部機制有非常 深入的了解，還會給社區帶來管理壓力，這就給新生代容器運行時造成 了難於跨越的集成壁壘。CRI接口規范試圖用定義清晰的抽象層清除這 一壁壘，讓開發者能夠專注於容器運行時本身。在通向插件式容器支持 及建設健康生態環境的路上，這是一小步，也是很重要的一步。
kubelet使用gRPC框架通過UNIX Socket與容器運行時(或CRI代 理)進行通信。在這個過程中kubelet是客戶端，CRI代理(shim)是服 務端，如圖2.3所示。
圖2.3 CRI的主要組件
Protocol Buffers API包含兩個gRPC服務:ImageService和
RuntimeService。
ImageService提供了從倉庫拉取鏡像、查看和移除鏡像的功能。
RuntimeService負責Pod和容器的生命周期管理，以及與容器的交互 (exec/attach/port-forward)。rkt和Docker這樣的容器運行時可以使用一 個Socket同時提供兩個服務，在kubelet中可以用--container-runtime- endpoint和--image-service-endpoint參數設置這個Socket。
文章來源於k8s指南