From 0fffaec5e57fe944751c180a04814f2a008547f4 Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 26 Jan 2024 16:54:28 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E5=86=85=E5=AE=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .vuepress/config.js | 25 +-------- Observability/tracing.md | 3 +- container/Container-Orchestration-Wars.md | 2 +- container/Nydus-image.md | 42 --------------- container/conclusion.md | 3 +- container/dragonfly.md | 19 ------- container/image.md | 66 ++++++++++++++++++++++- http/dns.md | 2 +- 8 files changed, 72 insertions(+), 90 deletions(-) delete mode 100644 container/Nydus-image.md delete mode 100644 container/dragonfly.md diff --git a/.vuepress/config.js b/.vuepress/config.js index ed4b04d8..c87f2efd 100644 --- a/.vuepress/config.js +++ b/.vuepress/config.js @@ -247,16 +247,7 @@ export default defineUserConfig({ children: [ '/container/Container-Orchestration-Wars.md', '/container/orchestration.md', - { - text: '7.3 容器镜像', - link: '/container/image.md', - collapsable: false, - sidebarDepth: 1, - children: [ - '/container/Nydus-image.md', - '/container/dragonfly.md' - ] - }, + '/container/image.md', '/container/runtime.md', { text: '7.5 容器间网络', @@ -282,19 +273,7 @@ export default defineUserConfig({ '/container/k8s-deploy-cilium.md', ] }, - /* - { - text: '7.7 以应用为中心进行封装', - link:'/container/application-centric.md', - collapsable: false, - sidebarDepth: 1, - children: [ - '/container/Kustomize.md', - '/container/Helm.md', - '/container/CRD-Operator.md', - '/container/OAM.md', - ] - }*/ + '/container/conclusion.md', ] }, { diff --git a/Observability/tracing.md b/Observability/tracing.md index 1ac0dd9d..9cc6b697 100644 --- a/Observability/tracing.md +++ b/Observability/tracing.md @@ -1,13 +1,12 @@ # 9.4 链路追踪 -参阅 Uber 公开的技术文档信息，它们的微服务架构中大约有 2,200 个服务，这些服务相互依赖的链路关系引用 Uber 博客中的配图[^1]，供你直观感受。而分布式链路追踪所要做的事情就是通过请求粒度的轨迹追踪与数据透传，实现规模级服务之间的确定性关联。 +参阅 Uber（优步，国外的打车公司）公开的技术文档信息，它们的微服务架构中大约有 2,200 个服务，这些服务相互依赖的链路关系引用 Uber 博客中的配图[^1]，供你直观感受。而分布式链路追踪所要做的事情就是通过请求粒度的轨迹追踪与数据透传，实现规模级服务之间的确定性关联。

Uber 使用 Jaeger 生成的追踪链路拓扑

- 分布式链路追踪诞生的标志性事件就是 Google Dapper 论文的发表。2010年4月，Benjamin H. Sigelman 等人在 Google Technical Report 上发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[^2]。Dapper 论文详细阐述了分布式链路追踪的设计理念，还提出了成为后续链路追踪系统设计的共识的两个概念：“追踪”（Trace）和“跨度”（Span）。 ## Trace 和 Span diff --git a/container/Container-Orchestration-Wars.md b/container/Container-Orchestration-Wars.md index 0df399a0..d7782c66 100644 --- a/container/Container-Orchestration-Wars.md +++ b/container/Container-Orchestration-Wars.md @@ -87,7 +87,7 @@ OCI 标准意在将容器运行时和镜像的实现从 Docker 项目中完全 ## 7. Kubernetes 最终胜出 -经过设计理念、架构、标准、生态等多方面的较量之后，Docker 在与 Kubernetes 的竞争中逐渐落败，Mesos 因其侧重在传统的资源管理，导致它在应对多云和集群管理时面临很多挑战，后来的 Mesos 项目发展也并不好，其标杆客户 Twitter 最后也放弃了 Mesos 改用 Kubernetes。 +经过设计理念、架构、标准、生态等多方面的较量之后，Docker 在与 Kubernetes 的竞争中逐渐落败，Mesos 因其侧重在传统的资源管理，导致它在应对多云和集群管理时面临很多挑战，标杆客户 Twitter 最后也放弃了 Mesos 改用 Kubernetes。 2017 年 10 月的 DockerCon 欧洲大会上，Docker 官方正式宣布支持 Kubernetes，决定将在自己的主打产品 Docker 企业版中内置 Kubernetes，并将 Docker 项目的容器运行时部分 Containerd 捐赠给了 CNCF 社区。 diff --git a/container/Nydus-image.md b/container/Nydus-image.md deleted file mode 100644 index ca6e10ce..00000000 --- a/container/Nydus-image.md +++ /dev/null @@ -1,42 +0,0 @@ -# 镜像加速器 Nydus - -随着时间推移，在大规模集群的应用实践上，目前镜像存在着一些问题。这些问题主要集中在： - -- **内容冗余**：不同层之间相同信息在传输和存储时都是冗余内容，在不读取内容的时候无法判断到这些冗余的存在。 -- **无法并行**：单一层是一个整体，对同一个层既无法并行传输，也不能并行提取。 -- **无法进行小块数据的校验** 只有完整的层下载完成之后，才能对整个层的数据做完整性校验。 - -上述这些问题核心是镜像的基本单位是 layer。但实际上，容器的运行整个镜像并不会被充分利用，一般镜像只有 6% 的内容会被实际用到。为了解决上面这些问题，我们就考虑实现一种新型的镜像结构，对镜像存储利用率、启动速度等更进一步优化，而这些就是 Nydus 要做的工作。 - -## 1. Nydus 介绍及特点 - -Nydus 是阿里云发起的基于延迟加载原理的镜像加速项目，配合 Dragonfly 做 P2P 加速，能够极大缩短镜像下载时间、提升效率，从而让用户能够更安全快捷地启动容器应用。 - -Nydus 提供了容器镜像按需加载的能力，在生产环境支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，端到端数据一致性，内核态支持等方面相比 OCIv1 有巨大优势。Nydus 符合 OCI 标准，与 containerd、CRI-O、Kata-containers 等流行的运行时有良好的兼容性。 - -
- -
- -Nydus 镜像格式并没有对 OCI 镜像格式在架构上进行修改，主要优化了其中的 Layer 数据层的数据结构。Nydus 将原本统一存放在 Layer 层的文件数据和元数据 （文件系统的目录结构、文件元数据等） 分开，分别存放在 `Blob Layer` 和 `Bootstrap Layer` 中。并对 `Blob Layer` 中存放的文件数据进行分块，以便于延迟加载 （在需要访问某个文件时，只需要拉取对应的 Chunk 即可，不需要拉取整个 Blob Layer） 。 - -同时，这些分块信息，包括每个 Chunk 在 Blob Layer 的位置信息等也被存放在 Bootstrap Layer 这个元数据层中。这样，容器启动时，仅需拉取 Bootstrap Layer 层，当容器具体访问到某个文件时，再根据 Bootstrap Layer 中的元信息拉取对应 Blob Layer 中的对应的 Chunk 即可。 - -## 2. Nydus 优势总结 - -总结，使用 Nydus 的优势如下： - -- 容器镜像按需下载，用户不再需要下载完整镜像就能启动容器。 -- 块级别的镜像数据去重，最大限度为用户节省存储资源。 -- 镜像只有最终可用的数据，不需要保存和下载过期数据。 -- 端到端的数据一致性校验，为用户提供更好的数据保护。 -- 兼容 OCI 分发标准和 artifacts 标准，开箱可用。 -- 支持不同的镜像存储后端，镜像数据不只可以存放在镜像仓库，还可以放到 NAS 或者类似 S3 对象存储中。 -- 与 Dragonfly 良好集成。 - - -用户部署了 Nydus 镜像服务后，由于使用了按需加载镜像数据的特性，容器的启动时间明显缩短。在官网的测试数据中，Nydus 能够把常见镜像的启动时间，从数分钟缩短到数秒钟。理论上来说，容器镜像越大，Nydus 体现出来的效果越明显。 - -
- -
\ No newline at end of file diff --git a/container/conclusion.md b/container/conclusion.md index bc5be769..8b3aed7d 100644 --- a/container/conclusion.md +++ b/container/conclusion.md @@ -3,4 +3,5 @@ 参考 - k8s 基于 cgroup 的资源限额 https://arthurchiao.art/blog/k8s-cgroup-zh -- 《凤凰架构》资源与调度 \ No newline at end of file +- 《凤凰架构》资源与调度 +- 《容器镜像格式二十年的螺旋进化之路》https://linux.cn/article-12442-1.html \ No newline at end of file diff --git a/container/dragonfly.md b/container/dragonfly.md deleted file mode 100644 index 0de00f55..00000000 --- a/container/dragonfly.md +++ /dev/null @@ -1,19 +0,0 @@ -# 7.6.2 镜像分发加速 - -容器云平台达到一定规模之后，镜像分发就可能成为整个平台的性能瓶颈。举例说明：在生产实践中，较大尺寸的容器镜像有多方面的问题（见过 12G 的镜像文件），其一影响容器启动效率，其二在应对瞬时高峰启动几百、几千 Pod 时，受带宽、镜像仓库服务瓶颈等影响，会存在较长的耗时。笔者见过多次所有的环节准备完毕，唯独遗漏了镜像下载服务，有时候甚至流量高峰已过，集群还没有扩展完毕。 - -如果你也有过此类的困扰，那么可以看看 Dragonfly。Dragonfly 是阿里巴巴开源的容器镜像分发系统，目标是解决容器镜像分发效率低下和镜像共享依赖公共镜像仓库等问题。它的核心思想是基于 P2P 的镜像分发模型，以提高镜像传输速度和并发性，减少公共镜像仓库的依赖。 - - -Dragonfly 是一种无侵入的解决方案，并不需要修改 Docker 等源码，下图为 Dragonfly 的架构图，在每一个节点上会启动一个 dfdaemon 和 dfget, dfdaemon 是一个代理程序，他会截获 dockerd 上传或者下载镜像的请求，dfget 是一个下载客户端工具。每个 dfget 启动后 将自己注册到 supernode 上。supernode 超级节点以被动 CDN 的方式产生种子数据块，并调度数据块分布。 - -
- -
- -通过镜像加速下载的场景，解析其中运作原理： - -- dfget-proxy 拦截客户端 docker 发起的镜像下载请求（docker pull）并转换为向 SuperNode 的 dfget 下载请求。 -- SuperNode 从镜像源仓库下载镜像并将镜像分割成多个 block 种子数据块。 -- dfget 下载数据块并对外共享已下载的数据块，SuperNode 记录数据块下载情况，并指引后续下载请求在结点之间以 P2P 方式进行数据块下载。 -- dfdaemon 将将镜像分片文件组成完整的镜像。 \ No newline at end of file diff --git a/container/image.md b/container/image.md index 1f981a2f..57a10f60 100644 --- a/container/image.md +++ b/container/image.md @@ -1,6 +1,8 @@ # 7.3 容器镜像 -容器镜像简单理解就是个 Gzip 压缩的特殊文件系统，内部包含了容器运行时所需的程序、库、资源、配置等。在 OCI 标准镜像出台之前，其实有两套广泛使用的镜像规范，分别是 appc 和 docker v2.2，但合久必分、分久必合，两者的规范也在各自的发展中逐步同化，所以 OCI 组织顺水推舟地在 docker v2.2 的基础上推出了 oci image format spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和前面一次，就可以在所有的容器引擎中运行该容器。 +容器镜像简单理解就是个特殊文件系统，内部包含了容器运行时所需的程序、库、资源、配置等。镜像的底层技术是使用 unionfs 的多层文件系统，它允许将多个文件系统层叠在一起，形成一个统一的文件系统视图。每个容器镜像都可以由多个文件系统层组成，包括基础镜像层、中间镜像层和容器特定的可写层。 + +在 OCI 标准镜像出台之前，其实有两套广泛使用的镜像规范，分别是 appc 和 docker v2.2，但合久必分、分久必合，两者的规范也在各自的发展中逐步同化，所以 OCI 组织顺水推舟地在 docker v2.2 的基础上推出了 oci image format spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和前面一次，就可以在所有的容器引擎中运行该容器。 ## 7.4.1 容器镜像的组成 @@ -55,5 +57,67 @@ boot etc lib media opt root sbin sys usr 在我们使用 docker run 命令时，便是将镜像中的各个层和配置组织起来从而启动一个新的容器。镜像就是一系列文件和配置的组合，它是静态的、只读的、不可修改的，而容器则是镜像的实例化，它是可操作的、动态的、可修改的。 +## 镜像分发加速 + +容器云平台达到一定规模之后，镜像分发就可能成为整个平台的性能瓶颈。举例说明：在生产实践中，较大尺寸的容器镜像有多方面的问题（见过 12G 的镜像文件），其一影响容器启动效率，其二在应对瞬时高峰启动几百、几千 Pod 时，受带宽、镜像仓库服务瓶颈等影响，会存在较长的耗时。笔者见过多次所有的环节准备完毕，唯独遗漏了镜像下载服务，有时候甚至流量高峰已过，集群还没有扩展完毕。 + +如果你也有过此类的困扰，那么可以看看 Dragonfly。Dragonfly 是阿里巴巴开源的容器镜像分发系统，目标是解决容器镜像分发效率低下和镜像共享依赖公共镜像仓库等问题。它的核心思想是基于 P2P 的镜像分发模型，以提高镜像传输速度和并发性，减少公共镜像仓库的依赖。 + + +Dragonfly 是一种无侵入的解决方案，并不需要修改 Docker 等源码，下图为 Dragonfly 的架构图，在每一个节点上会启动一个 dfdaemon 和 dfget, dfdaemon 是一个代理程序，他会截获 dockerd 上传或者下载镜像的请求，dfget 是一个下载客户端工具。每个 dfget 启动后 将自己注册到 supernode 上。supernode 超级节点以被动 CDN 的方式产生种子数据块，并调度数据块分布。 + +
+ +
+ +通过镜像加速下载的场景，解析其中运作原理： + +- dfget-proxy 拦截客户端 docker 发起的镜像下载请求（docker pull）并转换为向 SuperNode 的 dfget 下载请求。 +- SuperNode 从镜像源仓库下载镜像并将镜像分割成多个 block 种子数据块。 +- dfget 下载数据块并对外共享已下载的数据块，SuperNode 记录数据块下载情况，并指引后续下载请求在结点之间以 P2P 方式进行数据块下载。 +- dfdaemon 将将镜像分片文件组成完整的镜像。 + + +## 镜像启动加速 + +SUSE 的工程师 Aleksa Sarai 也专门写过一篇文章 来讨论这个话题，除了 tar 格式本身的标准化问题外，大家对当前的镜像的主要不满集中在 + +- **内容冗余**：不同层之间相同信息在传输和存储时都是冗余内容，在不读取内容的时候无法判断到这些冗余的存在。 +- **无法并行**：单一层是一个整体，对同一个层既无法并行传输，也不能并行提取。 +- **无法进行小块数据的校验** 只有完整的层下载完成之后，才能对整个层的数据做完整性校验。 + +上述这些问题核心是镜像的基本单位是 layer。但实际上，容器的运行整个镜像并不会被充分利用，然而，镜像的数据的实际使用率是很低的，Cern 在《Making containers lazy with Docker and CernVM-FS》的论文中就提到[^2]，一般镜像只有 6% 的内容会被实际用到。为了解决上面这些问题，我们就考虑实现一种新型的镜像结构，对镜像存储利用率、启动速度等更进一步优化，而这些就是 Nydus 要做的工作。 +Nydus 是阿里云发起的基于延迟加载原理的镜像加速项目，配合 Dragonfly 做 P2P 加速，能够极大缩短镜像下载时间、提升效率，从而让用户能够更安全快捷地启动容器应用。 + +Nydus 提供了容器镜像按需加载的能力，在生产环境支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，端到端数据一致性，内核态支持等方面相比 OCIv1 有巨大优势。Nydus 符合 OCI 标准，与 containerd、CRI-O、Kata-containers 等流行的运行时有良好的兼容性。 + +
+ +
+ +Nydus 镜像格式并没有对 OCI 镜像格式在架构上进行修改，主要优化了其中的 Layer 数据层的数据结构。Nydus 将原本统一存放在 Layer 层的文件数据和元数据 （文件系统的目录结构、文件元数据等） 分开，分别存放在 `Blob Layer` 和 `Bootstrap Layer` 中。并对 `Blob Layer` 中存放的文件数据进行分块，以便于延迟加载 （在需要访问某个文件时，只需要拉取对应的 Chunk 即可，不需要拉取整个 Blob Layer） 。 + +同时，这些分块信息，包括每个 Chunk 在 Blob Layer 的位置信息等也被存放在 Bootstrap Layer 这个元数据层中。这样，容器启动时，仅需拉取 Bootstrap Layer 层，当容器具体访问到某个文件时，再根据 Bootstrap Layer 中的元信息拉取对应 Blob Layer 中的对应的 Chunk 即可。 + + +总结，使用 Nydus 的优势如下： + +- 容器镜像按需下载，用户不再需要下载完整镜像就能启动容器。 +- 块级别的镜像数据去重，最大限度为用户节省存储资源。 +- 镜像只有最终可用的数据，不需要保存和下载过期数据。 +- 端到端的数据一致性校验，为用户提供更好的数据保护。 +- 兼容 OCI 分发标准和 artifacts 标准，开箱可用。 +- 支持不同的镜像存储后端，镜像数据不只可以存放在镜像仓库，还可以放到 NAS 或者类似 S3 对象存储中。 +- 与 Dragonfly 良好集成。 + + +用户部署了 Nydus 镜像服务后，由于使用了按需加载镜像数据的特性，容器的启动时间明显缩短。在官网的测试数据中，Nydus 能够把常见镜像的启动时间，从数分钟缩短到数秒钟。理论上来说，容器镜像越大，Nydus 体现出来的效果越明显。 + +
+ +
+ +[^1]: 参见 https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar +[^2]: 参见 https://indico.cern.ch/event/567550/papers/2627182/files/6153-paper.pdf \ No newline at end of file diff --git a/http/dns.md b/http/dns.md index 8d3204b7..789050b1 100644 --- a/http/dns.md +++ b/http/dns.md @@ -1,6 +1,6 @@ # 2.3 域名解析环节实践 -DNS 也许是世界上最大、最频繁的却最没有存在感的基础设施系统了。虽没有存在感，但它施加的影响却无处不在，2021 年期间互联网发生了几起影响颇大的服务宕机故障均与DNS系统有关：7月22日 Aakamai Edge DNS 故障，造成 PlayStation Network、HBO、UPS、Airbnb、Salesforce 等众多知名网站宕机[^1]；不久之后的10月4日，社交网络平台 Facebook 及旗下服务 Messenger、Instagram、WhatsApp、Mapillary 与 Oculus 发生全球性宕机[^2]。 +DNS 也许是世界上规模最大、交互最频繁却最没有存在感的基础设施系统。虽没有存在感，但它施加的影响却无处不在，2021 年期间互联网发生了几起影响颇大的服务宕机故障均与DNS系统有关：7月22日 Aakamai Edge DNS 故障，造成 PlayStation Network、HBO、UPS、Airbnb、Salesforce 等众多知名网站宕机[^1]；不久之后的10月4日，社交网络平台 Facebook 及旗下服务 Messenger、Instagram、WhatsApp、Mapillary 与 Oculus 发生全球性宕机[^2]。 这些故障影响范围为何如此之广？带着这些问题，我们开始 DNS 的篇节。