登陆

从零开始入门 K8s | 使用存储和耐久化数据卷:中心常识

admin 2019-11-09 171人围观 ,发现0个评论

一、Volumes 介绍

Pod Volumes

首要来看一下 Pod Volumes 的运用场景:

  • 场景一:假如 pod 中的某一个容器在运转时反常退出,被 kubelet 从头拉起之后,怎样确保之前容器发生的重要数据没有丢掉?
  • 场景二:假如同一个 pod 中的多个容器想要同享数据,应该怎样去做?

以上两个场景,其实都能够凭借 Volumes 来很好地处理,接下来首要看一下 Pod Volumes 的常见类型:

  1. 本地存储,常用的有 emptydir/hostpath;
  2. 网络存储:网络存储其时的完结方法有两种,一种是 in-tree,它的完结代码是放在 K8s 代码库房中的,跟着 K8s 对存储类型支撑的增多,这种方法会给 K8s 自身的维护和开展带来很大的担负;而第二种完结方法是 out-of-tree,它的完结其实是给 K8s 自身解耦的,经过笼统接口将不同存储的 driver 完结从 K8s 代码库房中剥离,因而 out-of-tree 是后边社区主推的一种完结网络存储插件的方法;
  3. Projected Volumes:它其实是将一些装备信息,如 secret/configmap 用卷的方法挂载在容器中,让容器中的程序能够经过 POSIX 接口来拜访装备数据;
  4. PV 与 PVC 便是今日要要点介绍的内容。

Persistent Volumes

接下来看一下 PV(Persistent Volumes)。已然现已有了 Pod Volumes,为什么又要引进 PV 呢?咱们知道 pod 中声明的 volume 生命周期与 pod 是相同的,以下有几种常见的场景:

  • 场景一:pod 重建毁掉,如用 Deployment 办理的 pod,在做镜像晋级的进程中,会发生新的 pod并且删去旧的 pod ,那新旧 pod 之间怎样复用数据?
  • 场景二:宿主机宕机的时分,要把上面的 pod 搬迁,这个时分 StatefulSet 办理的 pod,其完结已完结了带卷搬迁的语义。这时经过 Pod Volumes 显然是做不到的;
  • 场景三:多个 pod 之间,假如想要同享数据,应该怎样去声明呢?咱们知道,同一个 pod 中多个容器想同享数据,能够凭借 Pod Volumes 来处理;当多个 pod 想同享数据时,Pod Volumes 就很难去表达这种语义;
  • 场景四:假如要想对数据卷做一些功用扩展性,如:snapshot、resize 这些功用,又应该怎样去做呢?

以上场景中,经过 Pod Volumes 很难精确地表达它的复用/同享语义,对它的扩展也比较困难。因而 K8s 中又引进了 Persistent Volumes 概念,它能够将存储和核算别离,经过不同的组件来办理存储资源和核算资源,然后解耦 pod 和 Volume 之间生命周期的相关。这样,当把 pod 删去之后,它运用的 PV 依然存在,还能够被新建的 pod 复用。

PVC 规划目的

了解 PV 后,应该怎样运用它呢?

用户在运用 PV 时其实是经过 PVC,为什么有了 P从零开始入门 K8s | 使用存储和耐久化数据卷:中心常识V 又规划了 PVC 呢?首要原因是为了简化 K8s 用户对存储的运用方法,做到责任别离。一般用户在运用存储的时分,只用声明所需的存储巨细以及拜访形式。

拜访形式是什么?其实便是:我要运用的存储是能够被多个 node 同享仍是只能单 node 独占拜访(留意是 node level 而不是 pod level)?只读仍是读写拜访?用户只用关怀这些东西,与存储相关的完结细节是不需求关怀的。

经过 PVC 和 PV 的概念,将用户需求和完结细节解耦开,用户只用经过 PVC 声明自己的存储需求。PV是有集群办理员和存储相关团队来一致运维和管控,这样的话,就简化了用户运用存储的方法。能够看到,PV 和 PVC 的规划其实有点像面向目标的接口与完结的联系。用户在运用功用时,只需关怀用户接口,不需关怀它内部杂乱的完结细节。

已然 PV 是由集群办理员一致管控的,接下来就看一下 PV 这个目标是怎样发生的。

Static Volume Provisioning

榜首种发生方法:静态发生方法 - 静态 Provisioning。

