volume_volumes - CSDN
精华内容
参与话题
  • Volume

    千次阅读 2018-05-22 14:50:42
    默认情况下容器的数据都是非持久化的,在容器消亡以后数据也跟着丢失,所以 Docker 提供了 Volume 机制以便将数据持久化存储。类似的,Kubernetes 提供了更强大的 Volume 机制和丰富的插件,解决了容器数据持久化和...

    概述


    什么是Valume

    默认情况下容器的数据都是非持久化的,在容器消亡以后数据也跟着丢失,所以 Docker 提供了 Volume 机制以便将数据持久化存储。类似的,Kubernetes 提供了更强大的 Volume 机制和丰富的插件,解决了容器数据持久化和容器间共享数据的问题。

    与 Docker 不同,Kubernetes Volume 的生命周期与 Pod 绑定。容器挂掉后 Kubelet 再次重启容器时,Volume 的数据依然还在,而 Pod 删除时,Volume 才会清理。数据是否丢失取决于具体的 Volume 类型,比如 emptyDir 的数据会丢失,而 PV 的数据则不会丢

    Volume类型

    目前,Kubernetes 支持以下 Volume 类型:
    emptyDir、hostPath、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs、iscsi、flocker、glusterfs、rbd、cephfs、gitRepo、secret、persistentVolumeClaim、downwardAPI、azureFileVolume、azureDisk、vsphereVolume、Quobyte、PortworxVolume、ScaleIO、FlexVolume、StorageOS、local

    用的比较多的是:emptyDir、hostPath、nfs、glusterfs

    本地数据卷


    emptyDir

    emptyDir表示空目录,会在宿主机上创建数据卷目录并挂在到容器中。

    创建emptyDir类型的数据卷

    下面通过yaml文件创建一个emptyDir类型的数据卷:

    apiVersion: v1
    kind: Pod
    metadata:
      name: redis-pod
    spec:
      containers:
      - image: redis
        name: redis
        volumeMounts:
        - mountPath: /cache
          name: cache-volume
      volumes:
      - name: cache-volume
        emptyDir: {}

    这里会创建一个叫redis-pod的pod,使用redis镜像,然后创建了一个emptyDir类型的volume,并挂载到容器的/cache。注意在yaml文件中volumes的定义和containers的定义在同一级。

    创建这个pod:

    kubectl create -f empty.yaml

    这里写图片描述

    查看数据卷

    进入到这个pod中,可以看到我们挂载的cache目录:
    这里写图片描述

    hostPath

    可以将宿主机中的目录挂载到容器中。

    创建hostPath类型的volume

    通过yaml文件创建:

    apiVersion: v1
    kind: Pod
    metadata:
      name: test-pd
    spec:
      containers:
      - image: nginx
        name: test-container
        volumeMounts:
        - mountPath: /tmp-test
          name: test-volume
      volumes:
      - name: test-volume
        hostPath:
          path: /tmp
          type: Directory

    这里指定了源宿主机路径为/tmp,并指定它的类型为目录,将它挂在到容器的/tmp-test上

    创建:

    kubectl create -f hostpath.yaml 

    这里写图片描述

    查看volume

    进入这个pod:
    这里写图片描述

    可以看到容器将宿主机中的tmp目录挂载到了容器中的tmp-test上,其中的文件就是宿主机的文件。

    因为我实在master上查看的,所以下意识看了一下master上的tmp文件,发现文件名不对啊,后来想到应该是看node节点的tmp目录

    查看下pod分配到了哪个node,并查看该node下的tmp目录:
    这里写图片描述

    应用场景

    比如说做宿主机性能分析的应用,将proc等目录挂载到容器中可以用到,因为这些目录在任何宿主机上都有。

    网络数据卷


    NFS

    安装nfs

    首先另起一台虚拟机安装nfs:

    yum install -y rpcbind
    yum install -y nfs-utils

    配置exports:
    echo "/opt/nfs/data *(rw,no_root_squash)" >> /etc/exports

    创建nfs挂载文件的相关目录:

    mkdir -p /opt/nfs/data
    touch /opt/nfs/data/index.html
    echo "This is nfs volume test for k8s" >  /opt/nfs/data/index.html

    启动nfs:

    /etc/init.d/rpcbind start
    /etc/init.d/nfs start  

    创建nfs类型的volume

    通过yaml文件配置:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: nginx-nfs
    spec:
      replicas: 3
      template:
        metadata:
          labels:
            app: nginx-nfs
        spec:
          containers:
          - name: nginx-nfs
            image: nginx
            volumeMounts:
            - name: wwwroot
              mountPath: /usr/share/nginx/html
            ports:
            - containerPort: 80
          volumes:
          - name: wwwroot
            nfs:
            server: 10.10.109.19
            path: /opt/nfs/data

    这里指定了创建3副本的nginx,并指定nfs数据卷服务器为10.10.109.19,挂载/opt/wwwroot到容器的/usr/share/nginx/html

    创建:

    kubectl create -f nfs.yaml

    这里写图片描述

    访问测试

    首先将pod作为服务发布:

    apiVersion: v1
    kind: Service
    metadata:
      name: nginx-nfs-svc 
      labels:
        app: nginx-nfs
    spec:
      ports:
      - port: 90
        targetPort: 80
      selector:
        app: nginx-nfs

    发布:

    kubectl create -f nginx-service.yaml

    这里写图片描述

    在node节点通过ClusterIP进行访问.

    GlusterFS

    这是一个主流的分布式的存储,可以保证数据的可靠性和提高性能。

    Presustent Volumes 持久卷


    相关概念

    Presustent Volumes:又称为 PV,持久卷,是对存储抽象实现,是的存储作为集群中的资源。
    Presustent VolumesClaim:又称 PVC,持久卷申请,PVC消费PV资源

    pv 和 pvc是一种对底层存储抽象化管理的机制。pod 申请 PVC作为卷来使用,集群通过PVC查找绑定的PV,并挂在给pod

    PV类型

    • GCEPersistentDisk
    • AWSElasticBlockStore
    • AzureFile
    • AzureDisk
    • FC (Fibre Channel)
    • FlexVolume
    • Flocker
    • NFS
    • iSCSI
    • RBD (Ceph Block Device)
    • CephFS
    • Cinder (OpenStack block storage)
    • Glusterfs
    • VsphereVolume
    • Quobyte Volumes
    • HostPath
    • VMware Photon
    • Portworx Volumes
    • ScaleIO Volumes
    • StorageOS

    PV设定时的重要参数

    访问模式(accessModes)

    accessModes 主要有如下的几个:

    • ReadWriteOnce:读写挂载在一个节点上(谁用谁挂载)
    • ReadOnlyMany:只读挂载在多个节点上
    • ReadWriteMany:读写挂载在多个节点上

    回收策略(Recycling Policy)

    主要的Recycling Policy有如下三个:

    • Retain:不做任何操作,不使用的时候需要手动删除(默认)
    • Recycle:没有PVC使用的时候清空数据让其他PVC使用
    • Delete:

    PV状态(Phase)

    常见的Phase有如下几种:
    - Available:可用(可以被新的pvc挂载)
    - Bound:已经被pvc挂载了
    - Released:pvc已不再使用需要回收
    - Failed:创建失败

    创建一个PV

    通过nfs创建

    这也是我这里采用的方法

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: nfs-pv
    spec:
      capacity:
        storage: 5Gi
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Recycle
      nfs:
        path: /opt/nfs/data
        server: 10.10.109.19
    
    kubectl create -f nfs-pv.yaml

    通过glusterfs创建

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: gluster-pv
    spec:
      capacity:
        storage: 5Gi
      accessModes:
        - ReadWriteMany
      glusterfs:
        endpoints: "glusterfs-cluster"
        path: "gv0"
        readOnly: false

    查看创建的PV资源:
    这里写图片描述

    可以看到通过NFS创建的容量5G的pv已经成功了

    创建pvc

    只创建pv并不能直接使用,还需要pvc进行对pv的消费

    pvc是统一的,不用考虑后端是nfs还是glusterfs

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc001
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 5Gi
    
    kubectl create -f pvc.yaml

    requests指定了这个pvc申请多大的pv

    一般情况下可能会有多个pv,这种情况下pvc如何绑定pv的呢?其实是有两个条件:
    1、根据pvc申请的容量,采用最小匹配原则,例如有5G、10G、20G的pv,pvc申请4G,那么就会匹配到5G的pv
    2、根据访问模式匹配,匹配访问模式和pv模式一直的

    查看创建情况:
    这里写图片描述

    可以看到pv和pvc已经是绑定的状态。

    创建应用

    现在创建一个nginx应用来使用这个pvc:

    apiVersion: v1
    kind: Pod
    metadata:
      name: mypod
    spec:
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
          - mountPath: "/usr/share/nginx/html"
            name: wwwroot
      volumes:
        - name: wwwroot
          persistentVolumeClaim:
            claimName: pvc001
    
    kubectl create -f pvc-app.yaml

    在这个应用创建的时候指定了使用pvc的名称为pvc001

    查看创建结果:
    这里写图片描述

    已经创建成功了

    查看一下这个pod的ip,然后在任意节点上访问测试下这个pod:

    现在nginx的页面是nfs中的index的内容了

    然后尝试修改一下nfs中的index的内容然后重新访问:

    在修改后nginx的页面也同时更改了

    pv和pvc带来的好处

    首先就是不需要过多的关注后端的存储,不论后端是nfs还是glasterfs,对于开发人员更加友好。

    另外就是方便统一管理后端存储,运维人员负责生成不同大小的pv,开发人员只需要请求合适的pvc即可。

    展开全文
  • 用户可以通过docker run的--volume/-v或--mount选项来创建带有数据卷的容器,但这两个选项有些微妙的差异,在这里总结梳理一下。 二、命令用法 --volume(-v) 参数--volume(或简写为-v)只能创建bind mount。示例...

    一、前言

    用户可以通过docker run--volume/-v--mount选项来创建带有数据卷的容器,但这两个选项有些微妙的差异,在这里总结梳理一下。

    二、命令用法

    --volume(-v)

    参数--volume(或简写为-v)只能创建bind mount。示例:

    docker run --name $CONTAINER_NAME -it \
    -v $PWD/$CONTAINER_NAME/app:/app:rw \
    -v $PWD/$CONTAINER_NAME/data:/data:ro \
    avocado-cloud:latest /bin/bash
    

    注释:

    • 命令格式:[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]]
    • 如果指定HOST-DIR则必须是绝对路径,如果路径不存在则会自动创建
    • 实例中的rw为读写,ro为只读

    --mount

    参数--mount默认情况下用来挂载volume,但也可以用来创建bind mount和tmpfs。如果不指定type选项,则默认为挂载volume,volume是一种更为灵活的数据管理方式,volume可以通过docker volume命令集被管理。示例:

    docker run --name $CONTAINER_NAME -it \
    --mount type=bind,source=$PWD/$CONTAINER_NAME/app,destination=/app \
    --mount source=${CONTAINER_NAME}-data,destination=/data,readonly \
    avocado-cloud:latest /bin/bash
    

    注释:

    • 挂载volume命令格式:[type=volume,]source=my-volume,destination=/path/in/container[,...]
    • 创建bind mount命令格式:type=bind,source=/path/on/host,destination=/path/in/container[,...]
    • 如果创建bind mount并指定source则必须是绝对路径,且路径必须已经存在
    • 示例中readonly表示只读

    三、差异总结

    1、创建bind mount和挂载volume的比较

    对比项 bind mount volume
    Source位置 用户指定 /var/lib/docker/volumes/
    Source为空 覆盖dest为空 保留dest内容
    Source非空 覆盖dest内容 覆盖dest内容
    Source种类 文件或目录 只能是目录
    可移植性 一般(自行维护) 强(docker托管)
    宿主直接访问 容易(仅需chown) 受限(需登陆root用户)*

    *注释:Docker无法简单地通过sudo chown someuser: -R /var/lib/docker/volumes/somevolume来将volume的内容开放给主机上的普通用户访问,如果开放更多权限则有安全风险。而这点上Podman的设计就要理想得多,volume存放在$HOME/.local/share/containers/storage/volumes/路径下,即提供了便捷性,又保障了安全性。无需root权限即可运行容器,这正是Podman的优势之一,实际使用过程中的确受益良多。

    2、创建bind mount时使用--volume--mount的比较

    对比项 --volume 或 -v --mount type=bind
    如果主机路径不存在 自动创建 命令报错

     

    转载地址:https://shichen.blog.csdn.net/article/details/106292036

    展开全文
  • volume 服务

    2019-07-10 17:31:42
    Android 的volume服务主要是用来管理usb/sd卡 等外部存储设备。平台可以对外部存储设备进行操作和轮询状态,当外部存储设备状态发生变化时,volume 服务也会即时报告平台。 相关代码主要位于:system/core/...

    Android 的volume服务主要是用来管理usb/sd卡 等外部存储设备。平台可以对外部存储设备进行操作和轮询状态,当外部存储设备状态发生变化时,volume 服务也会即时报告平台。

     

    相关代码主要位于:
    system/core/vold
    frameworks/base/services/java/com/android/server/MountListener.java
    frameworks/base/services/java/com/android/server/MountService.java
    frameworks/base/core/java/android/os/IMountService.aidl
    hardware/libhardware_legacy/mount/IMountService.cpp
    hardware/libhardware_legacy/include/hardware_legacy/IMountService.h

    下图概述了这些组件之间的关系。但是没有搞清楚IMountService.h/cpp是干什么用的。

    还有一点值得注意,MountService被一个Android内部类ServiceManager注册(SystemServer.java):
    ServiceManager.addService("mount", new MountService(context))
    以这种方式注册有名服务(named service),所注册的服务是一个实现了aidl产生的stub类的派生类,并不需要实现一个Service的派生类。ServiceManager仅供Android平台内部使用。

    转载于:https://www.cnblogs.com/yuanfang/archive/2010/12/23/1914902.html

    展开全文
  • kubernetes存储Volume mounts

    千次阅读 2019-08-20 11:33:37
    Volume 本节我们讨论 Kubernetes 的存储模型 Volume,学习如何将各种持久化存储映射到容器。 我们经常会说:容器和 Pod 是短暂的。 其含义是它们的生命周期可能很短,会被频繁地销毁和创建。容器销毁时,保存在容器...

    Volume

    本节我们讨论 Kubernetes 的存储模型 Volume,学习如何将各种持久化存储映射到容器。

    我们经常会说:容器和 Pod 是短暂的。
    其含义是它们的生命周期可能很短,会被频繁地销毁和创建。容器销毁时,保存在容器内部文件系统中的数据都会被清除。

    为了持久化保存容器的数据,可以使用 Kubernetes Volume。

    Volume 的生命周期独立于容器,Pod 中的容器可能被销毁和重建,但 Volume 会被保留。

    本质上,Kubernetes Volume 是一个目录,这一点与 Docker Volume 类似。当 Volume 被 mount 到 Pod,Pod 中的所有容器都可以访问这个 Volume。Kubernetes Volume 也支持多种 backend 类型,包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等,完整列表可参考 https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

    Volume 提供了对各种 backend 的抽象,容器在使用 Volume 读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中呢还是云硬盘上。对它来说,所有类型的 Volume 都只是一个目录。

    我们将从最简单的 emptyDir 开始学习 Kubernetes Volume。

    emptyDir

    emptyDir 是最基础的 Volume 类型。正如其名字所示,一个 emptyDir Volume 是 Host 上的一个空目录。且无需指定宿主机上对应的目录,kubernetes会自动分配一个随机的目录。

    emptyDir Volume 对于容器来说是持久的,对于 Pod 则不是。当 Pod 从节点删除时,Volume 的内容也会被删除。但如果只是容器被销毁而 Pod 还在,则 Volume 不受影响。

    也就是说:emptyDir Volume 的生命周期与 Pod 一致。

    Pod 中的所有容器都可以共享 Volume,它们可以指定各自的 mount 路径。下面通过例子来实践 emptyDir,配置文件如下:

    apiVersion: v1
    kind: Pod
    metadata:
      name: producer-consumer
    spec:
      containers:
      - image: busybox
        name: producer
        volumeMounts:
        - mountPath: /producer_dir
          name: shared-volume
        args:
        - /bin/sh
        - -c
        - echo "hello world" > /producer_dir/hello ; sleep 30000
    
      - image: busybox
        name: consumer
        volumeMounts:
        - mountPath: /consumer_dir
          name: shared-volume
        args:
        - /bin/sh
        - -c
        - cat /consumer_dir/hello ; sleep 30000
    
      volumes:
      - name: shared-volume
        emptyDir: {}
    
    

    这里我们模拟了一个 producer-consumer 场景。Pod 有两个容器 producer和 consumer,它们共享一个 Volume。producer 负责往 Volume 中写数据,consumer 则是从 Volume 读取数据。

    ① 文件最底部 volumes 定义了一个 emptyDir 类型的 Volume shared-volume。

    ② producer 容器将 shared-volume mount 到 /producer_dir 目录。

    ③ producer 通过 echo 将数据写到文件 hello 里。

    ④ consumer 容器将 shared-volume mount 到 /consumer_dir 目录。

    ⑤ consumer 通过 cat 从文件 hello 读数据。

    执行如下命令创建 Pod:

    kubectl apply -f emptyDir.yml
    

    kubectl logs 显示容器 consumer 成功读到了 producer 写入的数据,验证了两个容器共享 emptyDir Volume。

    [root@master1] ~$ kubectl logs producer-consumer consumer
    hello world
    

    因为 emptyDir 是 Docker Host 文件系统里的目录,其效果相当于执行了 docker run -v /producer_dir 和 docker run -v /consumer_dir。通过 docker inspect 查看容器的详细配置信息,我们发现两个容器都 mount 了同一个目录:

    #producer
    {
                    "Type": "bind",
                    "Source": "/var/lib/kubelet/pods/29371fb1-246b-11e9-be96-00505638a42b/volumes/kubernetes.io~empty-dir/shared-volume",
                    "Destination": "/producer_dir",
                    "Mode": "",
                    "RW": true,
                    "Propagation": "rprivate"
                },
    
    #consumer
    {
                    "Type": "bind",
                    "Source": "/var/lib/kubelet/pods/29371fb1-246b-11e9-be96-00505638a42b/volumes/kubernetes.io~empty-dir/shared-volume",
                    "Destination": "/consumer_dir",
                    "Mode": "",
                    "RW": true,
                    "Propagation": "rprivate"
                },
    
    

    这里 /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-0800274451ad/volumes/kubernetes.io~empty-dir/shared-volume 就是 emptyDir 在 Host 上的真正路径。

    emptyDir 是 Host 上创建的临时目录,其优点是能够方便地为 Pod 中的容器提供共享存储,不需要额外的配置。但它不具备持久性,如果 Pod 不存在了,emptyDir 也就没有了。根据这个特性,emptyDir 特别适合 Pod 中的容器需要临时共享存储空间的场景,比如前面的生产者消费者用例。

    hostPath Volume

    hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。大部分应用都不会使用 hostPath Volume,因为这实际上增加了 Pod 与节点的耦合,限制了 Pod 的使用。不过那些需要访问 Kubernetes 或 Docker 内部数据(配置文件和二进制库)的应用则需要使用 hostPath。

    比如 kube-apiserver 和 kube-controller-manager 就是这样的应用,通过

    kubectl edit --namespace=kube-system pod kube-apiserver-master1.hanli.com
    查看 kube-apiserver Pod 的配置,下面是 Volume 的相关部分:

    volumeMounts:
        - mountPath: /etc/ssl/certs
          name: ca-certs
          readOnly: true
        - mountPath: /etc/pki
          name: etc-pki
          readOnly: true
        - mountPath: /etc/kubernetes/pki
          name: k8s-certs
          readOnly: true
      dnsPolicy: ClusterFirst
      enableServiceLinks: true
      hostNetwork: true
      nodeName: master1.hanli.com
      priority: 2000000000
      priorityClassName: system-cluster-critical
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      tolerations:
      - effect: NoExecute
        operator: Exists
      volumes:
      - hostPath:
          path: /etc/ssl/certs
          type: DirectoryOrCreate
        name: ca-certs
      - hostPath:
          path: /etc/pki
          type: DirectoryOrCreate
        name: etc-pki
      - hostPath:
          path: /etc/kubernetes/pki
          type: DirectoryOrCreate
        name: k8s-certs
    
    

    这里定义了三个 hostPath volume k8s、certs 和 pki,分别对应 Host 目录 /etc/kubernetes、/etc/ssl/certs 和 /etc/pki。

    如果 Pod 被销毁了,hostPath 对应的目录也还会被保留,从这点看,hostPath 的持久性比 emptyDir 强。不过一旦 Host 崩溃,hostPath 也就没法访问了。

    下一节我们将学习具备真正持久性的 Volume。

    ceph

    如果 Kubernetes 部署在诸如 AWS、GCE、Azure 等公有云上,可以直接使用云硬盘作为 Volume,下面是 AWS Elastic Block Store 的例子:

    在这里插入图片描述

    要在 Pod 中使用 ESB volume,必须先在 AWS 中创建,然后通过 volume-id 引用。其他云硬盘的使用方法可参考各公有云厂商的官方文档。

    Kubernetes Volume 也可以使用主流的分布式存,比如 Ceph、GlusterFS 等,下面是 Ceph 的例子:

    在这里插入图片描述

    Ceph 文件系统的 /some/path/in/side/cephfs 目录被 mount 到容器路径 /test-ceph。

    相对于 emptyDir 和 hostPath,这些 Volume 类型的最大特点就是不依赖 Kubernetes。Volume 的底层基础设施由独立的存储系统管理,与 Kubernetes 集群是分离的。数据被持久化后,即使整个 Kubernetes 崩溃也不会受损。

    当然,运维这样的存储系统通常不是项简单的工作,特别是对可靠性、高可用和扩展性有较高要求时。

    Volume 提供了非常好的数据持久化方案,不过在可管理性上还有不足。下一节我们将学习具有更高管理性的存储方案:PersistentVolume & PersistentVolumeClaim。

    PersistentVolume & PersistentVolumeClaim。

    Volume 提供了非常好的数据持久化方案,不过在可管理性上还有不足。

    拿前面 AWS EBS 的例子来说,要使用 Volume,Pod 必须事先知道如下信息:

    当前 Volume 来自 AWS EBS。

    EBS Volume 已经提前创建,并且知道确切的 volume-id。

    Pod 通常是由应用的开发人员维护,而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息:

    要么询问管理员。

    要么自己就是管理员。

    这样就带来一个管理上的问题:应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大,特别是对于生成环境,考虑到效率和安全性,这就成了必须要解决的问题。

    Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。

    PersistentVolume (PV) 是外部存储系统中的一块存储空间,由管理员创建和维护。与 Volume 一样,PV 具有持久性,生命周期独立于 Pod。

    PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时,用户可以创建一个 PVC,指明存储资源的容量大小和访问模式(比如只读)等信息,Kubernetes 会查找并提供满足条件的 PV。

    有了 PersistentVolumeClaim,用户只需要告诉 Kubernetes 需要什么样的存储资源,而不必关心真正的空间从哪里分配,如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理,只有管理员才应该关心创建 PersistentVolume 的细节信息。

    Kubernetes 支持多种类型的 PersistentVolume,比如 AWS EBS、Ceph、NFS 等,完整列表请参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

    NFS

    下节我们用 NFS 来体会 PersistentVolume 的使用方法。
    上一节我们介绍了 PV 和 PVC,本节通过 NFS 实践。

    作为准备工作,我们已经在 master1 节点上搭建了一个 NFS 服务器,目录为 /opt/software,并在目录中创建一个pv1文件夹

    下面创建一个 PV mypv1,配置文件 nfs-pv1.yml 如下:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: mypv1
    spec: 
      capacity: 
        storage: 1Gi
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Recycle
      storageClassName: nfs
      nfs: 
        path: /opt/software/pv1
        server: 192.168.255.131
    
    

    ① capacity 指定 PV 的容量为 1G。

    ② accessModes 指定访问模式为 ReadWriteOnce,支持的访问模式有:
    ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
    ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
    ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。

    ③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle,支持的策略有:
    Retain – 需要管理员手工回收。
    Recycle – 清除 PV 中的数据,效果相当于执行 rm -rf /thevolume/*。
    Delete – 删除 Storage Provider 上的对应存储资源,例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

    ④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类,PVC 可以指定 class 申请相应 class 的 PV。

    ⑤ 指定 PV 在 NFS 服务器上对应的目录。

    创建 mypv1:

    kubectl apply -f nfs-pv1.yml
    

    STATUS 为 Available,表示 mypv1 就绪,可以被 PVC 申请。

    接下来创建 PVC mypvc1,配置文件 nfs-pvc1.yml 如下:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata: 
      name: mypvc1
    spec: 
      accessModes: 
        - ReadWriteOnce
      resources:
        requests: 
          storage: 1Gi
      storageClassName: nfs
    
    

    PVC 就很简单了,只需要指定 PV 的容量,访问模式和 class。

    创建 mypvc1:

    kubectl apply -f nfs-pvc1.yml
    

    从 kubectl get pvc 和 kubectl get pv 的输出可以看到 mypvc1 已经 Bound 到 mypv1,申请成功。

    接下来就可以在 Pod 中使用存储了,Pod 配置文件 pod1.yml 如下:

    kind: Pod
    apiVersion: v1
    metadata: 
      name: mypod1
    spec:
      containers:
        - name: mypod1
          image: busybox
          args:
          - /bin/sh
          - -c
          - sleep 30000
          volumeMounts:
          - mountPath: "/mydata"
            name: mydata
      volumes:
        - name: mydata
          persistentVolumeClaim:
            claimName: mypvc1
    
    

    与使用普通 Volume 的格式类似,在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc1 申请的 Volume。

    创建 mypod1:

    kubectl apply -f pod1.yml
    

    验证 PV 是否可用:

    [root@master1] /opt/software$ kubectl exec mypod1 touch /mydata/hello
    
    [root@master1] /opt/software$ ls /opt/softwar/pv1/
    hello
    

    可见,在 Pod 中创建的文件 /mydata/hello 确实已经保存到了 NFS 服务器目录 /nfsdata/pv1 中。

    如果不再需要使用 PV,可用删除 PVC 回收 PV,下节我们详细讨论。

    在这里插入图片描述

    展开全文
  • volume

    2019-08-15 16:30:20
    host_path.yaml apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - name: busybox1 image: busybox command: ["/bin/sh"] args: ["-c", "while true; do echo hello; slee...
  • 存储卷和LUN的区别详解

    千次阅读 2013-03-04 16:01:19
    LUN是英文 Logical unit number的缩写,即逻辑单元号,它是在SCSI-3中定义的,并非单用于存储范畴,也可以指使用SCSI协议的一切外围设备,如磁带机、SCSI打印机等等。从SCSI-3的SAM模型中我们知道,SCSI-3(或者之后...
  • Docker Volume 数据卷

    2020-08-12 17:15:22
    Volume 的作用 Docker的数据持久化主要使用Volume。 Docker的数据持久化即使数据不随着Container的结束而结束,数据存在于host机器上。 使用Volume的优势 Volume可以在容器之间,以及容器和主机之间共享和重用数据...
  • 不得不说cmd命令很好用呢 ...attrib "H:\System Volume Information" -s //这句话可以选择,重置系统隐藏文件。 del "H:\System Volume Information" //del 删除文件夹 rd "H:\System Volume Infor
  • UNMOUNTABLE_BOOT_VOLUME问题解决方案

    万次阅读 2012-06-30 16:21:08
    症状:本本跑着跑着突然重启,之后无法正常进入系统,出现蓝屏,报错:UNMOUNTABLE_BOOT_VOLUME(其他不相关英文单词略),进入安全模式报同样的错。 解决方法:没见过这个问题,于是赶紧google了一下"UNMOUNTABLE_...
  • 1.问题描述 在一台Linux服务器(CentOS5.8)中物理磁盘/dev/cciss/c0d1上创建LVM时 依次执行 sudo fdisk -l sudo fdisk /dev/cciss/c0d1 p n ...报错错:Can't initialize physical volume "/
  • docker volume源码分析

    万次阅读 2016-12-29 22:47:05
    这是在docker v1.10.3版本的使用过程中,使用convoy 作为volume driver,在一次docker volume remove失败时,使我不得不对docker volume 的源码做一次分析。
  • centos 2.6.32-431,查看物理卷组,提示 No volume groups found,要怎么继续扩容
  • 问题: 在使用fdisk /dev/sdb 删除原有LVM分区,在接着创建LVM新...Can't initialize physical volume "/dev/sdb1" of volume group "myvg" without -ff 问题解决: 这是由于没有卸载原有逻辑卷,逻辑卷组,物理
  • F:\System Volume Information" -s //这句话可以选择,重置系统隐藏文件。 del "F:\System Volume Information" //del 删除文件夹 rd "F:\System Volume Information" //rd 删...
  • 创建Glusterfs分布式RAID10卷

    万次阅读 2013-12-15 09:10:13
    Glusterfs3.2.4/5支持五种Volume,即Distribute卷、Stripe卷、Replica卷、Distribute stripe卷和Distribute replica卷,这五种卷可以满足不同应用对高性能、高可用的需求。 (1)distribute volume:分布式卷,文件...
  • docker volume用法

    千次阅读 2019-08-23 15:51:36
    volume在docker中的意思表示将宿主机上的目录挂在到docker容器中,这样可以保持数据持久化,当将容器删除时,数据不会丢失 1、手动创建一个volume可以使用命令:docker volume create wincom-node,如下图所示: ...
  • 如今的病毒真是太猖狂,移动硬盘的System Volume Information 文件夹都感染上了。用杀毒软件虽然能检测到,但是没有办法清除掉,因为这个文件夹当前用户是没有权限访问到的,也就没有办法修改或是删除。所以要清除掉...
  • 在使用U盘测试ARM板的时候,会发现System Volume Information这个文件夹阴魂不散,总是存在,在Windows下是看不见的,即便将文件的查看属性设置为显示隐藏文件。 在使用U盘进行嵌入式ARM测试,自己做了一个脚本,想...
  • #System Volume Information文件夹无法删除很烦,强迫症表示很难受 System Volume Information是什么 造成原因 我的电脑有这个文件夹是因为当时学装系统的时候,想装双系统,结果导致无法开机,我进行引导修复的...
  • U盘中毒,U盘内的文件夹名称变成.exe后缀,且多出一个名为System Volume Information的文件夹,对U盘进行格式化无效后,可以尝试本篇博客介绍的方法删除文件夹。
1 2 3 4 5 ... 20
收藏数 178,655
精华内容 71,462
关键字:

volume