kubernetes-pvc-pvc

概念

PersistentVolume(PV)

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

PersistentVolumeClaim (PVC)

是用户存储的请求。它与Pod相似。Pod消耗节点资源,PVC消耗PV资源。Pod可以请求特定级别的资源(CPU和内存)。声明可以请求特定的大小和访问模式(例如,可以以读/写一次或只读多次模式挂载)

静态pv

集群管理员创建一些PV。它们带有可供集群用户使用的实际存储的细节。它们存在与Kubernetes API中,可用于消费

动态

当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时,集群可能会尝试动态地为PVC创建卷。此配置基于StorageClasses: PVC必须请求[存储类],并且管理员必须创建并配置该类才能进行动态创建。声明该类为""可以有效地禁用其动态配置

要启用基于存储级别的动态存储配置,集群管理员需要启用API server 上的DefaultStorageClass[准入控制器]。例如,通过确保DefaultStorageClass位于 API server 组件的--admission-control标志,使用逗号分割的有序值列表中,可以完成此操作

绑定

master中的控制环路监视新的PVC,寻找匹配的PV(如果可能),并将它们绑定在一起。如果为新的PVC动态调配PV,则该环路将始终将该PV绑定到PVC。否则,用户总会得到他们所请求的存储,但是容量可能超出要求的数量。一旦PV和PVC绑定后,PersistentVolumeClaim绑定是排他性的,不管它们是如何绑定的。PVC跟PV绑定是一对一的映射

持久化卷声明的保护

PVC保护的目的是确保由Pod正在使用的PVC不会从系统中移除,因为如果被移除的话可能会导致数据丢失

当启用PVC包含alpha功能时,如果用户删除了一个Pod正在使用的PVC,则该PVC不会被立即删除。PVC的删除将被推迟,直到PVC不再被任何pod使用

持久化卷类型

PersistenVolume类型以插件形式实现。Kubernetes目前支持以下插件类型:

  • 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 Photom Portworx Volumes ScaleIO Volumes StorageOS

持久卷演示代码

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

PV 访问模式

PersistentVolume可以以资源提供者支持的任何方式挂载到主机上。如下表表示,供应商具有不同的功能,每个PV的访问模式都将设置为该卷支持的特定模式。例如,NFS可以支持多个读/写客户端,但特定的NFS PV可能以只读方式导出到服务器上。每个PV都有一套自己的用来描述特定功能的访问模式

  • ReadWriteOne – 该卷可以被单个节点以读/写模式挂载
  • ReadOnlyMany– 该卷可以被多个节点以只读模式挂载
  • ReadWriteMany– 该卷可以被多个节点以读/写模式挂载

在命令行中,访问模式缩写为:

  • RWO - ReadWriteOnce
  • ROX - ReadOnlyMany
  • RWX- ReadWriteMany
Volume 插件ReadWriteOnceReadOnlyManyReadWriteMany
AWSElasticBlockStoreAWSElasticBlockStore--
AzureFile
AzureDisk--
CephFS
Cinder--
FC-
FlexVolume-
Flocker--
GCEPersistentDisk-
Glusterfs
HostPath--
iSCSI-
PhotonPersistentDisk--
Quobyte
NFS
RBD-
VsphereVolume--(当Pod并列时有效)
PorworxVolume-
ScaleIO-

回收策略

  • Retain(保留)– 手动回收
  • Recycle(回收)–基本擦除(rm -rf /thevolume/*) 最新版的服务已经不支持该回收策略了
  • Delete(删除)– 关联的存储资产(例如AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder卷)将被删除
  • 当前,只有 NFS 和HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk和Cinder卷支持删除策略

状态

卷可以处于以下的某种状态:

  • Available(可用) – 一块空闲资源还没有被任何声明绑定

  • Bound(已绑定)– 卷已经被声明绑定

  • Released(已释放)–声明被删除,但是资源还未被集群重新声明

  • Faild(失败) – 该卷的自动回收失败

*命令行会显示绑定到 PV 的 PVC 的名称 *

持久化演示说明 - NFS

I、安装 NFS 服务器

yum install -y nfs-common nfs-utils rpcbind
mkdir /nfsdata
chmod 666 /nfsdata
chown nfsnobody /nfsdata
cat /etc/exports
    /nfsdata *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind
systemctl start nfs

II、部署 PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassNmae: nfs
  nfs:
    path: /data/nfs
    server: 10.66.66.10

III、创建服务并使用 PVC

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: harbor.bwingame8.com/library/myapp:v2
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs"
      resources:
        requests:
          storage: 1Gi

关于StatefulSet

  • 匹配 Pod name(网络标识)的模式为:(statefulset名称)-(序号),比如上面的示例: web-0,web-1,web-2
  • StatefulSet为每一个Pod副本创建了一个DNS域名,这个域名的格式为:$(podname).(headless server name),也就意味着服务间是通过Pod域名来通信而非Pod IP,因为当Pod所在Node发生故障时,Pod会被漂移到其它Node上,Pod IP会发生变化,但是Pod域名不会有变化
  • StatefulSet 使用 Headless 服务来控制Pod的域名,这个域名的FQDN为:(servicename).(namespace).svc.cluster.local,其中,“cluster.local”指的是集群的域名
  • 根据 volumeClaimTemplates,为每个 Pod创建一个pvc,pvc的命名规则匹配模式:(volumeClaimTemplates.name)-(pod_name),比如上面的volumeMounts.name=www,Pod name=web-[0-2],因此创建出来的PVC是www-web-0、www-web-1、www-web-2
  • 删除 Pod 不会删除其pvc,手动删除pvc将自动释放pv

StatefulSet的启停顺序:

  • 有序部署: 部署StatefulSet时,如果有多个Pod副本,它们会被顺序地创建(从0到N-1)并且,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态
  • 有序删除:当Pod被删除时,它们被终止的顺序是N-1到0
  • 有序扩展:当对Pod执行扩展操作时,与部署一样,它前面的Pod必须都处于Running和Ready状态

StatefulSet使用场景:

  • 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现。
  • 稳定的网络标识符,即Pod重新调度后其Podname和Hostname不变。
  • 有序部署,有序扩展,基于 init containers来实现。
  • 有序收缩

文章作者: 阿培
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 阿培 !
 上一篇
kubernetes-调度器-调度说明 kubernetes-调度器-调度说明
简介Scheduler 是kubernetes的调度器,主要的任务是把定义的Pod分配到集群的节点上。听起来非常简单,单有很多要考虑的问题 公平:如何保证每个节点都能被分配资源 资源高效利用:集群所有资源最大化被使用 效率:调度的性能要好
2019-12-04
下一篇 
kubernetes-volume kubernetes-volume
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet会重启它,但是容器中的文件将丢失–容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod中同时运行多个容器时,这些容器之
2019-12-01
  目录