k8s存储卷

已于 2023-02-11 19:41:51 修改
阅读量2.5k 收藏 6
点赞数
文章标签： kubernetes
于 2022-08-30 14:04:42 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43266367/article/details/126471777
版权

文章目录

简介

存储卷是定义在Pod之上的可被其内部所有容器挂载是使用的共享目录，该目录实际上是宿主机或外部存储设备之上的存储空间，可以被Pod内的多个容器挂载使用。存储卷独立与Pod的生命周期，因此它存储的数据可以在容器重启或重建后继续使用。

目前k8s支持的存储卷可以大致分为一下几类，它们各自有着不同的实现插件：

  1. 临时存储卷：emptyDir
  2. 本地存储卷：hostPath
  3. 网络存储卷：nfs、cinder、rbd、iscsi等
  4. 特殊存储卷：configmap、secret
  5. 扩展支持第三方存储的存储接口：CSI

通常k8s内置的存储卷插件可以归类为In-Tree类型，它们通k8s源码一起发布迭代，而由存储厂商借助CSI接口扩展的独立于k8s源码的插件统称为Out-of-Tree类型，集群管理员可以根据需要创建自定义的扩展插件，CSI是比较常用的实现方式。目前k8s已经开始逐步将In-Tree类型的存储卷插件迁移到CSI，所以建议在新环境中使用CSI。

emptyDir存储卷

emptyDir存储卷可以看作是Pod上的一个临时目录，其生命周期和Pod相同，Pod创建时被创建，Pod删除时被删除，通常用于数据缓存和临时存储。
emptyDir存储卷定义在Pod资源的spec.volumes.emptyDir字段，可嵌套使用的字段有两个：

  • medium：用于指定emptyDir存储卷使用的存储介质，可用值为default和Memory，默认是default表示使用节点的默认存储介质(磁盘)；Memory表示使用基于内存的临时文件系统tmpfs，可用空间受限于内存，但性能很好，一般用于缓存
  • sizeLimit ：当前存储卷的空间限额，默认为nil，不限制
apiVersion: apps/v1
kind: Deployment
metadata:
  name: volume-emptydir-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: volume-emptydir-demo
  template:
    metadata:
      labels:
        app: volume-emptydir-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        volumeMounts:
        - name: cache-volume
          mountPath: /cache
      volumes:
      - name: cache-volume
        emptyDir:
          medium: Memory
          sizeLimit: 128Mi

进入Pod验证
在这里插入图片描述
emptyDir其实就是node节点上的一个目录，它存放在 /var/lib/kubelet/pods/<pod-id>/volumes/kubernetes.io~empty-dir/ 下
在这里插入图片描述

hostPath存储卷

hostPath是将工作节点上的目录或文件关联到Pod上的一种卷类型，类似于Docker的bind mount，hostPath卷的生命周期和工作节点相同。hostPath存储卷在Pod需要访问节点上的文件时很有用。

hostPath存储卷定义在Pod资源的spec.volumes.hostPathz字段，可嵌套使用的字段有两个：

  • path <string>：用于指定工作节点上的目录路径
  • type <string>：用于指定工作节点之上的存储类型

关于type字段，目前支持的值有下面这些：

  • DirectoryOrCreate：指定的目录不存在时，自动将其创建为0755权限的空目录，属主和属组都为kubelet
  • Directory：事先必须存在的目录
  • FileOrCreate：指定的不存在时，自动将其创建为0644权限的空文件，属主和属组都为kubelet
  • File：事先必须存在的文件
  • Socket：事先必须存在的Socket文件
  • CharDevice：事先必须存在的字符设备路径
  • BlockDevice：事先必须存在的文件设备路径
  • “”：空字符串，默认值，用于向后兼容，在关联hostPath卷之前不进行任何检查
