PV、PVC

前言
一、存儲卷
- 1. emptyDir 存儲卷
- - 1.1 概念
  - 1.2 實例
- 2. hostPath 存儲卷
- - 2.1 概念
  - 2.2 實例
- 3. nfs共享存儲卷
二、PV 和 PVC
- 1. 概念
- - 1.1 PV
  - 1.2 PVC
  - 1.3 PVC 的使用邏輯
  - 1.4 創建機制
  - 1.5 PV 和 PVC 的生命力周期
  - 1.6 創建及銷毀 PV 的流程
- 2. PV 和 PVC 的創建
- - 2.1 查看定義
  - 2.2 NFS 創建靜態PV
  - - 1) 配置nfs存儲
    - 2) 定義 PV
    - 3) 定義 PVC
    - 4) 測試訪問
  - 2.3 搭建 StorageClass + nfs-client-provisioner ，實現 NFS 的動態 PV 創建
  - - 1) 配置nfs服務
    - 2) 創建 Service Account
    - 3) 使用 Deployment 來創建 NFS Provisioner
    - 4) 創建 StorageClass
    - 5) 創建 PVC 和 Pod 測試
總結
- 1. 常使用的日志分析工具有些哪些以及它們如何與K8S集群進行通信
- 2. K8S 的存儲卷
- 3. PV 和 PVC
- 4. 創建 PV 的方式（PV類型）
- 5. PV 的四種狀態
- 6. 創建 PV 資源

前言

??容器磁盤上的文件的生命周期是短暫的，這就使得在容器中運行重要應用時會出現一些問題。首先，當容器崩潰時，kubelet 會重啟它，但是容器中的文件將丟失——容器以干凈的狀態（鏡像最初的狀態）重新啟動。其次，在Pod中同時運行多個容器時，這些容器之間通常需要共享文件。Kubernetes 中的Volume抽象就很好的解決了這些問題。Pod中的容器通過Pause容器共享Volume。

一、存儲卷

1. emptyDir 存儲卷

1.1 概念

??當Pod被分配給節點時，首先創建emptyDir卷，并且只要該Pod在該節點上運行，該卷就會存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以讀取和寫入emptyDir卷中的相同文件，盡管該卷可以掛載到每個容器中的相同或不同路徑上。當出于任何原因從節點中刪除 Pod 時，emptyDir中的數據將被永久刪除。

1.2 實例

mkdir /opt/volumes
cd /opt/volumesvim pod-emptydir.yaml 
apiVersion: v1
kind: Pod
metadata:name: pod-emptydirnamespace: defaultlabels:app: myapptier: frontend
spec:containers:- name: myappimage: ikubernetes/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80#定義容器掛載內容volumeMounts:#使用的存儲卷名稱，如果跟下面volume字段name值相同，則表示使用volume的這個存儲卷- name: html#掛載至容器中哪個目錄mountPath: /usr/share/nginx/html/- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentvolumeMounts:- name: html#在容器內定義掛載存儲名稱和掛載路徑mountPath: /data/command: ['/bin/sh','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done']#定義存儲卷volumes:#定義存儲卷名稱  - name: html#定義存儲卷類型emptyDir: {}kubectl apply -f pod-emptydir.yaml

在這里插入圖片描述

