解析 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 等运行特权应用，而行使强断绝容器引擎运行平凡应用。好比，典范的组合为：
（编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
