一文读懂 Kubernetes 存储设计
在 docker 的设计中,容器内的文件是临时存放的,当容器被删除后,容器内部的数据将会一同被清空。不过,我们可以通过在 docker run
启动容器时,使用 --volume/-v
参数来指定挂载卷,这样就能够将容器内部的路径挂载到主机,当我们在容器内部存放数据时会被同步到被挂载的主机路径中,容器删除后,保存到主机路径中的数据仍然存在。
docker 通过挂载卷的方式解决了持久化存储的问题,但 K8s 存储要面临的问题比这要复杂的多,K8s 通常会在多个主机部署节点,如果由 K8s 编排的 docker 容器崩溃,K8s 可能会在其他节点上重新拉起容器,原来节点主机上挂载的容器目录就无法使用了。K8s 为了解决容器存储的诸多限制,对存储资源做了一层抽象,叫作卷(Volume)。
Kubernetes 支持的卷类型
K8s 支持的卷基本上可以分为三类:配置信息、临时存储、持久存储。接下来我将一一介绍。
配置信息
首先我们来关注下配置信息,我们常见的应用不管是哪种类型,一般都会用到配置文件或启动参数,K8s 将配置信息进行了抽象,定义成了几种资源,常用的配置信息主要包含以下三种:
ConfigMap
Secret
DownwardAPI
ConfigMap
ConfigMap 卷主要用来保存应用的配置数据,以一个或多个 key: value
形式存在,其中 value
可以是字面量或配置文件。
ConfigMap 在设计上不是用来保存大量数据的,在 ConfigMap 中保存的数据不可超过 1MiB
(兆字节)。
创建示例
通过命令行创建
在创建 ConfigMap 的时候可以通过 --from-literal
参数来指定 key: value
,以下示例中 foo=bar
即为字面量形式,bar=bar.txt
为配置文件形式。
bar.txt
内容如下:
通过 kubectl describe
命令查看新创建的名称为 c1
的这个 ConfigMap
资源内容。
根据输出结果可以看到数据被保存到 Data
属性中,每个 key: value
之间通过 ----
进行分隔。
通过 Yaml 文件创建
创建 configmap-demo.yaml
内容如下:
通过 kubectl apply
命令应用这个文件。
得到的结果跟通过命令行方式创建的 ConfigMap 没什么两样。
使用示例
知道了如何创建 ConfigMap ,我们再来看下如何使用。
有两种方式可以使用创建好的 ConfigMap ,一种是通过环境变量将 ConfigMap 注入到容器内部,另一种是通过卷挂载的方式直接将 ConfigMap 以文件形式挂载到容器。
通过环境变量方式引用
创建 use-configmap-env-demo.yaml
内容如下:
这里创建一个名为 use-configmap-env
的 Pod,Pod 的容器分别用两种方式引用 ConfigMap 的内容。
指定 spec.containers.env
可以为容器引用一个 ConfigMap 的 key: value
对,valueFrom.configMapKeyRef
表明我们要引用 ConfigMap ,ConfigMap 的名称为 c2
,引用的 key
为 foo
。
指定 spec.containers.envFrom
则可以一次将 ConfigMap 中的所有 key: value
传递给容器,只需要通过 configMapRef.name
指定 ConfigMap 的名称即可。prefix
可以给引用的 key
前面增加统一前缀。
容器启动命令为 echo $(FOO) $(CONFIG_bar)
,可以分别打印通过 env
和 envFrom
两种方式引用的 ConfigMap 的内容。
实验结果表明,容器内部可以通过环境变量的方式引用到 ConfigMap 的内容。
通过卷挂载方式引用
创建 use-configmap-volume-demo.yaml
内容如下:
这里创建一个名为 use-configmap-volume
的 Pod,通过 spec.containers.volumeMounts
指定容器挂载,name
指定挂载的卷名,mountPath
指定容器内部挂载路径(也就是将 ConfigMap 挂载到容器内部的指定目录下),spec.volumes
声明一个卷,configMap.name
表明了这个卷要引用的 ConfigMap 名称。
可以通过如下命令创建 Pod 并验证容器内部能否引用到 ConfigMap。
创建 Pod 后,可以通过 kubectl exec
命令进入容器内部,查看容器 /usr/share/tmp/
目录,会有两个以 ConfigMap 中 key
为名称的文本文件(foo
、bar
),文件内容则为 key
所对应的 value
内容。
以上我们演示了两种方式将 ConfigMap 的内容注入到容器内部,容器内部的应用可以分别通过读取环境变量、文件内容的方式使用配置信息。
Secret
熟悉了 ConfigMap 的用法,接下来看下 Secret 的使用。
其实 Secret 同 ConfigMap 非常类似,只不过它会对存储的数据进行 base64 编码,Secret 卷用来给 Pod 传递敏感信息,例如密码、SSH 密钥等。
创建示例
通过命令行创建
Secret 同样可以通过 --from-literal
参数来指定 key: value
,不过这里演示另一种方式,通过 --form-file
参数直接从文件加载配置,文件名即为 key
,文件内容作为 value
。
foo.txt
内容如下:
查看创建出来的 Secret,与 ConfigMap 不同的是,创建 Secret 需要指明类型,以上命令通过指定 generic
参数来创建类型为 Opaque
的 Secret ,这也是 Secret 默认类型(Secret 支持的类型可以在官方文档查看,不过初期学习阶段你完全可以不必关心,只使用默认类型即可,因为只通过默认类型也能够实现其他几种类型的功能)。
可以发现,与 ConfigMap 不同,Secret 中的数据的 value
是不会直接展示出来的,仅展示了 value
的字节大小,这也是 Secret 名称的含义,为了保存密文。
通过 Yaml 文件创建
创建 secret-demo.yaml
内容如下:
通过 kubectl apply
命令应用这个文件。
同样能够正确创建出 Secret 资源,通过 Yaml 文件创建 Secret 时,指定的 data
内容必须经过 base64
编码,如我们指定的 user
和 password
都是编码后的结果。
如果觉得麻烦,也可以使用原始字符串方式,如下:
以上两种方式等价,更推荐使用 base64
编码的方式。
使用示例
同 ConfigMap 使用方式一样,我们也可以通过环境变量或卷挂载的方式来使用 Secret。
这了演示通过卷挂载方式引用 Secret ,首先创建 use-secret-volume-demo.yaml
内容如下:
这里创建一个名为 use-secret-volume-demo
的 Pod,Pod 的容器通过卷挂载方式引用 Secret 的内容。
可以发现被挂载到容器内部以后,Secret 的内容将变成明文存储。容器内部应用可以同使用 ConfigMap 一样来使用 Secret。
由此可见,无论是 ConfigMap 还是 Secret,都可以用来存储配置信息,可以通过 ConfigMap 来存放普通配置,通过 Secret 来存放敏感配置。
值得一提的是,使用环境变量方式引用 ConfigMap 或 Secret,当 ConfigMap 或 Secret 内容变更时,容器内部引用的内容不会自动更新;使用卷挂载方式引用 ConfigMap 或 Secret,当 ConfigMap 或 Secret 内容变更时,容器内部引用的内容会自动更新。如果容器内部应用支持配置文件热加载,那么通过卷挂载对的方式引用 ConfigMap 或 Secret 内容将是推荐方式。
DownwardAPI
DownwardAPI 可以将 Pod 对象自身的信息注入到 Pod 所管理的容器内部。
使用示例
创建 downwardapi-demo.yaml
内容如下:
使用如下:
不难发现,DownwardAPI 的使用方式同 ConfigMap 和 Secret 如出一辙,通过卷挂载方式挂载到容器内部以后,都是在容器挂载的目录下生成对应文件,用来存储 key: value。不同的是 DownwardAPI 不需要预先定义,可以直接使用,因为它能引用的内容已经都在当前 yaml 文件中定义好了。
小结
ConfigMap 、Secret 、DownwardAPI 这三种 Volume 存在的意义不是为了保存容器中的数据,而是为了给容器传递预先定义好的数据。
临时卷
接下来我们要关注的是临时卷,即临时存储。K8s 支持的临时存储中最常用的就是如下两种:
EmptyDir
HostPath
临时存储卷会遵从 Pod 的生命周期,与 Pod 一起创建和删除。
EmptyDir
先来看 EmptyDir 如何使用,EmptyDir 相当于使用 docker 时通过 --volume/-v
挂载时的隐式 Volume 形式,即不显式的声明在宿主机上的目录。K8s 会在宿主机上创建一个临时目录,被挂载到容器所声明的 mountPath
目录上。
使用示例
创建 emptydir-demo.yaml
内容如下:
这里创建一个名为 emptydir-nginx-pod
的 Pod,它包含两个容器 html-generator
和 nginx
,顾名思义,html-generator
用来不停的生成 html
文件,nginx
是一个 Web 服务,用来展示 html-generator
生成的 index.html
文件。
通过两个容器对的描述信息可以发现,html-generator
不停的将当前时间写入到 /usr/share/index.html
下,并将 /usr/share
目录挂载到名为 html
的卷中,而 nginx
容器则将 /usr/share/nginx/html
目录挂载到名为 html
的卷中,这样两个容器通过同一个卷 html
挂载到了一起。现在通过 kubectl apply
命令应用这个文件。
根据 nginx
容器内部 curl 127.0.0.1
命令输出结果可以发现,nginx
容器 /usr/share/nginx/html/indedx.html
文件内容即为 html-generator
容器 /usr/share/index.html
文件内容。
能够实现此效果的原理是,当我们声明卷类型为 emptyDir: {}
后,K8s 会自动在主机目录上创建一个临时目录,然后将 html-generator
容器 /usr/share/
目录和 nginx
容器 /usr/share/nginx/html/
同时挂载到这个临时目录上,这样两个容器的目录就能够同步数据了。
需要注意的是,容器崩溃并不会导致 Pod 被从节点上移除,因此容器崩溃期间 EmptyDir 卷中的数据是安全的。另外,emptyDir.medium
除了可以设成 {}
,还可以设成 Memory
表示内存挂载。
HostPath
HostPath 卷能将主机节点文件系统上的文件或目录挂载到指定的 Pod 中,与 EmptyDir 不同的是,当 Pod 删除时,与之绑定的 HostPath 并不会随之删除,如果新创建一个 Pod 并且挂载到上一个 Pod 使用过的 HostPath,原 HostPath 中的内容仍然存在。但这仅限于新的 Pod 和已经删除的 Pod 被调度到同一节点上,所以严格来讲 HostPath 仍然属于临时存储。
使用示例
HostPath 卷的一个典型应用是将主机节点上的时区通过卷挂载的方式注入到容器内部,这样能够保证启动的容器和主机节点时间同步。
创建 hostpath-demo.yaml
内容如下:
要实现时间同步,只需要将主机目录 /usr/share/zoneinfo/Asia/Shanghai
通过卷挂载的方式挂载到容器内部的 /etc/localtime
目录即可。通过 kubectl apply
命令应用这个文件,然后进入 Pod 容器内部使用 date
命令查看容器当前时间。
输出结果为 Sun Mar 13 17:00:22 CST 2022
,其中 CST
代表了上海时区,也就是主机节点的时区,如果不通过卷挂载的方式将主机时区挂载到容器内部,容器默认时区为 UTC
时区。
小结
本节介绍了 K8s 临时存储方案以及应用,EmptyDir 适用范围较少,可以当作临时缓存或者耗时任务检查点等。
绝大多数 Pod 应该忽略主机节点,不应该访问节点上的文件系统,有时候 DaemonSet 可能需要访问主机节点的文件系统,HostPath 可以用来同步主机节点时区到容器,其他情况下使用较少,HostPath 的最佳实践就是尽量不使用 HostPath。
持久卷
临时卷的生命周期与 Pod 相同,当 Pod 被删除时,K8s 会自动删除 Pod 挂载的临时卷。而当我们的 Pod 中应用需要将数据保存到磁盘,且即使 Pod 被调度到其他节点数据也应该存在时,我们就需要一个真正的持久化存储了。
K8s 支持的持久卷类型非常多,这里列出了 v1.24
版本支持的所有卷:
awsElasticBlockStore
- AWS 弹性块存储(EBS)azureDisk
- Azure DiskazureFile
- Azure Filecephfs
- CephFS volumecsi
- 容器存储接口 (CSI)fc
- Fibre Channel (FC) 存储gcePersistentDisk
- GCE 持久化盘glusterfs
- Glusterfs 卷iscsi
- iSCSI (SCSI over IP) 存储local
- 节点上挂载的本地存储设备nfs
- 网络文件系统 (NFS) 存储portworxVolume
- Portworx 卷rbd
- Rados 块设备 (RBD) 卷vsphereVolume
- vSphere VMDK 卷...
看到这么多持久卷类型不必恐慌,有很多类型我也是第一次见,K8s 针对持久卷有一套独有的思想,旨在让开发者不必关心这背后的持久化存储类型,在 K8s 中,开发者无论使用哪种持久卷,其用法都是一致的。
K8s 持久卷设计架构如下:
Node1
和 Node2
分别代表两个工作节点,当我们在工作节点创建 Pod 时,可以通过 spec.containers.volumeMounts
来指定容器挂载目录,通过 spec.volumes
来指定挂载卷,之前我们用这个挂载卷挂载了配置信息和临时卷,这里指定挂载持久卷可以采用同样的方式,图中每个 volumes
指向的是下方存储集群中不同的存储类型,K8s 完全支持这样做。为了保证高可用,我们通常会搭建一个存储集群,而存储集群内部可以使用任何 K8s 支持的持久化存储,如上图的 NFS
、CephFS
、CephRBD
。
存储集群
关于存储集群,因为我们通过 Pod 来操作存储,而 Pod 都会部署在 Node 中,所以存储集群最好跟 Node 集群搭建在同一内网,这样速度更快。
使用 NFS
这里我们使用 NFS 存储来演示 K8s 对持久卷的支持(NFS 测试环境搭建过程可以参考文章结尾的附录部分),创建 nfs-demo.yaml
内容如下:
持久化挂载方式与临时卷大同小异,我们这里同样使用一个 Nginx 服务来进行测试,将容器 index.html
所在目录 /usr/share/nginx/html/
挂载到 NFS 服务的 /nfs/data/nginx
目录下,在 spec.volumes
配置项中指定 NFS 服务,server
指明了 NFS 服务器地址,path
指明 NFS 服务器中挂载的路径,这个路径必须是已经存在的路径。通过 kubectl apply
命令应用这个文件。
接下来我们查看这个 Pod 使用 NFS 存储的结果:
NFS 节点
在 NFS 节点中我们准备一个 index.html
文件,其内容为 hello nfs
。
Pod
使用 curl
命令直接访问 Pod 的 IP
地址,即可返回 Nginx 服务的 index.html
内容,结果输出为 hello nfs
,证明 NFS 持久卷挂载成功。
可以登入 Pod 容器,通过 df -Th
命令查看容器目录挂载信息,可以发现,容器的 /usr/share/nginx/html/
目录被挂载到 NFS 服务的 /nfs/data/nginx
目录。
现在,当我们执行 kubectl delete -f nfs-demo.yaml
删除 pod 后,NFS 服务器上数据盘中的数据依然存在,这就是持久卷。
持久卷使用痛点
虽然我们通过使用持久卷,解决了临时卷数据易丢失的问题,但目前持久卷的使用方式,还是有一些不足之处:
Pod 开发人员可能对存储不够了解,却要对接多种存储
安全问题,有些存储可能需要账号密码,这些信息不应该暴露给 Pod
为了解决这些不足,K8s 又针对持久化存储抽象出了三种资源 PV、PVC、StorageClass。
PV(PersistentVolume)、PVC(PersistentVolumeClaim)、StorageClass
三种资源定义如下:
PV 描述的是持久化存储数据卷
PVC 描述的是 Pod 想要使用的持久化存储属性,既存储卷申明
StorageClass 作用是根据 PVC 的描述,申请创建对应的 PV
PV 和 PVC 的概念可以对应编程语言中的面向对象思想,PVC 是接口,PV 是具体实现。
有了这三种资源类型后,Pod 有两种方式来使用持久卷,分别是静态供应和动态供应。
静态供应
我们先来学习静态供应,静态供应不涉及 StorageClass,只涉及到 PVC 和 PV。
其使用流程图如下:
使用静态供应时,Pod 不再直接绑定持久存储,而是会绑定到 PVC 上,然后再由 PVC 跟 PV 进行绑定。这样就实现了 Pod 中的容器可以使用由 PV 真正去申请的持久化存储。
使用示例
创建 pv-demo.yaml
内容如下:
以上 Yaml
文件定义了两个 PV、一个 PVC 和一个 Pod。
两个 PV 申请容量分别为 1Gi
、100m
,通过 spec.capacity.storage
指定,并且他们通过 spec.nfs
指定了 NFS 存储服务的地址和路径。PVC 则申请 500m
大小的存储。最后在 Pod 的定义中,spec.volumes
绑定了这个名为 pvc-500m
的 PVC,而没有直接去绑定 NFS 存储服务。
通过 kubectl apply
命令应用这个文件:
创建好这些资源后,来观察下结果如何:
首先通过 kubectl get pod
命令查看新创建的 Pod,通过 curl
命令访问 Pod 的 IP
地址,可以得到 hello nginx1
的响应结果。
通过 kubectl get pvc
查看创建的 PVC,STATUS
字段标识这个 PVC 已经处于绑定(Bound
)状态,也就是与 PV 进行了绑定,CAPACITY
字段标识这个 PVC 绑定到了 1Gi
的 PV 上,尽管我们申请的 PVC 大小是 500m
,但由于我们创建的两个 PV 大小分别是 1Gi
和 100m
,K8s 会帮我们选择满足条件的最优解,因为没有刚好等于 500m
大小的 PV 存在,而 100m
又不满足,所以 PVC 会自动与 1Gi
大小的 PV 进行绑定。
通过 kubectl get pv
来查询创建的 PV 资源,可以发现 1Gi
大小的 PV STATUS
字段为 Bound
状态,CLAIM
有值,它标识的就是与之绑定的 PVC 的名字。
现在我们来登录 NFS 服务器,确认 NFS 存储上不同持久卷(PV)挂载的目录下文件内容。
可以看到,/nfs/data/nginx1
目录下的 index.html
内容为 hello nginx1
,即为上面通过 curl
命令访问 Pod 服务的响应结果。
总结下整个持久卷使用流程:首先创建一个 Pod,这个 Pod 的 spec.volumes
中绑定了 PVC,而 PVC 只是一个存储申明,代表我们的 Pod 需要什么样的持久化存储,它并没有标明 NFS 服务地址,也没有明确要和哪个 PV 进行绑定,我们只需要创建出这个 PVC 即可,接着我们创建了两个 PV,在 PV 中也没有明确指出要与哪个 PVC 进行绑定,只需要指出它的大小和 NFS 存储服务地址即可,此时 K8s 会自动帮我们进行 PVC 和 PV 的绑定,这样 Pod 就和 PV 产生了联系,也就可以访问持久化存储了,这就是静态供应持久卷的使用流程。
细心的你可能已经发现,前文中我提到静态供应不涉及 StorageClass,但是我在定义 PVC 和 PV 的 Yaml
文件时,还是都为其指定了 spec.storageClassName
值为 nfs-storage
,因为这是一个比较好的实践,便于管理,只有具有相同 StorageClass 的 PVC 和 PV 才可以进行绑定。
无论是 PVC 还是 PV,都有一个 spec.accessModes
字段,这个字段标识了持久卷的访问模式,K8s 持久化支持四中访问模式:
RWO - ReadWriteOnce —— 卷可以被一个节点以读写方式挂载
ROX - ReadOnlyMany —— 卷可以被多个节点以只读方式挂载
RWX - ReadWriteMany —— 卷可以被多个节点以读写方式挂载
RWOP - ReadWriteOncePod —— 卷可以被单个 Pod 以读写方式挂载( K8s
1.22
以上版本)
只有具有相同读写模式的 PVC 和 PV 才可以进行绑定。
现在我们来继续实验,通过命令 kubectl delete pod pv-nginx-pod
删除 Pod,再次查看 PVC 和 PV 状态。
说明 Pod 删除后,PVC 和 PV 还在。Pod 删除并不影响 PVC 的存在,而当 PVC 删除时 PV 是否删除,则可以通过设置回收策略来决定。
PV 回收策略(pv.spec.persistentVolumeReclaimPolicy
)有三种:
Retain —— 手动回收,也就是说删除 PVC 后,PV 依然存在,需要管理员手动进行删除
Recycle —— 基本擦除 (相当于 rm -rf /*)(新版已废弃不建议使用,建议使用动态供应)
Delete —— 删除 PV,即级联删除
现在通过命令 kubectl delete pvc pvc-500m
删除 PVC,查看 PV 状态。
可以看到 PV 依然存在,其 STATUS
已经变成 Released
,此状态下的 PV 无法再次绑定到 PVC,需要由管理员手动删除,这是由回收策略决定的。
注意:绑定了 Pod 的 PVC,如果 Pod 正在运行中,PVC 无法删除。
静态供应的不足
我们一起体验了静态供应的流程,虽然比直接在 Pod 中绑定 NFS 服务更加清晰,但静态供应依然存在不足。
首先会造成资源浪费,如上面示例中,PVC 申请
500m
,而没有刚好等于500m
的 PV 存在,这 K8s 会将1Gi
的 PV 与之绑定还有一个致命的问题,如果当前没有满足条件的 PV 存在,则这 PVC 一直无法绑定到 PV 处于
Pending
状态,Pod 也将无法启动,所以就需要管理员提前创建好大量 PV 来等待新创建的 PVC 与之绑定,或者管理员时刻监控是否有满足 PVC 的 PV 存在,如果不存在则马上进行创建,这显然是无法接受的
动态供应
介于静态供应存在不足,K8s 推出一种更加方便的持久卷使用方式,即动态供应。
动态供应核心组件上面已经见过,就是 StorageClass——存储类。
StorageClass 主要作用有两个:
一是资源分组,我们上面使用静态供应时指定 StorageClass 的目前就是对资源进行分组,便于管理
二是 StorageClass 能够帮我们根据 PVC 请求的资源,自动创建出新的 PV,这个功能是 StorageClass 中
provisioner
存储插件帮我们来做的。
其使用流程图如下:
相较于静态供应,动态供应在 PVC 和 PV 之间增加了存储类,这次 PV 并不需要提前创建好,只要我们申请了 PVC 并且绑定了有 provisioner
功能的 StorageClass,StorageClass 会帮我们自动创建 PV 并与 PVC 进行绑定。
我们可以根据提供的持久化存储类型,分别创建对应的 StorageClass,比如:
nfs-storage
cephfs-storage
rbd-storage
也可以设置一个默认 StorageClass, 通过在创建 StorageClass 资源时指定对应的 annotations
实现:
当创建 PVC 时不指定 spec.storageClassName
,这个 PVC 就会使用默认 StorageClass。
使用示例
这里我们仍然使用 NFS 来作为持久化存储,首先我们需要有一个能够支持自动创建 PV 的 provisioner
,可以在 GitHub 中找到一些开源的实现,我这里使用了 nfs-subdir-external-provisioner
这个存储插件,具体安装方法也非常简单,只需要通过 kubectl apply
命令应用它提供的几个 Yaml
文件即可,你可以点击项目链接查看文档。当存储插件安装完成,我们可以创建如下 StorageClass:
这个 StorageClass 指定了 provisioner
为我们安装好的 K8s-sigs.io/nfs-subdir-external-provisioner
,指定了 provisioner
的 StorageClass 就有了自动创建 PV 的能力。 provisioner
其实本质上也是一个 Pod,可以通过 kubectl get pod
来查看,是这个 Pod 能够自动创建 PV。
现在 provisioner
和 StorageClass 都已经创建好了,接下来就可以进行动态供应的实验了,创建 nfs-provisioner-demo.yaml
内容如下:
这里我们只定义了一个 PVC 和一个 Pod,并没有定义 PV,PVC 的 spec.storageClassName
指定为上面创建好的 StorageClass nfs-storage
,现在只需要通过 kubectl apply
命令来创建出 PVC 和 Pod 即可:
现在可以查看 PV、PVC 和 Pod,发现 PV 也已经被自动创建出来了,并且它们之间实现了绑定关系。
现在登录 NFS 服务,给远程挂载的卷写入 hello nfs
数据。
在 K8s 侧,就可以通过 curl
命令验证这次挂载的正确性了。
此时如果你通过 kubectl delete -f nfs-provisioner-demo.yaml
删除 Pod 和 PVC,PV 也会跟着删除,因为 PV 的删除策略是 Delete ,不过你会发现,NFS 卷中的数据还在,只不过被归档成了以 archived
开头的目录,这个功能是 K8s-sigs.io/nfs-subdir-external-provisioner
这个存储插件帮我们实现的,你可以回到上面查看在定义 StorageClass 是指定的 parameters.archiveOnDelete
属性,这就是存储插件的强大。
小结
通过定义指定了 provisioner
的 StorageClass,我们不仅可以实现 PV 的自动化创建,甚至可以实现数据删除时自动归档的功能,这完全依附于 K8s 动态供应存储设计的精妙。通过以上的实验,我们可以得出结论:动态供应是持久化存储最佳实践。
附录
NFS 实验环境搭建
NFS 全称 Network File System,是一种分布式存储,它能够通过局域网实现不同主机间目录共享。
架构图
一个 Server 节点和两个 Client 节点。
NFS 在 Centos 系统中的搭建过程:
Server 节点:
Client 节点:
希望此文能对你有所帮助。
联系我
微信:jianghushinian
博客地址:https://jianghushinian.cn/
参考
图书《Kubernetes in Action 中文版》
kubernetes 存储:https://kubernetes.io/zh-cn/docs/concepts/storage/
kubernetes 配置:https://kubernetes.io/zh-cn/docs/concepts/configuration/
NFS 存储插件:https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
版权声明: 本文为 InfoQ 作者【江湖十年】的原创文章。
原文链接:【http://xie.infoq.cn/article/0216d332203134710ff55ac64】。文章转载请联系作者。
评论