kubectl get pods -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
pod-emptydir   2/2     Running   0          49s   10.244.1.9   node01   <none>           <none>#在上面定義了2個容器，其中一個容器是輸入日期到index.html中，然后驗證訪問nginx的html是否可以獲取日期。以驗證兩個容器之間掛載的emptyDir實現共享。
curl 10.244.1.9
Fri Aug 11 07:19:57 UTC 2023
Fri Aug 11 07:19:59 UTC 2023
Fri Aug 11 07:20:01 UTC 2023
Fri Aug 11 07:20:03 UTC 2023
Fri Aug 11 07:20:05 UTC 2023
Fri Aug 11 07:20:07 UTC 2023
Fri Aug 11 07:20:09 UTC 2023
Fri Aug 11 07:20:11 UTC 2023
Fri Aug 11 07:20:13 UTC 2023
Fri Aug 11 07:20:15 UTC 2023
Fri Aug 11 07:20:17 UTC 2023
Fri Aug 11 07:20:19 UTC 2023
Fri Aug 11 07:20:21 UTC 2023
Fri Aug 11 07:20:23 UTC 2023
Fri Aug 11 07:20:25 UTC 2023
Fri Aug 11 07:20:27 UTC 2023
Fri Aug 11 07:20:29 UTC 2023
Fri Aug 11 07:20:31 UTC 2023
Fri Aug 11 07:20:33 UTC 2023
Fri Aug 11 07:20:35 UTC 2023
Fri Aug 11 07:20:37 UTC 2023
Fri Aug 11 07:20:39 UTC 2023
Fri Aug 11 07:20:41 UTC 2023
Fri Aug 11 07:20:43 UTC 2023
Fri Aug 11 07:20:45 UTC 2023
Fri Aug 11 07:20:47 UTC 2023

在這里插入圖片描述

2. hostPath 存儲卷

2.1 概念

??hostPath卷將 node 節點的文件系統中的文件或目錄掛載到集群中。

??hostPath可以實現持久存儲，但是在node節點故障時，也會導致數據的丟失。

2.2 實例

#在 node01 節點上創建掛載目錄
mkdir -p /data/pod/volume1
echo 'node01.abc.com' > /data/pod/volume1/index.html

在這里插入圖片描述

#創建 Pod 資源
vim pod-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-hostpathnamespace: default
spec:containers:- name: myappimage: nginx#定義容器掛載內容volumeMounts:#使用的存儲卷名稱，如果跟下面volume字段name值相同，則表示使用volume的這個存儲卷- name: html#掛載至容器中哪個目錄mountPath: /usr/share/nginx/html#讀寫掛載方式，默認為讀寫模式falsereadOnly: false#volumes字段定義了paues容器關聯的宿主機或分布式文件系統存儲卷volumes:#存儲卷名稱- name: html#路徑，為宿主機存儲路徑hostPath:#在宿主機上目錄的路徑path: /data/pod/volume1#定義類型，這表示如果宿主機沒有此目錄則會自動創建type: DirectoryOrCreate

在這里插入圖片描述

kubectl apply -f pod-hostpath.yaml#訪問測試
kubectl get pods -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
pod-hostpath   1/1     Running   0          25s   10.244.1.12   node01   <none>           <none>curl 10.244.1.12
node01.abc.com#刪除pod，再重建，驗證是否依舊可以訪問原來的內容
kubectl delete -f pod-hostpath.yaml  
kubectl apply -f pod-hostpath.yaml kubectl get pods -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
pod-hostpath   1/1     Running   0          31s   10.244.1.13   node01   <none>           <none>curl 10.244.1.13 
node01.abc.com

3. nfs共享存儲卷

#在stor01節點上環境配置
hostnamectl set-hostname stor01
systemctl stop firewalld
setenforce 0
rpm -q rpcbind
rpm -q nfs-utils

在這里插入圖片描述

#在stor01節點上安裝nfs，并配置nfs服務
mkdir /data/volumes -p
chmod 777 /data/volumesvim /etc/exports
/data/volumes 192.168.145.0/24(rw,no_root_squash)systemctl start rpcbind
systemctl start nfsshowmount -e
Export list for stor01:
/data/volumes 192.168.145.0/24

在這里插入圖片描述

#master節點操作
vim pod-nfs-vol.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-vol-nfsnamespace: default
spec:containers:- name: myappimage: ikubernetes/myapp:v1volumeMounts:- name: htmlmountPath: /usr/share/nginx/htmlvolumes:- name: htmlnfs:path: /data/volumesserver: stor01kubectl apply -f pod-nfs-vol.yamlkubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE    IP            NODE     NOMINATED NODE   READINESS GATES
pod-vol-nfs   1/1     Running   0          113s   10.244.1.14   node01   <none>           <none>

在這里插入圖片描述

#在nfs服務器上創建index.html
cd /data/volumes
vim index.html
<h1> nfs stor01</h1>

在這里插入圖片描述

