Volume

1. Concept

The volume of_Kubernetes is a component of pod, so it is defined in the specification of pod like a container. They are not separate Kubernetes objects, nor can they be created or deleted separately. Volumes can be used by all containers in pod, but they must be mounted in each container that needs to access them first. In each container, volumes can be mounted anywhere on its file system.

2. Why do you need Volume?

_The life cycle of files on container disks is short, which causes some problems when running important applications in containers. First, when the container crashes, kubelet restarts it, but the files in the container will be lost - the container restarts in a clean state (mirroring the original state). Secondly, when multiple containers are running simultaneously in Pod, files need to be shared between these containers. The Volume abstraction in Kubernetes solves these problems very well.

3. Volume type

2. emptyDir

1. emptyDir concept

_emptyDir is the most basic type of Volume, a simple empty directory for storing temporary data. If Pod sets the emptyDir type Volume, when Pod is assigned to Node, emptyDir will be created. As long as Pod runs on Node, emptyDir will exist (container hanging will not cause emptyDir to lose data), but if Pod is deleted from Node (Pod is deleted, or Pod migrates), emptyDir will also be deleted. And lost forever.

_Next, file sharing between two containers in the same pod will be achieved using emptyDir volumes

Create a pod emptydir-fortune, which has two containers and mounts the emptyDir volume. The container html-generator writes random content to the volume and verifies file sharing by accessing the container web-server.

3.2 nginx access

[root@master ~]# curl 10.102.191.57:8881
Writing is easy; all you do is sit staring at the blank sheet of paper until
drops of blood form on your forehead.
-- Gene Fowler
[root@master ~]# curl 172.27.9.135:30002
Don't Worry, Be Happy.
-- Meher Baba

Conclusion:

The container nginx successfully reads the contents written to the storage by the container fortune, and the emptyDir volume can realize file sharing between containers.

The lifetime of emptyDir volumes is associated with the lifetime of pods, so when pods are deleted, the contents of volumes are lost.

3. hostPath

1. Concept

_hostPath allows file systems on Node to be mounted into Pod. If Pod needs to use files on Node, host Path can be used. A pod running on the same node and using the same path in its hostPath volume can see the same file.

2. Create pod hostpath-nginx

2.1 Create mount directories

Create a mount directory on the node, and perform the following actions on the master and each node, respectively

3. Access pod hostpath-nginx

The pod runs on node01 and accesses the content of'node01'. For the index.html content of mounted file system / data, the container successfully reads the content of mounted node file system.

Use hostPath only when you need to read or write system files on a node. Never use them to persist data across pod s.

Host Path can achieve persistent storage, but it can also cause data loss when node fails.

4. NFS Shared Storage

1. Concept

NFS is the abbreviation of Network File System, i.e. Network File System. In Kubernetes, NFS can be mounted into Pod by simple configuration, while data in NFS can be permanently saved, while NFS supports simultaneous write operations.

_emptyDir can provide file sharing among different containers, but not storage; hostPath can provide file sharing and storage for different containers, but it is restricted by nodes and can not be shared across nodes; at this time, network storage (NAS) is needed, that is to say, it is convenient to store containers and can be accessed from any cluster node. This paper takes NFS as an example to test.

4.4 New pod reads shared storage data

Even if the pod is deleted and rebuilt, the shared data can still be accessed.

Conclusion:

NFS Shared Storage Persistent Data

NFS shared storage provides data sharing across nodes

V. PV and PVC

1. Concept

_Persistent Volume (PV) and Persistent Volume Claim (PVC) enable K8s cluster to have the logical abstraction ability of storage, which makes it possible to ignore the configuration of the actual background storage technology in the logic of configuring Pod, and leave the work of this configuration to the PV configurer, that is, the cluster. Manager. The relationship between stored PV and PVC is very similar to that between calculated Node and Pod; PV and Node are resource providers, which are configured by K8s cluster administrators according to changes in cluster infrastructure; while PVC and Pod are resource users, which vary according to changes in business service requirements and are used by K8s cluster. The provider is the administrator of the service to configure.

When cluster users need to use persistent storage in their pods, they first create a list of PVC, specify the minimum capacity requirements and access modes required, and then submit the list of pending volume declarations to the Kubernetes API server. Kubernetes will find a matching PV and bind it to PVC. PVC can be used as a volume in a pod, and other users cannot use the same PV unless it is released by removing the PVC binding first.

Released, the declaration deleted, but the resource has not yet been re-declared by the cluster

Failed, automatic recovery of the volume failed

There are three access modes for PV:

First, ReadWriteOnce: It's the most basic way, readable and writable, but only supports mounting by a single Pod.

Second, ReadOnlyMany: It can be mounted by multiple Pod s in a read-only manner.

Third, ReadWriteMany: This storage can be shared by multiple Pod s in a read-write manner. Not every kind of storage supports these three ways, such as sharing mode, which is less supported at present, and NFS is more commonly used.

PV does not belong to any namespace. Like nodes, PV is a cluster-level resource, which is different from pod and PVC.

3. Creating PVC

3.1 PVC Creation

[root@master ~]# more pvc-nfs.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mypvc #The name of the declaration, which is used as a volume for pod
spec:
accessModes:
- ReadWriteOnce #Access Volume Mode, Screening One of PV Conditions
volumeMode: Filesystem #Volume mode, consistent with PV, indicates that the volume is used as a file system or block device
resources: #Declare that you can request a specific number of resources to filter one of the PV conditions
requests:
storage: 2Gi
storageClassName: nfs #Request a specific class, consistent with PV, otherwise the binding cannot be completed
[root@master ~]# kubectl apply -f pvc-nfs.yaml
persistentvolumeclaim/mypvc created
[root@master ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mypvc Bound pv001 2Gi RWO nfs 22s

Create PVC mypvc, access volume mode is ReadWriteOnce, size is 2G; WO, ROX, RWX, RWO indicate the number of working nodes that can use volumes at the same time, not the number of pod s.