阿里巴巴云原生小助手个人页面-阿里云开发者社区

Serverless 的初心、现状和未来

作者 | 不瞋阿里云高级技术专家导读：Serverless 是如何产生的？当前有哪些落地场景？Serverless 的未来又将如何？本文分享了阿里云高级技术专家不瞋对于 Serverless 的看法，回顾其发展历程，并对 Serverless 的发展趋势做出预测。源起回望整个计算机技术发展史，我们会发现 “抽象、解耦、集成” 的主题贯穿其中。产业每一次的抽象、解耦、集成，都将创新推向新的高度，也催生出庞大的市场和新的商业模式。大型机时代，硬件和软件都是定制化的，使用专有的硬件、操作系统和应用软件。 PC 时代，硬件被抽象解耦成 CPU、内存、硬盘、主板、USB 设备等标准化的部件，不同厂商生产的部件可以自由组合，组装成整机。软件被抽象解耦为操作系统、库等可复用组件。硬件和软件的抽象解耦，创造了新的商业模式，释放了生产力，造就了 PC 时代的繁荣。云的时代，硬件软件化和软件服务化成为最显著的两个趋势。硬件软件化的核心在于硬件功能中越来越多的部分由软件来呈现，从而在迭代效率、成本等方面获得显著优势。以软件定义存储（Software Defined Storage，SDS）为例，SDS 是位于物理存储和数据请求之间的一个软件层，允许用户操控数据的存储方式和存储位置。通过硬件与软件解耦，SDS 可运行于行业标准系统或者 X86 系统上，意味着用户可以无差别的使用任何标准的商用服务器来满足不断增长的存储需求。硬件与软件解耦也让 SDS 能够横向扩展，消除容量规划，成本管理等方面的复杂性。云时代的另一趋势是软件服务化。应用软件的功能通过网络以远程调用的模式被海量用户使用。服务成为应用构建的基础，API 被实现为服务提供给开发者，微服务架构获得广泛的成功。服务也成为云产品的基本形态。过去 10 年，云已经证明了它的成功。用户只需要通过调用 API 就能获取服务器，而无需自己建设数据中心。算力以前所未有简洁的方式提供给用户。还记得 Google 那篇著名的 “Datacenter as a computer “ 论文吗？如果我们把云看作是 DT 时代的计算机，那么一个很自然的问题是：随着云的 API（全托管服务）越来越丰富，什么才是适合于云的编程模型？我们应当以何种 “抽象、解耦、集成” 的方式构建基于云的应用？在回答上述问题之前，让我们首先将目光转向 SaaS 领域。Salesforce 是 SaaS 领域的明星企业，在平台化能力建设方面的布局为我们提供了一个绝佳的案例。早期的 SaaS 产品采用标准化的交付模式，通过开放 API 接口实现被集成的能力。随着 Salesforce 产品越来越丰富，客户规模日益增长，企业开始面临新的挑战：如何更快地推出新产品，加强产品间的整合和协同？客户迅速增长，需求多样。如何高效地满足客户的定制化需求，增加客户粘性？如何提高产品被集成的能力，更好的衔接上下游资源？当产品能力和 API 完整度到达一定水准后，如何让开发者快速整合 API，围绕 Salesforce 能力便捷地开发应用？如何设计好的商业模式，让客户、企业和开发者共赢？ Salesforce 的策略是让整个业务、技术和组织平台化。平台放大了企业的价值，让企业、客户、开发者三方受益。通过不断提升平台的应用交付能力，对内大幅提高产品的研发效率，加强产品的集成和整合；对外则大幅提高了产品的被集成能力，建立开发者生态。从 2006 年开始，Salesforce 在平台化能力建设上大力投资，推出了 Apex，Visualforce 等编程语言，允许客户、合作伙伴和开发者在多租户环境下编写和运行自定义的逻辑代码。在此基础上，2008 年推出自研 Force.com PaaS 平台，客户能够在该平台上围绕 Salesforce 的能力构建自己的应用程序。2010 年收购了流行的 PaaS 服务商 Heroku，2019 年推出 Serverless 计算平台 Evergreen，进一步加强应用构建和集成与被集成能力。除了应用的构建能力，Salesforce 近几年来也在应用的移动化、数据化和智能化方面进行了大量的投资，延伸平台在相关领域的能力，帮助客户实现管理流程的数据化和智能化，并通过数据分析和交易撮合为客户带来增量业务。总结 Salesforce 的发展历程，我们可以得出一些观点： API 已成为价值交付最重要的形式；把 API 作为价值交付形式的产品或组织，当 API 丰富度和能力完整度达到一定水准后，会升级为平台，通过平台突破能力瓶颈，实现业务、产品和技术新的进化；平台能力高低体现在其编程模型上，即是否能帮助用户高效、低成本的构建新一代应用；平台除了大幅提升企业价值交付的能力，更重要的是建立起应用开发生态。虽然云远比上述 SaaS 案例复杂，但遵循着类似的发展逻辑。几乎所有云服务的产品功能都通过 API 体现，云服务商也把发展平台编程模型，提升用户价值交付能力和建立应用开发生态作为最重要的目标。当我们从编程模型的视角去审视云的产品体系，纷繁复杂的云服务各自的定位逐渐清晰。基础设施即服务（IaaS）和容器技术是云的基础设施，以 K8S 为代表的容器编排服务是云原生应用的操作系统，面向特定领域的后端服务（BaaS）则是云的 API。为了实现更高的生产力，在存储、数据库、中间件、大数据、AI 等领域，大量的 BaaS 服务是全托管、Serverless 的形态，这一趋势已持续多年。例如现在客户已经非常习惯使用 Serverless 化的对象存储，而不是自己基于服务器搭建数据存储系统。当云提供了丰富的 Serverless BaaS 服务后，需要一种新的通用计算服务，能够屏蔽基础设施的复杂度，基于云服务快速构建应用。因此 Serverless 计算应运而生，它包含了以下要素： Serverless 计算是全托管的计算服务，客户编写代码构建应用，无需管理和运维服务器等底层基础设施； Serverless 计算是通用、普适的，结合云 API（BaaS 服务）的能力，能够支撑云上所有重要类型的应用； Serverless 计算不但实现了最纯粹的按需付费（为代码实际运行消耗的资源付费），也应当支持预付费等计量模式，使得客户成本在各种场景下，与传统方式相比都极具竞争力；不同于虚拟机或容器等面向资源的计算平台，Serverless 计算是面向应用的。要能整合和联动云的产品体系及其生态，帮助用户在价值交付方式上实现颠覆式创新。现状：当下 Serverless 在哪些场景落地？随着用户心智的建立，产品本身能力的完善，Serverless 近年来呈加速发展的趋势。我们看到在很多场景下，用户使用 Serverless 架构在可靠性、成本和研发运维效率等方面获得显著的收益。 1. 小程序 / Web / Mobile / API 后端服务在小程序、Web/Moible 应用、API 服务等场景中，业务逻辑复杂多变，迭代上线速度要求高，而且这类在线应用，资源利用率通常小于 30%，尤其是小程序等长尾应用，资源利用率更是低于 10%。Serverless 计算的免运维，按需付费的特点非常适合构建小程序/Web/Mobile/API 后端系统，通过预留计算资源+实时自动伸缩，开发者能够快速构建延时稳定、能承载高频访问的在线应用。在阿里内部，使用 Serverless 构建后端服务是落地最多的场景，包括前端全栈领域的 Serverless For Frontends，机器学习算法服务，小程序平台实现等等。 2. 大规模批处理任务处理典型的离线任务批处理系统，例如大规模音视频文件转码服务，包含计算资源管理、任务优先级调度、任务编排、任务可靠执行、任务数据可视化等一系列功能。如果从机器或者容器层次开始构建，用户通常使用消息队列进行任务信息的持久化和计算资源的分配，使用 K8S 等容器编排系统实现资源的伸缩和容错，自行搭建或集成监控报警系统。如果任务涉及多个步骤，还需要整合工作流服务实现可靠步骤执行，而通过 Serverless 计算平台，用户只需要专注于实现任务处理逻辑，而且 Serverless 计算的极致弹性能很好的满足突发任务对算力的需求。 3. 基于事件驱动架构的在线应用和离线数据处理典型的 Serverless 计算服务通过事件驱动的方式广泛的与云端各种类型服务集成，用户无需管理服务器等基础设施和编写集成多个服务的胶水代码，轻松构建松耦合、分布式的事件驱动架构的应用。以阿里云函数计算为例，通过 API 网关和函数计算的集成，用户可以快速实现 API 后端服务。通过对象存储和函数计算的事件集成，函数能实时响应对象创建、删除等事件，实现以对象存储为中心的大规模数据处理。通过消息中间件和函数计算的事件集成，用户能快速实现海量消息的处理。通过和阿里云 EventBridge 的集成，无论是一方云服务，还是三方的 SaaS 服务，或者是用户自建的系统，所有的事件都可以快速便捷的被函数计算处理。 4. 运维自动化通过定时触发器，用户能够用函数快速实现定时任务，而无须管理执行任务的底层服务器。通过云监控触发器，用户可以接收 ECS 重启/宕机，OSS 对象存储流控等 IaaS 层服务的运维事件，并自动触发函数处理。未来：Serverless 将向何处去？近年来，Serverless 一直在高速发展，呈现出越来越大的影响力。主流的云服务商也在不断地丰富云产品体系，提供更好的开发工具，更高效的应用交付流水线，更好的可观测性，更细腻的产品间集成，但一切才刚刚开始。趋势 1：Serverless 将无处不在任何足够复杂的技术方案将被实现为全托管、Serverless 化的后端服务。不只是云产品，也包括合作伙伴和三方服务。云及其生态的能力将通过 API + Serverless 来体现。事实上，对于任何以 API 作为功能透出方式的平台型产品或组织，例如钉钉、微信、滴滴等等，Serverless 都将是其平台战略中最重要的部分。趋势 2：和容器生态将更加紧密融合容器在应用的可移植性和交付流程敏捷性上实现了颠覆式创新，是现代应用构建和交付的一次重要变革。绝佳的可移植性：通过操作系统虚拟化技术，应用及其运行环境被虚拟化为容器，实现了 build once，run anywhere，容器化的应用能够无差别的运行在开发机，on-premise，以及公有云的环境中；敏捷的交付流程：容器镜像已经成为应用封装和分发事实上的标准，今天全世界的开发人员都习惯将容器作为应用交付和分发的方式，围绕容器，已经建立了完整的应用交付工具链。容器已经成为现代应用运行的基础，但用户仍然需要负责服务器等基础设施的管理，包括水位预估、机器运维等等。因此业界出现了 AWS Fargate，阿里云 ECI 等 Serverless container 服务，帮助用户专注于容器化应用的构建，而无需负担基础设施的管理成本。从 Serverless 视角来看，函数计算等 Serverless 计算服务为用户带来了全自动的伸缩模式、极致弹性以及完全按需的计量方式，却在用户开发习惯的兼容性、可移植性、完工具链和生态等方面面临挑战，而这正是容器的优势。相信随着技术的发展，未来容器镜像也将成为函数计算等更多 Serverless 应用的分发方式，容器庞大的工具生态和 Serverless 免运维、极致弹性结合在一起，为用户带来全新的体验。趋势 3：Serverless 将通过事件驱动的方式连接云及其生态中的一切我们已经在前述章节中讨论了函数计算通过事件驱动和云服务连接的意义，这样的能力也会扩展到整个云的生态。无论是用户自己的应用，还是合作伙伴的服务；无论是 on-premise 环境，还是公有云，所有的事件都能以 Serverless 的方式处理。云服务及其生态将更紧密的连接在一些，成为用户构建弹性高可用的应用的基石。趋势 4：Serverless 计算将持续提高计算密度，实现最佳的性能功耗比和性能价格比虚拟机和容器是两种取向不同的虚拟化技术。前者安全性强，开销小，后者则相反。Serverless 计算平台一方面要求最高的安全性和最小的资源开销，鱼与熊掌必须兼得；另一方面要保持对原有程序执行方式的兼容，比如支持任意二进制文件，这使得适用于特定语言 VM 的方案不可行。因此 AWS Firecracker，Google gVisor 这样新的轻量虚拟化技术应运而生。以 AWS Firecracker 为例，通过对设备模型的裁剪和 kernel 加载流程的优化，实现了百毫秒的启动速度和极小的内存开销。一台裸金属实例支持数以千计的实例运行。结合应用负载感知的资源调度算法，云服务商有望在保持稳定性能的前提下，将超卖率提升一个数量级。当 Serverless 计算的规模和影响力变得越来越大，从应用框架、语言、硬件等层面，根据 Serverless 的负载特点进行端对端优化就变得非常有意义。新的 Java 虚拟机技术大幅提高 Java 应用的启动速度，非易失性内存帮助实例更快被唤醒，CPU 硬件和操作系统协作对高密环境下性能扰动实现精细隔离，所有新技术正在创造崭新的计算环境。实现最佳性能功耗比和性能价格比的另一个重要方向是支持异构硬件。长期以来，X86 处理器的性能越来越难以提升。而在 AI 等对算力要求极高的场景，GPU、FPGA、TPU（Tensor Processing Units）等架构的处理器的计算效率更具优势。随着异构硬件虚拟化、资源池化、异构资源调度、应用框架支持的成熟，异构硬件的算力也能通过 Serverless 的方式释放，大幅降低用户使用门槛。后记 2009 年，UC Berkeley 发表了一篇著名的论文“Above the Clouds: A Berkeley View of Cloud Computing”，讨论了云及其价值、挑战和演进路径，其中的真知灼见在云的十年发展历程中陆续被验证，今天已没有人怀疑云的价值和对各行各业深刻的影响。2019 年，他们发表了新的论文，“Cloud Programming Simplified: A Berkeley View on Serverless Computing”，预言 Serverless 将主导下一个十年云的发展，产业的发展是螺旋式上升，Serverless 的诞生和兴起逻辑早已蕴含其中。相信下一个十年， Serverless 将重塑企业创新的方式，帮助云成为社会发展的强大动力。课程推荐为了更多开发者能够享受到 Serverless 带来的红利，这一次，我们集结了 10+ 位阿里巴巴 Serverless 领域技术专家，打造出最适合开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。点击即可免费观看课程：https://developer.aliyun.com/learning/roadmap/serverless “阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