静态 Provisioning:由集群办理员事前去规划这个集群中的用户会怎样运用存储,它会先预分配一些存储,也便是预先创立一些 PV;然后用户在提交自己的存储需求(也便是 PVC)的时分,K8s 内部相关组件会协助它把 PVC 和 PV 做绑定;之后用户再经过 pod 去运用存储的时分,就能够经过 PVC 找到相应的 PV,它就能够运用了。

静态发生方法有什么缺乏呢?能够看到,首要需求集群办理员预分配,预分配其实是很难猜测用户实在需求的。举一个最简略的比如:假如用户需求的是 20G,可是集群办理员在分配的时分可能有 80G 、100G 的,但没有 20G 的,这样就很难满意用户的实在需求,也会形成资源糟蹋。有没有更好的方法呢?

Dynamic Volume Provisioning

第二种拜访方法:动态 Dynamic Provisioning。

动态供应是什么意思呢?便是说现在集群办理员不预分配 PV,他写了一个模板文件,这个模板文件是用来标明创立某一类型存储(块存储,文件存储等)所需的一些参数,这些参数是用户不关怀的,给存储自身完结有关的参数。用户只需求提交自身的存储需求,也便是 PVC 文件,并在 PVC 中指定运用的存储模板(StorageClass)。

K8s 集群中的管控组件,会结合 PVC 和 StorageClass 的信息动态,生成用户所需求的存储(PV),将 PVC 和 PV 进行绑定后,pod 就能够运用 从零开始入门 K8s | 使用存储和耐久化数据卷:中心常识PV 了。经过 StorageClass 装备生成存储所需求的存储模板,再结合用户的需求动态创立 PV 目标,做到按需分配,在没有添加用户运用难度的一同也解放了集群办理员的运维作业。

二、用例解读

接下来看一下 Pod Volumes、PV、PVC 及 StorageClass 详细是怎样运用的。

Pod Volumes 的运用

首要来看一下 Pod Volumes 的运用。如上图左边所示,咱们能够在 pod yaml 文件中的 Volumes 字段中,声明咱们卷的姓名以及卷的类型。声明的两个卷,一个是用的是 emptyDir,别的一个用的是 hostPath,这两种都是本地卷。在容器中应该怎样去运用这个卷呢?它其实能够经过 volumeMounts 这个字段,volumeMounts 字段里边指定的 name 其实便是它运用的哪个卷,mountPath 便是容器中的挂载途径。

这儿还有个 subPath,subPath 是什么?

先看一下,这两个容器都指定运用了同一个卷,便是这个 cache-volume。那么,在多个容器同享同一个卷的时分,为了阻隔数据,咱们能够经过 subPath 来完结这个操作。它会在卷里边树立两个子目录,然后容器 1 往 cache 下面写的数据其实都写在子目录 cache1 了,容器 2 往 cache 写的目录,其数据终究会落在这个卷里子目录下面的 cache2 下。

还有一个 readOnly 字段,readOnly 的意思其实便是只读挂载,这个挂载你往挂载点下面实践上是没有办法去写数据的。

别的 emptyDir、hostPath 都是本地存储,它们之间有什么纤细的不同呢?emptyDir 其实是在 pod 创立的进程中会暂时创立的一个目录,这个目录跟帅伯的宝贝着 pod 删去也会被删去,里边的数据会被清空掉;hostPath 望文生义,其实便是宿主机上的一个途径,在 pod 删去之后,这个目录仍是存在的,它的数据也不会被丢掉。这便是它们两者之间一个纤细的不同。

静态 PV 运用

接下来再看一下,PV 和 PVC 是怎样运用的。

先看一个静态 PV 创立方法。静态 PV 的话,首要是由办理员来创立的,办理员咱们这儿以 NAS,便是阿里云文件存储为例。我需求先在阿里云的文件存储控制台上去创立 NAS 存储,然后把 NAS 存储的相关信息要填到 PV 目标中,这个 PV 目标预创立出来后,用户能够经过 PVC 来声明自己的存储需求,然后再去创立 pod。创立 pod 仍是经过咱们方才解说的字段把存储挂载到某一个容器中的某一个挂载点下面。

那么接下来看一下 yaml 怎样写。集群办理员首要是在云存储厂商那儿先去把存储创立出来,然后把相应的信息填写到 PV 目标中。

