k8s persistent storage data

kubernetes persistent storage data

Kubernetes Volume Volume
- roll
- background
- emptyDir
- hostPath
Actual mounting of NFS volume
- Application scenarios
- Mount NFS volume
Persistent storagePersistantVolume
- introduce
PVC persistent volumeClaim
- PersistentVolumeClaims
Storage ClassStorage Class
- What is Storage Class
- Why StorageClass is needed
- Collaboration process of PV, PVC, StorageClass

Kubernetes Volume Volume

Volume

The files in the container are temporarily stored on the disk, which brings some problems to the special applications running in the container. First, when the container crashes, the kubelet will restart the container and the files in the container will be lost – because the container will be rebuilt in a clean state. Secondly, when multiple containers are running simultaneously in a Pod, it is often necessary to share files between these containers. Kubernetes abstracts Volume objects to solve these two problems.

Background

Docker also has the concept of a volume, but it has only a small and loose management of it. In Docker, volume is a directory on disk or in another container. Until recently, Docker did not support lifetime management of volumes based on local disks. Although Docker now also provides volume drivers, the functionality is currently very limited (for example, as of Docker 1.7, only one volume driver is allowed per container, and parameters cannot be passed to volumes).

A Kubernetes volume, on the other hand, has an explicit lifecycle-the same as the Pod that encapsulates it. Therefore, the volume outlives any container running in the Pod, and the data is preserved across container restarts. Of course, when a Pod no longer exists, the volumes will no longer exist as well. Perhaps more importantly, Kubernetes can support many types of volumes, and Pods can use any number of volumes simultaneously.

The core of a volume is a directory containing some data that is accessible to containers in a Pod. The specific volume type determines how the directory is formed, what media it supports, and what is stored in the directory.

When using volumes, the type of volume (spec.volumes field) and the location where the volume is mounted (-spec.containers.volumeMounts field) need to be provided in the Pod declaration.

Kubernetes provides numerous volume types, including erptyDir, hostPath, nts. glusterts, cephts, and ceph. Let’s talk about emptyDir:

emptyDir

When a Pod is assigned to a node, an emptyDir volume is first created, and the volume will exist as long as the Pod is running on the node. As its name indicates, the volume is initially empty. Although the paths to the emptyDir volumes mounted by containers in a Pod may be the same or different, these containers can all read and write the same files in the empty Dir volumes. When a Pod is deleted from the node for some reason, the data in the emptyDir volume will also be permanently deleted.

Note: A container crash will not cause the Pod to be removed from the node, so the data in the emptyDir volume is safe when the container crashes.

Some uses of emptyDir:

Cache space, such as disk-based sorting.
Provide checkpoints for long-running computing tasks so that tasks can be easily resumed from their pre-crash state.
Save files obtained by the content manager type container when the web server container serves data.

hostPath

The hostPath volume can mount files or directories on the host node’s file system to the Pod. While this is not required by most Pods, it provides powerful persistence capabilities for some applications.

Practical mounting of NFS volumes

Application scenarios

Many applications need a unified place within the cluster to store files, such as pictures, logs, etc., but using hostPath is not flexible because you need to specify the address of the host.

Mount NFS volume

Install nts service on Master and all Worker nodes
```
yum install -y nfs-utils rpcbind
```
Modify configurationvi /etc/exports
```
/nfsdata *(rw,sync,no_root_squash)
```

Automatically starts on the master node system

systemctl enable --now rpcbind
systemctl enable --now nfs

If /etc/exports is modified, the configuration needs to be reactivated
```
exportfs -r
```

View nfs mounting effect

[root@master Chapter8]# showmount -e master
Export list for master:
/nfsdata *

? This means that /nfsdata is successfully mounted.

Create a Pod to reference NFS storage:

Execution code: kubectl apply -f 8-2-nfs.yaml

apiVersion: v1
Kind: Pod
metadata:
  name: nfs-pd
spec:
  containers:
  - name: test-container
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: master
      path: /nfsdata

View the pod mounting directory

implement:

kubectl describe pod myapp

You can see that the NFS type directory was successfully mounted.

Volumes:
  nfs:
    Type: NFS (an NFS mount that lasts the lifetime of a pod)
    Server: master
    Path: /nfsdata
    ReadOnly: false

Persistent storage PersistantVolume

Introduction

The management of storage is a completely different problem than the management of compute instances. The PersistentVolume subsystem provides users and administrators with a set of APs that abstracts the details of how storage is provisioned from how it is used. To achieve this, we have introduced two new API resources: Persistentvolume and PersistentVolumeClaim.