云原生存储详解：容器存储与 K8s 存储卷

作者 | 阚俊宝阿里云技术专家导读：云原生存储详解系列文章将从云原生存储服务的概念、特点、需求、原理、使用及案例等方面，和大家一起探讨云原生存储技术新的机遇与挑战。本文为该系列文章的第二篇，会对容器存储的相关概念进行讲述，欢迎大家在留言区参与讨论。相关文章推荐：云原生存储详解：云原生应用的基石云原生存储详解：容器存储与 K8s 存储卷云原生存储的两个关键领域：Docker 存储卷、K8s 存储卷； Docker 存储卷：容器服务在单节点的存储组织形式，关注数据存储、容器运行时的相关技术； K8s 存储卷：关注容器集群的存储编排，从应用使用存储的角度关注存储服务。 Docker 存储容器服务之所以如此流行，一大优势即来自于运行容器时容器镜像的组织形式。容器通过复用容器镜像的技术，实现在相同节点上多个容器共享一个镜像资源（更细一点说是共享某一个镜像层），避免了每次启动容器时都拷贝、加载镜像文件，这种方式既节省了主机的存储空间，又提高了容器启动效率。 1. 容器读写层为了提高节点存储的使用效率，容器不光在不同运行的容器之间共享镜像资源，而且还实现了在不同镜像之间共享数据。共享镜像数据的实现原理：镜像是分层组合而成的，即一个完整的镜像会包含多个数据层，每层数据相互叠加、覆盖组成了最终的完整镜像。为了实现多个容器间共享镜像数据，容器镜像每一层都是只读的。而通过实践我们得知，使用镜像启动一个容器的时候，其实是可以在容器里随意读写的，这是如何实现的呢？容器使用镜像时，在多个镜像分层的最上面还添加了一个读写层。每一个容器在运行时，都会基于当前镜像在其最上层挂载一个读写层，用户针对容器的所有操作都在读写层中完成。一旦容器销毁，这个读写层也随之销毁。如上图所示例子，一个节点上共有 3 个容器，分别基于 2 个镜像运行。镜像存储层说明如下：该节点上共包含 6 个镜像层：Layer 1~6。镜像 1 由：Layer 1、3、4、5 组成；镜像 2 由：Layer 2、3、5、6 组成。所以两个镜像共享了 Layer 3、5 两个镜像层；容器存储说明：容器 1：使用镜像 1 启动容器 2：使用镜像 1 启动容器 3：使用镜像 2 启动容器 1 和容器 2 共享镜像 1，且每个容器有自己的可写层；容器 1（2）和容器 3 共享镜像 2 个层（Layer3、5）；通过上述例子可以看到，通过容器镜像分层实现数据共享可以大幅减少容器服务对主机存储的资源需求。上面给出了容器读写层结构，而读写的原则：对于读：容器由这么多层的数据组合而成，当不同层次的数据重复时，读取的原则是上层数据覆盖下层数据；对于写：容器修改某个文件时，都是在最上层的读写层进行。主要实现技术有：写时复制、用时配置。 1）写时复制写时复制（CoW：copy-on-write），表示只在需要写时才去复制，是针对已有文件的修改场景。CoW 技术可以让所有的容器共享 image 的文件系统，所有数据都从 image 中读取，只有当要对文件进行写操作时，才从 image 里把要写的文件复制到最上面的读写层进行修改。所以无论有多少个容器共享同一个 image，所做的写操作都是对从 image 中复制后在复本上进行，并不会修改 image 的源文件，且多个容器操作同一个文件，会在每个容器的文件系统里生成一个复本，每个容器修改的都是自己的复本，相互隔离，相互不影响。 2）用时配置用时分配：在镜像中原本没有某个文件的场景，只有在要新写入一个文件时才分配空间，这样可以提高存储资源的利用率。比如启动一个容器，并不会为这个容器预分配一些磁盘空间，而是当有新文件写入时，才按需分配新空间。 2. 存储驱动存储驱动是指如何对容器的各层数据进行管理，已达到上述需要实现共享、可读写的效果。即：容器存储驱动实现了容器读写层数据的存储和管理。常见的存储驱动： AUFS OverlayFS Devicemapper Btrfs ZFS 以 AUFS 为例，我们来讲述一下存储驱动的工作原理： AUFS 是一种联合文件系统（UFS），是文件级的存储驱动。 AUFS 是一个能透明叠加一个或多个现有文件系统的层状文件系统，把多层文件系统合并成单层表示。即：支持将不同目录挂载到同一个虚拟文件系统下的文件系统。可以一层一层地叠加修改文件，其底层都是只读的，只有最上层的文件系统是可写的。当需要修改一个文件时，AUFS 创建该文件的一个副本，使用 CoW 将文件从只读层复制到可写层进行修改，结果也保存在可写层。在 Docker 中，底下的只读层就是 image，可写层就是 Container 运行时。其他各种存储驱动这里不再细讲，有兴趣的同学可以到网上查询资料。 3. Docker 数据卷介绍容器中的应用读写数据都是发生在容器的读写层，镜像层+读写层映射为容器内部文件系统、负责容器内部存储的底层架构。当我们需要容器内部应用和外部存储进行交互时，需要一个类似于计算机 U 盘一样的外置存储，容器数据卷即提供了这样的功能。另一方面：容器本身的存储数据都是临时存储，在容器销毁的时候数据会一起删除。而通过数据卷将外部存储挂载到容器文件系统，应用可以引用外部数据，也可以将自己产出的数据持久化到数据卷中，所以容器数据卷是容器进行数据持久化的实现方式。容器存储组成：只读层（容器镜像） + 读写层 + 外置存储（数据卷）容器数据卷从作用范围可以分为：单机数据卷和集群数据卷。单机数据卷即为容器服务在一个节点上的数据卷挂载能力，docker volume 是单机数据卷的代表实现；集群数据卷则关注的是集群级别的数据卷编排能力，K8s 数据卷则是集群数据卷的主要应用方式。 Docker Volume 是一个可供多个容器使用的目录，它绕过 UFS，包含以下特性：数据卷可以在容器之间共享和重用；相比通过存储驱动实现的可写层，数据卷读写是直接对外置存储进行读写，效率更高；对数据卷的更新是对外置存储读写，不会影响镜像和容器读写层；数据卷可以一直存在，直到没有容器使用。 1）Docker 数据卷类型 Bind：将主机目录/文件直接挂载到容器内部。需要使用主机的上的绝对路径，且可以自动创建主机目录；容器可以修改挂载目录下的任何文件，是应用更具有便捷性，但也带来了安全隐患。 Volume：使用第三方数据卷的时候使用这种方式。 Volume命令行指令：docker volume (create/rm)；是Docker提供的功能，所以在非 docker 环境下无法使用；分为命名数据卷和匿名数据卷，其实现是一致的，区别是匿名数据卷的名字为随机码；支持数据卷驱动扩展，实现更多外部存储类型的接入。 Tmpfs：非持久化的卷类型，存储在内存中。数据易丢失。 2）Bind 挂载方式语法 -v: src:dst:opts 只支持单机版。 Src：表示卷映射源，主机目录或文件，需要是绝对地址； Dst：容器内目标挂载地址； Opts：可选，挂载属性：ro, consistent, delegated, cached, z, Z； Consistent, delegated, cached：为mac系统配置共享传播属性； Z、z：配置主机目录的selinux label。示例： $ docker run -d --name devtest -v /home:/data:ro,rslave nginx $ docker run -d --name devtest --mount type=bind,source=/home,target=/data,readonly,bind-propagation=rslave nginx $ docker run -d --name devtest -v /home:/data:z nginx 3）Volume 挂载方式语法 -v: src:dst:opts 只支持单机版。 Src：表示卷映射源，数据卷名、空； Dst：容器内目标目录； Opts：可选，挂载属性：ro（只读）。示例： $ docker run -d --name devtest -v myvol:/app:ro nginx $ docker run -d --name devtest --mount source=myvol2,target=/app,readonly nginx 4. Docker 数据卷使用 Docker 数据卷使用方式： 1）Volume 类型匿名数据卷：docker run –d -v /data3 nginx；会主机上默认创建目录：/var/lib/docker/volumes/{volume-id}/_data进行映射；命名数据卷：docker run –d -v nas1:/data3 nginx；如果当前找不到nas1卷，会创建一个默认类型(local)的卷。 2）Bind 方式 docker run -d -v /test:/data nginx如果主机上没有/test目录，则默认创建此目录。 3）数据卷容器数据卷容器是一个运行中的容器，其他容器可以继承此容器中的挂载数据卷，则此容器的所有挂载都会在引用容器中体现。 docker run -d --volumes-from nginx1 -v /test1:/data1 nginx继承所有来自配置容器的数据卷，并包含自己定义的卷。 4）数据卷的挂载传播 Docker volume 支持挂载传播的配置：Propagation。 Private：挂载不传播，源目录和目标目录中的挂载都不会在另一方体现； Shared：挂载会在源和目的之间传播； Slave：源对象的挂载可以传播到目的对象，反之不行； Rprivate：递归 Private，默认方式； Rshared：递归 Shared； Rslave：递归 Slave。示例： $ docker run –d -v /home:/data:shared nginx 表示：主机/home下面挂载的目录，在容器/data下面可用，反之可行； $ docker run –d -v /home:/data:slave nginx 表示：主机/home下面挂载的目录，在容器/data下面可用，反之不行； 5）数据卷挂载的可见性 Volume 挂载可见性：本地空目录、镜像空目录：无特殊处理；本地空目录、镜像非空目录：镜像目录的内容拷贝到主机；(是拷贝，不是映射；即使容器删除内容也会保存)；本地非空目录、镜像空目录：本地目录内容映射到容器；本地非空目录、镜像非空目录：本地目录内容映射到容器,容器目录的内容被隐藏。 Bind 挂载可见性：以主机目录为准。本地空目录、镜像空目录：无特殊处理；本地空目录、镜像非空目录：容器目录变成空；本地非空目录、镜像空目录：本地目录内容映射到容器；本地非空目录、镜像非空目录：本地目录内容映射到容器，容器目录的内容被隐藏。 5. Docker数据卷插件 Docker 数据卷实现了将容器外部存储挂载到容器文件系统的方式。为了扩展容器对外部存储类型的需求，docker 提出了通过存储插件的方式挂载不同类型的存储服务。扩展插件统称为 Volume Driver，可以为每种存储类型开发一种存储插件。单个节点上可以部署多个存储插件；一个存储插件负责一种存储类型的挂载服务。 Docker Daemon 与 Volume driver 通信方式有： Sock文件：linux 下放在/run/docker/plugins 目录下 Spec文件：/etc/docker/plugins/convoy.spec 定义 Json文件：/usr/lib/docker/plugins/infinit.json 定义实现接口： Create, Remove, Mount, Path, Umount, Get, List, Capabilities; 使用示例： $ docker volume create --driver nas -o diskid="" -o host="10.46.225.247" -o path=”/nas1" -o mode="" --name nas1 Docker Volume Driver 适用在单机容器环境或者 swarm 平台进行数据卷管理，随着 K8s 的流行其使用场景已经越来越少，关于 VolumeDriver 的详细介绍这里不在细讲，有兴趣可以参考：https://docs.docker.com/engine/extend/plugins_volume/ K8s 存储卷 1. 基础概念根据之前的描述，为了实现容器数据的持久化我们需要使用数据卷的功能，在 K8s 编排系统中如何为运行的负载(Pod)定义存储呢？K8s 是一个容器编排系统，其关注的是容器应用在整个集群的管理和部署形式，所以在考虑 K8s 应用存储的时候就需要从集群角度考虑。K8s 存储卷定义了在 K8s 系统中应用与存储的关联关系。其包含以下概念： 1）Volume 数据卷数据卷定义了外置存储的细节，并内嵌到 Pod 中作为 Pod 的一部分。其实质是外置存储在 K8s 系统的一个记录对象，当负载需要使用外置存储的时候，从数据卷中查到相关信息并进行存储挂载操作。生命周期和 Pod 一致，即 pod 被删除的时候数据卷也一起消失（注意不是数据删除）；存储细节定义在编排模板中，应用编排感知存储细节；一个负载（Pod）中可以同时定义多个 volume，可以是相同类型或不同类型的存储； Pod 的每个 container 可以引用一个或多个 volume，不同 container 可以同时使用相同 volume。 K8S Volume 常用类型：本地存储：如 HostPath、emptyDir，这些存储卷的特点是，数据保存在集群的特定节点上，并且不能随着应用飘逸，节点宕机时数据即不再可用；网络存储：Ceph、Glusterfs、NFS、Iscsi 等类型，这些存储卷的特点是数据不在集群的某个节点上，而是在远端的存储服务上，使用存储卷时需要将存储服务挂载到本地使用； Secret/ConfigMap：这些存储卷类型，其数据是集群的一些对象信息，并不属于某个节点，使用时将对象数据以卷的形式挂载到节点上供应用使用； CSI/Flexvolume：这是两种数据卷扩容方式，可以理解为抽象的数据卷类型。每种扩展方式都可再细化成不同的存储类型； PVC：一种数据卷定义方式，将数据卷抽象成一个独立于 pod 的对象，这个对象定义（关联）的存储信息即存储卷对应的真正存储信息，供 K8s 负载挂载使用。一些 volume 模板示例如下： volumes: - name: hostpath hostPath: path: /data type: Directory --- volumes: - name: disk-ssd persistentVolumeClaim: claimName: disk-ssd-web-0 - name: default-token-krggw secret: defaultMode: 420 secretName: default-token-krggw --- volumes: - name: "oss1" flexVolume: driver: "alicloud/oss" options: bucket: "docker" url: "oss-cn-hangzhou.aliyuncs.com" 2）PVC和PV K8s 存储卷是一个集群级别的概念，其对象作用范围是整个 K8s 集群，而不是而一个节点； K8s 存储卷包含一些对象（PVC、PV、SC），这些对象和应用负载（Pod）是独立，通过编排模板进行关联； K8s 存储卷可以有自己的独立生命周期，不依附于 Pod。 PVC 是 PersistentVolumeClaim 的缩写，译为存储声明；PVC 是在 K8s 中一种抽象的存储卷类型，代表了某个具体类型存储的数据卷表达。其设计意图是：存储与应用编排分离，将存储细节抽象出来并实现存储的编排（存储卷）。这样 K8s 中存储卷对象独立于应用编排而单独存在，在编排层面使应用和存储解耦。 PV 是 PersistentVolume 的缩写，译为持久化存储卷；PV 在 K8s 中代表一个具体存储类型的卷，其对象中定义了具体存储类型和卷参数。即目标存储服务所有相关的信息都保存在 PV 中，K8s 引用 PV 中的存储信息执行挂载操作。应用负载、PVC、PV 的关联关系为：从实现上看，只要有了 PV 既可以实现存储和应用的编排分离，也能实现数据卷的挂载，为何要用 PVC + PV 两个对象呢？K8s 这样设计是从应用角度对存储卷进行二次抽象；由于 PV 描述的是对具体存储类型，需要定义详细的存储信息，而应用层用户在消费存储服务的时候往往不希望对底层细节知道的太多，让应用编排层面来定义具体的存储服务不够友好。这时对存储服务再次进行抽象，只把用户关系的参数提炼出来，用 PVC 来抽象更底层的 PV。所以 PVC、PV 关注的对象不一样，PVC 关注用户对存储需求，给用户提供统一的存储定义方式；而 PV 关注的是存储细节，可以定义具体存储类型、存储挂载使用的详细参数等。使用时应用层会声明一个对存储的需求（PVC），而 K8s 会通过最佳匹配的方式选择一个满足 PVC 需求的 PV，并与之绑定。所以从职责上 PVC 是应用所需要的存储对象，属于应用作用域（和应用处于一个名词空间）；PV 是存储平面的存储对象，属于整个存储域（不属于某个名词空间）；下面给出 PVC、PV 的一些属性： PVC 和 PV 总是成对出现的，PVC 必须与 PV 绑定后才能被应用（Pod）消费； PVC 和 PV 是一一绑定关系，不存在一个 PV 被多个 PVC 绑定，或者一个 PVC 绑定多个 PV 的情况； PVC 是应用层面的存储概念，是属于具体的名词空间的； PV 是存储层面的存储概念，是集群级别的，不属于某个名词空间；PV 常由专门的存储运维人员负责管理；消费关系上：Pod 消费 PVC，PVC 消费 PV，而 PV 定义了具体的存储介质。 3）PVC 详细定义 PVC 定义的模板如下： apiVersion: v1 kind: PersistentVolumeClaim metadata: name: disk-ssd-web-0 spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: alicloud-disk-available volumeMode: Filesystem PVC 定义的存储接口包括：存储的读写模式、资源容量、卷模式等；主要参数说明如下： accessModes：存储卷的访问模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三种模式。 ReadWriteOnce 表示 pvc 只能同时被一个 pod 以读写方式消费； ReadWriteMany 可以同时被多个 pod 以读写方式消费； ReadOnlyMany 表示可以同时被多个 pod 以只读方式消费；注意：这里定义的访问模式只是编排层面的声明，具体应用在读写存储文件的时候是否可读可写，需要具体的存储插件实现确定。 storage：定义此 PVC 对象期望提供的存储容量，同样此处的数据大小也只是编排声明的值，具体存储容量要看底层存储服务类型。 volumeMode：表示存储卷挂载模式，支持 FileSystem、Block 两种模式； FileSystem：将数据卷挂载成文件系统的方式供应用使用；Block：将数据卷挂载成块设备的形式供应用使用。 4）PV 详细定义下面为云盘数据卷 PV 对象的编排示例： apiVersion: v1 kind: PersistentVolume metadata: labels: failure-domain.beta.kubernetes.io/region: cn-shenzhen failure-domain.beta.kubernetes.io/zone: cn-shenzhen-e name: d-wz9g2j5qbo37r2lamkg4 spec: accessModes: - ReadWriteOnce capacity: storage: 30Gi flexVolume: driver: alicloud/disk fsType: ext4 options: VolumeId: d-wz9g2j5qbo37r2lamkg4 persistentVolumeReclaimPolicy: Delete storageClassName: alicloud-disk-available volumeMode: Filesystem accessModes：存储卷的访问模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三种模式；具体含义同 PVC 字段； capacity：定义存储卷容量； persistentVolumeReclaimPolicy：定义回收策略，即删除 pvc 的时候如何处理 PV；支持 Delete、Retain 两种类型，动态数据卷部分会详细说明此参数； storageClassName：表示存储卷的使用的存储类名字，动态数据卷部分会详细说明此参数； volumeMode：同 PVC 中的 volumeMode 定义； Flexvolume：此字段表示具体的存储类型，这里 Flexvolume 为一种抽象的存储类型，并在 flexvolume 的子配置项中定义了具体的存储类型、存储参数。 5）PVC/PV 绑定 PVC 只有绑定了 PV 之后才能被 Pod 使用，而 PVC 绑定 PV 的过程即是消费 PV 的过程，这个过程是有一定规则的，下面规则都满足的 PV 才能被 PVC 绑定： VolumeMode：被消费 PV 的 VolumeMode 需要和 PVC 一致； AccessMode：被消费 PV 的 AccessMode 需要和 PVC 一致； StorageClassName：如果 PVC 定义了此参数，PV 必须有相关的参数定义才能进行绑定； LabelSelector：通过 label 匹配的方式从 PV 列表中选择合适的 PV 绑定； storage：被消费 PV 的 capacity 必须大于或者等于 PVC 的存储容量需求才能被绑定。满足上述所有需要的 PV 才可以被 PVC 绑定。如果同时有多个 PV 满足需求，则需要从 PV 中选择一个更合适的进行绑定；通常选择容量最小的，如果容量最小的也有多个，则随机选择。如果没有满足上述需求的 PV 存储，则 PVC 会处于 Pending 状态，等待有合适的 PV 出现了再进行绑定。 2. 静态、动态存储卷从上面的讨论我们了解到，PVC 是针对应用服务对存储的二次抽象，具有简洁的存储定义接口。而 PV 是具有繁琐存储细节的存储抽象，一般有专门的集群管理人员定义、维护。根据 PV 的创建方式可以将存储卷分为动态存储和静态存储卷：静态存储卷：由管理员创建的 PV 动态存储卷：由 Provisioner 插件创建的 PV 1）静态存储卷一般先由集群管理员分析集群中存储需求，并预先分配一些存储介质，同时创建对应的 PV 对象，创建好的 PV 对象等待 PVC 来消费。如果负载中定义了 PVC 需求，K8s 会通过相关规则实现 PVC 和匹配的 PV 进行绑定，这样就实现了应用对存储服务的访问能力。 2）动态存储卷由集群管理员配置好后端的存储池，并创建相应的模板（storageclass），等到有 PVC 需要消费 PV 的时候，根据 PVC 定义的需求，并参考 storageclass 的存储细节，由 Provisioner 插件动态创建一个 PV。两种卷的比较：动态存储卷和静态存储卷最终的效果都是：Pod -> PVC -> PV 的使用链路，且对象的具体模板定义都是一致的；动态存储卷和静态存储卷区别是：动态卷是插件自动创建 PV，而静态卷是集群管理员手动创建 PV。提供动态存储卷的优势：动态卷让 K8s 实现了 PV 的自动化生命周期管理，PV 的创建、删除都通过 Provisioner 完成；自动化创建 PV 对象，减少了配置复杂度和系统管理员的工作量；动态卷可以实现 PVC 对存储的需求容量和 Provision 出来的 PV 容量一致，实现存储容量规划最优。 3）动态卷的实现流程当用户声明一个 PVC 时，如果在 PVC 中添加了 StorageClassName 字段，其意图为：当 PVC 在集群中找不到匹配的 PV 时，会根据 StorageClassName 的定义触发相应的 Provisioner 插件创建合适的 PV 供绑定，即创建动态数据卷；动态数据卷时由 Provisioner 插件创建的，并通过 StorageClassName 与 PVC 进行关联。 StorageClass 可译为存储类，表示为一个创建 PV 存储卷的模板；在 PVC 触发自动创建PV的过程中，即使用 StorageClass 对象中的内容进行创建。其内容包括：目标 Provisioner 名字，创建 PV 的详细参数，回收模式等配置。 StorageClasss 模板定义如下： apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: alicloud-disk-topology parameters: type: cloud_ssd provisioner: diskplugin.csi.alibabacloud.com reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer provisioner：为一个注册插件的名字，此插件实现了创建 PV 的功能；一个 StorageClass 只能定义一个Provisioner； parameters：表示创建数据卷的具体参数；例如这里表示创建一个 SSD 类型的云盘； reclaimPolicy：用来指定创建 PV 的 persistentVolumeReclaimPolicy 字段值，支持 Delete/Retain；Delete 表示动态创建的 PV，在销毁的时候也会自动销毁；Retain 表示动态创建的 PV，不会自动销毁，而是由管理员来处理； allowVolumeExpansion：定义由此存储类创建的 PV 是否运行动态扩容，默认为 false；是否能动态扩容是有底层存储插件来实现的，这里只是一个开关； volumeBindingMode：表示动态创建 PV 的时间，支持 Immediate/WaitForFirstConsumer；分别表示立即创建和延迟创建。用户创建一个 PVC 声明时，会在集群寻找合适的 PV 进行绑定，如果没有合适的 PV 与之绑定，则触发下面流程： Volume Provisioner 会 watch 到这个 PVC 的存在，若这个 PVC 定义了 StorageClassName，且 StorageClass 对象中定义的 Provisioner 插件是自己，Provisioner 会触发创建 PV 的流程； Provisioner 根据 PVC 定义的参数（Size、VolumeMode、AccessModes）以及 StorageClass 定义的参数（ReclaimPolicy、Parameters）执行 PV 创建； Provisioner 会在存储介质端创建数据卷（通过 API 调用，或者其他方式），完成后会创建 PV 对象； PV 创建完成后，实现与 PVC 的绑定；以满足后续的 Pod 启动流程。 4）延迟绑定动态数据卷某种存储（阿里云云盘）在挂载属性上有所限制，只能将相同可用区的数据卷和 Node 节点进行挂载，不在同一个可用区不可以挂载。这种类型的存储卷通常遇到如下问题：创建了 A 可用区的数据卷，但是 A 可用区的节点资源已经耗光，导致 Pod 启动无法完成挂载；集群管理员在规划 PVC、PV 的时候不能确定在哪些可用区创建多个 PV 来备用。 StorageClass 中的 volumeBindingMode 字段正是用来解决此问题，如果将 volumeBindingMode 配置为 WaitForFirstConsumer 值，则表示 Provisioner 在收到 PVC Pending 的时候不会立即进行数据卷创建，而是等待这个 PVC 被 Pod 消费的时候才执行创建流程。其实现原理是： Provisioner 在收到 PVC Pending 状态的时候不会立即进行数据卷创建，而是等待这个 PVC 被 Pod 消费；如果有 Pod 消费此 PVC，调度器发现 PVC 是延迟绑定，则 pv 继续完成调度功能（后续会详细讲解存储调度）；且调度器会将调度结果 patch 到 PVC 的 metadata 中；当 Provisioner 发现 PVC 中写入了调度信息时，会根据调度信息获取创建目标数据卷的位置信息（zone、Node），并触发 PV 的创建流程。通过上述流程可见：延迟绑定会先让应用负载进行调度（确定有充足的资源供 pod 使用），然后再触发动态卷的创建流程，这样就避免了数据卷所在可用区没有资源的问题，也避免了存储预规划的不准确性问题。在多可用区集群环境中，更推荐使用延迟绑定的动态卷方案，目前阿里云 ACK 集群已经支持上述配置方案。 3. 使用示例下面给出一个 pod 消费 PVC、PV 的例子： apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nas-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi selector: matchLabels: alicloud-pvname: nas-csi-pv --- apiVersion: v1 kind: PersistentVolume metadata: name: nas-csi-pv labels: alicloud-pvname: nas-csi-pv spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain flexVolume: driver: "alicloud/nas" options: server: "***-42ad.cn-shenzhen.extreme.nas.aliyuncs.com" path: "/share/nas" --- apiVersion: apps/v1 kind: Deployment metadata: name: deployment-nas labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx1 image: nginx:1.8 - name: nginx2 image: nginx:1.7.9 volumeMounts: - name: nas-pvc mountPath: "/data" volumes: - name: nas-pvc persistentVolumeClaim: claimName: nas-pvc 模板解析：此应用为 Deployment 方式编排的一个 Nginx 服务，每个 pod 包含 2 个容器：nginx1、nginx2；模板中定义了 Volumes 字段，说明期望挂载数据卷给应用使用，此例中使用了 PVC 这种数据卷定义方式；应用内部：将数据卷 nas-pvc 挂载到 nginx2容器的 /data 目录上；nginx1 容器并没有挂载； PVC（nas-pvc）定义为一个不小于 50G 容量、读写方式为 ReadWriteOnce 的存储卷需求，且对 PV 有 Label 设置的需求； PV（nas-csi-pv）定义为一个容量为 50G、读写方式为 ReadWriteOnce、回收模式为 Retain、类型为 Flexvolume 抽象类型的存储卷，且具有 Label 配置；根据 PVC、PV 绑定的逻辑，此 PV 符合 PVC 消费要求，则 PVC 会和此 PV 进行绑定，并供 pod 挂载使用。总结此篇文章较为详细的讲述了容器存储的整体面貌，包括单机范围的 Docker 数据卷、和集群式的 K8s 数据卷；K8s 数据卷更多关注的时候集群级别的存储编排能力，同时也在节点上实现了具体的数据卷挂载流程。K8s 为了实现上述复杂的存储卷编排能力，其实现架构也较为复杂，下节内容我们将为您介绍 K8s 的存储架构和实现流程。课程推荐为了更多开发者能够享受到 Serverless 带来的红利，这一次，我们集结了 10+ 位阿里巴巴 Serverless 领域技术专家，打造出最适合开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。点击即可免费观看课程：https://developer.aliyun.com/learning/roadmap/serverless “阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