刚刚创立的阿里云 NAS 文件存储对应的 PV,有个比较重要的字段:capacity,即创立的这个存储的巨细,accessModes,创立出来的这个存储它的拜访方法,咱们后边会解说总共有几种拜访方法。

然后有个 ReclaimPolicy,ReclaimPolicy 的意思便是:这块存储在被运用后,等它的运用方 pod 以及 PVC 被删去之后,这个 PV 是应该被删掉仍是被保存呢?其实便是 PV 的收回战略。

接下来看看用户怎样去运用该 PV 目标。用户在运用存储的时分,需求先创立一个 PVC 目标。PVC 目标里边,只需求指定存储需求,不必关怀存储自身的详细完结细节。存储需求包含哪些呢?首要是需求的巨细,也便是 resources.requests.storage;然后是它的拜访方法,即需求这个存储的拜访方法,这儿声明为 ReadWriteMany,也即支撑多 node 读写拜访,这也是文件存储的典型特性。

上图中左边,能够看到这个声明:它的 size 和它的access mode,跟咱们方才静态创立这块 PV 其实是匹配的。这样的话,当用户在提交 PVC 的时分,K8s 集群相关的组件就会把 PV 的 PVC bound 到一同。之后,用户在提交 pod yaml 的时分,能够在卷里边写上 PVC 声明,在 PVC 声明里边能够经过 claimName 来声明要用哪个 PVC。这时,挂载方法其实跟前面讲的相同,当提交完 yaml 的时分,它能够经过 PVC 找到 bound 着的那个 PV,然后就能够用那块存储了。这是静态 Provisioning 到被 pod 运用的一个进程。

动态 PV 运用

然后再看一下动态 Provisioning。动态 Provisioning 上面大名鼎鼎过,系统办理员不再预分配 PV,而仅仅创立一个模板文件。

这个模板文件叫 StorageClass,在 StorageClass 里边,咱们需求填的重要信息:榜首个是 provisioner,provisioner 是什么?它其实便是说我其时创立 PV 和对应的存储的时分,应该用哪个存储插件往来不断创立。

这些参数是经过 K8s 创立存储的时分,需求指定的一些细节参数。关于这些参数,用户是不需求关怀的,像这儿 regionld、zoneld、fsType 和它的类型。ReclaimPolicy 跟咱们方才解说的 PV 里的意思是相同的,便是说动态创立出来的这块 PV,当运用方运用完毕、Pod 及 PVC 被删去后,这块 PV 应该怎样处理,咱们这个当地写的是 delete,意思便是说当运用方 pod 和 PVC 被删去之后,这个 PV 也会被删去掉。

接下来看一下,集群办理员提交完 StorageClass,也便是提交创立 PV 的模板之后,用户怎样用,首要仍是需求写一个 PVC 的文件。

PVC 的文件里存储的巨细、拜访形式是不变的。现在需求新加一个字段,叫 StorageClassName,它的意思是指定动态创立 PV 的模板文件的姓名,这儿 StorageClassName 填的便是上面声明的 csi-disk。

在提交完 PVC之后,K8s 集群中的相关组件就会依据 PVC 以及对应的 StorageClass 动态生成这块 PV 给这个 PVC 做一个绑定,之后用户在提交自己的 yaml 时,用法和接下来的流程和前面的静态运用方法是相同的,经过 PVC 找到咱们动态创立的 PV,然后把它挂载到相应的容器中就能够运用了。

PV Spec 重要字段解析

接下来,咱们解说一下 PV 的一些重要字段:

  • Capacity:这个很好了解,便是存储目标的巨细;
  • AccessModes:也是用户需求关怀的,便是说我运用这个 PV 的方法。它有三种运用方法。
  • 一种是单 node 读写拜访;
  • 第二种是多个 node 只读拜访,是常见的一种数据的同享方法;
  • 第三种是多个 node 上读写拜访。