apiVersion: apps/v1
kind: Deployment
metadata:
  name: volume-hostpath-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: volume-hostpath-demo
  template:
    metadata:
      labels:
        app: volume-hostpath-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        volumeMounts:
        - name: cache-volume
          mountPath: /cache
      volumes:
      - name: cache-volume
        hostPath:
          path: /data/kubernetes

进入Pod创建一个文件
在这里插入图片描述
在主机上验证文件是否存在
在这里插入图片描述

网络存储卷

k8s内置了多种类型的网络存储插件，它们支持的存储服务包括传统的NAS或SAS设备，以及分布式存储、云存储等。网络存储卷的生命周期可以超出工作节点的生命周期，存储卷的回收由集群管理员手动处理，存储的数据可以被Pod重复使用。

下面以NFS存储卷为例进行演示，其它网络存储卷的使用可以参考：https://kubernetes.io/docs/concepts/storage/volumes/

NFS存储卷

nfs存储卷可以将现有的nfs-server上的存储空间挂载到Pod中使用。当删除Pod时，nfs存储卷的内容会被保留，卷仅是被卸载而不是删除。而且NFS是文件系统级共享服务，支持被多个Pod挂载使用。定义NFS存储卷时支持嵌套使用3个字段：

  • server：NFS Server的地址或域名
  • path：NFS Server共享的目录
  • readOnly：是否以只读方式挂载，默认false

首先安装一下nfs-server，地址是192.168.122.1

apt -y install nfs-server
mkdir -p /data/k8s

vim /etc/exports
/data/k8s *(rw,no_root_squash,subtree_check)

exportfs -r
showmount -e 192.168.122.1

所有k8s工作节点都要安装nfs客户端

apt -y install nfs-common

nfs存储卷示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: volume-nfs-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: volume-nfs-demo
  template:
    metadata:
      labels:
        app: volume-nfs-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: nfs-volume
          mountPath: /usr/share/nginx/html/mysite
      volumes:
      - name: nfs-volume
        nfs:
         server: 192.168.122.1
         path: /data/k8s

等Pod创建之后，在nfs共享目录写入一个文件，然后访问nginx验证
在这里插入图片描述
在这里插入图片描述

PV和PVC

PV和PVC介绍

PV是由k8s集群管理员在全局级别配置的存储卷，它通过支持的存储卷插件及给定的配置参数关联到指定存储系统的存储空间，这个的存储空间可能是ceph rbd-image、nfs共享的目录和cephfs文件系统等，也就是说PV的数据最终是保存在后端的存储系统上的。PV将存储系统上的存储空间抽象为集群级别的API资源，由管理员负责创建维护。

将PV提供的存储空间用于Pod对象存储卷时，用户需要先在namespace中创建PVC资源声明需要的存储空间大小和访问模式等属性，接下来PV控制器会选择合适的PV与PVC进行绑定。随后，在Pod资源中通过persistenVolumeCliam卷插件指定要使用的PVC对象就可以使用这个PVC绑定的PV的存储空间。

总结来说，PV和PVC就是在用户和存储系统之间添加的一个中间层，管理员事先定义好PV，用户通过PVC声明要使用的存储特性来绑定符合条件的最佳PV，从而实现了用户和存储系统之间的解耦，用户不需要了解存储系统的具体使用方式，只需要定义PVC就可以。

PV生命周期

PV生命周期中存在几个状态，创建后未正确关联到存储设备的PV处于Pending状态，直到成功关联后转为Available状态。之后如果该PV被PVC绑定后转为Bound状态，直到相应的PVC被删除后会自动解除绑定，PV的状态转换为Released，随后PV的去向将由其回收策略决定。目前PV支持的回收策略有如下3种：

  1. Delete：删除PVC后，删除其所绑定的PV和PV关联的存储设备
  2. Retain：默认策略，删除PVC后将保留其所绑定的PV和存储的数据，但会将PV至于Released状态，此时PV不能被其它PVC绑定使用，需要管理员执行后续回收操作
  3. Recycle（已废弃）：删除PVC时其所绑定的PV上存储的数据会被清空，而后PV转为Available状态，可以再次被其它PVC绑定使用，此策略已废弃