#master節點操作
curl 10.244.1.14
<h1> nfs stor01</h1>kubectl delete -f pod-nfs-vol.yaml   #刪除nfs相關pod，再重新創建，可以得到數據的持久化存儲kubectl apply -f pod-nfs-vol.yaml

在這里插入圖片描述

二、PV 和 PVC

1. 概念

1.1 PV

??PV 全稱叫做 Persistent Volume，持久化存儲卷。它是用來描述或者說用來定義一個存儲卷的，這個通常都是由運維工程師來定義。

1.2 PVC

??PVC 的全稱是 Persistent Volume Claim，是持久化存儲的請求。它是用來描述希望使用什么樣的或者說是滿足什么條件的 PV 存儲。

1.3 PVC 的使用邏輯

??在 Pod 中定義一個存儲卷（該存儲卷類型為 PVC），定義的時候直接指定大小，PVC 必須與對應的 PV 建立關系，PVC 會根據配置的定義去 PV 申請，而 PV 是由存儲空間創建出來的。PV 和 PVC 是 Kubernetes 抽象出來的一種存儲資源。

1.4 創建機制

??PV和PVC模式是需要運維人員先創建好PV，然后開發人員定義好PVC進行一對一的Bond，但是如果PVC請求成千上萬，那么就需要創建成千上萬的PV，對于運維人員來說維護成本很高，Kubernetes提供一種自動創建PV的機制，叫StorageClass，它的作用就是創建PV的模板。

??創建 StorageClass 需要定義 PV 的屬性，比如存儲類型、大小等；另外創建這種 PV 需要用到的存儲插件，比如 Ceph 等。有了這兩部分信息，Kubernetes 就能夠根據用戶提交的 PVC，找到對應的 StorageClass，然后 Kubernetes 就會調用 StorageClass 聲明的存儲插件，自動創建需要的 PV 并進行綁定。

??總結：PV是集群中的資源。 PVC是對這些資源的請求，也是對資源的索引檢查。

1.5 PV 和 PVC 的生命力周期

PV和PVC之間的相互作用遵循這個生命周期：

Provisioning（配置）—> Binding（綁定）—> Using（使用）—> Releasing（釋放） —> Recycling（回收）

Provisioning，即 PV 的創建，可以直接創建 PV（靜態方式），也可以使用 StorageClass 動態創建
Binding，將 PV 分配給 PVC
Using，Pod 通過 PVC 使用該 Volume，并可以通過準入控制StorageProtection（1.9及以前版本為PVCProtection） 阻止刪除正在使用的 PVC
Releasing，Pod 釋放 Volume 并刪除 PVC
Reclaiming，回收 PV，可以保留 PV 以便下次使用，也可以直接從云存儲中刪除

??根據這 5 個階段，PV 的狀態有以下 4 種：

Available（可用）：表示可用狀態，還未被任何 PVC 綁定
Bound（已綁定）：表示 PV 已經綁定到 PVC
Released（已釋放）：表示 PVC 被刪掉，但是資源尚未被集群回收
Failed（失敗）：表示該 PV 的自動回收失敗

1.6 創建及銷毀 PV 的流程

??一個PV從創建到銷毀的具體流程如下：

一個PV創建完后狀態會變成Available，等待被PVC綁定。
一旦被PVC邦定，PV的狀態會變成Bound，就可以被定義了相應PVC的Pod使用。
Pod使用完后會釋放PV，PV的狀態變成Released。
變成Released的PV會根據定義的回收策略做相應的回收工作。

回收策略	作用
Retain	Retain就是保留現場，K8S集群什么也不做，等待用戶手動去處理PV里的數據，處理完后，再手動刪除PV。
Delete	Delete策略，K8S會自動刪除該PV及里面的數據。
Recycle	Recycle方式，K8S會將PV里的數據刪除，然后把PV的狀態變成Available，又可以被新的PVC綁定使用。

2. PV 和 PVC 的創建

2.1 查看定義

kubectl explain pv.spec    #查看pv定義的規格
FIELDS:apiVersion: v1kind: PersistentVolumemetadata:    #由于 PV 是集群級別的資源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespacename: spec

在這里插入圖片描述

