1Storage class introduction

Kubernetes Cluster administrators can provide different storage classes to meet users’ storage requirements based on different service quality levels, backup policies, and arbitrary policies. Dynamic storage volume provisioning is implemented using StorageClass, which allows storage volumes to be created on demand. Without dynamic storage provisioning, the administrator of the Kubernetes cluster would have to create new storage volumes through manual mode classes. With the dynamic storage volume, Kubernetes will be able to automatically create the storage that the user needs.

The overall process of dynamic storage supply based on StorageClass is shown as follows:

1) the cluster administrator creates the StorageClass (StorageClass) beforehand.

2) The user creates a persistent storage statement that uses the store class (PVC: PersistentVolumeClaim);

3) store persistence declarations to inform the system that it needs a PersistentVolume (PV: PersistentVolume);

4) The system reads the information of the storage class;

5) Based on the information of storage class, the system automatically creates the PV required by PVC in the background;

6) The user creates a Pod using PVC;

7) Applications in Pod carry out data persistence through PVC;

8) PVC uses PV for the final persistent processing of data.

2, define the storage class

Each stored class contains the provisioner, Parameters, and reclaimPolicy parameter fields, which are used when a PersistentVolume that belongs to a class needs to be provisioned dynamically.

The name of the storage class object is very important, and the user requests a specific storage class through the name class. When creating a storage object, the administrator sets the name and other parameters of the storage object. Once created, the storage object cannot be updated. Administrators can specify a default storage class for PVC.

Kind: StorageClass apiVersion: storage.k8s. IO /v1 Metadata: name: standard # Specifies the provisioner of the storage class. Kubernetes. IO /aws-ebs parameters: type: gp2 # reclaimPolicy: Retain mountOptions: -debugCopy the code

2.1 supplythose

The storage class has a provider parameter field that determines which storage volume plug-in the PV uses. Parameters must be set:

The Kubernetes storage class is not limited to the “interneal” provider in the table, whose name is prefixed with “kubernetes.io”; External providers can also be allowed and specified, and external providers are implemented through a separate program. The author of the external provider has full discretion over where the code will live, how it will be supplied, how it will run, what volume plug-ins (including Flex) to use, and so on. There is a class library in the Kubernetes-Incubator /external-storage repository to write the external provider. For example, NFS is not an internal provider, but it can be used. Some external providers are presented as lists in the Kubernetes-Incubator /external-storage repository, and some third party vendors provide external providers of their own.

2.2 Provider parameters

A storage class has a number of parameters that describe a storage volume and may have different parameters depending on the provider. For example, for the type parameter, its value might be IO1. When an argument is omitted, the default value is used.

2.3 Recovery strategy

A persistent storage volume created by a storage class is specified by the reclaimPolicy parameter, which can be Delete or Retain. The default value is Delete. For a persistent storage volume that is created manually and managed using a storage class, any storage volume specified at creation time will be used.

2.4 Articulated options

For a persistent storage volume that is dynamically created using a storage class, there is a mount option specified by the mountOptions parameter. If the storage volume plug-in does not support the specified mount option, the provision of storage will fail. The mount option is not validated in the storage class or PV, so it needs to be validated at setup time.

3, use storage classes

Dynamic storage volumes are implemented based on the StorageClass API object. The cluster administrator can define the StorageClass object as required. Each StorageClass object can specify a storage volume plug-in (i.e., provider). The cluster administrator can define a variety of storage volume offerings in a cluster, and users can select the storage that meets their requirements without having to understand the details and complexity of the storage.

3.1 Enable dynamic provisioning

To enable dynamic provisioning, the cluster administrator needs to create one or more storage-class objects for users in advance. The storage class object defines which provider to use and the parameters associated with the provider. Here is an example of a storage class that creates a storage class named Slow using a GCE provider:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standardCopy the code

Here we create a storage class named “FAST” that provides a volume disk like a solid state disk:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssdCopy the code

3.2 Use dynamic provisioning

The user requests dynamic provisioning storage by including a storage class in the PersistentVolumeClaim. In Kubernetes v1.6 version before, through the volume. The beta. Kubernetes. IO/storage – class annotation class request dynamic supply storage; After v1.6, users should request dynamic storage using the storageClassName parameter of the PersistentVolumeClaim object.

Here is an example YAML configuration file that requests a persistent storage volume declaration for the FAST storage class:

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: claim1 spec: accessModes: - ReadWriteOnce # Specify the storage class that will automatically create PV storageClassName: Fast Resources: Requests: Storage: 30GiCopy the code

This declaration will be similar to solid-state disks, and the volume will be destroyed when the persistent volume declaration is deleted.

3.3 The default behavior

If the Kubernetes cluster does not specify a storage class, the cluster administrator can enable the default storage class by performing the following Settings:

• Mark a default StorageClass object;
• Ensure that the DefaultStorage access controller is enabled on the API Server

