containerd是一个开源的行业标准容器运行时，主打简单性、稳定性和可移植性，同时支持Linux和Windows。2016年12月14日，Docker宣布将DockerEngine的核心组件containerd捐赠给一个新的开源社区，由其独立开发和运营。阿里云、AWS、谷歌、IBM和微软是共同建设containerd社区的首批成员。2017年3月，Docker将containerd捐赠给了CNCF（云原生计算基金会）。containerd得到了迅速的发展和广泛的支持。Docker引擎已经使用containerd作为容器生命周期管理的基础，Kubernetes于2018年5月正式支持containerd作为容器运行时管理器。2019年2月，CNCF宣布containerd毕业并成为生产就绪项目。containerd从1.1版本开始就内置了ContainerRuntimeInterface(CRI)支持，进一步简化了对Kubernetes的支持。其架构图如下：在Kubernetes场景下，containerd与完整的DockerEngine相比，资源占用更少，启动速度更快。来源containerdRedHat主导的cri-o是一个与containerd竞争的容器运行时管理项目。与cri-o项目相比，containerd在性能和更广泛的社区支持方面具有优势。更重要的是，containerd提供了一种灵活的扩展机制，支持各种符合OCI（OpenContainerInitiative）的容器运行时实现，例如runc容器（也称为Docker容器）、KataContainer、gVisor和Firecraker。沙盒容器。在Kubernetes环境中，可以使用不同的API和命令行工具来管理容器/Pod和镜像等概念。为了让大家更容易理解，我们可以用下图来说明如何使用不同层次的API和CLI来管理容器的生命周期管理。kubectl：是集群层面的命令行工具，支持Kubernetes的基本概念crictl：是节点上CRI的命令行工具，documentctr：是containerd的命令行工具，以及document体验Minikube就是体验containerd作为Kubernetes容器运行时的最简单的方式，下面我们将其作为Kubernetes容器运行时，支持runc和gvisor两种不同的实现。早期由于网络原因，很多朋友无法直接使用官方的Minikube进行实验。在最新的Minikube1.5版本中，已经提供了完整的配置方法，可以帮助您使用阿里云的镜像地址获取所需的Docker镜像和配置，支持Docker/Containerd等不同的容器运行时。我们创建一个Minikube虚拟机环境。详情请参考https://yq.aliyun.com/articles/221687。请注意，您需要指定--container-runtime=containerd参数以将containerd设置为容器运行时。同时registry-mirror也要换成自己的阿里云镜像加速地址。$minikubestart--image-mirror-countrycn\--iso-url=https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.5.0.iso\--registry-mirror=https://XXX.mirror.aliyuncs.com\--container-runtime=containerdMinikubev1.5.0onDarwin10.14.6自动选择'hyperkit'driver(alternates:[virtualbox])?inyourlocationNoneof已知的存储库是可访问的。Registry.cn-hangzhou.aliyuncs.com/google_containers被用作后备存储库。Creatingahyperkitvirtualmachine(CPUs=2,Memory=2000MB,Disk=20000MB)...?VM无法连接到所选镜像仓库：命令失败：curl-sShttps://k8s.gcr.io/stdout:stderr:curl:(7)无法连接到k8s.gcr.io端口443：连接超时：进程退出，状态为7正在containerd1.2.8中准备Kubernetesv1.16.2...正在拉取图像...正在启动Kubernetes。..?等待：apiserveretcdschedulercontroller完成！kubectl已配置为“minikube”$minikubedashboard正在验证仪表板运行状况...正在启动代理...正在验证代理运行状况...正在打开http://127.0.0.1:54438/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/在你的默认浏览器中...部署一个测试应用我们通过Pod部署一个nginx应用$catnginx.yamlapiVersion:v1kind:Podmetadata:name:nginxspec:containers:-name:nginximage:nginx$kubectlapply-fnginx.yamlpod/nginxcreated$kubectlexecnginx--uname-aLinuxnginx4.19.76#1SMP10月25日星期五16:07:41PDT2019x86_64GNU/Linux然后，我们启用minikube以支持gvisor$minikubeaddonsenablegvisorgvisor已成功启用$kubectlgetpod,runtimeclassgvisor-nkube-systemNAMEREADYSTATUSRESTARTSAGEpod/gvisor1/1Running060mNAMECREATEDATruntimeclass.node.k8s.io/gvisor2019-10-27T01:40:45Z$kubectlgetruntimeClassNAMECREATEDATgvisor2019-10-27T01:40:45Z当gvisorpod进入Running状态后，就可以部署gvisor测试应用了。我们可以看到K8s集群注册了一个gvisor的“runtimeClassName”。之后，开发者可以通过Pod声明中的“runtimeClassName”来选择不同类型的容器运行时实现。例如，如下我们创建一个运行在gvisor沙箱容器中的nginx应用程序。$catnginx-untrusted.yamlapiVersion:v1kind:Podmetadata:name:nginx-untrustedspec:runtimeClassName:gvisorcontainers:-name:nginximage:nginx$kubectldelete-fnginx-untrusted.yamlpod/nginx-untrusted创建$kubectlexecnginx-untrusted--uname-aLinuxnginx-untrusted4.4#1SMPSunJan1015:06:54PST2016x86_64GNU/Linux我们可以清楚地发现，由于基于runc的容器与主机共享操作系统内核，因此在runccontainer获取的OS内核版本与Minikube宿主机OS内核版本相同。gvisor的runsc容器使用独立内核，与Minikube宿主机的OS内核版本不同。正是因为每个沙箱容器都有独立的内核，减少了安全攻击面，具有更好的安全隔离特性。适用于隔离不受信任的应用程序或多租户场景。注意：gvisor在minikube中通过ptrace拦截内核调用，性能损失较大。另外gvisor的兼容性也需要加强。使用ctl和crictl工具，我们现在可以进入Minikube虚拟机$minikubesshcontainerd支持通过命名空间隔离容器资源，查看已有的containerd命名空间$sudoctrnamespaceslsNAMELABELSk8s.io#列出所有容器镜像$sudoctr--namespace=k8s.ioimagesls...#列出所有容器$sudoctr--namespace=k8s.iocontainersls在Kubernetes环境下，更简单的方法是使用crictl操作pods#查看pod列表$sudocrictlpodsPODIDCREATEDSTATENAMENAMESPACEATTEMPT78bd560a703273hoursagoReadynginx-untrusteddefault094817393744fd3hoursagoReadynginxdefault0...#查看名称包含nginx的pod的详细信息$sudocrictlpods--namenginx-vID:78bd560a70327f14077c441aa40da7e7ad52835100795a0fa9e5668f41760288Name:nginx-untrustedUID:dda218b1-d72e-4028-909d-55674fd99ea0Namespace:defaultStatus:ReadyCreated:2019-10-2702:40:02.660884453+0000UTCLabels：io.kubernetes.pod.name->nginx-untrustedio.kubernetes.pod.namespace->defaultio.kubernetes.pod.uid->dda218b1-d72e-4028-909d-55674fd99ea0注释：kubectl.kubernetes。io/last-applied-configuration->{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx-untrusted","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx"}],"runtimeClassName":"gvisor"}}kubernetes.io/config.seen->2019-10-27T02:40:00.675588392Zkubernetes.io/config.source->apiID:94817393744fd18b72212a00132a61c6cc08e031afe7b5295edafd3518032f9fName:nginxUID:bfcf51de-c921-4a9a-a60a-09faab1906c4Namespace:defaultStatus:ReadyCreated:2019-10-2702:38：19.724289298+0000UTCLabels：io.kubernetes.pod.name->nginxio.kubernetes.pod.namespace->默认io.kubernetes.pod.uid->bfcf51de-c921-4a9a-a60a-09faab1906c4注释：kubectl.kubernetes。io/最后应用-configuration->{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx"}]}}kubernetes.io/config.seen->2019-10-27T02:38:18.206096389Zkubernetes。io/config.source->api更多信息请参考https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/containerd与Docker的关系。很多同学关心的是containerd和Docker的关系，containerd是否可以取代Docker？containerd已经成为容器运行时的主流实现，也得到了Docker社区和Kubernetes社区的大力支持。DockerEngine底层的容器生命周期管理也是基于containerd实现的。但是DockerEngine包括更多的开发者工具链，比如镜像构建。它还包括Docker自带的日志、存储、网络、Swarm编排等能力。此外，安全、监控、开发等绝大多数容器生态厂商对DockerEngine的支持都比较完善，对containerd的支持也在逐步补充。因此，在Kubernetes运行环境中，更注重安全、效率和定制化的用户可以选择containerd作为容器运行环境。对于大多数开发者来说，继续使用DockerEngine作为容器运行时也是一个不错的选择。阿里云容器服务支持containerd在阿里云Kubernetes服务ACK中，我们采用了containerd作为容器运行时管理，支持安全沙箱容器和runc容器的混合部署。在现有产品中，我们与阿里云操作系统团队、蚂蚁金服共同支持了基于轻量级虚拟化的runV沙箱容器。4Q还将与操作系统团队和安全团队合作，发布基于IntelSGXSandbox容器的可信加密。具体产品信息请参考https://help.aliyun.com/document_detail/140541.html和ServerlessKubernetes(ASK)。我们还使用containerd灵活的插件机制来为无节点环境定制和裁剪容器运行时实现。阿里云双11亿元补贴提前领取，iPhone11Pro进抽：https://www.aliyun.com/1111/2...本文作者：易立阅读原文云栖社区原创内容，未经许可不得转载。