kubectl explain pv.spec    #查看pv定義的規格
spec:nfs:（定義存儲類型）path:（定義掛載卷路徑）server:（定義服務器名稱）accessModes:（定義訪問模型，有以下三種訪問模型，以列表的方式存在，也就是說可以定義多個訪問模式）- ReadWriteOnce          #（RWO）卷可以被一個節點以讀寫方式掛載。 ReadWriteOnce 訪問模式也允許運行在同一節點上的多個 Pod 訪問卷。- ReadOnlyMany           #（ROX）卷可以被多個節點以只讀方式掛載。- ReadWriteMany          #（RWX）卷可以被多個節點以讀寫方式掛載。
#nfs 支持全部三種；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 網絡上運行 SCSI 協議的一種網絡存儲技術）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。capacity:（定義存儲能力，一般用于設置存儲空間）storage: 2Gi （指定大小）storageClassName: （自定義存儲類名稱，此配置用于綁定具有相同類別的PVC和PV）persistentVolumeReclaimPolicy: Retain    #回收策略（Retain/Delete/Recycle） 
---------------------------------------------------------------------------------------------------------------------------
#Retain（保留）：當用戶刪除與之綁定的PVC時候，這個PV被標記為released（PVC與PV解綁但還沒有執行回收策略）且之前的數據依然保存在該PV上，但是該PV不可用，需要手動來處理這些數據并刪除該PV。
#Delete（刪除）：刪除與PV相連的后端存儲資源。對于動態配置的PV來說，默認回收策略為Delete。表示當用戶刪除對應的PVC時，動態配置的volume將被自動刪除。（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
#Recycle（回收）：如果用戶刪除PVC，則刪除卷上的數據，卷不會刪除。（只有 NFS 和 HostPath 支持）

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-tvOYIL3i-1692012639956)(C:/Users/86138/AppData/Roaming/Typora/typora-user-images/image-20230814143406216.png)]

kubectl explain pvc   #查看PVC的定義方式
KIND:     PersistentVolumeClaim
VERSION:  v1
FIELDS:apiVersion	<string>kind	<string>  metadata	<Object>spec	<Object>

在這里插入圖片描述

#PV和PVC中的spec關鍵字段要匹配，比如存儲（storage）大小、訪問模式（accessModes）、存儲類名稱（storageClassName）
kubectl explain pvc.spec
spec:accessModes: （定義訪問模式，必須是PV的訪問模式的子集）resources:requests:storage: （定義申請資源的大小）storageClassName: （定義存儲類名稱，此配置用于綁定具有相同類別的PVC和PV）

在這里插入圖片描述

2.2 NFS 創建靜態PV

1) 配置nfs存儲

mkdir v{1,2,3,4,5}vim /etc/exports
/data/volumes/v1 192.168.145.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.145.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.145.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.145.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.145.0/24(rw,no_root_squash)exportfs -arv	#發出共享信息showmount -e

在這里插入圖片描述

2) 定義 PV

#這里定義5個PV，并且定義掛載的路徑以及訪問模式，還有PV劃分的大小。
vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:name: pv001labels:name: pv001
spec:nfs:path: /data/volumes/v1server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv002labels:name: pv002
spec:nfs:path: /data/volumes/v2server: stor01accessModes: ["ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv003labels:name: pv003
spec:nfs:path: /data/volumes/v3server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv004labels:name: pv004
spec:nfs:path: /data/volumes/v4server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv005labels:name: pv005
spec:nfs:path: /data/volumes/v5server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 5Gi

在這里插入圖片描述

kubectl apply -f pv-demo.yamlkubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                   26s
pv002   2Gi        RWO            Retain           Available                                   26s
pv003   2Gi        RWO,RWX        Retain           Available                                   26s
pv004   4Gi        RWO,RWX        Retain           Available                                   25s
pv005   5Gi        RWO,RWX        Retain           Available                                   25s

在這里插入圖片描述

3) 定義 PVC

??這里定義了pvc的訪問模式為多路讀寫，該訪問模式必須在前面pv定義的訪問模式之中。定義PVC申請的大小為2Gi，此時PVC會自動去匹配多路讀寫且大小為2Gi的PV，匹配成功獲取PVC的狀態即為Bound

