nydus

问题一#xff1a;启动容器慢#xff1a;容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时#xff0c;由于在容器准备阶段需要三步#xff08;以overlayfs…

nydus

问题一启动容器慢容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时由于在容器准备阶段需要三步以overlayfs为例

下载镜像

使用overlayfs将容器可写层和镜像中的只读层聚合起来提供容器运行环境

其中下载镜像阶段需要下载整个镜像文件不能实现文件数据按需加载。

再加上下载镜像本身受限于网络带宽当容器镜像达到GB级别时下载时间会较长破坏了容器原本优秀的用户体验。

问题二较高的本地存储成本不同镜像之间可以共享的最小单位是镜像中的层缺点之一是重复数据的处理效率较低。

原因如下

其次层与层之间可能存在大量重复的数据即使有微小的差别也会被作为不同的层

再次根据

的设计镜像内部已经被上层删除的文件可能仍然存在于下层并包含在镜像中

对于镜像提供者

同一个镜像最终可能会因为使用了不同的文件系统而得到不同的镜像用户上传之后镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。

镜像去重效率低

虽然镜像中心有垃圾回收机制来实现去重功能但其仍然以层为单位所以只能在有完全相同hash

value

随着时间推移和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。

安全防护是软件供应链中非常重要的组成不光体现在对软件本身的安全增强也体现在对供应链的安全增强。

因为应用运行环境被前置到了容器镜像中所以对容器镜像的安全包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。

OCI

同一个镜像最终可能会因为使用了不同的文件系统而得到不同的镜像比如在文件系统A

order

内容冗余不同层之间相同信息在传输和存储时都是冗余内容在不读取内容的时候无法判断到这些冗余的存在

无法并行每一层是一个整体对同一个层既无法并行传输也不能并行提取

无法进行小块数据的校验只有完整的层下载完成之后才能对整个层的数据做完整性校验

1.2

在容器的生产实践中偏小的容器镜像能够很快部署启动。

当应用的镜像达到GB级以上的时候在节点上下载镜像通常会消耗大量的时间。

Dragonfly

P2P

网络有效地提升了容器镜像大规模分发的效率。

然而用户必须等待镜像数据完整下载到本地然后才能创建自己的容器。

Nydus

基础之上设计的容器镜像加速服务重新设计了镜像格式和底层文件系统从而加速容器启动速度提高大规模集群中的容器启动成功率。

nydus

nydus

镜像标准格式并以此设计了一个用户态的文件系统。

通过这些优化nydus

能够提供这些特性

支持不同的镜像存储后端镜像数据不只可以存放在镜像仓库还可以放到

NAS

把一个容器镜像分成元数据和数据两层。

其中元数据层是一棵自校验的哈希树。

每个文件和节点的哈希值则是由该的哈希值

确定。

每个文件的数据被按照固定大小切片并保存到数据层中。

数据切片可以在不同文件以及不同镜像中的不同文件共享。

FUSE

Kata容器。

对于存储后端支持使用容器仓库Registery、OSS

对象存储

还可以配置一个本地缓存避免每次启动容器时都从远端数据源拉取数据。

1.4

镜像服务后由于使用了按需加载镜像数据的特性容器的启动时间明显缩短。

在官网的测试数据中nydus

能够把常见镜像的启动时间从数分钟缩短到数秒钟。

理论上来说容器镜像越大nydus

提供运行时数据一致性校验

在传统的镜像中镜像数据会先被解压到本地文件系统再由容器应用去访问使用。

解压前镜像数据是完整校验的。

但是解压之后镜像数据不再能够被校验。

这带来的一个问题就是如果解压后的镜像数据被无意或者恶意地修改

nydus

镜像不会被解压到本地同时可以对每一次数据访问进行校验如果数据被篡改则可以从远端数据源重新拉取。

从图中可以看出对容器镜像数据进行运行时一致性校验是通过对每个数据块计算

SHA

采用分块的方式管理镜像数据。

如果在镜像文件非常大的时候对整个镜像文件计算哈希值非常不现实。

1.5

文件系统的增强拓展在云原生场景下的能力使其适应容器镜像存储场景。

RAFS

是内核态的容器镜像格式除了将镜像格式下沉到内核态还在镜像格式上进行了一系列优化例如块对齐、更加精简的元数据等。

RAFS

rootfs部分目录对应的数据并未存储在本地当在容器中访问到本地访问未命中这部分数据时通过

nydusd

简称FUSE使得用户无需修改内核代码就能创建自定义的文件系统。

FUSRE催生了著名的

fuse-overlayfs其在

用户态文件系统并不完全在用户态实现由两部分组成内核模块和用户态进程。

内核模块文件系统数据流程的功能实现负责截获文件访问请求和返回用户态进程处理请求的结果

FUSE

是运行在用户态的文件系统进程该程序会在启动时注册实现的数据请求处理接口如

ls、cd、mkdir

被分离出来作为独立的开源项目目标是提供更开放、稳定的容器运行基础设施。

分离出来的

containerd

是一个行业标准的容器运行时强调简单性、健壮性和可移植性可以作为守护进程运行在系统中。

containerd的功能主要包括以下内容

拉取/推送容器镜像

负责管理容器的镜像、生命周期、网络和存储实际运行容器是由容器运行时runc

containerd