相对应的，PVC在创建之后也处于Pending状态，成功绑定PV后转为Bound状态，被删除后处于Deleted状态

静态PV

PV资源的spec字段可以嵌套使用下面这些字段：

  • <volume-plugin> <Object>：具体存储卷插件配置，用来指定PV关联的存储设备，和Pod直接通过存储卷插件定义卷的参数一致
  • accessModes <[]string>：指定PV的访问模式，目前支持
  • capacity <map[string]string>：指定PV的容量
  • mountOptions <[]string>：挂载选项
  • nodeAffinity <Object>：节点亲和性，用于限制能访问该PV的节点
  • persistentVolumeReclaimPolicy <string>：当前PV的回收策略
  • volumeMode <string>：该PV的卷模型，用于指定此存储卷是被格式化为文件系统使用还是直接作为裸格式块设备使用，默认为Filesystem
  • storageClassName <string>：此PV所属的存储类名称，默认为空，不属于任何存储类

关于PV的访问模式，目前支持下面4种模式：

  1. ReadOnlyMany：简写为ROX，卷可以被多个节点以只读方式挂载
  2. ReadWriteOnce：简写为RWO，卷只能被一个节点以读写方式挂载，但ReadWriteOnce 访问模式也允许运行在同一节点上的多个 Pod 访问卷
  3. ReadWriteMany：简写为RWX，卷可以被多个节点以读写方式挂载
  4. ReadWriteOncePod：简写为RWOP，卷只能以读写方式被单个Pod挂载使用

关于不同的存储系统支持的访问模式，可以查询：https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/#access-modes

下面以NFS PV为例演示：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-demo
spec:
  nfs:
    server: 192.168.122.1
    path: /data/k8s
  accessModes: ["ReadWriteMany"]
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem

查看PV状态
在这里插入图片描述

PVC

PVC隶属于名称空间级别，定义PVC时可以通过访问模式、标签选择器、PV名称和存储资源需求限制多个匹配方式来筛选PV。其中访问模式和资源需求限制是重要的筛选标准。PVC的spec字段支持嵌套使用下面这些字段：

  • accessModes <[]string>：PVC的访问模式，可用值和PV的访问模式一致
  • resources <Object>：声明PVC要使用存储空间的需求和限制
  • dataSource <Object>：用于从指定的数据源恢复该PVC卷，目前支持从卷快照或已存在的PVC恢复
  • selector <Object>：标签选择器，用于筛选PV
  • storageClassName <string>：该PVC隶属的存储类
  • volumeMode <string>：卷模型，用于指定此存储卷是被格式化为文件系统使用还是直接使用裸格式的块设备；默认为Filesystem
  • volumeName <string>：直接指定要绑定的PV资源名称
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
  namespace: default
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 200Mi
    limits:
      storage: 1Gi
  volumeMode: Filesystem

查看PVC状态验证
在这里插入图片描述

PVC使用

PVC只能被同名称空间下的Pod使用，Pod通过spec.volumes.persistentVolumeClaim引用PVC作为存储卷，可以嵌套使用下面两个字段：

  • claimName：指定要引用的PVC的名称
  • readOnly：是否以只读模式挂载，默认False
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-pvc-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nfs-pvc-demo
  template:
    metadata:
      labels:
        app: nfs-pvc-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: nfs-pvc-volume
          mountPath: /usr/share/nginx/html/static
      volumes:
      - name: nfs-pvc-volume
        persistentVolumeClaim:
          claimName: nfs-pvc

访问Pod测试
在这里插入图片描述
在这里插入图片描述

动态PV

