Dragonfly Nydus——下一代容器格式的一种实现-阿里云开发者社区

Dragonfly Nydus——下一代容器格式的一种实现

2020-08-04 10460

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

容器服务 Serverless 版 ACK Serverless，952元额度多规格

容器服务 Serverless 版 ACK Serverless，317元额度多规格

容器镜像服务 ACR，镜像仓库100个不限时长

简介： 容器技术从1979年发展至今已经超过40年，docker 只能说是目前为止，其中一种比较著名而流行的实现。可以说，docker 解决了应用分发的难题，为日后 kubernetes 的流行奠定了基础。但是，俗话说得好，勇士战胜恶龙之日，自身亦化作恶龙。不管是 Docker 公司后来各种神操作（把项目改名 Moby ，docker swarm 的弱鸡编排）也好，CoreOS 的崛起也罢。开源世界的战争，是一种技术标准的全球话语权争夺，这种争夺远比你想象的要残酷。

最近在学习造核弹，刚好碰到 Dragonfly 群里，来自蚂蚁金服的巴德大佬在直播分享另外一个子项目Nydus。

按照我的理解，Nydus是下一代容器格式的一种实现。其存在主要是为了解决旧的容器格式（container format）存在的问题。

那么问题来了，什么是 Nydus？什么是 container format？ Nydus 具体解决了什么问题。这里先来一波名词扫盲。

名词扫盲

实际上，容器技术从1979年发展至今已经超过40年，docker 只能说是目前为止，其中一种比较著名而流行的实现。可以说，docker 解决了应用分发的难题，为日后 kubernetes 的流行奠定了基础。

但是，俗话说得好，勇士战胜恶龙之日，自身亦化作恶龙。不管是 Docker 公司后来各种神操作（把项目改名 Moby ，docker swarm 的弱鸡编排）也好，CoreOS 的崛起也罢，开源世界的战争，是一种技术标准的全球话语权争夺，这种争夺远比你想象的要残酷。

OCI

OCI全称 Open Container Initiative ，隶属于Linux基金会，是Docker, CoreOS联合其他容器厂商，于 2015-6-22 建立的一个开源组织。其目的主要是为了制定容器技术的通用技术标准。

OCI旗下主要有2个项目：

OCIv1

图片.png

OCIv1) 就是目前的容器格式。

OCIv2

OCIv2 就是为了解决 OCIv1 的历史技术债务。

Dragonfly Nydus

2020年4 月 10 日，由云原生计算基金会（CNCF）技术监督委员会投票决议，来自中国的开源项目 Dragonfly 正式晋升为 CNCF 孵化级别的托管项目，成为继 Harbor、TiKV 之后，第三个进入 CNCF 孵化阶段的中国项目。

图片.png

Dragonfly 的架构主要是为了解决了大规模镜像下载、远距离传输、带宽成本控制、安全传输这四大难题。

图片.png

Nydus 是OCIv2的一种实现，计划捐给 Dragonfly ，作为其旗下一个子项目运作。

当前容器格式的问题

图片.png

在直播分享中，巴德大佬提到了OCIv1的几个问题:

分层效率很低
数据没有校验
可重建性问题

分层效率很低

图片.png

分层效率低主要是指冗余性。如果把 docker image 比喻作汉堡包，镜像A是吉士汉堡包。

FROM centos

图片.png

镜像B是双层吉士汉堡包。

FROM centos
RUN yum update -y

# 拉取吉士汉堡包
docker pull h1
# 拉取双层吉士汉堡包
docker pull h2

那么按照目前的设计，镜像之间是独立的，也就是说，拉取h1之后，虽然磁盘里面已经缓存了 centos 的底层镜像，但是拉取h2的时候，还是重新拉取整个镜像，并没有复用 centos 那个底层镜像。最终导致了磁盘的冗余和网络流量的浪费。

数据没有校验(Verifiability)

这里稍加引述巴德大佬的话：

只读层被修改了，容器应用是不知道的。现在的OCI镜像格式下就有可能发生这种事情，镜像在构建和传输过程中是可校验的，但是镜像下载到本地后会被解压，解压后的文件的修改是无法探知的。

镜像需要下载，解压到本地文件系统，然后再交给容器去使用。这个流程中，解压到本地文件系统这一步是丢失可信的关键。

workspace 可重建性问题(repairability)

可重建性可以从某种程度上解决 docker build 慢的问题。

以轻量级 kubernetes event导出组件 kube-eventer为例，

FROM golang:1.14 AS build-env
ADD . /src/github.com/AliyunContainerService/kube-eventer
ENV GOPATH /:/src/github.com/AliyunContainerService/kube-eventer/vendor
ENV GO111MODULE on
WORKDIR /src/github.com/AliyunContainerService/kube-eventer
RUN apt-get update -y && apt-get install gcc ca-certificates
RUN make


FROM alpine:3.10

COPY --from=build-env /src/github.com/AliyunContainerService/kube-eventer/kube-eventer /
COPY --from=build-env /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

ENV TZ "Asia/Shanghai"
RUN apk add --no-cache tzdata
COPY deploy/entrypoint.sh /

ENTRYPOINT ["/kube-eventer"]

我们在机器A上反复执行docker build，每次的构建都是原子的，也就是说，每一次都是从上到下重新跑一遍。但实际上我们知道，很多指令都是重复的，没有必要重复执行。

可重建性还有另外一层意思，从机器A拷贝到机器B之后，继续构建docker image。