vim pod-vol-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: mypvcnamespace: default
spec:accessModes: ["ReadWriteMany"]resources:requests:storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:name: pod-vol-pvcnamespace: default
spec:containers:- name: myappimage: nginxvolumeMounts:- name: htmlmountPath: /usr/share/nginx/htmlvolumes:- name: htmlpersistentVolumeClaim:claimName: mypvc

在這里插入圖片描述

kubectl apply -f pod-vol-pvc.yamlkubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON    AGE
pv001     1Gi        RWO,RWX        Retain           Available                                            19m
pv002     2Gi        RWO            Retain           Available                                            19m
pv003     2Gi        RWO,RWX        Retain           Bound       default/mypvc                            19m
pv004     4Gi        RWO,RWX        Retain           Available                                            19m
pv005     5Gi        RWO,RWX        Retain           Available                                            19mkubectl get pvc
NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mypvc     Bound     pv003     2Gi        RWO,RWX                       22s

在這里插入圖片描述

4) 測試訪問

#在存儲服務器上創建index.html，并寫入數據，通過訪問Pod進行查看，可以獲取到相應的頁面。
cd /data/volumes/v3/
echo "welcome to use pv3" > index.htmlkubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
pod-vol-nfs   1/1     Running   0          46m   10.244.1.2   node01   <none>           <none>
pod-vol-pvc   1/1     Running   0          18m   10.244.2.2   node02   <none>           <none>curl  10.244.2.2
welcome to use pv3

在這里插入圖片描述

2.3 搭建 StorageClass + nfs-client-provisioner ，實現 NFS 的動態 PV 創建

??Kubernetes 本身支持的動態 PV 創建不包括 NFS，所以需要使用外部存儲卷插件分配PV。詳見：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/

??卷插件稱為 Provisioner（存儲分配器），NFS 使用的是 nfs-client，這個外部卷插件會使用已經配置好的 NFS 服務器自動創建 PV。
Provisioner：用于指定 Volume 插件的類型，包括內置插件（如 kubernetes.io/aws-ebs）和外部插件（如 external-storage 提供的 ceph.com/cephfs）。

1) 配置nfs服務

#在stor01節點上安裝nfs
mkdir /opt/k8s
chmod 777 /opt/k8s/vim /etc/exports
/opt/k8s 192.168.145.0/24(rw,no_root_squash,sync)systemctl restart nfs

在這里插入圖片描述

2) 創建 Service Account

??創建 Service Account，用來管理 NFS Provisioner 在 k8s 集群中運行的權限，設置 nfs-client 對 PV，PVC，StorageClass 等的規則

vim nfs-client-rbac.yaml
#創建 Service Account 賬戶，用來管理 NFS Provisioner 在 k8s 集群中運行的權限
apiVersion: v1
kind: ServiceAccount
metadata:name: nfs-client-provisioner
---
#創建集群角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: nfs-client-provisioner-clusterrole
rules:- apiGroups: [""]resources: ["persistentvolumes"]verbs: ["get", "list", "watch", "create", "delete"]- apiGroups: [""]resources: ["persistentvolumeclaims"]verbs: ["get", "list", "watch", "update"]- apiGroups: ["storage.k8s.io"]resources: ["storageclasses"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["events"]verbs: ["list", "watch", "create", "update", "patch"]- apiGroups: [""]resources: ["endpoints"]verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
---
#集群角色綁定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: nfs-client-provisioner-clusterrolebinding
subjects:
- kind: ServiceAccountname: nfs-client-provisionernamespace: default
roleRef:kind: ClusterRolename: nfs-client-provisioner-clusterroleapiGroup: rbac.authorization.k8s.io

在這里插入圖片描述

kubectl apply -f nfs-client-rbac.yamlkubectl get sa			#查看創建的角色

在這里插入圖片描述

3) 使用 Deployment 來創建 NFS Provisioner

??NFS Provisioner(即 nfs-client)，有兩個功能：一個是在 NFS 共享目錄下創建掛載點(volume)，另一個則是將 PV 與 NFS 的掛載點建立關聯。

