当前位置：网站首页>How does kubernetes store business data persistently? (10)

How does kubernetes store business data persistently? (10)

2022-06-29 02:46:00 【wzlinux】

Through the previous explanation , We know how to Pod Use in Volume To save the data .Volume Follow Pod The life cycle of is bound , When Pod After being deleted ,Volume The data in may be deleted together , See the corresponding volume plugin Requirements for use of , You can see the comparison table in the previous section .

Storage requirements

Here we also need to consider the following issues .

share Volume. at present Pod Internal Volume In fact, with Pod There is a static one-to-one binding relationship , Life cycle binding . This makes a difference Pod Can't share between Volume.
Reuse Volume Data in . When Pod To fail for some reason , After being deleted and recreated by the workload controller , We need to be able to reuse Volume Old data in .
Volume Some of its own strong relevance demands . For stateful workloads StatefulSet Come on , When it manages Pod There are some hardware or software problems in the host computer , For example, the disk is damaged 、kernel Abnormal etc. ,Pod again “ Long ” To other nodes , How to guarantee Volume and Pod A strong correlation between ？
Volume Function and semantic extension , Such as capacity 、 Tag information 、 Expand or shrink capacity, etc .

For this we are Kubernetes A special object is introduced in Persistent Volume（ abbreviation PV）, Separate computing from storage , Different controllers can be used to manage .

At the same time through PV, We can also work with Pod Decouple the life cycle of itself . One PV Can be several Pod Use at the same time , Even if Pod After being deleted ,PV This object still exists , Other new Pod It can still be reused . To better describe this association binding relationship , Easy to use , And shield more detailed parameters that users do not care about （ such as PV By whom 、 Where to create zone/region、 How to access , wait ）, We use an abstract object Persistent Volume Claim（PVC） To use PV.

We can PV It can be understood as a description of the actual physical storage resources ,PVC Is an easy to use abstraction API. stay Kubernetes in , We are all in Pod Pass through PVC How to use PV Of , See the picture below .

#yyds Dry inventory # Kubernetes How to persistently store business data ？(10)_ data

stay Kubernetes in , establish PV（PV Provision） There are two ways , Static and dynamic , As shown in the figure below .

#yyds Dry inventory # Kubernetes How to persistently store business data ？(10)_ Field _02

static state PV

#yyds Dry inventory # Kubernetes How to persistently store business data ？(10)_K8S_03

Let's start with static PV（Static PV）, The administrator manually creates the corresponding... On the back-end storage platform Volume, And then through PV Define the Kubernetes In the middle . Developers through PVC To use . Let's take a look at HostPath Type of PV Example ：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume # pv  Name 
  labels: # pv  Some of label
    type: local
spec:
  storageClassName: manual
  capacity: #  The  pv  The capacity of 
    storage: 10Gi
  accessModes: #  The  pv  New access mode 
    - ReadWriteOnce
  hostPath: #  The  pv  The use of  hostpath  type , It also supports the adoption of  CSI  Access to other  plugin
    path: "/mnt/data"

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.

here , We have defined a system called task-pv-volume Of PV,PV It is the resource of the cluster , It doesn't belong to one namespace. among storageClassName This field is some StorageClass The name of the object . We will be in the next section PV In the interpretation of the StorageClass The role of .

For each of these PV, We all need to set the storage capacity for it , Currently, only storage space settings are supported , For example, we have set up 10G Space size of . Other configurations will be added to the community in the future , Such as IOPS（Input/Output Operations Per Second, Input / output times per second ）、 Throughput, etc .

Here's the head accessMode You can specify the PV Several ways to access and mount ：

ReadWriteOnce（RWO） Indicates that the volume can only be mounted to one by reading and writing Pod Inside ;
ReadOnlyMany（ ROX） Indicates that the volume can be mounted to multiple nodes , And by multiple Pod Mount... As read-only ;
ReadWriteMany（RWX） Indicates that a volume can be mounted by multiple nodes in a read-write manner for multiple Pod Use at the same time .

Pay attention to one. PV There can only be one access mount mode . Different volume plugin Supported by accessMode Is not the same , In use , You can refer to the official This form Make a selection .

Let's look at this after we create it PV：

$ kubectl get pv task-pv-volume
NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s

     
      1.
      2.
      3.

You can see , This PV The status of is Available（ You can use ）.
Here we also see the above kubectl get There is a in the output of ReclaimPolicy Field , This field indicates that PV Recycling strategy for , The default is Retain, namely PV Data retention after use , The administrator needs to clean up the data manually . except Retain Outside , The following strategies are also supported ：

Recycle, I.e. recycling , This time will clear PV Data in ;
Delete, Delete immediately , This strategy is often used in the storage services of cloud service providers , such as AWS EBS.

Let's create another PVC：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
  namespace: dmeo
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.

When it's created ,Kubernetes Would be PVC Match the PV. We are PVC Specify the inside storageClassName by manua, At this time, I will only match storageClassName For the same manual Of PV. Once you find the right one PV after , You can bind to the PV On .

