关于kubernetes:Kubernetes存储之PCPVC

6次阅读

共计 3944 个字符,预计需要花费 10 分钟才能阅读完成。

概念

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 应用

长久化卷类型

PersistentVolume 类型以插件模式实现。Kubernetes 目前反对以下插件类型:

  • GCEPersistentDiskAWSElasticBlockStore AzureFile AzureDisk FC (Fibre Channel)
  • FlexVolumeFlockerNFS iSCSIRBD (Ceph Block Device) CephFS
  • Cinder (OpenStack block storage) Glusterfs VsphereVolume Quobyte Volumes
  • HostPathVMware Photon 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 都有一套本人的用来形容特定性能的拜访模式

  • ReadWriteOnce——该卷能够被单个节点以读 / 写模式挂载
  • ReadOnlyMany——该卷能够被多个节点以只读模式挂载
  • ReadWriteMany——该卷能够被多个节点以读 / 写模式挂载

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

  • RWO – ReadWriteOnce
  • ROX – ReadOnlyMany
  • RWX – ReadWriteMany

回收策略

  • 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(已开释)——申明被删除,然而资源还未被集群从新申明
  • Failed(失败)——该卷的主动回收失败

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

长久化演示阐明 - NFS

Ⅰ、装置 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

Ⅱ、部署 PV

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

Ⅲ、创立服务并应用 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: k8s.gcr.io/nginx-slim:0.8
        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 servername),也就意味着服务间是通过 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,Podname=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 来实现。
  • 有序膨胀。
正文完
 0