#由于 1.20 版本啟用了 selfLink，所以 k8s 1.20+ 版本通過 nfs provisioner 動態生成pv會報錯，解決方法如下：
vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:containers:- command:- kube-apiserver- --feature-gates=RemoveSelfLink=false       #添加這一行- --advertise-address=192.168.80.20
......kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
kubectl delete pods kube-apiserver -n kube-system 
kubectl get pods -n kube-system | grep apiserver

在這里插入圖片描述

#創建 NFS Provisioner
vim nfs-client-provisioner.yaml
kind: Deployment
apiVersion: apps/v1
metadata:name: nfs-client-provisioner
spec:replicas: 1selector:matchLabels:app: nfs-client-provisionerstrategy:type: Recreatetemplate:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisioner   	  #指定Service Account賬戶containers:- name: nfs-client-provisionerimage: quay.io/external_storage/nfs-client-provisioner:latestimagePullPolicy: IfNotPresentvolumeMounts:- name: nfs-client-rootmountPath: /persistentvolumesenv:- name: PROVISIONER_NAMEvalue: nfs-storage       #配置provisioner的Name，確保該名稱與StorageClass資源中的provisioner名稱保持一致- name: NFS_SERVERvalue: stor01           #配置綁定的nfs服務器- name: NFS_PATHvalue: /opt/k8s          #配置綁定的nfs服務器目錄volumes:              #申明nfs數據卷- name: nfs-client-rootnfs:server: stor01path: /opt/k8s

在這里插入圖片描述

kubectl apply -f nfs-client-provisioner.yaml kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-cd6ff67-sp8qd   1/1     Running   0          14s

在這里插入圖片描述

4) 創建 StorageClass

??創建 StorageClass，負責建立 PVC 并調用 NFS provisioner 進行預定的工作，并讓 PV 與 PVC 建立關聯

vim nfs-client-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: nfs-client-storageclass
provisioner: nfs-storage     #這里的名稱要和provisioner配置文件中的環境變量PROVISIONER_NAME保持一致
parameters:archiveOnDelete: "false"   #false表示在刪除PVC時不會對數據目錄進行打包存檔，即刪除數據；為ture時就會自動對數據目錄進行打包存檔，存檔文件以archived開頭

在這里插入圖片描述

kubectl apply -f nfs-client-storageclass.yamlkubectl get storageclass
NAME                      PROVISIONER   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-client-storageclass   nfs-storage   Delete          Immediate           false                  18s

在這里插入圖片描述

5) 創建 PVC 和 Pod 測試

vim test-pvc-pod.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: test-nfs-pvc#annotations: volume.beta.kubernetes.io/storage-class: "nfs-client-storageclass"     #另一種SC配置方式
spec:accessModes:- ReadWriteManystorageClassName: nfs-client-storageclass    #關聯StorageClass對象resources:requests:storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:name: test-storageclass-pod
spec:containers:- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentcommand:- "/bin/sh"- "-c"args:- "sleep 3600"volumeMounts:- name: nfs-pvcmountPath: /mntrestartPolicy: Nevervolumes:- name: nfs-pvcpersistentVolumeClaim:claimName: test-nfs-pvc      #與PVC名稱保持一致

在這里插入圖片描述

kubectl apply -f test-pvc-pod.yaml

在這里插入圖片描述

#PVC 通過 StorageClass 自動申請到空間
kubectl get pvc
NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS              AGE
test-nfs-pvc   Bound    pvc-ea0d73d0-42fd-455d-ab30-778ecd1aa342   1Gi        RWX            nfs-client-storageclass   105s

在這里插入圖片描述

#查看 NFS 服務器上是否生成對應的目錄，自動創建的 PV 會以 ${namespace}-${pvcName}-${pvName} 的目錄格式放到 NFS 服務器上
ls /opt/k8s/
default-test-nfs-pvc-pvc-ea0d73d0-42fd-455d-ab30-778ecd1aa342

在這里插入圖片描述

#進入 Pod 在掛載目錄 /mnt 下寫一個文件，然后查看 NFS 服務器上是否存在該文件
kubectl exec -it test-storageclass-pod sh
/ # cd /mnt/
/mnt # echo 'this is test file' > test.txt

