解析 Kubernetes 容器运行时

Kubernetes 已经成为容器编排调度领域的事实标准，其优良的架构不仅保证了丰富的容器编排调度功能，同时也提供了各个层次的扩展接口以满足用户的定制化需求。其中，容器运行时作为 Kubernetes 管理和运行容器的关键组件，当然也提供了简便易用的扩展接口，也就是 CRI(Container Runtime Interface)。

本文将介绍 CRI 的由来、演进以及未来展望，主要内容分为四个部分：Kubernetes架构简介、容器运行时接口的基本原理、容器运行时的演进以及未来的展望。

Kubernetes 简介

我们知道，Kubernetes是一个开源的容器集群管理系统，它的发展非常迅速，已经成为最流行和最活跃的容器编排系统。

从架构上来说，Kubernetes 的组件可以分为 Master 和 Node 两部分，其中 Master 是整个集群的大脑，所有的编排、调度、API 访问等都由 Master 来负责。

具体的来说，Master 包括以下几个组件：

• etcd 保存了整个集群的状态。
• kube-apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制。
• kube-controller-manager 负责维护集群的状态，包括很多资源的控制器，是保证 Kubernetes 声明式 API 工作的大脑。
• kube-scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的 Node 上;

而 Node 则是负责运行具体的容器，并为容器提供存储、网络等必要的功能：

• kubelet 负责维持容器的生命周期，同时也负责 Volume(CSI)和网络(CNI)的管理;
• Container runtime 负责镜像管理以及 Pod 和容器的真正运行。Kubelet 默认的容器运行时为 Docker;
• kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡
• Network plugin 也就基于 CNI(Container Network Internface)负责为容器配置网络。

除了这些核心的组件以外，Kubernetes 当然还包含了很多丰富的功能，这些都是通过扩展(Addon)的方式来部署的。比如 kube-dns 和 metrics-server 等，都是以容器的方式部署在集群里面，并提供 API 给其他组件调用。

提示：在 Kubernetes 中，通常你可以听到两种不同类型的扩展 Kubernetes 功能的方式：1) 第一种是扩展(Addon)，比如 dashboard、EFK、Prometheus、各种 Operator 等，这些扩展不需要 Kubernetes 提供标准的接口，但是都为 Kubernetes 增加了新的功能特性;2) 还有一种方式则是插件(Plugin)，比如 CNI、CRI、CSI、Device Plugin 等，这些都是 Kubernetes 各个核心组件提供了标准的内置接口，而外部插件则是实现这些接口，从而将 Kubernetes 扩展到更多的用例场景中。

Kubelet 架构

刚才提到，Kubelet 负责维持容器的生命周期。除此之外，它也配合 kube-controller-manager 管理容器的存储卷，并配合 CNI 管理容器的网络。下面就是 Kubelet 的简单架构示意图：

你可以发现，Kubelet 也是有很多组件构成，包括

• Kubelet Server 对外提供 API，供 kube-apiserver、metrics-server 等服务调用。比如 kubectl exec 需要通过 Kubelet API /exec/{token} 与容器进行交互。
• Container Manager 管理容器的各种资源，比如 cgroups、QoS、cpuset、device 等。
• Volume Manager 管理容器的存储卷，比如格式化磁盘、挂载到 Node 本地、最后再将挂载路径传给容器。
• Eviction 负责容器的驱逐，比如在资源不足时驱逐优先级低的容器，保证高优先级容器的运行。
• cAdvisor 负责为容器提供 metrics 数据源。
• Metrics 和 stats 提供容器和节点的度量数据，比如 metrics-server 通过 /stats/summary 提取的度量数据是 HPA 自动扩展的依据。
• 再向下就是 Generic Runtime Manager，这是容器运行时的管理者，负责跟 CRI 交互，完成容器和镜像的管理。
• 在 CRI 之下，包括两种容器运行时的实现
• 一个是内置的 dockershim，实现了 docker 容器引擎的支持以及 CNI 网络插件(包括 kubenet)的支持
• 另一个就是外部的容器运行时，用来支持 runc、containerd、gvisor 等外部容器运行时。

Kubelet 通过 CRI 接口跟外部容器运行时交互，而上图右侧就是 CRI 容器运行时的架构。它通常包括以下几个组件：

• CRI Server，这是 CRI gRPC server，监听在 unix socket 上面。在讨论容器运行时的时候，这个 Server 也通常成为 CRI shim(夹在容器引擎和Kubelet之间的一层)。
• Streaming Server，提供 streaming API，用在 Exec、Attach、Port Forward 等流式接口上。
• 容器和镜像的管理，比如拉取镜像、创建和启动容器等。
• CNI 网络插件的支持，用于给容器配置网络。
• 最后是容器引擎(Container Engine)的管理，比如支持 runc 、containerd 或者支持多个容器引擎。

这样，Kubernetes 中的容器运行时按照不同的功能就可以分为三个部分：

• 第一个是 Kubelet 中容器运行时的管理模块 Generic Runtime Manager，它通过 CRI 来管理容器和镜像。
• 第二个是容器运行时接口，是 Kubelet 与外部容器运行时的通信接口。
• 第三个是具体的容器运行时实现，包括 Kubelet 内置的 dockershim 以及外部的容器运行时(如 cri-o、cri-containerd 等)。

容器运行时接口(CRI)

容器运行时接口(CRI)，顾名思义，用来在 Kubernetes 扩展容器运行时，从而用户可以选择自己喜欢的容器引擎。

CRI 是基于 gPRC 的，用户不需要关心内部通信逻辑，而只需要实现定义的接口就可以，包括 RuntimeService 和 ImageService: RuntimeService负责管理Pod和容器的生命周期，而ImageService负责镜像的生命周期管理。

除了 gRPC API，CRI 还包括用于实现 streaming server 的库(用于 Exec、Attach、PortForward 等接口)和 CRI Tools。这两个稍后再作详细介绍。

基于 CRI 接口的容器运行时通常称为 CRI shim， 这是一个 gRPC Server，监听在本地的unix socket上;而kubelet作为gRPC的客户端来调用CRI接口。

另外，外部容器运行时需要自己负责管理容器的网络，推荐使用CNI，这样跟Kubernetes的网络模型保持一致。

（编辑：ASP站长网）