A Persistent Volume (PV) is a piece of storage in a cluster that can be provisioned in advance by an administrator or dynamically provisioned using a Storage Class. Persistent volumes are cluster resources, just like nodes are cluster resources. PV persistent volumes are implemented using volume plug-ins just like ordinary volumes, except that they have a life cycle independent of any Pod using PV. The implementation details of storage are documented in this API object, whether underlying it is NFS, isCS1, or a cloud-specific storage system.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  capacity:
    Storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /nfsdata
    server:master

Persistent Volume Claim (PersistentVolumeClaim, pVC) expresses the user’s request for storage. Conceptually similar to Pod. Pod will consume node resources, and PVC application will consume PV resources. Pods can request specific amounts of resources (CPU and memory); similarly PVC claims can request specific sizes and access modes (for example, you can require that the PV volume can be mounted in one of ReadWriteOnce, ReadOnly Many, or ReadWritelany modes, see Access model).

Although PersistentVolumeClaim allows users to consume abstract storage resources, a common situation is that users need PersistentVolume volumes with different properties (eg, performance) for different problems. Cluster administrators need to be able to provide PersistentVolume with different properties, and the differences between these PV volumes are not limited to volume size and access mode, without exposing the details of how the volume is implemented to users. In order to meet such needs, there is a storage class (StorageClass) source.

PVC persistent volume Claim

PersistentVolumeClaims

Each PVC object has spec and status parts, which correspond to the Claim specification and status respectively.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      Storage: 2Gi

access mode

Claim uses the same access mode convention as the volume when requesting storage with a specific access mode.

volume mode

Claim uses the same convention as volumes to indicate whether the volume is to be used as a file system or a block device.

resource

Claims, like Pods, can also request a specific amount of resources. In this context, the requested resource is storage. Both volumes and claims use the same resource model.

selection operator

Claim can set tag selectors to further filter the volume collection. Only volumes whose labels match the selector can be assigned to a claim. The selector contains two

Fields:

matchlabels – the volume must contain labels with this value

matchExpressions – Requirements constructed by setting a key, a list of values, and an operator. Legal operators are In, Notin, Exists, and DoesNotExist.

All requirements from matchLabels and matchExpressions are logically ANDed together. These requirements must be met to be considered a match.

kind

Claim can request a specific storage class by setting the name of the StorageClass for the storageClassNamne property. Only the PV volume of the requested class, that is, the PV volume whose storageClassName value is the same as the PVC setting, can be assigned to the PVC Claim.

PVC Claimn does not necessarily require a certain class. If the storageClassName attribute value of the PVC is set to w, it is considered that the request is for a storage class that has not been set.

PV volume, so this pVC Claim can only be assigned to a PV volume without a storage class set (a PersistentVolume (PV) object with no annotation set or an annotation value of w will not be deleted in the system, because doing so may cause data Lost. PVCs with no storageClassName set are quite different from this and will be treated differently by the cluster. The specific screening method depends on whether the DefaultStorageClass admission controller plug-in is enabled.

When a PVC sets a selector in addition to requesting Storage Class, the two requirements will be processed according to the logical AND relationship: only PVs that belong to the requested class and have the requested label can be bound to the PVC.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {<!-- -->key: environment, operator: In, values: [dev]}

Storage Class

What is Storage Class

Kubernetes provides a mechanism that can automatically create PVs, namely: Dynamic Provisioning. The core of this mechanism lies in the API object StorageClass.

The StorageClass object defines the following two parts:

Properties of Pv. For example, storage type, volume size, etc.
The storage plug-in needed to create this kind of PV

Why StorageClass is needed

In a large-scale Kubernetes cluster, there may be tens of thousands of PVCs, which means that operation and maintenance personnel must create these multiple PVs. In addition, as the project needs, new PVCs will continue to be submitted. , then the operation and maintenance personnel need to continuously add new PVs that meet the requirements, otherwise the new Pod will fail to be created because the PVC cannot be bound to the PV. Moreover, the certain storage space requested through the PVC is likely to be insufficient. To meet the various needs of applications for storage devices

Moreover, different applications may have different requirements for storage performance, such as read and write speed, concurrency performance, etc. In order to solve this problem, Kubernetes has introduced a new resource object for us: StorageClass. Through the definition of StorageClass, Administrators can define storage resources as certain types of resources, such as fast storage, slow storage, etc. Users can intuitively know the specific characteristics of various storage resources based on the description of StorageClass, so that they can use Go apply for suitable storage resources.

The naming of the StorageClass object is important. The user uses this naming to request the generation of a specific class. When creating a StorageClass object, the administrator sets the naming and other parameters of the StorageClass object. Once the object is created, it cannot be updated.

Administrators can specify a default storage class for PVCs that are not assigned to a specific StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: qgg-nfs-storage # The name here should be consistent with the environment variable PROVISIONER_NAME in the provisioner configuration file
parameters:
  archiveOnDelete: "false"