阿里巴巴云原生小助手个人页面-阿里云开发者社区

个人介绍

擅长的技术

险些没过试用期的二狗，他回来了！

投入 20 亿，赋能 1 万家，阿里云正式启动云原生合作伙伴计划

Serverless 的初心、现状和未来

云原生存储详解：容器存储与 K8s 存储卷

深度解读 OpenYurt ：边缘自治能力设计解析

SpringCloud 应用在 Kubernetes 上的最佳实践 —— 开发篇

云原生已来，只是分布不均

深度解读 OpenYurt：从边缘自治看 YurtHub 的扩展能力

测一测｜你的云原生架构几分熟？

CNCF 宣布首个中国原创项目 Harbor 毕业 | 云原生生态周报 Vol. 55

从零入门 Serverless | 一文详解 Serverless 架构模式

从零入门 Serverless | 一文搞懂函数计算及其工作原理

阿里高级技术专家：如何结构化地思考、做事、成长？

OAM 创始团队：揭秘 OAM Kubernetes 实现核心原理

险些没过试用期的二狗，他回来了！

投入 20 亿，赋能 1 万家，阿里云正式启动云原生合作伙伴计划

Serverless 的初心、现状和未来

云原生存储详解：容器存储与 K8s 存储卷

K8s 文档增加反种族歧视声明 | 云原生生态周报 Vol. 54

