Kubernetes 容器运行时演进

关注
发布于: 2020 年 04 月 23 日
Kubernetes 已经成为容器编排调度领域的事实标准，其优良的架构不仅保证了丰富的容器编排调度功能，同时也提供了各个层次的扩展接口以满足用户的定制化需求。其中，容器运行时作为 Kubernetes 管理和运行容器的关键组件，当然也提供了简便易用的扩展接口，也就是 CRI（Container Runtime Interface）。
﻿
本文将介绍 CRI 的由来、演进以及未来展望，主要内容分为四个部分：Kubernetes架构简介、容器运行时接口的基本原理、容器运行时的演进以及未来的展望。
Kubernetes 简介﻿
我们知道，Kubernetes是一个开源的容器集群管理系统，它的发展非常迅速，已经成为最流行和最活跃的容器编排系统。
﻿
从架构上来说，Kubernetes 的组件可以分为 Master 和 Node 两部分，其中 Master 是整个集群的大脑，所有的编排、调度、API 访问等都由 Master 来负责。
﻿
﻿
具体的来说，Master 包括以下几个组件：
﻿
etcd 保存了整个集群的状态。
kube-apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制。并且无论是集群内部还是外部的组件，都必须通过API Server来访问数据。
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 功能的方式：
* 第一种是扩展（Addon），比如 dashboard、EFK、Prometheus、各种 Operator 等，这些扩展不需要 Kubernetes 提供标准的接口，但是都为 Kubernetes 增加了新的功能特性；
* 还有一种方式则是插件（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的网络模型保持一致。
﻿
CRI 的推出为容器社区带来了新的繁荣，cri-o、frakti、cri-containerd 等一些列的容器运行时为不同场景而生：
﻿
cri-containerd——基于 containerd 的容器运行时
cri-o——基于 OCI 的容器运行时
frakti——基于虚拟化的容器运行时
﻿
而基于这些容器运行时，还可以轻易联结新型的容器引擎，比如可以通过 clear container、gVisor 等新的容器引擎配合 cri-o 或 cri-containerd 等轻易接入 Kubernetes，将 Kubernetes 的应用场景扩展到了传统 IaaS 才能实现的强隔离和多租户场景。
﻿
当使用CRI运行时，需要配置kubelet的--container-runtime参数为remote，并设置--container-runtime-endpoint为监听的unix socket位置（Windows上面为 tcp 或 npipe）。
﻿
CRI 接口﻿
那么，CRI 接口到底长的什么样呢？
﻿
CRI 接口包括 RuntimeService 和 ImageService 两个服务，这两个服务可以在一个 gRPC server 里面实现，当然也可以分开成两个独立服务。目前社区的很多运行时都是将其在一个 gRPC server 里面实现。
﻿
﻿
管理镜像的 ImageService 提供了 5 个接口，分别是查询镜像列表、拉取镜像到本地、查询镜像状态、删除本地镜像以及查询镜像占用空间等。这些都很容易映射到 docker API 或者 CLI 上面。
﻿
而 RuntimeService 则提供了更多的接口，按照功能可以划分为四组：
﻿
PodSandbox 的管理接口：PodSandbox 是对 Kubernete Pod 的抽象，用来给容器提供一个隔离的环境（比如挂载到相同的 cgroup 下面），并提供网络等共享的命名空间。PodSandbox 通常对应到一个 Pause 容器或者一台虚拟机。
Container 的管理接口：在指定的 PodSandbox 中创建、启动、停止和删除容器。
Streaming API 接口：包括 Exec、Attach 和 PortForward 等三个和容器进行数据交互的接口，这三个接口返回的是运行时 Streaming Server 的 URL，而不是直接跟容器交互。
状态接口，包括查询 API 版本和查询运行时状态。
Streaming APIStreaming API 用于客户端与容器需要交互的场景，所以采用的是流式接口，包括 Exec、PortForward 和 Attach 等。Kubelet 内置的 docker 通过 nsenter、socat 等方法来支持这些特性，但它们不一定适用于其他的运行时。因而，CRI 也显式定义了这些 API，并且要求容器运行时返回一个 streaming server 的 URL 以便 Kubelet 重定向 API Server 发送过来的流式请求。
﻿
这样一个完整的 Exec 流程就是
﻿
客户端 kubectl exec -i -t ...
kube-apiserver 向 Kubelet 发送流式请求 /exec/
Kubelet 通过 CRI 接口向 CRI Shim 请求 Exec 的 URL
CRI Shim 向 Kubelet 返回 Exec URL
Kubelet 向 kube-apiserver 返回重定向的响应
kube-apiserver 重定向流式请求到 Exec URL，接着就是 CRI Shim 内部的 Streaming Server 跟 kube-apiserver 进行数据交互，完成 Exec 的请求和响应
﻿
在 v1.10 及更早版本中，容器运行时必需返回一个 API Server 可直接访问的 URL（通常跟 Kubelet 使用相同的监听地址）；而从 v1.11 开始，Kubelet 新增了 --redirect-container-streaming（默认为 false），默认不再转发而是代理 Streaming 请求，这样运行时可以返回一个 localhost 的 URL。通过 Kubelet 代理的好处是由 Kubelet 处理与 API server 通信之间的请求认证。
﻿
实际上，各个运行时 streaming server 的处理框架都是类似的，因而 Kubelet 也提供来一个 steaming server  库，方便容器运行时的开发者引用。这个库在 Kubelet 的代码中，请参考 https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/server/streaming。
﻿
容器运行时演进过程﻿
了解了容器运行时接口的基本原理之后，接下来，我们再来看一下容器运行时的演进过程。
﻿
容器运行时的演进可以分为三个阶段：
﻿
首先，在 Kubernetes v1.5 之前，Kubelet 内置了 Docker 和 rkt 的支持，并且通过 CNI 网络插件给它们配置容器网络。这个阶段的用户如果需要自定义运行时的功能是比较痛苦的，需要修改 Kubelet 的代码，并且很有可能这些修改无法推到上游社区。这样，还需要维护一个自己的 fork 仓库，维护和升级都非常麻烦。
﻿
不同用户实现的容器运行时各有所长，许多用户都希望Kubernetes支持自定义的运行时。于是，从v1.5 开始增加了 CRI 接口，通过容器运行时的抽象层消除了这些障碍，使得无需修改 Kubelet 就可以支持运行多种容器运行时。CRI 接口包括了一组 Protocol Buffer、gRPC API 、用于 streaming 接口的库以及用于调试和验证的一系列工具等。在此阶段，内置的 Docker 实现也逐步迁移到了 CRI 的接口之下。但此时 rkt 还未完全迁移，这是因为 rkt 迁移 CRI 的过程将在独立的 repository 完成，方便其维护和管理。
﻿
第三阶段，从 v1.11 开始，Kubelet 内置的 rkt 代码删除，CNI 的实现迁移到 dockershim 之内。这样，除了 docker 之外，其他的容器运行时都通过 CRI 接入。外部的容器运行时除了实现 CRI 接口外，也要负责为容器配置网络。一般推荐使用 CNI，因为这样可以支持社区内的众多网络插件，不过这不是必需的，网络插件只需要满足 Kubernetes 网络的基本假设即可，即 IP-per-Pod、所有 Pod 和 Node 都可以直接通过 IP 相互访问。
﻿
CRI 容器运行时﻿
CRI 的推出为容器社区带来了新的繁荣，适用于各种不同场景的运行时也应运而生。比如：
﻿
﻿
这里也注意区分 CRI 容器运行时与容器引擎的区别：
﻿
CRI 容器运行时是指实现了 Kubelet CRI 接口的运行时，这样就可以无缝集成到 Kubernetes 之中。
容器引擎只是负责管理容器镜像和容器运行的一个服务，它也有一个标准是 OCI（Open Container Initiative）。
﻿
比如 CNCF 的 Container Runtime Landscape 中包括了一些列的“Container Runtime”，这其中有一些是实现了 CRI 的，比如 cri-o；而更多的则只是一个容器引擎，需要通过 cri-o、cri-containerd 等才可以应用到 Kubernetes 之中。
﻿
CRI Tools﻿
CRI Tools 对 Kubernetes 容器运行时和容器应用的排错来说是一个非常有用的工具。它是一个 SIG Node 所属的子项目，可以应用到所有实现了 CRI 接口的容器运行时中。CRI Tools 包括两个组件，crictl 用于排错和调试，而 critest 用于容器运行时实现进行一致性验证。
crictl﻿
先来看 crictl。crictl 提供了一个类似了 docker 命令的命令行工具。在排错或者调试容器应用时，有时候系统管理员需要登录到节点上去查看容器或镜像的状态，以便收集系统和容器应用的信息。这时候，推荐使用 crictl 来完成这些工作，因为 crictl 为所有不同的容器引擎都提供了一个一致的使用体验。
﻿
从使用上来说，crictl 的使用非常类似于 docker 命令行工具，比如你可以使用 crictl pods 来查询 PodSandbox 的列表、使用 crictl ps 来查询容器的列表、使用 crictl images 查询镜像列表。
﻿
需要注意的是，crictl 的设计目标是排错，而并非 docker 或者 kubectl 等的替代品。比如，由于 CRI 并没有定义镜像构建的接口，crictl 并不提供 docker build 这种构建镜像的功能。但由于 crictl 提供了一个面向 Kubernetes 的接口，相对于 docker 来说，crictl 可以提供一个对容器和 Pod 更清晰的视图。
﻿
critest﻿
critest 是一个容器运行时的一致性验证工具，用于验证容器运行时是否符合 Kubelet CRI 的要求。它是 CRI TOOLS 工具的一部分。除了验证测试，critest 还提供了 CRI 接口的性能测试，比如 critest -benchmark。
﻿
推荐将 critest 集成到 CRI 容器运行时的 Devops 流程中，保证每个变更都不会破坏 CRI 的基本功能。
﻿
另外，还可以选择将 critest 与 Kubernetes Node E2E 的测试结果提交到 Sig-node 的 TestGrid，向社区和用户展示。
﻿
未来展望﻿
Docker 运行时拆分﻿
目前 Docker 是内置在 Kubelet 中的一个运行时，也是默认的容器运行时。这样，实际上 Kubelet 就会依赖于 Docker，从而为 Kubelet 本身带来一定的维护负担。
﻿
比如，Kubelet 内部有些功能可能只是适用于 Docker 运行时。当 Docker 或者 Docker 依赖的其他组件（比如 containerd、runc）发现严重缺陷时，修复这些缺陷就需要重现编译和发布 Kubelet。
﻿
此外，当用户想要在 Docker 运行时中新增功能时，这些新增的功能可能并不容易引入到 Kubelet 中，特别是三个月的发布周期中，新的特性通常不会引入到现有的稳定分支中。从 Docker 运行时的角度来说，新特性的引入通常也会比较缓慢。
﻿
所以，拆分 Docker 容器引擎，将其独立出去成为一个 cri-docker 就可以解决上述的所有问题。
﻿
﻿
由于 Docker 作为默认的容器引擎，在生产环境中已经得到广泛应用，拆分和迁移会应用绝大部分用户，因为具体的迁移方法还需要社区的详细讨论。
﻿
强隔离容器引擎﻿
虽然 Kubernetes 提供了基本的多租户功能，可以不同应用放到不同 namespace 中进行隔离，也可以使用 RBAC 控制不同用户对各类资源的访问，但由于 Docker 共享内核的特性，在 Kubernetes 中运行不可信应用时还是有很大的安全隐患。为了消除这个问题，强隔离容器引擎应运而生。
﻿
最早的强隔离容器引擎就是 Kata containers 的前身 hyperd 和 clear container，它将 Kubernetes Pod 作为一个虚拟机来运行，这样就可以通过虚拟化的方式对容器应用进行强隔离。虚拟化是整个云计算中 IaaS 的基础，它的安全性已经得到了广泛验证，因而其安全性也就得到了保证。这两个项目目前已经合并成为 Kata containers。
﻿
除了 Kata containers 之外，Google 和 AWS 也在推进强隔离的容器引擎，也就是 gVisor 和 Firecraker。
﻿
跟 Kata containers 不同，gVisor 并不会去创建一个完整的 VM，而是实现了一个自己的沙箱（文档成为用户态内核），拦截和过滤容器的 syscall，从而达到安全隔离的目的。虽然 gVisor 相对于 VM 来说更轻量化，但拦截过滤也会带来很高的成本，对最终容器应用的性能会造成一定损失。
﻿
同样的，Firecraker 基于 KVM 实现了一个轻量级的 VM，称为 microVM。跟 Kata 不同的是，它没有使用 QEMU，而是用 Rust 构建了一套精简的设备模型，从而让每个 microVM 只占用大约 5MB 的内存。
﻿
多容器运行时﻿
有了强隔离的容器引擎后，不可避免的就出现了一些新的问题。比如，很多 Kubernetes 自身的服务或者扩展由于需要 HostNetwork 或特权模式，无法运行在强隔离的环境中。所以，多容器运行时也就应运而生了。
﻿
这样，就可以使用 runc/docker 等运行特权应用，而使用强隔离容器引擎运行普通应用。比如，典型的组合为：
﻿
runc + kata
runc + gVisor
Windows server containers + Hyper-V containers
﻿
以前，很多容器运行时都是在 CRI Shim 中支持多个容器引擎，并通过 Annotations 的形式选择。而借助于新的 RuntimeClass 资源，就可以直接通过 Pod Spec 来选择不同的 runtime。
﻿
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
 name: myclas
# RuntimeClass is non-namespaced
handler: myconfiguration
---
apiVersion: v1
kind: Pod
metadata:
 name: mypod
spec:
 runtimeClassName: myclass
 # ...
﻿
RuntimeClass 本身还处在比较早期的阶段，未来还会继续在调度等方面进一步增强。
﻿
﻿