北京京西建设集团网站,比较好的外贸公司,广州建信网络有限公司,网站建设工作任务“ 包括 nydus 的基本概念、架构和容器镜像加速使用方法。 1. nydus
1.1 存在的问题 对于容器镜像使用者 问题一#xff1a;启动容器慢#xff1a;容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时#xff0c;由于在容器准备阶段需要三步#xff08;以overlayfs… “ 包括 nydus 的基本概念、架构和容器镜像加速使用方法。 1. nydus
1.1 存在的问题 对于容器镜像使用者 问题一启动容器慢容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时由于在容器准备阶段需要三步以overlayfs为例 下载镜像 解压镜像 使用overlayfs将容器可写层和镜像中的只读层聚合起来提供容器运行环境
其中下载镜像阶段需要下载整个镜像文件不能实现文件数据按需加载。再加上下载镜像本身受限于网络带宽当容器镜像达到GB级别时下载时间会较长破坏了容器原本优秀的用户体验。
问题二较高的本地存储成本不同镜像之间可以共享的最小单位是镜像中的层缺点之一是重复数据的处理效率较低。原因如下 首先层内部存在重复的数据 其次层与层之间可能存在大量重复的数据即使有微小的差别也会被作为不同的层 再次根据 OCI imagespec 对删除文件和 hardlink 的设计镜像内部已经被上层删除的文件可能仍然存在于下层并包含在镜像中 对于镜像提供者 这里的提供者主要指容器服务的镜像中心。 问题一巨大的存储资源浪费 存在大量相似镜像造成这种情况有两个原因 首先上面提到的层的缺点导致在容器镜像中心存在许多相似镜像 其次OCI image 使用了 targzip 格式来表示镜像中的层而 tar 格式并不区分 tar archive entries ordering这带来一个问题如果用户在不同机器上 build 同一个镜像最终可能会因为使用了不同的文件系统而得到不同的镜像用户上传之后镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。 镜像去重效率低 虽然镜像中心有垃圾回收机制来实现去重功能但其仍然以层为单位所以只能在有完全相同hash value 的层之间去重。
问题二云原生软件供应链带来的新需求
随着时间推移和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。安全防护是软件供应链中非常重要的组成不光体现在对软件本身的安全增强也体现在对供应链的安全增强。因为应用运行环境被前置到了容器镜像中所以对容器镜像的安全包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。
OCI 镜像规范的缺陷
主要的缺陷有两点 tar格式标准 tar格式并不区分tar archive entries ordering这带来一个问题即如果用户在不同机器上 build 同一个镜像最终可能会因为使用了不同的文件系统而得到不同的镜像比如在文件系统A 上的 order 是 foo 在 bar 之前进入 tar在文件系统 B 上的 order 是 bar 在 foo 之前进入tar那么这两个镜像是不同的 当 tar 被 gzip 压缩过之后不支持 seek导致运行之前必须先下载并解压 targz 的 image layers而不能实现文件数据按需加载。 以层为镜像的基本单位 内容冗余不同层之间相同信息在传输和存储时都是冗余内容在不读取内容的时候无法判断到这些冗余的存在 无法并行每一层是一个整体对同一个层既无法并行传输也不能并行提取 无法进行小块数据的校验只有完整的层下载完成之后才能对整个层的数据做完整性校验 其他一些问题比如跨层数据删除难以完美处理。
1.2 nudys 基础
在容器的生产实践中偏小的容器镜像能够很快部署启动。当应用的镜像达到GB级以上的时候在节点上下载镜像通常会消耗大量的时间。Dragonfly 通过引入 P2P 网络有效地提升了容器镜像大规模分发的效率。然而用户必须等待镜像数据完整下载到本地然后才能创建自己的容器。
Nydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务重新设计了镜像格式和底层文件系统从而加速容器启动速度提高大规模集群中的容器启动成功率。nydus 由阿里云和蚂蚁集团的工程师合作开发并大规模部署在内部的 生产环境中。
nydus 优化了现有的 OCI 镜像标准格式并以此设计了一个用户态的文件系统。通过这些优化nydus 能够提供这些特性 容器镜像按需下载用户不再需要下载完整镜像就能启动容器 块级别的镜像数据去重最大限度为用户节省存储资源 镜像只有最终可用的数据不需要保存和下载过期数据 端到端的数据一致性校验为用户提供更好的数据保护 兼容 OCI 分发标准和 artifacts 标准开箱即可用 支持不同的镜像存储后端镜像数据不只可以存放在镜像仓库还可以放到 NAS 或者类似 S3 的对象存储上 与 Dragonfly 的良好集成
1.3 nydus 架构 nydus 的架构主要包含两部分内容 新的镜像格式Rafs nydus 把一个容器镜像分成元数据和数据两层。其中元数据层是一棵自校验的哈希树。每个文件和目录都是哈希树中的一个附带哈希值的节点。一个文件节点的哈希值是由文件的数据确定一个目录节点的哈希值则是由该目录下所有文件和目录的哈希值 确定。每个文件的数据被按照固定大小切片并保存到数据层中。数据切片可以在不同文件以及不同镜像中的不同文件共享。 负责解析容器镜像的 FUSE 用户态文件系统进程 nydus 兼容多种文件系统能够解析 FUSE 和 virtiofs 协议来支持传统的 runc 容器、 Kata容器。对于存储后端支持使用容器仓库Registery、OSS 对象存储 、NAS、Dragonfly 的超级节点和 Peer 节点作为nydus 的镜像数据存储后端。此外为了加速启动速度nydus 还可以配置一个本地缓存避免每次启动容器时都从远端数据源拉取数据。
1.4 nydus 特性
容器启动速度变快
用户部署了 nydus 镜像服务后由于使用了按需加载镜像数据的特性容器的启动时间明显缩短。在官网的测试数据中nydus 能够把常见镜像的启动时间从数分钟缩短到数秒钟。理论上来说容器镜像越大nydus 体现出来的效果越明显。 提供运行时数据一致性校验
在传统的镜像中镜像数据会先被解压到本地文件系统再由容器应用去访问使用。解压前镜像数据是完整校验的。但是解压之后镜像数据不再能够被校验。这带来的一个问题就是如果解压后的镜像数据被无意或者恶意地修改 用户是无法感知的。而 nydus 镜像不会被解压到本地同时可以对每一次数据访问进行校验如果数据被篡改则可以从远端数据源重新拉取。 从图中可以看出对容器镜像数据进行运行时一致性校验是通过对每个数据块计算 SHA 256 实现的这得益于 nydus 采用分块的方式管理镜像数据。如果在镜像文件非常大的时候对整个镜像文件计算哈希值非常不现实。
1.5 nydus 镜像格式RAFS
RAFS 是对 EROFS 文件系统的增强拓展在云原生场景下的能力使其适应容器镜像存储场景。RAFS v6 是内核态的容器镜像格式除了将镜像格式下沉到内核态还在镜像格式上进行了一系列优化例如块对齐、更加精简的元数据等。 RAFS v6 镜像格式
1.6 nydus-snapshotter
Nydus snapshotter 是 containerd 的一个外部插件使得 containerd 能够使用 nydus 镜像加速服务。在 containerd 中 snapshot 的工作是给容器提供 rootfsNydus snapshotter 实现了 containerd 的 snapshot 的接口使得 containerd 可以通过 nydus 准备 rootfs 以启动容器。由于 nydus-snapshotter 实现了按需加载的特性在 containerd 启动容器时只需要根据容器镜像的元数据信息准备 rootfs部分目录对应的数据并未存储在本地当在容器中访问到本地访问未命中这部分数据时通过 nydusd 从镜像 registry 拉取对应数据内容。 2. FUSE
用户态文件系统filesystem in userspace 简称FUSE使得用户无需修改内核代码就能创建自定义的文件系统。FUSRE催生了著名的 fuse-overlayfs其在 rootless 容器化中扮演重要的角色。
用户态文件系统并不完全在用户态实现由两部分组成内核模块和用户态进程。 内核模块文件系统数据流程的功能实现负责截获文件访问请求和返回用户态进程处理请求的结果 用户态进程负责处理具体的数据请求对应处理函数由内核模块触发
FUSE 的工作流程如下图 其中fuse_user 是运行在用户态的文件系统进程该程序会在启动时注册实现的数据请求处理接口如 ls、cd、mkdir 等同时程序在某个路径挂载 fuse 文件系统 /tmp/fuse_fs当对 /tmp/fuse_fs 执行相关操作时 请求会经过 VFS虚拟文件系统 到达 fuse 的内核模块 内核模块根据请求类型调用用户态进程注册的函数 当程序完成对请求的处理后将结果通过 VFS 返回给系统调用
3. containerd
containerd 最开始是 Docker Engine 中的一部分后来containerd 被分离出来作为独立的开源项目目标是提供更开放、稳定的容器运行基础设施。分离出来的 containerd 将具有更多的功能涵盖整个容器运行时管理的所有需求。
containerd 是一个行业标准的容器运行时强调简单性、健壮性和可移植性可以作为守护进程运行在系统中。containerd的功能主要包括以下内容 管理容器的生命周期从创建容器到销毁容器 拉取/推送容器镜像 存储管理管理镜像及容器数据的存储 调用 runc 运行容器与 runc 等容器运行时交互 管理容器网络接口及网络
containerd 采用 C/S 架构服务端通过 unix domain socket 暴露低层 gRPC 接口客户端通过这些 gRPC 接口管理节点上的容器containerd 负责管理容器的镜像、生命周期、网络和存储实际运行容器是由容器运行时runc 是其中一种完成。 containerd 将系统划分成不同的组件每个组件由一个或多个模块协作完成Core 部分不同模块都以插件的形式集成到 containerd 中插件之间相互依赖。
containerd 的组件可以分成三类Storage、Metadata 和 Runtimessnapshot 属于 Storage 组件中的一个插件用来管理容器镜像的文件系统快照镜像中的每一层都会被解压成文件系统快照。在使用 nydus 的 containerd 环境中nydus-snapshotter 负责完成这部分工作。
4. erofs fsache
erofs over fscache 基本概念
erofs over fscache 是 Linux 内核原生的镜像按需加载特性于 5.19 版本合入 Linux 内核主线。
已有的用户态方案会涉及频繁的内核态/用户态上下文切换以及内核态/用户态之间的内存拷贝从而造成性能瓶颈。这一问题在容器镜像已经全部下载到本地的时候尤其突出容器运行过程中涉及的文件访问都会陷出到用户态的服务进程。
事实上我们可以将按需加载的 1缓存管理和 2缓存未命中的时候通过各种途径 (例如网络) 获取数据这两个操作解耦开。缓存管理可以下沉到内核态执行这样当镜像在本地 ready 的时候就可以避免内核态/用户态上下文的切换。而这也正是 erofs over fscache 技术的价值所在。
fscache/cachefiles (以下统称 fscache) 是 Linux 系统中相对成熟的文件缓存方案广泛应用于网络文件系统erofs over fscache 技术使得 fsache 能够支持 erofs 的按需加载特性。
容器在访问容器镜像的时候fscache 会检查当前请求的数据是否已经缓存如果缓存命中 (cache hit)那么直接从缓存文件读取数据。这一过程全程处于内核态之中并不会陷出到用户态。
缓存未命中 (cache miss)时 需要通知用户态的 Nydusd 进程以处理这一访问请求此时容器进程会陷入睡眠等待状态Nydusd 通过网络从远端获取数据通过 fscache 将这些数据写入对应的缓存文件之后通知之前陷入睡眠等待状态的进程该请求已经处理完成之后容器进程即可从缓存文件读取到数据。 erofs over fscache 优势 异步预取 容器创建之后当容器进程尚未触发按需加载 (cache miss) 的时候用户态的 Nydusd 就可以开始从网络下载数据并写入缓存文件之后当容器访问的文件位置恰好处于预取范围内的时候就会触发 cache hit 直接从缓存文件读取数据而不会再陷出到用户态。用户态方案则无法实现该优化。 网络 IO 优化 当触发按需加载 (cache miss) 时Nydusd 可以一次性从网络下载比当前实际请求的数据量更多的数据并将下载的数据写入缓存文件。例如容器访问 4K 数据触发的 cache miss而 Nydusd 实际一次性下载 1MB 数据以减小单位文件大小的网络传输延时。之后容器访问接下来的这 1MB 数据的时候就不必再陷出到用户态。用户态方案则无法实现该优化因为即使触发 cache miss 的时候用户态的服务进程同样实现了该优化下一次容器访问位于读放大范围内的文件数据的时候同样会陷出到用户态。 更佳的性能表现 当镜像数据已经全部下载到本地的时候 (即不考虑按需加载的影响)erofs over fscache 的性能表现显著优于用户态方案同时与原生文件系统的性能相近从而实现与原生容器镜像方案 (未实现按需加载) 相近的性能表现。
5. 环境安装
nerdctl 安装
# git clone https://github.com/rootless-containers/rootlesskit.git
# cd rootlesskit
# make sudo make installwget https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-full-0.22.2-linux-amd64.tar.gz
sudo tar -zxvf nerdctl-full-0.22.2-linux-amd64.tar.gz -C /usr/localsudo systemctl enable --now containerd
sudo systemctl enable --now buildkit# sudo apt-get install uidmap -y
# containerd-rootless-setuptool.sh installsudo nerdctl version # 需要使用sudo不然会提示安装 rootless nydus 安装
安装主要的3个工具也可以直接下载所有工具的二进制文件编译安装时默认没有没有nydusify nydusify将 OCI 格式的容器镜像转换为 nydus 格式RAFS容器镜像的工具。 nydus-image将解压后的容器镜像转换为 nydus 格式镜像的工具。 nydusd解析 nydus 格式镜像并提供 FUSE 挂载点以供容器访问的守护程序。nydusd也可以用作 virtiofs 后端使得 Guest 可以访问 Host 的文件。
git clone https://github.com/dragonflyoss/image-service.gitcd image-servicemake make install# 默认没有安装 nydusify
wget 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
tar -zxvf nydus-static-v2.1.0-rc.1-linux-amd64.tgz -C nydus-static
sudo cp nydus-static/nydusify /usr/local/bin
sudo cp nydus-static/nydus-overlayfs /usr/local/binnydus-image --version
nydusify --version
nydusd --version
安装nydus-snapshotter
git clone github.com/containerd/nydus-snapshotter.git
cd nydus-snapshotter
make make installsudo systemctl enable nydus-snapshotter
sudo systemctl start nydus-snapshotter
systemctl status nydus-snapshotter nydus-snapshotter以 service 的形式运行 /usr/local/bin/containerd-nydus-grpc 可执行文件配置信息位于 /etc/nydus/config.json 文件。
默认 address 位置/run/containerd-nydus/containerd-nydus-grpc.sock
默认工作目录/var/lib/containerd-nydus-grpc
默认缓存目录/var/lib/containerd-nydus-grpc/cache
部署本地镜像仓库测试用
# sudo docker run -d -p 5000:5000 \
# --restartalways \
# --name registry \
# -v /var/lib/registry:/var/lib/registry \
# -d registrysudo docker run -d --nameregistry --restartalways -p 5000:5000 registry
sudo docker logs registry -f
将OCI格式的镜像转换为RAFS格式镜像
sudo nydusify convert \--nydus-image $(which nydus-image) \--source ubuntu:16.04 \--target localhost:5000/ubuntu:16.04-nydus
nydusify 基本命令 转换后的镜像层文件位于当前目录下的tmp文件夹
sudo tree tmp -L 4 将 OCI 标准的镜像格式转换为 nydus 使用的 RAFS 镜像格式后可以使用 nydusd 解析并提供 fuse 挂载点供容器使用。编写配置文件 registry.json使得 nydus 使用 容器镜像 registry 已经搭建本地容器镜像 register 用于测试作为存储后端。
{device: {backend: {type: registry,config: {scheme: http,host: localhost:5000,repo: ubuntu}},digest_validate: false},mode: direct
}
挂载 RAFS 镜像 为 fuse 挂载点–bootstrap 参数传递位于 tmp/bootstraps 下的文件路径
sudo nydusd \--config ./registry.json \--mountpoint /mnt \--bootstrap ./tmp/bootstraps/4-sha256:fb15d46c38dcd1ea0b1990006c3366ecd10c79d374f341687eb2cb23a2c8672e \--log-level info
查看挂载情况 输出日志信息 除了使用 nydusify 直接将 OCI 标准格式镜像转换为 nydus 格式镜像nydus-image 工具也支持直接对已经解压的 OCI 容器镜像文件层转换为 nydus 格式镜像。
1获取OCI镜像元数据信息
docker pull ubuntu:16.04
sudo docker inspect -f {{json .GraphDriver }} ubuntu:16.04 | jq . Docker 使用 overlay2 存储驱动通过所需的 lowerdir、upperdir、merged 和 workdir 结构自动创建 overlay 挂载点。 对于 Nydus 来说目录树通常是一个镜像层由两部分组成 bootstrap存储目录的文件系统元数据信息 blob存储目录中的所有文件数据
2建立生成 nydus 镜像的目录
mkdir -p nydus-image/{blobs,layer1,layer2,layer3,layer4}
3转换最底层的镜像层
sudo nydus-image create \--bootstrap ./nydus-image/layer1/bootstrap \--blob-dir ./nydus-image/blobs \--compressor none /var/lib/docker/overlay2/78f2b3506072c95ca3929a0a797c1819e8966b8bbf5ce8427b671296ca1ad35a/difftree -L 2 ./nydus-image 4转换第二底层镜像层–parent-bootstrap 指父层即刚才转换好的镜像层
sudo nydus-image create \--parent-bootstrap ./nydus-image/layer1/bootstrap \--bootstrap ./nydus-image/layer2/bootstrap \--blob-dir ./nydus-image/blobs \--compressor none /var/lib/docker/overlay2/373ea430abb0edd549583f949ec8259806d9eb7d0a0416ec1494d2fc7efeeedc/diff 5转换第3层和第4层每次都需要指定 --parent-bootstrap 为上一次生成的镜像层
sudo nydus-image create \--parent-bootstrap ./nydus-image/layer2/bootstrap \--bootstrap ./nydus-image/layer3/bootstrap \--blob-dir ./nydus-image/blobs \--compressor none /var/lib/docker/overlay2/05424b8c067c59368c11ad5674d68d95365e87487bdf10e3d9842b1016583369/diffsudo nydus-image create \--parent-bootstrap ./nydus-image/layer3/bootstrap \--bootstrap ./nydus-image/layer4/bootstrap \--blob-dir ./nydus-image/blobs \--compressor none /var/lib/docker/overlay2/942c712e7276be5bde4fb7b30f72583c4a9cf0b2aaa14215cd690daf893a630e/diff
将 nydus 镜像挂载到目录
sudo nydusd \--config ./localfs.json \--mountpoint /mnt \--bootstrap ./nydus-image/layer4/bootstrap \--log-level info
其中localfs.json文件的内容为
{device: {backend: {type: localfs,config: {dir: /YOUR-WORK-PATH/nydus-image/blobs}}},mode: direct
}
dir 为生成的 nydus 镜像文件中 blobs 目录的绝对路径。
6. 通过nydussnapshotter启动容器
添加配置文件
Nydus 提供了 containerd 远程快照管理工具 containerd-nydus-grpc 用于准备 nydus 镜像格式的容器rootfs首先将 nydusd 配置保存到 /etc/nydus/config.json 文件。
sudo tee /etc/nydus/config.json /dev/null EOF
{device: {backend: {type: registry,config: {scheme: http,skip_verify: false,timeout: 5,connect_timeout: 5,retry_limit: 2,auth: }},cache: {type: blobcache,config: {work_dir: cache}}},mode: direct,digest_validate: false,iostats_files: false,enable_xattr: true,fs_prefetch: {enable: true,threads_count: 4}
}
EOF
containerd-nydus-grpc 会自动从 $HOME/.docker/config.json 中读取 docker login auth如果不想使用这个值需要直接替换配置文件中的内容。
直接从终端启动 containerd-nydus-grpc如果已经通过 containerd-nydus-grpc service 启动则可以跳过此步骤
sudo /usr/local/bin/containerd-nydus-grpc \--config-path /etc/nydus/config.json \--shared-daemon \--log-level info \--root /var/lib/containerd/io.containerd.snapshotter.v1.nydus \--cache-dir /var/lib/nydus/cache \--address /run/containerd-nydus/containerd-nydus-grpc.sock \--nydusd-path /usr/local/bin/nydusd \--nydusimg-path /usr/local/bin/nydus-image \--log-to-stdout
修改containerd配置文件proxy_plugins.nydus 的 address 和 containerd-nydus-grpc 的对应。
sudo tee -a /etc/containerd/config.toml EOF
[proxy_plugins][proxy_plugins.nydus]type snapshotaddress /run/containerd-nydus/containerd-nydus-grpc.sock[plugins.cri][plugins.cri.containerd]snapshotter nydusdisable_snapshot_annotations false
EOFsudo systemctl restart containerd
sudo ctr -a /run/containerd/containerd.sock plugin ls | grep nydus
通过nydus启动容器
# 转换镜像并上传到本地 registry
sudo nydusify convert --nydus-image /usr/local/bin/nydus-image --source ubuntu --target localhost:5000/ubuntu-nydussudo nerdctl --snapshotter nydus pull localhost:5000/ubuntu-nydus:latest
sudo nerdctl --snapshotter nydus run --rm -it localhost:5000/ubuntu-nydus:latest bash 重启主机之后启动环境
sudo systemctl restart nydus-snapshotter
sudo systemctl restart containerdsudo docker rm -f registry
sudo docker run -d --nameregistry --restartalways -p 5000:5000 registry sudo docker logs registry -f
参考资料
[1] OCI 镜像标准格式: https://github.com/opencontainers/image-spec
[2] 自校验的哈希树: https://en.wikipedia.org/wiki/Merkle_tree
[3] FUSE: https://www.kernel.org/doc/html/latest/filesystems/fuse.html
[4] virtiofs: https://virtio-fs.gitlab.io/
[5] runc 容器: https://github.com/opencontainers/runc
[6] Kata容器: https://katacontainers.io/
[7] OSS 对象存储: https://www.alibabacloud.com/product/oss
[8] nydus-snapshotter: https://github.com/containerd/nydus-snapshotter
[9] fuse-overlayfs: https://github.com/containers/fuse-overlayfs
[10] 5.19 版本: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id65965d9530b0c320759cd18a9a5975fb2e098462