在這里插入圖片描述

#發現 NFS 服務器上存在，說明驗證成功
cat /opt/k8s/default-test-nfs-pvc-pvc-ea0d73d0-42fd-455d-ab30-778ecd1aa34/test.txt

在這里插入圖片描述

總結

1. 常使用的日志分析工具有些哪些以及它們如何與K8S集群進行通信

日志分析工具：EFK
daemonset 控制器在K88s每個Node上部署filebeat或logstash的Pod，采用hostpath類型存儲卷共享宿主機上的日志目錄，供filebeat或logstas采集日志數據
在Pod添加采集filebeat或logstash邊車容器，并采用emptydir類型的存儲卷共享應用容器的日志目錄

2. K8S 的存儲卷

emptyDir	可實現Pod中的容器之間共享目錄數據，但emptyDir存儲卷沒有持久化數據的能力，存儲卷會隨著Pod生命周期結束而一起刪除。
hostPath	將Node節點上的目錄/文件掛載到Pod容器指定目錄中，有持久化數據的能力，但只能在單個node節點上持久化數據，不能實現跨Node節點的Pod共享數據。
nfs			使用NFS服務將存儲卷掛載到Pod容器的指定目錄中，有持久化數據的能力，且也能實現跨Node節點的Pod共享數據。

3. PV 和 PVC

PV：K8S在指定存儲設備空間中邏輯劃分創建的可持久化的存儲資源對象
PVC：是對PV資源對象的請求和綁定，也是Pod能掛在使用的一種存儲卷類型

4. 創建 PV 的方式（PV類型）

1）手動根據配置文件創建的的靜態Pod
2）通過StorageClass調用存儲卷插件創建的動態PV

5. PV 的四種狀態

Available（可用）：表示可用狀態，PV被創建出來了，還未被PVC綁定
Bound（已綁定）：表示PV已經被PVC綁定，PV與PVC是一對一的綁定關系
Released（已釋放）：表示PVC被刪除，但是PV資源還未被回收
Failed（失敗）：表示PV的自動回收失敗

6. 創建 PV 資源

#創建使用 靜態PV
1）準備好存儲設備和共享目錄
2）手動創建PV資源，配置 存儲卷類型 訪問模式（RWO RWX ROX RWOP） 存儲空間大小  回收策略（Retain Recycle Delete）等
3）創建PVC資源，配置請求PV資源的訪問模式（必要條件，必須是PV能支持的訪問模式） 存儲空間大小（默認就近選擇大于等于指定大小的PV）來綁定PV
4）創建Pod和Pod控制器資源掛載PVC存儲卷，配置存儲卷類型為 persistentVolumeClaim ，并在容器配置中定義存儲卷掛載點目錄
(不要在 Pod 配置中使用 nodeName 來指定部署節點。因為使用 nodeName， Pod 將會繞過 scheduler 的調度，PWC 將停留在 pending 狀態)

#創建使用 動態PV
1）準備好存儲設備和共享目錄
2）如果是外置存儲卷插件，需要先創建serviceaccount賬戶（Pod使用的賬戶）和做RBAC授權（創建角色授予相關資源對象的操作權限，再將賬戶和角色進行綁定），使serviceaccount賬戶具有對PV PVC StorageClass等資源的操作權限
3）創建外置存儲卷插件provisioner的Pod，配置中使用serviceaccount賬戶作為Pod的用戶，并設置相關環境變量參數
4）創建StorageClass（SC）資源，配置中引用存儲卷插件的插件名稱（PROVISIONER_NAME）
---------------- 以上操作是一勞永逸的，以后只需要創建PVC時設置StorageClass就可以自動調用存儲卷插件動態生成PV資源 ----------------
5）創建PVC資源，配置中設置 StorageClass資源名稱 訪問模式 存儲空間大小。創建PVC資源會自動創建相關的PV資源。
6）創建Pod資源掛載PVC存儲卷，配置存儲卷類型為 persistentVolumeClaim ，并在容器配置中定義存儲卷掛載點目錄