OAM 深入解读：使用 OAM 定义与管理 Kubernetes 内置 Workload

深度解读 OpenYurt ：边缘自治能力设计解析

无法通过阿里云试用期，是一种什么样的体验？

阿里云叔同：以容器为代表的云原生技术，已经成为释放云价值的最短路径

如何画好一张架构图？（内含知识图谱）

SpringCloud 应用在 Kubernetes 上的最佳实践 —— 开发篇

云原生已来，只是分布不均

深度解读 OpenYurt：从边缘自治看 YurtHub 的扩展能力

测一测｜你的云原生架构几分熟？

CNCF 宣布首个中国原创项目 Harbor 毕业 | 云原生生态周报 Vol. 55

从零入门 Serverless | 一文详解 Serverless 架构模式

从零入门 Serverless | 一文搞懂函数计算及其工作原理

阿里高级技术专家：如何结构化地思考、做事、成长？

OAM 创始团队：揭秘 OAM Kubernetes 实现核心原理

险些没过试用期的二狗，他回来了！

投入 20 亿，赋能 1 万家，阿里云正式启动云原生合作伙伴计划

Serverless 的初心、现状和未来

云原生存储详解：容器存储与 K8s 存储卷

K8s 文档增加反种族歧视声明 | 云原生生态周报 Vol. 54

OAM 深入解读：使用 OAM 定义与管理 Kubernetes 内置 Workload

Arthas 征文活动火热进行中，cherry 键盘等你来拿！（内附第二期中奖名单）

深度解读 OpenYurt ：边缘自治能力设计解析

无法通过阿里云试用期，是一种什么样的体验？

揭秘：如何为 Kubernetes 实现原地升级

阿里云叔同：以容器为代表的云原生技术，已经成为释放云价值的最短路径