[Kubernetes] CRI 的设计与工做原理

我们来看看,有了 CRI 以后, Kubernetes 的架构图:

咱们能够看到, CRI 机制可以发挥做用的核心,在于每个容器项目如今均可以本身实现一个 CRI shim ,自行对 CRI 请求进行处理.这样, Kubernetes 就有了一个统一的容器抽象层,使得下层容器在运行的时候,能够自由地对接,从而进入 Kubernetes 当中去.
做为一个 CRI shim , container 对 CRI 的具体实现,又是怎样的呢?这个时候,咱们就须要去看看 CRI 这个接口的定义里面都有什么了.

咱们可以看到, CRI 待实现接口,主要有两类:

• RuntimeService .它提供的接口,主要就是和容器有关的操做.好比,建立和启动容器,删除容器,执行 exec 命令等.
• ImageService .它提供的接口,主要是和容器镜像相关的操做,好比 拉取镜像,删除镜像等等.

我们主要来看 RuntimeService 这一部分.在这里, CRI 设计的一个重要原则,就是确保这个接口自己,只关注容器,不关注 Pod .之因此这样的缘由有两个:第一, Pod 是 Kubernetes 的编排概念,而不是容器运行时的概念,因此就不能假设全部的下层容器项目,都可以暴露出能够直接映射为 Pod 的 API .第二,若是 CRI 里面引入了 Pod 的概念,那么只要 Pod API 对象的字段发生变化,那么 CRI 就颇有可能须要变动.基于以上缘由, CRI 设计中,并无一个直接建立 Pod 或者启动 Pod 的接口.
CRI shim 还有一个重要的工做,就是如何实现 exec , logs 等接口.这些接口不一样在于, gRPC 接口调用期间, kubelet 须要和容器项目维护一个长链接来传输数据.这种 API ,就称之为 Streaming API .
CRI shim 中对 Streaming API 的实现,依赖于一套独立的 Streaming Server 机制,以下:

当对一个容器执行 kubectl exec 命令时,这个请求首先会交给 API Server , 而后 API Server 就会调用 kubelet 的 Exec API .此时, kubelet 会调用 CRI 的 Exec 接口,而负责响应这个接口的,就是 CRI shim .可是在这一步, CRI shim 并不会直接去调用后端的容器项目(好比 Docker )来进行处理,而只会返回一个 URL 给 kubelet .这个 URL ,就是该 CRI shim 对应的 Streaming Server 的地址和端口.
kubelet 在拿到这个 URL 以后,就会把它以 Redirect 的方式返回给 API Server .因此这个时候, API Server 就会经过重定向来向 Streaming Server 发起真正的 /exec 请求,和它创建长链接.
Stream Server 这一部分具体怎么实现,彻底能够由 CRI shim 的维护者自行决定.

因此, CRI 这个接口的设计,实际上仍是比较宽松的.这就意味着,做为容器项目的维护者,在实现 CRI 的具体接口时,每每拥有着很高的自由度,这个自由度不只包括了容器的生命周期管理,也包括了如何将 Pod 映射成本身的实现,还包括了如何调用 CNI 插件来为 Pod 设置网络的过程.
基于此,当你对容器这一层有特殊的需求时,优先建议考虑实现一个本身的 CRI shim .

以上就是关于 CRI 的设计与工做原理的一些内容了.
以上内容来自我学习<深刻剖析Kubernetes>专栏文章以后的一些看法,有偏颇之处,还望指出.
感谢您的阅读~