K8S entry series (19) - NFS/PV/PVC of K8S storage

NFS

concept
A network file system that allows a system to share directories and files with others on the network. By using NFS, users and programs can access files on remote systems as if they were local files.
Application in K8S
In Kubernetes, NFS can be mounted to Pod through simple configuration, and the data in NFS can be permanently saved. At the same time, NFS supports simultaneous write operations. When the Pod is deleted, the Volume is unloaded and the content is retained. This means that NFS allows us to process data in advance, and these data can be passed between pods.
establish

yum  install  nfs-utils rpcbind  -y  
mkdir -p /data/{nfs1,nfs2,nfs3}
vi  /etc/exports
# add to
/data/nfs1  *(rw,no_root_squash,no_all_squash,sync)
/data/nfs2  *(rw,no_root_squash,no_all_squash,sync)
/data/nfs3  *(rw,no_root_squash,no_all_squash,sync)
# Refresh configuration
exportfs -r
# restart
systemctl restart rpcbind  && systemctl restart nfs
systemctl enable  rpcbind  && systemctl enable  nfs

PV/PVC

brief introduction
Persistent volume (PV) is a segment of network storage that has been configured by the administrator in the cluster. Resources in a cluster are like a node, which is a cluster resource. PV is a volume plug-in such as a volume, but has a lifecycle independent of any single pod that uses PV. This API object captures the implementation details of storage, that is, NFS, iSCSI or cloud provider specific storage systems.

Persistent volume claim (PVC) is a user stored request. It is similar to pod. Pod consumes node resources and PVC consumes storage resources. Pods can request specific levels of resources (CPU and memory). Permission requirements can request specific sizes and access modes.

PV classification
Create some Static clusters: PV Static administrators. They have details of the actual storage available to cluster users. It exists in the Kubernetes API and can be used.

Dynamic: when the static PV created by the administrator does not match the user's PersistentVolumeClaim, the cluster may try to dynamically configure the volume for PVC. This configuration is based on StorageClasses: PVC must request a class and the administrator must have created and configured the class for dynamic configuration. The declaration of this class is required to effectively disable dynamic configuration for itself

life cycle
PV is a resource in the cluster. PVC is not only a request for these resources, but also a claim inspection for resources. The interaction between PV and PVC follows this life cycle:
Create = > bind = > use = > release = > recycle

Support type

  • GCEPersistentDisk
  • AWSElasticBlockStore
  • AzureFile
  • AzureDisk
  • FC (Fibre Channel)
  • FlexVolume
  • Flocker
  • NFS
  • iSCSI
  • RBD (Ceph Block Device)
  • CephFS
  • Cinder (OpenStack block storage)
  • Glusterfs
  • VsphereVolume
  • Quobyte Volumes
  • HostPath (single node testing only – local storage is not supported in any way and WILL - - NOT WORK in a multi-node cluster)
  • VMware Photon
  • Portworx Volumes
  • ScaleIO Volumes

Create PV example

vim pvs.yml
# content
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
spec:
  # Specific storage capacity
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  # Access mode, ReadWriteOnce/ReadOnlyMany/ReadWriteMany, single node read / write / multi node read / write
  accessModes:
    - ReadWriteOnce
  # Recycling policy: Retain/Recycle/Delete, Retain/Recycle/Delete
  persistentVolumeReclaimPolicy: Recycle
  # PV can have a class, which is specified by setting the storageClassName attribute to the name of StorageClass. The PV of a particular class can only be bound to the PVC requesting that class. PV without storageClassName has no class and can only be bound to PVC that does not require a specific class.
  storageClassName: slow
  # Kubernetes administrators can specify additional installation options when mounting a persistent volume on a node
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    # nfs path
    path: /data/nfs1
    # nfs node IP
    server: 192.168.58.103
# establish
kubectl create -f pvs.yml
# see
kubectl get pv 


Analysis of important parameters:
Capability: specific storage CAPACITY
ACCESS MODES: ACCESS MODES
RECLAIM POLICY: RECLAIM POLICY
STATUS: STATUS (Available /Bound /Released /Failed available / bound / released / failed)

case

Deploy a Mysql and mount the data directory into pv

  1. When PVC is created and PV is not bound, K8S will automatically find PV according to PVC needs.
vim mysql-pvc.yaml
# add to
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-mysql-001
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
# 
kubectl apply  -f mysql-pvc.yaml
# View pvc 
kubectl get pvc 
  1. Create pod
apiVersion: v1
kind: Pod
metadata:
 labels:
  app: mysql-001
 name: mysql-001
spec:
   restartPolicy: Never
   containers:
   - name: mysql-001
     image: daocloud.io/library/mysql:5.7.4
     imagePullPolicy: IfNotPresent
     ports:
     - containerPort: 3306
       name: mysql-port
     env:
     - name: MYSQL_ROOT_PASSWORD
       value: admin123
     volumeMounts:
     - name: data
       mountPath: /var/lib/mysql
   volumes:
   - name: data
     persistentVolumeClaim:
       claimName: pvc-mysql-001
  1. After verification, enter the nfs directory and find that mysql data has been mounted

Tags: Java Kubernetes PV

Posted by hossein2kk on Sun, 08 May 2022 04:40:40 +0300