将系统划分成不同的组件每个组件由一个或多个模块协作完成Core

containerd

组件中的一个插件用来管理容器镜像的文件系统快照镜像中的每一层都会被解压成文件系统快照。

在使用

nydus

已有的用户态方案会涉及频繁的内核态/用户态上下文切换以及内核态/用户态之间的内存拷贝从而造成性能瓶颈。

这一问题在容器镜像已经全部下载到本地的时候尤其突出容器运行过程中涉及的文件访问都会陷出到用户态的服务进程。

1缓存管理和

获取数据这两个操作解耦开。

缓存管理可以下沉到内核态执行这样当镜像在本地

ready

hit)那么直接从缓存文件读取数据。

这一过程全程处于内核态之中并不会陷出到用户态。

缓存未命中

进程以处理这一访问请求此时容器进程会陷入睡眠等待状态Nydusd

fscache

将这些数据写入对应的缓存文件之后通知之前陷入睡眠等待状态的进程该请求已经处理完成之后容器进程即可从缓存文件读取到数据。

erofs

就可以开始从网络下载数据并写入缓存文件之后当容器访问的文件位置恰好处于预取范围内的时候就会触发

cache

直接从缓存文件读取数据而不会再陷出到用户态。

用户态方案则无法实现该优化。

当触发按需加载

可以一次性从网络下载比当前实际请求的数据量更多的数据并将下载的数据写入缓存文件。

例如容器访问

cache

数据的时候就不必再陷出到用户态。

用户态方案则无法实现该优化因为即使触发

cache

的时候用户态的服务进程同样实现了该优化下一次容器访问位于读放大范围内的文件数据的时候同样会陷出到用户态。

over

的性能表现显著优于用户态方案同时与原生文件系统的性能相近从而实现与原生容器镜像方案

(未实现按需加载)

https://github.com/rootless-containers/rootlesskit.git

rootlesskit

https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-full-0.22.2-linux-amd64.tar.gz

sudo

nerdctl-full-0.22.2-linux-amd64.tar.gz

/usr/localsudo

containerd-rootless-setuptool.sh

installsudo

安装主要的3个工具也可以直接下载所有工具的二进制文件编译安装时默认没有没有nydusify

nydusify将

https://github.com/dragonflyoss/image-service.gitcd

image-servicemake

https://github.com/dragonflyoss/image-service/releases/download/v2.1.0-rc.1/nydus-static-v2.1.0-rc.1-linux-amd64.tgz

mkdir

nydus-static-v2.1.0-rc.1-linux-amd64.tgz

nydus-static

github.com/containerd/nydus-snapshotter.git

nydus-snapshotter

/usr/local/bin/containerd-nydus-grpc

address

位置/run/containerd-nydus/containerd-nydus-grpc.sock

默认工作目录/var/lib/containerd-nydus-grpc

默认缓存目录/var/lib/containerd-nydus-grpc/cache

部署本地镜像仓库测试用

/var/lib/registry:/var/lib/registry

registrysudo

localhost:5000/ubuntu:16.04-nydus

nydusify

./tmp/bootstraps/4-sha256:fb15d46c38dcd1ea0b1990006c3366ecd10c79d374f341687eb2cb23a2c8672e

\--log-level

nydus-image/{blobs,layer1,layer2,layer3,layer4}

sudo

/var/lib/docker/overlay2/78f2b3506072c95ca3929a0a797c1819e8966b8bbf5ce8427b671296ca1ad35a/difftree

./nydus-image

/var/lib/docker/overlay2/373ea430abb0edd549583f949ec8259806d9eb7d0a0416ec1494d2fc7efeeedc/diff

5转换第3层和第4层每次都需要指定

/var/lib/docker/overlay2/05424b8c067c59368c11ad5674d68d95365e87487bdf10e3d9842b1016583369/diffsudo

nydus-image

/var/lib/docker/overlay2/942c712e7276be5bde4fb7b30f72583c4a9cf0b2aaa14215cd690daf893a630e/diff

nydus

/YOUR-WORK-PATH/nydus-image/blobs}}},mode:

direct

/usr/local/bin/containerd-nydus-grpc

\--config-path

/var/lib/containerd/io.containerd.snapshotter.v1.nydus

\--cache-dir

/run/containerd-nydus/containerd-nydus-grpc.sock

\--nydusd-path

修改containerd配置文件proxy_plugins.nydus

address

[proxy_plugins][proxy_plugins.nydus]type

snapshotaddress

/run/containerd-nydus/containerd-nydus-grpc.sock[plugins.cri][plugins.cri.containerd]snapshotter

nydusdisable_snapshot_annotations

false

/run/containerd/containerd.sock

plugin

localhost:5000/ubuntu-nydussudo

nerdctl

localhost:5000/ubuntu-nydus:latest

sudo

localhost:5000/ubuntu-nydus:latest

bash

https://github.com/opencontainers/image-spec

[2]

https://en.wikipedia.org/wiki/Merkle_tree

[3]

https://www.kernel.org/doc/html/latest/filesystems/fuse.html

[4]

https://github.com/opencontainers/runc

[6]

https://www.alibabacloud.com/product/oss

[8]

https://github.com/containerd/nydus-snapshotter

[9]

https://github.com/containers/fuse-overlayfs

[10]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id65965d9530b0c320759cd18a9a5975fb2e098462