用户在提交 PVC 的时分,最重要的两个字段 —— Capacity 和 AccessModes。在提交 PVC后,K8s 集群中的相关组件是怎样去找到适宜的 PV 呢?首要它是经过为 PV 树立的 AccessModes 索引找到一切能够满意用户的 PVC 里边的 AccessModes 要求的 PV list,然后依据 PVC 的 Capacity,StorageClassName, Label Selector 进一步挑选 PV,假如满意条件的 PV 有多个,挑选 PV 的 size 最小的,accessmodes 列表最短的 PV,也即最小适宜准则。

  • ReclaimPolicy:这个便是方才大名鼎鼎的,我的用户方 PV 的 PVC 在删去之后,我的 PV 应该做怎样处理?常见的有三种方法。
  • 榜首种方法咱们就不说了,现在 K8s 中现已不引荐运用了;
  • 第二种方法 delete,也便是说 PVC 被删去之后,PV 也会被删去;
  • 第三种方法 Retain,便是保存,保存之后,后边这个 PV 需求办理员来手动处理;
  • StorageClassName:StorageClassName 这个咱们方才说了,咱们动态 Provisioning 时有必要指定的一个字段,便是说咱们要指定究竟用哪一个模板文件来生成 PV ;
  • NodeAffinity:便是说我创立出来的 PV,它能被哪些 node 去挂载运用,其实是有约束的。然后经过 NodeAffinity 来声明对node的约束,这样其实对 运用该 PV 的 pod 调度也有约束,便是说 pod 有必要要调度到这些能拜访 PV 的 node 上,才干运用这块 PV,这个字段在咱们下一解说说存储拓扑调度时在细说。

PV 状况流通

接下来咱们看一下 PV 的状况流通。首要在创立 PV 目标后,它会处在时间短的pending 状况;等真实的 PV 创立好之后,它就处在 available 状况。

available 状况意思便是能够运用的状况,用户在提交 PVC 之后,被 K8s 相关组件做完 bound(即:找到相应的 PV),这个时分 PV 和 PVC 就结合到一同了,此刻两者都处在 bound 状况。当用户在运用完 PVC,将其删去后,这个 PV 就处在 released 状况,之后它应该被删去仍是被保存呢?这个就会依靠咱们方才说的 ReclaimPolicy。

这儿有一个点需求特别阐明一下:当 PV 现已处在 released 状况下,它是没有办法直接回到 available 状况,也便是说接下来无法被一个新的 PVC 去做绑定。假如咱们想把现已 released 的 PV 复用,咱们这个时分一般应该怎样去做呢?

榜首种方法:咱们能够新建一个 PV 目标,然后把之前的 released 的 PV 的相关字段的信息填到新的 PV 目标里边,这样的话,这个 PV 就能够结合新的 PVC 了;第二种是咱们在删去 pod 之后,不要去删去 PVC 目标,这样给 PV 绑定的 PVC 仍是存在的,下次 pod 运用的时分,就能够直接经过 PVC 去复用。K8s 中的 StatefulSet 办理的 Pod 带存储的搬迁便是经过这种方法。

三、操作演示

接下来,我会在实践的环境中给咱们演示一下,静态 Provision从零开始入门 K8s | 使用存储和耐久化数据卷:中心常识ing 以及动态 Provisioning 详细操作方法。

静态 Provisioning 比如

静态 Provisioning 首要用的是阿里云的 NAS 文件存储;动态 Provisioning 首要用了阿里云的云盘。它们需求相应存储插件,插件我现已提早布置在我的 K8s 集群中了(csi-nasplugin 是为了在 K8s 中运用阿里云 NAS 所需的插件,csi-disk 是为了在 K8s 中运用阿里如此盘所需求的插件)。

咱们接下来先看一下静态 Provisioning 的 PV 的 yaml 文件。

volumeAttributes 是我在阿里云 nas 控制台预先创立的 NAS 文件系统的相关信息,咱们首要需求关怀的有 capacity 为 5Gi; accessModes 为多 node 读写拜访; reclaimPolicy:Retain,也便是当我运用方的 PVC 被删去之后,我这个 PV 是要保存下来的;以及在运用这个卷的进程中运用的 driver。

然后咱们把对应的 PV 创立出来:

咱们看一下上图 PV 的状况,现已处在 Available,也便是说它现已能够被运用了。

再创立出来 nas-pvc:

咱们看这个时分 PVC 现已新创立出来了,并且也现已和咱们上面创立的 PV 绑定到一同了。咱们看一下 PVC 的 yaml 里边写的什么。

其实很简略 ,便是我需求的巨细以及我需求的 accessModes。提交完之后,它就与咱们集群中现已存在的 PV 做匹配,匹配成功之后,它就会做 bound。

接下来咱们去创立运用 nas-fs 的 pod:

上图看到,这两个 Pod 都现已处在 running 状况了。

咱们先看一下这个 pod yaml:

pod yaml 里边声明晰方才咱们创立出来的 PVC 目标,然后把它挂载到 nas-container 容器中的 /data 下面。咱们这个 pod 是经过 deployment 创立两个副本,经过反亲和性,将两个副本调度在不同的 node 上面。

上图咱们能够看一下,两个 Pod 地点的宿主机是不相同的。

如下图所示:咱们登陆到榜首个上面,findmnt 看一下它的挂载信息,这个其实就挂载在我声明的 nas-fs 上,那咱们再在下面 touch 个 test.test.test 文件,咱们也会登陆到别的一个容器,看一下它有没有被同享。

咱们退出再登陆别的一个 pod(方才登陆的是榜首个,现在登陆第二个)。

如下图所示:咱们也 findmnt 一下,能够看到,这两个 pod 的长途挂载途径相同,也便是说咱们用的是同一个 NAS PV,咱们再看一下方才创立出来的那个是否存在。

能够看到,这个也是存在的,就阐明这两个运转在不同node上的 pod 同享了同一个 nas 存储。

接下来咱们看一下把两个 pod 删掉之后的状况。先删 Pod,接着再删一下对应的 PVC(K8s 内部对 pvc 目标由维护机制,在删去 pvc 目标时假如发现有 pod 在运用 pvc,pvc 是删去不掉的),这个可能要稍等一下。

看一下下图对应的 PVC 是不是现已被删掉了。

上图显现,它现已被删掉了。再看一下,方才的 nas PV 仍是在的,它的状况是处在 Released 状况,也便是说方才运用它的 PVC 现已被删掉了,然后它被 released 了。又由于咱们 RECLAIN POLICY 是 Retain,所以它这个 PV 是被保存下来的。

动态 Provisioning 比如

接下来咱们来看第二个比如,动态 Provisioning 的比如。咱们先把保存下来的 PV 手动删掉,能够看到集群中没有 PV了。接下来演示一下动态 Provisioning。

首要,先去创立一个生成 PV 的模板文件,也便是 storageclass。看一下 storageclass 里边的内容,其实很简略。

如上图所示,我事前指定的是我要创立存储的卷插件(阿里如此盘插件,由阿里云团队开发),这个咱们现已提早布置好了;咱们能够看到,parameters部分是创立存储所需求的一些参数,可是用户不需求关怀这些信息;然后是 reclaimPolicy,也便是说经过这个 storageclass 创立出来的 PV 在给绑定到一同的 PVC 删去之后,它是要保存仍是要删去。

如上图所示:现在这个集群中是没有 PV 的,咱们动态提交一个 PVC 文件,先看一下它的 PVC 文件。它的 accessModes-ReadWriteOnce (由于阿里如此盘其实只能是单 node 读写的,所以咱们声明这样的方法),它的存储巨细需求是 30G,它的 storageClassName 是 csi-disk,便是咱们方才创立的 storageclass,也便是说它指定要经过这个模板去生成 PV。

这个 PVC 此刻正处在 pending 状况,这就阐明它对应的 PV 还在创立进程中。

稍过一会,咱们看到现已有一个新的 PV 生成,这个 PV 其实便是依据咱们提交的 PVC 以及 PVC 里边指定的storageclass 动态生成的。之后 K8s 会将生成的 PV 以及咱们提交的 PVC,便是这个 disk PVC 做绑定,之后咱们就能够经过创立 pod 来运用了。

再看一下 pod yaml:

pod yaml 很简略,也是经过 PVC 声明,标明运用这个 PVC。然后是挂载点,下面咱们能够创立看一下。

如下图所示:咱们能够大约看一下 Events,首要被调度器调度,调度完之后,接下来会有个 attachdetach controller,它会去做 disk 的 attach 操作,便是把咱们对应的 PV 挂载到调度器调度的 node 上,然后Pod对应的容器才干发动,发动容器才干运用对应的盘。

接下来我会把 PVC 删掉,看一下 PV 会不会依据咱们的 reclaimPolicy 随之删掉呢?咱们先看一下,这个时分 PVC 仍是存在的,对应的 PV 也是存在的。

然后删一下 PVC,删完之后再看一下:咱们的 PV 也被删了,也便是说依据 reclaimPolicy,咱们在删去 PVC 的一同,PV 也会被删去掉。

咱们的演示部分就到这儿了。

四、架构规划

PV 和 PVC 的处理流程

咱们接下来看一下 K8s 中的 PV 和 PVC 系统的完好处理流程。我首要看一下这张图的右下部分里边大名鼎鼎的 csi。

