Kubernetes series (seven): persistent storage StorageClass

Previous lessons we learn  PV and  PVC to use, but in front of the PV are static, what does that mean? I'm a PVC to be used, then you must manually to create a PV, we also said that in this way a large extent does not meet our needs, we have such a need for concurrent application of storage is relatively high, and the other applications read and write speeds and relatively high demand, especially for the  StatefulSet types of applications simple to use static PV is very inappropriate, in which case we need to use dynamic PV, that is, we want to explain today a  StorageClass.

Creating Provisioner

To use StorageClass, we have to install the corresponding automatic configuration program, such as storage backend we use here is the nfs, then we need to use a nfs-client auto-configuration program, we call it Provisioner, we use this program nfs server has been configured to automatically create lasting volume, that is, automatically help us to create PV.

• PV is automatically created to ${namespace}-${pvcName}-${pvName}create a shared data directory on the NFS server such naming format
• And when the PV is recovered will be archieved-${namespace}-${pvcName}-${pvName}present on the NFS server such naming format.

Of course, deploying nfs-clientbefore, we need to successfully install the nfs server, previous lessons we have passed, the service address is 1192.168.3.131, shared data directory is / data / k8s /, and then we can deploy nfs-client we can also refer directly nfs-client documents , can be installed.

 

Step: Configure Deployment, which will replace the corresponding parameters into our own configuration nfs (nfs-client.yaml)

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-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: 192.168.3.131
            - name: NFS_PATH
              value: /data/k8s
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.3.131
            path: /data/k8s

Step two: the environment variable NFS_SERVER and NFS_PATH replaced, of course, include the following nfs configuration, we can see that we're using a program called nfs-client-provisioner of serviceAccount, so we need to create a sa, and then bind the permissions corresponding to: (nfs-client-sa.yaml)

Our new here called the nfs-client-provisioner ServiceAccount, and then bind a group called nfs-client-provisioner-runner's ClusterRole, which ClusterRoledeclared some rights, including to persistentvolumesadd, delete, change, etc. authority, so we can use this ServiceAccountto automatically create PV.

The third step: After Deployment statement nfs-client to complete, since we can create a StorageClasssubject of: (nfs-client-class.yaml)

We declare a named course-nfs-storage of StorageClassobjects, pay attention to the following provisionercorresponding value and must be above Deploymentthe value of the environment variable following PROVISIONER_NAME same.

Now we have to create these resource objects it:

kubectl create -f nfs-client.yaml
kubectl create -f nfs-client-sa.yaml
kubectl create -f nfs-client-class.yaml

Once created view the resource status:

[root@localhost nfs]# kubectl get pods
NAME                                      READY   STATUS              RESTARTS   AGE
nfs-client-provisioner-5db79cb75f-nk952   0/1     ContainerCreating   0          12s

[root@localhost nfs]# kubectl get storageclass
NAME                 PROVISIONER      AGE
course-nfs-storage   fuseim.pri/ifs   31s
harbor-data          fuseim.pri/ifs   90d

New StorageClass

The above StorageClassresource object is created successfully, and then we walk through an example of a dynamic test under PV, first create a PVC objects: (test-pvc.yaml)

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

Here we declare an PVCobject using  ReadWriteMany the access patterns, space 1Mi request, but we can see the above PVC We did not identify any documents and information StorageClass associated, so if we are able to directly create objects automatically tied to the PVC given the appropriate PV object? Obviously not (provided that no suitable PV), we have here are two ways to take advantage of the above StorageClass objects we create to automatically help us create a suitable PV:

• The first method: In this PVCadd a statement object StorageClassto identify the object, where we can take advantage of a annotationsproperty is identified as follows

• kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: test-pvc
    annotations:
      volume.beta.kubernetes.io/storage-class: "course-nfs-storage"
  spec:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: 1Mi

• The second method: We can set this course-nfs-storage of StorageClass as the default storage backend Kubernetes, we can use the kubectl patchcommand to update: yaml $ kubectl patch storageclass course-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

• The above two methods are possible, of course, in order not to affect the default behavior of the system, here is the first method, you can directly create:

The above two methods are possible, of course, in order not to affect the default behavior of the system, here is the first method, you can directly create:

(Note that the network problem here necessary to pull the mirror outside the network)

kubectl create -f test-pvc.yaml
persistentvolumeclaim "test-pvc" created
[root@localhost nfs]# kubectl get pvc
NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         AGE
pvc-nfs    Bound    pv1                                        1Gi        RWO                                 12h
test-pvc   Bound    pvc-a7293619-bb8c-11e9-93e7-000c29ecf8a8   1Mi        RWX            course-nfs-storage   11h

We can see a file called test-pvc PVC object is successfully created, the state already is Bound, is not it also had a corresponding VOLUME object column is the most important STORAGECLASS, now is not it also have the value that we just created the StorageClasstarget course-nfs-storage.

Then look at it objects PV:

[root@localhost nfs]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS         REASON   AGE
pvc-a7293619-bb8c-11e9-93e7-000c29ecf8a8   1Mi        RWX            Delete           Bound    default/test-pvc   course-nfs-storage            3m48s

You can see is not automatically generated PV object associated access mode RWX, the recovery strategy is  Delete, this is not our target PV manually create it, this is done by our above  StorageClass object is created automatically. This is a method of creating StorageClass.

 

OK, here we generally understand the role of StorageClass, next we will actually use it up.