器运行时是执行容器并在节点上管理容器镜像的软件,目前,最广为人知的容器运行时是Docker,但在生态系统中还有其余容器运行时软件,好比Rkt、Containerd和Lxd。Docker是如今于Kubernetes环境中使用的最多见的容器运行时,今天数人云给你们推荐一个Docker的组件——Containerd,它多是更好的选择。html
本文是由谷歌的软件工程师Lantao Liu和IBM的开源开发者Mike Brown基于自身相关实践,共同编写。node
Kubernetes 1.5引入了一个名为容器运行时接口(CRI)的内部插件API,以方便地访问不一样的容器运行时,CRI容许Kubernetes使用各类容器运行时,而不须要从新编译。从理论上说,Kubernetes能够使用任何实现CRI的容器运行时管理容器和容器镜像。linux
在过去的6个月中,来自Google、Docker、IBM、中兴和ZJU的工程师们一直在努力为CRI For Containerd,这个项目被称为cri-containerd,用户能够使用容器做为底层运行时运行Kubernetes集群,而且无需安装Docker。git
Containerd是一个兼容OCI的核心容器运行时,它被设计为嵌入到更大的系统当中,提供了在一个节点上执行容器和管理镜像的最小功能集,它是由Docker公司发起,并于2017年3月加入了CNCF,Docker引擎自己是创建在早期版本的容器之上,而且很快将更新到最新版本。github
与Docker相比,Containerd的规模要小得多,提供了Golang客户端API,并且更专一于可嵌入,较小范围会致使一个更小的代码库,随着时间的推移,其更容器维护以及匹配Kubernetes的需求,以下图所示:网络
综上所述,从技术的角度来看,Containerd是Kubernetes的容器进行时比较好的选择。框架
Cri-Containerd是对于容器的一个实现,它在与Kubelet和 Containerd相同的节点上运行,在Kuberntes和Containerd之间的分层中,Cri-Containerd处理来自Kubelet的全部国际服务请求,并使用Containerd管理容器和容器镜像,Cri-Containerd管理这些服务请求,在必定程度上是经过造成Containerd服务请求,同时添加足够的附加功能来去支持CRI需求。ide
与当前的Docker CRI实现(Dockershim)相比,Cri-Containerd消除了栈中的额外跳转,使堆栈更加稳定和高效。工具
能够经过下面这个例子来演示当Kubele建立一个单一容器的时候,如何使用Cri-Containerd。测试
Kubelet经过国际运行时服务API调用了Cri-Containerd,用以建立一个Pod;
Cri-Containerd使用Containerd建立和启动一个特殊的暂停容器(沙箱容器),并将该容器放在Pod的Cgroups和名称空间中;
Containerd使用CNI配置了Pod的网络名称空间;
Kubelet随后经过国际服务API调用了“容器”,以拉出应用程序的容器的镜像;
若是镜像不存在于节点,则Cri-Containerd将进一步使用Containerd来拉出镜像;
而后,Kubelet经过“CRI”服务API调了“Cri-Containerd”经过拉取容器的镜像来建立和启动应用程序容器;
Cri-Containerd最终调用Containerd来建立应用程序容器,将其放入Pod的Cgroups和命名空间中,而后启动该容器的新应用程序容器。
在这些步骤以后,将建立并运行一个Pod及其相应的应用程序容器。
Cri-Containerd V1.0.0-alpha.0是在2017年9月25日发布的。
其功能完备,全部的Kubernetes的特性都获得了支持。
全部的CRI validation test(CRI validation test是一种测试框架,用于验证是否符合Kubernetes的全部要求。地址:https://github.com/kubernetes...)
全部的 Node e2e Test都已经过(用于测试Kubernetes节点级功能的测试框架如Managing Pods、Mounting Volumes等,地址:https://github.com/kubernetes...)。
若想了解更多关于V1.0-Alpha的相关内容,请前往:https://github.com/kubernetes...
对于一个多节点集群安装程序,并使用能应用和Kubeadm启动步骤请参见:https://github.com/kubernetes...
若想在Google云端从头建立一个集群,请参见:https://github.com/kelseyhigh...
对于一个自发布Tarball的自定义安装,请参见:https://github.com/kubernetes...
对于在本地VM上安装LinuxKit,请参见:https://github.com/linuxkit/l...
Containerd承诺,在下一阶段将主要改进稳定性和可用性方面的问题:
稳定性:
在Kubernetes的测试基础设施上创建一套完整的Kubernetes集成测试,包括Ubuntu、COS(容器化的OS 地址:https://cloud.google.com/cont...)等等。
积极解决用户报告的任何测试失败和其余问题。
可用性:
提升Crictl(https://github.com/kubernetes...)的用户体验,Crictl是全部的CRI容器运行时的可移植命令行工具,这里的目标是使其易于用于调试和开发场景。
集成Kube-up.sh(https://kubernetes.io/docs/ge...)帮助用户使用Cri-Containerd来提升Kubernetes集群的生产质量。
改进文档。
预计在2017年末发布V1.0-Beta。
Cri-Containerd是一个Kubernetes的孵化器项目,地址:ttps://github.com/kubernetes-incubator/cri-containerd。欢迎提供任何具备建设性的意见和建议,具体的使用入门指南请参见:https://github.com/kubernetes...
Cri-Containerd是由Kubernetes Signode社区开发和维护的,若有相关的建议,能够加入社区:
Sig-Node社区网站:https://github.com/kubernetes...
Slack:Kubernetes(kubernet.slack.com)的sig-节点通道:https://kubernetes.slack.com/
原文做者:Kubernetes
原文连接:http://blog.kubernetes.io/201...