PVC yes namespace Level of resources , Let's create and see :

$ kubectl get pvc -n demo
NAME            STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   AGE
task-pv-claim   Bound    task-pv-volume   10Gi       RWO            manual         9s

     
      1.
      2.
      3.

We can see This PVC Already with our top PV Bound up . Let's check it out task-pv-volume This PV object , You can see that its state also changes from Available Turned into Bound.

$ kubectl get pv task-pv-volume
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                   STORAGECLASS   REASON   AGE
task-pv-volume   10Gi       RWO            Retain           Bound    default/task-pv-claim   manual                  2m12s

     
      1.
      2.
      3.

PV There are generally the following five states ：

Pending It means that at present PV It has not been created in the back-end storage system ;
Available That is, idle and available status , At this time, it has not been bound to any PVC On ;
Bound As in the above example , At this time, it has been bound to a PVC Yes ;
Released Indicates the bound PVC It has been deleted , But the resources have not been recycled ;
Failed Indicates that recycling failed .

Again , about PVC Come on , There are also three states ：

Pending Indicates that no... Has been bound PV;
Bound It means that you have been with a PV bound ;
Lost Relating to PV Out of contact .

Let's take a look at , How to be in Pod Use static... In PV. Look at the following example ：

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
  namespace: demo
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx:1.14.2
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.

Once I've created it ：

$ kubectl get pod task-pv-pod -n demo
NAME          READY   STATUS    RESTARTS   AGE
task-pv-pod   1/1     Running   1          82s
$ kubectl exec -it task-pv-pod -n demo -- /bin/bash
[email protected]:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay          40G  5.0G   33G  14% /
tmpfs            64M     0   64M   0% /dev
tmpfs           996M     0  996M   0% /sys/fs/cgroup
/dev/vda1        40G  5.0G   33G  14% /etc/hosts
shm              64M     0   64M   0% /dev/shm
overlay         996M  4.0M  992M   1% /usr/share/nginx/html
tmpfs           996M   12K  996M   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs           996M     0  996M   0% /proc/acpi
tmpfs           996M     0  996M   0% /sys/firmware

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

You can see ,PV Has been properly mounted to Pod Inside .
static state PV The biggest problem is that it is not convenient to use , The administrator creates a batch of specified specifications in advance PV, Cannot create on demand . In use , It is often encountered that the resource size does not match , Unequal specifications , cause PVC Can't bind PV The situation of . At the same time, it will cause a waste of resources , For example, one only needs 1G Spatial Pod, The binding 10G Of PV.

These problems , Can be dynamically PV To solve .

dynamic PV

To dynamically create PV, We need some parameters to help us create PV. Here we use StorageClass This object describes , You can Kubernetes There are many definitions in StorageClass, Here is a Storage Examples of definitions ：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-rbd-sc
  annotation:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/rbd #  mandatory , Used to specify volume plugin To create PV Physical resources 
parameters: #  Some of the parameters 
  monitors: 10.16.153.105:6789
  adminId: kube
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: kube
  userId: kube
  userSecretName: ceph-secret-user
  userSecretNamespace: default
  fsType: ext4
  imageFormat: "2"
  imageFeatures: "layering"

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.

You can use notes storageclass.kubernetes.io/is-default-class To specify the default StorageClass. So the newly created PVC Medium storageClassName Fields will automatically use the default StorageClass.

Here is a provisioner Field is required , Mainly used to specify which volume plugin To create PV. you 're right , This is exactly what we talked about last time CSI driver Name .

Now let's talk about the dynamic PV Process of work ：

#yyds Dry inventory # Kubernetes How to persistently store business data ？(10)_K8S_04

First we defined one StorageClass. When the user has created Pod in the future , It specifies PVC, This is the time Kubernetes Will be based on StorageClass As defined in Provisioner To call the corresponding plugin To create PV.PV Once created , Follow PVC Binding , Mount to Pod Use in .

StatefulSet How to use PV and PVC？

Remember when we said StatefulSet Problems left over from ？ about StatefulSet Managed Pod, Every Pod The use of Volume The data in are all different , And the relationship between them needs strong binding . Not at this time StatefulSet Of spec.template To point directly to PV and PVC 了 . So we were StatefulSet Used in volumeClaimTemplate, With this template We can do it for everyone Pod Generate a single PVC, And bind PV 了 , So as to realize stateful service Pod All have their own storage . What's generated here PVC Name and StatefulSet Of Pod Name the same , Are with a specific serial number .

You can see here StatefulSet Example :

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.
      20.
      21.
      22.
      23.
      24.
      25.
      26.
      27.
      28.
      29.
      30.
      31.
      32.

Last

In this chapter, we talked about PV、PVC as well as StorageClass, Their direct relationship and design ideas . Maybe when you first came into contact with these concepts , A little confused , But the problem to be solved by analyzing each object , It can help you master them better .

https://kubernetes.io/docs/concepts/storage/persistent-volumes/