关于kubernetes:kubernetes-使用-PV-和-PVC-管理数据存储

文章链接
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要利用时会呈现一些问题。首先，当容器解体时，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 rpcbind
  mkdir -p /home/bsh/nfs
  vim /etc/exports
  /home/bsh/nfs *(rw,sync,no_root_squash)

  配置详解：
  ro	只读拜访
  rw	读写访问
  sync	所有数据在申请时写入共享
  async	NFS 在写入数据前能够相应申请
  secure	NFS 通过 1024 以下的平安 TCP/IP 端口发送
  insecure	NFS 通过 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_squash	root 用户的所有申请映射成如 anonymous 用户一样的权限（默认）
  no_root_squas	root 用户具备根目录的齐全治理拜访权限
  anonuid=xxx	指定 NFS 服务器 /etc/passwd 文件中匿名用户的 UID

启动 nfs rpcbind

systemctl enable nfs rpcbind
systemctl start nfs rpcbind

创立 PV

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

apiVersion: v1
kind: PersistentVolume
metadata:
  name: tomcat
spec:
  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  pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
tomcat   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: v1
kind: PersistentVolumeClaim
metadata:
  name: tomcat
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

创立 pv

kubectl  apply  -f  tomcat-log-pvc.yaml

查看 pv

[root@master]# kubectl  get pvc
NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
tomcat   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  tomcat
tomcat-deployment-7588b5c8fd-4grh2       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-l89t7       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-mb8bh       1/1     Running   0          31s

最初

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