解析 Kubernetes 容器运行时
|
CRI 的推出为容器社区带来了新的繁荣，适用于各种不同场景的运行时也应运而生。比如：  这里也注意区分 CRI 容器运行时与容器引擎的区别：
比如 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 等运行特权应用，而使用强隔离容器引擎运行普通应用。比如，典型的组合为：
（编辑：宁德站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