csi 是什么?csi 的全称是 container storage interface,它是 K8s 社区后边对存储插件完结 ( out of tree ) 的官方引荐方法。csi 的完结大体能够分为两部分:

  • 榜首部分是由 k8s 社区驱动完结的通用的部分,像咱们这张图中的 csi-provisioner和 csi-attacher controller;
  • 别的一种是由云存储厂商实践的,对接云存储厂商的 OpenApi,首要是完结真实的 create/delete/mount/unmount 存储的相关操作,对应到上图中的 csi-controller-server 和 csi-node-server。

接下来看一下,当用户提交 yaml 之后,k8s 内部的处理流程。用户在提交 PVCyaml 的时分,首要会在集群中生成一个 PVC 目标,然后 PVC 目标会被 csi-provisioner controller watch 到,csi-provisioner 会结合 PVC 目标以及 PVC 目标中声明的 storageClass,经过 GRPC 调用 csi-controller-server,然后,到云存储服务这边去创立真实的存储,并终究创立出来 PV 目标。最终,由集群中的 PV controller 将 PVC 和 PV 目标做 bound 之后,这个 PV 就能够被运用了。

用户在提交 pod 之后,首要会被调度器调度选中某一个适宜的node,之后该 node 上面的 kubelet 在创立 pod 流程中会经过首要 csi-node-server 将咱们之前创立的 PV 挂载到咱们 pod 能够运用的途径,然后 kubelet 开端 create && start pod 中的一切 container。

PV、PVC 以及经过 csi 运用存储流程

咱们接下来经过另一张图来愈加详细看一下咱们 PV、PVC 以及经过 CSI 运用存储的完好流程。

首要分为三个阶段:

  • 榜首个阶段(Create 阶段)是用户提交完 PVC,由 csi-provisioner 创立存储,并生成 PV 目标,之后 PV controller 将 PVC 及生成的 PV 目标做 bound,bound 之后,create 阶段就完结了;
  • 之后用户在提交 pod yaml 的时分,首要会被调度选中某一个适宜的 node,等 pod 的运转 node 被选出来之后,会被 AD Controller watch 到 pod 选中的 node,它会去查找 pod 中运用了哪些 PV。然后它会生成一个内部的目标叫 VolumeAttachment 目标,从而去触发 csi-attacher去调用 csi-controller-server 去做真实的 attache 操作,attach 操作调到云存储厂商 OpenAPI。这个 attach 操作便是将存储 attach到 pod 将会运转的 node 上面。第二个阶段 —— attach 阶段完结;
  • 然后咱们接下来看第三个阶段。第三个阶段发生在 kubelet 创立 pod 的进程中,它在创立 pod 的进程中,首要要去做一个 mount,这儿的 mount 操作是为了将现已 attach 到这个 node 上面那块盘,进一步 mount 到 pod 能够运用的一个详细途径,之后 kubelet 才开端创立并发动容器。这便是 PV 加 PVC 创立存储以及运用存储的第三个阶段 —— mount 阶段。

总的来说,有三个阶段:榜首个 create 阶段,首要是创立存储;第二个 attach 阶段,便是将那块存储挂载到 node 上面(一般为将存储 load 到 node 的 /dev 下面);第三个 mount 阶段,将对应的存储进一步挂载到 pod 能够运用的途径。这便是咱们的 PVC、PV、现现已过 CSI 完结的卷从创立到运用的完好流程。

本文总结

本文内容就到此为止了,这儿为咱们简略总结一下:

  • 介绍了 K8s Volume 的运用场景,以及自身局限性;
  • 经过介绍 K8s 的 PVC 和 PV 系统,阐明 K8s 经过 PVC 和 PV 系统增强了 K8s Volumes 在多 Pod 同享/搬迁/存储扩展等场景下的才能的必要性以及规划思维;
  • 经过介绍 PV(存储)的不同供应形式 (static and dynamic),学习了怎样经过不同方法为集群中的 Pod 供应所需的存储;
  • 经过 PVC&PV 在 K8s 中完好的处理流程,深化了解 PVC&PV 的作业原理 。

---------------------------------

本文作者: 至天

原文链接:https://yq.aliyun.com/articles/720251?utm_content=g_1000080951

本文为云栖社区原创内容,未经答应不得转载。

请关注微信公众号
微信二维码
不容错过
Powered By Z-BlogPHP