k8s基于Storage Class和nfs动态供给(NFS+PV+PVC)

1、Kubernetes集群管理员通过提供不同的存储类,可以满足用户不同的服务质量级别、备份策略和任意策略要求的存储需求。动态存储卷供应使用StorageClass进行实现,其允许存储卷按需被创建。如果没有动态存储供应,Kubernetes集群的管理员将不得不通过手工的方式类创建新的存储卷。通过动态存储卷,Kubernetes将能够按照用户的需要,自动创建其需要的存储。

基于StorageClass的动态存储供应整体过程如下图所示:
k8s基于Storage Class和nfs动态供给(NFS+PV+PVC)_第1张图片1)集群管理员预先创建存储类(StorageClass);

2)用户创建使用存储类的持久化存储声明(PVC:PersistentVolumeClaim);

3)存储持久化声明通知系统,它需要一个持久化存储(PV: PersistentVolume);

4)系统读取存储类的信息;

5)系统基于存储类的信息,在后台自动创建PVC需要的PV;

6)用户创建一个使用PVC的Pod;

7)Pod中的应用通过PVC进行数据的持久化;

8)而PVC使用PV进行数据的最终持久化处理。

2、example

首先创建nfs服务,参考另外一篇文章:https://blog.csdn.net/BigData_Mining/article/details/88638879

1)创建RBAC授权provisioner,(如果集群启用了RBAC,如果namespace不是default)

# cat nfs-rbac.yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-provisioner
  namespace: monitoring
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
   name: nfs-provisioner-runner
   namespace: monitoring
rules:
   -  apiGroups: [""]
      resources: ["persistentvolumes"]
      verbs: ["get", "list", "watch", "create", "delete"]
   -  apiGroups: [""]
      resources: ["persistentvolumeclaims"]
      verbs: ["get", "list", "watch", "update"]
   -  apiGroups: ["storage.k8s.io"]
      resources: ["storageclasses"]
      verbs: ["get", "list", "watch"]
   -  apiGroups: [""]
      resources: ["events"]
      verbs: ["watch", "create", "update", "patch"]
   -  apiGroups: [""]
      resources: ["services", "endpoints"]
      verbs: ["get","create","list", "watch","update"]
   -  apiGroups: ["extensions"]
      resources: ["podsecuritypolicies"]
      resourceNames: ["nfs-provisioner"]
      verbs: ["use"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: monitoring
roleRef:
  kind: ClusterRole
  name: nfs-provisioner-runner
  apiGroup: rbac.authorization.k8s.io

2)创建nfs的nfs-client-provisioner

# cat nfs-deployment.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
   name: nfs-client-provisioner
   namespace: monitoring
spec:
   replicas: 1
   strategy:
     type: Recreate
   template:
      metadata:
         labels:
            app: nfs-client-provisioner
      spec:
         serviceAccount: nfs-provisioner
         containers:
            -  name: nfs-client-provisioner
               image: quay.io/external_storage/nfs-client-provisioner:latest
               volumeMounts:
                 -  name: nfs-client-root
                    mountPath:  /persistentvolumes
               env:
                 -  name: PROVISIONER_NAME
                    value: fuseim.pri/ifs
                 -  name: NFS_SERVER
                    value: 10.2.68.77
                 -  name: NFS_PATH
                    value: /data/opv
         volumes:
           - name: nfs-client-root
             nfs:
               server: 10.2.68.77
               path: /data/opv

!!PS:10.2.68.77是nfs服务的监听地址,/data/opv是nfs共享的目录。
这个镜像中volume的mountPath默认为/persistentvolumes,不能修改,否则运行时会报错。

3)创建storageclass

# cat storageclass-nfs.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: grafana-nfs
  namespace: monitoring
provisioner: fuseim.pri/ifs
reclaimPolicy: Retain

provisioner: 该字段指定使用存储卷类型,不同的存储卷提供者类型这里要修改成对应的值。
reclaimPolicy:有两种策略:Delete、Retain。默认是Delet
用户删除PVC释放对PV的占用后,系统根据PV的"reclaim policy"决定对PV执行何种回收操作。 目前,"reclaim policy"有三种方式:Retained、Recycled、Deleted。
Retained

保护被PVC释放的PV及其上数据,并将PV状态改成"released",不将被其它PVC绑定。集群管理员手动通过如下步骤释放存储资源:

手动删除PV,但与其相关的后端存储资源如(AWS EBS, GCE PD, Azure Disk, or Cinder volume)仍然存在。
手动清空后端存储volume上的数据。
手动删除后端存储volume,或者重复使用后端volume,为其创建新的PV。

Delete

删除被PVC释放的PV及其后端存储volume。对于动态PV其"reclaim policy"继承自其"storage class",
默认是Delete。集群管理员负责将"storage class"的"reclaim policy"设置成用户期望的形式,否则需要用
户手动为创建后的动态PV编辑"reclaim policy"。

Recycle

保留PV,但清空其上数据,已废弃

!!PS:fuseim.pri/ifs为上面deployment上创建的PROVISIONER_NAME(可以更改,但是这两个地方必须统一)。

4)创建PersistenetVolumeClaim

在存储类被正确创建后,就可以创建PersistenetVolumeClaim来请求StorageClass,而StorageClass将会为PersistenetVolumeClaim自动创建一个可用PersistentVolume。PersistenetVolumeClaim是对PersistenetVolume的声明,即PersistenetVolume为存储的提供者,而PersistenetVolumeClaim为存储的消费者。

# cat pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim
  namespace: monitoring
 # annotations:
 #   volume.beta.kubernetes.io/storage-class: "grafana-nfs"
spec:
  storageClassName: grafana-nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

!!PS:grafana-nfs为上面创建的storageclass的name,1Mi是设置的目录的大小。
在这里插入图片描述
5)testpod

# cat testpod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: monitoring
spec:
  containers:
  - name: test-pod
    image: busybox
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && exit 0 || exit 1"
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim

启动pod,一会儿pod就是completed状态,说明执行完毕。
在这里插入图片描述
我们去NFS共享目录查看有没有SUCCESS文件。
在这里插入图片描述
说明部署正常,并且可以动态分配NFS的共享卷。

StatefulSet案例

本来做StorageClass测试的目的就是为了实现StatefulSet,结果越做越跑偏。。。现在回到原本的目标,来实现一个简单的StatefulSet。

编写statefulset.yaml文件如下:

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx1"
  replicas: 2
  volumeClaimTemplates:
  - metadata:
      name: test
      annotations:
        volume.beta.kubernetes.io/storage-class: "nfs"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      serviceAccount: nfs-provisioner
      containers:
      - name: nginx1
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: "/persistentvolumes"
          name: test

注意,这里的mountPath必须指定为/persistentvolumes,否则会出现表面上PV创建成功,其实在NFS系统中找不到的问题。

当发现两个Pod都正常运行,且在NFS系统中能够找到PV,说明试验成功。

进一步的,可以用kubectl exec -it 进入Pod,并创建一个文件,看看在PV中能否发现相同的文件已生成。

你可能感兴趣的:(Kubernetes)