NFS服务器安装

yum install -y nfs-common nfs-utils rpcbind

 创建挂载目录：

mkdir /nfs
chmod 777 /nfs/
chown nfsnobody /nfs

 

vim /etc/exports
  #标明要开放出去的目录
  nfs *(rw,no_root_squash,no_all_squash,sync)

systemctl start rpcbind
systemctl start nfs

 Master Node节点安装：

yum install -y nfs-utils rpcbind

 测试nfs是否可用：

在任意一台机器上：

137为我们的nfs服务器

mkdir /test
showmount -e 192.168.170.137
mount -t nfs 192.168.170.137:/nfs /test
cd /test
date > index.html

 

回到nfs服务器查看 nfs目录：

测试完毕 ：

umount /test
rm -rf /test

 pv yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfsv1
  nfs:
    path: /nfs
    server: 192.168.170.137

创建pv

创建pvc 及其服务  yaml：

#无头服务
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: nginx
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfsv1"
      resources:
        requests:
          storage: 1Gi

这里需要注意如果你创建好了 pv 但是报错：

error while running "VolumeBinding" filter plugin for pod "web-0": pod has unbound immediate PersistentVolumeClaims

反复确认 pv 和 yaml 里的一致，可能是由于 自动创建的PVC 导致，删除掉旧的pvc重新创建即可。

如果上述步骤均正确，你看到的应该是如下结果：

这里由于StatefulSet会按照顺序创建 所以知显示了两个web，第二个web启动失败的原因是由于没有可供使用的pv,我们这里需要为剩下的两个pod创建pv。

回到 nfs 服务器:

重启服务：

systemctl restart rpcbind

systemctl restart nfs

 查看Export list

创建其他pv

yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv2
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfsv1
  nfs:
    path: /nfs1
    server: 192.168.170.137

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv3
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfsv1
  nfs:
    path: /nfs2
    server: 192.168.170.137

pod检测到可加载的pv资源后自动创建pvc并绑定：

将资源存放在nfs目录：

访问pod查看结果：

我们使用podname.svcname访问一下这个步骤需要进入到某个pod内部，因为外部没有dns解析：

随便创建一个pod：

apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/netcoredemo/demo1:v1
    name: myapp

 

 

如何彻底删除pv:

我们删除掉StatefulSet时会将它管理的pod一并删除。其他的需要手动删除。当我们将其它资源删除后 pv依然存在

 手动释放资源：

nfs服务器下所有的目录：

rm -rf  nfs nfs1 nfs2

kubectl get pv nfspv1 -o yaml

删除掉此处连接：

概念

PersisitentVolyme(PV)

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

PersistentVolumeClaim(PVC)

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

静态pv

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

动态PV

当管理员创建的静态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目前支持以下插件类型：

• GCEPersistentDiskAWSElasticBlockStoreAzureFileAzureDiskFC (Fibre Channel)
• FlexVolumeFlockerNFSiSCSIRBD (Ceph Block Device)CephFS
• Cinder (OpenStack block storage)GlusterfsVsphereVolumeQuobyte Volumes
• HostPath VMware PhotonPortworx VolumesScaleIO VolumesStorageOS

PV访问模式

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

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

在命令行中，访问模式缩写为：

RWO	ReadWriteOnce
ROX	ReadOnlyMany
RWX	ReadWriteMany

一个卷一次只能使用一种访问模式挂载，即使它支持很多访问模式。例如 GCEPersistentDisk可以由单个节点作为ReadWriteOnce模式挂载，或由多个节点以readOnlyMany模式挂载，但不能同时挂载。

回收策略：

Retain(保留) --手动回收

Delete (删除) --关联的存储资产 如 AWS EBS、GCE PD、Azure Disk和OpenStack Cinder卷 将被删除

当前只有NFS和HostPath支持回收策略。 AWS EBS、GCE PD 、Azure Disk 和Cinder卷支持删除策略

状态：

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

• Available（可用）——一块空闲资源还没有被任何声明绑定
• Bound（已绑定）——卷已经被声明绑定
• Released（已释放）——声明被删除，但是资源还未被集群重新声明
• Failed（失败）——该卷的自动回收失败

 

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

 

关于 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 来实现。
• 有序收缩。