icon-cookie
The website uses cookies to optimize your user experience. Using this website grants us the permission to collect certain information essential to the provision of our services to you, but you may change the cookie settings within your browser any time you wish. Learn more
I agree
blank_error__heading
blank_error__body
Text direction?

containerd 1.4最新功能特性一览

2020-08-19 07:45 来源:Docker

本次CKA培训课程,通过线下授课、考题解读、模拟演练等方式,帮助学员快速掌握Kubernetes的理论知识和专业技能,并针对考试做特别强化训练,让学员能从容面对CKA认证考试,使学员既能掌握Kubernetes相关知识,又能通过CKA认证考试,点击下方图片了解详情。

containerd 1.4[1]于2020年8月17日正式发布,带来一系列全新功能,具体包括对“lazy-pulling”、SELinux MCS、cgroup v2以及Windows CRI的支持能力。

Lazy-pulling

Lazy-pulling是指在镜像拉取彻底完成之前启动容器。以往的版本无法实现这一功能,因为OCI标准tar.gz不支持在经过压缩的归档文件中寻找随机领衔。

containerd 1.4则支持使用Stargz进行lazy-pulling。Stargz是由谷歌公司提出的可搜索式tar.gz格式,Stargz归档文件的尾部包含有领衔量表结构(stargz.index.json),能够在无需扫描完整归档的前提下对特定文件条目进行访问。Stargz的数据结构在一定程度上类似于ZIP格式——二者的区别在于,Stargz能够与旧版tar.gz格式完全兼容。

legacy tar.gz与Stargz

Stargz的containerd实现还支持我们为Stargz打造的特别扩展版本,即eStargz。eStargz能够对归档中的相关事件文件进行重新排序及压缩,借此在单一HTTP请求中进行预获取。

Stargz与eStargz

在带有Docker Hub的Azure VM实例(eastus2)上得到的基准测试结果表明,在最佳情况下,Stargz/eStargz能够将容器的启动延迟从数十秒缩短至数秒。

基准测试结果,越低越好

要了解如何配置containerd以通过Stargz/eStargz启用lazy-pulling,请参阅 https://github.com/containerd/stargz-snapshotter 。

另外,建议大家参考Kohei Tokunaga的文章 《在Containerd使用Lazy镜像分发实现迅如闪电的容器启动速度[2]》。

CRI上的SELinux MCS

CRI插件现在支持自动设置SELinux MCS(多类别安全),借此严格隔离各容器。MCS支持功能并非新鲜事物,Docker方面也表示积极接纳,但此前的CRI插件版本一直未能做好配合。

MCS能够防止属于不同SELinux类别的进程与文件之间发生干扰,这类干扰出现在/proc/$PID/attr/current 与 ls -Z 当中:

[root@container] # whoami

root

[root@container] # cat /proc/self/attr/current

system_u:system_r:container_t:s0:c496,c687

  • Linux用户:root
  • SELinux用户:system_u
  • SELinux角色:system_r
  • SELinux域(即类型): container_t
  • SELinux 敏感度(即级别):s0
  • SELinux 类别: c496,c687

以c496,c687类别运行的进程,至少能够访问c496与c687二者之一内的文件:

[root@container] # ls -Z foo

system_u:object_r:container_file_t:s0:c496,c687 foo

[root@container] # cat foo

hello

但该进程无法访问其他类别下的文件:

[root@container] # ls -Z foo

system_u:object_r:container_file_t:s0:c136,c954 foo

[root@container] # cat foo

cat: hello: Permission denied

cgroup v2

以往,在未向内核cmdline中添加systemd.unified_cgroup_hierarchy=0的情况下,containerd无法在Fedora的各最新版本上运行。这是因为containerd不支持cgroup v2,而cgroup v2正是Fedora上的默认cgroup版本(自Fedora 31起)。

现在,conatinerd已经正式支持cgroup v2,你无需调整内核cmdline即可将其正常运行在Fedora之上。

与v1版本相比,cgroup v2的最大优势在于无需root权限即可实现安全配置。如此一来,非root Docker用户也可以轻松设置容器的资源限制:

需要注意的是,截至2020年8月,能够支持cgroup v2的Docker 20.XX版本仍未正式发布,但大家可以通过我的GitHub repo获取二进制快照:https://github.com/AkihiroSuda/moby-snapshot。

Docker 20.XX预计将在未来几个月内与大家见面。

containerd 1.4中的其他变化

CRI插件现在支持Windows容器。关于当前实现状态的更多详细信息,请参阅Kubernetes增强倡议(KEP)[3]。

containerd 1.4还添加了对以下功能的支持:

  • systemd NOTIFY_SOCKET[4]
  • 基于FUSE的快照程序[5]
  • 重新加载CNI配置,但不重新启动守护程序[6]
  • 不使用socat即可实现CRI端口转发[7]

containerd的市场采用率正稳步提升

目前,containerd在云原生市场上的采用率正稳步提升。

除了Google Kubernetes Engine(GKE)以及IBM Cloud Kubernetes Service(IKS)之外,Azure Kubernetes Service(AKS)自2020的7月起也开始支持containerd节点。自2019年12月开始,Amazon EKS的Fargate集成也正式引入containerd。

除Kubernetes服务之外,containerd还成功登陆VMware Fusion,负责在macOS上运行Linux容器(Nautilus项目)。关于更多详细信息,请参阅VMware博客[8]。

containerd 1.5计划简介

containerd社区目前已经在就下个版本的开发计划进行讨论。

  • NRI(节点资源接口):用于控制节点资源(例如cgroups)的全新通用接口。受CNI启发而来。
  • 沙箱API:CRI沙箱容器将作为一流对象获得支持。这意味着在新版本中,大家将无需使用/pause进程。
  • 快照配额:为文件系统快照设置配额的功能,将在下个版本中成为现实。

containerd 1.5预计将于2020年第四季度或2021年第一季度发布。

相关链接:

原文链接:https://medium.com/nttlabs/containerd14-70ae3ea29dba 返回搜狐,查看更多

责任编辑:

Measure
Measure
Related Notes
Get a free MyMarkup account to save this article and view it later on any device.
Create account

End User License Agreement

Summary | 4 Annotations
SELinux MCS
2020/08/20 10:37
cgroup v2的最大优势在于无需root权限即可实现安全配置
2020/08/20 10:37
Lazy-pulling是指在镜像拉取彻底完成之前启动容器
2020/08/20 10:39
stargz.index.json
2020/08/20 10:39