尽管PV和PVC简化了用户使用使用存储系统的难度，管理员负责创建PV，用户只需要定义PVC即可。但这种静态PV供给方式也存在一些问题：

  1. 管理员无法预测用户的存储需求，很容易会导致PVC无法匹配到合适的PV被挂起，直到管理员介入解决
  2. 那些能匹配到PV的PVC可能存在存储空间浪费现象，比如一个需求5G的PVC绑定到一个个10G的PV

更好的解决方案是一种称为动态预配、按需创建PV的机制。集群管理员需要借助StorageClass资源定义一到多个“PV模板”，并在模板中定义好连接到存储系统需要的配置参数。创建PVC时，需要为其指定所属的存储类，而后PV控制器会自动连接到相应存储类上定义的目标存储系统去创建符合PVC需求的PV，并完成PVC和PV的绑定。

StorageClass

存储类(StorageClass)是k8s上API资源类型之一。存储类通常由集群管理员按需创建，用于区分存储类型，比如按存储性能高低、备份策略创建创建不同的存储类。另外，存储类也是PVC筛选PV的条件之一，指定了存储类的PVC只能从其隶属的存储类下筛选PV。但存储类最重要的功能是对PV动态预配的支持。

StorageClass没有spec字段，除了apiVersion、kind和metadata之外，可用的字段如下：

  • allowVolumeExpansion <bool>：是否支持存储卷空间扩展功能
  • provisioner <string>：必选字段用于指定存储服务方，存储类要基于该字段确定要使用的存储插件，以便连接到目标存储系统
  • parameters <map[string]string>：连接到目标存储系统时需要用到的参数
  • reclaimPolicy <string>：当前存储类动态创建的PV的回收策略，默认为Delete
  • mountOptions <[]string>：当前存储类动态创建的PV的默认挂载选项

并不是所有的k8s内置存储插件都支持基于存储类实现PV动态预配，关于支持的存储插件可以查询：https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#provisioner

NFS StorageClass

下面以nfs为例，由于内置的nfs存储插件不支持PV动态预配，所以要借助第三方项目实现：https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

下载相关的部署文件

mkdir ./nfs-provisioner && cd ./nfs-provisioner
wget https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/archive/refs/tags/v4.0.2.zip
unzip v4.0.2.zip
cd nfs-subdir-external-provisioner-4.0.2/deploy/

修改部署文件，与环境匹配

kubectl create ns storage
NAMESPACE=storage
sed -i'' "s/namespace:.*/namespace: $NAMESPACE/g" ./rbac.yaml ./deployment.yaml	#修改namespace值，将资源部署到storage namespace
vim deployment.yaml
###################
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: easzlab/nfs-subdir-external-provisioner:v4.0.1	#修改镜像为国内的镜像源
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 192.168.122.1	#修改为nfs-server的地址
            - name: NFS_PATH
              value: /data/k8s	#修改为nfs-server的共享目录路径
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.122.1	#修改为nfs-server的地址
            path: /data/k8s	#修改为nfs-server的共享目录路径

部署nfs-provisioner

kubectl apply -f rbac.yaml
kubectl apply -f deployment.yaml

查看Pod状态，验证nfs-provisoner已成功运行
在这里插入图片描述

创建StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  archiveOnDelete: "false"
reclaimPolicy: Retain

查看StorageClass资源
在这里插入图片描述

PV动态预配

动态PV预配功能的使用有两个前置条件：支持动态PV创建功能的卷插件，以及一个使用了对应于该存储卷插件的后端存储系统的StorageClass资源。

还是以nfs为例，先定义PVC：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc-dynamic
  namespace: default
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 500Mi
    limits:
      storage: 1Gi
  volumeMode: Filesystem
  storageClassName: managed-nfs-storage	#指定StorageClass为上一步创建的StorageClass

