文章链接
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要利用时会呈现一些问题。首先，当容器解体时，kubelet 会重启它，然而容器中的文件将失落——容器以洁净的状态（镜像最后的状态）重新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间通常须要共享文件。所以我会用 NFS 为例，创立 PV 、PVC.

PV 属于集群中的资源。PVC 是对这些资源的申请，也作为对资源的申请的查看。 PV 和 PVC 之间的相互作用遵循这样的生命周期.

PersistentVolume（PV）

PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具备独立于应用 PV 的 Pod 的生命周期。此 API 对象蕴含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。

PV 有两种形式来配置：动态和动静。

  • 动态
    集群管理员创立一些 PV。它们带有可供群集用户应用的理论存储的细节。它们存在于 Kubernetes API 中，可用于生产。

  • 动静
    依据 StorageClasses，当管理员创立的动态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动静地为 PVC 创立卷。

    装置并配置 nfs rpcbind

    yum install -y nfs-utils rpcbindmkdir -p /home/bsh/nfsvim /etc/exports/home/bsh/nfs *(rw,sync,no_root_squash)
    配置详解：
    ro只读拜访
    rw读写访问
    sync所有数据在申请时写入共享
    asyncNFS在写入数据前能够相应申请
    secureNFS通过1024以下的平安TCP/IP端口发送
    insecureNFS通过1024以上的端口发送
    wdelay如果多个用户要写入NFS目录，则归组写入（默认）
    no_wdelay如果多个用户要写入NFS目录，则立刻写入，当应用async时，无需此设置。
    Hide在NFS共享目录中不共享其子目录
    no_hide共享NFS目录的子目录
    subtree_check如果共享/usr/bin之类的子目录时，强制NFS查看父目录的权限（默认）
    no_subtree_check和下面绝对，不查看父目录权限
    all_squash共享文件的UID和GID映射匿名用户anonymous，适宜专用目录。
    no_all_squash保留共享文件的UID和GID（默认）
    root_squashroot用户的所有申请映射成如anonymous用户一样的权限（默认）
    no_root_squasroot用户具备根目录的齐全治理拜访权限
    anonuid=xxx指定NFS服务器/etc/passwd文件中匿名用户的UID

启动 nfs rpcbind

systemctl enable nfs rpcbindsystemctl start nfs rpcbind

创立PV

创立 yaml 文件
vim tomcat-log-pv.yaml

apiVersion: v1kind: PersistentVolumemetadata:  name: tomcatspec:  capacity:    storage: 1Gi  accessModes:    - ReadWriteMany  nfs:    path: /home/bsh/nfs/tomcat-log    server: 10.0.10.51

创立 pv

kubectl  apply  -f  tomcat-log-pv.yaml

查看pv

[root@master ]# kubectl  get  pvNAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGEtomcat   1Gi        RWX            Retain           Available                                   26s

pv 属性详解

PV的存储容量

PV 将具备特定的存储容量。这是应用PV的capacity属性设置的。

目前，存储大小是能够设置或申请的惟一资源。将来的属性可能包含 IOPS、吞吐量等。

PV的拜访模式

PersistentVolume能够以资源提供者反对的任何形式挂载到主机上。如下表所示，供应商具备不同的性能，每个 PV 的拜访模式都将被设置为该卷反对的特定模式。例如，NFS 能够反对多个读/写客户端，但特定的 NFS PV 可能以只读形式导出到服务器上。每个 PV 都有一套本人的用来形容特定性能的拜访模式。
存储模式包含：

  • ReadWriteOnce——该卷能够被单个节点以读/写模式挂载
  • ReadOnlyMany——该卷能够被多个节点以只读模式挂载
  • ReadWriteMany——该卷能够被多个节点以读/写模式挂载
    在命令行中，拜访模式缩写为：
  • RWO - ReadWriteOnce
  • ROX - ReadOnlyMany
  • RWX - ReadWriteMany
    一个卷一次只能应用一种拜访模式挂载，即便它反对很多拜访模式。例如，GCEPersistentDisk 能够由单个节点作为 ReadWriteOnce 模式挂载，或由多个节点以 ReadOnlyMany 模式挂载，但不能同时挂载
    PV的回收策略
    persistentVolumeReclaimPolicy属性用来指定PV的回收策略

以后的回收策略包含：

  • Retain（保留）——手动回收
  • Recycle（回收）——根本擦除（rm -rf /thevolume/*）
  • Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除
    以后，只有 NFS 和 HostPath 反对回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷反对删除策略。

storageClassName PV 能够具备一个类，通过将 storageClassName 属性设置为 StorageClass 的名称来指定该类。一个特定类别的 PV 只能绑定到申请该类别的 PVC。没有 storageClassName 的 PV 就没有类，它只能绑定到不须要特定类的 PVC。

PersistentVolumeClaim（PVC）

PersistentVolumeClaim（PVC）是用户存储的申请。它与 Pod 类似。Pod 耗费节点资源，PVC 耗费 PV 资源。Pod 能够申请特定级别的资源（CPU 和内存）。申明能够申请特定的大小和拜访模式（例如，能够以读/写一次或 只读屡次模式挂载）。

创立PVC

创立 yaml 文件
vim tomcat-log-pvc.yaml

apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: tomcatspec:  accessModes:    - ReadWriteMany  resources:    requests:      storage: 1Gi

创立 pv

kubectl  apply  -f  tomcat-log-pvc.yaml

查看pv

[root@master ]# kubectl  get pvcNAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGEtomcat   Bound    tomcat   1Gi        RWX                           18s

应用PVC

vim tomcat.yaml

apiVersion: apps/v1 kind: Deployment   metadata:               name: tomcat-deployment       labels:           app: tomcat  spec:            replicas: 3  selector:          matchLabels:       app: tomcat  minReadySeconds: 1  progressDeadlineSeconds: 60  revisionHistoryLimit: 2  strategy:    type: RollingUpdate    rollingUpdate:      maxSurge: 1      maxUnavailable: 1  template:            metadata:        labels:          app: tomcat    spec:               containers:           - name: tomcat             image: wenlongxue/tomcat:tomcat-demo-62-8fe6052            imagePullPolicy: Always                  ports:        - containerPort: 8080        resources:          requests:            memory: "2Gi"            cpu: "80m"          limits:             memory: "2Gi"             cpu: "80m"        readinessProbe:          httpGet:            path: /            port: 8080          initialDelaySeconds: 180          periodSeconds: 5          timeoutSeconds: 3          successThreshold: 1          failureThreshold: 30        volumeMounts:        - mountPath: "/usr/local/tomcat/logs"          name: tomcat      volumes:      - name: tomcat        persistentVolumeClaim:          claimName: tomcat

部署查看 pod

# 部署kubectl  apply  -f tomcat.yaml # 查看kubectl  get  pods |grep  tomcattomcat-deployment-7588b5c8fd-4grh2       1/1     Running   0          31stomcat-deployment-7588b5c8fd-l89t7       1/1     Running   0          31stomcat-deployment-7588b5c8fd-mb8bh       1/1     Running   0          31s

最初

PVC 不关怀后端存储提供者是 NFS 还是 GFS，具体应用哪种类型的存储由 PV 来定义，PVC 只和暗藏了存储实现细节的 PV 对接。
本形式为动态调配，如果有一千个 Pod，每个 Pod 有一个 PVC，那么管理员须要人工开设一千个 PV，随着集群规模的扩充，将导致无奈无效治理。
K8S 提供了一种能够动态分配的工作机制，能够主动创立 PV，该机制依赖一个叫做 StorageClass 的 API 对象。
文章链接