Administrators can by adding storageclass. Kubernetes. IO/is – the default – the class notes, marking a particular storageclass as the default storage classes. In the cluster, if there is a default StorageClass, the system will be able to create a PersistentVolume without specifying storageClassName. DefaultStorageClass access controller automatically points storageClassName to the DefaultStorageClass. Note: There can be at most one default storage class in a cluster. If there is no default storage class, a PersistentVolume will not be created if the storageClassName specified is not shown in the PersistentVolumeClaim.

4,NFSStorage Class Example

4.1 Deploy the NFS – provisioner

Select the storage volume to store state and data for the NFS-provisioner instance and attach the storage volume to the container’s /export command.

. volumeMounts: - name: export-volume mountPath: /export volumes: - name: export-volume hostPath: path: /tmp/nfs-provisioner ...Copy the code

For StorageClass select a supplier name, and in the deploy/kubernetes/deployment. The yaml set.

args:
  - "-provisioner=example.com/nfs"
...Copy the code

The complete deployment.yaml file reads as follows:

kind: Service apiVersion: v1 metadata: name: nfs-provisioner labels: app: nfs-provisioner spec: ports: - name: nfs port: 2049 - name: mountd port: 20048 - name: rpcbind port: 111 - name: rpcbind-udp port: 111 protocol: UDP selector: app: nfs-provisioner --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nfs-provisioner spec: replicas: 1 strategy: type: Recreate template: metadata: labels: app: nfs-provisioner spec: Containers: - name: nfs-provisioner image: quay. IO /kubernetes_incubator/ NFs-provisioner :v1.0.8 ports: - name: nfs containerPort: 2049 - name: mountd containerPort: 20048 - name: rpcbind containerPort: 111 - name: rpcbind-udp containerPort: 111 protocol: UDP securityContext: capabilities: add: - DAC_READ_SEARCH - SYS_RESOURCE args: - "-provisioner=nfs-provisioner" env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: SERVICE_NAME value: nfs-provisioner - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace imagePullPolicy: "IfNotPresent" volumeMounts: - name: export-volume mountPath: /export volumes: - name: export-volume hostPath: path: /srvCopy the code

In setting up the deploy/kubernetes/deployment. The yaml file, through kubectl create command in kubernetes cluster deployment NFS – provisioner.

$ kubectl create -f {path}/deployment.yamlCopy the code

4.2 Create StorageClass

Here is the example-nfs StorageClass configuration file, which defines a StorageClass named nfs-storageclass whose provider is nfs-provisioner.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storageclass
  provisioner: nfs-provisionerCopy the code

Kubectl create -f with the above configuration file:

$ kubectl create -f deploy/kubernetes/class.yamlCopy the code

Storageclass “example – NFS” created

After the StorageClass is created correctly, PersistenetVolumeClaim can be created to request StorageClass, which will automatically create a PersistentVolume available for the PersistenetVolumeClaim.

4.3 create PersistenetVolumeClaim

PersistenetVolumeClaim is a claim to PersistenetVolume, which is the provider of storage and PersistenetVolumeClaim, which is the consumer of storage. Below is the YAML configuration file that PersistentVolumeClaim, which specifies the storage class to use through the spec.storageclassName field.

PersistenetVolume is created using the nfs-storageclass storageclass for PersistenetVolumeClaim. The PersistenetVolume is stored in 1Mi. Can be read and written by multiple containers.

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-pvc spec: accessModes: - ReadWriteMany storageClassName: NFS -storageclass resources: requests: storage: 1MiCopy the code

Create the above persistent storage volume declaration with kubectl create:

$ kubectl create -f {path}/claim.yamlCopy the code

4.4 Create a deployment that uses PersistenVolumeClaim

Here you define the deployment YAML configuration file named busybox-Deployment using the image busyBox. The busybox image-based container needs to persist data in the/MNT directory, and the YAML file specifies that the container PersistenVolumeClaim with the NFS name is used to persist the data in the container.

# This mounts the nfs volume claim into /mnt and continuously # overwrites /mnt/index.html with the time and hostname of  the pod. apiVersion: v1 kind: Deployment metadata: name: busybox-deployment spec: replicas: 2 selector: name: busybox-deployment template: metadata: labels: name: busybox-deployment spec: containers: - image: busybox command: - sh - -c - 'while true; do date > /mnt/index.html; hostname >> /mnt/index.html; sleep $(($RANDOM % 5 + 5)); done' imagePullPolicy: IfNotPresent name: busybox volumeMounts: # name must match the volume name below - name: nfs mountPath: "/mnt" # volumes: - name: nfs persistentVolumeClaim: claimName: nfs-pvcCopy the code

Create busy-deployment deployment with kubectl create:

$ kubectl create -f {path}/nfs-busybox-deployment.yamlCopy the code

The resources

1. The Storage Classes address: kubernetes. IO/docs/concep…
2. The Dynamic Volume Provisioning address: kubernetes. IO/docs/concep…
3. Nfs-provisioner Address: github.com/kubernetes-…

About the author: Ji Xiangyuan, product manager of Beijing Shenzhou Aerospace Software Technology Co., LTD. The copyright of this article belongs to the author.