泉州快速建站模板,免费推广网站,wordpress重置,哪个公司的装饰设计公司作者 | 阚俊宝 阿里巴巴技术专家参与文末留言互动#xff0c;即有机会获得赠书福利#xff01;导读#xff1a;云原生存储详解系列文章将从云原生存储服务的概念、特点、需求、原理、使用及案例等方面#xff0c;和大家一起探讨云原生存储技术新的机遇与挑战。本文为该系列… 作者 | 阚俊宝  阿里巴巴技术专家参与文末留言互动即有机会获得赠书福利导读云原生存储详解系列文章将从云原生存储服务的概念、特点、需求、原理、使用及案例等方面和大家一起探讨云原生存储技术新的机遇与挑战。本文为该系列文章的第二篇会对容器存储的相关概念进行讲述欢迎大家在留言区参与讨论。相关文章推荐云原生存储详解云原生应用的基石云原生存储详解容器存储与 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)写时复制写时复制(CoWcopy-on-write)表示只在需要写时才去复制是针对已有文件的修改场景。CoW 技术可以让所有的容器共享 image 的文件系统所有数据都从 image 中读取只有当要对文件进行写操作时才从 image 里把要写的文件复制到最上面的读写层进行修改。所以无论有多少个容器共享同一个 image所做的写操作都是对从 image 中复制后在复本上进行并不会修改 image 的源文件且多个容器操作同一个文件会在每个容器的文件系统里生成一个复本每个容器修改的都是自己的复本相互隔离相互不影响。2)用时配置用时分配在镜像中原本没有某个文件的场景只有在要新写入一个文件时才分配空间这样可以提高存储资源的利用率。比如启动一个容器并不会为这个容器预分配一些磁盘空间而是当有新文件写入时才按需分配新空间。2. 存储驱动存储驱动是指如何对容器的各层数据进行管理已达到上述需要实现共享、可读写的效果。即容器存储驱动实现了容器读写层数据的存储和管理。常见的存储驱动AUFSOverlayFSDevicemapperBtrfsZFS以 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, ZConsistent, delegated, cached为 mac 系统配置共享传播属性Z、z配置主机目录的 selinux label。示例$ docker run -d --name devtest -v /home:/data:ro,rslave nginx$ docker run -d --name devtest --mount typebind,source/home,target/data,readonly,bind-propagationrslave nginx$ docker run -d --name devtest -v /home:/data:z nginx3)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 sourcemyvol2,target/app,readonly nginx4. 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递归 SharedRslave递归 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 host10.46.225.247 -o path”/nas1 -o mode --name nas1Docker 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.com2)PVC 和 PVK8s 存储卷是一个集群级别的概念其对象作用范围是整个 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 消费 PVCPVC 消费 PV而 PV 定义了具体的存储介质。3)PVC 详细定义PVC 定义的模板如下apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: disk-ssd-web-0spec:  accessModes:  - ReadWriteOnce  resources:    requests:      storage: 20Gi  storageClassName: alicloud-disk-available  volumeMode: FilesystemPVC 定义的存储接口包括存储的读写模式、资源容量、卷模式等主要参数说明如下accessModes存储卷的访问模式支持ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三种模式。ReadWriteOnce 表示 pvc 只能同时被一个 pod 以读写方式消费ReadWriteMany 可以同时被多个 pod 以读写方式消费ReadOnlyMany 表示可以同时被多个 pod 以只读方式消费。注意这里定义的访问模式只是编排层面的声明具体应用在读写存储文件的时候是否可读可写需要具体的存储插件实现确定。storage定义此 PVC 对象期望提供的存储容量同样此处的数据大小也只是编排声明的值具体存储容量要看底层存储服务类型。volumeMode表示存储卷挂载模式支持 FileSystem、Block 两种模式FileSystem将数据卷挂载成文件系统的方式供应用使用Block将数据卷挂载成块设备的形式供应用使用。4)PV 详细定义下面为云盘数据卷 PV 对象的编排示例apiVersion: v1kind: PersistentVolumemetadata:  labels:    failure-domain.beta.kubernetes.io/region: cn-shenzhen    failure-domain.beta.kubernetes.io/zone: cn-shenzhen-e  name: d-wz9g2j5qbo37r2lamkg4spec:  accessModes:  - ReadWriteOnce  capacity:    storage: 30Gi  flexVolume:    driver: alicloud/disk    fsType: ext4    options:      VolumeId: d-wz9g2j5qbo37r2lamkg4  persistentVolumeReclaimPolicy: Delete  storageClassName: alicloud-disk-available  volumeMode: FilesystemaccessModes存储卷的访问模式支持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 插件创建的 PV1)静态存储卷一般先由集群管理员分析集群中存储需求并预先分配一些存储介质同时创建对应的 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/v1kind: StorageClassmetadata:  name: alicloud-disk-topologyparameters:  type: cloud_ssdprovisioner: diskplugin.csi.alibabacloud.comreclaimPolicy: DeleteallowVolumeExpansion: truevolumeBindingMode: WaitForFirstConsumerprovisioner为一个注册插件的名字此插件实现了创建 PV 的功能一个 StorageClass 只能定义一个Provisionerparameters表示创建数据卷的具体参数例如这里表示创建一个 SSD 类型的云盘reclaimPolicy用来指定创建 PV 的 persistentVolumeReclaimPolicy 字段值支持 Delete/RetainDelete 表示动态创建的 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: v1kind: PersistentVolumeClaimmetadata:  name: nas-pvcspec:  accessModes:  - ReadWriteOnce  resources:    requests:      storage: 50Gi  selector:    matchLabels:      alicloud-pvname: nas-csi-pv---apiVersion: v1kind: PersistentVolumemetadata:  name: nas-csi-pv  labels:    alicloud-pvname: nas-csi-pvspec:  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/v1kind: Deploymentmetadata:  name: deployment-nas  labels:    app: nginxspec:  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 的存储架构和实现流程。- 赠书福利 -6 月 22 日 1200 前在留言区欢迎大家讨论交流你对于容器存储的疑惑精选留言点赞第 1 名即可免费获得此书