PVC创建后，PV会被自动创建并绑定到PVC
在这里插入图片描述
在nfs-server上也会为PV自动创建一个目录
在这里插入图片描述
配置Pod使用PVC测试

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-pvc-dynamic-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nfs-pvc-dynamic-demo
  template:
    metadata:
      labels:
        app: nfs-pvc-dynamic-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: nfs-pvc-dynamic-volume
          mountPath: /usr/share/nginx/html/static
      volumes:
      - name: nfs-pvc-dynamic-volume
        persistentVolumeClaim:
          claimName: nfs-pvc-dynamic

进入Pod写入测试数据，然后访问测试
在这里插入图片描述
在这里插入图片描述

林凡修
关注
【K8S系列】深入解析K8S存储
颜淡慕潇
06-25 2万+
在 Kubernetes 中，存储具有非常广泛的应用场景。可以根据实际需求选择适合自己的存储方案，以便更好地管理容器化应用程序中的数据和资源。 本文会从以下三个方面，带你了解k8s存储：1.k8s存储类型；2.存储使用场景；3.存储使用案例
【kubernetes】关于k8s集群的存储卷
liu_xueyin的博客
03-05 1485
metadata: #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespacename:spec#查看pv定义的规格spec:nfs:（定义存储类型）path:（定义挂载卷路径）server:（定义服务器名称）accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）- ReadWriteOnce #（RWO）卷可以被一个节点以读写方式挂载。
k8s的存储卷
m0_70766460的博客
01-10 1247
1、Provisioning（配置）------pvc请求request------检索（找一个合适的pv）------pvc和pv（binding绑定）------使用------pod被删除------pv的releasing（释放）------recying（回收）即使容器被销毁，删除，重启，节点上的存储卷的数据依然存在，后续也可以继续使用。pod内的挂载点声明一个请求，pvc请求，pvc会找一个最合适的pv来作为pod的存储卷，pv和共享目录再一一映射，最终由nfs来提供最终的共享存储空间。
关于k8s集群的存储卷
2402_83805984的博客
08-08 1159
从节点中删除 Pod 时，emptyDir中的数据将被永久删除。
k8s中的存储
最新发布
2302_81167603的博客
10-11 749
k8s的存储
k8s 之存储卷
yaoxie1534的博客
11-04 962
每次使用存储要先创建pv, 再创建pvc，真累!所以我们可以实现使用存储的动态供给特性。静态存储需要用户申请PVC时保证容量和读写类型与预置PV的容量及读写类型完全匹配, 而动态存储则无需如此.管理员无需预先创建大量的PV作为存储资源Kubernetes从1.4版起引入了一个新的资源对象StorageClass，可用于将存储资源定义为具有显著特性的类（Class）而不是具体的PV。用户通过PVC直接向意向的类别发出申请，匹配由管理员事先创建的PV，或者由其按需为用户动态创建PV，这样就免去。
K8S存储卷
mac99776的博客
09-08 615
K8S存储卷 存储卷分为，临时卷和持久卷； 临时卷： 有时候有些应用程序需要额外的存储，比如，将不常用的数据转移到影响很小的存储中 emptyDir： 是最基础的Volume类型，用于存储临时数据的简单目录，当Pod被删除则emptyDir ConfigMap： 是Pod映射（文件或者目录）的一种方式，允许年将配置文件与镜像文件分离。常用于配置文件的 kubectl create configman 名称 --from -file=文件路径 持久卷 hostPath： 各个节点映射本地目录保持持久性，将no
K8s卷存储详解（一）
抽象空间的博客
07-25 1514
Pod是由容器构成的，我也知道，容器（如Docker）有个特点就是，容器删除后，在容器中产生的数据也会随之销毁。K8s会监控容器的运行状态，当有容器崩溃或停止时，K8s的Controller会删除这些容器，并重新创建新的容器。EmptyDir是在当 Pod 分派到某个Node节点上时创建的，它的初始内容为空，k8s自动分配一个目录，而无需指定宿主机上对应的目录文件。临时卷的生命周期与 Pod 的生命周期相同，与 Pod 一起创建和删除，当 Pod 不再存在时，Kubernetes 也会销毁临时卷。
【k8s】k8s存储卷 emptyDir、hostpath、nfs
sl963216757的博客
07-26 829
一、卷简介 卷官方文档 容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet将重新启动容器，容器中的文件将会丢失,因为容器会以干净的状态重建。其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。 Kubernetes 抽象出 Volume 对象来解决这两个问题。 Kubernetes 卷具有明确的生命周期,与包裹它的 Pod 相同。 因此，卷比 Pod中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 当然，
k8s存储卷-动态PV
wutong0824的博客
01-16 1122
SelfLink：API的资源对象之一，表示资源对象在集群当中自身的一个连结，self-Link是一个唯一的标识号，可以用于标识k8s集群当中的每个资源的对象。容器里使用的配置，在provisioner当中定义好环境变量，传给容器，storageclass的名称，NFS服务器的地址，NFS的目录。NFS的provisionner的客户端以pod的方式运行在集群当中，监听k8s集群当中PV的请求，然后动态的创建于NFS相关的PV。命名为 nfs-client-provisioner-clusterrole。
K8S存储卷详解：类型与使用指南
"本文主要介绍了K8S存储技术的基础知识，包括存储的分类以及K8S中的存储卷、数据卷类型、持久化存储等概念，旨在帮助读者理解K8S如何处理集群内的存储需求。" Kubernetes（简称K8s）作为一个强大的容器编排系统，...
k8s存储 卷（一）
热门推荐
天码行空的码的博客
07-17 1万+
一、可用的卷类型 1、emptyDir 用于存储临时数据的简单空目录 2、hostPath 用于将目录从工作节点的文件系统挂在到pod中 3、gitRepo 通过检出Git仓库的内容来初始化的卷 4、nfs 挂载到pod中的NFS共享卷 5、gcePersistentDisk (google高效能型存储磁盘卷)、awsEla...
k8s之存储卷
wyh20030130的博客
01-23 1242
1、Provisioning（配置）-------pvc请求request-------检索（找一个合适的pv）---------pvc和pv（binding绑定）--------使用-------pod被删除---------pv（releasing释放）--------recycling回收。容器和节点之间创建一个可以持久保存容器内文件的存储卷，即使容器被销毁，删除，重启，节点上的存储卷的数据依然存在，后续可以继续使用。好处就是集中，方便管理。hostPath：节点目录的存储卷，可以实现持久化存储。
kubernetes存储卷
ll945608651的博客
08-04 820
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在Pod中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题。Pod中的容器通过Pause容器共享Volume。
k8s中的存储卷
奇华资料的博客
01-24 239
Kubernetes支持诸多类型的卷。卷的核心是包含一些数据的一个目录。存储卷属于Pod，Pod的存储卷Pod内的容器能够共享使用。临时卷的生命周期与Pod相同，持久卷则有自己独立的生命周期。使用字段为Pod设置卷，在字段中声明卷在容器中的挂载位置。卷挂载在镜像内的指定路径上，卷不能挂载到其他卷之上，也不能与其他卷有硬链接。
【k8s】8、数据存储
努力充实，远方可期
06-20 830
第八章 数据存储 ​ 在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。 ​ Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容
【Kubernetes】关于k8s集群的存储卷
weixin_68840588的博客
08-16 602
k8s集群存储卷
【云原生】k8s之存储卷
zhangchang3的博客
07-07 1554
静态pod创建 动态pod创建
docker_存储卷
959
02-21 667
docker存储卷 文章目录docker存储卷1 COW机制2 什么是存储卷3 使用存储卷的好处4 为什么要用存储卷5 存储卷管理方式6 存储卷的分类7 容器数据管理8 在容器中使用数据卷9 数据卷容器10 利用数据卷容器迁移数据 1 COW机制 Docker镜像由多个只读层叠加而成，启动容器时，Docker会加载只读镜像层并在镜像栈顶部添加一个读写层。 如果运行中的容器修改了现有的一个已经存在的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值