关于kubernetes:Kubernetes存储之PCPVC

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

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 服务器

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

匹配 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 来实现。
有序膨胀。

关于kubernetes:Kubernetes存储之PCPVC

概念

长久化卷类型

PV 拜访模式

回收策略

状态

长久化演示阐明 - NFS

对于 StatefulSet